---
category: Unified
tags: [auto-consolidated, technical-documentation]
title: [[Cosmos 플랫폼 (Netflix)|Cosmos 플랫폼 (Netflix]]
last_updated: 2026-05-02
---

# [[Cosmos 플랫폼 (Netflix)|Cosmos 플랫폼 (Netflix]]

## 📌 Brief Summary
> Cosmos는 넷플릭스(Netflix)가 마이크로서비스, 비동기 워크플로우, 서버리스 함수의 장점을 결합하여 구축한 컴퓨팅 플랫폼이다 [1]. 기존 모놀리식 아키텍처인 'Reloaded'의 한계를 극복하고 관측성, 모듈성, 생산성, 지속적 배포(Continuous Delivery)를 향상시키기 위해 개발되었다 [2, 3]. 수 분에서 수년에 걸쳐 실행되는 복잡한 계층적 워크플로우 및 리소스 집약적인 알고리즘을 조율하는 데 최적화되어 있으며, 대규모 처리량과 지연 시간에 민감한 작업 부하를 모두 지원한다 [1].

---

> 넷플릭스 코스모스 플랫폼(Netflix Cosmos)은 마이크로서비스의 장점과 비동기 워크플로우 및 서버리스 함수를 결합한 컴퓨팅 플랫폼이다 [1]. 이 플랫폼은 주로 수 분에서 수 년까지 지속될 수 있는 복잡하고 계층적인 워크플로우를 통해 조정되는 자원 집약적 알고리즘을 처리하는 데 사용된다 [1]. 기존의 모놀리식 아키텍처인 '리로디드(Reloaded)'의 한계를 극복하고 관찰성, 모듈성, 생산성, 자동화된 전송 능력을 향상시키기 위해 개발되었다 [2-4].

## 📖 Core Content
* **배경 및 점진적 전환:** 넷플릭스의 기존 미디어 처리 시스템인 'Reloaded'는 개발팀 규모가 커짐에 따라 인프라와 애플리케이션 코드가 뒤섞이고 새로운 기능 배포가 지연되는 모놀리식 아키텍처의 한계를 겪었다 [2]. 이를 해결하기 위해 워크플로우 기반 미디어 특화 마이크로서비스 플랫폼인 Cosmos가 구축되었으며, 시스템을 완전히 교체할 때까지 기존 시스템 주위를 감싸며 새로운 시스템을 성장시키는 '스트랭글러 피그(Str[[ANGLE|ANGLE]]r fig) 패턴'을 도입하여 위험을 줄이면서 마이그레이션을 진행했다 [3, 4].
* **다차원적 관심사의 분리 ([[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]]):** Cosmos는 로직을 API, 워크플로우, 서버리스 함수로 나누는 한편, 도메인 특화 애플리케이션 로직과 분산 컴퓨팅을 처리하는 플랫폼으로 분리하는 양방향 관심사 분리 원칙을 적용했다 [5]. 분산 처리를 담당하는 플랫폼은 세 가지 주요 하위 시스템과 이를 연결하는 큐잉 시스템으로 구성된다 [6].
    * **Optimus:** 외부 요청을 내부 비즈니스 모델로 매핑하는 API 계층이다 [6].
    * **Plato:** 비즈니스 규칙을 모델링하는 워크플로우 계층으로, 'Emirax'라는 도메인 특화 언어(DSL)를 사용하는 포워드 체이닝(forward chaining) 규칙 엔진을 기반으로 설계되었다 [6-8].
    * **Stratum:** 상태가 없으며 계산 집약적인 알고리즘을 실행하는 서버리스 계층이다 [6].
    * **Timestone:** 위의 하위 시스템들이 비동기적으로 통신할 수 있도록 돕는 대규모 저지연 우선순위 큐잉 시스템이다 [6].
* **지연 시간 관리 및 활용 사례:** Cosmos는 서비스의 분해와 계층화를 지원하여 스튜디오에서 들어오는 미디어 소스를 처리하는 대규모 처리량 중심의 고위급 서비스인 'Tapas'와, 사용자 대면 작업으로 지연 시간에 민감한 'Sagan' 등의 다양한 서비스를 효율적으로 오케스트레이션한다 [9-12]. 수요 폭증 시 발생하는 지연 문제를 해결하기 위해 Stratum은 리소스 풀(Resource pools) 설정, 사전 확보된 웜 용량(Warm capacity), 컨테이너 시작 비용을 분산하는 마이크로 배치(Micro-batches), 작업의 우선순위(Priority) 지정 등의 전략을 활용한다 [13].

---

*   **배경 및 개발 목적:** 넷플릭스는 기존의 모놀리식 미디어 처리 시스템인 '리로디드(Reloaded)'가 규모의 확장과 개발자 수의 증가로 인해 새로운 기능 배포를 지연시키고 운영 부담을 가중시키는 문제에 직면했다 [2, 3]. 이에 대응하여 관찰성(Observability), 모듈성([[Modularity|Modularity]]), 생산성(Productivity), 지속적 배포(Delivery)를 제공하는 워크플로우 중심의 미디어 특화 마이크로서비스 플랫폼인 코스모스를 구축하게 되었다 [4]. 기존 시스템을 점진적으로 안전하게 대체하기 위해 '스트랭글러 피그(str[[ANGLE|ANGLE]]r fig)' 패턴을 채택하였다 [5].

*   **아키텍처 및 관심사의 분리 ([[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]]):** 코스모스는 애플리케이션과 플랫폼의 로직을 분리하여, 개발자가 분산 컴퓨팅의 세부 사항을 알 필요 없이 미디어 특화 추상화에 집중할 수 있게 한다 [6, 7]. 비즈니스 로직은 다음과 같은 세 가지 스케일 인식(scale-aware) 하위 시스템으로 나뉘어 관리된다 [6-8].
    *   **옵티머스(Optimus):** 외부 요청을 내부 비즈니스 모델로 매핑하는 API 계층이다 [7, 8].
    *   **플라토(Plato):** 비즈니스 규칙 모델링을 위한 워크플로우 계층으로, 'Emirax'라는 도메인 특화 언어를 사용하는 전방 추론(forward chaining) 규칙 엔진이다 [7-10].
    *   **스트라툼(Stratum):** 무상태([[State|State]]less) 및 컴퓨팅 집약적인 함수를 실행하기 위한 서버리스 계층이다. 유연한 리소스 스케줄링을 지원하며 타이투스(Titus) 컨테이너 플랫폼 위에 구축되었다 [7, 8, 11].

*   **비동기 통신 시스템:** 코스모스의 하위 시스템들은 대규모, 저지연 우선순위 대기열 시스템인 **타임스톤(Timestone)** 을 통해 서로 비동기적으로 통신한다 [7, 8].

*   **지연 시간 및 처리량 관리:** 사용자 대면 서비스와 같은 지연 시간 민감(Latency-sensitive) 애플리케이션을 위해 스트라툼은 리소스 풀, 웜 커패시티(Warm capacity), 마이크로 배치(Micro-batches), 우선순위 설정을 통해 함수 실행 지연 시간을 관리한다 [12, 13]. 반면 리소스를 대량으로 소비하는 처리량 민감(Throughput-sensitive) 워크로드의 경우, 더 저렴한 '기회주의적(opportunistic)' 컴퓨팅 리소스를 활용할 수 있도록 유연하게 스케줄링한다 [11].

## ⚖️ Trade-offs & Caveats
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

---

- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

## 🔗 Knowledge Connections
- **Related Topics:** 마이크로서비스 (Microservices), 서버리스 컴퓨팅 (Serverless Computing), [[관심사의 분리 (Separation of Concerns)|관심사의 분리 (Separation of Concerns]]
- **Projects/Contexts:** Reloaded, Optimus, Plato, Stratum, Timestone, Tapas, Sagan
- **Contradictions/Notes:** "서버리스 함수를 조율하는 워크플로우를 트리거하는 마이크로서비스"라는 Cosmos의 프로그래밍 모델은 강력하지만, 단순한 애플리케이션에 적용하기에는 부가되는 복잡성이 이점보다 클 수 있다는 점이 지적된다 [14]. 또한, Cosmos 플랫폼 도입 당시 애플리케이션 개발자들은 일관성과 신뢰성을 획득하는 대신 일정한 유연성을 포기하는 방향으로 마인드셋을 전환해야 했다 [14].

---
*Last updated: 2026-04-18*

---

---

- **Related Topics:** 마이크로서비스 (Microservices), [[관심사의 분리 (Separation of Concerns)|관심사의 분리 (Separation of Concerns]], 서버리스 컴퓨팅 (Serverless Computing)
- **Projects/Contexts:** 리로디드 (Reloaded), 타파스 (Tapas), 사간 (Sagan), 스트랭글러 피그 패턴 (Strangler fig pattern)
- **Contradictions/Notes:** 소스에 따르면, 코스모스 서비스는 전형적인 마이크로서비스와 유사한 점이 있으나 완전히 같지는 않다. 일반적인 마이크로서비스가 무상태 비즈니스 로직을 가진 API로 요청 부하에 따라 자동 확장되는 반면, 코스모스는 다단계 워크플로우와 컴퓨팅 집약적인 비동기 서버리스 함수를 결합하고 있으며 큐(queue)의 크기에 따라 확장된다는 차이가 존재한다 [14]. 

---
*Last updated: 2026-04-18*

---
