“우리 도 MSA 로 가야죠.” — 이 말 은 세련 되게 들린다. 하지만 MSA 는 트로피 가 아니라 도구 다. 그리고 도구 를 필요 없을 때 꺼내면 손 을 벤다. 이 글 은 “언제 쪼개야 하는가” 를 비용 과 신호 로 고찰 한다.

우리도 MSA로 가야죠 — 5명 회사가 7개로 쪼갠 뒤 모든 지표가 악화 / 쪼개기 전 3가지 신호

1. MSA 는 공짜 가 아니다 — 청구서 를 먼저 보라

그림 의 사례: 개발 5 명 회사 가 모놀리스 1 개 를 서비스 7 개 로 쪼갰다. 6 개월 뒤 지표:

지표 분리 전 분리 후 6 개월
배포 단위 수 1 7
CI 빌드 시간(전체) 4 분 28 분
한 기능 추가 — 만지는 서비스 수 1 4~5
장애 평균 디버깅 시간 40 분 4 시간
신규 입사자 첫 PR 까지 3 일 3 주

전부 나빠졌다. MSA 는 분산 시스템 세금 을 물린다 — 네트워크 경계, 분산 트랜잭션, 관측 의 파편화, 배포 오케스트레이션. 이 세금 을 상쇄 할 이득 이 없으면, 순손실 이다. 5 명 팀 에게 7 개 서비스 는 한 사람 당 1.4 개 를 운영 하라는 뜻.

2. 쪼개기 전 물어야 할 3 가지 신호

그림 이 주는 진짜 교훈 은 이거다 — MSA 는 “이 신호 가 켜졌을 때” 만 답 이다.

🔴 신호 ① 팀 이 서로 막고 있나? (조직 신호)

  • A 팀 배포 를 B 팀 이 기다리고 있다면 → 코드 를 쪼개 배포 독립성 을 준다.
  • 콘웨이 의 법칙: 조직 구조 가 곧 아키텍처 다. MSA 는 사실 코드 문제 가 아니라 팀 문제 를 푸는 도구.
  • 사례 의 회사: 개발 5 명, 슬랙 채널 하나, 막힘 없음 → 신호 꺼짐.

🟡 신호 ② 한 모듈 이 폭주 하나? (부하 신호)

  • 특정 모듈 만 트래픽 이 몰려 독립 스케일링 이 필요하면 → 그 모듈 만 떼낸다.
  • 사례: 모든 서비스 부하 가 비슷 → 같이 스케일 하면 됨 → 신호 꺼짐.

🟢 신호 ③ 도메인 경계 가 정말 있나? (도메인 신호)

  • 모놀리스 에서 도 경계 를 못 긋는데 서비스 로 쪼개면 → 분산 된 진흙공(distributed monolith) 이 된다. 최악.
  • 사례: 한 트랜잭션 이 5 개 도메인 경계 를 넘나들며 터짐 → 경계 가 없다 → 신호 꺼짐.

결론: 3 신호 중 0 개 가 켜져 있었다. 분리 는 늦출 수 있는 결정 이었는데, 시점 이 너무 빨랐다. — 이게 가역성↔속도 축 그 자체다. MSA 분리 는 되돌리기 어려운 결정 이라 느리게 갔어야 했다.

3. 내 경험 — 2 개 로 쪼갰지, 7 개 가 아니다

나 도 정산 시스템 을 모놀리스 → MSA 로 전환 했다. 하지만 신호 를 보고 갈랐다:

  • 7 개 가 아니라 2 개 + 게이트웨이 — order-service(거래) / settlement-service(정산) / gateway. 딱 진짜 경계 가 있는 곳 에서만.
  • 경계 신호 가 확실 했다 — 거래 컨텍스트 와 정산 컨텍스트 는 변경 이유·주기 가 다르다(Bounded Context). 여기 는 신호 ③ 이 켜진 곳.
  • 완전 분리 대신 Read-only Projection — settlement 가 order 의 코드 를 import 하지 않으면서 같은 테이블 을 @Immutable 로 읽는다. 데이터 는 공유, 코드 는 분리. ArchUnit 으로 경계 를 자동 검증. → 분산 트랜잭션 의 세금 을 최소화 하면서 경계 는 지킴.

즉 “쪼갤 수 있다” 와 “쪼개야 한다” 는 다르다. 쪼갤 수 있는 곳 은 많지만, 쪼개야 하는 곳 은 신호 가 켜진 곳 뿐이다. (→ 정산 시스템 을 KPI 로)

4. 대안 — 모듈러 모놀리스

신호 가 애매 할 때 의 정답 은 대개 모듈러 모놀리스 다:

  • 경계 는 긋되(모듈·패키지·의존 규칙), 배포 는 하나.
  • 헥사고날/DDD 로 도메인 을 나누고, ArchUnit 으로 의존 방향 을 강제 → 코드 경계 는 MSA 급, 운영 부담 은 모놀리스 급.
  • 나중 에 진짜 신호 가 켜지면, 이미 경계 가 그어져 있으니 그때 떼내면 된다. 경계 를 코드 에 먼저, 배포 는 나중에.

“언젠가 MSA 갈 거니까 지금 쪼개자” 는 함정이다. 경계 를 명확히 해두면, 분리 는 필요할 때 싸게 할 수 있다.

결론 — MSA 는 목적 이 아니라 신호 에 대한 응답

“우리 도 MSA 로 가야죠” 에 나 는 이제 세 가지 를 되묻는다:

  1. 팀 이 서로 배포 를 막고 있나? (조직)
  2. 한 모듈 만 독립 스케일 이 필요한가? (부하)
  3. 모놀리스 에서 이미 도메인 경계 가 뚜렷한가? (도메인)

하나 도 안 켜졌다면 — 아직 이다. 모듈러 모놀리스 로 경계 만 그어두고, 신호 가 켜질 때 쪼개라. MSA 는 유행 을 따르는 결정 이 아니라, 구체적 통증 에 대한 응답 이어야 한다.

아키텍처 는 자랑 이 아니라 문제 해결 이다. 없는 문제 를 위한 MSA 는, 있는 문제 를 만든다.