이 글에서 얻는 것
- “모놀리스 vs 마이크로서비스”를 이분법으로 보지 않고, 모듈러 모놀리스(모듈화) → 점진 분리의 현실적인 경로를 설계할 수 있습니다.
- 경계(도메인/데이터/트랜잭션)를 먼저 잡아 “분리했더니 더 어려워지는” 함정을 피할 수 있습니다.
- Strangler(점진 대체)로 트래픽을 안전하게 옮기고, 롤백 가능한 전환을 만드는 방법을 이해합니다.
0) “나누기”의 목표를 먼저 정하라
서비스를 나누는 이유가 불명확하면, 분리 후 운영 복잡도만 늘어납니다.
대표적인 목표:
- 배포 독립성(특정 기능만 빠르게 배포하고 싶다)
- 확장성(특정 도메인만 스케일해야 한다)
- 변경 충돌 감소(팀이 커져서 같은 코드에서 싸운다)
- 안정성(장애 격리, blast radius 축소)
목표가 정해지면 “모듈화로 충분한가?” “서비스 분리가 필요한가?”가 결정됩니다.
1) 3가지 선택지: 모놀리스 / 모듈러 모놀리스 / 마이크로서비스
모놀리스: 단일 배포 단위
- 장점: 단순, 개발 속도 빠름
- 단점: 커지면 변경/빌드/배포 비용 증가, 장애 격리 어려움
모듈러 모놀리스: 배포는 하나지만, 내부 경계를 강하게 분리
- 장점: 운영 복잡도는 낮고, 변경 반경은 줄어듦(현실적)
- 단점: 배포 독립성은 제한적(여전히 한 덩어리)
마이크로서비스: 도메인별 독립 배포/운영
- 장점: 독립 확장/배포, 장애 격리
- 단점: 분산 시스템 비용(관측/네트워크/데이터 일관성/운영)이 크게 증가
대부분의 팀은 “모듈러 모놀리스”에서 큰 가치를 얻고, 필요할 때만 서비스 분리로 넘어갑니다.
2) 0단계: 경계를 잡는다(도메인/데이터/트랜잭션)
분리는 “코드”보다 “경계”가 먼저입니다.
- 도메인 경계: 주문/결제/배송처럼 책임이 분명한가?
- 데이터 경계: 누가 어떤 테이블을 소유하는가?
- 트랜잭션 경계: 어떤 변경이 반드시 원자적으로 묶여야 하는가?
이걸 건너뛰면, 결국 분리 후에도 서로의 DB를 찌르고 호출이 난무합니다.
3) 1단계: 모듈러 모놀리스로 ‘먼저’ 정리한다
서비스로 나누기 전에, 한 코드베이스 안에서 먼저 경계를 만듭니다.
- 기능 기준 패키지/모듈로 분리
- 모듈 간 공개 API를 최소화(UseCase/Facade/DTO)
- 인프라 의존(ORM/HTTP)을 경계 밖으로 밀어내기(Port/Adapter)
이 단계만 해도 “코드가 덜 얽히고”, 추후 분리 비용이 크게 줄어듭니다.
4) 2단계: 데이터 분리 전략을 결정한다
서비스 분리에서 가장 어렵고 중요한 건 데이터입니다.
선택지는 대략 세 가지입니다.
- 공유 DB + 스키마 분리(초기): 운영은 쉬우나 결합이 남음
- DB 분리(권장 방향): 소유권이 명확해지지만, 분산 트랜잭션/최종 일관성을 받아들여야 함
- 이벤트/CDC 기반 동기화: 읽기 모델/검색/통계 같은 파생 데이터에 적합
“한 번에 완벽한 분리”보다 “소유권을 명확히 하고, 점진적으로 분리”가 현실적입니다.
5) 3단계: Strangler로 점진 분리(트래픽을 안전하게 옮기기)
Strangler 패턴의 핵심은 “새 시스템을 옆에 붙이고, 트래픽을 조금씩 옮기는 것”입니다.
- 라우팅 레이어(API Gateway/Ingress/프록시)에서 특정 경로/사용자/비율만 새 서비스로 전환
- Shadow(미러링)로 결과를 비교해 신뢰도를 쌓기
- 문제 시 즉시 롤백(라우팅 되돌리기)
이 과정에서 관측성(로그/트레이스/지표)이 없으면 디버깅이 매우 어렵습니다.
6) 흔한 함정
- “서비스 분리 = 성공”이라고 믿고, 분산 트랜잭션/운영 복잡도를 과소평가
- 공통 모듈을 공유하다가 결국 강결합(버전 지옥)
- 서비스 간 동기 호출이 너무 많아져 레이턴시/장애 전파가 심해짐
연습(추천)
- 현재 모놀리스에서 “경계가 가장 뚜렷한 도메인” 1개를 골라 모듈러 모놀리스 형태로 패키지/의존성 규칙을 만든 뒤, 변경 반경을 비교해보기
- 데이터 소유권 표를 만들어보기(테이블/컬렉션의 오너 서비스는 누구인가?)
- Strangler 전환 시나리오를 작성해보기(Shadow → Canary → Cutover, 롤백 조건 포함)
💬 댓글