AI와 엔터테인먼트에 관한 대부분의 대화는 잘못된 축에 갇혀 있습니다. AI가 작가들을 대체할까요? AI가 애니메이션 스튜디오를 망하게 할까요? 이것들은 문화 전쟁(culture-war)적인 질문들이며, 훌륭한 헤드라인이 될 수는 있지만 무엇을 구축해야 하는지에 대해서는 아무것도 알려주지 않습니다. 만약 당신이 아키텍트(architect)나 시니어 엔지니어(senior engineer)라면, 흥미로운 질문은 다릅니다. 콘텐츠가 한 번 제작되어 배포되는 대신 온디맨드(on demand)로 생성될 때, 엔터테인먼트의 백엔드(backend)는 어떤 모습일까요? 실제로 그 시스템을 설계하려고 시도해 보면, 모델(model)은 쉬운 부분이라는 것을 깨닫게 됩니다. 어려운 부분은 새로운 옷을 입은 오래된 친구들입니다. 즉, 스트리밍 지연 시간(streaming latency), 데이터 계보(data lineage), 그리고 단위 경제성(unit economics)입니다. 다만 이제 콘텐츠 자체가 확률적(probabilistic)이며 요청당 생성된다는 점이 다릅니다. 이 글에서는 해당 설계 영역을 지배하는 세 가지 제약 조건과, 왜 이것들이 모델 품질보다 훨씬 앞서 중요하게 다뤄져야 하는지에 대해 살펴봅니다.

지연 시간(Latency)은 성능 튜닝의 세부 사항이 아니라 제품 그 자체이다

배치 생성(Batch generation)은 이미 해결된 데모입니다. 밤새 클립을 렌더링할 수 있고, 그것이 얼마나 걸렸는지는 아무도 신경 쓰지 않습니다. 엔터테인먼트가 상호작용(interactive)하게 되는 순간, 그 가정은 무너집니다. 입 모양을 맞추는 실시간 더빙(Live dubbing), 즉흥 대사를 하는 게임 캐릭터, 시청자의 선택에 따라 분기되는 쇼; 이 모든 것들은 실제 동시성(concurrency) 환경에서 에지(edge) 단의 약 200밀리초 이내에 추론(inference)을 완료해야 합니다. 이 단 하나의 요구 사항이 당신의 전체 로드맵을 조용히 다시 작성합니다. 이제 당신의 AI 프로젝트는 분산 시스템(distributed systems) 프로젝트가 됩니다. 당신은 갑자기 요청 간의 KV-캐시(KV-cache) 재사용, 토큰 지연 시간(token latency)을 줄이기 위한 투기적 디코딩(speculative decoding), 하드웨어에 맞추기 위한 모델 샤딩(model sharding), 그리고 사용자에게 전달되는 왕복 시간(round trip)이 실시간처럼 느껴질 만큼 짧도록 지역별 GPU 배치(regional GPU placement)에 대해 고민하게 됩니다.

생성형 미디어(generative media)를 단순히 "호스팅된 API를 호출하고 응답을 기다리는 것"으로 취급하는 팀은 인터랙티브(interactive)한 결과물을 출시하는 즉시 한계에 부딪힐 것입니다. API 지연 시간(latency) 하한선에 네트워크 왕복 시간(network round trips), 그리고 콜드 스타트(cold starts)가 더해지면, 모델이 실행되기도 전에 예산을 초과해 버립니다. 이를 위해 설계한다는 것은 고빈도 매매(high-frequency trading) 경로 나 실시간 입찰(real-time bidding) 시스템과 마찬가지로 지연 시간 예산(latency budget)의 관점에서 생각해야 함을 의미합니다.

# 지연 시간 예산(latency budget)은 열망이 아니라 계약입니다.
# 인터랙티브한 생성형 미디어는 엔드 투 엔드(end to end)로 예산을 분해해야 합니다.
...

교훈은 인터랙티브함이 AI의 역량을 스트리밍 시스템(streaming-systems) 문제로 변모시킨다는 것입니다. 마법 같은 경험은 더 큰 모델을 통해서가 아니라 아키텍처를 통해 얻어집니다.

출처(Provenance)는 쿼리 속도로 제공되는 저장 필드가 됩니다

화면의 어떤 프레임이라도 합성된 것일 수 있을 때, 세 가지 질문은 더 이상 법적인 사후 고려 사항이 아니라 데이터 모델의 일부가 됩니다: 누가 이것을 만들었는가, 무엇으로 학습되었는가, 그리고 누구에게 비용을 지불해야 하는가입니다. 전통적인 파이프라인(pipeline)에서 권리와 귀속(attribution)은 스프레드시트와 한 번 협상된 계약서에 존재합니다. 생성형 파이프라인에서는 콘텐츠가 요청마다, 자체적인 라이선스 약관을 가진 자산으로 학습된 모델로부터 지속적으로 생성됩니다. 이러한 질문에 사후에 답할 수는 없습니다. 생성 시점에 이를 캡처하여 계속 전달해야 합니다.

구체적으로, 이는 자산이 생성되는 즉시 서명하고, 검증 가능하며 변조 방지(tamper-evident)가 가능한 형태로 귀속 메타데이터(attribution metadata)를 부착하며, 모든 변환(transform), 모든 재인코딩(re-encode), 모든 합성(composite), 모든 편집(edit) 과정을 통해 해당 계보(lineage)를 전파해야 함을 의미합니다. C2PA와 같은 표준이 바로 이를 위해 존재하지만, 아키텍처 측면의 실행 책임은 여러분에게 있습니다. 출처(provenance)는 미디어 자체와 함께 저장, 서명 및 제공되는 여러분의 스키마(schema) 내 일급 객체(first-class field)여야 합니다. 규제 기관, 권리 소유자 또는 플랫폼이 특정 프레임이 어디에서 왔는지 묻는다면, 2주간의 포렌식 조사(forensic investigation)를 거친 후가 아니라 쿼리 속도(query speed)로 답할 수 있어야 합니다.

이것이 매우 중요한 이유는 출처(provenance)가 진정으로 사후에 보완할 수 없는 유일한 속성이기 때문입니다. 지연 시간(latency)은 시간이 지나면서 최적화할 수 있습니다. 비용(cost)은 더 나은 하드웨어를 통해 낮출 수 있습니다. 하지만 계보(lineage) 없이 백만 개의 에셋을 생성했다면, 그 이력은 단순히 사라진 것입니다. 첫 프레임부터 이를 구축하거나, 아니면 영원히 구축할 수 없음을 받아들여야 합니다.

토큰당 비용(Cost-Per-Token)에서 분당 비용(Cost-Per-Minute)으로의 단위 경제학 전환

생성형 텍스트는 업계가 토큰당 비용(cost per token)으로 생각하도록 훈련시켰습니다. 하지만 생성형 비디오는 그러한 직관을 완전히 깨뜨립니다. 개인화된 4K 콘텐츠 1분은 GPU-초(GPU-seconds)로 표시되는 실제적이고 측정 가능한 한계 비용(marginal cost)을 가지며, 창의적 야망이 아닌 바로 이 숫자가 어떤 기능이 손익 계산서(P&L)와 마주했을 때 실제로 살아남을지를 결정합니다. 이것은 엔터테인먼트라는 라벨을 달고 있는 제조(manufacturing) 문제입니다. 승리하는 스튜디오와 플랫폼은 공장이 생산 라인을 계측(instrument)하는 방식과 동일하게 추론(inference)을 계측할 것입니다. 즉, 가동률(utilization), 수율(yield), 그리고 전달된 분당 비용(cost per delivered minute)을 끊임없이 추적할 것입니다.

대부분의 조직은 아직 이를 측정하지 않고 있습니다. 그들은 인상적인 파일럿 프로젝트를 실행하지만, 이후 분당 비용이 관객 규모(audience scale)에서 해당 기능을 실행 불가능하게 만든다는 사실을 깨닫게 됩니다. 이에 대한 아키텍처적 대응은 첫날부터 비용을 설계 제약 조건(design constraint)으로 취급하는 것입니다. 생성된 세그먼트를 캐싱(caching)하고 재사용하며, 품질 기준을 통과하는 가장 작은 모델을 선택하고, 상호작용(interactivity)이 허용되는 곳에서 배칭(batching)을 수행하며, 지연 시간 예산(latency budget)을 충족하는 가장 저렴한 하드웨어로 요청을 라우팅(routing)하는 것입니다. 비용과 지연 시간은 끊임없이 대립하며, 기능별로 그 대립을 해결하는 것이 실제 업무입니다.

결론

세 가지 제약 조건 아래에 깔린 패턴은 동일합니다. 콘텐츠를 생성하는 기술이 이를 관리(govern), 속성 부여(attribute), 그리고 비용을 지불(pay)하는 시스템보다 더 빠르게 도래하고 있다는 점입니다. 단일 모델의 품질이 아니라, 바로 이 격차(gap)가 향후 10년 동안 플랫폼 가치가 구축될 지점입니다. 아키텍트들에게 이는 묘하게 안심이 되는 일입니다. 우리는 이전에 스트리밍 파이프라인(streaming pipelines), 계보 시스템(lineage systems), 그리고 용량 경제 모델(capacity-economics models)을 구축해 본 경험이 있기 때문입니다. 새로움은 콘텐츠가 확률적(probabilistic)이며 요청당(per request) 생성될 때 이 세 가지를 모두 수행해야 한다는 점에 있습니다.

다음 설계 검토(design review) 시 고려해야 할 세 가지 핵심 사항입니다:

1. 상호작용성(interactivity)을 스트리밍 시스템 문제로 취급하십시오. 200ms 미만의 지연 시간 예산(latency budget)은 모델 선택을 분산 시스템(distributed-systems)의 영역인 에지 배치(edge placement), 캐시 재사용(cache reuse), 투기적 디코딩(speculative decoding)의 문제로 변모시킵니다.
2. 출처(provenance)를 저장되고 서명된 필드로 만드십시오. 이는 사후에 보완할 수 없는 유일한 속성이므로, 생성 시점에 계보(lineage)를 캡처하고 쿼리 속도(query speed)로 제공해야 합니다.
3. 전달된 분당 비용(cost per delivered minute)을 측정하십시오. 생성형 비디오 경제학이 어떤 기능이 출시될지를 결정합니다. 추론(inference)을 연구용 데모가 아닌 공장 바닥(factory floor)처럼 계측(instrument)하십시오.

헤드라인을 장식하는 것은 모델입니다. 하지만 실제로 무엇이 출시될지를 결정하는 것은 아키텍처입니다.