레이어드 아키텍처(Layered Architecture) 완벽 이해 – 웹 애플리케이션 구조의 기본
레이어드 아키텍처는 가장 널리 사용되는 애플리케이션 설계 구조입니다. Spring, Java, .NET, Django 등 거의 모든 프레임워크에서 기본 구조로 채택되며, 유지보수성과 확장성에서 큰 장점을 가집니다. 이 글에서는 레이어드 아키텍처의 구성, 계층 간 책임, 실무 적용 전략까지 모두 정리합니다.
1. 레이어드 아키텍처란?
레이어드 아키텍처는 시스템을 역할에 따라 계층(Layer)으로 분리하여 구성하는 설계 방식입니다. 각 계층은 자신보다 하위 계층만 의존하며, 관심사 분리(SoC: Separation of Concerns)를 철저히 지킵니다.
대표적인 계층 구성
- Presentation Layer: 사용자 요청/응답 처리 (Controller)
- Service Layer: 비즈니스 로직 처리 (Service)
- Persistence Layer: 데이터 접근 처리 (Repository, DAO)
- Domain Layer: 핵심 모델, 엔티티, 밸류 객체 등
2. 계층별 책임 설명
📌 Controller (프레젠테이션 계층)
- HTTP 요청/응답 처리
- 입력 검증(Validation)
- Service 호출 후 결과 반환 (DTO 등)
📌 Service (비즈니스 계층)
- 도메인 로직 수행
- 트랜잭션 처리
- Repository 조합 및 비즈니스 흐름 관리
📌 Repository / DAO (데이터 접근 계층)
- DB와 직접 통신 (JPA, MyBatis 등)
- SQL 또는 쿼리 메서드 정의
📌 Domain (모델 계층)
- 핵심 Entity, VO(Value Object) 정의
- 비즈니스 상태와 규칙 포함
- Service에 의해 사용됨
3. 계층 간 의존성 흐름
아래 방향으로만 의존합니다 (단방향):
Controller → Service → Repository → DB
↑ ↑
DTO/VO Entity
4. 실무 프로젝트 예시 구조 (Spring 기준)
src/main/java/com/example/
├── controller/
├── service/
├── repository/
├── domain/
└── dto/
controller → service → repository 흐름이 명확하며, dto와 domain은 양방향으로 재사용됩니다.
5. 레이어드 아키텍처의 장점
- 관심사 분리로 코드 역할 명확
- 유지보수성, 테스트 용이성 향상
- 개발자 역할 분담이 쉬움
- 단위 테스트 작성이 쉬움
6. 단점 및 보완점
- 단순한 CRUD에도 계층이 많아질 수 있음
- 계층 간 의존성이 커질수록 테스트 어려움 →
@Transactional남용 주의 - 복잡한 도메인에는 DDD, 클린 아키텍처로 보완 필요
7. 결론
레이어드 아키텍처는 모든 백엔드 개발자가 반드시 이해하고 실무에서 구현할 수 있어야 하는 기본 설계 구조입니다. 프로젝트의 복잡도에 따라 계층 수를 조절하고, 코드 책임을 명확히 분리함으로써 유지보수성과 확장성을 확보할 수 있습니다.
