– 시스템 설계의 고전적 구조를 현대적으로 재해석하다
“단순한 구조 같지만, 깊이 들여다보면 분산 시스템의 근간이 여기에 있다.”
📌 1. 들어가며: 왜 3계층 아키텍처인가?
WEB-WAS-DB 구조는 1990년대 후반부터 등장하여, 2000년대 인터넷 서비스의 폭발적 성장과 함께 분산 시스템 설계의 사실상 표준 구조로 자리잡았습니다.
오늘날 클라우드 환경, 마이크로서비스, 서버리스 구조가 부상하고 있지만, 이 3계층 구조의 철학과 역할 분리는 여전히 현대 아키텍처의 근간을 이룹니다.
“3계층 아키텍처는 단순한 기술 스택이 아니라, 시스템의 책임과 복잡성을 나누는 설계 원칙이다.”
🔍 2. 각 계층의 기술적 정의와 책임
| 계층 | 주요 역할 | 기술 스택 예시 |
|---|---|---|
| WEB (Presentation Layer) | 사용자 인터페이스, 요청 수신, 정적 자원 제공 | Nginx, Apache, CDN, React, Vue |
| WAS (Application Layer) | 비즈니스 로직, 인증, 트랜잭션 처리 | Tomcat, Spring Boot, Node.js, Django |
| DB (Data Layer) | 영속성, 트랜잭션 보장, 데이터 정합성 | PostgreSQL, MySQL, Oracle, MongoDB |
🧩 책임 분리의 원칙 (Separation of Concerns)
- WEB은 단순 라우팅, 프레젠테이션 → 확장성과 보안 고려 용이
- WAS는 비즈니스의 심장 → 확장과 격리 필요
- DB는 트랜잭션/정합성 보증 → 성능·복제·보안 중심 설계
🛠️ 3. 아키텍처 설계 시 고려 요소
1. 스케일 아웃 전략
- WEB과 WAS는 수평 확장이 유리 → Stateless 설계 권장
- DB는 수직 확장 한계 존재 → Read Replication, Sharding 필요
2. 트랜잭션 보장
- WAS ↔ DB 간의 ACID 보장
- 멀티노드 WAS 간의 분산 트랜잭션 문제 고려 (XA Protocol, SAGA 패턴 등)
3. 보안 계층화
- WEB ↔ 사용자: HTTPS, 인증 토큰
- WAS ↔ DB: 최소 권한 원칙, 연결 암호화, 방화벽 계층 구성
4. 로드밸런싱
- WEB ↔ WAS: L7 Load Balancer (쿠키 스티키 / 무상태)
- WAS ↔ DB: DB Connection Pool 최적화
⚙️ 4. 통신 및 메시징 모델
🧾 클라이언트 요청 흐름 예시
[사용자] → HTTP 요청 →
[WEB] → 인증 헤더 파싱 →
[WAS] → 비즈니스 처리 →
[DB] → 쿼리 실행 →
[WAS] → 응답 포맷 구성 →
[WEB] → 사용자에게 HTML/JSON 전달
🔁 연결 방식
- WEB ↔ WAS: RESTful API, gRPC, WebSocket
- WAS ↔ DB: JDBC, ORM (Hibernate, Sequelize 등)
🧪 5. 분산 시스템 관점의 문제들
1. CAP 이론 적용
- DB 계층에서는 CAP 중 CP 또는 CA 선택 상황 발생
- Web/WAS 계층에서는 Availability 우선 설계가 많음
2. 장애 복원력 (Fault Tolerance)
- WEB: CDN fallback, health check 기반 Auto-recovery
- WAS: Circuit Breaker, Retry, Fallback pattern
- DB: Active-Standby 구성, Failover, Replication lag 대응
3. Consistency vs. Performance
- 캐시 계층의 도입 (Redis, Memcached)으로 성능 향상
- WAS가 DB 부하를 줄이기 위해 쓰기 지연 패턴을 사용할 수도 있음 (Eventual Consistency)
☁️ 6. 클라우드 환경에서의 3계층 아키텍처
| 계층 | 현대적 구현 예시 (AWS 기준) |
|---|---|
| WEB | Amazon CloudFront, Application Load Balancer, Nginx on EC2 |
| WAS | ECS Fargate, Lambda + API Gateway, EKS |
| DB | RDS (Aurora), DynamoDB, ElastiCache |
📦 IaC (Infrastructure as Code)
- Terraform, AWS CDK로 계층별 인프라 자동화
- 예:
module "was"→ ECS Cluster + Service,module "db"→ RDS + Subnet Group
🧠 APM 연동
- WEB: Page Load Metrics
- WAS: Application Tracing (NewRelic, Datadog, X-Ray)
- DB: 쿼리 슬로우 로그 분석
🧭 7. 마이크로서비스 아키텍처(MSA)로의 진화와 비교
| 항목 | 3계층 구조 | MSA |
|---|---|---|
| 통신 방식 | HTTP, JDBC | REST, gRPC, 메시지 큐 |
| 데이터 저장소 | 통합 RDB | 서비스별 DB 분리 (Polyglot Persistence) |
| 장점 | 관리 용이, 안정성 | 확장성, 독립 배포 |
| 단점 | 단일 장애점, 변경 전파 위험 | 복잡성 증가, 분산 트랜잭션 이슈 |
오늘날 3계층 구조는 ‘모놀리식 아키텍처’로 분류되지만, 초기 단계에서는 여전히 균형 잡힌 선택지입니다.
🧮 8. 실제 설계 시 체크리스트 (대학원 연구 or 실무기준)
| 항목 | 고려 내용 |
|---|---|
| 상태 관리 | WAS stateless 유지 여부 → 세션 저장소 분리 |
| 확장성 | 각 계층별 수평 확장 조건 (Auto Scaling 그룹) |
| 연결 병목 | WAS ↔ DB 간 커넥션 풀 사이즈, 타임아웃 |
| 보안 정책 | Subnet 분리, Security Group 구성, 최소 권한 접근 |
| CI/CD 구성 | 계층별 배포 자동화 및 롤백 정책 존재 여부 |
| 장애 전파 | 단일 계층 장애 시 복구/대체/우회 설계 유무 |
| 테스트 전략 | 각 계층별 단위 테스트, 통합 테스트 계획 수립 |
✅ 결론: 3계층 구조는 ‘단순함의 미학’이자 ‘확장성의 초석’
WEB-WAS-DB 3계층 구조는 단순히 세 계층으로 나누는 설계가 아니라,
복잡한 애플리케이션을 책임, 보안, 확장성, 유지보수성 관점에서 해체하고 구조화하는 전략입니다.
오늘날 서버리스나 MSA 환경이 대세라고 해도,
3계층 구조의 철학은 변하지 않습니다.
“시스템은 결국 나눌 수 있어야 관리할 수 있다.
그리고 관리 가능한 시스템만이 성장 가능한 시스템이다.”
📚 참고자료:
- Martin Fowler, Patterns of Enterprise Application Architecture
- AWS Well-Architected Framework
- Google Cloud Architecture Center
- ACM Queue: Monolith vs Microservices: It’s Not Either/Or
2930 Blog에서 더 알아보기
구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.