멀티 모듈(Multi Module)이란?
애플리케이션이 각각 특정 목적이나 기능을 제공하는 여러 모듈로 나누어지는 프로젝트 구조를 의미합니다.
모듈(Module)이란?
소프트웨어 개발의 모듈은 특정 기능을 수행하는 독립적인 코드 단위이며 종종 더 큰 시스템의 일부를 말합니다.
멀티 모듈은 왜 사용할까?
위 사진은 처음 소규모 앱을 만들 때 주로 사용하는 프로젝트 구조입니다.
위 구조는 처음 서비스 운영 시에는 문제가 없으나 서비스가 발전하여 기능이 점점 추가될 경우 다음과 같은 문제가 발생합니다.
확장성 문제: 계층의 가장 아랫부분인 인프라 계층부터 구현하려는 경향을 가지게 되는데, 이는 도메인과 db 엔티티의 경계를 모호게 하여 결국 도메인 모듈과 인프라 모듈이 혼재하기 되는 한계를 갖습니다.
리소스 관리: 프로젝트 규모가 커질수록 모듈 간 복잡도가 높아지고, 빌드 시간이 늘어납니다.
그 밖에도 여러 문제가 있지만 크게 위 두 문제를 해결하기 위한 목적 멀티 모듈 구조를 사용합니다.
멀티 모듈을 사용함으로써 어떤 이점이 있을까?
향상된 확장성: 전체 시스템을 재작 업할 필요 없이 모듈을 업데이트하거나 추가하여 새로운 기능을 추가하거나 기존 기능을 강화하는 것이 더 쉽습니다.
리소스 최적화: 다양한 모듈이 리소스를 효율적으로 관리할 수 있습니다. 예를 들어, 서버 설정이나 라이브러리를 바꿀 때 특정 모듈에만 영향이 가도록 만들 수 있습니다.
시스템 전체 오류 위험 감소: 하나의 모듈에 문제가 발생하면 해당 모듈을 격리하여 전체 시스템이 손상되는 것을 방지할 수 있습니다.
더 쉬워진 유지 관리 및 업그레이드: 개별 모듈을 독립적으로 업데이트, 테스트 및 유지 관리할 수 있으므로 이러한 프로세스가 단순화되고 의도하지 않은 결과가 발생할 위험이 줄어듭니다.
어떻게 멀티 모듈을 설계하면 좋을까?
이 부분은 여러 글들을 보고 난 뒤 설계에 대해 개인적으로 고민했던 부분을 공유할까 합니다.
먼저 모듈을 나누는 기준에 대해 검색을 해보니 다음과 같은 공통점이 나왔습니다.
1. 모듈은 독립적인 의미가 존재
2. 계층 간 의존 관계에 대한 규칙이 존재
위 공통점을 기준 삼아 다음 사진의 구조로 멀티 모듈을 만들었습니다.
처음에는 레이어드 아키텍처를 기준으로 중복되는 코드들만 따로 분리해서 일단 만들어보자라는 생각을 시작으로 모듈을 분리했습니다. 하지만 다음과 같은 문제점이 나왔습니다.
프로젝트가 점점 커지면서 core 모듈 안에 존재하는 코드들이 점점 많아졌으며, core 모듈 내에서도 서로 거미줄처럼 의존하는 코드들이 많아져 수정이 점점 힘들어졌습니다.
그래서 다른 방식이 없을까? 하고 생각하고 검색해 본 결과 구조를 다음과 같이 변경했습니다.
위 사진에 있는 모듈별 역할은 다음과 같습니다.
app-api
독립적으로 실행 가능하며, storage 모듈을 제외한 다른 모듈과 협력하여 기능을 처리하는 모듈
예) controller, service
domain
비즈니스 로직을 처리하는 계층
예) domain, repository
storage
다양한 저장소에 대한 설정 및 제어 관련한 코드를 처리하는 모듈
예) db-config, repositoryImpl
clients
저장소 외 외부 시스템과 통신하는 모듈
예) 타 api 서비스(aws, gcp.. 등)
core (공통 모듈 계층)
모든 모듈에서 공통으로 사용될 수 있는 코드들을 모아둔 계층
예) common, utils, type 등
support (독립 모듈 계층)
시스템과 무관하게 어디에서나 사용 가능한 라이브러리를 모아둔 계층
예) 로깅, 모니터링
왜 위 구조로 모듈을 분리했나?
다음의 이유들을 기준 삼아 분리를 진행했습니다.
1. properties의 설정값 정보가 필요한 코드들 분리: core 모듈 내에서도 코드가 많아지니 properties 설정값이 비대하지는 경향이 있었습니다. 저는 이 설정값도 모듈 공통 기준으로 분리해서 의존성을 관리하고 싶은 목적이 있었습니다.
2. 자주 변하는 것과 변하지 않는 것을 기준으로 분리: 결국 모듈을 분리하는 것도 설계의 일부라 생각이 들기도 했고 프로젝트 코드를 봤을 때 명확하게 이렇게 모듈을 분리해야 해라고 생각이 들지 않았기 때문에 고민이 좀 많았었는데요.
이 부분은 설계의 기본 중 하나인 자주 변하는 것과 변하지 않는 것 기준으로 먼저 분리를 해보고 문제가 생긴다면 그때 다시 생각해 보자라는 생각으로 나눴습니다.
언제 사용하면 좋을까?
모노리스 프로젝트에서 사용하는 공통 컴포넌트(Common) 코드가 비대해져서 작업 수행 및 히스토리 파악이 어려울 경우 또는 대규모의 복잡한 애플리케이션, 특히 확장이 필요한 애플리케이션, 여러 팀에서 개발하는 애플리케이션, 빈번한 업데이트 및 유지 관리가 필요한 애플리케이션을 처리할 때 사용하면 좋겠다고 생각합니다.
마무리
오늘은 멀티 모듈 구조에 대해 고민했던 내용들을 정리해 보았습니다.
최근 멀티 모듈 구조에 관해서 다른 동료 개발자들이랑 이야기해 보니 몇몇 분들은 굳이 이렇게 해야 하나?라고 생각한 분들이 있었습니다. 그래서 "왜 그럴까?" 하고 좀 더 이야기를 해보고 생각을 정리해 보니 "모노리스 구조로도 충분히 개발이 가능한데 굳이 멀티 모듈로 가야 하는 건가?"라는 생각과 "이거 어떻게 멀티 모듈을 분리해야 하는 건가?"라는 두 가지 답이 안 나와서 그런 게 아닐까?라고 생각이 들었습니다.
그래서 공부하여 정리를 해보니 위 두 가지 질문에 대한 답이 정리가 되어서 이런 상황에서 쓰면 좋겠다고 명확하게 설명할 수 있겠다고 생각이 들어 좋았습니다. 하지만 이 정리한 내용이 다른 분들에게 공감이 갈까?라는 새로운 고민이 생기긴 했네요.
이번 포스팅은 마무리하면서 다른 주제의 포스팅에서 뵙겠습니다.
참고
멀티모듈 설계 이야기 with Spring, Gradle
안드로이드 [Kotlin] - Clean Architecture / 모듈화(2)
https://github.com/MangKyu/multimodule-sample
'CS 지식 > 아키텍처' 카테고리의 다른 글
| 도메인 주도 설계(Domain Driven Design)란? (0) | 2022.09.22 |
|---|---|
| 이벤트 기반 아키텍처(Event Driven Architecture)란? (0) | 2022.03.20 |
| GraphQL 이란? (0) | 2021.11.16 |
