Tier와 Layer의 결정적 구분점은 분리 관점이다. Tier는 다른 서버·프로세스처럼 물리적으로 떨어진 실행 단위의 분리, Layer는 한 실행 단위 안에서 역할을 나누는 논리적 분리를 가리킨다.
2. 2→3-Tier 진화
클라이언트가 DB에 직접 붙던 2-Tier(Fat Client)는 보안·유지보수·확장성 문제가 있었고, 그래서 클라이언트와 DB 사이에 Application Server 계층을 끼운 3-Tier가 등장했다. 업무 로직과 트랜잭션·커넥션 관리를 서버 계층으로 옮긴 것이 핵심이다.
3. BaaS도 3-Tier
Supabase·Firebase처럼 클라이언트에서 DB로 바로 질의하는 듯 보여도 실제로는 중간에 Application Server가 동작하므로 2-Tier가 아니라 3-Tier다. '바로 연결하는 것처럼 보이는 코드'에 속지 말아야 한다.
Tier와 Layer는 원래 뜻(층·계층)은 비슷하지만, 무엇을 기준으로 나누는지가 다르다. Tier는 물리적 관점의 분리로, 물리적으로 떨어져 있기에 서로 다른 서버·프로세스가 된다. Layer는 논리적 관점의 역할 분리다.
구분
Tier
Layer
분리 관점
물리적 분리
논리적 분리
실체
다른 서버·프로세스 등 떨어진 실행 단위
한 실행 단위 안의 역할 계층
예시
3-Tier, N-Tier, Client-Server
OSI 7 Layer, (보충) MVC 같은 코드 내부 계층
주의할 점은 이 구분이 학술적으로도 업계에서도 엄밀하게 정의되어 있지 않고 혼용되는 경우가 더 많다는 것이다. 따라서 용어 자체보다 '물리적으로 분리된 실행 단위냐, 코드 안의 논리적 역할이냐'라는 기준을 잡는 것이 실질적이다.
⚠️ Tier와 Layer는 사전적 의미는 겹치지만 적용 관점이 갈린다. Tier는 물리적으로 떨어진 실행 단위(다른 서버·프로세스)를 가르는 말이고, Layer는 하나의 실행 단위 안에서 논리적 역할을 나누는 말이다. 다만 이 구분은 정식으로 완전히 정의된 것이 아니라 현업에서 혼용되는 경우가 많다는 점도 함께 기억해야 한다.
▶️ 관련 스크립트
Tier와 Layer 비교표입니다. 원래 뜻은 비슷합니다 — 어떤 층, 계층이죠. 핵심은 Tier는 물리적 관점에서의 분리, Layer는 논리적 관점에서의 계층 분리라는 점입니다. 이 부분이 둘의 구분점입니다. 물리적으로 떨어져 있기 때문에 다른 서버, 다른 프로세스가 되는 거죠.
2. 2-Tier(Fat Client) 시대와 그 한계
지금은 3-Tier가 대세지만, 한때 2-Tier 시대가 있었다. 이를 Fat Client 시대라고도 불렀는데, 1990년대부터 2000년대 초까지 Visual Basic, Delphi, Power Builder 같은 도구로 만든 설치형 데스크톱 프로그램이 DB에 직접 연동하는 구조였다.
이 구조의 문제는 세 가지다.
문제
원인
보안
클라이언트가 DB에 직접 연결됨
유지보수
업무 로직이 클라이언트에 모두 들어 있음
확장성
클라이언트마다 DB 커넥션을 직접 점유
특히 업무 로직이 클라이언트에 다 있다 보니, 로직이 조금만 바뀌어도 모든 클라이언트를 다시 배포해야 했다. 클라이언트가 DB와 직접 연결된다는 점이 보안 측면에서도 약점이었다.
⚠️ 2-Tier의 근본 문제는 '연결 구조'와 '로직 위치' 두 축에서 동시에 발생한다. 클라이언트가 DB에 직접 붙는 구조는 보안을 약하게 만들고, 업무 로직이 클라이언트에 들어 있는 구조는 작은 변경에도 전체 재배포를 강요한다. 즉 보안 문제와 유지보수 문제는 각각 다른 원인에서 나온 별개의 한계다.
▶️ 관련 스크립트
지금은 3-Tier가 대세지만 과거 한때 2-Tier 시대가 있었습니다. 2-Tier, Fat Client 시대라고 불렀는데요. 1990년대부터 2000년대 초까지 Visual Basic, Delphi, Power Builder 같은 것으로 구현체를 만들었습니다.
설치용 데스크톱 프로그램으로 설치되어 DB하고 직접 연동하는 거죠. 이게 2-Tier 형태의 애플리케이션이었습니다. 그런데 2-Tier는 문제가 있었죠 — 보안 문제, 유지보수 문제, 확장성 문제. 클라이언트가 DB하고 직접 연결되다 보니 보안 문제가 있었고, 업무 로직이 클라이언트에 다 있다 보니 로직이 조금만 바뀌어도 클라이언트를 다시 배포해야 했죠.
3. 3-Tier 등장과 Application Server의 역할
3-Tier의 핵심은 클라이언트와 데이터베이스 사이에 Application Server 계층을 추가한 것이다. 이 계층이 2-Tier의 한계를 그대로 해소한다.
Application Server가 맡는 역할은 다음과 같다.
역할
효과
업무 로직 담당
로직이 서버에 모이므로 변경 시 클라이언트 재배포 불필요
DB Connection Pool 중앙 관리
커넥션을 모아 관리해 확장성 확보
Transaction 관리
트랜잭션을 서버 계층에서 일관 처리
보안·기능의 경계
클라이언트와 DB 사이를 가로막는 경계 역할
즉 클라이언트를 DB에서 떼어내고 그 사이에 로직·연결·보안의 책임을 모두 떠안는 중간 실행 단위를 둔 것이 3-Tier의 본질이다. 이 계층이 물리적으로 분리된 별도 실행 단위이기 때문에 'Tier'가 하나 늘어난 것으로 센다.
⚠️ Application Server는 단순한 '중계기'가 아니라 책임의 집결지다. 클라이언트가 DB에 직접 닿지 못하게 막는 보안·기능의 경계 역할이 핵심이며, 커넥션 풀과 트랜잭션을 중앙에서 관리한다는 점이 확장성과 일관성을 동시에 가져온다.
▶️ 관련 스크립트
그래서 3-Tier가 등장했습니다. 3-Tier의 핵심은 클라이언트와 데이터베이스 사이에 Application Server 계층이 추가된 것입니다. Application Server는 업무 로직을 담당하고, DB Connection Pool을 중앙에서 관리하고, Transaction을 관리하고, 클라이언트와 DB 사이의 보안과 기능의 경계 역할을 했습니다.
4. BaaS(Supabase)는 2-Tier가 아니다 — 보이는 구조에 속지 마라
최근 Supabase 같은 BaaS는 클라이언트(예: React)에서 마치 DB로 바로 연결해 질의하는 것처럼 코드가 작성된다. 그래서 '이건 2-Tier 아닌가?'라는 오해가 생긴다.
하지만 실제로는 코드가 React에서 쿼리하듯 작성될 뿐, 중간에서 Application Server가 동작한다. 클라이언트가 데이터베이스로 바로 연결되는 것이 아니라 중간 계층을 거치므로 결국 3-Tier 구조다.
이 절의 교훈은 'Tier를 셀 때는 코드의 겉모양이 아니라 실제로 거치는 물리적 실행 단위를 봐야 한다'는 것이다. 클라이언트 코드가 DB를 직접 부르는 것처럼 보여도, 그 호출이 별도 서버 계층을 통과한다면 그것은 2-Tier가 아니다.
⚠️ 겉으로 드러난 코드 형태와 실제 실행 경로는 다를 수 있다. Supabase로 '바로 연결하는 것처럼 보이는' 코드라도 중간에 Application Server가 있으면 그것은 2-Tier가 아니라 3-Tier다. Tier 판정 기준은 코드의 작성 방식이 아니라 요청이 실제로 통과하는 물리적 계층의 수다.
▶️ 관련 스크립트
Supabase로 마치 바로 연결하는 것처럼 보이죠? 이게 2-Tier일까요?
비록 코드는 React에서 마치 쿼리를 하는 것처럼 작성하지만, 실제로는 중간에 Application Server가 동작하는 것입니다.
그래서 React에서 데이터베이스로 바로 연결되는 것이 아니라 중간 계층을 이용하는 거죠. 결국 3-Tier 구조입니다.
Supabase로 연결하는 것은 2-Tier가 아닙니다. 중간에 Application Server가 있습니다.
5. 마무리 정리와 더 생각해볼 주제
화자가 직접 정리한 핵심은 다음과 같다.
Tier는 물리적 계층 분리, Layer는 논리적 역할 분리
과거 한때 2-Tier(Fat Client) 시대가 있었고
지금은 3-Tier가 대세이며, 요즘은 N-Tier까지 확장하는 추세다
그리고 화자는 더 파고들 만한 질문 세 가지를 던진다.
Micro Service Architecture는 몇 Tier인가?
CORBA, DCOM은 사라지고 REST API가 살아남은 이유는 무엇인가?
Firebase, Supabase 같은 BaaS를 쓰면 백엔드 개발자가 필요 없어질까?
이 질문들은 이번 영상에서 답하지 않고 남겨둔 사고거리로, '물리적 분리'라는 같은 기준을 더 복잡한 현대 아키텍처에 적용해 보라는 확장 과제다.
⚠️ 마무리 정리는 영상 전체를 한 문장 기준으로 압축한다. 결국 이 영상의 한 줄 요약은 'Tier는 물리적 분리, Layer는 논리적 분리이며, 2-Tier→3-Tier→N-Tier로 확장되어 왔다'는 것이다. 던져진 세 질문은 이 기준을 MSA·BaaS 같은 최신 구조로 직접 적용해 보라는 의도다.
▶️ 관련 스크립트
자, 정리하겠습니다. Tier는 물리적 계층 분리, Layer는 논리적 역할 분리. 과거 한때 2-Tier, Fat Client 시대가 있었습니다.
지금은 3-Tier가 대세고요, 요즘에는 N-Tier까지 확장하는 추세죠. 조금 더 생각해 볼까요? Micro Service Architecture는 몇 Tier일까요? 그리고 CORBA, DCOM은 사라지고 REST API가 살아남은 이유는 뭘까요? 그리고 Firebase, Supabase 같은 BaaS를 쓰면 백엔드 개발자가 필요 없어질까요?
개발 가이드라인
아키텍처의 Tier 수를 셀 때는 코드의 겉모양이 아니라 '물리적으로 분리된 실행 단위'를 기준으로 세고, 코드 내부의 역할 분리(Layer)와 혼동하지 마라.
BaaS(Supabase/Firebase)를 쓰더라도 클라이언트가 DB에 직접 붙는 게 아니라 중간 서비스 계층을 거치므로 3-Tier로 이해하고, 보안·권한 경계를 그 중간 계층에 두어라.
업무 로직을 클라이언트에 두면 작은 변경에도 전체 재배포가 필요해지니, 로직·트랜잭션·DB 커넥션 관리는 Application Server 계층에 집중시켜라.