핵심 인사이트 (3줄 요약)
- 본질: 계층형 아키텍처 (Layered Architecture)는 시스템을 책임과 관심사(concern)에 따라 수직으로 분리된 계층으로 구성하여, 각 계층이 바로 아래 계층만 호출하고 상위 계층의 존재를 모르게 하는 설계 방식이다.
- 가치: 관심사 분리(Separation of Concerns)를 강제함으로써 하나의 계층 변경이 다른 계층에 미치는 영향을 최소화하고, 각 계층을 독립적으로 교체하거나 테스트할 수 있는 구조를 만든다.
- 판단 포인트: 계층형 아키텍처의 가장 큰 위험은 "아키텍처 싱크홀(Architecture Sinkhole) 안티패턴"으로, 비즈니스 로직 없이 단순히 데이터를 위아래로 전달만 하는 계층이 형성되어 불필요한 오버헤드가 발생하는 상황이다.
Ⅰ. 개요 및 필요성
계층형 아키텍처는 가장 오래되고 널리 사용되는 아키텍처 스타일이다. MVC (Model-View-Controller) 패턴, Java EE (Enterprise Edition) 플랫폼, Spring Framework 기반 웹 애플리케이션이 모두 이 구조를 기반으로 한다. 1990년대 이후 엔터프라이즈 애플리케이션 개발의 사실상 표준(de facto standard)으로 자리 잡았다.
계층형 아키텍처가 필요한 이유는 소프트웨어의 서로 다른 관심사를 분리하여 변경의 파급을 제한하기 위해서다. UI가 바뀐다고 데이터베이스 코드가 바뀌면 안 되고, 비즈니스 규칙이 변경된다고 화면이 재설계되어서는 안 된다. 계층 경계가 이 분리를 보장한다.
┌─────────────────────────────────────────────────────────────┐
│ 4계층 아키텍처 구조 (전형적 웹 애플리케이션) │
├─────────────────────────────────────────────────────────────┤
│ ┌──────────────────────────────────────────┐ │
│ │ 프레젠테이션 계층 (Presentation Layer) │ │
│ │ Controller, View, REST API 엔드포인트 │ │
│ └──────────────┬───────────────────────────┘ │
│ │ (단방향 의존) │
│ ┌──────────────▼───────────────────────────┐ │
│ │ 비즈니스 로직 계층 (Business Layer) │ │
│ │ Service, Domain Object, Use Case │ │
│ └──────────────┬───────────────────────────┘ │
│ │ │
│ ┌──────────────▼───────────────────────────┐ │
│ │ 퍼시스턴스 계층 (Persistence Layer) │ │
│ │ Repository, DAO, ORM Mapper │ │
│ └──────────────┬───────────────────────────┘ │
│ │ │
│ ┌──────────────▼───────────────────────────┐ │
│ │ 데이터베이스 계층 (Database Layer) │ │
│ │ RDBMS, NoSQL, 파일 시스템 │ │
│ └──────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
각 계층은 위에서 아래로만 의존하며, 계층 격리(Layer Isolation)를 통해 각 계층을 독립적으로 변경하거나 교체할 수 있다. 예를 들어 ORM(Object-Relational Mapping)을 Hibernate에서 MyBatis로 교체해도 비즈니스 로직 계층은 영향을 받지 않는다.
- 📢 섹션 요약 비유: 고층 빌딩은 1층이 주차장, 2~10층이 사무실, 11~20층이 주거, 21층이 식당으로 나뉜다. 주차장 구조를 바꿔도 위 층 생활에는 영향이 없다. 계층별로 역할이 분리되어 있기 때문이다.
Ⅱ. 아키텍처 및 핵심 원리
계층형 아키텍처의 핵심 규칙은 ① 단방향 의존성(계층 위에서 아래로만), ② 계층 격리(인접한 계층만 호출), ③ 명확한 계층별 역할 분담이다. 일부 구현에서는 열린 계층(Open Layer)을 허용하여 비인접 계층을 직접 호출할 수 있지만, 이는 계층 격리를 약화시키므로 명시적 설계 결정이 필요하다.
| 항목 | 설명 | 포인트 |
|---|---|---|
| 프레젠테이션 | 사용자 인터페이스·API 처리 / Controller, View, DTO | 비즈니스 계층 |
| 비즈니스 | 업무 규칙·유스케이스 처리 / Service, Domain Object | 퍼시스턴스 계층 |
| 퍼시스턴스 | 데이터 영속성 처리 / Repository, DAO | 데이터베이스 계층 |
| 데이터베이스 | 실제 데이터 저장 / DB, 파일 시스템 | 없음 |
┌─────────────────────────────────────────────────────────────┐
│ 아키텍처 싱크홀(Sinkhole) 안티패턴 탐지 │
├─────────────────────────────────────────────────────────────┤
│ 정상 흐름: 각 계층이 실질적 처리를 수행 │
│ Controller → Service(비즈니스 로직 수행) → Repository │
│ │
│ 싱크홀 흐름: 로직 없이 단순 전달만 │
│ Controller → Service(그냥 Repository 호출만) │
│ → Repository(그냥 DB 호출)│
│ │
│ 20% 이상이 싱크홀이면 계층 통합 검토 필요 │
└─────────────────────────────────────────────────────────────┘
성능 관점에서 계층형 아키텍처는 각 계층 간 데이터 변환(DTO ↔ Domain ↔ Entity)에서 불필요한 오버헤드가 발생할 수 있다. 특히 간단한 CRUD(Create, Read, Update, Delete) 작업에서 5개 계층을 거치는 것은 과도한 복잡성이 될 수 있다.
- 📢 섹션 요약 비유: 공장 생산 라인에서 각 공정(계층)은 이전 공정이 완성한 반제품만 받아서 자기 작업만 한다. 페인트 도장 공정이 용접 방법을 알 필요가 없는 것처럼, 각 계층은 바로 아래 계층의 결과물만 알면 된다.
Ⅲ. 비교 및 연결
계층형 아키텍처와 마이크로서비스 아키텍처(MSA)는 자주 비교되며, 두 스타일의 차이는 분리 축이 다르다는 점이다. 계층형은 기술적 관심사(presentation·business·data)로 수직 분리하고, MSA는 비즈니스 기능(주문·결제·배송)으로 수평 분리한다.
| 비교 축 | A | B |
|---|---|---|
| 분리 기준 | 기술적 관심사 (횡적 계층) | 비즈니스 도메인 (종적 서비스) |
| 배포 단위 | 전체 시스템 함께 | 서비스별 독립 |
| 확장 방식 | 전체 수직 확장 | 서비스별 수평 확장 |
| 적합 규모 | 소·중규모, 단일 팀 | 대규모, 다팀 |
| 운영 복잡도 | 낮음 | 높음 |
계층형 아키텍처는 헥사고날 아키텍처, 클린 아키텍처, 어니언 아키텍처와의 비교에서 "의존성 방향"이 핵심 차이다. 계층형에서는 비즈니스 계층이 퍼시스턴스 계층(인프라)에 의존하지만, 헥사고날·클린·어니언에서는 의존성이 역전되어 인프라가 도메인에 의존한다.
- 📢 섹션 요약 비유: 계층형 아키텍처는 회사의 부서 구조처럼 기술 기능별로 조직(개발팀·디자인팀·DB팀)을 나눈 것이고, MSA는 비즈니스 결과물별로 팀(주문팀·결제팀·배송팀)을 나눈 것이다.
Ⅳ. 실무 적용 및 기술사 판단
감리 현장에서 계층형 아키텍처 점검의 핵심은 ① 계층 경계 침범 여부, ② 아키텍처 싱크홀 비율, ③ 계층 간 의존성 방향 확인이다. Spring 기반 프로젝트에서 @Controller가 Repository를 직접 주입받아 사용하면 계층 경계 침범이다.
판단 체크리스트
- 각 계층의 역할과 경계가 명확히 정의되고 팀 전체가 공유하는가?
- 상위 계층이 하위 계층을 건너뛰는 계층 침범(Layer Skipping)이 없는가?
- 아키텍처 싱크홀(단순 위임 계층) 비율이 20% 미만인가?
- 퍼시스턴스 계층의 기술(ORM 종류)이 비즈니스 계층 코드에 노출되어 있지 않은가?
- 계층 간 데이터 교환에 DTO를 사용하여 계층 간 구조 변화가 격리되는가?
- 📢 섹션 요약 비유: 법원 시스템에서 검사는 재판관에게 직접 판결을 요청하고, 재판관은 집행관에게 집행을 지시한다. 검사가 집행관에게 직접 지시하거나, 집행관이 재판관을 건너뛰면 법 질서가 무너진다.
Ⅴ. 기대효과 및 결론
계층형 아키텍처는 명확한 구조적 이해와 팀 온보딩 용이성으로 중소규모 시스템에서 검증된 선택이다. 전통적인 엔터프라이즈 프레임워크(Spring, .NET)의 기본 구조와 일치하므로 생태계 지원이 풍부하다. 감리·인수 테스트에서도 계층 단위로 산출물(소스 코드, 테스트, 배포 패키지)을 검증하기 용이하다.
한계는 확장성과 모놀리식(monolithic) 배포 단위다. 트래픽이 급증하면 특정 계층만 독립 확장이 불가능하고 전체를 스케일 아웃해야 한다. 비즈니스 로직이 서비스 클래스에 몰리는 "뚱뚱한 서비스(Fat Service)" 안티패턴도 계층형에서 자주 발생한다.
미래 방향으로는 ① 계층형과 MSA를 결합한 모듈형 모놀리스(Modular Monolith), ② 계층형 아키텍처 내 CQRS(Command Query Responsibility Segregation) 패턴 적용, ③ 헥사고날 아키텍처로의 점진적 전환이 현실적 경로로 각광받고 있다.
계층형 아키텍처는 "관심사를 분리하는 가장 단순하고 직관적인 방법"으로 기억하되, 시스템이 성장하면서 그 한계를 인식하고 대안을 준비하는 것이 성숙한 아키텍처 판단이다.
- 📢 섹션 요약 비유: 초등학교 교실은 국어, 수학, 체육을 한 담임이 가르쳐도 충분하다(계층형). 하지만 대학교는 전공별 교수가 독립적으로 강의해야 한다(MSA). 학교 규모에 맞는 구조가 최선이다.
📌 관련 개념 맵
[관심사 분리] → [계층형 아키텍처] → [Spring MVC] → [계층형 한계 인식] → [헥사고날/클린 아키텍처] → [MSA]
| 개념 | 연결 포인트 |
|---|---|
| MVC 패턴 | 계층형 아키텍처의 3계층 구조를 웹에 적용한 패턴 |
| DIP (의존성 역전) | 헥사고날·클린 아키텍처가 계층형의 의존성 방향을 개선하는 원칙 |
| 아키텍처 싱크홀 | 계층형 아키텍처의 대표적 안티패턴 |
| 모듈형 모놀리스 | 계층형과 MSA의 절충 형태 |
📈 관련 키워드 및 발전 흐름도
[임기응변 스파게티 코드] → [계층형 아키텍처 정착] → [Java EE·Spring 표준화] → [계층형 한계(확장성·배포)] → [헥사고날·클린 아키텍처] → [MSA·모듈형 모놀리스]
👶 어린이를 위한 3줄 비유 설명
- 케이크는 스폰지, 크림, 딸기 층으로 나뉘어 있고, 각 층은 자기 역할만 해요.
- 딸기(프레젠테이션)가 바뀌어도 스폰지(비즈니스)와 크림(데이터)은 그대로예요.
- 계층형 아키텍처는 이렇게 역할이 다른 것들을 층층이 쌓아서 깔끔하게 만드는 방법이에요!