Spring Boot의 Controller–Service–Repository 구조와 4계층 아키텍처의 논리적 관계
소프트웨어 아키텍처에서 흔히 사용하는 표현은 Presentation, Application, Domain, Infrastructure로 구성된 4계층 구조이다. 반면, 일반적인 Spring Boot 프로젝트에서는 Controller, Service, Repository, Entity 중심으로 폴더가 구성된다.
두 구조는 용어가 다를 뿐, 역할과 책임 측면에서 논리적으로 동일한 계층을 나타낸다.
아래에서는 두 구조가 어떻게 매핑되며, 스프링 환경에서 실용적으로 왜 이런 형태가 자리 잡았는지를 논리적으로 설명한다.
1. 계층 개념의 정리: 역할 관점에서는 동일한 구조
아래는 DDD 또는 클린 아키텍처에서 정의하는 4계층과 Spring Boot의 폴더 구조를 역할 기반으로 매핑한 것이다.
| 개념적 계층 (논리적 아키텍처) | Spring Boot 구성 요소 | 책임 |
|---|---|---|
| Presentation Layer | Controller, DTO | 외부 요청 수신, 응답 생성 |
| Application Layer | Service | 유스케이스 실행, 비즈니스 로직 흐름 제어 |
| Domain Layer | Entity, Domain Logic | 핵심 규칙 정의, 비즈니스 모델 유지 |
| Infrastructure Layer | Repository, Config | 데이터 접근, 외부 시스템 연동 |
즉, Spring Boot의 구조는 계층형 아키텍처의 논리적 역할을 그대로 구현한 형태이며, 단지 기술적 관습에 따라 명칭이 차이날 뿐 개념적으로는 동일한 구조다.
2. 스프링 생태계에서 Controller–Service–Repository 구조가 사실상 표준이 된 이유
스프링 기반 프로젝트에서 논리 계층 명칭(Presentation, Domain 등)을 폴더 이름으로 사용하지 않는 데에는 다음과 같은 실용적 이유가 있다.
2.1 Spring Data JPA의 추상화로 인해 Repository 구현 코드가 거의 없음
Infrastructure 계층은 기술 요소(DB, Redis, 외부 시스템)의 구체 구현을 담는 곳이다.
그러나 Spring Data JPA 환경에서는 Repository 구현 클래스가 스프링에 의해 자동 생성되므로, 개발자가 인프라 구현을 작성할 일이 많지 않다.
이 결과 Infrastructure 라는 별도 폴더를 구성해도 실제로 들어갈 코드가 많지 않아 실효성이 떨어진다.
2.2 명칭 기반(Type-based) 폴더 구조가 개발자들에게 더 직관적
Spring 개발자는 오랜 기간 Controller/Service 관례에 익숙해져 있다.
따라서 “상품 조회 기능은 어디에 위치하는가?”라는 질문에 대해 controller 폴더를 탐색하는 방식이 훨씬 직관적이다.
이는 협업에서의 생산성을 높이고, 팀 간 공통 인지 부하를 줄이는 실질적 효과가 있다.
2.3 논리 계층과 물리 디렉토리를 반드시 일치시킬 필요가 없음
계층형 아키텍처에서 중요한 것은 책임의 구분과 의존성 방향이다.
폴더 이름을 Presentation·Domain처럼 변경하는 것은 물리적 표현을 바꾸는 것이지, 논리 구조 자체를 바꾸는 것이 아니다.
즉, 현재의 controller–service–repository–entity 구조만으로도 계층 구조는 완전히 충족된다.
3. 언제 논리적 계층 구조를 물리 구조로까지 분리할 필요가 있는가?
프로젝트가 초기 단계이거나 중·소규모 서비스에서는 계층 간 역할만 명확히 지키면 충분하다.
그러나 일부 경우에는 Presentation, Application, Domain, Infrastructure를 물리적으로도 분리하는 것이 필요하다.
3.1 외부 시스템 연동이 대규모로 증가한 경우
3.2 DB 교체(MySQL → MongoDB, DynamoDB 등)를 비즈니스 코드 수정 없이 수행해야 하는 경우
3.3 포트·어댑터 기반의 헥사고날 아키텍처가 요구되는 경우
이런 환경에서는 Infrastructure 계층이 커지므로 논리 계층을 명확히 독립시켜 유지보수성을 높일 필요가 있다.
즉, 프로젝트 복잡도가 물리 계층 분리를 정당화할 때 비로소 논리적 용어가 폴더 구조에 반영된다.
4. 결론
-
Spring Boot에서 사용하는 Controller–Service–Repository 구조는
논리적으로 4계층 아키텍처(Presentation, Application, Domain, Infrastructure)와 완전히 동일한 구조다. -
명칭의 차이는 기술 생태계 관습과 생산성을 고려한 결과로,
논리적 아키텍처의 책임 분리 원칙을 충실히 반영하고 있다. -
논리 계층을 물리 계층과 동일하게 분리해야 하는 상황은
대규모 시스템, 복잡한 외부 연동 환경, 기술 독립성이 강하게 요구되는 시스템으로 한정된다.
따라서 일반적인 Spring Boot 서비스에서는 현재의 Controller–Service–Repository–Entity 구조가
논리적 계층 구조를 실용적으로 구현한 정당한 형태라고 볼 수 있다.
