실수는 스토리보드에서 고쳐라 — 디즈니 1930년 파이프라인을 에이전트 워크스페이스로 옮기다
1930년대 디즈니 만화 영화를 만들던 공정이 AI 워크스페이스에 통할 줄은 꿈에도 몰랐다.
AI로 영상을 뽑는 이야기만 나오면 죄다 어떤 신상 모델이 최고네 마네 하는 스펙 배틀로 빠지기 일쑤다. 그런데 이번 글은 결이 완전히 다르다. r/ClaudeCode에 올라온 한 편의 글인데, 모델의 체급을 자랑하는 대신 철저하게 ‘워크스페이스 구조’ 하나만으로 퀄리티 문제를 풀어낸다. 원조는 무려 1930년대 디즈니 애니메이션 스튜디오다. 100년 전 아날로그 시절에 쓰던 공정이 2026년 AI 워크스페이스에 소름 돋을 정도로 딱 들어맞는다.
작성자인 u/VanCliefMedia는 Claude Code로 애니메이션 영상을 찍어내는 창작자다. Sonnet으로 한 땀 한 땀 장인 정신으로 만들 수도 있고, Opus 5.5를 물리면 두 시간 만에 50편까지 양산할 수도 있다고 한다. 하지만 이 글의 본질은 모델의 성능 따위가 아니다. 작성자 본인의 말마따나 “이 워크스페이스 구조야말로 영상뿐 아니라 다른 모든 AI 자동화 작업에 그대로 복붙할 수 있는 알맹이”이기 때문이다.
실수는 늦게 발견할수록 피눈물이 난다
자동화 파이프라인에 빠지기 쉬운 가장 흔한 함정이 있다. 중간 단계에서 사람이 감시하지 않고 AI한테 풀코스로 맡겨버리면, 앞단의 사소한 오타 하나가 나쁜 테이크가 되고, 그 테이크가 결국 쓰레기 영상 한 편으로 둔갑한다는 점이다. 스크립트 단계의 작은 삐끗함이 최종 렌더링 단계까지 가면 수습 불가능한 핵폭탄으로 커진다(솔직히 렌더링 한참 돌리고 나서 오타나 싱크 꼬인 거 발견하면 모니터를 부수고 싶어진다). 사람 눈을 가린 채 전자동으로만 밀어붙이면 실수는 지수함수로 불어난다는 게 작성자의 뼈아픈 관찰이다.
그래서 해결책은 단순하지만 강력하다. 문제를 무조건 맨 앞단으로 끌고 오는 것이다. 다 렌더링된 영상 프레임에서 장면 하나를 뜯어고치는 데 한 시간이 걸린다면, 텍스트 스토리보드 단계에서는 백스페이스 몇 번으로 3초 만에 끝난다. 초등학생도 알 만한 산수인데, 정작 이걸 파이프라인 전체의 핵심 룰로 박아두고 일하는 팀은 의외로 드물다.
계약서가 박혀 있는 폴더 구조
작성자의 워크스페이스는 ICM이라 부르는 깔끔한 폴더 구조로 짜여 있다.
animations/
CLAUDE.md <- 전체 지도: 무엇이 어디에 있고, 각 작업이 어디로 향하는지
CONTEXT.md <- 파이프라인 전체 프로세스를 정리한 한눈 요약표
anim.py <- 모든 실행 명령 (speak, transcribe, cues, stills, render)
stages/
01_voice/CONTEXT.md
02_transcript/CONTEXT.md
03_cues/CONTEXT.md
04_scene/CONTEXT.md
05_render/CONTEXT.md
videos/<slug>/ <- 영상 한 편당 독립된 폴더 하나씩
여기서 각 스테이지 폴더마다 들어있는 CONTEXT.md 파일이 일종의 ‘업무 계약서’ 역할을 한다. 예컨대 스토리보드 단계의 실제 계약 내용을 보면 이렇다.
# 03_cues: the storyboard
Reads: 02_transcript/transcript.md, 01_voice/brief.md, _shared/kit.md
Don't read: words.json (the command does)
1. 03_cues/cues.md를 쓴다. 화면이 바뀌는 지점마다 cue 하나
2. python anim.py cues <slug> 가 각 구절을 단어 타이밍에 맞춘다
Output: cues.md (원본), cues.js + cues.json (생성물. 손대지 않는다)
Person checks: 스토리보드를 읽는다. 볼 만한 비트가 다 들어갔는지,
이야기 순서가 맞는지.
읽어야 할 파일(Reads), 만들어낼 결과물(Output), 그리고 사람이 직접 검수할 항목(Person checks). 계약은 딱 이 세 줄로 깔끔하게 정리된다. Claude는 자기가 맡은 스테이지에 꼭 필요한 파일만 골라 읽고, 사람이 직전 산출물을 읽고 컨펌하기 전까지는 절대로 다음 단계로 멋대로 넘어가지 않는다. 루트의 CLAUDE.md는 전체 지도 역할만 하니 몇 줄 안으로 짧게 유지되고, 세부 디테일은 각 스테이지의 CONTEXT.md로 철저히 쪼개진다. 컨텍스트가 필요한 딱 그만큼만 로드되니 토큰 낭비도 없다.
1930년 디즈니로 타임머신 타기
디즈니가 1930년대 백설공주 시절에 정립했던 애니메이션 제작 공정이 정확히 이 구조와 맞닿아 있다. 당시에도 목소리 성우 녹음을 무조건 제일 먼저 진행했고, 대사를 exposure sheet(X-sheet)에 프레임 단위로 쪼개 넣었으며, 러프 스케치는 펜선 따고 채색하기 전에 sweatbox라 불리는 간이 영사실에서 감독과 스태프들이 모여 깐깐하게 검수했다.
이걸 AI 파이프라인과 1:1로 매칭해 보면 소름이 돋는다. Voice 단계에서는 구어체로 작성된 스크립트를 자기 목소리 복제 모델로 먼저 녹음한다. Words 단계에서는 Whisper가 단어 하나하나의 시작과 끝 싱크를 밀리초 단위로 찍고, 대본과 발음이 어긋난 곳에 플래그를 꽂는다. Cues 단계는 텍스트 스토리보드인데, 각 연출 비트가 실제 음성 타이밍에 단단히 물려 있어 장면의 템포가 목소리에서 자연스럽게 뿜어져 나온다. Scene 단계에서는 Claude가 캐릭터, 배경, 소품 함수들을 조합해 자바스크립트로 장면을 코딩한다. 화면의 모든 요소가 시간의 함수로 엮여 있어 별도의 타이머가 필요 없고, 렌더링 전에 콘택트 시트를 먼저 훑어보며 그래픽 겹침을 미리 잡아낸다. 마지막 Render 단계는 헤드리스 크롬이 프레임을 굽고 ffmpeg가 오디오와 효과음을 합쳐서 최종 비디오를 뱉는다.
작성자가 계약서에서 단연 첫손으로 꼽는 핵심 라인은 바로 Person checks다. 다음 단계의 스크립트가 돌아가기 전에 사람이 10초간 눈으로 확인하는 그 한 줄이, 어설픈 실수가 거대한 쓰레기 영상으로 눈덩이처럼 불어나는 참사를 원천 차단한다.
왜 여기에 주목해야 할까
에이전트 세션을 무한정 늘리고 수십만 토큰의 컨텍스트를 통째로 쏟아붓는 요즘 유행과 정반대에 서 있는 영리한 아키텍처다. 100만 토큰 컨텍스트 창이 커질수록 중간 기억이 붕괴되는 현상을 자주 목격했을 텐데, 이 방식은 파이프라인을 잘게 썰고 단계마다 사람이라는 브레이크를 걸어둔다. 스테이지마다 꼭 필요한 몇 개 파일만 쏙쏙 읽으니 컨텍스트 창에 과부하가 걸릴 틈이 없다.
그리고 또 하나. 이 파이프라인 구조에는 ‘특정 AI 모델’에 대한 의존성이 아예 없다. 텍스트 파일을 읽고 쓸 줄 아는 모델이라면 Claude든, GPT든, 심지어 로컬 LLM이든 똑같은 폴더 구조 위에서 굴릴 수 있다는 게 작성자의 설명이다. 모델 교체 주기가 몇 주 단위로 미친 듯이 빨라진 지금, 폴더 구조와 검수 계약서라는 ‘모델 중립적 자산’의 가치는 갈수록 높아질 수밖에 없다.
정리
다들 어떤 모델이 더 똑똑하냐며 벤치마크 점수 싸움에 매달릴 때, 여전히 가장 저평가된 무기는 ‘단단한 구조’다. Reads, Output, Person checks. 이 세 줄짜리 패턴은 영상 제작뿐만 아니라 코드 리뷰, 사내 문서 자동화, 대량 데이터 가공 어디에 갖다 붙여도 즉시 약발이 받는다.
작업 하나당 폴더 하나, 각 단계마다 계약서 한 장. 겉보기엔 투박하고 손이 더 가는 것처럼 보여도, 실전에서 버그 없이 굴러가는 자동화를 만들고 싶다면 결국 이 100년 전 디즈니의 지혜로 돌아오게 되어 있다.