Monolith Modular Monolith MSA
3줄 요약
- Monolith, Modular Monolith, MSA는 성숙도 순서가 아니라 변경 결합도, 데이터 소유권, 배포 독립성, 장애 격리, 운영 준비도로 고르는 구조 선택이다.
- Monolith는 transaction과 운영이 단순하고, Modular Monolith는 process는 하나로 두면서 module 경계를 강제하며, MSA는 owner와 DB와 배포 책임을 분리한다.
- 서비스 분리는 성능을 항상 올리지 않는다. 네트워크 latency, eventual consistency, 장애 전파, observability, migration 비용을 새로 만든다.
핵심 정리
- Monolith가 나쁜 구조는 아니다. 작은 팀, 빠른 도메인 변경, 강한 transaction, 낮은 운영 역량에서는 합리적이다.
- Modular Monolith는 MSA 전 단계가 아니라, 단일 배포를 유지하면서 코드와 데이터 접근 경계를 훈련하는 선택이다.
- MSA는 팀이 독립적으로 배포하고 운영할 수 있으며 데이터 owner가 분리될 때 의미가 있다.
- Shared DB를 그대로 둔 서비스 분리는 MSA가 아니라 network를 추가한 분산 monolith가 되기 쉽다.
- 분산 transaction은 2PC보다 saga, outbox, idempotency, 보상 상태, 사용자 pending 계약으로 푸는 경우가 많다.
- 서비스 수가 늘수록 장애 격리도 가능하지만 timeout, retry, tracing, schema migration, on-call 비용도 늘어난다.
판단 순서
- 변경 결합도를 본다.
- 같은 기능 변경마다 order, payment, shipping 코드가 함께 바뀌는지 확인한다.
- 데이터 소유권을 정한다.
- 누가 write 권한을 갖고 어떤 테이블을 직접 읽어도 되는지 정한다.
- transaction 경계를 확인한다.
- 단일 ACID가 필요한지, pending/eventual consistency를 받아들일 수 있는지 판단한다.
- 배포 독립성이 실제 요구인지 본다.
- 팀, release cadence, rollback, 규제, SLO가 분리되는지 본다.
- 장애 격리 필요성을 확인한다.
- 결제 장애가 주문 조회를 막아도 되는지, fallback이 가능한지 정한다.
- 운영 준비도를 점검한다.
- tracing, alert, runbook, contract test, schema migration, on-call owner가 있는지 본다.
헷갈리는 지점
- MSA가 항상 Monolith보다 진보한 구조라고 오해하기 쉽다.
- 운영 준비 없이 나누면 단순한 함수 호출이 timeout, retry, partial failure 문제로 바뀐다.
- Modular Monolith를 어중간한 구조라고 생각하기 쉽다.
- 실제로는 service 분리 전에 의존성 방향, public API, 데이터 접근 금지를 검증하는 강한 설계 선택이다.
- DB만 공유하면 구현이 쉬우니 괜찮다고 느끼기 쉽다.
- Shared DB는 배포 독립성과 데이터 소유권을 깨뜨려 서비스 경계를 약하게 만든다.
- 분리하면 장애 격리가 자동으로 된다고 생각하기 쉽다.
- 동기 fanout, 공통 DB, 공통 cache, 공통 deploy pipeline이 남아 있으면 장애는 여전히 전파된다.
상세본 구성
01. Monolith의 장점과 한계 상세.md: 단일 app/DB 구조가 유리한 조건과 한계 신호를 다룬다.02. Modular Monolith 설계 상세.md: module API, 의존성 방향, repository 접근 제한, 내부 event를 다룬다.03. MSA 분리 기준 상세.md: 어떤 경계가 service 분리 후보가 되는지 판단한다.04. 분산 트랜잭션과 데이터 소유권 상세.md: 단일 ACID를 포기할 때 필요한 saga, outbox, owner 계약을 다룬다.05. MSA 도입 실패 신호 상세.md: 분산 monolith, shared DB, sync fanout, owner 부재를 탐지한다.
확인 질문
- 확인 질문: Monolith를 유지하는 것이 합리적인 경우는 언제인가?
- 답변: 팀이 작고 도메인이 자주 바뀌며 강한 transaction과 단순 운영이 더 중요한 경우다.
- 확인 질문: MSA 분리의 최소 조건은 무엇인가?
- 답변: 독립 배포할 owner team, 데이터 소유권, API/event 계약, 장애 대응과 관측 체계가 있어야 한다.
- 확인 질문: Shared DB를 둔 서비스 분리가 위험한 이유는 무엇인가?
- 답변: 코드만 나뉘고 데이터 owner와 schema 변경 책임이 분리되지 않아 배포 독립성과 장애 격리가 깨지기 때문이다.