MSA 마이크로서비스 언제 도입하나: 모놀리스 안 부수는 기준 [2026]
MSA는 비즈니스 경계로 서비스를 분리한 아키텍처입니다. 너무 일찍 도입하면 망가지는 이유, 도입 신호 6가지, 모놀리스·모듈러 모놀리스·MSA 비교와 스트랭글러 전환 전략을 정리했습니다.
이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스
MSA 도입 시점은 트래픽이나 개발자 수 하나로 정할 수 없습니다. 독립 배포가 필요한 비즈니스 경계가 실제로 존재하고, 팀이 API·데이터 소유권·비동기 실패·관찰성·보안·당직을 운영할 수 있으며, 모놀리스의 변경 충돌 비용이 분산 시스템의 고정비보다 클 때 검토합니다. 대부분은 먼저 모듈러 모놀리스와 자동화된 배포·관찰성을 갖추는 편이 안전합니다.
서비스를 많이 쪼개면 코드 저장소 경계는 생기지만 업무 경계가 명확해지는 것은 아닙니다. 여러 서비스가 같은 데이터베이스 테이블을 수정하거나 한 기능 배포에 모두 함께 바뀌면 네트워크만 추가된 분산 모놀리스가 됩니다. 독립성은 이름이 아니라 변경·데이터·배포·장애의 실제 책임으로 증명해야 합니다.
MSA의 비용은 컨테이너 수보다 계약 버전, 인증, 서비스 간 지연, 재시도 중복, 데이터 일관성, 추적, 테스트 환경, 온콜과 플랫폼 팀에 있습니다. 이 운영 능력이 없으면 작은 기능 변경도 여러 팀과 장애 지점을 거치며 더 느려질 수 있습니다.
독립 변경·확장·장애 격리의 반복 증거가 있을 때 경계를 추출한다#
추상적 미래보다 최근 변경과 사고에서 실제 결합 비용을 측정합니다.
| 신호 | 확인 질문 | 필요 증거 | 성급한 신호 |
|---|---|---|---|
| 변경 | 한 영역 변경이 다른 릴리스를 막는가 | 배포 대기·충돌 이력 | 코드가 커 보임 |
| 확장 | 특정 부하만 독립 확장해야 하나 | 자원·트래픽 프로필 | 전체 트래픽 증가 |
| 장애 | 한 영역 실패를 격리할 가치가 큰가 | 사고 영향·복구 목표 | 서비스 수가 적음 |
| 조직 | 팀이 제품 경계를 끝까지 소유하나 | 온콜·SLO·플랫폼 역량 | 개발자 수 증가 |
모놀리스·모듈러 모놀리스·서비스 추출을 같은 품질 기준으로 비교한다#
가장 복잡한 구조가 아니라 현재 문제를 푸는 가장 작은 운영 책임을 선택합니다.
| 선택 | 잘 맞는 상태 | 필수 규율 | 퇴출·전환 증거 |
|---|---|---|---|
| 모놀리스 | 작은 팀·빠른 학습 | 테스트·배포·모듈 규칙 | 프로파일·의존성 지도 |
| 모듈러 모놀리스 | 업무 경계는 있으나 독립 운영 불필요 | 모듈 API·데이터 접근 제한 | 경계 위반 검사 |
| 선택적 추출 | 특정 변경·부하·격리 요구 | 계약·데이터 소유·관찰 | 트래픽 단계 전환 |
| 다중 서비스 | 여러 자율 팀·성숙한 플랫폼 | SLO·보안·온콜·비용 | 서비스별 독립 복구 |
실무 시나리오: 주문 타임아웃 재시도로 결제와 포인트가 중복 처리됐다#
호출자는 응답을 못 받아 재시도했지만 하위 서비스는 첫 요청을 이미 실행한 상황을 가정합니다.
| 단계 | 확인 질문 | 복구 조치 | 종료 증거 |
|---|---|---|---|
| 차단 | 어떤 명령·소비자가 계속 재시도하나 | 재시도 중지·큐 격리 | 추가 중복 없음 |
| 재구성 | 주문·결제·포인트 사건 순서는 | 추적 ID·멱등 키·원장 대조 | 영향 거래 확정 |
| 보상 | 어떤 원거래를 반전해야 하나 | 승인된 취소·포인트 조정 | 고객·회계 원장 일치 |
| 재발 방지 | 왜 전달과 실행을 혼동했나 | 멱등 수신·outbox·상태 조회 | 지연·중복 시험 통과 |
공식 클라우드 아키텍처 지침과 관찰성 표준을 운영 책임에 연결한다#
Microsoft Azure Architecture Center와 AWS Prescriptive Guidance는 마이크로서비스의 경계·데이터·통신·운영 패턴과 트레이드오프를 설명합니다. OpenTelemetry는 분산 추적·메트릭·로그를 수집·전달하는 벤더 중립 관찰성 프레임워크입니다. 이 지침들은 MSA가 특정 조직에 적합하거나 성능·가용성이 자동 개선된다고 보장하지 않으며 실제 변경·장애 비용과 팀 역량으로 판단해야 합니다.
- Microsoft Microservices architecture style: 서비스 경계·데이터·통신·운영 트레이드오프
- AWS Decomposing monoliths guidance: 모놀리스 분해 전략과 패턴의 공식 지침
- OpenTelemetry documentation: 분산 시스템의 추적·메트릭·로그 관찰성 표준
서비스 수보다 계약·데이터·SLO·배포·당직의 소유권을 운영한다#
먼저 모놀리스의 빌드·테스트·배포 시간, 변경 충돌, 장애 영향, 특정 부하와 팀 의존성을 계측합니다. 업무 이벤트와 결정 권한을 기준으로 모듈 경계를 만들고 다른 모듈의 테이블을 직접 읽고 쓰는 경로를 제거합니다. 이 단계만으로 문제가 해결되면 서비스 추출을 보류합니다.
추출 후보는 독립 데이터 소유권과 API·이벤트 계약, 버전 호환 기간, 오류·타임아웃·재시도·중복·순서 역전 처리, 인증·권한, SLO와 비용을 정의합니다. 분산 트랜잭션을 숨기지 않고 불변 원장·outbox·멱등 소비자·보상 거래와 대사로 설계합니다.
트래픽은 그림자 읽기, 일부 사용자, 일부 쓰기 순으로 전환하고 옛 경로와 결과를 비교합니다. 서비스·배포·비밀·대시보드·알람·런북에는 실제 팀 소유자를 둡니다. 호출 그래프·지연·오류 예산·단위 비용을 검토해 이점이 없는 서비스는 다시 합칠 수 있어야 합니다.
서비스 분리 전 외주·내부 팀 책임은 SI와 인하우스 개발팀 비교에서 확인하세요. 레거시 전환의 예산 우선순위는 IT 예산 편성 가이드를 함께 보세요. 안전한 개발·인수 검수는 외주 개발 검수 체크리스트도 참고할 수 있습니다.
독립 배포·데이터 소유·부분 장애·중복 처리·롤백을 증명하면 승인한다#
검수에는 계약 구버전 호출, 느린 하위 서비스, 응답 유실, 메시지 중복·순서 역전, 데이터 지연, 인증서·비밀 교체를 포함합니다. 한 서비스 배포와 장애가 약속된 경계 안에 머물고 거래 상태는 추적 ID와 원장으로 재현돼야 합니다.
전환 전 피크 부하, 카나리·롤백, 큐 적체, 백업 복원, 리전 또는 핵심 의존성 장애와 온콜 인계를 훈련합니다. 회사 계정에서 저장소·파이프라인·인프라·스키마·계약·관찰성·런북을 인수하고 대체 팀이 한 서비스를 독립 배포·복구해야 합니다.
핵심 요약
- ✓MSA는 변경·확장·장애 격리 이득이 분산 시스템 고정비보다 클 때 도입한다
- ✓먼저 모듈러 모놀리스·자동 배포·관찰성·팀 소유권을 갖춘다
- ✓서비스는 독립 데이터·계약·SLO·당직과 복구 책임으로 경계를 증명한다
- ✓타임아웃·중복·순서 역전은 멱등·outbox·보상·대사로 처리한다
- ✓선택적 추출·단계 트래픽·롤백을 거치고 이점 없는 서비스는 다시 합친다
자주 묻는 질문