Spring Boot 프로젝트 구조 설계 가이드 (MVC, Layered, Domain 기반, Hexagonal)

반응형

Spring Boot로 웹 애플리케이션을 개발할 때 어떤 프로젝트 구조를 선택해야 할지 고민되시나요?
MVC, Layered, Domain 기반, Hexagonal 구조 등 대표적인 설계 방식들의 특징과 장단점을 비교하고, 개인 학습용 프로젝트에 적합한 구조를 추천합니다.

---

들어가며

지난 글에서는 IntelliJ IDEA 설치부터 Spring Boot를 위한 기본 설정까지 소개했습니다. 이번 글에서는 Spring Boot 프로젝트를 생성할 때 적용할 프로젝트 구조에 대해 소개합니다.

IntelliJ IDEA Community Edition 설치 및 Kotlin + Spring Boot 기본 설정 가이드 (2025 최신)

아직 개발이 익숙하지 않은 분들은 Spring Boot로 프로젝트를 시작할 때, "패키지를 어떻게 나누지?", "Controller랑 Service는 어디에 둬야 하지?" 같은 고민을 합니다. 처음이니까 가장 간단한 구조로 만들 수도 있고, 본인에게 익숙한 구조로 만들 수도 있습니다.
개발 업무를 하는 분들도 실무에서 프로젝트 생성 경험이 별로 없다면, 프로젝트 생성 시 프로젝트 구조에 대해 한번쯤 고민해보게 됩니다. 왜냐하면 프로젝트 구조는 단순히 폴더 정리 방식이 아니라, 개발 생산성과 유지보수성에 직접적인 영향을 주는 설계의 핵심 요소이기 때문입니다.
별다른 고민 없이 구조를 정했다가 프로젝트 규모가 점차 커지고 복잡해지면서 구조 변경의 필요성을 느꼈을 때는 이미 구조를 바꾸기 어려운 상황에 처할 수 있습니다.

이번 글에서는 실무에서 많이 사용되는 대표적인 프로젝트 구조들을 정리하고, 초보자 및 개인 학습용 프로젝트에 가장 적합한 구조를 추천하겠습니다.

1. MVC (Model-View-Controller) 구조

개요

MVC 구조는 가장 기본적인 웹 애플리케이션 구조입니다. Front 영역까지 포함하는 프로젝트라면 아마 가장 익숙한 구조일 것입니다.

• Model: 데이터 및 비즈니스 로직
• View: 사용자에게 보여지는 화면 (HTML, JSON 등)
• Controller: 요청을 받아서 Model과 View를 연결

Spring Boot에서는 다음과 같이 구성됩니다:

com.example.demo
 ├── controller
 ├── model
 └── view (또는 templates)

장점

• 직관적이고 구조가 단순해 초보자에게 익숙함
• 빠르게 프로토타입 개발 가능
• Spring MVC의 기본 패턴과 일치

단점

• 프로젝트 규모가 커질수록 역할이 모호해짐
• Model에 비즈니스 로직과 데이터 로직이 섞이기 쉬움
• 유지보수성 낮음

추천 사용처: 소규모 웹 앱, REST API 실습용 프로젝트

2. Layered Architecture (계층형 구조)

개요

MVC보다 한 단계 발전된, 실무에서 가장 널리 쓰이는 구조입니다. Back-end 도메인에서 가장 기본적인 구조입니다.

• Controller: HTTP 요청/응답 처리
• Service: 비즈니스 로직 담당
• Repository: 데이터 접근 (DB, JPA 등)

com.example.demo
 ├── controller
 ├── service
 ├── repository
 └── domain (또는 entity)

장점

• 책임이 명확하게 분리되어 유지보수 용이
• 테스트 코드 작성이 용이
• 규모 확장에 유리

단점

• 단순 CRUD 프로젝트에서는 계층이 과도할 수 있음 (계층은 많으나 Controller나 Service에서 역할이 단순 전달밖에 없는 상황 발생)
• 비즈니스 로직이 복잡해지면 service 계층이 비대해짐

추천 사용처: 일반적인 REST API, 실무형 학습 프로젝트

3. Domain 기반 (패키지 by Domain) 구조

개요

계층별로 나누는 대신, 업무 도메인(기능 단위) 별로 패키지를 분리하는 방식입니다.

com.example.demo
 ├── user
 │    ├── UserController.kt
 │    ├── UserService.kt
 │    ├── UserRepository.kt
 │    └── User.kt
 ├── order
 │    ├── OrderController.kt
 │    ├── OrderService.kt
 │    ├── OrderRepository.kt
 │    └── Order.kt
 └── common

장점

• 기능별로 코드가 모여 있어서 가독성과 탐색성 향상
• 새로운 기능 추가 시 관련 코드만 해당 도메인에 추가하면 됨
• 팀 단위 개발 시 충돌이 적음

단점

• 중복 코드가 생기기 쉬움
• 공통 기능 관리가 어려움
• 초보자에게는 구조가 다소 생소

추천 사용처: 중~대규모 프로젝트, 도메인 주도 설계(DDD) 연습용

4. Hexagonal Architecture

개요

비즈니스 로직과 외부 의존성을 철저히 분리하는 DDD(Domain-Driven Development) 스타일 구조입니다.

com.example.demo
 ├── domain
 │    ├── model
 │    └── service
 ├── application
 │    └── usecase
 ├── infrastructure
 │    ├── persistence
 │    └── api
 └── interface
      └── controller

장점

• 테스트 가능성과 유지보수성이 뛰어남
• 외부 시스템(DB, API, UI)에 독립적
• 대규모, 장기 프로젝트에 적합

단점

• 설계 난이도가 높음
• 초보자에게는 구조가 복잡하고 이해하기 어려움
• 소규모 프로젝트에서는 과도한 설계

추천 사용처: 복잡한 도메인 로직을 가진 대규모 시스템

5. 구조별 비교 요약

구조	주요 특징	장점	단점	추천 대상
MVC	전통적인 3계층	단순하고 빠름	확장성 낮음	입문자, 간단한 앱
Layered	실무 표준 구조	유지보수 용이, 명확한 역할	다소 반복적	일반적인 서비스
Domain 기반	기능 단위로 분리	가독성·확장성 우수	공통 로직 관리 어려움	도메인 중심 설계
Hexagonal	의존성 역전, 완전한 분리	테스트와 유지보수 우수	복잡, 난이도 높음	대규모 시스템

6. 개인 학습용으로 추천하는 구조

추천: Layered (계층형) 구조

개인 학습이나 소규모 프로젝트에서는 Controller → Service → Repository → Domain 구조가 가장 실용적이고 관리하기 쉬운 방식입니다. (Front 영역까지 포함하고자 한다면 MVC를 추천합니다.)

이 구조는

• Spring Boot 공식 가이드와 일치하고,
• Kotlin과 잘 어울리며,
• 실제 기업 실무에서도 동일하게 적용됩니다.

프로젝트를 조금 더 성장시키고 싶다면,

• 이후 단계에서 domain 단위로 분리하거나
• ports/adapters 패턴 일부를 도입하면 자연스럽게 확장할 수 있습니다.

마치며

프로젝트 구조는 정답이 있는 게 아니라, 목적과 규모에 따라 달라지는 선택입니다. 프로젝트 구조뿐만 아니라 모든 요소들은 주어진 상황에 따라 각각의 선택이 trade-off를 갖습니다.
하지만 개인 학습용으로는 Layered 구조가 이해하기 쉽고, 실무로 넘어갈 때도 자연스럽게 적응할 수 있습니다.

다음 글에서는 이 구조를 기반으로 실제 Kotlin + Spring Boot 프로젝트 패키지 구성 예시와 코드 작성 패턴을 단계별로 소개하겠습니다.

Kotlin + Spring Boot 프로젝트 기본 구조(Layered Architecture)와 예제 코드