넷플릭스, 쿠팡, 배달의민족이 마이크로서비스 아키텍처를 사용한다는 기사를 읽으면 "우리도 마이크로서비스로 시작해야 하지 않을까?"라는 생각이 듭니다. 하지만 이 세 회사의 공통점은 모두 모놀리식으로 시작해서 서비스가 충분히 성장한 후에야 마이크로서비스로 전환했다는 것입니다.

처음부터 마이크로서비스로 시작한 것이 아닙니다. 아키텍처 선택은 기술적 유행이 아니라 현재 팀 규모와 서비스 상황에 맞는 합리적 판단이어야 합니다.

모놀리식 아키텍처

모놀리식은 모든 기능이 하나의 서버에서 동작하는 구조입니다. 사용자 관리, 주문 처리, 결제, 알림 기능이 모두 하나의 코드베이스에 있습니다. 장점은 명확합니다. 개발이 단순하고, 배포가 한 번에 끝나며, 2~5명의 소규모 팀이 관리하기 적합합니다.

로컬 함수 호출로 기능 간 통신이 이루어지므로 네트워크 지연도 없고, 데이터베이스 트랜잭션 관리도 단순합니다. 수만 명의 동시 사용자까지는 모놀리식으로 충분히 처리할 수 있습니다. 대부분의 스타트업이 이 규모를 넘길 일은 초기 몇 년간 없습니다.

디버깅도 쉽고, 신규 개발자가 합류했을 때 전체 코드베이스를 파악하기도 훨씬 수월합니다. 하나의 IDE에서 전체 흐름을 추적할 수 있다는 것은 개발 생산성에서 큰 장점입니다.

마이크로서비스 아키텍처

마이크로서비스는 각 기능을 독립된 서버(서비스)로 분리하는 구조입니다. 결제 서비스, 사용자 서비스, 주문 서비스가 각각 별도 서버에서 운영됩니다. 하나의 서비스에 장애가 발생해도 다른 서비스는 정상 동작한다는 장점이 있으며, 팀별로 독립 배포가 가능해 수십~수백 명 규모의 개발 조직에서 병렬 개발 속도를 높일 수 있습니다.

하지만 대가가 큽니다. 서비스 간 통신을 위한 API Gateway, 메시지 큐(Kafka, RabbitMQ), 서비스 디스커버리(Consul, Eureka)가 필요합니다. 분산 트랜잭션, 데이터 일관성, 서비스 간 장애 전파 방지(Circuit Breaker 패턴) 등 모놀리식에서는 존재하지 않던 복잡한 문제들이 발생합니다.

운영 복잡도가 5~10배 증가하며, 최소 3~5명의 DevOps 엔지니어가 인프라를 전담해야 합니다.

마틴 파울러의 조언: MonolithFirst

소프트웨어 아키텍처의 권위자 마틴 파울러는 "MonolithFirst" 전략을 권장합니다. 처음에는 모놀리식으로 시작하고, 서비스가 성장하면서 특정 부분에 병목이 발생할 때 그 부분만 분리하라는 것입니다. 이유는 간단합니다.

서비스 초기에는 어떤 부분이 병목이 될지 예측할 수 없습니다. 미리 분리해 놓으면 잘못된 경계로 나눌 가능성이 높고, 이를 수정하는 비용이 처음부터 모놀리식으로 시작하는 것보다 훨씬 큽니다. 실제로 조기에 마이크로서비스를 도입했다가 서비스 간 경계 설정 실패로 오히려 개발 속도가 저하되어 다시 모놀리식으로 회귀하는 사례도 적지 않습니다.

비용 현실

마이크로서비스 인프라는 스타트업 규모의 서비스에서 모놀리식 대비 3~5배의 운영 비용이 듭니다. AWS 기준으로 모놀리식이 월 50~100만 원이면, 동일한 트래픽 규모 서비스의 마이크로서비스는 월 200~500만 원 수준입니다.

여기에 Kubernetes 클러스터 관리, 모니터링 도구(Datadog, Prometheus, Grafana), CI/CD 파이프라인, 중앙 집중식 로그 수집 시스템(ELK Stack) 등의 추가 비용까지 고려하면 차이는 더 벌어집니다.

매출이 본격적으로 발생하기도 전에 인프라 비용만으로 월 수백만 원이 소진되는 스타트업도 있습니다.

프로덕트 메이커의 제안

저희에게 재개발 요청이 들어왔던 프로젝트 중에 이런 경우가 있었습니다. 사용자가 얼마 되지도 않는 초기 서비스인데, 8개 이상의 마이크로서비스로 분리되어 있었습니다. 처음에 큰 그림을 그리셨다고 하는데, 그러기엔 초기 개발 비용이 너무 많이 소비됐습니다. 서비스마다 언어가 달랐고 인수인계 문서도 없어서 구조를 파악하는 것만으로도 상당한 시간이 걸렸습니다. 초기 개발 비용은 저희가 받은 게 아니라 이전 개발사가 받은 겁니다. 클라이언트 입장에서는 돈은 돈대로 쓰고, 결과물은 유지보수 난이도가 아주 높은 상태였습니다. 8개 서비스가 같은 언어도 아니고 다른 부분도 있어서, 수정하려면 각 언어에 맞는 개발자가 따로 필요하고, 서비스 간 연결 구조를 모르면 하나를 고쳤는데 다른 곳이 깨지는 상황이 반복됩니다. 저희는 해당 언어들을 모두 다룰 수 있어서 결과적으로 해결해드렸지만, 일반적인 개발사에서는 이런 구조를 인수받는 것 자체를 거부하는 경우가 많습니다.

프로덕트 메이커는 초기 프로젝트에서 모놀리식 구조를 제안합니다. 하나의 서버로 시작하되, 서비스가 성장하면서 특정 기능에 트래픽이 집중되면 그 부분만 별도 서비스로 추출하는 점진적 방식입니다. 물론 클라이언트가 마이크로서비스를 원하시면 만들어드릴 수 있습니다. 다만 초기 단계에서는 비용과 복잡도 면에서 모놀리식이 훨씬 합리적이라는 점을 설명드리고, 판단은 클라이언트에게 맡깁니다.

실제로 저희가 개발·운영 중인 연매출 300억 규모의 몰인몰 형태 쇼핑몰도 모놀리식으로 구축되어 있습니다. 피크 타임에 수천 명이 동시 접속하는 서비스인데, 해당 시점에만 오토스케일링되도록 인프라를 세팅해놓았습니다. 마이크로서비스 없이도 충분히 잘 운영되고 있습니다. 넷플릭스의 아키텍처가 아니라, 지금 우리 서비스의 규모에 맞는 아키텍처를 선택하는 것이 현명한 판단입니다.