¶ 10권 — 모놀리식에서 MSA로: 아키텍처 전환 판단과 설계
서비스가 성장하면 조직은 반드시 "이제 마이크로서비스로 가야 하는가"라는 질문과 마주하게 된다. 이 질문에 대한 답은 유행이 아니라 실제로 관찰되는 마찰 신호와 조직의 준비 상태로 판단해야 한다.
이 책은 그 판단 기준부터 실제 분리 원칙, 점진적 전환 전략, 서비스 간 통신 설계까지 하나의 흐름으로 다룬다.
¶ 모놀리식 한계의 신호 — 무엇을 관찰해야 하는가
전환의 근거는 코드 크기가 아니라 그 크기가 만드는 마찰이다. 대표적인 신호는 다섯 가지다.
- 배포 결합 — 한 팀의 작은 기능 배포를 위해 전체 애플리케이션을 다시 빌드·테스트해야 하고, 한 팀의 실수가 무관한 팀의 배포까지 막는 상태
- 조직 경계와 코드 경계의 불일치
- 스케일링 요구의 불균일성
- 기술 스택의 획일적 강제
- 온보딩 시간 증가
반대로 "다들 쓰니까", "코드 줄 수가 많다", "팀이 작다"는 신호가 아니다. 팀 규모가 작다면 분산 시스템 운영 부담(네트워크 장애 처리, 분산 트레이싱, 다중 배포 파이프라인)을 감당하기 어렵기 때문에 처음부터 마이크로서비스로 시작하는 것은 오히려 위험하다는 것이 MonolithFirst 원칙의 핵심이다.
¶ 전환 여부를 가르는 판단 기준
신호를 확인했다면 세 가지 질문으로 판단을 좁힌다.
- 도메인 경계가 이미 드러나 있는가
- 조직이 이 복잡도를 감당할 준비가 되어 있는가 — 서비스별 배포 파이프라인·온콜 체계, 분산 트레이싱·중앙집중 로깅, 데이터 일관성 확보 전략이 함께 따라와야 한다
- 비용 대비 이득이 명확한가
이 세 질문에 다수 "아니오"가 나온다면 전환보다 모놀리식 내부 모듈화가 우선이다.
¶ 서비스 분리 원칙 — 도메인 주도 설계(DDD)의 기초
전환을 결정했다면 "어디서 자를 것인가"가 남는다. 핵심 기준이 바운디드 컨텍스트(Bounded Context) 개념으로, 하나의 모델이 내부적으로 일관되려면 적용 범위를 명시적으로 한정해야 한다.
실무 절차는 다음 네 단계를 제안한다.
- 이벤트 스토밍으로 업무 이벤트를 시간순 나열
- 용어 충돌 지점 찾기
- 각 컨텍스트를 소유할 팀 매핑
- 데이터 소유권 확인
가장 흔한 실패는 도메인이 아니라 기술 계층이나 데이터 테이블 단위로 나누는 것으로, 이는 "분산 모놀리식"을 낳는다.
¶ 점진적 전환 전략 — Strangler Fig 패턴
경계를 정했다면 "어떻게 옮길 것인가"다. Strangler Fig 패턴은 기존 시스템을 감싸고 기능 단위로 트래픽을 새 서비스로 점진 리디렉션하는 방식으로, 전면 재작성이 안는 위험을 피한다.
실무 단계는 다음과 같다.
- 기능 식별(위험 낮고 경계가 뚜렷한 것부터)
- 파사드/라우팅 계층 도입
- 기능 이관 및 검증
- 트래픽 전환
- 기존 코드 제거
- 다음 기능으로 반복
¶ 서비스 간 통신 방식과 데이터 소유권 분리 원칙
서비스를 나눈 뒤에는 통신 방식을 정해야 한다.
| 방식 | 특징 |
|---|---|
| 원격 프로시저 호출(RPI, REST/gRPC) | 즉시 응답이 필요한 상호작용에 적합하지만 강한 런타임 결합을 만든다 |
| 메시징(비동기) | 느슨한 결합을 제공한다 |
데이터 소유권은 "Database per Service" 원칙에 따라 각 서비스가 자신의 데이터베이스를 전용 소유해야 한다. 이렇게 분리하면 여러 서비스에 걸친 트랜잭션 일관성은 이벤트 발행·구독을 통한 최종적 일관성(eventual consistency)으로 해결한다.
¶ 핵심 포인트 — 아키텍처는 조직 구조를 따라간다
책 전체를 관통하는 원리는 콘웨이의 법칙(Conway's Law)이다. 시스템을 설계하는 조직은 필연적으로 그 조직의 의사소통 구조를 복사한 설계를 만들어낸다는 관찰로, 서비스 경계는 기술적 편의가 아니라 이를 소유할 팀의 경계와 일치해야 함을 뒷받침한다.
원하는 아키텍처가 먼저 있고 팀 구조가 이를 가로막는다면, 코드보다 팀 구조를 먼저 재편하는 "역(逆) 콘웨이 전략"도 고려할 수 있다. 결국 MSA 전환은 코드 리팩터링이 아니라 조직 설계 프로젝트에 가깝다.
¶ 참고할 만한 사례
배달의민족(우아한형제들)의 회원시스템 이벤트 기반 아키텍처 전환, 당근마켓의 회원 시스템 MSA 순차 마이그레이션, Amazon의 2000년대 초 SOA 전환, Netflix의 2008년 장애를 계기로 한 7년간의 마이크로서비스 전환 사례가 소개된다.
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.