경영진이 말합니다. "요즘 다 마이크로서비스라던데, 우리도 MSA로 가죠." 5명 팀이 서비스를 12개로 쪼갰습니다. 6개월 뒤, 기능 하나 바꾸려면 서비스 5개를 동시에 배포해야 하고, 장애가 나면 어느 서비스가 원인인지 추적조차 어렵습니다. 한편 다른 회사는 거대 모놀리식이 배포 30분·전체 멈춤으로 발목을 잡습니다. 아키텍처는 유행이 아니라 트레이드오프입니다. "무엇이 옳은가"가 아니라 "우리 상황에 무엇이 맞는가"를 판단해야 합니다.
- 1모놀리식과 MSA의 구조 차이와 각각의 장단점을 설명할 수 있다
- 2MSA가 떠안는 "분산의 비용"을 구체적으로 나열할 수 있다
- 3"분산 모놀리스"가 왜 최악인지 설명할 수 있다
- 4조직 규모·도메인 성숙도에 맞는 아키텍처를 판단할 수 있다
두 구조의 트레이드오프
하나로 묶기 vs 잘게 나누기
모놀리식: 하나의 배포 단위에 모든 기능
┌──────────────────────────┐
│ [주문][결제][회원][알림] │ ─ 하나의 DB
└──────────────────────────┘
+ 단순(개발·배포·디버깅), 내부 호출 빠름, 트랜잭션 쉬움
− 부분 확장 불가, 전체 재배포, 커질수록 결합도↑
MSA: 기능별 독립 서비스(각자 배포·DB)
[주문]─▶[결제] [회원] [알림]
│DB │DB │DB │DB ─ 네트워크로 통신
+ 독립 배포·부분 확장·기술 다양성·장애 격리
− 네트워크 지연/실패, 분산 트랜잭션, 운영 복잡도↑
핵심: MSA의 이점(독립 배포·부분 확장)은 공짜가 아닙니다. 네트워크·데이터 일관성·운영 복잡도라는 비용을 지불합니다. 이 비용을 감당할 [[cicd-pipeline]]·[[slo-error-budget]] 역량이 없으면 MSA는 속도를 오히려 죽입니다.
분산의 비용 — MSA가 가져오는 것
나누는 순간 생기는 새로운 문제들
서비스를 나누면 '함수 호출'이 '네트워크 호출'로 바뀌며 새로운 문제가 따라옵니다.
- 네트워크 호출: 지연·타임아웃·부분 실패. 한 요청이 여러 서비스를 거치면 실패 지점이 늘어남 → [[async-event-driven]]·재시도·서킷브레이커 필요.
- 데이터 일관성: 서비스마다 DB가 다르면 하나의 트랜잭션으로 못 묶음 → 사가(Saga)·결과적 일관성 같은 복잡한 패턴.
- 운영 복잡도: 서비스 수만큼 배포·모니터링·로그·온콜이 늘어남. 한 요청을 추적하려면 분산 추적(distributed tracing).
- 조직 정합(Conway의 법칙): 시스템 구조는 조직 구조를 닮음 → 서비스 경계가 팀 경계와 맞아야 함.
PM·인프라 관점: "MSA로 가자"는 결정은 곧 관측성·배포 자동화·온콜 체계에 대한 대규모 투자 결정입니다. 이것 없이 쪼개면 분산의 비용만 떠안습니다.
결합도 진단 — 직접 확인
MSA를 한다면 '진짜 독립적인가'를, 모놀리식이라면 '모듈 경계가 있는가'를 점검합니다. 분산 모놀리스 여부를 가리는 핵심입니다.
점검 항목:
1) 한 기능 변경 시 동시 배포해야 하는 서비스 수
→ 1개면 독립적(OK). 3개+면 강결합(분산 모놀리스 의심)
2) 여러 서비스가 같은 DB/테이블을 직접 읽고 쓰나?
→ 공유 DB = 강결합. 서비스별 DB가 MSA 원칙
3) 동기 호출 체인 깊이 (A→B→C→D)
→ 깊을수록 한 곳 지연/장애가 전체로 전파
4) 한 서비스만 독립 배포·롤백 가능한가?
→ 불가하면 나눈 의미 없음
예시 진단 결과:
"주문 변경하려면 결제·재고·알림도 같이 배포" → 강결합 ✗
"3개 서비스가 users 테이블 직접 접근" → 공유DB ✗
→ 분산 모놀리스. MSA 복잡도는 떠안고 이점은 없음
→ 처방: 경계 재설계 또는 일부 재통합
echo '서비스 의존 그래프와 DB 공유 여부 확인'- 한 기능 변경에 여러 서비스 동시 배포가 필요하면 → 분산 모놀리스 신호. 나눴는데 독립 배포가 안 되면 나눈 이점이 0
- 여러 서비스가 같은 테이블을 직접 접근하면 → 공유 DB 강결합. 한 서비스가 스키마 바꾸면 다른 서비스가 깨짐. 서비스별 DB로 경계를 다시 긋는다
- 동기 호출 체인이 깊으면(A→B→C→D) → 끝단 한 곳의 지연이 전체 응답시간·장애로 전파. 비동기([[async-event-driven]])나 호출 단순화 검토
- 모놀리식이라도 내부 모듈 경계(패키지/도메인)가 없으면 → 나중에 분리 불가능한 "빅볼오브머드". 경계는 모놀리식 안에서도 미리 그어둔다
상황: 5~6명 팀이 유행을 좇아 서비스를 10개 넘게 쪼갰습니다. 이제 작은 기능 하나도 여러 레포·여러 배포를 거쳐야 하고, 장애 시 어느 서비스가 원인인지 추적이 안 되며, 인프라 운영(10개 파이프라인·모니터링·온콜)이 팀을 압도합니다.
원인: 조직 역량과 도메인 성숙도를 초과한 분할입니다. MSA의 이점(독립 배포·팀 자율성)은 '서비스마다 다른 팀이 소유'할 만큼 조직이 클 때 나오는데, 작은 팀에선 한 사람이 여러 서비스를 오가며 분산의 비용만 떠안습니다. Conway 법칙상 6명에게 12개 서비스는 부정합입니다.
진단:
□ 서비스 수 > 팀원 수인가? (소유 불가 신호)
□ 도메인 경계가 6개월 새 여러 번 바뀌었나? (경계 미성숙)
□ 분산 추적·중앙 로그·자동 배포가 갖춰졌나? (없으면 MSA 운영 불가)
해결: 재통합(merge back) 을 두려워하지 않습니다. 강결합된 서비스들을 다시 모놀리식(또는 모듈러 모놀리스)으로 합쳐 단순함을 되찾고, 정말 독립이 필요한 부분(예: 트래픽 폭주하는 결제)만 선택적으로 분리합니다. "Monolith First, 필요할 때 분리"가 대부분의 팀에 맞는 경로입니다. 아키텍처 결정은 유행이 아니라 조직 역량에 맞춰야 합니다.
인프라/SRE로서 아키텍처 선택은 당신의 운영 부담을 직접 결정합니다 — MSA는 서비스 수만큼의 파이프라인·모니터링·온콜·분산추적(Jaeger 등)을 요구하므로, "MSA로 가자"는 결정에 반드시 그 운영 투자를 함께 견적해 의사결정에 올려야 합니다. 분산 모놀리스(공유 DB·동기 호출 체인)를 발견하면 경계 재설계를 제안하는 것도 SRE의 역할입니다. PM은 아키텍처를 '기술팀만의 결정'으로 두지 말고, 그것이 팀 구조(Conway)·배포 속도·운영 비용에 미치는 영향을 이해해 함께 판단해야 합니다. 가장 비싼 실수는 '필요하지도 않은 복잡도'를 일찍 들이는 것입니다.
다음 모듈에서는 이 서비스들(또는 프론트-백엔드)이 서로 대화하는 규약 — API와 계약을 다룹니다.