MSA vs 모놀리스 — 실제 부하 시뮬로 비교

한 줄 결론

MSA는 해결책이 아니라 trade-off입니다. 5개 service chain은 throughput을 N배로 늘리지 않고 p99 latency를 누적시키며 운영 복잡도 N배를 만듭니다. "팀이 5개라서 service도 5개" — Conway's Law가 정답. 부하 분산은 부수 효과.

모놀리스 = 모든 게 한 process

• 장점: 함수 호출 = 1ms 미만 (network latency 없음). transaction 한 줄에. 디버깅 단순.
• 한계: 단일 deploy unit이라 1 부분 release = 전체 재배포. 한 모듈이 메모리 폭발하면 전체 다운. team scale-out 어려움.

MSA = 도메인별 분리 + 독립 deploy

• 장점: 팀별 독립 release. 한 service 다운 = 일부만 영향 (격리). 도메인별 다른 기술 선택 가능 (polyglot).
• 비용: network 호출 1ms × N hop = p50 N배. p99는 곱 비슷 (tail latency 누적). distributed transaction 어려움 (Saga 등). 운영 복잡도 N배 (deploy / monitor / debug).

시뮬로 보는 비교

시뮬레이터에서 scale-out-chain-latency preset 열기. 5개 service chain에 각자 p99 50ms로 설정된 환경입니다.

결과: chain 전체 p99 ~200ms. 5 × 50ms (선형) 아닌 곱 비슷한 수치. 이유: 한 service slow하면 chain 전체 slow (서로 독립 X).

모놀리스로 같은 로직 처리하면 ~30ms. 즉 MSA로 처리량을 늘렸다고 생각하지만 한 요청당 latency는 6배 커짐.

언제 MSA?

모놀리스가 견디지 못할 때만:

1. 팀 인원이 50+ → Conway's Law (Two-pizza team)
2. 도메인별 release cycle이 매우 다름 (결제 = 주 1회, 검색 = 일 5회)
3. 특정 도메인이 다른 기술 필수 (e.g. ML inference = Python, payment = Java)
4. 모듈별 부하 패턴이 너무 다름 (검색 spike vs 결제 안정)

그 외엔 Modular Monolith로 시작 — 코드는 모듈 분리, 배포는 단일. 나중에 정말 분리 필요한 도메인만 MSA로 빼냄.

MSA 도입 시 필수 (시뮬에서 확인)

• Circuit Breaker — 한 service 죽으면 cascading 회피
• Outbox Pattern — DB write + 이벤트 publish atomic
• Saga — 분산 트랜잭션
• CQRS — read/write 분리
• API Gateway — 통합 진입점 (auth, rate limit)

면접 답변 템플릿

"MSA는 부하 분산이 아니라 조직 분산입니다. 팀이 작으면 모놀리스가 더 빠르고 정확합니다. 팀이 50+ 명 되면 deploy / release / on-call이 모놀리스로 안 풀려서 MSA로 가는 거고, 그 비용은 latency 6배 + 운영 복잡도 N배 + Saga/CQRS 필요. 단순 trade-off입니다."