MSA 도입 기준을 볼 때 가장 먼저 물어야 할 것은 “서비스를 몇 개로 나눌까”가 아닙니다. “나눴을 때 운영할 준비가 되어 있는가”입니다.
마이크로서비스는 멋진 구조처럼 보이지만, 시스템을 나누면 코드만 나뉘는 것이 아닙니다. 배포, 장애 추적, 데이터 일관성, 테스트, 팀 책임도 함께 나뉩니다.
Martin Fowler의 Microservices와 Monolith First 글을 바탕으로, MSA가 과한 선택이 되는 지점을 정리하겠습니다.
MSA 도입 전에 먼저 확인할 것
MSA 도입 기준은 독립 배포 필요성에서 시작한다
마이크로서비스의 중요한 장점은 서비스별 독립 배포입니다. 결제 서비스만 바꾸고 주문 서비스는 그대로 두거나, 검색 서비스만 따로 확장하는 식의 운영이 가능해집니다. 코드 경계를 나누는 기본 감각은 추상 클래스와 인터페이스 차이 글의 설계 관점과도 연결됩니다.
하지만 독립 배포가 실제로 필요하지 않다면, 서비스 분리는 오히려 비용이 됩니다. 한 팀이 한 애플리케이션을 함께 고치고 함께 배포하는 상황에서는 모듈화된 모놀리식이 더 빠르고 단순할 수 있습니다.
도메인 경계가 불안정하면 나누기 어렵다
MSA는 서비스 경계가 곧 팀과 데이터의 경계가 되기 쉽습니다. 그런데 제품 초기에는 도메인 개념이 자주 바뀝니다. 주문과 결제, 쿠폰, 정산의 책임이 계속 바뀌는 상황에서 서비스를 너무 빨리 나누면, 경계를 옮기는 비용이 커집니다.
Monolith First 관점은 여기서 실용적입니다. 처음에는 모놀리식으로 시작하되 내부 모듈 경계를 잘 잡고, 실제로 변하지 않는 경계가 보일 때 분리하는 방식입니다.
도메인 경계가 안정됐다는 말은 회의에서 이름만 정했다는 뜻이 아닙니다. 장애가 나도 어느 팀이 책임질지, 데이터 정합성 문제가 생겼을 때 어느 서비스가 기준인지, 기능 변경이 있을 때 어느 배포가 필요한지 반복해서 확인됐다는 뜻에 가깝습니다.
MSA가 과한 신호
- 서비스는 여러 개인데 배포는 항상 한꺼번에 한다
- 장애가 나면 어느 서비스 문제인지 추적하기 어렵다
- 데이터베이스는 하나인데 서비스만 억지로 나눴다
- 팀은 하나인데 서비스 소유권만 복잡해졌다
- 로컬 개발 환경을 띄우는 것만으로 시간이 많이 든다
이런 신호가 보이면 MSA가 문제를 푸는 것이 아니라 새로운 문제를 만들고 있을 가능성이 큽니다.
운영 체계가 없으면 작은 서비스가 더 위험하다
서비스가 하나일 때는 로그 한 곳, 배포 한 번, DB 하나만 봐도 많은 문제를 추적할 수 있습니다. 서비스가 여러 개로 나뉘면 요청 하나가 여러 프로세스와 네트워크를 지나갑니다.
이때 tracing, metrics, 중앙 로그, 알림 기준, 장애 대응 절차가 없으면 문제를 찾는 시간이 길어집니다. MSA는 코드 구조가 아니라 운영 구조까지 함께 바꾸는 선택입니다.
- 요청이 어떤 서비스들을 지나갔는지 추적할 수 있는가
- 서비스별 에러율과 지연 시간을 볼 수 있는가
- 배포 실패 시 빠르게 되돌릴 수 있는가
- 계약 변경이 다른 팀에 어떻게 전달되는가
데이터 분리는 가장 늦게 어려워진다
처음에는 서비스만 나누고 DB는 공유해도 괜찮아 보일 수 있습니다. 하지만 시간이 지나면 서비스 경계보다 DB 테이블 의존성이 더 강한 결합이 됩니다.
진짜 MSA에 가까워지려면 각 서비스가 자기 데이터를 소유해야 합니다. 그러면 조인 대신 API 호출이나 이벤트가 필요해지고, 일관성도 한 트랜잭션이 아니라 eventual consistency 관점으로 봐야 할 수 있습니다.
이 준비가 되어 있지 않다면 서비스만 나누는 것보다 모듈화된 모놀리식 안에서 데이터 소유권과 경계를 먼저 정리하는 편이 낫습니다.
현실적인 전환 순서
MSA를 목표로 하더라도 처음부터 모든 것을 쪼갤 필요는 없습니다. 오히려 경계를 확인하는 순서가 더 중요합니다.
- 먼저 모놀리식 내부의 모듈 경계를 정리한다
- 모듈 간 직접 참조를 줄이고 API처럼 호출 지점을 명확히 만든다
- 데이터 소유권을 문서화한다
- 배포와 모니터링 자동화를 먼저 갖춘다
- 변경이 잦고 독립 배포 가치가 큰 영역부터 분리한다
이 순서는 느려 보이지만 실제로는 위험을 줄입니다. 서비스 분리 후에 경계가 틀렸다는 것을 알게 되면 코드 이동보다 데이터와 운영 절차를 바꾸는 비용이 더 큽니다.
따라서 MSA 도입 기준은 기술 유행이 아니라 조직의 학습 속도와 운영 능력까지 포함해서 봐야 합니다.
도입 전 체크리스트
- 서비스별 독립 배포가 실제 병목을 줄이는가?
- 도메인 경계와 팀 책임이 어느 정도 안정됐는가?
- 서비스별 데이터 소유권을 정할 수 있는가?
- 로그, tracing, metrics 같은 관측성 체계가 있는가?
- 장애가 났을 때 누가 어떤 순서로 대응할지 정해져 있는가?
- 계약 테스트나 통합 테스트 전략이 있는가?
이 질문에 답하기 어렵다면 아직은 MSA보다 모듈화된 모놀리식을 먼저 다듬는 편이 낫습니다.
모놀리식은 실패한 구조가 아니다
모놀리식은 한 덩어리라서 무조건 나쁘다는 뜻이 아닙니다. 잘 나눈 패키지, 명확한 계층, 의존성 규칙, 자동화된 테스트를 가진 모놀리식은 작은 팀에 매우 강한 선택입니다.
문제는 모놀리식 자체가 아니라 아무 경계 없이 커진 코드입니다. 반대로 MSA도 경계와 운영 체계 없이 나누면 분산된 혼란이 됩니다.
정리
MSA는 큰 시스템을 다루는 강력한 선택지지만, 초기 기본값으로 삼기에는 비용이 큽니다. 독립 배포, 안정된 도메인 경계, 관측성, 팀 소유권이 준비됐을 때 가치가 커집니다.
아직 그 조건이 없다면 먼저 모듈화된 모놀리식을 잘 만드는 것이 더 현실적입니다. 좋은 MSA는 보통 좋은 경계에서 나오고, 좋은 경계는 시간이 지나며 드러납니다.
