포스트

넷플릭스 vs 구글: 두 거인의 아키텍처 여정과 철학

게시
By BLUEBUG
51 분읽는 시간
넷플릭스 vs 구글: 두 거인의 아키텍처 여정과 철학

“넷플릭스는 AWS 위에서 세계 최대의 마이크로서비스 생태계를 구축했고,
구글은 자체 인프라로 Kubernetes의 아버지 Borg를 만들어 세상에 선물했다.
같은 목적지를 향해 전혀 다른 길을 걸은 두 회사의 이야기.”

프롤로그: 왜 이 두 회사를 비교하는가

2026년 1월 현재, 넷플릭스는 190개국 이상에서 3억 명 이상의 구독자에게 매달 수십억 시간의 비디오를 스트리밍한다. 구글은 하루 85억 건 이상의 검색을 처리하고, Gmail, YouTube, Google Maps를 포함한 수십 개의 서비스를 운영한다. 두 회사 모두 상상을 초월하는 규모에서 작동하지만, 그들이 택한 아키텍처 여정은 놀랍도록 다르다.

넷플릭스는 클라우드의 사도가 되었다. 2008년 치명적인 데이터베이스 장애 이후, 그들은 자체 데이터센터를 완전히 포기하고 Amazon Web Services로 이주하는 7년 여정을 시작했다. 오늘날 넷플릭스는 AWS 위에 구축된 1,000개 이상의 마이크로서비스를 운영하며, 클라우드 네이티브 아키텍처의 교과서가 되었다.

구글은 인프라의 철학자가 되었다. 2000년대 초, 그들은 수십만 대의 서버를 관리해야 하는 문제에 직면했고, Borg라는 내부 클러스터 관리 시스템을 구축했다. 10년 이상 Borg를 운영하면서 얻은 교훈을 바탕으로 2014년 Kubernetes를 오픈소스로 공개했고, 이는 전체 업계의 표준이 되었다.

이 문서는 두 회사의 아키텍처 철학, 기술 선택, 조직 문화를 비교하며, 왜 그들이 서로 다른 길을 택했는지, 그리고 우리가 무엇을 배울 수 있는지 탐구한다.

1부: 역사의 갈림길 - 서로 다른 출발점

1.1 넷플릭스: 재앙에서 태어난 변화

2008년 8월, 넷플릭스는 악몽을 경험했다. 데이터베이스 손상으로 인해 DVD 배송 서비스가 3일간 완전히 중단되었다. 당시 넷플릭스는 여전히 자체 데이터센터에서 모놀리식 애플리케이션을 운영하고 있었다. 이 사건은 회사의 존재 자체를 위협했다.

그들이 깨달은 것:

1
2
3
4
5
6
7
8
9
10
11

현재 상태 (2008):
- 단일 데이터센터
- 모놀리식 애플리케이션
- 수직 확장 (더 큰 서버 구매)
- 단일 실패 지점들

문제:
- 하드웨어 장애 = 전체 서비스 중단
- 확장 한계 (얼마나 큰 서버?)
- 느린 배포 (전체 재배포)
- 혁신 속도 제한

넷플릭스의 CEO Reed Hastings와 당시 클라우드 아키텍트였던 Adrian Cockcroft는 근본적인 결정을 내렸다. “우리는 데이터센터 운영 전문가가 되고 싶지 않다. 우리는 엔터테인먼트 회사다.”

그들의 선택:

1
2
3
4
5
6
7
8
9
10

목표:
- 99.99% 가용성
- 무한 확장성
- 빠른 혁신
- 재앙 대비 (Disaster Recovery)

솔루션:
→ AWS로 완전 이주
→ 마이크로서비스 아키텍처
→ 자체 데이터센터 폐쇄

이 결정은 당시로서는 매우 과감했다. 2008년 AWS는 S3와 EC2만 있었고, “미션 크리티컬” 워크로드를 클라우드에서 실행한다는 것은 거의 상상할 수 없었다. 하지만 넷플릭스는 베팅했고, 7년에 걸친 마이그레이션을 시작했다.

2016년, 마침내 완료: 넷플릭스는 자체 데이터센터의 마지막 서버를 끄고 100% 클라우드 기반 회사가 되었다. 이는 업계 역사상 가장 큰 클라우드 마이그레이션 중 하나였다.

1.2 구글: 필연에서 태어난 혁신

구글의 이야기는 다르다. 그들은 재앙이 아니라 성공의 무게에 직면했다.

2000년대 초, 구글은 폭발적으로 성장하고 있었다. 검색, Gmail, Maps, YouTube… 각 서비스는 수백만, 수십억 명의 사용자를 가지고 있었다. 그리고 각 서비스는 수천, 수만 대의 서버를 필요로 했다.

그들이 마주한 문제:

1
2
3
4
5
6
7
8
9
10

규모:
- 수십만 대의 서버
- 수백 개의 서비스
- 24시간 운영 필수

도전:
- 어떻게 관리하나?
- 수작업은 불가능
- 각 서비스마다 별도 팀?
- 리소스 낭비 (서버들이 대부분 유휴)

구글은 클라우드라는 옵션조차 없었다. AWS는 2006년에야 시작되었고, 구글의 규모와 요구사항을 만족시킬 수 있는 외부 제공자는 없었다. 그들은 스스로 해결해야 했다.

Borg의 탄생 (2003-2004년경):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

설계 원칙:
1. 머신을 공유 리소스 풀로 취급
   (개별 "애완동물"이 아니라)
   
2. 스케줄링의 공정성
   - Gmail과 검색이 같은 서버 공유
   - 우선순위와 할당량 기반
   
3. 높은 활용률
   - 레이턴시 민감 작업 (검색, Gmail)
   - 배치 작업 (MapReduce, 분석)
   - 둘을 같은 서버에서 실행
   → 리소스 활용률 70-80%
   
4. 복원력
   - 서버 장애 전제
   - 자동 재시작
   - 자가 치유

Borg는 구글 내부에서만 사용되었고, 10년 이상 외부에 알려지지 않았다. 구글은 2015년에야 “Large-scale cluster management at Google with Borg”라는 논문을 발표했다.

그리고 2014년, Kubernetes: 구글은 Borg의 교훈을 바탕으로 Kubernetes를 오픈소스로 만들었다. Borg를 직접 공개할 수 없었기 때문에 (너무 많은 구글 내부 시스템과 결합), 깨끗한 재구현을 선택했다.

왜 오픈소스로?

1
2
3
4
5
6
7
8
9
10
11
12

구글의 전략:
1. 업계 표준 만들기
   - 모든 클라우드가 Kubernetes 지원
   - Google Cloud도 경쟁력 확보
   
2. 인재 확보
   - 개발자들이 Kubernetes 학습
   - 구글에서 일하고 싶어함
   
3. 생태계 구축
   - 도구, 플러그인, 통합
   - 무료로 얻음

1.3 핵심 차이: “빌드” vs “바이”

넷플릭스와 구글의 출발점이 완전히 달랐던 이유는 간단하다.

넷플릭스:

1
2
3
4
5
6
7
8
9
10

질문: "데이터센터를 운영할 것인가?"
답변: "아니오. 우리의 핵심 역량이 아니다."

결과: AWS 선택
     클라우드 위에 구축
     마이크로서비스 아키텍처 채택
     
철학: "Buy" (구매)
     인프라는 상품화되었다
     우리는 비즈니스에 집중

구글:

1
2
3
4
5
6
7
8
9
10

질문: "외부 클라우드를 사용할 것인가?"
답변: "우리 규모를 처리할 수 없다."

결과: 자체 데이터센터 구축
     Borg/Kubernetes 개발
     모든 것을 직접 제어
     
철학: "Build" (구축)
     인프라가 경쟁 우위
     우리가 더 잘 할 수 있다

이 근본적인 차이가 그들의 아키텍처 여정을 결정했다.

2부: 아키텍처 철학 - 같은 목표, 다른 접근

2.1 넷플릭스: 클라우드 네이티브의 극한

넷플릭스의 아키텍처는 하나의 원칙으로 요약된다: “모든 것은 실패한다.”

Netflix Chaos Engineering:

1
2
3
4
5
6
7
8
9
10
11
12
13

철학:
"장애는 불가피하다.
 따라서 우리는 의도적으로 장애를 발생시켜 
 시스템이 견딜 수 있도록 훈련한다."

Chaos Monkey:
- 무작위로 프로덕션 서버 종료
- 영업시간 중에!
- 아무 경고 없이

Chaos Kong:
- 전체 AWS 리전 시뮬레이션 다운
- "만약 us-east-1이 사라진다면?"

이것은 미친 것처럼 들리지만, 논리는 명확하다. 프로덕션에서 장애를 테스트하지 않으면, 실제 장애가 발생했을 때 어떻게 반응할지 모른다.

마이크로서비스 설계 원칙:

1. 서비스 독립성

1
2
3
4
5
6
7
8
9
10

각 마이크로서비스는:
- 독립적으로 배포 가능
- 자체 데이터베이스 소유
- 다른 서비스 다운에도 작동
- API를 통해서만 통신

예시: 추천 서비스 다운
→ 사용자는 여전히 비디오 재생 가능
→ 기본 추천 목록 표시
→ 서비스 복구 시 정상화

2. 자동 복구 (Auto-remediation)

1
2
3
4
5
6
7

서비스 헬스 체크:
- 30초마다 상태 확인
- 3회 연속 실패 → 자동 재시작
- 재시작 실패 → 새 인스턴스 생성
- 로드 밸런서가 자동으로 트래픽 재분배

사람 개입 없음

3. 클라이언트 측 복원력

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Hystrix Circuit Breaker:

정상 상태:
Client → Service A → 응답 (50ms)

Service A 느려짐:
Client → Service A → 타임아웃 (5초)
→ 사용자 경험 악화

Circuit Open (자동):
Client -X-> Service A (호출 안 함)
      └→ Fallback 응답 (캐시 또는 기본값)
→ 빠른 실패 (Fast Fail)
→ Service A 복구 시간 확보

Circuit Half-Open (테스트):
일부 요청만 전송
성공하면 → Circuit Close

2.2 구글: 효율성과 통일성

구글의 아키텍처 철학은 다르다: “모든 것은 컨테이너다.”

Borg의 설계 원칙:

1. 리소스 최적화

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

문제:
- 검색 서비스: 하루 중 특정 시간 피크
- MapReduce 작업: 유휴 시간 활용

Borg 솔루션:
같은 서버에서 둘 다 실행

Priority 시스템:
- Prod (Production): 레이턴시 민감 (검색, Gmail)
- Non-Prod: 배치 작업

리소스 경합 시:
Prod 작업 우선
Non-Prod 작업 일시 중단 또는 종료

결과:
서버 활용률 60-80%
(일반적 데이터센터: 10-30%)
→ 전체 데이터센터 비용 절감

2. 통일된 추상화

1
2
3
4
5
6
7
8
9
10
11
12

모든 것이 컨테이너:
- Gmail 프론트엔드
- YouTube 인코딩
- MapReduce 작업
- Bigtable 스토리지
- 심지어 Borg 자체

장점:
- 단일 관리 인터페이스
- 표준화된 배포
- 일관된 모니터링
- 리소스 스케줄링 단순화

3. 선언적 설정

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

Borg Job 정의:

job: {
  name: "gmail-frontend"
  replicas: 1000
  cpu: 2.0
  memory: 4GB
  disk: 10GB
  
  constraints: {
    datacenter: ["us-central", "us-east"]
    machine_type: ["n1-standard"]
  }
}

Borg가 알아서:
- 적절한 서버 찾기
- 인스턴스 배포
- 헬스 체크
- 장애 시 재시작
- 리소스 모니터링

운영자는 "무엇"만 정의
"어떻게"는 Borg가 처리

2.3 핵심 차이: 신뢰의 위치

넷플릭스:

1
2
3
4
5
6
7
8
9

신뢰: 외부 (AWS)
전략: AWS는 장애를 처리
      우리는 애플리케이션 복원력에 집중

결과:
- Multi-AZ 배포
- Region 간 복제
- Chaos Engineering으로 검증
- 인프라 자체는 신경 안 씀

구글:

1
2
3
4
5
6
7
8
9

신뢰: 자신 (Borg)
전략: 우리가 인프라를 제어
      장애는 하드웨어 수준에서 처리

결과:
- 자체 데이터센터
- 커스텀 네트워킹 (Andromeda)
- 커스텀 스토리지 (Colossus)
- 모든 레이어 최적화

3부: 기술 스택 비교 - 도구의 선택

3.1 넷플릭스 스택 (2026년 현재)

컨트롤 플레인 (AWS):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

프론트엔드:
- React (웹)
- Swift/Kotlin (모바일)
- 다양한 TV OS별 네이티브 앱

API Gateway:
- Zuul 2 → Envoy 기반 (2026)
- TLS 종료
- 동적 라우팅
- 레이트 리미팅

GraphQL 레이어:
- Domain Graph Services (DGS)
- Federated GraphQL
- 각 도메인별 그래프 서비스

마이크로서비스 (1,000+):
- Java + Spring Boot (주력)
- Python (ML 파이프라인)
- Node.js (일부 서비스)
- Go (고성능 서비스)

서비스 디스커버리:
- Eureka (자체 개발)
- 서비스 자동 등록/탐색

로드 밸런싱:
- Ribbon (클라이언트 측)
- AWS ELB (서버 측)

복원력:
- Hystrix → Resilience4j (2026)
- Circuit Breaker
- Bulkhead
- Rate Limiting

데이터 레이어:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

NoSQL:
- Cassandra (주 스토리지)
  - 사용자 선호도
  - 시청 기록
  - 메타데이터
  
- DynamoDB (일부 워크로드)

캐싱:
- EVCache (Memcached 기반, 자체 개발)
- 초고속 읽기
- 전역 복제

관계형:
- MySQL (결제, 구독 정보)
- 트랜잭션 보장

스트리밍:
- Apache Kafka
- 실시간 이벤트 처리
- 로그 수집
- A/B 테스트 데이터

분석:
- S3 (Data Lake)
- Spark (처리)
- Presto (쿼리)

비디오 파이프라인:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

인코딩:
- FFmpeg (기본)
- VMAF (품질 평가, 자체 개발)
- Per-title encoding
- Shot-based encoding (2026)
- AV1 코덱 (20-30% 대역폭 절감)

AI 기반 최적화 (2025-2026):
- Film Grain Synthesis
- HDR 복원
- 자동 품질 검사

DRM:
- Widevine (Android, 크롬)
- FairPlay (Apple)
- PlayReady (기타)

패키징:
- DASH / HLS
- Adaptive Bitrate Streaming

데이터 플레인 (Open Connect):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

자체 CDN:
- 전 세계 ISP 내 캐시 서버
- OCA (Open Connect Appliance)
- 로컬 스토리지 페타바이트급

작동 방식:
1. 밤에 새 콘텐츠 배포 (Fill Window)
2. ISP 네트워크 내 OCA에 저장
3. 사용자 재생 시 가장 가까운 OCA에서 스트리밍
4. 레이턴시 최소화

결과:
- 글로벌 대역폭 비용 절감
- 빠른 스타트업 시간
- 버퍼링 최소화

AI/ML:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

추천 시스템:
- Multi-task Foundation Model (2025+)
- 사용자 선호도 학습
- 컨텍스트 인식

검색:
- Generative AI Search (2025)
- Entertainment Knowledge Graph
- 의미 기반 검색

개인화:
- 썸네일 개인화
- 순위 알고리즘
- 실시간 A/B 테스트

3.2 구글 스택 (2026년 현재)

Borg/Kubernetes 레이어:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Borg (내부):
- 여전히 구글 프로덕션의 핵심
- 수십만 대 서버 관리
- 컨테이너 수십억 개 스케줄링

Kubernetes (외부/일부 내부):
- GKE (Google Kubernetes Engine)
- 10주년 (2025)
- AI 워크로드 지원 강화
- Agent Sandbox (2026)
  - gVisor 기반 격리
  - LLM 생성 코드 안전 실행

컨테이너 런타임:
- gVisor (보안 강화)
- containerd
- CRI-O

서비스 메시:

1
2
3
4
5
6
7
8
9

Istio (오픈소스, 구글 주도):
- 서비스 간 통신 관리
- 트래픽 제어
- 보안 (mTLS)
- 관측성

Envoy Proxy:
- 고성능 프록시
- 레이어 7 로드 밸런싱

데이터 저장:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Bigtable:
- NoSQL, Wide-column
- Gmail, Google Maps 기반
- 페타바이트급 스케일

Spanner:
- 전역 분산 SQL
- ACID 트랜잭션
- 외부 일관성
- 자동 샤딩

Colossus:
- 분산 파일 시스템 (GFS 후속)
- YouTube 비디오 저장
- 페타바이트 단일 파일 가능

Firestore / Datastore:
- 문서 기반 NoSQL
- 앱 개발자용

네트워킹:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Andromeda:
- 소프트웨어 정의 네트워킹
- 가상 네트워크 오버레이
- 물리 네트워크와 분리

Jupiter:
- 데이터센터 패브릭
- 1 Petabit/sec 대역폭
- 커스텀 스위치

B4:
- 글로벌 WAN
- 소프트웨어 정의
- 트래픽 엔지니어링

검색 스택:

1
2
3
4
5
6
7
8
9
10
11
12

Caffeine:
- 웹 인덱싱 시스템
- 실시간 업데이트

MapReduce → Flume → Dataflow:
- 대규모 데이터 처리
- 배치 + 스트리밍

BigQuery:
- 서버리스 데이터 웨어하우스
- 페타바이트급 쿼리
- SQL 인터페이스

AI/ML:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

TensorFlow:
- 머신러닝 프레임워크
- 오픈소스
- 업계 표준

TPU (Tensor Processing Unit):
- 커스텀 AI 칩
- TensorFlow 최적화
- 클라우드에서 사용 가능

Vertex AI:
- 통합 ML 플랫폼
- AutoML
- MLOps

3.3 비교표: 넷플릭스 vs 구글

항목넷플릭스구글
인프라AWS (퍼블릭 클라우드)자체 데이터센터
컨테이너 오케스트레이션AWS ECS/EKS + 자체 도구Borg (내부) + Kubernetes
서비스 개수1,000+ 마이크로서비스수천 개 서비스
주 언어Java (Spring Boot)C++, Java, Python, Go
API 스타일REST → GraphQLgRPC, REST
서비스 디스커버리Eureka (자체)Borg Naming Service
로드 밸런싱Ribbon (클라이언트), ELBGSLB (Global Server Load Balancing)
데이터베이스Cassandra, DynamoDB, MySQLBigtable, Spanner, Megastore
캐싱EVCache (자체)다층 캐싱 (Memcached, …)
스트리밍KafkaPub/Sub
모니터링Atlas (자체), PrometheusBorgmon, Cloud Monitoring
로깅ELK Stack 변형Logs Explorer, BigQuery
배포Spinnaker (자체 개발)Borg 스케줄러, GKE
CDNOpen Connect (자체)Google Global Cache
ML 플랫폼자체 + AWS SageMakerTensorFlow + Vertex AI
CI/CDJenkins + SpinnakerInternal tools + Cloud Build

4부: 조직 철학 - 아키텍처는 조직을 반영한다

4.1 넷플릭스: “Freedom and Responsibility”

넷플릭스의 조직 문화는 전설적이다. 그들의 문화 덱 (Culture Deck)은 실리콘밸리에서 가장 많이 공유된 문서 중 하나다.

핵심 원칙:

1. 맥락, 통제가 아닌 (Context, not Control)

1
2
3
4
5
6
7
8
9
10
11
12

전통적 회사:
Manager: "이렇게 하세요."
Engineer: "네."

넷플릭스:
Manager: "우리 목표는 X입니다. 제약은 Y입니다."
Engineer: "이해했습니다. 방법은 제가 선택하겠습니다."

결과:
- 마이크로서비스 기술 스택 다양성
- 팀이 언어/프레임워크 선택
- 단, API 계약 준수 필수

2. 높은 인재 밀도 (High Talent Density)

1
2
3
4
5
6
7
8
9
10
11
12

철학:
"10명의 평범한 엔지니어보다
 1명의 탁월한 엔지니어가 낫다"

실천:
- "Keeper Test"
  "이 사람이 퇴사한다면 막을 것인가?"
  답이 "아니오"면 → 지금 놓아주기
  
- 최고 수준 급여
- 스톡옵션 대신 현금
- 무제한 휴가

3. 팀 자율성

1
2
3
4
5
6
7
8
9

각 마이크로서비스 팀:
- 완전한 소유권
- 기획부터 배포까지
- 24/7 온콜 책임
- "You build it, you run it"

Conway's Law 활용:
조직 구조 = 아키텍처
독립적 팀 = 독립적 서비스

4.2 구글: 데이터와 엔지니어링 우수성

링크에서 제공된 구글 조직문화 인사이트를 바탕으로:

핵심 원칙:

1. 지속적 전환 (Continuous Transformation)

1
2
3
4
5
6
7
8

지속적 개선을 넘어서:
- "다른 회사가 어떻게 했는가?" (X)
- "우리에게 맞는 해답은?" (O)

벤치마킹보다 혁신:
- Borg: 아무도 안 했던 것
- Bigtable: 새로운 데이터 모델
- Kubernetes: 업계에 선물

2. 원칙과 정책의 구분

1
2
3
4
5
6
7
8
9
10
11
12
13

원칙 (Principles):
- 변하지 않는 기초
- 10년+ 유지
- 예: "리드타임에 용량 결정"

정책 (Policies):
- 기술/시장에 따라 변경
- 6-12개월 주기
- 예: "리드타임 길이, 용량 단위"

장점:
- 변화 속에서도 안정성
- 하지만 민첩성 유지

3. 협업 > R&R

1
2
3
4
5
6
7
8
9
10
11
12
13

전통적 회사:
명확한 역할과 책임
"이건 내 일이 아니야"

구글:
- 모호한 목표 의도적 설정
- 개인 역량의 합으로 불가능한 과제
- 서로 강점 빌려야만 달성 가능
- 포커스 영역 (R&R 대신)

결과:
"누구의 일도 아닌 문제"에 
모두가 나서는 문화

4. 스폰서십 문화

1
2
3
4
5
6
7
8
9
10
11
12
13

멘토링 (Mentoring):
- 조언 제공
- 응원

스폰서십 (Sponsorship):
- 네트워크 활용
- 기회 창출
- 홍보
- 리소스 제공

구글의 강조:
A급 인재는 타고나는 것이 아니라
조직이 함께 만드는 것

4.3 조직 구조 비교

넷플릭스: 서비스 기반 팀

1
2
3
4
5
6
7
8
9
10
11
12

User Service Team (5-8명):
├─ Backend Engineers (3)
├─ Frontend Engineers (1)
├─ DevOps Engineer (1)
├─ QA Engineer (1)
└─ Product Manager (1)

완전 독립:
- 자체 백로그
- 자체 배포 일정
- 자체 기술 선택
- 자체 온콜

구글: 기능 + 레이어 하이브리드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Search Team (수백 명):
├─ Crawling
├─ Indexing
├─ Ranking
├─ Serving
└─ Infrastructure

공유 인프라:
- Borg (모든 팀 사용)
- Spanner (공통 DB)
- 네트워킹
- 보안

SRE (Site Reliability Engineering):
- 별도 조직
- 프로덕션 신뢰성 전담
- 개발팀과 협력

5부: 스케일의 차원 - 숫자로 보는 차이

5.1 넷플릭스 스케일 (2026 Q1 기준)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

사용자:
- 구독자: 300+ 백만
- 국가: 190+
- 동시 스트리밍: 수백만

트래픽:
- 월간 스트리밍: 수십억 시간
- 하루 이벤트: 1조+ (2023 기준)
- 피크 대역폭: 글로벌 인터넷 트래픽의 15%

데이터:
- 콘텐츠 라이브러리: 페타바이트급
- 사용자 데이터: 엑사바이트급
- Cassandra 클러스터: 수백 노드

인프라:
- AWS 리전: 다수
- 마이크로서비스: 1,000+
- Open Connect 서버: 수천 대 (ISP 내)

팀:
- 엔지니어: 수천 명 (전체 직원 ~13,000)
- 마이크로서비스당 평균 팀 크기: 5-8명

5.2 구글 스케일 (2026 추정)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

사용자:
- 검색 일일 쿼리: 85억+
- Gmail 사용자: 18억+
- YouTube 사용자: 25억+
- Maps 사용자: 10억+

트래픽:
- 글로벌 인터넷 트래픽: ~10-15%
- YouTube 시청 시간: 일 10억+ 시간

데이터:
- 데이터센터 수: 30+ (추정)
- 서버 수: 수백만 대 (추정)
- 저장 데이터: 엑사바이트급

인프라:
- Borg 관리 컨테이너: 수십억 개
- Bigtable 클러스터: 전 세계
- Spanner 노드: 수만 개

팀:
- 전체 직원: ~180,000
- 엔지니어: ~40,000-50,000 (추정)
- SRE: 수천 명

5.3 핵심 차이: 깊이 vs 폭

넷플릭스:

1
2
3
4
5
6
7
8
9
10
11
12
13

특징:
- 단일 비즈니스 (스트리밍)
- 매우 깊은 최적화
- 특정 워크로드에 특화

예시:
- 비디오 인코딩: 세계 최고 수준
- 개인화 알고리즘: 극도로 정교
- CDN 최적화: 엄청난 비용 절감

하지만:
- 다양성 낮음
- 한 분야에 집중

구글:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

특징:
- 다중 비즈니스 (검색, 광고, YouTube, Cloud, ...)
- 매우 넓은 범위
- 범용 인프라

예시:
- Borg: 모든 워크로드 처리
  (검색, Gmail, MapReduce, 비디오 인코딩, ...)
- Bigtable: 다양한 액세스 패턴
- Kubernetes: 모든 산업에 적용

장점:
- 재사용성
- 범용성
- 생태계

6부: 배운 교훈과 실수들

6.1 넷플릭스가 배운 것

1. 클라우드 마이그레이션의 현실

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

낙관적 예상 (2008):
"2-3년이면 완료"

현실 (2009-2016):
7년 소요

이유:
- 기술적 복잡성
- 조직 변화
- 새로운 도구 학습
- 문화 전환

교훈:
"클라우드 마이그레이션은 
 기술 프로젝트가 아니라
 비즈니스 전환이다"

2. 마이크로서비스의 대가

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

얻은 것:
- 독립적 확장
- 빠른 배포
- 팀 자율성
- 기술 다양성

지불한 것:
- 운영 복잡도
- 분산 디버깅
- 네트워크 레이턴시
- 데이터 일관성 문제

넷플릭스의 결론:
"우리 규모에서는 가치 있었다.
 하지만 모든 회사에게는 아니다."

3. Chaos Engineering의 가치

1
2
3
4
5
6
7
8
9
10
11
12
13

2011년 AWS US-East-1 장애:
- 많은 AWS 고객 다운
- 넷플릭스는 정상 운영

이유:
Chaos Monkey가 이미 준비시킴
- Multi-AZ 배포
- 자동 장애 조치
- 우아한 성능 저하

교훈:
"프로덕션에서 테스트하지 않으면
 프로덕션 장애 시 놀라게 된다"

6.2 구글이 배운 것

1. Borg의 한계

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

문제:
- 너무 구글 특화
- 내부 시스템 깊이 결합
- 외부 공개 불가능
- 학습 곡선 가파름

해결:
Kubernetes로 재설계
- 깨끗한 추상화
- 표준 API
- 확장 가능한 아키텍처
- 커뮤니티 친화적

교훈:
"내부 도구를 오픈소스로 만들려면
 처음부터 다시 만들어라"

2. 포트 관리의 악몽

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Borg 설계:
모든 컨테이너가 호스트 IP 공유
→ 포트를 리소스로 스케줄링
→ 애플리케이션이 할당된 포트 사용

문제:
- 포트 충돌
- 복잡한 설정
- 개발자 혼란

Kubernetes 개선:
각 Pod에 자체 IP
→ 포트 문제 사라짐
→ 훨씬 간단

교훈:
"네트워킹은 간단해야 한다"

3. 오픈소스의 힘

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Kubernetes 오픈소스 후:
- 기여자: 수만 명
- 플러그인/도구: 수천 개
- 기업 채택: 대부분
- 구글 혼자는 불가능했을 생태계

비용:
- 무료로 얻은 혁신
- 인재 유입
- 업계 표준

교훈:
"좋은 기술을 공유하면
 더 좋은 기술이 돌아온다"

7부: 미래 전망 - 2026년 이후

7.1 넷플릭스의 방향

AI 통합 심화

1
2
3
4
5
6
7
8
9
10

2025-2026 발표:
- Generative AI Search
- Multi-task Foundation Model
- Entertainment Knowledge Graph

미래 (2026-2030):
- AI 기반 콘텐츠 제작 도구
- 실시간 개인화 강화
- 예측적 캐싱 (AI가 시청 예측)
- 자동화된 A/B 테스트

Edge Computing 확대

1
2
3
4
5
6
7

현재: Open Connect (ISP 내 캐싱)

미래:
- 더 많은 로직을 Edge로
- 지연 시간 민감 기능
- 로컬 개인화
- 5G 네트워크 활용

코덱 혁신

1
2
3
4
5
6
7
8
9

AV1 → AV2:
- 추가 30% 대역폭 절감
- 더 나은 품질
- 더 빠른 인코딩

AI 기반 압축:
- Neural Codecs
- 학습된 압축
- 맞춤형 인코딩

7.2 구글의 방향

AI 인프라 강화

1
2
3
4
5
6
7
8
9
10

GKE 10주년 (2025) 발표:
- Agent Sandbox
- Kubernetes-native AI
- gVisor 격리

미래:
- AI-first 인프라
- LLM 워크로드 최적화
- 추론 가속화
- TPU 진화

Borg 차세대: Omega

1
2
3
4
5
6
7
8

Omega (이미 개발 중):
- 공유 상태 저장소
- 더 나은 스케줄링
- 더 빠른 배치

하지만:
Borg는 여전히 핵심
"작동하는 걸 고치지 마라"

Kubernetes 진화

1
2
3
4
5
6
7
8
9

웹어셈블리 (WASM) 통합:
- 경량 실행
- Edge에서 클라우드까지
- Fermyon 같은 플랫폼

Multi-cluster 관리:
- Fleet (GKE)
- 통합 제어 플레인
- 전역 부하 분산

7.3 수렴하는 트렌드

두 회사 모두:

1. AI 우선 (AI-First)

1
2
3
4
5
6

모든 것에 AI:
- 인프라 관리
- 리소스 최적화
- 이상 탐지
- 자동 복구
- 용량 계획

2. 지속 가능성 (Sustainability)

1
2
3
4
5

탄소 배출 감소:
- 에너지 효율적 데이터센터
- 재생 가능 에너지
- 효율적인 코덱
- 워크로드 최적화

3. Edge + Cloud 하이브리드

1
2
3
4

컴퓨팅 분산:
- 중앙 데이터센터 (훈련, 저장)
- Edge (추론, 캐싱)
- Device (개인화)

결론: 다른 길, 같은 목적지

교훈 1: 컨텍스트가 모든 것이다

넷플릭스와 구글은 완전히 다른 길을 택했지만, 둘 다 성공했다. 왜일까?

1
2
3
4
5
6
7
8
9
10
11

넷플릭스:
- 단일 비즈니스 (스트리밍)
- 빠른 혁신 필요
- 인프라는 차별화 아님
→ 클라우드 + 마이크로서비스

구글:
- 다중 비즈니스
- 극한의 규모
- 인프라가 경쟁 우위
→ 자체 인프라 + Borg

핵심: 자신의 비즈니스 컨텍스트에 맞는 선택을 했다.

교훈 2: 조직과 아키텍처는 하나다

Conway’s Law는 피할 수 없다.

1
2
3
4
5
6
7
8
9

넷플릭스:
독립적 팀 → 독립적 서비스
"Freedom and Responsibility"
→ 마이크로서비스 자연스러움

구글:
거대 조직, 공유 인프라
엔지니어링 우수성 강조
→ 통일된 플랫폼 필요

핵심: 아키텍처를 바꾸려면 조직을 바꿔야 한다.

교훈 3: 오픈소스의 힘

구글이 Kubernetes를 오픈소스로 만든 것은 업계 전체를 바꿨다.

1
2
3
4
5
6
7
8
9

직접 효과:
- Kubernetes = 업계 표준
- Google Cloud 경쟁력
- 인재 유입

간접 효과:
- 넷플릭스도 Kubernetes 활용
- 모든 클라우드가 지원
- 생태계 폭발

핵심: 때로는 나누는 것이 독점하는 것보다 가치 있다.

교훈 4: 완벽함보다 진화

두 회사 모두 완벽한 아키텍처로 시작하지 않았다.

1
2
3
4
5
6
7
8
9
10
11
12

넷플릭스:
모놀리스 (2008)
→ 7년 마이그레이션
→ 마이크로서비스 (2016)
→ 지속적 진화 (2026)

구글:
다양한 시스템들
→ Borg (2003)
→ Omega (진행중)
→ Kubernetes (2014)
→ 계속 개선

핵심: 진화하는 시스템이 설계된 시스템을 이긴다.

최종 조언: 당신의 길을 찾아라

넷플릭스처럼 해야 하는 경우:

1
2
3
4
5

✓ 단일 비즈니스/제품
✓ 빠른 혁신 필요
✓ 팀 자율성 중요
✓ 클라우드 비용 < 데이터센터 비용
✓ 인프라 전문성 불필요

구글처럼 해야 하는 경우:

1
2
3
4
5

✓ 극한의 규모
✓ 다중 비즈니스
✓ 인프라가 경쟁 우위
✓ 커스텀 하드웨어 필요
✓ 장기 최적화 가능

대부분의 회사:

1
2
3
4

→ 둘 사이 어딘가
→ 하이브리드 접근
→ 작게 시작
→ 필요에 따라 진화

에필로그: 2026년의 통찰

2026년 1월 현재, 넷플릭스와 구글은 여전히 서로 다른 길을 걷고 있다. 하지만 흥미롭게도, 그들은 점점 더 많은 것을 공유하고 있다.

넷플릭스는:

  • Kubernetes를 일부 워크로드에 채택
  • 자체 인프라 (Open Connect) 확대
  • AI 인프라에 투자

구글은:

  • Kubernetes를 더 클라우드 친화적으로
  • GKE Autopilot (관리형 서비스)
  • “Boring Technology” 수용

두 회사 모두 깨달았다:

1
2
3

"완벽한 아키텍처는 없다.
 완벽한 선택도 없다.
 컨텍스트에 맞는 선택만 있을 뿐이다."

당신의 회사, 당신의 팀, 당신의 비즈니스에 맞는 아키텍처를 선택하라. 넷플릭스도, 구글도 아닌, 당신만의 길을 찾아라.

참고 자료

넷플릭스:

  1. “Netflix Architecture: A Look Into Its System Architecture in 2026” - ClickIT Tech (2025년 12월)
  2. “Inside Netflix’s Architecture: How It Handles Billions of Views Seamlessly” - Rocky Bhatia (2025년 3월)
  3. “Netflix Tech Stack Explained: CDN, Microservices” - VdoCipher (2025년 10월)
  4. “Understanding design of microservices architecture at Netflix” - TechAhead (2025)
  5. “Netflix Microservices Architecture Guide” - Yochana (2025년 6월)
  6. Netflix Tech Blog - https://netflixtechblog.com/
  7. “Adopting Microservices at Netflix” - F5/NGINX

구글:

  1. “Large-scale cluster management at Google with Borg” - Google Research (2015)
  2. “Borg, Omega, and Kubernetes” - ACM Queue
  3. “Borg: The Predecessor to Kubernetes” - Kubernetes Blog (2015)
  4. “GKE and Kubernetes at KubeCon 2025” - Google Cloud Blog (2025년 11월)
  5. “How Google’s Borg Became Kubernetes” - TechPreneur (2025년 8월)
  6. “What on earth is Kubernetes?” - Kyle Jeong (2026)
  7. “The Growth of Containers and Kubernetes Architecture” - TechAhead (2025년 11월)

조직 문화:

  1. “AI 시대, 변화에 흔들리지 않는 구글 조직문화와 인재경영 사례” - Ringle (2025년 10월)
  2. Netflix Culture Deck
  3. “Work Rules!” - Laszlo Bock (구글 전 HR 수석 부사장)

기타:

  1. “Building Microservices” - Sam Newman
  2. “Site Reliability Engineering” - Google
  3. “The Phoenix Project” - Gene Kim

작성 일자: 2026-01-10

저자 노트:
이 문서는 넷플릭스와 구글의 공개된 아키텍처 정보, 기술 블로그, 학술 논문, 그리고 조직문화 자료를 바탕으로 작성되었습니다. 두 회사는 완전히 다른 길을 택했지만, 각자의 컨텍스트에서 최적의 선택을 했습니다.

중요한 것은 “넷플릭스처럼” 또는 “구글처럼” 하는 것이 아니라, 당신의 비즈니스, 팀, 그리고 목표에 맞는 아키텍처를 선택하는 것입니다. 트렌드를 따르지 말고, 문제를 해결하십시오.

TechStack, Architecture
Architecture Microservices Netflix Google Kubernetes Borg infrastructure distributed-systems cloud-native case-study Architect Claude.write
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.