넷플릭스는 어떻게 수백 TB의 카메라 원본을 클라우드에서 처리할까? MPS & FLAPI 사례

왜 넷플릭스는 자체 이미지 처리 엔진을 만들지 않았을까?

넷플릭스는 매일 수백 시간 분량, 수 TB에 달하는 카메라 원본 푸티지를 수집합니다. 전 세계 다양한 제작사, 카메라 포맷, 워크플로우를 지원하면서도 일관된 품질과 빠른 납기를 유지하는 것은 단순한 파일 관리 이상의 과제입니다.

초기에는 제작 현장마다 파일 처리 방식이 제각각이었고, 수동 작업으로 인한 휴먼 에러, 감사(Audit)의 어려움, 유사한 워크플로우를 매번 재구현해야 하는 비효율이 발생했습니다. 넷플릭스는 이를 해결하기 위해 **Content Hub Media Production Suite(MPS)**를 구축했습니다.

핵심 결정 중 하나는 이미지 처리 엔진을 처음부터 개발하지 않고, 업계에서 이미 검증된 FilmLight의 FLAPI를 통합한 점입니다. FilmLight는 Baselight, Daylight 등 컬러 그레이딩 및 데일리(Dailies) 툴로 유명한 회사입니다. 넷플릭스는 "모든 것을 직접 만들기보다, 전문 분야는 최고의 파트너와 협력한다"는 철학을 따랐습니다.

참고: 이 접근법은 단순한 API 연동을 넘어, 장기적인 공동 로드맵 조정과 오픈 스탠다드(ACES, ASC FDL)에 대한 피드백 루프를 만드는 전략적 협력 관계로 발전했습니다.

MPS의 핵심: FLAPI를 활용한 미디어 처리 엔진

MPS는 단일 애플리케이션이 아니라, 전 세계 넷플릭스 프로덕션을 지원하는 도구와 서비스의 생태계입니다. 그 중심에서 FLAPI는 두 가지 주요 역할을 수행합니다.

1. 카메라 메타데이터 검사(Inspection)

프로덕션에서 업로드된 미디어는 ASC MHL(Media Hash List)로 무결성을 확인한 후, FLAPI를 통해 기술적 특성을 분석합니다.

# FLAPI를 활용한 메타데이터 검사 예시 (개념 코드)
# 실제 코드는 Java/Python 기반 Docker 이미지로 패키징됩니다.

import flapi  # 가상의 FLAPI 래퍼

def inspect_clip(clip_path: str):
    """
    클립의 카메라 메타데이터를 추출하고 넷플릭스 표준 스키마로 변환합니다.
    """
    # FLAPI로 원본 파일 메타데이터 읽기
    metadata = flapi.parse_metadata(clip_path)
    
    # 표준 필드 매핑 (카메라 모델, 코덱, 프레임 레이트, 해상도 등)
    normalized = {
        "camera_model": metadata.get("cameraModel"),
        "codec": metadata.get("videoCodec"),
        "frame_rate": metadata.get("frameRate"),
        "resolution": f"{metadata.get('width')}x{metadata.get('height')}",
        "reel_name": metadata.get("reelName"),
        "timecode_start": metadata.get("startTimecode"),
        "color_space": metadata.get("colorSpace")
    }
    return normalized

# 결과는 다운스트림 프로세스에서 검색 가능하고 재사용 가능
# -> 매칭, 디버깅, 검증에 활용

이 메타데이터는 타임코드 기반 자동 매칭, 샷 디버깅, 파이프라인 전반의 유효성 검사에 사용됩니다. FLAPI는 Docker 이미지로 패키징되어 클라우드와 온프레미스 컴퓨팅 센터에 동일하게 배포되므로, 전 세계 어디서 촬영된 푸티지든 일관된 평가가 가능합니다.

2. VFX 플레이트 및 결과물 생성

VFX 워크플로우는 이미지 처리 파이프라인의 극한을 요구합니다. MPS는 정확한 프레이밍, 일관된 컬러 매니지먼트, 올바른 디베이어/디코딩을 유지하면서 빠른 처리 시간을 보장해야 합니다.

# VFX 플레이트 생성 파이프라인 예시 (개념 코드)
# FLAPI + ACES + ASC FDL 조합

def generate_vfx_plate(clip_path, framing_decision_list, aces_metadata):
    """
    VFX 플레이트를 생성합니다.
    - 디베이어: 카메라 원본을 올바른 포맷으로 디코딩
    - 크롭/디스퀴즈: ASC FDL에 따라 프레이밍 결정 반영
    - 컬러 파이프라인: ACES Metadata File(AMF) 적용
    """
    # 1. 디베이어 및 디코딩
    raw_image = flapi.debayer(clip_path, params={"decode_format": "ARRI_RAW"})
    
    # 2. 프레이밍 결정 적용 (ASC FDL)
    framed_image = flapi.crop_and_desqueeze(raw_image, framing_decision_list)
    
    # 3. ACES 컬러 파이프라인 적용
    final_image = flapi.apply_aces(framed_image, aces_metadata)
    
    # 4. OpenEXR + AMF 메타데이터와 함께 저장
    flapi.write_exr(final_image, "output/vfx_plate_001.exr", metadata=aces_metadata)
    
    return "output/vfx_plate_001.exr"

이 과정은 완전 자동화되어 있으며, 감사 가능(Auditable)합니다. AMF를 OpenEXR과 함께 전달함으로써 수신자가 어떤 컬러 변환이 적용되었는지 정확히 알 수 있어, 데일리와 일치하는 최종 결과물을 보장합니다.

클라우드 미디어 처리 공장: 탄력적 확장의 핵심

전통적인 영상 처리 모델은 고성능 GPU와 대용량 스토리지에 투자하는 것이었지만, 넷플릭스는 클라우드 환경의 제약을 오히려 강점으로 활용했습니다.

클라우드 우선 통합의 원칙

넷플릭스의 Cosmos 컴퓨팅 플랫폼에서 동작하기 위해 FLAPI는 다음 조건을 만족해야 했습니다:

• 서버리스 함수로 패키징 가능 (Linux Docker 이미지)
• CPU 전용 인스턴스에서도 동작 (GPU 대비 더 넓은 컴퓨팅 풀 활용)
• Java, Python, CLI로 헤드리스 호출 지원
• 무상태(Stateless) 운영 → 실패 시 워커 종료 후 재실행

# FLAPI 기반 워커 Dockerfile 예시
FROM ubuntu:22.04

# FLAPI 런타임 및 종속성 설치
RUN apt-get update && apt-get install -y \
    openjdk-17-jdk \
    python3.10 \
    python3-pip \
    && rm -rf /var/lib/apt/lists/*

# FLAPI 라이브러리 복사 (실제 배포용)
COPY flapi-runtime/ /opt/flapi/
COPY worker.py /app/worker.py

# Cosmos Stratum Function 진입점
ENTRYPOINT ["python3", "/app/worker.py"]

# worker.py - Cosmos Stratum Function 예시
import sys
import json

def process_clip(event, context):
    """
    단일 클립 또는 서브 클립을 처리하고 종료합니다.
    """
    clip_path = event['clip_path']
    output_location = event['output_location']
    frame_range = event.get('frame_range', None)
    amf_file = event.get('amf_file', None)
    fdl_file = event.get('fdl_file', None)
    
    # FLAPI 처리 로직 호출
    result = flapi_process(clip_path, output_location, frame_range, amf_file, fdl_file)
    
    return {
        'statusCode': 200,
        'body': json.dumps({'result': result})
    }

탄력적 확장의 이점

프로덕션 워크로드는 본질적으로 스파이크가 심합니다. 조용한 날에는 새 푸티지가 거의 없지만, VFX 납기일이 다가오면 수천 개의 병렬 렌더링이 필요합니다. FLAPI를 클라우드 함수로 배포함으로써 MPS는:

• 주문형으로 컴퓨팅을 할당하고 작업 큐가 비면 즉시 해제
• 고정된 로컬 하드웨어 풀에 용량을 묶어두지 않음
• 공유 리소스 풀에서 여러 인코딩 워크로드 간 수요를 평탄화

이 덕분에 넷플릭스 제작진은 마감일에 대한 불안 없이 빠른 처리 시간을 경험할 수 있습니다.

국내 적용 맥락

국내 OTT나 방송사 환경에서는 아직까지 온프레미스 기반의 미디어 파이프라인이 많습니다. 하지만 넷플릭스의 사례는 다음과 같은 시사점을 줍니다:

• 클라우드 네이티브 미디어 처리: Docker 기반 서버리스 아키텍처는 기존 MAM(Media Asset Management) 시스템과 통합하기 쉽습니다.
• 오픈 스탠다드 준수: ACES, ASC FDL, AMF 등 개방형 표준을 따르면 다양한 벤더 도구와의 호환성이 높아집니다.
• 파트너십 전략: 검증된 상용 엔진(FLAPI)을 활용하면 개발 리소스를 절약하면서도 품질을 보장할 수 있습니다.

결론: 협력이 만들어낸 효율성

넷플릭스 MPS와 FLAPI의 통합은 단순한 기술 연동을 넘어, 업계 표준을 선도하는 파트너십의 모범 사례를 보여줍니다. 반복 가능한 작업은 자동화하고, 표준화가 필요한 부분은 중앙화하며, 깊은 도메인 전문성이 필요한 영역은 신뢰할 수 있는 파트너에게 맡기는 전략입니다.

이 접근법의 진정한 가치는 위기의 부재에서 드러납니다. VFX 업체가 재전송을 요청하지 않고, 편집실이 수정된 플레이트를 기다리지 않으며, 컬러 시설이 톤 매핑 경로를 재발명하지 않아도 되는 환경이 바로 그것입니다.

한계 및 주의사항

• FLAPI는 GPU 렌더링도 지원하지만, 넷플릭스는 CPU 인스턴스를 주로 사용합니다. GPU가 필요한 고급 이펙트나 실시간 처리에는 적합하지 않을 수 있습니다.
• 클라우드 기반 파이프라인은 네트워크 대역폭과 지연 시간에 영향을 받으므로, 초대용량 파일 전송 시 최적화가 필요합니다.

다음 단계 학습 방향

• ACES( Academy Color Encoding System) 공식 문서를 통해 컬러 파이프라인의 표준을 이해해보세요.
• ASC FDL(Framing Decision List) 명세를 살펴보면 프레이밍 자동화의 원리를 알 수 있습니다.
• 클라우드 네이티브 미디어 처리에 관심이 있다면, AWS MediaConvert나 Azure Video Indexer 같은 서비스와의 비교도 좋은 학습 주제입니다.

함께 보면 좋은 글

• 팬톤이 에이전트 AI로 색상 전문성을 확장한 방법 AI-Ready 데이터베이스의 핵심 역할
• 넷플릭스의 AI 진화 복잡한 Graph Search를 자연어로 검색하는 기술

본 아티클은 Netflix TechBlog의 원문을 기반으로, 국내 개발자 맥락에 맞게 재구성한 인사이트입니다.