소프트웨어 아키텍처 시리즈 3화 – 레이어드 아키텍처의 구조와 실제 적용 방식
레이어드 아키텍처는 가장 널리 사용되는 소프트웨어 구조 중 하나입니다. 그 기본 개념부터 실제 프로젝트에서 어떻게 구현되고, 어떤 한계를 갖는지까지 실무 중심으로 정리해봅니다.
레이어드 아키텍처란 무엇인가?
레이어드 아키텍처(Layered Architecture)는 소프트웨어를 **기능적으로 구분된 계층(Layer)**으로 나누어 각 계층이 자신의 역할만을 책임지는 구조입니다. 아래와 같은 전형적인 계층 구성이 자주 등장합니다:
- Presentation Layer (프레젠테이션, UI 계층)
사용자 인터페이스 또는 API 엔드포인트 - Application Layer (애플리케이션 계층)
비즈니스 흐름 제어 및 유스케이스 처리 - Domain Layer (도메인 계층)
비즈니스 규칙, 핵심 로직 (종종 Application과 합쳐지기도 함) - Infrastructure Layer (인프라 계층)
데이터베이스, 외부 시스템, 네트워크 등 기술 의존성 처리
이 네 계층은 가장 보편적인 구성입니다. 프로젝트 규모와 철학에 따라 다르게 나뉘거나 병합되기도 합니다.
계층 간 의존 관계
레이어드 아키텍처는 일반적으로 하위 계층에서 상위 계층으로의 의존은 금지되고, 상위 계층이 하위 계층을 호출하는 구조입니다.
예:
- Controller → Service → Repository
- UI → UseCase → DBAdapter
이런 구조는 **기능 간 관심사 분리(Separation of Concerns)**를 통해 유지보수성과 테스트 용이성을 확보하는 데 효과적입니다.
실무 적용 사례: Spring 기반 백엔드 시스템
Java/Spring 기반의 대다수 기업 프로젝트에서는 다음과 같이 구현됩니다:
- Controller (UI/REST) → 사용자 요청을 받고 validation 수행
- Service → 비즈니스 흐름 구현, 트랜잭션 관리
- Repository → JPA, MyBatis 등을 통한 DB 접근
- Entity/Model → 비즈니스 객체 또는 DTO
또한, 단위 테스트에서도 계층별로 mocking이 가능해, 테스트 격리성과 생산성을 높일 수 있습니다.
장점: 지금도 널리 쓰이는 이유
- 구조가 명확하고, 학습 곡선이 낮음
→ 팀 내 커뮤니케이션 비용이 줄어듭니다. - 단위 테스트, 기능 분리, 리팩토링에 유리
→ 각 계층의 책임이 뚜렷해지기 때문입니다. - 기존 프레임워크(Sprint, .NET 등)와 잘 맞음
→ 주요 프레임워크들이 기본적으로 레이어 구조를 전제로 설계됨
단점과 한계: 모든 상황에 적합하지 않다
- 계층 간 호출 경로가 고정되어 있음
→ 예외 흐름이나 유연한 분기 처리가 어려움 - 모든 요청이 모든 계층을 거쳐야 하는 과도한 오버헤드
→ 단순한 CRUD조차 4~5개의 파일을 건드려야 할 수 있음 - 도메인 중심 설계(DDD)와는 자연스럽게 맞지 않음
→ DDD는 도메인 객체가 중심이지만, 레이어드 구조는 흐름 중심으로 흘러가기 때문
전환 고려 시점: 언제 다른 아키텍처를 고민해야 할까?
- 복잡한 도메인 로직이 비즈니스 로직보다 중요해졌을 때
→ 헥사고날, 클린 아키텍처로의 전환 고려 - 동기 호출에서 비동기 이벤트 기반으로 전환할 때
→ Event-driven Architecture(EPA) 등으로 확장 - MSA로의 분산 설계가 필요할 때
→ 계층 구조보다 각 서비스의 독립성과 경계 설정이 중요해짐
모르면 모른다고 말해야 할 부분
"레이어드 아키텍처는 확실히 성능이 낮은가요?"라는 질문에 대한 확답은 어렵습니다.
레이어드 구조 자체가 성능 병목의 원인이 되는 경우는 거의 없습니다. 병목은 일반적으로 DB 쿼리, IO, 외부 API 호출 등 기술적인 지점에서 발생합니다. 따라서 구조 자체보다는 어떻게 설계하고 구현하느냐가 더 큰 영향을 미칩니다.
마무리하며
레이어드 아키텍처는 지금도 수많은 프로젝트에서 실전적으로 사용되는 안정적인 선택지입니다. 하지만 그 한계를 명확히 인식하고, 적절한 맥락에서 다른 아키텍처로의 전환을 고민할 줄 아는 것도 아키텍트의 중요한 역할입니다.
이후 시리즈에서는 클린 아키텍처, 헥사고날 아키텍처, 도메인 중심 설계 등 다양한 구조를 실제 상황에 맞춰 비교하면서 점점 더 깊이 있는 설계를 다뤄가겠습니다.