3-Tier 구조, 그리고 이게 VPC와 만나는 지점

웹 서비스를 설계할 때 "왜 웹서버, 애플리케이션 서버, DB 서버를 따로 두는가?"라는 질문에서 시작하는 개념이 3-tier 구조다.

---

3-Tier 구조

 

Presentation Tier — 웹서버, 로드밸런서. 사용자가 직접 마주하는 곳이다. 매장의 카운터라고 보면 된다.

Application Tier — WAS, API 서버. 실제 비즈니스 로직을 처리한다. 손님은 못 들어오는 주방에 해당한다.

Data Tier — DB 서버. 데이터를 저장하는 창고다. 주방(Application Tier)만 드나들 수 있고, 카운터 직원조차 직접 못 들어간다.

트래픽은 항상 한 방향으로 흐른다.

사용자 → Presentation → Application → Data

---

왜 굳이 나누는가

계층을 나누는 이유는 네 가지로 요약된다.

• 보안: DB가 인터넷에 직접 노출되지 않는다. 웹서버가 뚫려도 공격자가 바로 DB까지 가지 못한다.
• 독립적 확장: 웹 트래픽만 몰리면 Presentation Tier만 늘리면 된다. DB까지 같이 키울 필요가 없다.
• 장애 격리: 한 계층에 문제가 생겨도 나머지 계층은 원칙적으로 영향을 덜 받는다.
• 유지보수: 계층별로 기술 스택과 담당자가 분리되어 있어 수정과 배포가 독립적이다.

---

VPC 위에서는 이렇게 구현된다

3-tier는 논리적인 설계 개념이고, 이걸 실제 클라우드 네트워크에 옮겨놓은 게 VPC의 Public/Private Subnet 구조다.

• Presentation Tier → Public Subnet (외부 접근이 필요하니까)
• Application Tier → Private Subnet (반드시 Presentation Tier를 거쳐야 접근 가능)
• Data Tier → 가장 안쪽 Private Subnet (Application Tier에서 오는 트래픽만 허용)

각 계층 사이의 경계는 보안그룹으로 강제된다. 예를 들어 Data Tier의 보안그룹은 "Application Tier 보안그룹에서 오는 3306 포트 요청만 허용"처럼 설정해서, DB 서버가 인터넷과 통신할 물리적 경로 자체를 없애버린다.

---

정리

3-tier 구조는 "누가 무엇을 처리하는가"를 나누는 설계이고, VPC의 서브넷 분리는 그 설계를 네트워크 레벨에서 실제로 강제하는 장치다. 애플리케이션 아키텍처와 인프라 네트워크 설계가 결국 같은 그림을 그리고 있다는 걸 이해하면, 왜 DB 서버를 Private Subnet 깊숙이 넣는지가 자연스럽게 납득된다.