단일 프로젝트 구조와 멀티 모듈 구조

처음 개발을 시작하는 단계에서는 보통 단일 프로젝트 구조에서 시작한다. 하지만 그 크기가 증대하고 각각의 역할들이 무수히 많아지면 관리와 복잡도도 매우 증가하게 된다. 그렇기 때문에 이를 해결하고자 나오는 해결책으로 대부분 모듈 구조화를 얘기하곤 한다.

문제점은?

예를 들어 Member라는 도메인이 존재한다. 단일 프로젝트 구조라면 Member라는 하나의 큰 도메인을 중심으로 여러 개의

 

서버들이 이에 대해 깊은 의존관계를 띄며 (ex - Internal Service (application serving..), Admin Serving, Exception, Utils..)등 여러 가지가 한 도메인 구조에서 존재하게 된다.

⇒ 즉, 여러 개의 IDE를 켜서 하나의 도메인을 바라보는 코드를 수정해서 배포하고 이를 또 적용하는 매우 비효율적인 일이 발생하게 된다.

 

이때 같은 도메인을 가진 곳에서 중복적인 기능이 필요하다면 어떻게 할 것인가? 분명 다른 위치여도 같은 코드들이 들어가게 될 것이다. 또한, 의존성도 필요한 의존성들을 전부 붙이게 될 것이다.

 

그렇다면 공용으로 사용하는 의존성과 기능들을 모아서 하나의 공용으로 사용하는 것을 만들면 되지 않을까?라는 생각이 든다. 하지만 이는 위험을 초래한다. 이를 많은 블로그나 사람들이 아래 사진처럼 common 모듈이 비대해지는 형상이라고 표현한다.

사진출처

멀티모듈 설계 이야기 with Spring, Gradle | 우아한형제들 기술블로그

 

결국 특정 기능을 수정하려고 해도 같은 결과를 맞닥뜨리게 된다. 하나를 수정하거나 특정 의존성이 추가/삭제된다면 이는 전체 서비스에 영향이 가게 된다. 한마디로 거대한 의존성 덩어리가 되고 이는 곧 복잡한 코드 연관성을 가지는 거대한 공용 덩어리가 된다.

 

예를 들어, common 모듈에 dynamodb 의존성을 추가해 둔 상태이고, batch 모듈은 webflux로 구현되어 있다. webflux는 기본적으로 netty를 띄우고 당연히 nettydb가 뜰 것이라 생각했지만, common 모듈의 daynamodb 의존성에 의해 jetty가 떠 있었는 현상이 발생할 수도 있다.

 

결국 문제는 크게 아래로 많이 칭한다.

• 모듈에 대한 정의가 모호하다.
• 모듈화란 무엇일까? 무엇을 중심으로 정의를 내려야 할까?
  • 역할과 책임이 명확하다면 좋은 모듈이 될 수 있지 않을까?
  • 역할과 책임에 대한 범위는 어떻게 잡아야 하지?

문제 해결책으로 등장한 도메인 기반 멀티 모듈

여러 블로그나 글에서 정의한 단일 모듈의 한계는 다음과 같다.

• 서로 다른 프로젝트에서 공통된 코드가 사용된다면, 코드를 복붙 해서 사용해야 한다.
• 여러 프로젝트를 사용하기 위해 IDE, 인스턴스를 N개 실행해야 한다.
• 패키지끼리 의존성이 강해서 하나의 수정이 N개의 오류를 발생시킬 수 있다.
• 프로젝트규모가 커지면 각 패키지가 담당하는 역할이 모호해진다.

멀티모듈은 각각의 모듈이 독립적이고, 간섭하지 않아 위의 문제가 발생하지 않는다.

 

결과적으로 멀티모듈 아키텍처는 프로젝트의 구조를 효율적으로 관리할 수 있는 여러 가지 장점을 제공한다. 다음은 멀티모듈의 주요 장점이다.

• 독립적인 개발과 배포
  • 멀티모듈 구조에서는 각 모듈이 독립적으로 개발되고 배포된다. 이로 인해 특정 기능의 변경이나 버그 수정이 다른 모듈에 영향을 미치지 않아, 전체 시스템의 안정성을 높인다.
• 코드 재사용성 향상
  • 공통된 기능이나 라이브러리를 여러 모듈에서 손쉽게 공유할 수 있다. 이는 코드 중복을 줄이고 유지보수를 용이하게 하여 개발 효율성을 크게 향상한다.
• 모듈 간의 명확한 책임 분리
  • 각 모듈은 특정한 역할과 책임을 가지며, 이를 통해 코드의 가독성과 이해도를 높인다. 각 모듈의 경계를 명확히 설정함으로써 팀원 간의 협업도 수월해진다.
• 스케일링 용이성
  • 멀티모듈 아키텍처는 프로젝트가 커짐에 따라 확장하기 용이하다. 새로운 기능이나 도메인을 추가할 때, 기존 모듈에 영향을 주지 않고 새로운 모듈을 생성하여 작업할 수 있다.
• 테스트 용이성
  • 독립적인 모듈은 각각의 기능에 대해 개별적으로 테스트할 수 있다. 이는 문제를 조기에 발견하고 수정할 수 있는 기회를 제공하며, 전체 시스템의 품질을 높이는 데 기여한다.
• 팀 간 협업 최적화
  • 여러 팀이 동시에 작업할 수 있는 환경을 제공한다. 각 팀은 특정 모듈에 집중하여 개발할 수 있으며, 이를 통해 개발 속도를 높인다.

결론 및 생각

멀티모듈 아키텍처는 단일 모듈 구조에서 발생할 수 있는 다양한 문제를 해결하며, 개발 효율성과 시스템 안정성을 높이는 데 큰 도움을 준다.

 

프로젝트의 규모가 커질수록 멀티모듈의 장점을 더욱 뚜렷하게 느낄 수 있으며, 장기적으로 유지보수와 확장성 측면에서 많은 이점을 제공한다. 따라서, 초기 단계에서부터 멀티모듈 구조를 고려하는 것이 바람직하다.

 

사실 멀티모듈을 해석하고 이를 적용하는 것은 팀마다 그리고 개인마다 해석이 다를 수 있다. 그리고 흔하게 사용되는 멀티모듈 구조가 이미 타 블로그나 글에서도 많이 언급되는 구조들도 존재한다.

 

하지만 결국 이는 특정 집단의 Best Practice이기 때문에 상황에 맞춰서 팀 간의 긴밀한 소통을 통해 끊임없이 고민해야 한다. 계속 어떤 구조가 더 나은 구조인지 고민하고 상황에 따라 바뀔 수 있기 때문에 확장 가능성도 고민해야 한다.

나 같은 경우도 사내에서 멀티 모듈을 도입할 때 정말 많은 구조들을 고민했고 어떻게 하면 효과적으로 이를 활용할 수 있을지 고민을 정말 많이 했다. 실제로 3~4번 정도는 아키텍처를 갈아엎은 기억도 존재한다.

 

그리고 굳이 멀티 모듈이 아니어도 되는 것이 존재한다. 가벼운 소규모 프로젝트 이거나 굳이 특정 도메인에 얽힌 것이 아닌 것들에 대한 서버, 기타 기능을 제공하는 유틸 기능에 대한 것 등 불 필요한 것들도 잘 고민해서 쪼개 가져가는 것도 방법이 될 수 있다. 하나의 방식에 너무 사로 잡히지 말고 여러 가능성을 열어두고 고민하는 게 좋은 방법이다.