Amazon은 마이크로서비스의 선구자인데, Amazon Prime Video는 마이크로서비스에서 모놀리식으로 돌아갔다. Netflix는 MSA의 교과서인데, 초기에는 모놀리식이었다. 정답은 무엇인가? 역사·논문·실패 사례·데이터베이스 전략까지 — 이 논쟁의 끝장을 내본다.
2023년 3월, 기술 커뮤니티를 뒤흔든 블로그 글이 하나 올라왔다.
Amazon Prime Video 팀이 자사의 비디오 품질 모니터링 시스템을 마이크로서비스에서 모놀리식으로 전환했다는 것. 결과: 비용 90% 절감.
Amazon — 마이크로서비스의 선구자, "Two-Pizza Team"의 발명자, 서비스 지향 아키텍처의 상징 — 이 모놀리식으로 돌아갔다?
이 소식은 즉시 바이럴이 됐다. "마이크로서비스는 과대평가됐다", "모놀리식이 답이다" vs "문맥을 무시한 해석이다", "특수한 경우일 뿐이다" — 논쟁이 격렬했다.
이 글에서는 이 영원한 논쟁을 역사, 논문, 실패 사례, 데이터베이스 전략까지 포함하여 끝장 정리해 보겠다.
모놀리식 아키텍처(Monolithic Architecture) 는 애플리케이션의 모든 기능이 하나의 코드베이스, 하나의 배포 단위, 하나의 프로세스에 포함된 구조다.
쇼핑몰을 예로 들면: 사용자 인증, 상품 조회, 장바구니, 주문, 결제, 배송 추적, 리뷰 — 이 모든 기능이 하나의 애플리케이션 안에 있다. 하나의 WAR 파일, 하나의 Docker 이미지로 배포된다.
비유: "거대한 성". 모든 방(기능)이 하나의 건물에 있다. 성 안에서는 이동이 자유롭고 빠르다. 하지만 화장실을 수리하려면 성 전체를 셧다운해야 할 수도 있다.
| 장점 | 설명 |
|---|---|
| 단순함 | 하나의 코드베이스, 하나의 배포, 하나의 DB. 이해하기 쉬움 |
| 개발 속도 (초기) | 프로젝트 시작이 빠르다. 서비스 간 통신 오버헤드 없음 |
| 디버깅 용이 | 모든 코드가 한 곳에. 스택 트레이스가 완전함 |
| 트랜잭션 용이 | 하나의 DB, 하나의 트랜잭션으로 데이터 일관성 보장 |
| 배포 단순 | 하나를 빌드하고 하나를 배포하면 끝 |
| 인프라 비용 | 서비스 간 네트워크 호출 없음. 오버헤드 적음 |
| 한계 | 설명 |
|---|---|
| 코드베이스 비대화 | 수백만 줄이 되면 빌드에 수십 분, 이해에 수 주 |
| 배포의 공포 | 작은 변경도 전체를 다시 배포. "금요일에 배포 금지" |
| 기술 종속 | 전체가 하나의 언어/프레임워크. Python 서비스에 Go를 쓸 수 없음 |
| 확장의 한계 | 주문만 바쁜데 전체를 복제해야 함. 자원 낭비 |
| 장애 전파 | 결제 서비스의 메모리 누수가 전체를 죽일 수 있음 |
| 팀 간 충돌 | 10개 팀이 하나의 코드베이스를 수정. 머지 충돌의 지옥 |
마이크로서비스 아키텍처(Microservices Architecture) 는 애플리케이션을 작고 독립적인 서비스들의 집합으로 구성하는 방식이다. 각 서비스는 독립적으로 개발·배포·확장된다.
같은 쇼핑몰에서: 사용자 서비스, 상품 서비스, 주문 서비스, 결제 서비스, 배송 서비스, 리뷰 서비스 — 각각이 독립된 팀이 운영하는 독립된 서비스다.
비유: "전문가 마을". 빵집, 우체국, 은행, 병원이 각각 별도의 건물에 있다. 각 건물을 독립적으로 수리·확장할 수 있다. 하지만 빵을 사서 은행에서 결제하려면 건물 사이를 이동해야 한다.
| 장점 | 설명 |
|---|---|
| 독립 배포 | 결제 서비스만 업데이트 가능. 다른 서비스 영향 없음 |
| 기술 다양성 | 주문은 Java, 추천은 Python, 실시간은 Go — 적재적소 |
| 독립 확장 | 주문 서비스만 10배로 스케일 아웃 |
| 장애 격리 | 리뷰 서비스가 죽어도 주문은 정상 작동 |
| 팀 자율성 | 각 팀이 자기 서비스를 완전히 소유. Conway's Law 실현 |
| 기술 부채 관리 | 한 서비스를 완전히 재작성해도 다른 서비스 영향 없음 |
| 비용 | 설명 |
|---|---|
| 분산 시스템의 복잡성 | 네트워크 장애, 데이터 일관성, 분산 트랜잭션 |
| 운영 오버헤드 | 서비스 50개 = 모니터링·배포·로깅 50배 |
| 서비스 간 통신 | 네트워크 지연, 직렬화/역직렬화 비용 |
| 데이터 관리 | 서비스별 DB → JOIN 불가, 데이터 일관성 어려움 |
| 디버깅 난이도 | 분산 트레이싱 없이는 문제 추적 불가능 |
| 인프라 비용 | API Gateway, 서비스 메시, 메시지 큐, 로드밸런서... |
마이크로서비스 이전에 SOA(Service-Oriented Architecture)가 있었다. 2000년대 엔터프라이즈 IT의 핵심 트렌드. 시스템을 서비스로 분리하고 ESB(Enterprise Service Bus) 로 연결하는 구조.
SOA의 문제: ESB가 거대한 중앙 집중형 미들웨어로 성장하며, 그 자체가 모놀리식이 되어버림. "분산 모놀리스"라는 최악의 결과.
2002년, Jeff Bezos가 Amazon 전 직원에게 보낸 유명한 메모:
- 모든 팀은 데이터와 기능을 서비스 인터페이스로 노출해야 한다
- 팀 간 통신은 이 서비스 인터페이스를 통해서만 이루어져야 한다
- 다른 통신 방식은 허용되지 않는다. 직접 DB 접근, 메모리 공유 모두 금지
- 어떤 기술을 쓰든 상관없다
- 모든 서비스 인터페이스는 외부에 공개 가능하도록 설계해야 한다
- 이를 따르지 않는 사람은 해고된다
이것이 서비스 지향 아키텍처의 실전 선언문이다. 이 메모가 Amazon을 "마이크로서비스의 선구자"로 만들었고, 궁극적으로 AWS(외부 공개 가능한 서비스)의 탄생으로 이어졌다.
Martin Fowler와 James Lewis가 2014년에 발표한 블로그 글 "Microservices"가 이 용어를 공식적으로 정의했다:
"마이크로서비스 아키텍처는 단일 애플리케이션을 작은 서비스들의 모음으로 개발하는 접근법이다. 각 서비스는 자체 프로세스에서 실행되고, 경량 메커니즘(보통 HTTP)으로 통신한다."
2009년, Netflix는 모놀리식에서 마이크로서비스로의 전환을 시작했다. 데이터센터 장애를 계기로, AWS로의 마이그레이션과 함께 수백 개의 마이크로서비스로 분해했다. 이 경험을 Zuul, Eureka, Hystrix, Ribbon 등의 오픈소스로 공개하며 MSA의 전도사가 됐다.
1967년, 프로그래머 Melvin Conway가 발표한 법칙:
"시스템의 구조는 그것을 설계한 조직의 커뮤니케이션 구조를 반영한다."
5명이 한 팀이면 → 모놀리식이 자연스럽다. 50명이 10개 팀이면 → 각 팀이 자기 서비스를 가지는 마이크로서비스가 자연스럽다.
마이크로서비스에서 가장 어려운 질문: "어디서 나눌 것인가?"
Eric Evans의 2003년 저서 "Domain-Driven Design"에서 제안한 바운디드 컨텍스트(Bounded Context) 가 이 질문의 핵심 답이다:
각 서비스는 하나의 비즈니스 도메인을 담당한다. "주문"이라는 개념이 서비스마다 다른 의미를 가질 수 있다:
각 서비스는 자기 맥락(Context) 안에서 "주문"을 자기 방식으로 정의하고, 서비스 간에는 **명확한 인터페이스(API)**로 소통한다.
모놀리식에서는 보통 하나의 데이터베이스를 모든 기능이 공유한다:
장점: SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id — 간단하고 빠르다.
MSA의 핵심 원칙: 각 서비스는 자기만의 데이터베이스를 소유한다. 다른 서비스의 DB에 직접 접근하지 않는다.
이것이 이 시리즈에서 다룬 Polyglot Persistence(다중 모델 아키텍처) 의 실현이다. 각 서비스가 자기 워크로드에 맞는 DB를 선택한다:
| 서비스 | 추천 DB | 이유 |
|---|---|---|
| 사용자 인증 | Aurora PostgreSQL | 관계형 데이터, ACID 필수 |
| 상품 카탈로그 | MongoDB | 유연한 스키마, 카테고리별 다른 속성 |
| 장바구니/세션 | DynamoDB | 초고속 키-값, 자동 만료 |
| 주문/결제 | Aurora PostgreSQL | ACID 트랜잭션, 관계형 데이터 |
| 상품 검색 | OpenSearch | 풀텍스트 + 벡터 검색 |
| 추천 | DynamoDB + 벡터 DB | 사용자별 추천 + 유사 아이템 |
| 로그/모니터링 | 시계열 DB | 시간 순서 데이터 |
| 분석/리포팅 | Redshift | OLAP, 대규모 집계 |
모놀리식에서는 하나의 DB 트랜잭션으로 "주문 생성 + 재고 차감 + 결제 처리"를 원자적으로 할 수 있다.
MSA에서는? 주문·재고·결제가 각각 다른 DB. 분산 트랜잭션은 매우 어렵다.
해결 패턴:
1. Saga 패턴: 각 서비스가 로컬 트랜잭션을 수행하고, 실패 시 보상 트랜잭션을 실행하여 롤백.
주문 생성 → 재고 차감 → 결제 요청
↓ 결제 실패!
주문 취소 ← 재고 복원 ← 결제 취소 (보상)
2. 이벤트 소싱: 상태 대신 이벤트의 순서를 저장. "주문 생성됨", "결제 완료됨", "배송 시작됨" — 이벤트 시퀀스가 현재 상태를 결정.
사례 A — 5명 스타트업의 MSA 도입
팀원 5명의 초기 스타트업이 "Netflix처럼 해야 한다"며 서비스를 10개로 나눴다. 결과:
사례 B — 분산 모놀리스
기업이 "마이크로서비스"를 도입했지만, 서비스 간 동기 호출이 체인처럼 연결:
서비스A → 서비스B → 서비스C → 서비스D → 서비스E
하나가 느려지면 전체가 느려진다. 하나가 죽으면 전체가 죽는다. 모놀리식의 단점만 유지하면서 MSA의 복잡성만 추가된 최악의 결과.
Amazon은 각 팀이 피자 두 판으로 먹일 수 있는 규모(6~8명)를 유지하고, 각 팀이 자기 서비스를 완전히 소유한다. 조직 구조와 아키텍처가 일치한 성공 사례. Conway's Law의 정석.
| 시기 | 상태 | 교훈 |
|---|---|---|
| 2007 | 모놀리식 Java 앱 | 기능은 되지만 배포가 어려움 |
| 2008 | DB 장애로 3일간 DVD 배송 중단 | 단일 장애점의 위험 |
| 2009~ | AWS + MSA 전환 시작 | 7년에 걸친 점진적 전환 |
| 2016 | 수백 개의 마이크로서비스 | 전 세계 130개국 동시 출시 가능 |
| 2026 | 성숙한 MSA + 내부 플랫폼 | 수천 명의 엔지니어가 독립 배포 |
핵심: Netflix는 하루아침에 MSA로 전환하지 않았다. 7년에 걸쳐 점진적으로 전환했고, 그 과정에서 수많은 도구(Zuul, Eureka, Hystrix)를 만들었다.
2023년의 Prime Video 사례를 자세히 보면:
Martin Fowler가 2015년에 제안한 전략:
"프로젝트를 시작할 때는 모놀리식으로 시작하라. 마이크로서비스는 나중에 필요할 때 분리하라."
이유: 마이크로서비스의 올바른 경계(바운디드 컨텍스트)를 처음부터 알기는 어렵다. 모놀리식으로 운영하면서 도메인을 이해한 뒤에, 명확한 경계가 보일 때 서비스를 분리하는 것이 안전하다.
| 기준 | 모놀리식이 나은 경우 | MSA가 나은 경우 |
|---|---|---|
| 팀 규모 | < 10명 | > 50명, 다수 팀 |
| 도메인 이해도 | 초기 (도메인 불명확) | 성숙 (경계 명확) |
| 배포 주기 | 주 1~2회 | 팀별 하루 수십 회 |
| 확장 요구 | 전체가 균일한 부하 | 특정 서비스만 폭주 |
| 기술 다양성 | 단일 스택으로 충분 | 서비스별 최적 기술 필요 |
| 장애 격리 | 일부 다운타임 허용 | 서비스별 독립 운영 필수 |
| 트랜잭션 | 복잡한 트랜잭션 많음 | 서비스 간 느슨한 결합 가능 |
| 인프라 역량 | DevOps 전담 없음 | 인프라 팀 + 내부 플랫폼 |
Ruby on Rails 창시자 DHH(David Heinemeier Hansson) 가 2016년에 제안한 개념. Basecamp(팀 협업 도구)는 2026년까지도 모놀리식으로 수백만 사용자를 서비스한다.
Shopify도 대표적 사례. 세계 최대의 이커머스 플랫폼 중 하나이면서, 거대한 모놀리식 Rails 앱으로 운영된다. 다만 내부적으로 모듈 경계를 엄격히 관리한다.
하나의 배포 단위 안에서:
├── 사용자 모듈 (user/) → 자체 모델, 서비스, 컨트롤러
├── 주문 모듈 (order/) → 자체 모델, 서비스, 컨트롤러
├── 결제 모듈 (payment/) → 자체 모델, 서비스, 컨트롤러
└── 배송 모듈 (shipping/) → 자체 모델, 서비스, 컨트롤러
모듈 간 통신: 정의된 인터페이스(API)를 통해서만
모듈 간 직접 DB 접근: 금지
이것이 "모놀리식"과 "마이크로서비스"의 중간 지점이다. 배포는 하나이지만, 코드의 경계는 명확하다. 나중에 특정 모듈을 서비스로 분리하기 쉽다.
2026년의 합의:
Kelsey Hightower (Google, 2020 트윗):
"나는 모놀리식이 마이크로서비스의 미래라고 예측한다. 모노리포(monorepo)에 대한 투자가 정답이다."
Sam Newman ("Building Microservices" 저자, 2023):
"마이크로서비스는 선택이지, 기본값이 아니다. 기본값은 모놀리식이어야 한다."
2026년의 진짜 트렌드: 아키텍처 논쟁보다 플랫폼 엔지니어링. 모놀리식이든 MSA든, 개발자가 쉽게 배포·모니터링·확장할 수 있는 내부 플랫폼을 구축하는 것이 핵심.
Spotify의 Backstage, 각 기업의 내부 개발자 포털(IDP) — 아키텍처의 복잡성을 플랫폼이 흡수하고, 개발자는 비즈니스 로직에만 집중.
이 시리즈 전체를 관통하는 메시지가 있다:
"어떤 기술이 최고인가?"가 아니라 "우리의 문제에 맞는 기술은 무엇인가?"가 올바른 질문이다.
모놀리식이 "구식"이고 마이크로서비스가 "최신"인 것이 아니다. 각각은 다른 상황에 최적화된 아키텍처 패턴이다.
| 상황 | 최적 아키텍처 | 이 시리즈의 관련 기술 |
|---|---|---|
| 소규모 팀, 초기 제품 | 모놀리식 | EC2/ECS + Aurora + S3 |
| 성장 중, 도메인 명확화 | 모듈러 모놀리식 | ECS + Aurora + DynamoDB |
| 대규모, 다수 팀 | 마이크로서비스 | ECS/K8s + Polyglot DB + API GW |
| 이벤트 기반, 간헐적 | 서버리스 | Lambda + DynamoDB + EventBridge |
코어닷투데이도 이 원칙을 따른다. AI 서비스의 핵심은 비즈니스 가치를 만드는 것이지, 특정 아키텍처를 따르는 것이 아니다. 서비스 규모와 팀 역량에 맞는 아키텍처를 선택하고, 성장에 따라 점진적으로 진화시키는 것 — 그것이 이 "영원한 논쟁"에 대한 가장 현실적인 답이다.
이 글은 이 시리즈의 모든 기술 (클라우드, EC2, Docker, ECS, Fargate, K8s, Lambda, S3, RDS, DynamoDB, OpenSearch, CloudFront, API Gateway, EBS, CloudWatch, VPC, ALB, NAT Gateway, Bedrock, IAM, CloudTrail, Redshift, Aurora, MongoDB, 컬럼나 DB, 시계열 DB, 벡터 DB)이 실전에서 어떻게 조합되는지를 보여주는 최종 정리편입니다.