멀티 모듈 방식이란?

항상 단일 모듈(싱글 모듈) 방식으로만 프로젝트를 해오다가, 이번 사이드 프로젝트 팀에 합류하면서 처음으로 멀티 모듈 구조로 개발을 경험했다.

처음엔 구조를 파악하는 게 쉽지 않았지만, 직접 써보고 나니 왜 규모가 커질수록 멀티 모듈이나 MSA 구조로 리팩토링하는 게 좋은지 확실히 느낄 수 있었다. 이번 글에서는 MSA 멀티 모듈 구조가 무엇이고, 실제로 어떻게 적용했는지, 그리고 느낀 점을 정리해본다.

멀티 모듈(Multi Module) 방식이란?

멀티 모듈 방식은 하나의 프로젝트를 여러 개의 독립적인 모듈로 나누어 개발하는 구조다. 기존의 단일 모듈 구조에서는 모든 소스코드와 리소스가 한 프로젝트 안에 다 들어가 있었지만, 멀티 모듈에서는 기능이나 역할별로 모듈을 분리해서 각각 독립적으로 관리할 수 있다.

멀티 모듈 구조의 대표적 장점

• 코드 중복 최소화
  공통으로 사용하는 코드(예: 엔티티, DTO, 유틸리티 등)를 별도의 공통 모듈로 분리해 여러 모듈에서 재사용할 수 있다.
  예를 들어, Member 도메인에 변경이 생기면 공통 모듈만 수정하면 되고, 여러 프로젝트를 일일이 열어서 복붙할 필요가 없다.
• 독립적인 개발 및 배포
  각 모듈은 독립적으로 개발, 빌드, 테스트, 배포가 가능하다. 특정 모듈에 문제가 생겨도 다른 모듈에 영향이 최소화된다.
• 팀 협업에 유리
  대규모 프로젝트에서는 모듈별로 팀을 나눠서 개발할 수 있어 협업이 수월하고, 관리가 효율적이다.
• 유지보수 용이
  관심사 분리가 명확해져서, 유지보수와 확장이 쉬워진다.

실제 적용한 우리 팀의 멀티 모듈 구조

우리 프로젝트의 구조는 크게 boot와 data 두 개의 상위 모듈로 나뉜다.

• boot
  • api
  • batch
  • office
• data
  • core-data
  • office-data

core-data에서는 엔티티, 레포지토리, 서비스 등 데이터 관리와 저장, 튜닝을 담당하고,
api에서는 core-data의 서비스를 받아와 비즈니스 로직을 처리한다.
office도 비슷한 구조지만, api에서 구현한 로직을 Feign Client를 통해 office에서 호출할 수 있도록 설계했다.

싱글 모듈 방식과의 비교

구분싱글 모듈 방식멀티 모듈 방식

 

코드 관리	모든 코드가 한곳에 집중	기능/역할별로 분리, 공통코드 재사용 용이
빌드/배포	전체 빌드·배포만 가능	모듈별 독립 빌드·배포 가능
협업	협업 시 충돌·의존성 문제 잦음	팀별 모듈 분담, 협업 효율↑
유지보수	규모 커질수록 복잡도↑, 관리 어려움	관심사 분리로 유지보수·확장성↑
단점	구조 단순, 소규모에 적합	초기 설계·설정 복잡, 의존성 관리 필요

 

멀티 모듈 방식의 단점과 주의점

• 구조 파악과 설계가 어렵다
  처음엔 각 모듈의 역할과 흐름을 이해하는 데 시간이 걸릴 수 있다.
• 초기 설정 및 의존성 관리 복잡
  Gradle/Maven 등 빌드 도구 설정, 모듈 간 의존성 관리가 필요하다.
• 빌드 시간 증가
  모듈이 많아질수록 전체 빌드 시간이 길어질 수 있다.
• 공통 모듈 변경 시 영향도 큼
  core/common 모듈이 비대해지면, 작은 변경도 여러 모듈에 영향을 줄 수 있어 주의가 필요하다.

결론: 언제 멀티 모듈 방식을 선택할까?

• 프로젝트가 커지고, 여러 도메인/기능이 복잡하게 얽혀 있을 때
• 여러 팀이 동시에 개발하거나, 코드의 재사용성이 중요한 경우
• 유지보수와 확장성을 고려해야 하는 대규모 서비스라면
  → 멀티 모듈 구조로 리팩토링하는 것이 확실히 유리하다.

처음에는 구조가 복잡하게 느껴질 수 있지만, 한 번 익숙해지고 나면
프로젝트의 규모가 커질수록 멀티 모듈 구조의 장점이 많다고 생각을 한다. 
앞으로도 대규모 프로젝트를 설계할 때  멀티 모듈 방식이나 MSA을 적극적으로 고민해볼 가치가 충분하다고 생각하지만, 처음 하다보니 적응하는데 어려웠다.