멀티 모듈 구조(Multi Module Architecture)란?

하나의 리포지토리/애플리케이션 내부에 명확한 경계와 의존 방향을 만든 구조

멀티 모듈은 하나의 빌드 단위(Gradle/Maven) 아래에 여러 개의 모듈(subproject)을 두고, 각 모듈이 역할과 의존 관계를 명확히 갖도록 설계한 프로젝트 형태입니다. 마치 레고 블록으로 거대한 성을 만드는 것과 비슷합니다. 성 전체를 한 덩어리로 만드는 게 아니라, 성벽, 탑, 문 등 기능별로 작은 블록을 조립해 합치는 것으로 생각하면 이해가 쉬울 것 같습니다.

멀티 모듈 프로젝트의 장점은?

1. 빌드 속도 향상 ⚡️

   멀티모듈의 가장 큰 장점 중 하나는 바로 빌드 속도 개선입니다. 전체 프로젝트를 빌드하는 대신, 변경된 모듈과 그에 의존하는 모듈만 다시 빌드하기 때문입니다. Gradle의 캐싱 기능과 결합되면 그 효과는 더욱 극대화됩니다.

2. 코드의 재사용성 및 유지보수 용이성 🛠️

   공통 기능을 core나 shared 같은 모듈로 분리해두면, 여러 기능 모듈에서 쉽게 가져다 쓸 수 있습니다. 똑같은 코드를 여기저기 복사-붙여넣기 할 필요가 없어집니다. 또한, 기능별로 코드가 명확하게 분리되어 있어 특정 기능을 수정하거나 개선할 때 다른 곳에 미칠 영향을 최소화할 수 있습니다.

3. 명확한 책임 분리 (SoC) 🧑‍💻

   각 모듈은 자신만의 명확한 역할과 책임을 가집니다. '로그인' 기능에 문제가 생겼다면? feature_login 모듈만 살펴보면 됩니다. 이렇게 책임 소재가 분명해지면 코드의 이해도가 높아지고, 여러 개발자가 협업할 때 발생할 수 있는 충돌(Conflict)을 줄일 수 있습니다. 각자 자신의 구역(모듈)에 집중하며 효율적으로 작업할 수 있게 됩니다.

멀티 모듈 프로젝트의 단점은?

1. 초기 설정의 복잡함 🌀

   처음 프로젝트를 구성할 때 모듈 간의 의존성을 설정하고 Gradle 스크립트를 관리하는 것이 다소 복잡하게 느껴질 수 있습니다.

2. 관리 포인트 증가 🤔

   모듈이 많아질수록 관리해야 할 build.gradle 파일도 늘어나게 됩니다. 라이브러리 버전을 통일하는 등의 관리에 신경 써야 합니다.

3. 모듈 간 통신 📡

   모듈 간의 통신을 위한 명확한 규칙(인터페이스 정의 등)이 없다면, 오히려 더 복잡한 의존성 지옥에 빠질 수도 있습니다.

왜 우리 프로젝트에 멀티 모듈 구조를 적용해야 했을까?

우리 프로젝트의 핵심 도메인은 다음과 같습니다.

1. Forecast (예보): 날씨 예보 데이터와 관련된 핵심 도메인
2. Mountain (산): 산의 정보, 등산 코스와 관련된 핵심 도메인
3. User (사용자): 사용자 정보, 인증 등과 관련된 도메인
4. Report (리포트): 사용자가 생성하는 산행 리포트 관련 도메인

그리고 우리 프로젝트는 2개의 애플리케이션이 동작합니다.

• api-server : 사용자 요청을 받아 날씨 예보, 사용자 정보, 리포트 데이터 등을 제공하는 실시간 서버입니다.
• batch-server : 주기적으로 초단기, 단기, 산악 날씨 예보 api를 호출하여 날씨 데이터를 수집하고 가공하여 데이터베이스에 저장하는 배치 서버입니다.

여기서 중요한 점은, 각 서버가 필요로 하는 도메인이 달랐다는 것입니다.

• api-server 는 Forecast, Mountain, User, Report 네 가지 도메인 모두를 사용합니다.
• batch-server 는 오직 날씨 데이터를 다루므로 Forecast , Mountain 도메인만 필요합니다.

🤯 우리가 마주한 문제들: 불필요한 의존성과 확장성의 한계

단일 모듈 구조에서는 batch-server가 전혀 사용하지 않는 User와 Report 도메인의 코드까지 모두 포함하게 됩니다. 이는 다음과 같은 비효율을 낳았습니다.

1. 불필요한 의존성: batch-server는 User 도메인의 작은 코드 변경만으로도 전체를 다시 빌드하고 배포해야 했습니다. 이는 안정성을 해치고 배포 리스크를 높이는 원인이었습니다.
2. 빌드 시간 증가: 프로젝트 규모가 커질수록 작은 변경에도 전체 코드를 컴파일해야 하므로 빌드 시간이 증가했습니다.
3. 미래 확장성의 부재: 현재는 '산악형 국립공원'에 한정된 서비스를 제공하고 있지만, 저희의 목표는 우리나라의 모든 산으로 서비스를 확장하는 것입니다. 새로운 종류의 예보 데이터나 지역별 특화 기능이 추가될 경우, 단일 모듈 구조에서는 코드의 복잡성이 걷잡을 수 없이 커질 것이 예상되었습니다.

🌟 멀티 모듈 구조를 적용했을 때의 기대 효과

1. 배포·릴리스 리스크 급감

   batch-server는 domain-forecast, domain-mountain만 의존하도록 고정 → user-domain, report-domain의 변경이 batch-server의 CD 동작에 영향을 미치지 않음.

2. 빌드·테스트 체감 속도 향상

   변경 모듈만 빌드/테스트

   • Gradle 증분 빌드 + 캐시로 수정 범위가 작은 PR의 피드백 루프가 빨라짐.

3. 기능 추가/확장 속도 상승

   플러그인식 기능 연동: 기상/산악 API 클라이언트를 infrastructure-module:*로 분리 → 새로운 공급자를 추가하고 싶은 경우, 새로운 모듈을 생성하는 것으로 기존 모듈에 영향 없이 쉽게 기능 추가/확장이 가능함.

   도메인 수평 확장 용이: ‘전국 산 확장’ 시 domain-mountain만 확장하고, batch/api는 인터페이스 계약만 유지하면 됨.