멀티모듈

멀티모듈이란?

우리가 흔히 프로젝트를 하며 만날 수 있는 프로젝트들은 단일 모듈 멀티 프로젝트이다.

단일 모듈 멀티 프로젝트

- member-internal-api
- member-external-api
- member

위 처럼 서로 독립된 프로젝트들이 하나의 중심 Domain을 공유하고 있는 상황에서 생기는 문제점들을 알아보자.

• 사람에게 의존적인 일관성
  • 
  • 각각으로 진행되던 프로젝트에서, 동일하게 다뤄지는(공유되어야 하는) Member라는 도메인이 존재한다. 이 클래스들이 서로 다른 3개의 프로젝트에 존재해, 복붙을 통해서 옮겨야 했다.
    • 사람에게 의존적인 일관성을 가지고 있다.

• 사내 리포지터리에 공유 -> 번거로움..
  • 
  • 이 문제를 해결하기 위해 하나의 공통된 사내 레포지터리(Nexus)에 프로젝트를 올리는 방법이 사용되었다. (공유되는 domain을 프로젝트화해서 공유)
    • 이 방법을 통해 시스템적 일관성은 보장되었다! (일일이 복붙 안해도 된다)
      • 그러나 프로젝트 4개에서 Nexus에 올리고, 다시 다운받고, ... 이런 과정이 되게 번거로웠다.ㅠㅠ

멀티 모듈 단일 프로젝트

위와같은 상황을 해결하기 위해, 멀티 모듈 단일 프로젝트를 도입했다!

• 
• 프로젝트가 하나고 그 안에 여러개의 모듈을 설치하는 방식
  • 프로젝트를 분리해 넥서스로 공유되던 프로젝트(그림에서는 Mmeber)를, 하나의 IDE에서 포함해서 사용 가능 (Intelli-j를 하나만 켜둬도 괜찮아서 편하다)
  • 시스템적으로 일관성도 보장되었다!

MSA vs 멀티모듈

• Monolithic 아키텍쳐
  • 
    • 하나의 애플리케이션에서 여러 개의 영역으로 구분되고, 이것이 하나의 프로젝트에서 통으로 관리되는 것을 Monolithic 아키텍쳐라고 부른다.

• MSA

  • 
    • 동일한 구조이지만, 서비스를 내부적으로 가지는 도메인을 상세히 분리하고, 그 분리된 직군들이 하나의 서비스를 제공하는 것을 MSA라고 한다.

• 멀티모듈

  • Monolithic, MSA 모두 멀티모듈로 다뤄질 수 있는 개념일 수 있다.
    • 
    • 
  • 멀티모듈과 MSA가 사용성 측면에서 크게 연관이 없을 수 있다.
  • 그럼에도 불구하고, MSA에서 멀티모듈이 부각되는 이유는
    • 개발 중 시스템을 분리, 통합해야 하는 사이클에 있어서 멀티모듈의 도입이
    • 역할, 의존성의 분리를 통해 시스템의 분리, 통합을 유연하게 만들어 줄 수 있는 좋은 아키텍처를 만들도록 도와주기 때문이다.

좋은 아키텍처는 시스템이 모노리틱 구조로 태어나서 단일 파일로 배포되더라도, 이후에는 독립적으로 배포 가능한 단위들의 집합으로 성장하고, 또 독립적인 서비스나 마이크로서비스 수준까지 성장할 수 있도록 만들어져야 한다. 또한 좋은 아키텍처라면 나중에 상황이 바뀌었을 때 이 진행 방향을 거꾸로 돌려 원래 형태인 모노리틱 구조로 되돌릴 수도 있어야 한다. by.클린 아키텍처

---

실패한 멀티 모듈 프로젝트

멀티 모듈이라는 개념을 처음 접하면, 아래와 같이 생각할 수 있다.

😃 아, 공통로직을 common(혹은 core)로 분리하려고 멀티 모듈을 사용하는거구나!

그러나 이와같은 접근은 아래와 같은 문제점을 유발할 수 있다.

문제점1. 스파게티 코드

다양한 공통(이라고 생각되는)로직들이 Common으로 모이게 된다. Common에 대한 명확한 기준없이 공통(이라고 생각되는)로직들을 한 곳에 묶어버리게 되면, Common이 점점 커지게 되고, 이후에 특정 기능을 제거하려고 할때, 이 Common모듈을 사용하는 모든 모듈이 영향을 받는 상황이 발생할 수 있다.

문제점2. 공통묘듈이 의존성 덩어리가 됨

• 
  • Common으로 코드가 다 몰리게 되다보니, Common에서 서로 다른 모듈(위의 3가지)의 의존성을 전부 가지게 되었다.
  • 의존성을 모두 가지는 것은 어떤 위험성을 갖게 되는 걸까?

• 
  • 스프링부트를 사용하면, 스프링부트가 하나의 모듈안에 모든 설정을 가지고 있고 특정 발동 조건을 가지고 있다. Bean의 존재여부나, 심지어는 클래스의 존재 여부만으로 특정 의존성이 발생할 수 있다.
    • 따라서 특정 모듈에서 특정 클래스를 가지고 있는것 만으로, 의도하지 않았던 의존성이 모듈 전체에 영향을 미칠 수 있다.
    • 예상하지 못한 의존성으로 문제가 생기더라도, 이 의존성이 정확히 어느 부분에서 시작된것인지 예측하기조차 힘들다...

문제점3. - 설정값 공유의 문제

• 
  • DB의 커넥션을 다 동일하게 맞춰버려서 DB 접근이 적은 모듈까지도 과하게 DB 커넥션을 가져가 문제가 되었다.

---

🧐 왜 위와같은 실패가 발생했을까?

모듈에 대한 정의가 모호했다.

Common처럼 광범위하고 모호한 이름으로 프로젝트를 진행한 것이 문제가 되었다.

모듈화란?

• 모듈에 대한 철학
  • 기존: 머리(common)를 여기저기(external, internal ...) 바꿔가면서 사용하는 방식. 완성된 로직에 머리(core, common)을 붙여 성격이 다른 새로운 기능을 생성하는 방식을 의미한다.
    • 
    • 왼쪽의 '머리'를 완성되어있는 다양한 로봇에 붙이면 성격이 다른 로봇이 되는 애니메이션.
  • 이후: 중앙에 '사람형태의 로봇'을 두고, 거기에 '팔-다리(기능이 명확한 모듈)'를 추가하거나 변경하며 시스템을 구성하는 것.
    • 
    • 중앙의 '사람형태 로봇'이 모든 흐름을 관리하며, 거기에 '팔-다리'라는 명확한 기능을 붙여서 완성된다.

그래서, 무엇을 중심으로 모듈을 정의내려야 할까?

• 역할과 책임
  • 객체지향의 개념과 유사하게, 모듈화라는 것 역시 그 역할과 책임이 명확한 것이 중요하다.
• 그래서, 역할과 책임에 대한 범위는?
  • 이 역할과 책임에 대한 범위는 그 크기의 조절이 쉽지 않은데, 어떻게 조절할 것인가?
  • 아, 모듈의 대표 개념인 라이브러리를 참고해서 알아보자!
• 라이브러리
  • 어, 계층을 뒀네??
  • 
    • 라이브러리에서 계층간 역할과 흐름을 명확히 한 것을 확인할 수 있었다.
  • 그러나, 라이브러리(프레임워크)는 사용성, 기능 제공에 목적이 있고, 우리가 만드는 애플리케이션의 목적은 서비스 제공이므로 계층 분류에 있어 차이게 있었다.
    • 직접 계층, 역할을 나누어 보자!
      • 멀티 모듈을 직접 구성해보자!!

---

내 생각

모듈화는 복잡한 시스템을 더욱 효율적으로 관리하고, 유연하게 확장할 수 있는 방법을 제공한다. 소프트웨어 개발에 있어 '복잡성'과 '재사용성'이라는 주요 과제를 어떻게 다룰지에 대한 고민으로, "응집력이 높고 결합도가 낮은 모듈을 어떻게 구성할 것인가"라는 질문이 핵심적으로 다뤄져야 하는 문제라는 것을 배웠다.

이전에 많은 분들과 협업하며 프로젝트를 진행해오면서, 단순히 기능을 수행하는 것에 집중하는 경향이 있었다. 기능이 담기는 구조보다는 기능 자체의 명확함과 정확성이 더 중요하다는 방향으로 생각이 변화했던 것 같다.(즉, 구조의 중요성을 간과하는 방향으로.)

그러나 영상에서 장기간 특정 코드를 다루고 개선시켜 나가는 과정에서, 가장 핵심이 되는 구조가 명확하지 않으면 그 안에 쌓인 코드들이 견고하게 쌓이지 않고 무너진다는 것을 보여주신 것 같다. 특히, 개발자 개인의 구조에 대한 접근의 변화가 청자로 하여금 더 명쾌하고 직관적으로 느끼게 하는 것이 흥미로웠다. (모듈화에 대한 발표자의 생각 변화가, 접하는 나로서도 훨씬 선명하게 느껴졌다.)

처음 구조를 설계하는 개발자의 접근 방식이 명확해지고 체계가 잡히는 것만으로, 함께 개발을 수행하는 모든 팀원이 오해하고 곡해하며 낭비하는 시간, 그리고 단순히 이해에만 소요되는 시간, 이 모든 것들을 줄여준다. 초기에 구조를 견고하게 견고히 하는 작업은, 결과적으로 오류를 줄여주어 기능 역시 더욱 명확하게 작동하게 하는 것 같다. 결과적으로 팀 전체에 매우 이득이 될 것 같다.

---

Reference

• [우아한테크세미나] 190829 우아한멀티모듈 by 우아한형제들 권용근님
• 멀티모듈 설계 이야기 with Spring, Gradle