✍️ 필사 모드: 아키텍처 사례 연구 — Netflix·Stripe·Cloudflare·Shopify를 2025년 기준으로 심층 분석

프롤로그 — "이론 22편 끝냈다. 현실은 어떻게 돌아가는가?"

Season 2에서 우리는 원칙과 패턴을 배웠다. 이제 Season 3은 현실의 사례.

• Netflix는 왜 7,000개 마이크로서비스를 운영하는가?
• Stripe는 왜 아직도 Ruby 모노리스인가?
• Cloudflare는 어떻게 하루 32조 요청을 처리하는가?
• Shopify는 Black Friday에 $10B 매출을 어떻게 받아내는가?

이 글은 공개된 엔지니어링 블로그, 컨퍼런스 발표, 포스트모템에서 추출한 실제 아키텍처. 내부 정보는 없고, 모든 출처는 공개 자료다.

Season 3 Ep 1 — 아키텍처 사례 연구.

1부 — Netflix — 7,000개 마이크로서비스의 오케스트라

규모 (2024 공개 자료)

- MAU: 2.7억
- 동시 스트리밍: 수천만
- 트래픽: 인터넷 트래픽의 15%
- 마이크로서비스: 7,000개+ (추정)
- AWS EC2 인스턴스: 수백만
- Cassandra 클러스터: 수천 개
- Kafka 메시지: 하루 수조 건

아키텍처 스택

Edge: Zuul (API Gateway) → Spring Cloud Gateway로 이동 중
Service Mesh: 자체 구현 (Ribbon, Eureka) → gRPC 기반
DB: Cassandra (primary), DynamoDB, EVCache (Memcached)
Caching: EVCache (자체 개발), Moneta
Streaming: Kafka + Flink
Compute: AWS EC2 + Titus (자체 컨테이너 플랫폼)
Chaos Engineering: Chaos Monkey (발명)

Chaos Engineering — Netflix의 발명

Chaos Monkey: 프로덕션에서 무작위 서버 종료
Chaos Gorilla: 가용 영역(AZ) 전체 종료
Chaos Kong: 리전 전체 종료

철학: "장애는 피할 수 없다. 미리 연습해서 복원력을 만든다." 효과: 10년 넘게 큰 outage 없음 (2023 AWS us-east-1 장애 때도 살아남음).

인코딩 전략

한 영화 → 120개 이상 버전
(해상도 × 비트레이트 × 오디오 × HDR × 자막)

Per-title encoding: 영화마다 최적 비트레이트 분석
Per-shot encoding: 장면마다 다른 비트레이트 → 대역폭 20% 절감
AV1 codec: 2024년 활성화, H.264 대비 20-30% 효율

Open Connect — 자체 CDN

이유: 상용 CDN으로는 규모/비용 감당 X
구조: 전 세계 ISP의 데이터센터에 자체 서버 설치
효과: 인터넷 backbone 부하 최소화, 지연 감소
규모: 18,000+ 서버 in 175+ 국가

배포 도구 — Spinnaker

2014년 Netflix 개발 → 오픈소스. GitOps 이전 시대의 CD. 2025 현실: Spinnaker 쇠퇴, ArgoCD가 대세. Netflix 내부도 modernize 중.

교훈

1. 규모가 아키텍처를 정의: 2.7억 사용자엔 마이크로서비스 필수
2. 실패 예상: Chaos Engineering은 "if"가 아닌 "when"
3. 자체 도구 과감: CDN, 컨테이너 플랫폼 자체 개발
4. 데이터 중심: Per-shot encoding 같은 세밀한 최적화
5. 근데 7,000개는 당신 회사가 따라할 것 X — Netflix니까 필요

2부 — Stripe — 모노리스가 이긴다

규모 (2024 공개)

- 결제 처리: 연 $1T+ (2023년)
- 고객: 수백만 (Uber, Amazon, Google, OpenAI 등)
- Ruby 모노리스: 코드 수천만 줄
- 직원: 8,000+

"대기업이 왜 아직 모노리스?"

Stripe는 **"우리는 모노리스다"**를 자랑스럽게 말함.

이유:

1. 결제 도메인은 강한 일관성 필요 (ACID)
2. 마이크로서비스 = 분산 트랜잭션 = 복잡도
3. 개발자 생산성: 한 repo, 한 배포
4. 강한 테스트 → 리팩터 자유

실제 구조

Sorbet (Ruby type checker) — Stripe 개발
Rails 기반 모노리스
수천 개 endpoint
Postgres (sharded) + MongoDB (일부 레거시)
Kafka for 이벤트
Spark for analytics

Sorbet: Ruby에 정적 타입을 추가한 Stripe의 자체 도구. 2019 오픈소스. TypeScript가 JS에 한 역할.

API 버저닝

날짜 기반: Stripe-Version: 2024-12-18
매일 새 버전 가능 (breaking change 있을 때만)
각 버전 영원히 유지 (2011년 v1 여전히 작동)

내부 구현:
- Request → version translator → 현재 내부 스키마
- 현재 내부 → version translator → Response
- 10년치 버전 유지 비용 vs 고객 신뢰

Idempotency

모든 POST API에 Idempotency-Key 지원. Redis + DB로 24시간 보관. 동시 요청 시 lock으로 단일 처리 보장. Stripe가 Idempotency 표준을 만듦.

Data Infrastructure

Pervasive Caching: 각 서비스가 자체 캐시
Event sourcing: 결제 이력은 절대 수정 X
Double-entry bookkeeping: 회계 스타일 (balances = sum of events)
Strong consistency: Spanner-like 자체 구현

교훈

1. 모노리스도 $1T 처리 가능: 마이크로서비스가 필수 아님
2. 도구 자체 개발: Sorbet, Skycfg (Starlark config)
3. API는 계약: 10년 유지 각오로 설계
4. Idempotency가 기본: 분산 시스템의 필수
5. 개발자 경험 = 제품: 내부 도구도 UX 중시

3부 — Cloudflare — Edge의 제왕

규모 (2024)

- 네트워크: 300+ 도시, 120+ 국가
- 트래픽: 하루 32조 요청
- DNS: 하루 30+ quadrillion 쿼리
- DDoS 차단: 209 Tbps 공격 방어 (2024)
- Workers: 매일 7백만+ 개 배포

핵심 제품 스택

Edge: 자체 하드웨어 + 소프트웨어 스택
Network: Anycast (1.1.1.1 하나의 IP, 300 PoP)
DDoS: L3/L4/L7 다층 방어
Workers: V8 isolate 기반 serverless
Workers AI: Edge inference (LLM)
R2: S3 호환 object storage (egress 무료가 차별화)
D1: SQLite-based distributed DB
Durable Objects: Stateful 서버리스
Hyperdrive: DB connection pooler at edge
Tunnel: Zero Trust private network

Workers — 왜 V8 isolate?

Lambda: 컨테이너 → 100ms+ cold start
Workers: V8 isolate → 5ms cold start

이유:
- V8 isolate는 가벼움 (수 MB 메모리)
- 같은 프로세스에 수천 isolate
- 각 isolate는 격리 (같은 V8)

제약: Node API 일부만 지원 (표준 Web API 중심). 파일시스템 X. CPU 시간 50ms 제한 (paid는 30초).

네트워크 스택 특징

Quicksilver: 자체 KV store (configuration 초고속 분산)
Unimog: L4 load balancer
BGP: 전 세계 광고, Argo Smart Routing

2022 11월 장애 포스트모템 (유명)

무슨 일: 전 세계 Cloudflare dashboard 다운
원인: BGP 경로 전파 오류 (한 스위치 업그레이드 중)
지속: 2시간
교훈: "Control plane은 분산돼야" — Argo control plane 재설계

가치: 포스트모템 공개 — 업계 전체 배움.

교훈

1. Edge가 미래: 중앙 데이터센터보다 전 세계 분산
2. 자체 스택 전체: 네트워크 하드웨어부터 런타임까지
3. 투명한 포스트모템: 신뢰 쌓는 문화
4. 무료 tier 전략적: 개발자 lock-in
5. 다른 CDN 차별화: 개발자 플랫폼 (Workers) 핵심

4부 — Shopify — Black Friday의 왕

규모 (2023-2024)

- Merchant: 500만+ 가맹점
- Black Friday 2023: $9.3B 매출 (4일)
- Peak RPS: 70만+ 요청/초
- Orders: 분당 수만 건
- GMV: 연 $300B+

아키텍처 스택

Rails 모노리스: "Shopify Core"
Ruby: 주력 언어 (YJIT 적극 활용)
MySQL: sharded, Vitess와 유사한 자체 구현
Kafka: 이벤트 스트리밍
Go, Elixir, Rust: 특수 서비스
Kubernetes (일부), GCP + 자체 데이터센터

Pods — Shopify의 샤딩

Pod: 가맹점을 그룹화한 격리 단위
각 Pod: MySQL shard + Redis + 다른 리소스
한 Pod 문제 → 다른 Pod 영향 X (blast radius 제한)
전 세계 수십 개 Pod

효과: 한 고객이 DB 포화시켜도 다른 고객 영향 X.

Black Friday 준비

1. 연간 예측 트래픽 4-10x
2. 6개월 전부터 리허설
3. Game day: 의도적 장애 시뮬레이션
4. Capacity planning: 무한 증설이 아닌 효율 개선
5. Feature freeze: 2주 전부터 주요 배포 중단
6. On-call 대대적 준비

YJIT — Ruby JIT의 전환점

2022: YJIT Rust로 재작성
2023+: Shopify Core 채택
효과: 전체 서버 CPU 15% 감소 → 서버 비용 절감
Shopify가 YJIT 개발 이끔 (Maxime Chevalier-Boisvert)

Storefront — 새로운 FE 스택

Hydrogen: Shopify의 Remix 기반 SSR 프레임워크
Oxygen: Shopify의 배포 플랫폼
이전: Liquid 템플릿 엔진 (자체)
이후: React + TypeScript

교훈

1. Pod로 샤딩: 고객 격리는 scaling의 친구
2. Black Friday는 평소 실력의 배가: 매일 조금씩
3. 모노리스 + 주변 micro: Rails + Go/Elixir 특수 부분
4. YJIT처럼 언어/런타임 투자: 복리 효과
5. Game day 문화: 장애를 연습

5부 — Discord — 수천만 동시 사용자 채팅

규모

- Registered users: 3억+
- DAU: 1.5억+
- Messages: 하루 400억+
- Voice minutes: 월 수십억

재밌는 언어 선택

Elixir (Erlang VM): 채팅 서비스 (대규모 동시성)
Rust: 성능 크리티컬 (voice server 등)
Python: ML, 백엔드 일부
Go, TypeScript: 기타

ScyllaDB로 Cassandra 대체 (2023)

문제: Cassandra 177 노드, 유지보수 지옥
해결: ScyllaDB로 마이그레이션 (C++ 재작성 Cassandra)
결과: 노드 177 → 72, 레이턴시 50% 감소, $$$ 절감

교훈: 언어/런타임 변경으로 인프라 절반. 엔지니어링 시간 투자할 가치.

교훈

1. BEAM(Erlang)의 힘: WhatsApp, Discord가 증명
2. 언어 섞어라: 도메인마다 적합한 언어
3. DB 교체는 가능: 사전에 interface 추상화
4. Rust 점진 도입: 성능 크리티컬부터

6부 — GitHub — 가장 큰 코드 저장소

규모

- Repos: 5억+
- 개발자: 1.5억+
- Git 데이터: 수 PB
- Actions: 분당 수백만 작업

아키텍처 진화

2008: Rails 모노리스 (시작)
~2016: MySQL + Redis + memcached
2020+: Spokes (Git storage), Kafka, Kubernetes 점진 도입
2022-: Microsoft 인수 후 Azure 마이그레이션 중

재미있는 엔지니어링

Monolith-first: 큰 Rails 앱을 여전히 유지
Spokes: Git을 분산 저장 (자체)
Codespaces: VS Code Server를 위한 Kubernetes 오케스트레이션
Copilot: OpenAI 협업

교훈

1. Rails는 여전히 유효: 올바르게 쓰면
2. Git 저장은 어렵다: 파일시스템 문제
3. Developer platform = 자체 코드: Codespaces는 GitHub dev 환경

7부 — Figma — 실시간 협업 혁명

기술적 도전

수십 명이 같은 캔버스 동시 편집
지연 50ms 이내 느껴야
Offline 편집 후 merge
Undo/Redo 혼란 없이

CRDT 기반 동시 편집

Conflict-free Replicated Data Types
각 편집은 commutative (순서 무관)
서버는 중재자, 최종 상태는 수렴

Figma의 데이터 모델:
- Node tree (DOM-like)
- 각 edit은 operation 타입
- WebSocket으로 실시간 sync

Rust 기반 core

Rust로 작성된 co-editor core
WASM으로 브라우저 실행
Native 수준 성능

교훈

1. 실시간 협업 = CRDT: Google Docs, Figma 모두
2. Web 앱이 Native를 대체: WASM 덕분
3. 회사 === 프로덕트: Figma는 프로덕트 집요함

8부 — Notion — 블록 기반 문서의 데이터 모델

데이터 모델

모든 것이 block
Page = block of blocks
Text, heading, list, code, ... 모두 block

Block 데이터 구조:
{
  id: "block_123",
  type: "paragraph",
  content: [...],
  parent: "block_456",
  children: ["block_789", ...],
  properties: {...}
}

특징: 재귀적 트리. 전 세계 Notion 사용자의 모든 데이터가 같은 구조.

Postgres + Caching

Primary: Postgres (모든 block)
Cache: Redis, Memcached
Search: Elasticsearch
AI: OpenAI embedding

2024 Growth: AI 기능 확대로 Postgres 부하 급증. Sharding 진화.

교훈

1. 데이터 모델이 전부: 잘 설계된 스키마는 확장 가능
2. 블록 = 유연성: "페이지" 중심이 아니라 "블록" 중심
3. Postgres의 힘: NoSQL 안 써도 Notion 스케일 가능

9부 — Spotify — 팀 구조와 아키텍처

Spotify Model (논란 있음)

Squad: 팀 (product area)
Tribe: 여러 Squad 묶음
Chapter: 같은 역할 (예: 백엔드 엔지니어)
Guild: 관심사 기반 커뮤니티

2024 현실: Spotify 자신도 "우리가 이 모델대로 안 함"이라고 공개. 교훈: 조직 구조는 회사마다 다르다. 템플릿 복사 X.

Backstage — 내부 개발자 포털

2020 오픈소스: 내부 도구를 외부로
기능: 서비스 카탈로그, 문서, TechDocs, 템플릿
CNCF 채택: Incubating 프로젝트

2025 현실: Platform Engineering의 표준 도구.

Event-driven

Kafka 중심 아키텍처
Play event → 수십 서비스에 broadcast
Recommendation은 이벤트 집계 기반

교훈

1. "Spotify Model"의 신화: 조직 구조는 일반화 어렵다
2. Internal platform → OSS: Backstage 방식
3. Event streaming = 유연성: 새 서비스 쉽게 추가

10부 — Airbnb — Monolith → Services → Monolith?

여정

2008-2017: Rails 모노리스
2017-2022: 마이크로서비스 이동 (복잡도 폭발)
2022+: 일부 재통합 ("macroservices")

교훈: 실수 공개. "마이크로서비스 너무 많이 쪼갰다, 일부 합치는 중."

발명품

• Airflow: 데이터 파이프라인 스케줄러 (2015, 지금 표준)
• Lottie: 벡터 애니메이션 (프론트엔드)
• Knowledge Graph: 검색/추천

교훈

1. 과도한 쪼개기 위험: MSA는 공짜 아님
2. Retrospective 문화: 실수 인정 + 수정
3. 주변 도구가 브랜드: Airflow가 회사 이미지

11부 — 공통 패턴 10가지

사례들에서 추출한 패턴:

1. 모노리스도 OK: Stripe, Shopify, GitHub — 규모 되는데 모노리스
2. 샤딩/Pod로 격리: Shopify Pod, Netflix region
3. Event-driven: Kafka 중심 (Spotify, Shopify, Netflix)
4. 자체 CDN/인프라: Netflix Open Connect, Cloudflare 자체 스택
5. Chaos Engineering: Netflix 시작, 업계 확산
6. 언어 섞어 쓰기: Rust(성능), Elixir/Erlang(동시성), Go(인프라)
7. GitHub 플로우: PR 리뷰 + CI + 자동 배포
8. 오픈소스 → 표준: Airflow, Kubernetes, Backstage, Sorbet
9. 포스트모템 공개: Cloudflare, GitLab 투명성
10. 도구 자체 개발 과감: 규모 되면 무조건

12부 — 따라할 것 vs 따라하지 말 것

따라할 것

• 강한 테스트 + CI/CD
• 포스트모템 문화
• Idempotency (Stripe 방식)
• Feature Flag
• 관측 가능성 (logs/metrics/traces)
• DORA 지표 측정

따라하지 말 것

• 7,000개 마이크로서비스 (Netflix) — 당신 회사 규모 X
• 자체 CDN 제작 (Netflix) — 호스팅 비용 충분히 크지 않으면 낭비
• Spotify Model 복사 — 조직 context 다름
• Rust로 전체 재작성 — 성능 병목 없으면 의미 X
• Kubernetes everything — 작은 스타트업엔 과함

13부 — 작은 회사의 사례

Plausible Analytics (10명):

• Elixir 모노리스
• ClickHouse for analytics
• Prod 서버 몇 대
• Open source, bootstrapped
• $2M+ ARR

Gumroad (수십 명):

• Rails 모노리스
• Postgres, Redis
• Heroku → AWS 이동
• Simple. 그게 포인트.

Bytebase (수십 명):

• Go + React
• SQLite (embedded) + Postgres 옵션
• CNCF 지향

교훈: 작은 팀일수록 단순함이 무기. 모노리스 + 한 DB로도 $100M+ 가능.

14부 — 체크리스트 12개

• 사례 연구로 본인 회사 비교
• Netflix의 Chaos Engineering 일부 도입 (간단한 것부터)
• Stripe의 Idempotency Key 구현
• Cloudflare의 포스트모템 읽기 (공개)
• Shopify의 Pod 격리 개념 적용
• Discord의 Rust for hot path
• Figma의 CRDT (실시간 협업 필요 시)
• Notion의 데이터 모델 학습
• Spotify의 Backstage (Platform)
• Airbnb의 "Macroservices" 생각
• 회사 사이즈 맞춤 도구 선택
• Postmortem 템플릿 우리도 도입

15부 — 안티패턴 10가지

1. Netflix 흉내 (대기업 방식) → 당신 회사 규모 X
2. 100명에 100개 서비스 → 운영 불가능
3. 자체 DB/언어 제작 → 10,000명 규모 아니면 낭비
4. 트렌드 따라감 → 안정성 희생
5. 포스트모템 비밀 → 같은 실수 반복
6. Chaos Engineering 준비 없이 → 그냥 장애
7. Kubernetes 강제 → 단순함 상실
8. Microservices + 강한 일관성 → 분산 트랜잭션 지옥
9. Rust everywhere → 팀 채용 어려움
10. Spotify Model 맹신 → 컨텍스트 무시

마무리 — "거인의 어깨 위에서"

Netflix, Stripe, Cloudflare는 천재들만 모인 곳이 아니다.

• 수년간 반복된 실수와 학습
• 투명한 포스트모템 (공개 자료 풍부)
• 대단한 규모에서 발견한 원칙

당신 회사 규모가 작다면 오히려 단순함의 무기를 가졌다. 큰 회사는 "그게 작을 때 왜 시작부터 Microservices 썼지"를 후회한다.

다음 글은 Season 3 Ep 2 — 유명 포스트모템 해부. Cloudflare 2022, Fastly 2021, AWS 2017, Heroku DNS 이슈, Knight Capital $440M 8분 등. 실패에서 배우는 게 가장 빠른 성장.

다음 글 예고 — "유명 포스트모템 해부: Cloudflare·Fastly·AWS·Knight Capital의 실패에서 배우기"

Season 3 Ep 2는:

• Cloudflare 2022-06 (BGP), 2019-07 (Regex)
• Fastly 2021-06 (한 고객 config → 인터넷 절반 다운)
• AWS S3 2017-02 (오타 하나로 us-east-1 다운)
• Knight Capital 2012 (8분만에 $440M 손실)
• GitLab 2017 (DB wipe)
• Common patterns

실패에서 더 빨리 배운다. 다음 글에서.