📝 gradle 멀티 모듈 vs spring modulith

[jaeyeong951]

📌 의문

모듈을 나눈다는 관점에서 보면 이전부터 그랬던 것 처럼 gradle 기반으로 멀티 모듈을 구성해도 충분할 것 같은데 왜 spring modulith 를 쓰는가?

🤔 비교

1. gradle 기반 멀티 모듈화

• 각 모듈이 별도의 프로젝트임
• 모듈별로 별도의 build.gradle을 두어 의존성과 빌드 설정을 물리적으로 분리하여 관리
  • 그래서 각 모듈은 보통 독립된 JAR로 생성됨
• 애초에 물리적으로 구분했기 때문에 모듈을 루트 프로젝트에서 이탈시키기 쉬움
• 다만, 물리적으로 독립된 프로젝트가 여러개 생기는 만큼 복잡도가 상대적으로 증가
  • gradle 의존성 관리는 그 갯수가 한개 한개 늘어날 때마다 관리 비용이 배로 늘어남
• 모듈이 늘어나고 모듈간 의존성이 복잡해질 경우 이를 추적하는 것도 어려움
• 모듈 분리의 기준이 애매해지는 순간이 옴
  • 물리적인 분리이다보니 모듈을 분리하는 것 자체가 부담이고 "이것도 모듈로 빼야해? 근데 안빼기도 애매함" 같은 경우가 생김

2. spring modulith

• 각 모듈은 논리적으로 구분됨 (단순 패키지 단위 구분)
• 별도 서브프로젝트 형태가 아니므로, 빌드 관점에서는 여전히 “하나의 프로젝트”
• modulith 가 제공하는 부가적인 기능을 통해 모듈 간 의존성을 통제
• 의존성 관리가 수월함 (명확한 통제 + 테스트 + 시각화)
  • 의존성이 한눈에 보인다면 새로운 개발자가 합류해서 코드베이스에 적응하는 시간도 많이 줄어들듯?
• 하나의 모놀리식 프로젝트임에도 불구하고 내부에서 아키텍처가 서서히 무너지는 현상을 방지할 수 있음
• 애플리케이션이 커질 경우 빌드/배포 성능 문제로 인해 결국 몇몇 모듈은 물리적으로 분리되어야 함
  • 하지만 modulith 를 적극 활용하여 모듈화를 잘 해놓았다면 물리적 분리는 자연스럽게 가능 (점진적 분리가 간편)

언제 뭘 쓸까?

• 큰 조직에서 모듈별로 독립적인 개발을 하고 배포 주기도 다르다.
• 도메인 경계가 아주 명확하고 언젠가 반드시 분리할거다.

→ 애초에 모듈 빼는게 낫다.

• 조직의 규모가 크지 않고 한 덩어리로 배포되어도 상관 없다.
• 도메인이 어떻게 나눠질지 아직 불명확하다.
• 근데 아키텍처 정리는 잘 되었으면 좋겠다.

→ spring modulith 쓰면 좋다.

💡 정리

“기술적으로(빌드·CI·배포 관점) 모듈을 나눌 것인가?” → Gradle 멀티 모듈
“하나의 애플리케이션 안에서 도메인 경계를 잡고, 모듈 간 의존성을 관리할 것인가?” → Spring Modulith