AI로 애니메이션 콘텐츠를 제작한다는 것은 텍스트-투-비디오(text-to-video) 모델을 사용해야 한다는 일반적인 가정이 있습니다. 실제로 출판되는 대부분의 콘텐츠 — 숫자가 올라가는 차트, 단계별로 나타나는 다이어그램, 슬라이드되어 들어오는 제목 등 — 에 대해 그 가정은 비용이 많이 들고 잘못되었습니다.

Sora 2의 API는 720p 기준 초당 $0.10이며, Pro 티어에서는 초당 $0.30에서 $0.70까지입니다. 그리고 OpenAI는 전체 API를 2026년 9월 24일에 종료할 예정입니다. 한편, 이러한 모델들에 대한 실패 모드 벤치마크가 기록하는 것은 바로 위의 콘텐츠와 같습니다: 판독 가능한 텍스트. 연구자들은 이를 글리프 붕괴(glyph collapse)라고 부르는데, 이는 녹아내리는 문자나 단어를 거의 스펠링한 레이블을 의미합니다. 생성형 비디오 모델은 확산 모델이 스프레드시트에 적합하지 않은 것처럼, 막대 차트에는 잘못된 도구입니다.

대안은 'AI를 사용하지 않는다'가 아닙니다. 그것은 다른 분업화(division of labour)입니다: LLM이 기계 검증 가능한 사양(spec)을 작성하고, 결정론적 코드(deterministic code)가 픽셀을 렌더링합니다. 저는 이 아키텍처를 제대로 설명하고자 합니다. 왜냐하면 이것이 실제로 작동하는 것이며, AI 비디오에 대해 글을 쓰는 거의 모든 사람이 이를 설명하지 않기 때문입니다.

생성형 모델이 실제로 필요한 경우

먼저 실제 사례부터 인정하겠습니다. 사진처럼 사실적인 장면, 인간의 존재, 물리적 공간을 통한 카메라 움직임, 또는 내용 자체가 데이터 구조를 가지고 있지 않은 모든 것 — 드론 샷, 배우, 날씨 등 — 이 필요하다면 생성형 모델이 필요하며, 여기에 언급된 내용은 해당되지 않습니다. 이것이 바로 이러한 모델들이 존재하는 목적이며, 주제가 진정으로 시각적일 때 그들은 놀랍습니다.

주장은 더 좁은 범위에 있습니다: 비즈니스와 개발자가 실제로 배포하는 대부분의 비디오 콘텐츠는 그렇지 않기 때문입니다.

대부분의 비디오 콘텐츠는 구조화되어 있으며, 구조화된 콘텐츠는 사양을 갖는다

실제로 출판되는 것을 살펴보세요: 제품 설명 영상, 통계 발표, 프로세스 워크스루(walkthroughs), 튜토리얼 인트로, 분기별 수치 게시물, 경로 지도, 출시 카운트다운. 스타일링을 제거하면 이 모든 것은 구조화된 데이터 — 단어, 숫자, 노드와 엣지, 좌표, 타임스탬프 — 입니다.

구조를 가진 콘텐츠는 명세(spec)로 기술될 수 있으며, 명세는 코드를 통해 렌더링(rendering)될 수 있습니다. 즉, 결정론적(deterministically)으로, 비용 없이, 어떤 해상도에서든, 모든 글리프(glyph)가 실제 벡터(vector)인 상태로 구현 가능합니다.

• 키네틱 텍스트 (Kinetic text) — 문자열, 스타일, 타이밍 곡선.
• 차트 및 통계 (Charts and stats) — 레이블과 값의 행, 템플릿, 지속 시간.
• 다이어그램 및 플로우차트 (Diagrams and flowcharts) — 노드(node)와 엣지(edge)로 구성된 타입화된 그래프.
• 지도 (Maps) — 정류장, 경로, 프레임, 카메라.
• UI 워크스루 (UI walkthroughs) — 타임라인 위의 화면과 강조 표시.

이를 위한 도구들은 성숙해 있으며 지루할 정도인데, 이는 찬사입니다. Remotion은 React 컴포넌트를 비디오로 렌더링하며, Motion Canvas와 그 파이프라인 지향 포크(fork)인 Revideo는 TypeScript 제너레이터(generator)를 통해 애니메이션을 구동합니다. Manim은 모든 3Blue1Brown 스타일의 수학 설명 영상 뒤에 있는 엔진입니다. 저희의 접근 방식은 훨씬 더 좁습니다. 모든 것이 SVG 내부의 CSS 키프레임(keyframes) 또는 SMIL이며, 이것이 바로 내보낸 파일이 런타임 라이브러리 없이도 애니메이션을 구현하는 이유입니다.

트레이드오프(trade-offs)는 다르지만, 속성은 동일합니다. 픽셀은 분포(distribution)에서 샘플링되는 것이 아니라 계산됩니다.

[

이 차트의 모든 레이블과 숫자는 실제 벡터 글리프(vector glyph)입니다. 이는 텍스트-투-비디오(text-to-video) 모델들이 벤치마크에서 실패하는 바로 그 지점입니다. 이를 렌더링하는 데는 비용이 들지 않았으며 수 밀리초(milliseconds)밖에 걸리지 않았습니다. (여기서는 dev.to를 위해 GIF로 보여주지만, 원본은 20 KB 크기의 SVG입니다.)

아키텍처: 에이전트가 명세를 작성하고, 코드가 픽셀을 렌더링한다

다음은 엔드 투 엔드(end to end)로 작동하는 구조입니다.

**스토리보드 에이전트 (storyboard agent)**가 가장 먼저 투입됩니다. 이 에이전트는 브리프 (brief)를 받아 프레임 단위로 이야기를 작성합니다. 즉, 시청자가 무엇을, 어떤 순서로, 얼마나 오래 보게 될지를 결정합니다. 스토리보딩은 언어 작업 (language task)이기에 LLM (Large Language Model)이 이를 잘 수행하며, 이 단계를 생략해서는 안 됩니다. 모든 후속 결정이 이 문서에 의존하기 때문입니다.

그다음 **애니메이션 추론기 (animation reasoner)**가 스토리보드를 검토하며, 어떤 부분에 애니메이션이 필요한지, 그리고 어떤 종류의 애니메이션이 필요한지를 결정합니다. 모든 것이 움직여야 하는 것은 아닙니다. 정적 상태에서 타이틀만 유지되는 것도 정당한 장면입니다. 모델에게 모든 것을 애니메이션화하라고 지시하는 대신, 정지 상태를 선택할 수 있다고 알려주면 더 나은 페이싱 (pacing)을 만들어낼 수 있습니다.

그다음은 전체 설계를 실질적으로 구현하는 단계입니다.

도구 호출 계약 (Tool-call contracts)은 생성과 결정론 사이의 인터페이스이다

운동감이 있는 텍스트 (kinetic text), 차트 (chart), 다이어그램 (diagram), 지도 (map), UI 등 모든 애니메이션 카테고리는 모델에게 도구 호출 (tool call) 형태로 노출되며, 도구의 스키마 (schema)가 곧 해당 애니메이션 형태의 분류 체계 (taxonomy)가 됩니다.

// 차트 계약 (chart contract). 모델은 이를 채울 뿐이며,
// 픽셀, 타임라인 또는 코드를 직접 생성하지 않습니다.
{
...

이 스키마가 무엇을 인코딩(encode)하고 있는지 살펴보십시오. 단순히 타입 (type)뿐만 아니라, 해당 형태의 *분류 체계 (taxonomy)*를 담고 있습니다. 다섯 가지 템플릿이 존재하는 이유는 이 시스템에 존재하는 차트 애니메이션이 그것들이기 때문입니다. 레이블에 maxLength: 20이 설정된 이유는 더 긴 문자열은 막대(bar)에 들어가지 않기 때문입니다. maxItems: 8인 이유는 9개의 행은 레이아웃을 잡을 수 없기 때문입니다. 인간 디자이너가 눈으로 보고 적용했을 제약 조건들이 모델이 반드시 준수해야 하는 곳에 명시되어 있습니다.

도구 호출 계층 (tool-calling layer)은 반환 값을 렌더러 (renderer)가 필요로 하는 정확한 형태로 강제합니다. 검증 (validation)은 나중에 덧붙여진 검토 단계가 아니라, 그 자체로 인터페이스입니다.

저희의 플로우차트 스튜디오 (flowchart studio)는 실제 운영 환경에서 정확히 이 루프를 실행합니다. 저작 에이전트 (authoring agent)의 행이 검증에 실패하면, 수정 프롬프트 (repair prompt)는 거절 사유만을 전달받으며 그 외의 정보는 받지 않습니다. 또한 재시도 횟수는 제한됩니다:

// 제한된 수정 (Bounded repair). 모델은 대화 내용이 아닌 사유만을 전달받습니다.
async function authorSpec(brief, { maxRepairs = 2 } = {}) {
  let attempt = await callModel(AUTHOR_SYSTEM, brief);
...

기계가 확인할 수 없는 사양(spec)은 프롬프트(prompt)일 뿐, 사양(spec)이 아닙니다.

그 지점부터 파이프라인은 의도적으로 지능적이지 않게 설계되었습니다. **결정론적 렌더러 (Deterministic renderers)**는 채워진 각 계약(contract)을 애니메이션 세그먼트로 변환합니다. 즉, 동일한 입력은 매번 동일한 바이트를 생성합니다. **스티처 (stitcher)**는 ffmpeg를 사용하여 이 세그먼트들을 조립합니다. 어떤 모델도 이 단계에는 관여하지 않으며, 이것이 바로 이 단계의 출력을 신뢰할 수 있는 정확한 이유입니다.

아키텍처. 각 계약의 왼쪽에는 생성(generation)이, 오른쪽에는 결정론(determinism)이 있으며, 비디오를 시청할 필요가 없는 검증기(verifier)가 존재합니다.

검증기는 프레임을 샘플링합니다, 아무도 비디오를 볼 수 없기 때문입니다

LLM은 비디오를 볼 수 없습니다. 멀티모달 모델 (multimodal models)을 사용하더라도, 전체 비디오를 컨텍스트 윈도우 (context window)를 통해 전달하는 것은 잘못된 생각입니다. 비용이 많이 들고, 손실이 발생하며, 느리기 때문입니다.

하지만 검증기에게는 비디오가 필요하지 않습니다. 렌더링이 결정론적이기 때문에, 공개 중간 지점, 레이블이 안착하는 지점, 마지막 프레임 등 그럴듯한 몇 개의 타임스탬프 (timestamps)를 선택하여 정지 영상을 요청하고 이를 검사할 수 있습니다.

// 일정한 간격이 아니라,
// 애니메이션이 흥미로울 것으로 예상되는 지점을 샘플링합니다.
const probes = [
...

이것은 저희의 자체 캡처 파이프라인에서 직접 배운 교훈입니다. 프레임은 실제 시계 시간 (wall-clock time)을 따라가는 것이 아니라, 애니메이션 클락 (animation clock)을 탐색 (seeking) 함으로써 생성되므로, "2.4초 지점의 프레임"은 안정적이고 재현 가능한 결과물입니다. 샘플링된 정지 영상의 검증이 신뢰할 수 있는 이유는 오직 렌더러가 결정론적이기 때문입니다 — 이는 픽셀이 반드시 코드로부터 나와야 하는 또 다른 이유이기도 합니다. 검증에 실패하면, 실패 원인을 첨부하여 제한된 수리 루프 (bounded repair loop)를 통해 해당 사양 (spec)을 소유한 에이전트 (agent)에게 다시 전달됩니다.

보이스오버 (voiceover) 경로는 병렬로 실행됩니다

내레이션 (Narration)은 픽셀 (pixels)을 기다릴 필요가 없습니다. 스크립트 에이전트 (script agent)가 비주얼 (visuals)이 생성된 것과 동일한 스토리보드 (storyboard)로부터 보이스오버 (voiceover)를 작성하면, TTS 모델이 이를 말하고, 동기화 (sync) 단계에서 오디오를 이어 붙인 타임라인 (timeline)에 맞춥니다.

두 경로 모두 명시적인 지속 시간 (durations)을 가진 하나의 스토리보드에서 파생되기 때문에, 동기화는 추측이 아닌 산술적인 (arithmetic) 작업이 됩니다. 스토리보드는 단일 진실 공급원 (single source of truth)이며, 그 외의 모든 것은 그것의 투영 (projection)입니다.

이미 이런 방식으로 작동하는 도구들

이 패턴을 한 번 이해하고 나면, 어디에서나 보입니다.

Google의 NotebookLM Video Overviews는 내레이션이 포함된 슬라이드 (narrated slides)로 시작되었습니다. 이는 결정론적 (deterministic) 슬라이드 렌더러 (renderer) 위에 AI 스크립트가 올라간 형태로, 이 패턴의 가장 순수한 형태입니다. 더 최신인 Cinematic 티어 (tier)에서는 Google의 표현을 빌리자면, Gemini가 이미지 및 비디오 모델을 조율하는 크리에이티브 디렉터 (creative director) 역할을 수행합니다. 이 오케스트레이션 (orchestration)은 여전히 에이전트 (agent)가 구조적인 결정을 내리는 과정이며, 생성형 모델 (generative models)은 에이전트가 호출하는 도구 (tools)일 뿐입니다.

Easymotion은 채팅을 지도 애니메이션 (map animations)과 업로드된 스프레드시트 (spreadsheets) 기반의 애니메이션 차트 (animated charts)로 변환해 줍니다. 프롬프트 (prompt)를 입력하면 템플릿화된 결정론적 움직임 (templated deterministic motion)이 출력되며, 비용은 월 약 10달러부터 시작합니다.

그리고 이것이 저희의 flowchart studio가 작동하는 방식이기도 합니다. Describe it 모드에서 에이전트는 사람이 직접 채우는 것과 동일한 템플릿 중 하나를 위해 행 (rows)을 작성합니다. 이는 동일한 에디터 (editor)에 배치되고, 동일한 검증 (validation)을 거치며, 동일한 레이아웃 (layout) 및 타이밍 (timing) 코드를 통해 렌더링됩니다. Upload one 모드에서는 비전 에이전트 (vision agent)가 사진으로 찍은 다이어그램 (diagram)을 읽어 타이핑된 그래프 (graph)로 변환합니다. 두 모드 모두 모델은 구조 (structure)를 작성하고, 템플릿이 기하학적 구조 (geometry)와 움직임 (motion)을 소유합니다. infographic studio 역시 같은 맥락입니다. AI가 데이터를 제안할 수는 있지만, 애니메이션은 계산 (computed)됩니다.

Describe-it 에이전트가 작성하는 출력물 클래스는 다음과 같습니다. 레이아웃 (Layout)과 타이밍 (Timing)은 템플릿에 의해 계산되며, 에이전트는 이 두 가지를 전혀 건드리지 않습니다.

이 포스트에서 움직이는 모든 것은 이런 방식으로 만들어졌습니다

위의 두 애니메이션은 모두 우리 제품의 실제 출력물입니다. 사양 (Specs)으로 작성되었으며, 코드로 렌더링 (Rendered)되었습니다. 원문 포스트에서 이들은 문서 자체가 움직임을 설명하기 때문에 반복 재생되는 독립적인 SVG 파일입니다. 여기 있는 GIF들은 이 글에서 설명하는 것과 동일한 결정론적 파이프라인 (Deterministic pipeline)을 통해 생성되었으며, 이것이 바로 이들을 비용 없이 제작할 수 있었던 이유이기도 합니다.

비디오 모델 (Video model)도 관여하지 않았고, 렌더 팜 (Render farm)도 필요 없었으며, 초당 과금도 발생하지 않았습니다.

이것이 솔직한 요약입니다: 콘텐츠에 구조 (Structure)가 있다면, 모델이 사양 (Spec)을 작성하게 하고 코드가 픽셀 (Pixels)을 만들게 하십시오 — 그리고 생성형 모델 (Generative model)은 그럴 가치가 있는 장면들을 위해 아껴두십시오.