---
id: P-REINFORCE-AUTO-6271CF
category: "10_Wiki/💡 Topics/Programming & Language"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환"
---

# [[넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환|넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> 넷플릭스는 시스템 확장성과 혁신 속도를 높이기 위해 7년에 걸쳐 기존 모놀리식 데이터센터 환경을 마이크로서비스 아키텍처로 성공적으로 전환했습니다 [1, 2]. 이어 미디어 파일 처리 파이프라인인 '리로디드(Reloaded)' 시스템의 운영 복잡성 한계를 극복하기 위해, '코스모스(Cosmos)' 플랫폼을 도입했습니다 [3-5]. 코스모스는 마이크로서비스에 비동기 워크플로우와 서버리스 함수를 결합한 혁신적인 플랫폼으로, API, 워크플로우, 서버리스 계층을 명확히 분할하는 '관심사의 분리(Separation of Concerns)'를 구현하여 개발 생산성과 시스템 안정성을 대폭 향상시켰습니다 [6-8].

## 📖 구조화된 지식 (Synthesized Content)
* **마이크로서비스 아키텍처로의 기반 전환:**
  넷플릭스의 초기 모놀리식 아키텍처는 긴밀한 결합으로 인해 유연한 확장과 혁신에 걸림돌이 되었습니다 [2]. 넷플릭스는 7년이라는 기간 동안 이를 무상태(Stateless) 서비스 기반의 마이크로서비스 아키텍처로 전환하며 수평적 확장(Scale out)을 이뤄냈습니다 [1, 2]. 또한, 관계형 데이터베이스(RDBMS)를 탈피해 다중 지역 복제가 가능하고 가용성이 높은 카산드라(Cassandra)로 전환했으며, 카오스 몽키(Chaos Monkey)를 통한 파괴 테스트를 자동화하여 99.999%의 가용성을 목표로 하는 높은 신뢰성을 확보했습니다 [9, 10].

* **레거시 시스템 '리로디드(Reloaded)'의 한계와 코스모스(Cosmos)의 탄생:**
  넷플릭스의 미디어 클라우드 엔지니어링 팀은 미디어 처리를 위해 3세대 시스템인 '리로디드'를 약 7년간 운영했습니다 [3]. 그러나 시스템의 규모가 10배 이상 커지고 기능이 복잡해짐에 따라, 기존의 모놀리식 구조와 중앙 집중식 데이터 모델은 기능 배포를 지연시키는 부채로 작용했습니다 [3, 4]. 인프라와 애플리케이션 코드가 혼재된 복잡성을 해결하기 위해, 넷플릭스는 스트랭글러 피그(Strangler Fig) 패턴을 적용하여 레거시 시스템을 점진적으로 대체하는 워크플로우 기반 마이크로서비스 플랫폼 '코스모스'를 개발했습니다 [5, 11].

* **다차원적 관심사 분리(SoC)를 적용한 코스모스 아키텍처:**
  코스모스는 단순한 마이크로서비스를 넘어 복잡한 비동기 워크플로우와 컴퓨팅 집약적인 서버리스 함수를 융합했습니다 [6, 12]. 애플리케이션의 비즈니스 로직과 플랫폼의 인프라 세부 사항을 격리하고, 논리를 세 가지 주요 하위 시스템으로 분리하는 고도의 관심사 분리를 적용했습니다 [7, 8].
  * **옵티머스(Optimus):** 외부의 요청을 내부 비즈니스 모델로 매핑하는 API 계층입니다 [13].
  * **플라토(Plato):** 비즈니스 규칙을 모델링하는 워크플로우 계층으로, 포워드 체이닝(Forward Chaining) 규칙 엔진을 사용하여 항상 켜져 있는 비동기 워크플로우 생성을 지원합니다 [13, 14].
  * **스트라툼(Stratum):** 무상태(Stateless) 및 컴퓨팅 집약적 알고리즘을 수행하는 서버리스 함수 계층입니다 [13].
  이 세 가지 하위 시스템은 대규모 저지연 우선순위 대기열 시스템인 타임스톤(Timestone)을 통해 비동기적으로 상호 통신하여 결합도를 극도로 낮추었습니다 [8, 13].

* **워크로드 특성에 따른 성능 최적화:**
  코스모스 플랫폼은 다수의 서비스를 오케스트레이션하여 워크로드를 관리합니다. 수백만 CPU 시간을 소비하며 장시간 미디어를 처리하는 타파스(Tapas)와 같은 처리량 민감형 서비스와, 사용자의 즉각적인 반응을 처리해야 하는 세이건(Sagan) 같은 지연 시간 민감형 서비스를 모두 지원합니다 [15-18]. 서버리스 계층인 스트라툼은 지연 시간을 단축하기 위해 리소스 풀 활용, 웜(Warm) 용량 사전 대기, 함수 시작 비용을 분산하는 마이크로 배치(Micro-batches) 적용, 그리고 중요도에 따른 우선순위 스케줄링 방식을 도입했습니다 [19].

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[마이크로서비스 아키텍처 (Microservices Architecture)|마이크로서비스 아키텍처(Microservices Architecture)]], [[관심사의 분리(Separation of Concerns)|관심사의 분리(Separation of Concerns)]], [[서버리스 컴퓨팅(Serverless Computing)|서버리스 컴퓨팅(Serverless Computing)]], [[카오스 몽키(Chaos Monkey)|카오스 몽키(Chaos Monkey)]], [[카산드라(Cassandra)|카산드라(Cassandra)]]
- **Projects/Contexts:** [[리로디드(Reloaded)|리로디드(Reloaded)]], [[코스모스(Cosmos)|코스모스(Cosmos)]], [[타파스(Tapas)|타파스(Tapas)]], [[스트랭글러 피그 패턴(Strangler Fig Pattern)|스트랭글러 피그 패턴(Strangler Fig Pattern)]]
- **Contradictions/Notes:** 마이크로서비스 전환은 넷플릭스에 조직적 민첩성과 신뢰성을 가져다주었지만, 개발자가 분산 시스템 내 서비스 통신을 직접 구현해야 하는 복잡성이 증가하고 N개의 모놀리식 앱이 N*M개의 서비스로 확장되면서 막대한 메모리 및 JVM 오버헤드가 발생한다는 단점도 보고되었습니다 [20-23]. 이러한 한계를 극복하고자 넷플릭스는 단순한 API 호출 방식을 넘어, "마이크로서비스가 워크플로우를 트리거하고, 서버리스 함수를 오케스트레이션하는" 방식으로 플랫폼 아키텍처(코스모스)를 진화시켰습니다 [24].

---
*Last updated: 2026-04-18*
- Raw Source: 00_Raw/2026-04-20/넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환.md
---