Netflix는 어떻게 수만 개의 시놉시스를 LLM으로 팩트체크할까? (비용 52% 절감기)

들어가며: '사실인데 거짓말 같은' 시놉시스의 함정

Netflix처럼 수천 개 타이틀 × 시즌별 에피소드 × 다국어 시놉시스를 사람이 직접 팩트체크하는 건 불가능합니다. 그래서 이들은 LLM 기반 factuality 서비스를 운영하는데, 기존 방식은 추론 모델에 100k+ 토큰 컨텍스트를 통째로 넣고 5번 반복 호출하는 홀리스틱(holistic) 방식이었어요.

문제는 두 가지였습니다.

1. 비용 폭발 — 판정 1건당 5번의 장문 컨텍스트 추론 호출.
2. 근거(rationale) 불일치 — 모델이 엉뚱한 이유로 FAIL을 때리거나(예: 'wonderful magic'이라는 표현이 없다고 실패 처리), 반대로 미묘한 오류를 "별거 아니다"라며 통과시킴.

여기서 중요한 포인트는 팩트체크의 스펙트럼입니다. Netflix는 오류를 4단계로 나눠요.

• A: 완전히 사실 (통과)
• B: 완전히 거짓 (탈락)
• C: 모든 문장은 참이지만 오해를 유발 (예: 레이디 휘슬다운 중심 이야기처럼 서술)
• D: 문장은 참이지만 뉘앙스가 오도 (예: 첫 만남부터 열정적 로맨스처럼 서술)

C와 D가 진짜 어려운 케이스입니다. 단순 문자열 매칭이나 키워드 검사로는 절대 못 잡아요. 이 글은 그 C/D를 잡으면서 비용까지 줄인 아키텍처 이야기입니다.

핵심 아이디어: 홀리스틱 → Cascade 3단 구조

Netflix가 도입한 개선점은 크게 세 가지입니다.

1) Confidence Gating (신뢰도 게이팅)

모델에게 verdict와 함께 confidence를 출력하게 시키고, 고신뢰 케이스는 1회 호출로 끝냅니다. 저신뢰 케이스만 추가 검증으로 escalate. 공항 보안 검색대 비유가 딱 맞아요 — 대부분은 그냥 통과, 알람 울린 가방만 정밀 검사.

2) Specialized Judges (전문화된 심판 2명)

같은 프롬프트로 5번 돌리는 건 샘플링 노이즈만 줄여줄 뿐, 체계적 추론 오류는 못 잡습니다. 그래서 역할을 나눕니다.

• Literal Judge: 문장이 문자 그대로 참인가?
• Implicature Judge: 안 본 시청자에게 거짓 그림을 주는가?

# 두 심판을 병렬 호출하는 의사 코드 (실무 적용 예시)
from dataclasses import dataclass

@dataclass
class Verdict:
    label: str          # "PASS" or "FAIL"
    confidence: float   # 0.0 ~ 1.0
    rationale: str
    concessions: list   # 모델이 스스로 인정한 '애매한 지점'

async def cascade_check(synopsis: str, source_material: str) -> Verdict:
    # Stage 1: 두 심판 병렬 호출
    literal, implicature = await asyncio.gather(
        literal_judge(synopsis, source_material),
        implicature_judge(synopsis, source_material),
    )

    # Confidence Gating: 둘 다 고신뢰면 즉시 종료
    if literal.confidence > 0.8 and implicature.confidence > 0.8:
        return merge_verdicts(literal, implicature)

    # Stage 2: 저신뢰 + concession이 있으면 라우터로
    concessions = literal.concessions + implicature.concessions
    if concessions:
        atomic_claims = await router.reframe(concessions)
        for claim in atomic_claims:
            # 외부 사실이면 web judge, 원문 재확인이면 source recheck
            result = await route_and_recheck(claim, source_material)
            if result.contradicted:
                return Verdict("FAIL", 0.9, result.reason, [])
    return merge_verdicts(literal, implicature)

3) Router + Stage-2 Recheck (원자적 재검증)

심판들이 스스로 남긴 **concession(양보, 의심, 가정)**을 모아서 라우터가 **원자적 명제(atomic claim)**로 재구성합니다. 그리고 각 명제에 필요한 증거 유형을 지정해 Stage-2 심판에게 라우팅하죠. 예를 들어:

• 외부 인용/비평이 필요한 명제 → Web Judge
• 원문 소재 재확인이 필요한 명제 → Source Recheck

이렇게 하면 "모델이 애매하게 넘긴 지점"을 콕 집어 다시 검증할 수 있어요. Stage-2는 두 방향으로 원판정을 뒤집을 수 있습니다.

• FAIL → PASS: 모든 concession이 2차 검증에서 지지됨
• PASS → FAIL: concession 중 하나라도 반박됨

주의사항 및 실무 함정

⚠️ 주의 1: '작은 모델로 갈아타기'는 답이 아닙니다

Netflix가 ablation을 돌려본 결과, 단순히 더 작은 모델을 쓰면 너무 엄격해지고, reasoning effort를 올리면 너무 관대해집니다. 즉 "간단한 튜닝"으로는 홀리스틱 베이스라인의 근본 문제를 못 잡아요. 구조를 바꿔야 합니다.

⚠️ 주의 2: P50 레이턴시는 증가합니다

Cascade는 저신뢰 케이스에 대해 Stage-2까지 태우기 때문에 중앙값 레이턴시가 올라갑니다. Netflix는 "판정에 허용 가능한 범위"라고 판단했지만, 실시간성이 중요한 서비스(예: 채팅 필터링)에는 그대로 이식하기 어렵습니다. 반드시 비동기 배치 처리나 캐싱 레이어를 함께 설계하세요.

⚠️ 주의 3: 에피소드 단위 태스크엔 '전체 요약' 컨텍스트가 필수

에피소드 시놉시스만 던져주면 모델이 과도하게 FAIL을 때립니다. 해당 디테일이 전체 스토리라인에 맞는지 판단할 컨텍스트가 없기 때문이에요. Netflix는 전체 시즌 요약을 프롬프트에 추가해서 이 문제를 해결했습니다.

📊 성과 비교

핵심은 정확도와 비용을 동시에 개선했다는 점입니다. 보통은 트레이드오프인데, 이 아키텍처는 라우팅으로 필요한 곳에만 비용을 쓰기 때문에 둘 다 잡혔어요.

결론: 여러분의 서비스에 어떻게 적용할까?

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

이 아키텍처는 Netflix 같은 하이퍼스케일이 아니어도 충분히 유효합니다. 특히 콘텐츠 검수·모더레이션·RAG 답변 검증을 하는 국내 팀이라면 바로 참고할 만해요. 예를 들어 커머스 상품 설명의 사실 검증, CS 챗봇 답변의 hallucination 검증, 뉴스 요약 검증 등에 같은 패턴을 쓸 수 있습니다.

국내 SI 프로젝트에서는 보통 "LLM 한 번 호출해서 판정"으로 끝내는 경우가 많은데, 여기서 한 단계 더 나아가 confidence + concession + router 3종 세트를 넣는 것만으로도 품질이 크게 달라집니다. 다만 비용 계산을 사전에 반드시 하세요. 저신뢰 케이스 비율이 높으면 cascade가 오히려 홀리스틱보다 비쌀 수 있습니다.

다음 단계 학습 방향

1. LLM-as-a-Judge 패턴 — 이 글에서도 정합도 측정에 사용됐습니다. 판정 시스템을 만들 거라면 필수 선행 학습.
2. Constitutional AI / Self-Critique — 모델이 자기 추론의 약한 고리를 스스로 찾게 만드는 프롬프트 엔지니어링 기법.
3. Routing 패턴 (Mixture-of-Experts 스타일) — 태스크별로 적합한 모델/도구에 분배하는 아키텍처. 비용 최적화의 핵심입니다.

함께 보면 좋은 글

• 엣지 AI 시대의 새 기준, NVIDIA IGX Thor가 던지는 질문 — 온디바이스 추론 비용 관점에서 비교해 보면 재밌습니다.
• 픽셀 퍼펙트는 이제 그만, 현대 웹 개발의 새로운 완벽함 — '완벽함'의 정의를 다시 생각하게 하는 글. 이 글의 "기술적으로 참이지만 오해를 유발"이라는 개념과도 통합니다.

원문 아키텍처와 실험 결과는 Netflix Tech Blog의 근거자료에서 직접 확인하실 수 있어요. 삽질 없이 바로 적용해 보시길!