경영진이 말합니다. "요즘 다 마이크로서비스라던데, 우리도 MSA로 가죠." 5명 팀이 서비스를 12개로 쪼갰습니다. 6개월 뒤, 기능 하나 바꾸려면 서비스 5개를 동시에 배포해야 하고, 장애가 나면 어느 서비스가 원인인지 추적조차 어렵습니다. 한편 다른 회사는 거대 모놀리식이 배포 30분·전체 멈춤으로 발목을 잡습니다. 아키텍처는 유행이 아니라 트레이드오프입니다. "무엇이 옳은가"가 아니라 "우리 상황에 무엇이 맞는가"를 판단해야 합니다.
- 1모놀리식과 MSA의 구조 차이와 각각의 장단점을 설명할 수 있다
- 2MSA가 떠안는 "분산의 비용"을 구체적으로 나열할 수 있다
- 3"분산 모놀리스"가 왜 최악인지 설명할 수 있다
- 4조직 규모·도메인 성숙도에 맞는 아키텍처를 판단할 수 있다
확대
위 그림처럼 모놀리스는 초기 개발이 빠르지만 팀이 커질수록 충돌이 늘고, MSA는 독립 배포가 가능한 대신 운영 복잡도가 따릅니다.
두 구조의 트레이드오프
하나로 묶기 vs 잘게 나누기
핵심: MSA의 이점(독립 배포·부분 확장)은 공짜가 아닙니다. 네트워크·데이터 일관성·운영 복잡도라는 비용을 지불합니다. 이 비용을 감당할 CI/CD 파이프라인·SLO·에러버짓·포스트모템 역량이 없으면 MSA는 속도를 오히려 죽입니다.
분산의 비용 — MSA가 가져오는 것
나누는 순간 생기는 새로운 문제들
서비스를 나누면 '함수 호출'이 '네트워크 호출'로 바뀌며 새로운 문제가 따라옵니다.
- 네트워크 호출: 지연·타임아웃·부분 실패. 한 요청이 여러 서비스를 거치면 실패 지점이 늘어남 → 동기 vs 비동기·재시도·서킷브레이커 필요.
- 데이터 일관성: 서비스마다 DB가 다르면 하나의 트랜잭션으로 못 묶음 → 사가(Saga)·결과적 일관성 같은 복잡한 패턴.
- 운영 복잡도: 서비스 수만큼 배포·모니터링·로그·온콜이 늘어남. 한 요청을 추적하려면 분산 추적(distributed tracing).
- 조직 정합(Conway의 법칙): 시스템 구조는 조직 구조를 닮음 → 서비스 경계가 팀 경계와 맞아야 함.
PM·인프라 관점: "MSA로 가자"는 결정은 곧 관측성·배포 자동화·온콜 체계에 대한 대규모 투자 결정입니다. 이것 없이 쪼개면 분산의 비용만 떠안습니다.
확대
위 그림처럼 레이어드 아키텍처는 관심사를 3계층으로 분리해, 비즈니스 로직을 재사용하고 DB 교체 시 Data Layer만 수정할 수 있습니다.
결합도 진단 — 직접 확인
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) → 끝단 한 곳의 지연이 전체 응답시간·장애로 전파. 비동기(동기 vs 비동기)나 호출 단순화 검토
- 모놀리식이라도 내부 모듈 경계(패키지/도메인)가 없으면 → 나중에 분리 불가능한 "빅볼오브머드". 경계는 모놀리식 안에서도 미리 그어둔다
상황: 5~6명 팀이 유행을 좇아 서비스를 10개 넘게 쪼갰습니다. 이제 작은 기능 하나도 여러 레포·여러 배포를 거쳐야 하고, 장애 시 어느 서비스가 원인인지 추적이 안 되며, 인프라 운영(10개 파이프라인·모니터링·온콜)이 팀을 압도합니다.
원인: 조직 역량과 도메인 성숙도를 초과한 분할입니다. MSA의 이점(독립 배포·팀 자율성)은 '서비스마다 다른 팀이 소유'할 만큼 조직이 클 때 나오는데, 작은 팀에선 한 사람이 여러 서비스를 오가며 분산의 비용만 떠안습니다. Conway 법칙상 6명에게 12개 서비스는 부정합입니다.
진단:
□ 서비스 수 > 팀원 수인가? (소유 불가 신호)
□ 도메인 경계가 6개월 새 여러 번 바뀌었나? (경계 미성숙)
□ 분산 추적·중앙 로그·자동 배포가 갖춰졌나? (없으면 MSA 운영 불가)
해결: 재통합(merge back) 을 두려워하지 않습니다. 강결합된 서비스들을 다시 모놀리식(또는 모듈러 모놀리스)으로 합쳐 단순함을 되찾고, 정말 독립이 필요한 부분(예: 트래픽 폭주하는 결제)만 선택적으로 분리합니다. "Monolith First, 필요할 때 분리"가 대부분의 팀에 맞는 경로입니다. 아키텍처 결정은 유행이 아니라 조직 역량에 맞춰야 합니다.
확대
위 그림처럼 동기 호출은 강결합으로 한 서비스 장애가 전파되지만, 이벤트드리븐은 메시지 브로커를 통해 장애를 격리합니다.
심화 — 쪼개는 기술: 경계는 코드가 아니라 데이터에서 갈린다
심화: 모놀리스에서 서비스를 떼어내는 실제 순서 — 코드 분리는 쉬운 절반이다
"필요해지면 떼어내면 된다"까지 판단했다면, 다음 질문은 "그래서 실제로 어떻게 떼어내나"입니다. 여기서 대부분의 팀이 놀라는 지점은 코드가 아니라 데이터입니다.
- 코드 분리보다 데이터 분리가 훨씬 어렵습니다: 모놀리스 안에서 JOIN 한 줄이던 것이, 서비스를 나누면 네트워크 왕복 N번이 됩니다. 하나의 트랜잭션으로 묶이던 "주문 저장 + 재고 차감"은 사가와 보상 트랜잭션으로 풀어야 합니다. 어떤 테이블을 어느 서비스가 소유하는가 — 이 소유권 정리가 분리 작업의 본체입니다.
- Strangler 패턴의 실제 동작: 기존 모놀리스 앞에 프록시/게이트웨이를 세우고, 경로 단위로 트래픽을 새 서비스로 옮깁니다.
/orders만 새 서비스로, 나머지는 모놀리스로. 옮긴 경로가 안정되면 다음 경로로 — 실패하면 라우팅만 되돌리면 됩니다. 단, 이 라우팅 계층 자체가 새로운 단일 장애점이자 크리티컬 인프라가 된다는 비용이 따릅니다. - 전환기의 이중 상태: 옮기는 동안 데이터가 양쪽에 존재하는 기간이 생깁니다. 이중 쓰기(dual write)는 한쪽만 성공하는 순간 불일치를 만들므로, 한쪽을 원본으로 정하고 다른 쪽은 동기화로 따라가게 하는 설계가 필요합니다.
- 중간 단계로서의 모듈러 모놀리스: 배포는 하나로 유지하되 내부를 도메인 모듈로 엄격히 나누고 모듈 간 직접 참조를 금지하는 구조입니다. 서비스 경계를 배포를 쪼개기 전에 검증할 수 있습니다 — 경계가 틀렸으면 리팩터링으로 고치면 되지, 네트워크를 되돌릴 필요가 없습니다.
즉 "모놀리식 → MSA"는 스위치가 아니라 경로입니다. 그리고 그 경로의 난이도는 코드 구조가 아니라 데이터 소유권과 트랜잭션 경계가 결정합니다.
상황: "이 레거시는 손댈 수 없으니 처음부터 새로 만들자"며 MSA 기반 전면 재작성(big rewrite)을 시작했습니다. 기존 모놀리스는 기능 동결. 그런데 18개월이 지나도 새 시스템은 기존 기능을 다 따라잡지 못했고, 그 사이 경쟁사와 기능 격차가 벌어지며 프로젝트 중단 압박이 커집니다.
원인: 재작성 대상이 움직이는 목표물임을 간과했습니다. 기존 시스템에는 수년간의 예외 처리·엣지 케이스가 문서 없이 녹아 있어 "따라잡기"의 분모 자체가 추정보다 훨씬 크고, 동결했다는 기존 시스템에도 긴급 수정은 계속 들어가 목표가 계속 이동합니다. 빅뱅 전환은 "완성 전까지 아무 가치도 배포되지 않는" 구조라, 늦어질수록 매몰비용만 쌓입니다.
진단:
□ 새 시스템이 '전부 완성'되기 전까지 사용자에게 전달되는 가치가 0인가? (빅뱅 신호)
□ 기존 시스템의 기능 목록을 실제로 산정했나, 아니면 "몇 달이면 되겠지"였나?
□ 동결 기간에도 기존 시스템에 수정이 계속 들어가고 있나? (목표물 이동)
해결: 재작성을 중단하고 점진 전환(Strangler) 으로 방향을 바꿉니다 — 프록시를 앞에 세우고, 가장 가치 있는 경로 하나부터 새 서비스로 옮겨 몇 주 단위로 가치를 배포합니다. 옮길 때마다 라우팅 전환으로 검증하고, 문제가 생기면 되돌립니다. 기존 모놀리스는 '버릴 코드'가 아니라 전환이 끝날 때까지의 기능 명세이자 안전망입니다. 전면 재작성이 정당화되는 경우는 드뭅니다 — 대부분의 "손댈 수 없는 레거시"는 사실 "경계를 그어가며 조금씩 옮길 수 있는 레거시"입니다.
인프라/SRE로서 아키텍처 선택은 당신의 운영 부담을 직접 결정합니다 — MSA는 서비스 수만큼의 파이프라인·모니터링·온콜·분산추적(Jaeger 등)을 요구하므로, "MSA로 가자"는 결정에 반드시 그 운영 투자를 함께 견적해 의사결정에 올려야 합니다. 분산 모놀리스(공유 DB·동기 호출 체인)를 발견하면 경계 재설계를 제안하는 것도 SRE의 역할입니다. PM은 아키텍처를 '기술팀만의 결정'으로 두지 말고, 그것이 팀 구조(Conway)·배포 속도·운영 비용에 미치는 영향을 이해해 함께 판단해야 합니다. 가장 비싼 실수는 '필요하지도 않은 복잡도'를 일찍 들이는 것입니다.
다음 모듈에서는 이 서비스들(또는 프론트-백엔드)이 서로 대화하는 규약 — API와 계약을 다룹니다.
실전 랩으로 손에 익히기: 아키텍처 선택 실습 — 팀·도메인·규모로 모놀리식/모듈러/MSA를 고르고 분해 경계를 판단합니다.
관련 모듈로 더 깊이:
- API와 계약 — 서비스들이 서로 대화하는 규약(API 계약)을 정의하는 법
- 동기 vs 비동기 — 동기 호출 대신 이벤트로 느슨하게 결합하는 아키텍처
- 12-Factor App — 어떤 아키텍처든 환경에 흔들리지 않게 만드는 설계 원칙