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가 각 홉 편도 5ms로 순서대로 이어지는 환경입니다.

결과: 1,000 RPS 실측에서 서비스 카드는 전부 CPU 53~56%로 한가한데 e2e p50 127.7ms · p99 142.1ms입니다. 인터넷 왕복 40ms + 홉 6개 왕복 60ms = 100ms가 "가는 시간"이라, 지연의 78%는 어느 서비스 카드에도 안 찍힙니다 — 한 service가 느려지면 chain 전체가 같이 느려지는 이유도 이거예요(서로 독립 X).

같은 워크로드를 모놀리스/MSA 두 토폴로지로 나란히 둔 v16-monolith vs v16-msa 비교가 더 정확합니다: 모놀리스 p50 45.9 · p99 54.3ms → 같은 로직을 4단계 서비스 체인(순차 호출)으로 쪼갠 MSA는 p50 86.8 · p99 105.0ms. 처리량이 늘어난 게 아니라 요청 한 건당 지연이 약 1.9배 커진 겁니다.

언제 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 약 2배(실측 p50 45.9→86.8ms) + 운영 복잡도 N배 + Saga/CQRS 필요. 단순 trade-off입니다."