MSA는 왜 도입하는가 — 모놀리스가 무너지는 시점

“MSA로 쪼개면 배포가 빨라지겠지”라는 생각으로 전환을 시작한 팀은 종종 운영 복잡도만 3배가 된 분산 모놀리스를 손에 들게 된다. MSA가 실제로 무엇을 해결하는 구조인지 이해하지 못하면, 아키텍처를 바꿔도 원래 문제는 그대로 남는다. 모놀리스는 정확히 어느 지점에서 무너지는가?

모놀리스가 한계를 드러내는 순간

모놀리스의 병목은 코드 품질이 아니라 구조적 결합에서 온다. 팀 A의 기능 배포를 위해 팀 C의 준비를 기다려야 한다. 긴급 핫픽스를 배포하면 전체 코드가 함께 나간다. 주문 서비스에만 트래픽이 몰려도 회원·상품 서비스까지 통째로 복제해야 한다. ML 모델 서빙에 Python이 필요하지만 Spring 모놀리스 안에 억지로 끼워야 한다.

이 네 가지 — 독립 배포 불가, 확장 비효율, 기술 스택 종속, 팀 결합도 — 가 실제로 병목으로 느껴지기 시작할 때가 MSA를 고려할 시점이다. 팀이 10명 미만이거나 도메인 경계가 아직 불명확하다면, 이 신호는 아직 오지 않은 것이다.

서비스 경계를 어디서 긋느냐가 80%다

경계를 잘못 그으면 이후 모든 것이 뒤틀린다. 가장 흔한 실수는 CRUD 단위로 쪼개는 것이다. OrderCreateService, OrderReadService, OrderUpdateService로 나누면 주문 생성이 주문 조회를 HTTP로 호출하게 되고, 트랜잭션 경계가 네트워크를 가로지른다.

올바른 분해 기준은 Bounded Context — 동일한 언어와 모델이 일관되게 사용되는 경계다. “상품(Product)“은 주문 컨텍스트에서는 orderedPrice 스냅샷이고, 배송 컨텍스트에서는 weight와 size다. 같은 이름이지만 필요한 속성이 다르다. 컨텍스트마다 자신에게 필요한 속성만 복사하여 소유하는 것이 분산 시스템에서의 올바른 데이터 전략이다.

경계 검증은 두 질문으로 압축된다. “팀이 이 서비스만 독립적으로 배포할 수 있는가?” 그리고 “이 서비스의 DB 스키마 변경이 다른 서비스 코드를 수정하게 만드는가?” 두 번째 질문에 “예”라고 답한다면, 그 경계는 다시 그어야 한다.

분산 모놀리스 — 두 아키텍처의 최악

서비스를 물리적으로 나눴지만 데이터와 배포가 여전히 결합된 상태가 분산 모놀리스다. 세 가지 안티패턴이 이를 만들어낸다.

Shared Database: 주문 서비스의 스키마를 변경하면 결제 서비스의 JOIN 쿼리가 깨진다. 모든 팀이 스키마 변경 전에 미팅을 열고 동시 배포를 조율한다. 모놀리스와 완전히 동일한 배포 결합이다.

동기 호출 체인: 각 서비스의 가용성이 99.9%여도, 5단계 직렬 호출 체인의 전체 가용성은 $0.999^5 \approx 99.5\%$다. 월 219분의 다운타임. 체인의 끝에 있는 배송 서비스가 3초 응답 지연을 보이면, 스레드 풀이 순서대로 소진되며 전체 시스템이 마비된다.

배포 순서 의존성: 주문 서비스 응답에 필드를 추가하면 결제 서비스가 파싱 에러를 낸다. 결제 서비스 먼저 배포, 주문 서비스 배포, 결제 서비스 재배포 — 세 번의 조율된 배포가 필요하다.

Conway’s Law와 팀 구조

MSA 전환은 기술 결정이 아니라 조직 결정이다. Melvin Conway는 1967년에 말했다: “시스템 설계는 그것을 만든 조직의 커뮤니케이션 구조를 닮는다.” 기능별 팀(프론트팀/백엔드팀/DB팀)이 MSA로 전환하면, 서비스 경계를 같은 팀원이 넘나들며 분산 모놀리스를 만든다.

Inverse Conway Maneuver — 원하는 아키텍처에 맞게 먼저 팀을 재구성하라. 주문팀·결제팀·배송팀이 각자의 서비스를 독립적으로 소유하면, 팀 경계가 곧 서비스 경계가 된다.

팀 규모별 권장 선택도 여기서 나온다. 10명 미만이면 모놀리스, 10~50명이면 모듈러 모놀리스, 50명 이상에 도메인별 팀 구조가 갖춰졌을 때 MSA를 검토한다. 대부분의 경우 “모듈러 모놀리스로 시작 → Strangler Fig로 점진 전환”이 Big Bang 전환보다 안전하다.

서비스 자율성 — 진짜 MSA의 기준

서비스를 물리적으로 분리하는 것만으로는 충분하지 않다. 자율성은 네 차원에서 동시에 달성돼야 한다.

• 독립 배포: 다른 팀에 공지 없이 언제든 단독 배포 가능
• 독립 확장: 트래픽이 몰리는 서비스만 스케일아웃, 나머지는 그대로
• 기술 자율성: 서비스 내부 기술 스택을 자유롭게 선택
• 데이터 자율성: 서비스가 자신의 DB를 단독 소유하고 다른 서비스는 API로만 접근

정리

• 모놀리스가 무너지는 지점은 배포 결합·확장 비효율·팀 결합이 실제 병목으로 느껴질 때다. 그 전에는 모놀리스가 더 나은 선택이다.
• 서비스 경계는 Bounded Context 기준으로 그어야 한다. CRUD 단위 분해는 분산 모놀리스의 출발점이다.
• 분산 모놀리스는 Shared DB, 동기 호출 체인, 배포 순서 의존성 세 안티패턴으로 만들어진다. 가용성 공식 $0.999^N$을 기억하라.
• Conway’s Law에 따라 팀 구조 없이 아키텍처만 바꾸면 원래로 돌아간다. 조직을 먼저 바꾸거나, Strangler Fig로 점진적으로 전환하라.

다음 글에서는 서비스 간 통신 방식 — 동기 REST와 비동기 이벤트의 선택 기준과 트레이드오프를 다룬다.