결론부터 말씀드리겠습니다. 마이크로서비스는 만능이 아닙니다. 그리고 대부분의 서비스는 모놀리스로 시작하는 편이 낫습니다. 2023년 아마존 프라임 비디오 팀이 영상 모니터링 시스템을 서버리스 마이크로서비스에서 모놀리스로 되돌려 인프라 비용을 90% 줄였다는 글이 화제가 됐습니다. 거대한 회사가 마이크로서비스를 버렸다는 사실보다 중요한 건, 그들조차 처음에 경계를 잘못 그었다는 점입니다.
오늘은 마이크로서비스와 모놀리스 사이에서 무엇을 기준으로 결정해야 하는지 이야기해보겠습니다. (스포일러를 하나 드리면, 이 결정은 생각보다 기술 문제가 아닙니다.)
마이크로서비스가 푸는 문제와 만드는 문제
먼저 마이크로서비스가 실제로 해결하는 문제를 분명히 해야 합니다. 마이크로서비스는 팀이 서로를 기다리지 않고 독립적으로 배포하게 해주고, 트래픽이 몰리는 일부만 따로 스케일하게 해줍니다. 이 두 가지가 절실한 조직에서는 분산의 비용을 치를 가치가 있습니다.
문제는 같은 구조가 새로운 복잡성을 만든다는 데 있습니다. 가장 비싼 비용은 네트워크 경계입니다. 같은 프로세스 안의 함수 호출은 나노초 단위지만, 네트워크 호출은 밀리초 단위입니다. 약 100만 배 차이입니다. 모놀리스에서는 그냥 함수 하나였던 것이, 마이크로서비스에서는 직렬화, 네트워크 왕복, 타임아웃, 재시도, 그리고 실패 처리를 동반한 원격 호출이 됩니다.
여기서 중요한 점은, 이 복잡성이 코드에만 머물지 않는다는 것입니다. DZone의 2024년 조사에 따르면 분산 시스템에서의 디버깅은 단일 시스템보다 약 35% 더 오래 걸립니다. 하나의 요청이 다섯 개 서비스를 거치면, 장애가 났을 때 다섯 곳의 로그를 맞춰봐야 합니다. (저는 이걸 가볍게 봤다가 새벽에 트레이스를 추적하며 대가를 치른 적이 있습니다.)
분산은 공짜가 아니다
마틴 파울러는 이 추가 비용을 마이크로서비스 프리미엄이라고 불렀습니다. 분산 아키텍처는 그 자체로 상당한 비용과 위험을 얹는데, 시스템의 복잡성이 그 프리미엄을 넘어설 만큼 클 때에만 본전을 뽑는다는 뜻입니다. 그래서 그는 2015년에 이미 ‘MonolithFirst’, 즉 모놀리스로 먼저 시작하라고 권했습니다. 성공한 마이크로서비스 이야기는 거의 다 잘 만든 모놀리스가 커진 뒤 쪼개진 경우였기 때문입니다.
소프트웨어 공학에는 더 오래된 통찰이 있습니다. 프레드 브룩스는 복잡성을 두 종류로 나눴습니다. 문제 자체에서 비롯되는 본질적 복잡성과, 우리가 푸는 방식 때문에 생기는 우발적 복잡성입니다. 마이크로서비스가 위험한 건, 본질적 복잡성을 줄이려다 우발적 복잡성을 더 키우기 쉽다는 점입니다. 네트워크는 신뢰할 수 있다는 가정, 지연은 0이라는 가정 같은 ‘분산 컴퓨팅의 오류’들은 바로 이 우발적 복잡성이 우리를 무는 지점입니다.
| 구분 | 모놀리스 | 마이크로서비스 |
|---|---|---|
| 호출 비용 | 인메모리, 나노초 | 네트워크, 밀리초 (약 100만 배) |
| 배포 | 한 번에 전체 | 서비스별 독립 배포 |
| 디버깅 | 한 곳의 스택 트레이스 | 여러 서비스 로그 대조 (약 35%↑) |
| 데이터 정합성 | 단일 트랜잭션 | 분산 트랜잭션, 결과적 일관성 |
| 전제 조건 | 적음 | 운영 성숙도, 자율적 팀 구조 |
트레이드오프는 분명합니다. 독립 배포와 부분 확장을 얻는 대신, 네트워크 지연과 분산 트랜잭션, 운영 부담을 떠안습니다. 잘 만든 모놀리스가 나쁜 게 아닙니다. 대부분의 서비스에는 충분합니다. 감당 못 할 분산을 미리 떠안는 것은 갚을 계획 없는 기술 부채를 네트워크 너머에 쌓는 일과 같습니다.
진짜 결정 요인은 코드가 아니라 조직이다
여기서 한 단계 더 들어가 보겠습니다. 마이크로서비스 결정은 본질적으로 기술 문제가 아니라 조직 문제입니다. 1968년 멜빈 콘웨이가 남긴 콘웨이 법칙은 이렇게 말합니다. 시스템을 설계하는 조직은 그 조직의 의사소통 구조를 그대로 닮은 설계를 내놓는다. 팀이 셋이면 시스템도 셋으로 갈라지는 경향이 있다는 뜻입니다.
이 관점을 뒤집으면 실용적인 지침이 나옵니다. 『Accelerate』의 저자들이 데이터로 뒷받침한 역 콘웨이 책략은, 원하는 아키텍처를 얻으려면 팀 구조를 먼저 그렇게 바꾸라고 말합니다. DORA 연구의 핵심 질문은 간단합니다. “한 팀이 다른 팀과 긴밀히 조율하지 않고도 설계부터 배포까지 끝낼 수 있는가.” 이 질문에 ‘아니오’라면, 시스템만 쪼개도 배포는 여전히 서로를 기다리며 막힙니다. 분산된 모놀리스, 즉 네트워크로 연결됐지만 함께 배포해야 하는 최악의 조합이 됩니다.
그래서 저는 누군가 마이크로서비스를 묻기 전에 조직부터 봅니다. 독립적으로 배포하고 책임지는 팀이 없는데 서비스만 나누는 것은, 배관을 새로 깔지 않고 수도꼭지만 늘리는 일과 같습니다. 시니어 개발자가 코드를 짜기 전에 조직과 제약부터 살피는 이유가 여기 있습니다.
모듈러 모놀리스라는 중간지대
다행히 선택지는 둘만 있는 게 아닙니다. 모듈러 모놀리스는 하나의 배포 단위 안에서 모듈 경계를 명확히 분리한 구조입니다. 마이크로서비스의 경계 이점은 살리고, 네트워크와 배포의 분산 복잡성은 피합니다. Shopify가 대표적인 사례이고, CNCF의 2026년 1분기 리포트에 따르면 마이크로서비스를 도입했던 조직의 42%가 일부 서비스를 다시 더 큰 배포 단위로 통합했는데, 그 형태가 바로 모듈러 모놀리스입니다.
핵심은 바운디드 컨텍스트로 모듈을 나누되, 그 경계를 코드로 강제하는 것입니다. 폴더만 나눠놓고 아무 데서나 서로를 import하면 모듈이 아니라 그냥 큰 진흙 덩어리입니다.
app/
orders/ # 주문 도메인 — 외부엔 공개 인터페이스만 노출
public/ # 다른 모듈이 호출할 수 있는 유일한 진입점
internal/ # 이 경계 밖에서는 import 금지 (정적 검사로 강제)
payments/ # 결제 도메인
shipping/ # 배송 도메인실제로 한 구독 커머스 서비스를 만들 때, 주문과 결제와 배송 도메인을 이렇게 체계적으로 분리한 적이 있습니다. 당시 트래픽 규모에서 이걸 세 개의 마이크로서비스로 띄울 이유는 없었습니다. 대신 모듈 경계만 단단히 그어두니, 나중에 결제만 따로 떼어내야 할 때 그 모듈이 그대로 추출 가능한 이음새가 되어주었습니다. 경계가 안정된 모듈을 떼어내는 것은, 경계가 불확실한 상태에서 처음부터 쪼개는 것과는 난이도가 다릅니다.
프라임 비디오 팀이 한 일도 본질은 같았습니다. 잘게 나눠 네트워크와 S3로 대용량 데이터를 주고받던 단계를, 한 프로세스 안으로 합쳐 그 오버헤드를 없앤 것입니다. 쪼개는 게 늘 진보가 아니라는 사실을, 그들은 비용 청구서로 배웠습니다.
그래서 언제 쪼개야 하는가
마이크로서비스로 가야 할 신호는 분명합니다. 막연한 ‘확장성’이 아니라 구체적인 압력으로 나타납니다.
| 쪼개도 좋은 신호 | 아직 이른 신호 |
|---|---|
| 팀들이 서로의 배포를 기다리며 막힌다 | 팀이 하나거나, 조율이 어렵지 않다 |
| 특정 기능만 트래픽이 몰려 따로 스케일해야 한다 | 전체를 같이 키워도 감당된다 |
| 도메인 경계가 여러 번 검증돼 안정적이다 | 경계가 자주 바뀐다 |
| 분산을 운영할 성숙도가 있다 | 모니터링·온콜 체계가 아직 없다 |
데이터 계층에서도 같은 교훈을 얻은 적이 있습니다. 서로 다른 데이터베이스를 CDC로 묶어 실시간 파이프라인을 만든 프로젝트에서, 비동기 처리가 주는 유연함의 대가로 정합성을 맞추는 복잡성을 고스란히 떠안아야 했습니다. 분산은 늘 무언가를 얻는 대신 무언가를 내줍니다. 그 교환이 지금 우리에게 남는 장사인지 따지는 것이 설계의 본질입니다.
결론
좋은 아키텍처는 유행을 따르는 게 아니라 맥락에 맞추는 것입니다. 마이크로서비스가 틀렸다는 이야기가 아닙니다. 넷플릭스에게 맞는 옷이 이제 막 시작하는 우리 팀에게도 맞으리란 법은 없다는 이야기입니다. 기술 스택을 고를 때와 똑같이, 기준은 ‘무엇이 최신인가’가 아니라 ‘무엇이 지금 우리 맥락에 맞는가’입니다.
그래서 다음에 누군가 “이거 마이크로서비스로 가야 하지 않을까요”라고 물으면, 저는 세 가지를 되묻습니다. 팀이 정말 독립적으로 배포하고 있나요. 도메인 경계가 충분히 안정됐나요. 분산의 비용을 감당할 준비가 됐나요. 셋 다 ‘예’가 아니라면, 답은 대개 잘 설계된 모놀리스, 그리고 단단한 모듈 경계입니다. 쪼개는 일은 그다음에 해도 늦지 않습니다.
참고 자료
- Martin Fowler, “MonolithFirst” (martinfowler.com, 2015)
- Martin Fowler, “Microservice Trade-Offs” (martinfowler.com)
- Sam Newman, 『Monolith to Microservices』 (O’Reilly, 2019)
- Marcin Kolny, “Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%” (Amazon Prime Video Tech, 2023)
- Frederick P. Brooks, “No Silver Bullet: Essence and Accident in Software Engineering” (1986)
- Melvin Conway, “How Do Committees Invent?” (1968) — 콘웨이 법칙
- Nicole Forsgren, Jez Humble, Gene Kim, 『Accelerate』 (IT Revolution, 2018) — DORA, 역 콘웨이 책략
- CNCF, “Cloud Native Architecture Report” (2026 Q1) — 모듈러 모놀리스 통합 추세
