모놀리스 vs 마이크로서비스

애니메이션이 보여주는 것

세 사건이 갈림길이다. 배포: 결제 한 줄 수정에 모놀리스는 전체 재배포, 마이크로서비스는 결제만. 확장: 주문 폭주에 전체 3벌 vs 주문만 3개. 장애: 알림 메모리 누수에 전체 다운 vs 알림만 다운.

단, 두 가지 정직한 대가도 함께 보여준다. 서비스 사이의 호출은 함수(나노초)가 아니라 네트워크(밀리초·실패 가능)가 되고, 장애 격리도 공짜가 아니다 — 알림을 동기로 기다리게 짰다면 마이크로서비스에서도 장애는 그대로 전파된다.

언제 무엇을 고르는가

결정 기준은 기술보다 조직과 규모다.

• 팀이 하나·도메인이 아직 흐릿함: 모놀리스로 시작한다. 마이크로서비스의 이득(독립 배포)은 팀이 여럿일 때 생기고, 비용(운영·네트워크·분산 트랜잭션)은 즉시 생긴다.
• 갈아탈 신호: 배포 열차가 서로를 막기 시작할 때(팀 A의 배포가 팀 B를 기다림), 특정 모듈만 스케일 요구가 다를 때, 모듈별로 다른 기술이 진짜 필요할 때.
• 떼어내는 방법: 한 번에 전환이 아니라 스트랭글러 피그 — 가장 아픈 경계부터 하나씩 서비스로 떼고, 프록시가 트래픽을 점진적으로 넘긴다.
• 중간 지대: 모듈러 모놀리스(경계는 엄격, 배포는 하나)가 대부분 팀의 최적점이다. Shopify가 대표 사례.
• 분산 모놀리스 경보: 서비스가 여럿인데 늘 함께 배포해야 하고 하나가 죽으면 다 죽는다면 — 두 방식의 비용만 합산한 상태다.

숨은 청구서

마이크로서비스 전환의 견적에는 코드 분리 외에 서비스 발견, 분산 추적, 서킷 브레이커, 사가(분산 트랜잭션), 계약 테스트, 파이프라인 N벌이 들어간다. 아마존·넷플릭스가 이 비용을 감당하는 이유는 수백 팀의 독립 배포가 그보다 값지기 때문이다 — 다섯 명 팀이라면 그 산수가 성립하지 않는다.