Spring 프로젝트 구조

wjd15sheep·2025년 6월 12일

Spring boot

Spring Boot

목록 보기

12/19

Spring 프로젝트를 시작할 때마다 가장 먼저 부딪히는 고민 중 하나는 바로 “파일 구조를 어떻게 나눌 것인가?”입니다.

MVC 기반이라는 전통적인 구조가 있지만, 프로젝트의 규모나 목적에 따라 전혀 다른 방식이 더 적합할 수도 있습니다.

이번 글에서는 레이어 단위 분리와 도메인 단위 분리라는 두 가지 주요 구조를 비교하고, 각각의 장단점과 추천 기준까지 정리해보겠습니다.

🧱 Spring의 기본 구조: MVC란?

Spring은 웹 애플리케이션 개발을 위한 프레임워크로, 전통적으로 MVC 패턴을 기반으로 합니다.

Model: 비즈니스 로직과 데이터
View: 사용자 인터페이스
Controller: 요청 처리 및 흐름 제어

이 MVC 패턴을 실제 코드 구조에 어떻게 반영하느냐에 따라 프로젝트의 전체적인 유지보수성과 협업 난이도가 달라집니다.

그래서 등장한 두 가지 주요 접근 방식이 있습니다.
바로 레이어 단위 분리와 도메인 단위 분리입니다.
지금부터 이 두 구조를 비교하며 어떤 프로젝트에 어떤 구조가 적합한지 살펴보겠습니다.

레이어 단위 분리 (Layer-Based Structure)

레이어 단위 분리(Layer-Based Structure)는 역할(Role) 중심으로 프로젝트의 디렉터리 구조를 나누는 방식입니다.
즉, 기능(비즈니스 도메인)이 아니라 역할에 따라 Controller, Service, Repository 등으로 나누는 전통적인 구조입니다.

📌 구조 예시

src/
└── main/
    └── java/
        └── com/example/project/
            ├── controller/
            ├── service/
            ├── repository/
            ├── entity/
            └── dto/

✅ 장점

항목	설명
단순하고 직관적	초보자도 이해하기 쉽고, 전통적인 MVC와 유사
기능 책임 분리가 명확	컨트롤러는 요청 처리, 서비스는 비즈니스 로직, 리포지토리는 DB 접근 등 역할 구분 명확
작은 프로젝트에 적합	규모가 작으면 파일 간 의존이 적고 관리가 용이함

⚠️ 단점

항목	설명
도메인 관련 코드가 흩어짐	Product 관련 코드가 여러 폴더(controller, service, repo)에 흩어져서 응집도가 낮음
기능 추가 시 변경 범위 큼	새로운 기능을 추가하면 여러 레이어를 수시로 넘나들며 작업해야 함
도메인 중심 설계(Domain-Driven Design)에 부적합	도메인을 중심으로 설계할 수 없음. 비즈니스 요구사항 반영이 어려움

도메인 단위 분리 (Domain-Based Structure, aka Feature-Based)

도메인 단위 분리(Domain-Based Structure, 또는 Feature-Based Structure)는 비즈니스 기능(도메인) 을 중심으로 프로젝트 디렉터리를 구성하는 방식입니다.
예를 들어, user, product, order 등 각 도메인마다 controller, service, repository, entity, dto 등의 파일을 하위에 배치합니다.

✅ 이 구조는 관련된 코드들이 한 곳에 모여 있어 응집도가 높고 유지보수나 확장에 유리하며, 도메인 주도 설계(DDD) 에 적합합니다.

📌 구조 예시

src/
└── main/
    └── java/
        └── com/example/project/
            ├── user/
            │   ├── controller/
            │   ├── service/
            │   ├── repository/
            │   ├── entity/
            │   └── dto/
            ├── product/
            └── order/

✅ 장점

항목	설명
응집도 높음	하나의 도메인(예: product)에 관련된 코드가 한 폴더에 집중되어 있음
기능 확장·유지보수 용이	기능 추가 시 해당 도메인 폴더 내에서 대부분의 작업 가능
도메인 주도 설계(Domain-Driven Design)에 적합	비즈니스 로직이 도메인 중심으로 설계되므로 확장성 및 유연성 높음
팀 단위 협업에 강함	도메인 별 담당자 나눌 수 있어 작업 충돌 감소

⚠️ 단점

항목	설명
초기에 구조 잡기 복잡	폴더 구조 설계에 고민이 많고, 도메인 정의가 선행되어야 함
도메인 간 의존 복잡도 증가 가능	도메인 간 호출이 많아지면 의존성과 순환 참조 문제가 발생할 수 있음
중복 가능성	각 도메인마다 유사한 구조를 반복적으로 생성할 가능성 있음 (ex. BaseEntity, DTO 등)

🧩 정리 비교표

항목	레이어 단위	도메인 단위
구조 기준	역할 (Controller, Service 등)	기능/도메인 (User, Product 등)
초기 진입 장벽	낮음	다소 높음
응집도	낮음	높음
유지보수	대형화 시 불편	확장성 뛰어남
비즈니스 로직 반영	어려움	용이
협업 효율성	충돌 가능 ↑	도메인별 분업 가능

📌 추천 기준

상황	추천 구조
간단한 개인 프로젝트	레이어 기반
장기 유지보수가 필요한 서비스	도메인 기반
팀 단위 협업 진행	도메인 기반
JPA와 DDD를 함께 활용할 예정	도메인 기반
Django/Express 등 기능 중심 구조에 익숙한 경우	도메인 기반