들어가며: ML 서빙, 왜 라우팅이 중요한가?

ML 모델을 서비스로 제공할 때 가장 까다로운 문제 중 하나는 '어떤 모델을, 어떤 사용자에게, 어떤 버전으로 보여줄 것인가' 입니다. 특히 넷플릭스처럼 수백 개의 모델이 초당 100만 건의 요청을 처리하는 환경에서는 이 문제가 인프라 아키텍처의 핵심 과제가 됩니다.

이 글은 넷플릭스 테크블로그의 'State of Routing in Model Serving' 시리즈를 기반으로, ML 모델 서빙 플랫폼에서 트래픽을 어떻게 지능적으로 라우팅하는지, 그리고 그 과정에서 어떤 아키텍처적 고민이 있었는지를 살펴봅니다.

핵심 질문: 단일 API 진입점으로 수백 개의 모델을 안전하게 서빙하면서, 연구자(모델 개발자)와 클라이언트(서비스 개발자) 모두에게 최적의 추상화를 제공하려면 어떻게 해야 할까?

배경: 넷플릭스의 '모델'은 단순한 추론이 아니다

일반적인 ML 서빙 시스템은 infer(features) -> score 형태의 단순한 추론 함수를 제공합니다. 하지만 넷플릭스에서 '모델'이란 전처리, 피처 계산, 후처리, 그리고 선택적인 ML 추론 컴포넌트를 모두 포함하는 하나의 워크플로우입니다.

예를 들어 '시청 중인 콘텐츠(Continue Watching) 행 개인화' 유스케이스를 보면:

  • 입력: UserId, 국가, 디바이스 ID
  • 출력: 정렬된 영화/시리즈 ID 리스트

클라이언트는 단순히 userId와 컨텍스트만 넘기면, 모델 서빙 플랫폼이 내부적으로 필요한 피처를 수집하고, 적절한 모델을 선택해 추론을 수행한 뒤 결과를 반환합니다. 이 과정에서 클라이언트는 모델의 버전, 실험 여부, 클러스터 위치 등을 전혀 알 필요가 없습니다.

이를 위해 넷플릭스는 Switchboard라는 중앙 라우팅 서비스를 도입했습니다.

1세대: Switchboard — 단일 진입점의 시작

Switchboard는 모든 ML 추론 요청이 반드시 거쳐야 하는 중앙 프록시 레이어입니다. 이 서비스는 다음과 같은 핵심 역할을 수행합니다:

1. Objective 추상화

넷플릭스는 유스케이스를 Objective라는 열거형(Enum)으로 정의합니다. 예를 들어 ContinueWatchingRanking이라는 Objective가 하나의 비즈니스 요구사항을 나타냅니다. 클라이언트는 Objective만 지정하면 되고, 내부적으로 어떤 모델이 사용될지는 Switchboard가 결정합니다.

2. 컨텍스트 기반 라우팅

Switchboard는 요청의 컨텍스트(userId, 디바이스, 로케일, A/B 실험 할당 등)를 분석해 적절한 모델 인스턴스로 라우팅합니다. 이때 연구자(ML 개발자)는 JavaScript 기반의 Switchboard Rules를 작성하여 라우팅 규칙을 정의합니다.

/**
 * 모델 연구자가 A/B 실험을 위해 작성하는 라우팅 규칙 예시
 * Cell 1: 현재 프로덕션 모델 (기본값)
 * Cell 2, 3: 실험 모델 (후보)
 */
function defineAB12345Rule() {
  const abTestId = 12345;
  const objectives = Objectives.ContinueWatchingRanking;
  const abTestCellToModel = {
    1: {name: "netflix-continue-watching-model-default"},
    2: {name: "netflix-continue-watching-model-cell-2"},
    3: {name: "netflix-continue-watching-model-cell-3"}
  };
  return {
    cellToModel: abTestCellToModel,
    abTestId: abTestId,
    targetObjectives: [objectives],
    modelInputType: constants.TITLE_INPUT_TYPE,
    modelType: 'SCORER'
  };
}

3. 트래픽 분할 및 생애주기 관리

Switchboard는 카나리 배포, 섀도우 모드 테스트, 즉시 롤백 등을 지원합니다. 연구자는 새로운 모델을 전체 트래픽의 1%에만 노출시켜 안전하게 검증할 수 있습니다.

Switchboard의 한계

하지만 규모가 커지면서 세 가지 주요 문제가 드러났습니다:

문제영향
단일 장애점(SPOF)Switchboard에 버그가 발생하면 모든 ML 서비스 중단
추가 레이턴시 (10~20ms)직렬화/역직렬화 비용 + 테일 레이턴시 증폭
클라이언트 유연성 저하서빙 클러스터에서 실제 트래픽과 인공 트래픽 구분 어려움

실무 인사이트: 중앙 집중형 라우팅은 초기 개발 속도를 높여주지만, 규모가 커질수록 레이턴시와 장애 전파 리스크가 커집니다. 이는 MSA(마이크로서비스 아키텍처)에서 API 게이트웨이를 설계할 때도 동일하게 고려해야 할 지점입니다.

2세대: Lightbulb — 분리와 위임의 지혜

넷플릭스는 Switchboard의 장점을 유지하면서 단점을 해결하기 위해 Lightbulb 아키텍처로 진화했습니다. 핵심 아이디어는 라우팅 결정을 위한 메타데이터 해석(Control Plane)과 실제 트래픽 전달(Data Plane)을 분리하는 것입니다.

새로운 아키텍처 구성

  1. Lightbulb (경량 서비스): 요청 컨텍스트를 받아서 routingKey와 ObjectiveConfig(모델 ID 등)를 반환합니다. 이 서비스는 실제 요청 페이로드를 전혀 보지 않고, 최소한의 메타데이터만으로 결정을 내립니다.

  2. Envoy Proxy: 이미 넷플릭스의 모든 서비스 간 통신에 사용되는 Envoy가 실제 라우팅을 담당합니다. Lightbulb가 생성한 routingKey를 HTTP 헤더에 담아 Envoy가 해당 VIP로 요청을 전달합니다.

// Lightbulb 응답 예시
{
  "routingKey": "continue-watching-v2-us-east",
  "objectiveConfig": {
    "modelId": "netflix-continue-watching-model-cell-2",
    "experimentId": 12345
  }
}

이점

  • 레이턴시 감소: Switchboard를 거치지 않으므로 직렬화/역직렬화 비용 제거
  • 장애 격리: Lightbulb에 장애가 발생해도 Envoy가 캐싱된 라우팅 정보로 fallback 가능
  • 테넌트 분리: 각 유스케이스(테넌트)별로 라우팅 클러스터를 분리하여 오류 전파 방지

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

국내 IT 기업에서도 ML 모델 서빙 인프라를 구축하는 사례가 늘고 있습니다. 특히 커머스, 핀테크, 콘텐츠 추천 분야에서 넷플릭스와 유사한 고민을 하고 계신 분들이 많을 거예요.

  • SI/금융권 환경: 레거시 시스템과의 연동을 고려할 때, Switchboard 같은 중앙 라우팅 레이어를 도입하면 초기 통합 비용을 낮출 수 있습니다. 다만, 레이턴시에 민감한 금융 트랜잭션의 경우 Lightbulb 방식의 분리 아키텍처가 더 적합할 수 있습니다.
  • 스타트업: 초기에는 단순한 API 게이트웨이로 시작해도 좋지만, 모델 수가 10개를 넘어가고 A/B 실험이 빈번해지면 Switchboard 스타일의 추상화가 필요해집니다.
  • MLOps 도구와의 연계: 국내에서는 Kubeflow, MLflow, Seldon Core 등을 많이 사용하는데, 이러한 도구들과 Switchboard/Lightbulb의 개념을 결합하면 더 강력한 서빙 플랫폼을 구축할 수 있습니다.

이 아키텍처의 한계와 주의사항

Lightbulb 아키텍처가 완벽한 해결책은 아닙니다. 다음과 같은 한계를 인지해야 합니다:

  1. Envoy 의존성: Envoy의 라우팅 능력과 커스터마이징 범위에 따라 구현이 제한될 수 있습니다. Envoy가 지원하지 않는 복잡한 라우팅 로직이 필요하다면 다시 중앙 서비스를 고려해야 합니다.
  2. 메타데이터 캐싱 일관성: Lightbulb의 라우팅 키가 변경되었을 때, Envoy의 캐시가 즉시 갱신되지 않으면 잘못된 라우팅이 발생할 수 있습니다.
  3. 운영 복잡성: 단일 서비스(Switchboard)에서 두 개의 컴포넌트(Lightbulb + Envoy 설정)로 분리되면서 운영 포인트가 늘어났습니다.

다음 단계 학습 방향

이 글에서 다룬 라우팅 아키텍처 외에도, 넷플릭스는 시리즈의 후속 포스트에서 추론(Inference) 엔진 최적화와 피처 페칭(Feature Fetching) 전략을 다룰 예정입니다. 관심 있으신 분들은 다음 주제를 함께 공부해보세요:

  • gRPC vs REST: 고성능 ML 서빙에서는 gRPC 스트리밍이 왜 선호되는가
  • 모델 병렬화와 파이프라이닝: 하나의 모델이 여러 GPU에 걸쳐 있을 때의 라우팅
  • 캐싱 전략: 동일한 사용자 요청에 대해 추론 결과를 캐싱하여 레이턴시를 줄이는 방법

함께 보면 좋은 글:

Netflix ML model serving architecture diagram showing Switchboard routing layer Coding Session Visual

핵심 개념: Objective 추상화와 Switchboard Rules

Objective가 해결하는 문제

클라이언트(마이크로서비스)는 단순히 Objective만 지정하면 됩니다. 예를 들어:

  • ContinueWatchingRanking
  • PaymentFraudDetection
  • HomepagePersonalization

내부적으로 어떤 모델(v1, v2, v3)이 사용되는지, 어떤 A/B 실험이 진행 중인지는 전혀 신경 쓸 필요가 없습니다. 이는 **인터페이스 분리 원칙(Interface Segregation Principle)**의 ML 인프라 버전이라고 볼 수 있습니다.

Switchboard Rules의 실제 동작 흐름

/**
 * Control Plane: 연구자가 규칙을 정의하면,
 * Gutenberg 시스템을 통해 Switchboard와 Serving Cluster에 배포됩니다.
 */

// 1. 연구자가 A/B 실험 규칙을 정의
function defineAB12345Rule() {
  const abTestId = 12345;
  const objectives = Objectives.ContinueWatchingRanking;
  const abTestCellToModel = {
    1: {name: "netflix-continue-watching-model-default"},
    2: {name: "netflix-continue-watching-model-cell-2"},
    3: {name: "netflix-continue-watching-model-cell-3"}
  };
  return {
    cellToModel: abTestCellToModel,
    abTestId: abTestId,
    targetObjectives: [objectives],
    modelInputType: constants.TITLE_INPUT_TYPE,
    modelType: 'SCORER'
  };
}

// 2. Data Plane: 요청이 들어오면
// - Switchboard가 실험 플랫폼에 userId의 cell 할당 조회
// - 할당 결과에 따라 적절한 모델 선택
// - 해당 모델이 위치한 클러스터 VIP로 요청 전달

Switchboard vs Lightbulb 비교 표

특성Switchboard (1세대)Lightbulb + Envoy (2세대)
라우팅 결정 위치중앙 서비스Lightbulb (메타데이터) + Envoy (실행)
Data Plane 개입요청 페이로드 전체 처리헤더 기반 라우팅만 수행
레이턴시 오버헤드10~20ms (직렬화/역직렬화)~1ms (헤더 조회)
장애 전파 위험높음 (SPOF)낮음 (Envoy 캐싱 fallback)
운영 복잡성낮음 (단일 서비스)중간 (두 컴포넌트 조율 필요)
확장성수평 확장 가능하나 병목 발생매우 높음 (Envoy는 이미 분산)

Network traffic routing diagram for ML inference requests across cluster shards Programming Illustration

주의사항: 중앙 라우팅이 항상 정답은 아니다

Switchboard에서 Lightbulb로의 진화는 **'중앙 집중형이 좋은가, 분산형이 좋은가'**라는 오래된 질문에 대한 하나의 사례 연구입니다.

중앙 라우팅이 적합한 경우

  • 초기 단계로 모델 수가 적고(10개 미만), A/B 실험이 드문 경우
  • 레이턴시 요구사항이 엄격하지 않은 배치 추론 시스템
  • 팀 규모가 작아 운영 오버헤드를 감수하기 어려운 경우

분산 라우팅이 적합한 경우

  • 초당 수십만 건 이상의 실시간 추론이 필요한 경우
  • 다양한 테넌트(유스케이스)가 서로 다른 SLA를 요구하는 경우
  • 장애 허용(Fault Tolerance)이 중요한 미션 크리티컬 시스템

실무 팁: 국내 환경에서는 AWS API Gateway + Lambda를 조합한 중앙 라우팅으로 시작한 뒤, 트래픽이 늘어나면 Envoy + 서비스 메시(예: Istio) 기반의 분산 라우팅으로 전환하는 패턴이 효과적입니다.

결론: 아키텍처는 정답이 아니라 트레이드오프다

넷플릭스의 사례는 '초기에는 단순함을, 성장 후에는 분리와 위임을' 선택하는 전형적인 아키텍처 진화 패턴을 보여줍니다.

  • Switchboard는 빠른 혁신을 위한 추상화를 제공했지만, 규모가 커지면서 레이턴시와 장애 리스크라는 대가를 치렀습니다.
  • Lightbulb는 동일한 추상화를 유지하면서도, Control Plane과 Data Plane을 분리하여 각각의 문제를 해결했습니다.

ML 모델 서빙 아키텍처를 고민하시는 분들께 드리는 조언은:

  1. 먼저 필요한 추상화 수준을 정의하세요. 클라이언트가 알아야 할 것과 몰라도 될 것을 명확히 구분하세요.
  2. 초기에는 단순하게 시작하세요. Switchboard 같은 중앙 라우팅으로 시작해도 충분합니다.
  3. 성장의 고통을 느꼈을 때 분리하세요. 성급한 분산화는 오히려 복잡성만 증가시킵니다.

원문 글에서 언급된 것처럼, 이 시리즈는 앞으로도 계속됩니다. 다음 편에서는 추론 엔진 최적화와 피처 페칭 전략을 다룰 예정이라고 하니, ML 인프라에 관심 있으신 분들은 함께 지켜봐 주세요!

Cloud infrastructure diagram illustrating decoupled routing with Lightbulb and Envoy Technical Structure Concept

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.