마이크로서비스 vs 모놀리스 — 현실적 선택 기준
규모별 추천, 운영 복잡도, 배포, 데이터 일관성, 팀 구조별 아키텍처 선택 가이드.
한 줄 요약: 팀 3명 이하, 초기 단계 프로덕트라면 모놀리스가 맞다. 팀이 10명 이상이고 특정 컴포넌트의 배포/스케일링 요구가 다르게 분화됐다면 마이크로서비스를 검토할 시점이다. 마이크로서비스로 시작하면 대부분 실패한다.
"요즘 다들 마이크로서비스 쓴다"는 이유로 아키텍처를 선택하는 것은 팀과 프로덕트에 맞지 않는 복잡성을 일찍 도입하는 것이다. Amazon, Netflix가 마이크로서비스로 성공했지만, 그들이 모놀리스로 시작했다는 사실도 함께 알려져 있다. 이 글은 규모, 팀 구조, 운영 역량별로 어떤 아키텍처를 선택해야 하는지 현실적인 판단 기준을 제시한다.
모놀리스와 마이크로서비스 — 무엇이 다른가
모놀리스(Monolith)
단일 배포 단위로 모든 기능이 하나의 코드베이스에 있다. 비즈니스 로직, API, 데이터 접근이 하나의 프로세스에서 실행된다. "모놀리스"는 부정적 의미가 아니다. 잘 설계된 모놀리스는 유지보수하기 쉽고, 배포가 단순하며, 로컬 개발 환경 구성이 쉽다.
- 모듈러 모놀리스: 코드베이스 내부는 도메인 경계로 명확히 분리되어 있지만, 배포는 단일 단위다. 내부 복잡도를 관리하면서 운영 단순성을 유지한다.
마이크로서비스(Microservices)
기능별로 독립적인 서비스가 각자 배포되고, 네트워크(HTTP, gRPC, 메시지 큐)를 통해 통신한다. 각 서비스는 독립적으로 스케일링하고, 다른 언어/프레임워크를 쓸 수 있다.
- 서비스 메시(Service Mesh): Istio, Linkerd 같은 서비스 메시로 서비스 간 통신을 관리하면 트래픽 제어, 관찰 가능성, 보안을 서비스 코드 밖에서 처리한다.
규모별 아키텍처 비교
운영 복잡도 — 마이크로서비스가 만드는 새 문제들
마이크로서비스는 코드 복잡도를 낮추는 대신 운영 복잡도를 높인다. 이 비용을 감당할 수 있는지 먼저 판단해야 한다.
서비스 간 통신
모놀리스에서 함수 호출은 마이크로서비스에서 네트워크 호출이 된다. 네트워크는 실패한다. 타임아웃, 재시도, 서킷 브레이커 패턴이 필요해진다. 각 서비스의 API 버전 관리도 별도로 해야 한다.
분산 트랜잭션과 데이터 일관성
주문과 결제가 다른 서비스라면, 결제는 성공했는데 주문 생성에 실패한 경우 어떻게 처리할까? 모놀리스에서 DB 트랜잭션 롤백 한 줄이면 해결됐던 것이, 마이크로서비스에서는 SAGA 패턴이나 2PC(Two-Phase Commit)로 구현해야 한다. 이것은 상당한 엔지니어링 비용이다.
관찰 가능성 (Observability)
단일 요청이 여러 서비스를 거칠 때 어디서 느려지고 어디서 에러가 났는지 추적하려면 분산 트레이싱(Jaeger, Zipkin, Tempo)과 중앙화된 로그(ELK, Loki), 메트릭 수집(Prometheus, Grafana)이 필요하다. 이 인프라를 구축하고 유지하는 것 자체가 풀타임 작업이 될 수 있다.
로컬 개발 환경
서비스가 10개라면 로컬에서 개발할 때 10개 서비스를 모두 띄워야 한다. Docker Compose로 해결할 수 있지만, 각 서비스의 설정과 의존성을 관리하는 비용이 생긴다. 개발자 생산성에 직접 영향을 미친다.
팀 구조와 아키텍처 — Conway의 법칙
Conway의 법칙: 조직이 만드는 시스템은 조직의 커뮤니케이션 구조를 반영한다.
마이크로서비스가 잘 작동하려면 팀 구조가 서비스 경계와 일치해야 한다. 결제 서비스는 결제 팀이 소유하고, 알림 서비스는 알림 팀이 소유하는 식이다. 팀이 서비스 경계와 다르게 구성되어 있으면, 서비스 간 변경이 여러 팀의 조율을 필요로 하고 마이크로서비스의 팀 독립성 이점이 사라진다.
판단 흐름
아키텍처를 결정하기 전에 다음 질문에 답해보자.
- 현재 팀 규모가 10명 이하인가? → 모놀리스 유지
- 특정 기능의 배포 주기나 스케일링 요구가 나머지와 명확히 다른가? → 그 기능만 서비스로 분리 검토
- 팀이 서비스 소유권 기준으로 재편될 수 있는가? → 마이크로서비스 전환 검토 가능
- 분산 트레이싱, 서비스 메시, 분산 트랜잭션 처리 역량이 팀에 있는가? → 없으면 모놀리스 유지
모놀리스에서 마이크로서비스로 — 현실적 전환 경로
성공한 마이크로서비스 아키텍처는 대부분 잘 작동하는 모놀리스에서 진화한 것이다. 처음부터 마이크로서비스로 시작하는 것은 "분산 모놀리스"라는 최악의 결과로 이어질 가능성이 높다.
1단계 — 모듈러 모놀리스
먼저 단일 배포 단위를 유지하면서 내부를 도메인 경계로 명확히 분리한다. 각 모듈은 자체 폴더, 자체 데이터 모델, 최소한의 공개 API를 갖는다. 이 경계가 나중에 서비스 분리 선이 된다.
2단계 — 스트랭글러 패턴으로 분리
스트랭글러(Strangler) 패턴: 모놀리스 전체를 한 번에 분리하지 않고, 가장 독립성이 높고 분리 이점이 분명한 기능부터 별도 서비스로 떼어낸다. 모놀리스는 계속 작동하고, 분리된 기능은 API 게이트웨이를 통해 라우팅한다.
분리 우선순위 기준:
- 다른 컴포넌트와 데이터 의존성이 가장 적은 것
- 스케일링 요구가 나머지와 다른 것 (예: 이미지 처리, 검색)
- 배포 주기가 나머지와 다른 것
3단계 — 인프라 역량 선제 구축
서비스 분리 전에 관찰 가능성 인프라(트레이싱, 로그 집계, 알림)를 먼저 갖춰라. 서비스가 분리된 후에 구축하려 하면 장애 대응 중에 인프라를 구축해야 하는 상황이 생긴다.