탄생 배경
MSA의 장점을 가지고 다른 기업에서 적용시키다 보니 아래와 같은 문제들이 나타나게 되었다.
MSA의 부작용
- 네트워크 통신/ 장애 포인트 증가
- 분산 트랜잭션으로 묶기가 힘들어짐
- 모니터링, 배포 운영의 복잡도 증가
특히, 팀이 작을 수록 아래와 같은 문제점이 발생함
팀이 작을 때
- 쓸데 없이 나눈 서비스 수가 오히려 불편함만 가져옴
- 즉, 서비스 수 > 감당 가능한 팀 수
- 조직이 도메인 경계를 구분하지 않는 소규모 팀이라고 할 때 서비스는 나뉘어지는 이상한 구조가 나올 수 있다
- Conway’s Law - 조직이 아키텍쳐를 결정
- 복잡성이 증가할 수 록 소규모 팀에서는 발목이 잡히는 경우 발생
모듈러 모놀리스
모놀리식과 모듈식 설계 패러다임의 측면을 결합한 아키텍처 접근
- 단일 배포 단위를 유지하면서 내부를 도메인 경계로 명확히 분리한 구조
- 모듈은 일반적으로 비즈니스 역량 또는 도메인 주도 설계 (DDD) 원칙을 중심으로 조직된다.
특징
- 모듈성:
- 모듈러 모놀리식은 더 작고 독립적인 모듈로 구조화되며, 각 모듈은 특정 기능이나 비즈니스 도메인을 담당
- 모듈은 명확한 경계와 책임을 기준으로 조직되어 관심사의 분리와 유지보수성을 촉진한다
- 긴밀한 통합
- 모듈 구조를 가지지만 모든 모듈은 하나의 코드베이스와 런타임 환경 안에서 긴밀히 통합된다.
- 모듈 간 별도의 배포나 통신 메커니즘이 필요 xx
- 공유 코드베이스와 데이터:
- 모든 모듈이 동일한 코드베이스, 라이브러리, 데이터 저장소를 공유
- 이는 분산 시스템에 비해 개발과 배포를 단순화하면서도, 코드 조직과 관심사 분리 같은 모듈성의 이점을 유지하게 된다.
- 확장성 및 유지보수성:
- 전통적 모놀리식 대비 확장성과 유지보수성에서 이점을 제공
- 애플리케이션을 모듈로 분해함으로써 복잡성을 더 효과적으로 관리하고, 개별 컴포넌트를 독립적으로 확장할 수 있다
- 유연성
- 단일 코드베이스임에도 개발과 배포 측면에서 유연
- 전체 시스템에 영향을 주지 않고도 요구 사항 변경에 맞춰 모듈을 쉽게 추가, 제거, 수정 가능
- 배포 용이성:
- 배포 아티팩트가 하나뿐이므로 분산 시스템에 비해 배포가 더 간단하다.
- 배포와 운영의 복잡성이 줄어들어 애플리케이션 라이프사이클 관리가 쉬워짐
⇒ 모듈성과 모놀리식 아키텍처의 단순함을 결합함으로써, 모듈러 모놀리식은 유연성, 확장성, 유지보수성 간 균형을 이루어 중간 정도의 복잡성과 확장성 요구를 가진 애플리케이션에 적합
원칙
- 모듈성
- 애플리케이션을 더 작고 독립적인 모듈로 분해하고, 각 모듈은 특정 기능이나 비즈니스 도메인을 책임져야한다.
- 모듈은 명확한 경계와 잘 정의된 인터페이스를 가져야 하며, 이는 관심사의 분리와 유지보수의 용이성을 높임
- 높은 응집도, 낮은 결합도
- 각 모듈은 정확하고 집중된 목적을 가져야 하며 애플리케이션의 특정 측면을 책임져야 한다.(높은 응집도)
- 동시에 모듈 간 의존은 느슨해야 하며 서로에 과도하게 의존해서는 안된다.(낮은 결합도)
- 명확한 경계
- 모듈 간 경계를 명확히 정의하여 의존성을 최소화하고, 독립적인 개발과 테스트를 용이하게 한다.
- 모듈을 뒤섞거나 강한 결합을 도입하면 복잡성이 증가하고 변경이 어려워진다.
- 단일 책임 원칙(SRP)
- 각 모듈은 변경의 이유가 하나만 있어야 한다는 단일 책임 원칙을 따른다
- 이는 모듈 내부의 명확성과 단순성을 유지하고, 한 모듈의 변경이 시스템의 관련 없는 부분에 영향을 주지 않도록 한다.
패턴
- 레이어드 아키텍처
- 애플리케이션을 여러 레이어로 나누어 각 레이어가 특정 기능을 담당한다.
- 일반적으로 표현/UI 레이어, 비즈니스 로직 레이저, 데이터 접근 레이어가 포함된다.
- 관심사의 분리를 촉진하고 확장성과 유지보수성을 높임
- 모듈러 모놀로식
- 애플리케이션을 더 작고 독립적인 모듈로 분해하며, 각 모듈은 특정 기능이나 비즈니스 도메인을 담당한다
- 단일 코드베이스이지만 모듈 간 결합은 느슨하며, 모듈을 독립적으로 개발, 배포, 유지관리할 수 있다.
- 모놀리식의 단순함과 모듈식의 모듈성을 결합함
- 컴포넌트 기반 아키텍처
- 애플리케이션을 재사용 가능한 독립 컴포넌트로 조직하며, 각 컴포넌트는 관련 집합을 캡슐화한다.
- 컴포넌트를 조립, 구성하여 더 큰 애플리케이션을 구축함으로써 코드 재사용과 유지 보수성을 높인다
단점
- 복잡성 관리: 애플리케이션의 규모와 복잡성이 커질수록 모듈 간 상호작용을 관리하고 코드베이스 전반의 일관성을 보장하는 일이 어려워질 수 있다.
- 때문에 불필요한 복잡성을 피하려면 모듈 경계와 의존성을 신중히 설계해야함!
- 의존성 관리: 모듈 간 상호 의존성이 있거나 한 모듈의 변경이 다른 모듈에 영향을 줄 수 있을 때, 의존성 관리가 어려울 수 있다.
- 충돌이나 브레이킹 체인지를 피하려면 의존성과 버전 관리를 신중히 해야 합니다.
- 배포 복잡성: 전통적 모놀리식보다 모듈러 모놀리식은 여러 모듈을 함께 배포해야 하므로 더 복잡할 수 있다.
- 특히 분산 환경에서 배포를 조율하고 모듈 간 일관성을 확보하는 일이 도전적
- 테스트 오버헤드: 모듈 간 상호작용과 개별 모듈 자체를 모두 테스트해야 하므로, 전통적 모놀리식보다 테스트가 더 어렵고 시간이 소요될 수 있다.
- 포괄적인 테스트 스위트를 마련하고 모듈 전반의 충분한 커버리지를 확보해야 한다.
3가지 아키텍처 비교
모놀리스 방식
경계 x
- 단일 배포
- 모든 구성 요소가 강한 결합
- 애플리케이션 전체가 하나의 분리 불가능한 유닛으로 구축됨
- 유지보수 어려움
모듈러 모놀리스
도메인 경계 강제
- 단일 배포
- 모듈 간 결합을 느슨하게 설계하여 개발, 테스트, 유지보수를 쉽다.
- 애플리케이션을 더 작고 관리 가능한 모듈 또는 컴포넌트로 분해하며, 각 모듈은 특정 기능 집합을 담당한다.
- 도메인 분리 유지
- 내부적으로 도메인 경계를 강제함으로써 팀이 분리되고 서비스가 커지면 MSA로 자연스럽게 분리 및 확장이 가능하게 한다
MSA
독립 배포 단위
- 서비스별 독립 배포
- 높은 운영 복잡도
- 개별 확장 가능
전환 전략
모놀리스 → 모듈러 → MSA
모놀리스를 처음으로 하는 이유는 도메인 경계를 정확히 식별하기 위함이다. 댓글을 찾아보던 중 정확하게 식별을 하지 않는다면 모듈러 모놀리스의 구조는 이상하게 간다고 한다…
모듈러 모놀리스는 MSA의 예행연습이라고 한다. 경계를 코드로 강제해두면, 필요할 때 쪼개기가 훨씬 수월하여 MSA 전환이 가능하다는 점이다
참고자료
'Back-end > Architecture' 카테고리의 다른 글
| 모듈식 모놀리스와 헥사고날 아키텍처로 구성된 Nearby 서버 구조 분석하기 (0) | 2026.07.17 |
|---|