[버티] 프로젝트 구조 설계 고민과 선택
버티 프로젝트 구조 설계 고민과 선택
프로젝트를 처음 시작할 때 가장 고민했던 부분 중 하나는 전체 구조를 어떻게 잡을 것인가였습니다. 단순한 CRUD를 넘어서 소셜 로그인, 커뮤니티, AI 기반 정착 리포트 등 다양한 기능을 포함할 예정이었기 때문에, 기능이 늘어나더라도 유지보수가 쉽고, 각 도메인이 명확하게 분리되도록 설계하고 싶었습니다.
처음엔 기능 중심으로 폴더를 나눌까도 생각했지만, 여러 기능이 얽혀 있을 때 책임이 명확하지 않고 코드가 뒤섞일 우려가 있었습니다. 그래서 고민 끝에 도메인 주도 설계(Domain-Driven Design, DDD) 와 MVC 구조, 그리고 레이어드 아키텍처(Layered Architecture) 를 조합한 형태로 프로젝트 구조를 설계하기로 했습니다.
💡 도메인 주도 설계란?
DDD는 비즈니스의 복잡한 요구사항을 도메인 중심으로 풀어가는 소프트웨어 설계 방법입니다. 코드 구조가 실제 도메인 모델과 맞닿아 있어 유지보수가 용이하고, 비즈니스 개념을 중심으로 기능을 구현할 수 있도록 도와줍니다. 핵심은 ‘도메인을 기준으로 책임을 분리’하는 것입니다.
또한 레이어드 아키텍처는 기능을 계층별로 나누어 역할을 분리함으로써 각 계층 간의 결합도를 낮추고 테스트와 유지보수를 용이하게 합니다. 대표적으로는 Controller → Service → Repository 계층 구조를 따릅니다.
최종적으로 다음과 같은 구조를 구성했습니다:
org.example.burtyserver/
├── domain/ # 도메인 중심 패키지
│ ├── auth/ # 인증 관련 기능
│ │ ├── controller/ # API 컨트롤러 (Presentation Layer)
│ │ └── dto/ # 데이터 전송 객체
│ │
│ └── user/ # 사용자 관련 기능
│ ├── entity/ # 엔티티 클래스 (Domain Layer)
│ ├── repository/ # 데이터 접근 계층 (Persistence Layer)
│ └── service/ # 비즈니스 로직 (Application Layer)
│
├── global/ # 공통/전역 기능
│ ├── config/ # 설정 클래스
│ ├── exception/ # 예외 처리
│ └── security/ # 보안 관련 클래스
│ ├── jwt/ # JWT 관련 클래스
│ ├── oauth2/ # OAuth2 관련 클래스
│ └── dto/ # 보안 관련 DTO
│
└── BurtyServerApplication.java # 애플리케이션 진입점
-> 아직 개발중!
이 구조는 기능별 분리보다 도메인별 분리를 우선시했으며, 각 도메인이 자신의 책임과 역할에 따라 나뉘도록 구성했습니다. 공통 설정이나 보안 로직처럼 여러 도메인에서 공유되는 요소들은 global이라는 전역 패키지에 따로 관리하여 관심사 분리를 명확히 했습니다.
실제로 프로젝트를 진행하면서 새로운 기능이 추가될 때마다 이 구조 덕분에 확장이 훨씬 수월했습니다. 예를 들어 AI 정착 리포트 기능을 추가할 때도 settlement라는 도메인을 추가해 기존 구조에 영향을 주지 않고도 자연스럽게 통합할 수 있었습니다.
도메인 주도 설계를 기반으로 구조를 잡는 과정은 단순히 코드를 예쁘게 나누는 것을 넘어서, 기능과 비즈니스 로직의 맥락(Context)을 코드 레벨에서 표현하는 데 큰 도움이 되었습니다. 또한 레이어드 아키텍처를 통해 각 계층의 역할이 명확해져 협업 시 작업 분담이나 코드 리뷰도 훨씬 효율적으로 이루어졌습니다.
이 경험은 제가 프로젝트를 단순히 “만드는 것”을 넘어서, “운영 가능한 구조로 설계한다”는 감각을 키우는 데 결정적인 계기가 되었습니다.
