넷플릭스는 ML 모델을 어떻게 연결했나? – Model Lifecycle Graph 구축기

들어가며: ML 규모가 커질수록 생기는 ‘연결’의 문제

넷플릭스는 개인화 추천에서 시작된 머신러닝(ML)을 이제 스튜디오, 결제, 광고 등 전 비즈니스 영역으로 확장했습니다. 각 도메인은 저마다의 기술 스택과 조직 구조를 가지고 운영되면서, ML 모델과 데이터가 ‘사일로(Silo)’에 갇히는 문제가 발생했습니다.

예를 들어, 스튜디오 팀이 만든 콘텐츠 임베딩(장면 전환 탐지, 시각적 트랜지션 등)은 광고 맥락 매칭이나 개인화 추천에도 활용될 수 있지만, 이를 발견하고 연결할 인프라가 없었습니다. 모델 레지스트리, 파이프라인 오케스트레이터, 실험 플랫폼이 각각 따로 놀면서, ML 실무자는 다음과 같은 기본적인 질문에 답하기 위해 여러 시스템을 오가야 했습니다.

• 발견(Discovery): 어떤 피처가 있고, 어떤 데이터 소스를 사용할 수 있나?
• 계보(Lineage): 이 모델의 데이터를 생성한 파이프라인은 무엇인가?
• 영향도(Impact): 이 모델을 쓰는 A/B 테스트는? 내가 이 피처를 바꾸면 어떤 모델이 영향받을까?

이 문제의 본질은 단순히 UI를 통합하는 것이 아니라, 이질적인 메타데이터를 하나의 연결된 그래프로 만드는 기술적 도전이었습니다.

핵심 해결책: Metadata Service(MDS)와 Model Lifecycle Graph

넷플릭스는 Metadata Service (MDS) 라는 중앙 시스템을 구축했습니다. MDS는 다양한 소스 시스템(Kafka, AWS SNS/SQS)에서 이벤트를 실시간으로 수집하고, 이를 정규화(Normalization)하여 하나의 통합 엔티티 모델로 변환한 뒤, 지식 보강(Knowledge Enrichment) 과정을 통해 엔티티 간 관계를 추론하고 그래프를 형성합니다.

핵심 추상화 개념

• Component: AIP URI(예: aip://model/registry/ranking-v5)로 고유하게 식별 가능한 객체
• Entity: ML 에코시스템 내의 구체적인 자산(모델, 피처, 파이프라인 등)
• Entity Type: 동일한 데이터 구조를 공유하는 엔티티 그룹
• Domain: 관련 엔티티 타입의 기능적 그룹 (예: Models Domain)
• Provider: 특정 소스 시스템을 기반으로 한 Domain의 구현체

그래프 형성 과정 (5단계)

1. 이벤트 수집: 소스 시스템이 'thin event'를 발행 (예: model_instance_created)
2. 엔티티 보강(Hydration): MDS가 소스 시스템 API를 호출해 최신 상태를 조회
3. 데이터 변환 및 정규화: 각 시스템의 스키마를 통합 엔티티 모델로 변환 (예: owner_emails -> owners with AIP URI)
4. 저장 및 인덱싱: Datomic(그래프+캐시)과 Elasticsearch(검색)에 동시 저장
5. 지식 보강 및 그래프 형성: 백그라운드 작업이 엔티티 간 관계를 추론하고 엣지를 생성

예시: 모델과 A/B 테스트 연결

1. 모델 인스턴스가 pipeline_run_id를 참조
2. 보강 작업이 파이프라인을 조회하여 A/B 테스트 셀 정보 발견
3. 실험 플랫폼에서 테스트 상세 정보 조회
4. 최종적으로 모델 -> 파이프라인 -> A/B 테스트 셀 -> A/B 테스트 간 관계를 그래프에 추가

이 과정을 통해 MDS는 단순한 데이터 수집기를 넘어 새로운 지식을 유추하는 시스템으로 동작합니다. 다음은 이 연결을 활용한 GraphQL 쿼리 예시입니다.

# 넷플릭스 AIP Portal에서 모델의 계보와 영향도를 탐색하는 쿼리 예시
query {
  model(id: "aip://model/registry/ranking-model-v5-20XX0101") {
    name
    owners { name }
    currentInstance {
      version
      pipeline {
        name
        owners { name }
      }
      features {
        edges {
          node {
            name
            data { edges { node { name } } }
          }
        }
      }
      associatedAbTests {
        name
        cells { number name }
      }
    }
  }
}

이 쿼리 하나로 모델의 소유자, 파이프라인, 피처, 데이터 소스, 연관된 A/B 테스트까지 모두 조회할 수 있습니다. 이전에는 각각의 시스템을 직접 호출해야 했죠.

실무 적용 시 주의사항과 한계

MDS의 설계에는 몇 가지 트레이드오프가 있습니다.

1. 비동기 보강의 지연(Latency)

새로운 엔티티가 생성된 후 관계가 그래프에 완전히 반영되기까지 수 분의 지연이 발생할 수 있습니다. 넷플릭스는 각 엔티티의 '마지막 보강 시각'을 포털에 표시하여 실무자가 데이터의 신선도를 판단할 수 있게 했습니다.

2. 소스 시스템에 추가 부하

Hydration 과정에서 MDS가 소스 시스템의 API를 호출하므로, 읽기 부하가 증가합니다. 이를 완화하기 위해 레이트 리밋, 캐싱, 백오프(Backoff) 전략이 필수적입니다.

3. 메타데이터 품질에 대한 의존성

소스 시스템이 이벤트를 누락하거나, 소유권 정보가 오래되거나, 엔티티에 설명이 부족하면 그래프의 유용성이 떨어집니다. 넷플릭스는 자동 검증 및 보강 시스템을 통해 이 문제를 해결하고 있지만, 완벽한 해결책은 아직 없습니다.

한국 개발 생태계에서의 적용 맥락

국내 IT 기업, 특히 대규모 플랫폼(커머스, 게임, 핀테크)에서도 유사한 문제를 겪고 있습니다. 여러 팀이 각자 ML 모델을 개발하면서, '누가 어떤 모델을 만들었는지', '이 피처를 바꾸면 어떤 서비스에 영향이 갈지'를 파악하기 어려운 경우가 많습니다. 넷플릭스의 접근법은 다음과 같은 환경에서 특히 유용합니다.

• ML 플랫폼 팀이 있는 조직: 중앙에서 메타데이터 서비스를 구축할 수 있는 역량이 있을 때
• 여러 도메인에 ML을 적용 중인 기업: 개인화, 검색, 광고, 리스크 관리 등 다양한 영역에서 모델을 운영할 때
• 마이크로서비스 아키텍처를 사용하는 환경: 각 서비스가 독립적인 데이터 스토어를 가질 때

다만, 넷플릭스처럼 자체적인 ML 인프라(피처 스토어, 모델 레지스트리, 실험 플랫폼)를 모두 갖추고 있는 경우에나 이 아키텍처의 진가가 발휘됩니다. 국내 중소기업이라면 오픈소스 도구(MLflow, Kubeflow, Feast 등)를 조합하여 유사한 효과를 낼 수 있습니다.

결론: ML 생태계의 ‘연결’이 곧 생산성이다

넷플릭스의 Model Lifecycle Graph는 단순한 기술 시스템이 아닙니다. 이는 ML 조직의 협업 문화를 바꾸는 인프라입니다. 모델, 피처, 파이프라인, 실험이 하나의 그래프로 연결되면서, 실무자는 더 이상 '누구에게 물어볼까' 고민하지 않고 시스템 자체에서 답을 찾을 수 있습니다.

MDS의 핵심 교훈은 다음과 같습니다.

• 이벤트를 '변경 알림'으로만 사용하고, 상태는 소스 시스템에서 직접 조회하라 (순서에 강건함)
• 비동기 보강을 통해 관계를 점진적으로 발견하라 (실시간성과 정확성의 트레이드오프)
• URI 기반의 주소 체계로 모든 엔티티를 유일하게 식별하라 (확장성)

이러한 접근법은 ML 도구가 계속 늘어나는 상황에서도 확장 가능한 기반을 제공합니다. 새로운 도구가 추가될 때마다 Provider만 구현하면 전체 그래프가 자동으로 확장됩니다.

함께 보면 좋은 글

• 파이썬 보안팀(PSRT)이 달라졌다 – PEP 811로 본 오픈소스 보안의 지속 가능성
• 메타의 FFmpeg 포크 폐기, 대규모 미디어 처리를 위한 업스트림 기여 전략

다음 단계 학습 방향

• 실습: MLflow나 Kubeflow를 사용해 나만의 ML 메타데이터 저장소를 구축해보세요.
• 심화: GraphQL과 Datomic의 데이터 모델링 패턴을 학습하면 더 깊이 이해할 수 있습니다.
• 참고: 넷플릭스의 원문 블로그를 방문해 더 자세한 아키텍처 다이어그램을 확인해보세요.