요약
Layer와 Tier 차이는 개발을 처음 배울 때보다, 오히려 실무에서 더 자주 헷갈리는 주제다. 오늘 직원과 커피를 마시며 이 이야기를 하다가, 주니어 개발자들이 은근히 많이 헷갈리는 지점이라는 생각이 들어 정리해봤다.
짧게 말하면 Layer는 논리적인 책임 분리에 가깝고, Tier는 물리적인 배포/실행 단위 분리에 가깝다. 다만 현업에서는 두 단어가 자주 섞여 쓰이기 때문에, 단어 자체보다 “지금 논리 구조를 말하는지, 배포 구조를 말하는지”를 먼저 보는 편이 더 안전하다.
목차
이 글에서 다루는 내용
커피 마시다 나온 Layer와 Tier 이야기
오늘 직원과 커피를 마시면서 아키텍처 이야기를 하다가 Layer와 Tier 이야기가 나왔다. 사실 오래 개발한 사람에게는 익숙한 단어처럼 느껴질 수 있다. Presentation Layer, Business Layer, Data Access Layer. 2-tier, 3-tier, N-tier. 워낙 많이 들어온 말이다.
이 글은 그 대화에서 출발해 Layer vs Tier 차이를 실무에서 덜 헷갈리게 정리해본 기록이다.
그런데 이야기를 하다 보니, 이게 주니어 개발자 입장에서는 생각보다 헷갈릴 수 있겠다는 생각이 들었다. 둘 다 한국어로는 “계층”이라고 번역되기 쉽고, 자료마다 “3-layer architecture”, “3-tier architecture” 같은 표현이 섞여 나오기도 한다. 심지어 실무자들도 편하게 말하다 보면 둘을 엄격히 구분하지 않을 때가 많다.
그래서 이 글은 “정답 시험”처럼 Layer와 Tier를 외우자는 글이 아니다. 회의나 코드 리뷰에서 서로 다른 그림을 떠올리지 않기 위해, 어떤 관점에서 구분하면 좋은지 정리해보는 글이다.
Layer는 논리적인 책임 분리다
Layer는 보통 소프트웨어 내부를 역할과 책임에 따라 나누는 논리적인 구분이다. 예를 들면 다음과 같은 식이다.
- Presentation Layer: 화면, 요청/응답, 사용자와 맞닿는 부분
- Business Layer 또는 Domain Layer: 업무 규칙과 핵심 판단
- Data Access Layer: 데이터베이스나 외부 저장소 접근
이 구분은 하나의 애플리케이션 안에서도 가능하다. 같은 서버, 같은 프로세스, 같은 배포 파일 안에 있어도 역할이 나뉘어 있으면 Layer라고 말할 수 있다. 예를 들어 Spring 애플리케이션 안에서 Controller, Service, Repository를 나누는 것은 물리적으로 서버가 세 대라서가 아니라, 코드의 책임을 분리하기 위해서다.
Layer를 볼 때는 “어디에 배포됐나?”보다 “무슨 책임을 맡고 있나?”를 먼저 본다.
Tier는 물리적인 배포 분리다
Tier는 보통 물리적으로 분리된 실행/배포 단위를 말할 때 쓴다. “물리적”이라는 말이 꼭 실제 서버 장비 한 대를 뜻하는 것은 아니다. 별도 서버, 별도 프로세스, 별도 네트워크 경계, 별도 배포 단위처럼 런타임에서 분리되어 있느냐가 핵심이다.
가장 익숙한 예는 3-tier 구조다.
- Client Tier: 브라우저, 모바일 앱, 데스크톱 클라이언트
- Application Tier: 웹 서버, WAS, API 서버, 업무 로직 서버
- Data Tier: 데이터베이스, 저장소
Microsoft의 N-tier architecture 설명도 애플리케이션을 logical layers와 physical tiers로 나눈다고 설명한다. 이 표현이 꽤 깔끔하다. Layer는 논리적인 층이고, Tier는 물리적인 배포 층이다.
Layer vs Tier 차이가 헷갈리는 이유
헷갈리는 이유는 단순하다. 실제 시스템에서는 Layer와 Tier가 서로 겹쳐 보이기 때문이다.
| 구분 | Layer | Tier |
|---|---|---|
| 관점 | 논리적 책임 | 물리적 실행/배포 |
| 주요 질문 | 이 코드는 무슨 역할인가? | 이 구성요소는 어디서 실행되는가? |
| 예시 | Controller, Service, Repository | Browser, API Server, Database |
| 분리 기준 | 함수 호출, 모듈, 패키지, 책임 | 네트워크 호출, 프로세스, 서버, 배포 단위 |
| 같은 서버에 있어도 되는가 | 가능하다 | 보통 분리됐다고 보기 어렵다 |
예를 들어 Controller, Service, Repository가 모두 하나의 애플리케이션 안에 있으면 3-layer 구조라고 말할 수 있다. 하지만 그것만으로 3-tier라고 말하기는 어렵다. 반대로 브라우저, API 서버, DB 서버가 나뉘어 있으면 3-tier 구조라고 볼 수 있다. 그 안의 API 서버 내부에는 또 여러 Layer가 있을 수 있다.
또 하나의 이유는 단어가 현업에서 엄격하게만 쓰이지 않는다는 점이다. 참고한 영상에서도 말하듯이 Layer와 Tier는 학문적으로 항상 완벽히 분리되어 쓰이는 말이라기보다, 업계에서 혼용되는 경우가 많다. 그래서 단어 하나만 보고 싸우기보다, 말하는 사람이 어떤 그림을 떠올리는지 확인하는 게 더 중요하다.
예로 보면 더 쉽게 구분된다
예 1. 하나의 서버에 있는 Spring 애플리케이션
Controller, Service, Repository가 잘 나뉘어 있고, DB 접근 코드가 Repository로 모여 있다고 하자. 이건 Layer 분리가 잘 된 예다. 하지만 애플리케이션이 하나의 서버 프로세스로 실행되고 있다면, 배포 관점에서는 여전히 하나의 Application Tier로 볼 수 있다.
예 2. 브라우저, API 서버, 데이터베이스
브라우저가 API 서버를 호출하고, API 서버가 DB에 접근한다. 이 구조는 전형적인 3-tier에 가깝다. Client Tier, Application Tier, Data Tier가 네트워크 경계를 두고 분리되어 있기 때문이다. 그리고 API 서버 내부에는 Presentation/API Layer, Business Layer, Data Access Layer가 다시 존재할 수 있다.
예 3. 과거 2-tier 클라이언트/서버
예전에는 데스크톱 프로그램이 DB에 직접 붙는 구조가 많았다. Visual Basic, Delphi, PowerBuilder 같은 도구로 만든 클라이언트 프로그램이 DB와 직접 통신하는 형태다. 이 경우 Client Tier와 Data Tier가 바로 연결된다. 업무 로직이 클라이언트에 많이 들어가면 배포와 보안, 유지보수에서 부담이 커진다. 그래서 중간에 Application Tier를 두는 3-tier 구조가 자연스럽게 중요해졌다.
예 4. React에서 Supabase를 직접 호출하면 2-tier일까?
커피 마시며 이야기할 때 실제로 논쟁이 됐던 예가 이것이었다. React 애플리케이션에서 Supabase를 직접 호출하면 2-tier라고 봐야 하느냐는 질문이다.
내가 보기에는 이 질문이 Layer와 Tier를 헷갈리기 좋은 대표 사례다. 브라우저에서 실행되는 React 앱이 있고, 그 앱이 별도 백엔드 서버 없이 Supabase API를 직접 호출한다면, 배포/실행 관점에서는 대략 Client Tier와 Supabase 쪽 Backend/Data Tier가 직접 연결된 구조처럼 볼 수 있다. 전통적인 3-tier에서 말하는 “내가 운영하는 Application Server Tier”가 얇거나 없는 셈이다.
하지만 그렇다고 해서 애플리케이션 안에 Layer가 없는 것은 아니다. React 코드 안에서도 화면 컴포넌트, 상태 관리, API 호출 모듈, 도메인성 검증 로직을 나눌 수 있다. 이건 여전히 논리적인 Layer 분리다. 즉 Tier 관점에서는 2-tier처럼 보일 수 있지만, Layer 관점에서는 여러 책임으로 나눌 수 있다.
다만 Supabase를 단순히 “DB”라고만 보면 설명이 조금 거칠어진다. Supabase는 PostgreSQL만 노출하는 것이 아니라 Auth, Storage, Edge Functions, Realtime, REST/GraphQL 계층 같은 백엔드 기능을 함께 제공한다. 그래서 “React가 DB에 직접 붙는다”보다는 “React가 관리형 백엔드 플랫폼을 직접 호출한다”에 가깝다. 이 차이를 말해두면 논쟁이 훨씬 덜 거칠어진다.
그래서 회의에서는 이렇게 정리하는 편이 낫다. “우리 서버를 따로 두지 않고 React가 Supabase를 직접 호출하니 배포 관점에서는 2-tier에 가깝다. 하지만 React 내부 코드 구조는 별도의 layer로 나눠서 관리해야 한다.”
실무에서는 이렇게 말하면 덜 헷갈린다
나는 주니어 개발자에게 이 주제를 설명할 때, 용어 자체보다 질문을 바꿔보라고 말하는 편이 좋다고 느꼈다.
- Layer를 말하는 중인가? 그러면 책임, 역할, 코드 구조, 의존 방향을 보고 있다.
- Tier를 말하는 중인가? 그러면 배포 위치, 프로세스, 네트워크 경계, 서버 구성을 보고 있다.
회의에서 “우리 서비스는 3-layer야”라고 말하면 누군가는 Controller-Service-Repository를 떠올릴 수 있고, 누군가는 브라우저-WAS-DB를 떠올릴 수 있다. 이때 “논리적인 layer 이야기인가요, 배포 tier 이야기인가요?”라고 한 번만 물어도 대화가 훨씬 선명해진다.
개인적으로는 문서에 쓸 때 Layer는 코드/책임 구조, Tier는 배포/실행 구조라고 먼저 정의해두는 편이 좋다. 특히 신규 프로젝트 온보딩 문서에서는 이 한 줄이 생각보다 많은 오해를 줄여준다.
결론
Layer와 Tier는 둘 다 계층을 뜻하지만, 실무에서 구분할 때는 관점이 다르다. Layer는 논리적인 책임 분리이고, Tier는 물리적인 실행/배포 분리다.
물론 현실에서는 두 단어가 섞여 쓰인다. 그래서 “이 표현이 무조건 틀렸다”고 말하기보다, 지금 논리 구조를 이야기하는지 배포 구조를 이야기하는지 확인하는 습관이 더 중요하다. 오늘 커피 마시며 나눈 짧은 대화에서 다시 느낀 점은, 이런 기본 용어일수록 주니어에게는 한 번 명확히 정리해주는 게 도움이 된다는 것이다.
다음에 누군가 “3-layer랑 3-tier가 같은 거 아닌가요?”라고 묻는다면, 이렇게 답하면 될 것 같다. 겹쳐 보일 수는 있지만, Layer는 코드의 책임을 나누는 말이고 Tier는 실행되는 자리를 나누는 말이다.