Springboot Java - Multi Module

서브 프로젝트를 진행하는데, 멀티모듈의 구조로 가져가는 것도 좋을 것 같다는 의견을 들었다.

f-lab에서 멘토링을 진행 중이고, 멘토님께서 말씀해주셨다.

그동안 몇몇 프로젝트를 라이브러리로 사용하기 위해, 라이브러리에 해당하는 프로젝트를 따로 만들어 jar로 배포하고 그 파일을 다른 프로젝트에서 사용한 적은 있지만, 멀티 모듈이라는 용어는 처음 들었다.

그래서 이에대해 자세히 알아보고 정리해보고자 한다.

multi-module이란?

모듈과 멀티 모듈

모듈(module)

모듈은 여러 가지로 정의될 수 있지만, 일반적으로 큰 체계의 구성요소이고, 다른 구성요소와 독립적으로 운영된다.

멀티 모듈(multi-module)

서로 독립적인 프로젝트(인증, 어플리케이션)를 하나의 프로젝트로 묶어 모듈로서 사용되는 구조를 말한다.

대략적으로 어떤 구조를 말하는지는 이 단어의 설명만으로도 이해가 되긴한다.

뭐가 달라지는 걸까?

멀티 모듈의 구조로 설계하면, 뭐가 어떻게 달라질까?

기존 프로젝트와 멀티 모듈 프로젝트

기존의 방식대로 개발한다면, 계층 구조나 도메인 구조 중 선택해서 개발하게 된다.

controller
	⎿ AController
	⎿ BController

service
	⎿ AService
	⎿ BService
   
domain
	⎿ A
	⎿ B

A
⎿ controller
⎿ service

B
⎿ controller
⎿ service

---

그렇게 개발했다면, 위의 그림과 같이 (계층형-좌 / 도메인형-우) 프로젝트의 구조를 가지게 될텐데, 만약 이 A,B외에도 다양한 도메인이 있고, 규모가 대규모라면, 많은 인력의 사람들과 협업해야한다면? 이렇게 관리하기에는 무리가 있다.

그렇다면 멀티모듈은? 각 모듈은 독립적으로 빌드 및 배포가 가능하기 때문에 프로젝트에 있는 기능들을 여러 개의 모듈로 나눠서 개발하면 하나의 프로젝트로 관리하는 것보다 편할 것이다. 그러한 이유로 요즘 MSA 구조도 많이 사용된다.

MSA와 멀티 모듈

그렇다면 MSA 구조와 멀티 모듈이 어떻게 다른지도 알아보자.

MSA(Microservices Architecture)

서비스별로 완전히 독립된 애플리케이션으로 나누고, API를 통해 통신하는 방식

멀티 모듈(Multi-module)

하나의 프로젝트 안에서 여러 개의 모듈을 나누어 개발하는 방식

이 둘의 차이점은 완전히 독립되었는지(=여러개의 프로젝트인지), 아니면 하나의 프로젝트인지다.

왜 그러면 MSA를 사용하지 않고 멀티 모듈을 적용하라고 하셨을까? 아마 MSA의 구조는 운영의 복잡도가 높아 혼자 개발을 시작하는 서브 프로젝트로는 적합하지 않다고 생각하셨을 것 같다. 더군다나 모듈로도 분리해서 개발해 본적이 없으니 더 오래 걸리지 않았을까..하는 생각도 든다. 그리고 이런 멀티 모듈의 구조라면 이미 기능마다 모듈화 되어있기 때문에, 규모가 커졌을 때 MSA 구조로 변경하기에도 쉽다.

멀티 모듈의 장점은?

지금까지 멀티 모듈이 기존의 구조들과 어떤점이 다른지 알아봤다. 그러면 이제는 이런 멀티 모듈의 장점은 무엇인지, 왜 써야하는지 알아보자.

여러가지 글을 읽은 후 내가 생각하는 멀티 모듈의 가장 큰 장점은 기능 단위별로 분리를 해주면서, 공통 부분에 대한 구조나 규칙은 보장해준다는 점이다. 서비스의 규모가 커져서 Member에 관련된 기능을 여러개로 나눴다고 생각한다면,

• Member가 여러 API를 통해 인증을 받는 기능들
• Member가 실제 우리 로직에서 사용될 때 이용되는 기능들
• Member에 연관된 스케줄러들

또 각 나눠진 부분을 프로젝트 단위로 실행한다면, 공통 부분인 Member에 대한 항목들은 복붙을 해야한다. 이렇게 되면 공통 항목인 Member를 변경하는 일이 있을 때마다 3개의 프로젝트에 적용해야하는 상황이 생긴다. 불안하기도하고, 변경사항이 생길 때마다 작업양이 많이 생긴다.

이럴 때 멀티 모듈의 구조라면 기존의 단일 프로젝트를 프로젝트 안에 모듈로서 갖고 있기 때문에, 복붙해야하는 상황이 사라진다. Member를 공통으로 사용하는 모듈에 넣고, 각 기능들은 각자의 모듈로 실행하면 되기 때문이다.

물론 그렇다고 해서 작업양이 아예 사라지지는 않지만, 공통 부분에 대한 내용을 복붙하는 작업 없이도 완벽하게 구조나 규칙이 보장된다.

언제 사용하면 좋을까?

이런 공통모듈은 언제 사용되면 좋을까? 어떤 기준을 가지고 선택하면 좋을지 알아보자.

• 계층형(Layered Architecture): 가장 기본적인 방식, 프로젝트 규모가 작고 빠른 개발이 필요할 때
• 도메인형 (Domain-Driven Architecture): 도메인 중심으로 관리하려고 할 때
• 멀티 모듈 (Multi-Module Architecture): 한 프로젝트 내에서 모듈별로 분리, 유지보수성을 높이고 싶을 때
• MSA (Microservices Architecture): 완전히 독립적인 서비스로 운영, 대규모 서비스에서 확장성을 극대화

마치며

이외에도 더 많은 구조가 있을 것이고, 여기 정리한 언제 사용하면 좋을지에 대한 기준이 절대적인 것은 아니다. 그동안에는 다양한 구조에 대해 모르기도 했고, 그래서 언제 적용하면 좋을지에 대해 생각해 본 적이 없는데, 몰랐던 구조에 대해 알게되고 어떤 구조가 가장 적합할까? 에 대한 생각을 해보는 것 자체가 좋은 기회라는 생각이 들었다.

이 구조가 적합할까? 라는 기준은 이번 한번의 고민으로 끝나지 않고, 앞으로도 계속 해야하는 고민이 아닐까 싶다.