45 lines
4.2 KiB
Markdown
45 lines
4.2 KiB
Markdown
---
|
|
id: P-REINFORCE-AUTO-2F7488
|
|
category: "[[10_Wiki/💡 Topics/Programming & Language]]"
|
|
confidence_score: 0.90
|
|
tags: [auto-reinforced]
|
|
last_reinforced: 2026-04-20
|
|
github_commit: "[P-Reinforce] Continuous Worker - 코스모스(Cosmos)"
|
|
---
|
|
|
|
# [[코스모스(Cosmos)]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> 지식 요약 정보 추출 중...
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
* **플랫폼 도입 배경 및 목적:**
|
|
넷플릭스는 이전에 파트너와 스튜디오에서 들어오는 미디어 파일을 처리하기 위해 'Reloaded'라는 모놀리식 아키텍처를 사용했습니다 [4]. 하지만 개발자 규모가 늘어나고 처리 규모가 10배 이상 커지면서, 기존 아키텍처는 기능 배포를 지연시키고 운영에 큰 부담을 주는 부채가 되었습니다 [2]. 이에 대응하기 위해 인프라와 애플리케이션 코드가 뒤섞이는 문제를 해결하고, 워크플로우 중심의 미디어 특화 마이크로서비스를 위한 새로운 플랫폼인 코스모스를 개발하게 되었습니다 [2, 3, 5].
|
|
|
|
* **관심사의 분리(Separation of Concerns) 구조:**
|
|
코스모스는 두 가지 축으로 관심사를 분리합니다. 첫째, 로직을 API, 워크플로우, 서버리스 함수로 분할합니다 [6]. 둘째, 플랫폼과 애플리케이션을 분리하여 애플리케이션 개발자가 분산 컴퓨팅의 복잡한 세부 사항(데이터 배포 등)을 몰라도 미디어 특화 추상화를 통해 비즈니스 로직에만 집중할 수 있게 합니다 [6].
|
|
|
|
* **주요 하위 시스템(Subsystems):**
|
|
도메인 특화 및 확장 독립적(scale-agnostic)인 컴포넌트들은 다음의 세 가지 확장 인지(scale-aware) 하위 시스템 위에서 동작합니다 [6, 7].
|
|
* **옵티머스(Optimus):** 외부 요청을 내부 비즈니스 모델로 매핑하는 API 계층입니다 [7].
|
|
* **플라토(Plato):** 비즈니스 규칙 모델링을 위한 워크플로우 계층으로, 'Emirax'(Groovy 기반 도메인 특화 언어)를 사용하는 전진 추론(forward chaining) 규칙 엔진입니다 [7-9].
|
|
* **스트라툼(Stratum):** 상태가 없고 계산 집약적인 알고리즘을 실행하기 위해 호출되는 서버리스 계층입니다 [7].
|
|
* 이 하위 시스템들은 대규모, 저지연의 우선순위 큐 시스템인 **타임스톤(Timestone)**을 통해 비동기적으로 서로 통신합니다 [7].
|
|
|
|
* **워크로드 처리 전략:**
|
|
코스모스는 사용자 대기 시간이 중요한 '지연 시간에 민감한(Latency-sensitive)' 워크로드와 자원을 대량 소비하며 하루당 처리량이 중요한 '처리량에 민감한(Throughput-sensitive)' 워크로드를 모두 지원합니다 [1, 10, 11]. 특히 지연 시간을 관리하기 위해 자원 풀(Resource pools), 사전 컴퓨팅 자원 확보(Warm capacity), 마이크로 배치(Micro-batches), 작업 우선순위(Priority) 지정 등의 메커니즘을 사용합니다 [12].
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- **Related Topics:** [[Microservices]], [[Serverless Computing]], [[Separation of Concerns]], [[Workflow]]
|
|
- **Projects/Contexts:** [[Netflix Media Cloud Engineering]], [[Reloaded (Netflix Legacy System)]], [[Tapas (Netflix Service)]]
|
|
- **Contradictions/Notes:** 넷플릭스는 기존의 거대하고 복잡한 레거시 시스템(Reloaded)에서 코스모스로 전환하는 데 따른 위험을 줄이기 위해, 새로운 시스템이 기존 시스템을 둘러싸면서 점진적으로 완전히 대체하는 스트랭글러 피그(strangler fig) 패턴을 채택했습니다 [13]. 한편 "마이크로서비스가 워크플로우를 트리거하고 서버리스 함수를 오케스트레이션한다"는 코스모스의 프로그래밍 모델은 대부분의 사용 사례에 효과적이지만, 너무 단순한 애플리케이션의 경우에는 오히려 추가되는 복잡성이 이점보다 클 수 있다고 지적됩니다 [14].
|
|
|
|
---
|
|
*Last updated: 2026-04-18*
|
|
- Raw Source: [[00_Raw/2026-04-20/코스모스(Cosmos).md]]
|
|
---
|