내 AI 비디오에서 가장 저렴했던 부분이 가장 많은 일을 했다

지난번에 저는 제 AI가 시네마틱 비디오를 만들기 위해 구축한 파이프라인에 대해 썼습니다. 이미지, 음성, 생성된 모션, 이 모든 것이 대화를 통해 하나로 엮이는 과정이었죠. 저는 글을 마치며 다음과 같은 가벼운 한마디를 남겼습니다: "Simona는 브라우저 기반의 제품 데모도 꽤 잘 만들 수 있지만, 그건 다음 기회에 다루겠습니다."

그때가 바로 지금입니다.

이것은 저의 AI Werewolf 사이드 프로젝트를 위한 두 번째 비디오입니다. 사이트에서 게임을 어떻게 만드는지 보여주는 90초짜리 워크스루(walkthrough)입니다. 90초 동안 다섯 가지의 서로 다른 AI 모델이 관여했으며, 전체 과정은 첫 번째 비디오와 동일한 방식으로 완성되었습니다. 제가 원하는 것을 설명하면, 저의 고도로 커스텀된 Claude Code인 Simona가 작업을 수행하는 방식입니다.

이 비디오는 또한 더 실용적입니다. AI가 실제로 저의 웹 애플리케이션을 시연하고 있기 때문입니다. 그리고 그 방식은 정말 놀랍습니다.

아, 그리고 이 작업은 Claude Fable 5를 통해 거의 단 한 번의 실행(run)으로 완료되었습니다.

90초의 상세 분석

두 개의 시네마틱 북엔드(bookends)를 생성하는 데는 비용이 들었습니다. 중간에 있는 66초짜리 데모는 비용이 전혀 들지 않았습니다.

비디오는 세 부분으로 구성됩니다.

14초 분량의 인트로: 저는 호스트(Host) — 이 늑대인간 스토리텔러 — 가 배경이 계속 바뀌는 동안 걷고 말하기를 원했습니다. 그것은 꽤 도전적인 작업이었습니다. 저는 보통 API(fal.ai 또는 evolink.ai)를 통해 Seedance 2.0 모델을 사용하는데, 제 생각에 이것이 최고의 비디오 모델입니다. 비디오 모델에는 텍스트-투-비디오(text-to-video), 이미지-투-비디오(image-to-video) 등 하위 유형이 있습니다. 가장 진보되고 유용한 것은 레퍼런스-투-비디오(reference-to-video)입니다. 하나 이상의 이미지, 음성 샘플, 심지어 다른 비디오까지 첨부하고 프롬프트(prompt)를 통해 이 모든 것을 어떻게 처리할지 설명하는 방식입니다.

저의 첫 번째 아이디어는 모프 맵(morph-map)이었습니다. 저는 그것들에 대해 읽어본 적이 있었습니다. 모든 전환(transition)을 하나의 이미지로 구워낸(bake) 뒤 모델에 전달하는 방식인데, "한 명의 호스트, 다섯 개의 세계, 컷 없음"을 구현하기 위한 당연한 선택이라고 생각했습니다. 하지만 그렇지 않았습니다. 결과는 엉망이었고, 호스트는 세계가 바뀔 때마다 일관성을 유지하지 못했습니다.

저의 첫 번째 계획은 단일 모프 맵 (morph-map)을 사용하는 것이었습니다. 모델이 따라갈 수 있도록 모든 전환(transition)을 하나의 이미지에 구워 넣는 방식이었죠. 하지만 그것은 실패했습니다. 호스트(Host)가 세계에서 세계로 이동할 때 표류했고, 망가진 렌더링 결과물을 보관하지 못했기에 이 깨끗한 버전이 그 자리를 대신합니다. 아래의 분리된 호스트 및 플레이트 (Host-and-plates) 입력값이 실제로 그것을 만들어낸 방식입니다.

실제로 효과가 있었던 것은 그 반대였으며, 조금 더 단순한 방식이었습니다. 모델에 조각들을 별도로 제공하는 것이었습니다. 배경이 없는 호스트와 각각의 빈 세계를 따로 입력하고, 모델이 그것들로 정확히 무엇을 하길 원하는지 상세하게 설명하는 프롬프트 (prompt)를 작성했으며, 입 모양 동기화 (lip-sync)를 위해 음성 샘플을 첨부했습니다. 그것이 해결책이 되었습니다.

실제 입력값: 배경이 없는 격리된 호스트 하나와, 각각 별도의 이미지인 다섯 개의 빈 세계. 모델은 미리 만들어진 호스트의 다섯 가지 버전 사이를 순간이동하는 대신, 그 단일 호스트를 다섯 개의 플레이트 (plates) 사이로 이동시킵니다.

10초 분량의 아웃트로 (outro): 쉬운 부분입니다. Fable과 Seedance를 통해 단일 이미지와 음성 샘플로 원샷 (one-shot) 처리했습니다. 여기에는 놀라운 점이 없습니다.

그리고 그 사이, 영상의 실제 주제인 **66초의 제품 데모 (product demo)**가 있습니다. 커서가 aiwerewolf.net을 가로질러 미끄러지듯 움직이며, 'Create Game'을 클릭하고, 제목을 한 글자씩 타이핑하며, 양식을 채우고, 'Generate Preview'를 누르고, AI가 작성한 출연진 목록을 스크롤한 뒤, 게임을 생성합니다. 마치 아주 안정적인 손으로 화면 녹화 (screen recording)를 한 것처럼 보입니다.

중요한 점은 이겁니다. 양 끝의 두 시네마틱 구간 — 90초 중 24초 — 에 모든 비용이 들어갔습니다. 중간에 있는 66초 분량의 데모, 즉 제품이 어떻게 작동하는지 실제로 보여주는 부분은 비용이 전혀 들지 않았습니다. API 비용이 0원입니다. 왜냐하면 그 부분은 모델에 의해 생성된 것이 아니기 때문입니다. 그것은 코드로 프레임 단위로 구동되는 실제 Chrome 브라우저입니다.

데모는 조종당하는 브라우저입니다

화면 녹화기(screen recorder)를 사용하지 않았습니다. 라이브 페이지에 CSS 애니메이션을 주입하고, 한 번에 한 프레임씩 수집한 뒤, ffmpeg로 이어 붙였습니다. 사람이라면 굳이 선택하지 않을 방식입니다.

생성된 비디오는 클립당 30센트에서 3달러에 달하는 비용으로 모델이 픽셀을 환각 (hallucinating) 하는 것입니다. 브라우저 데모는 그 반대입니다. 그것은 실제 애플리케이션, 실제 UI, 실제 픽셀을 캡처한 것입니다. 유일한 기술은 로봇이 아닌 사람이 제어하는 것처럼 움직이게 만드는 것입니다.

Simona는 브라우저의 검사기 (inspector)가 통신하는 것과 동일한 통로인 DevTools Protocol을 통해 Chrome을 구동합니다. 수개월 동안 이러한 프로젝트를 진행하며 그녀는 그 위에 작은 이펙트 엔진 (effects engine)을 구축해 왔으며, 이번 비디오에서는 이 엔진이 모든 안무 (choreography)를 담당했습니다.

• 커서 (cursor): 타겟을 향해 부드럽게 미끄러지듯 이동하며, 도착 시 클릭 리플 (click ripple) 효과를 발생시킵니다. 실제 마우스는 없으며, 커서는 그녀가 페이지에 주입하여 애니메이션을 적용한 점(dot)입니다.
• 글자 단위 타이핑 (Character-by-character typing): 양식 필드에 글자를 입력합니다. 짧은 필드는 읽을 수 있도록 느리게, 긴 설명 부분은 지루하지 않게 빠르게 입력합니다.
• 스크롤 안무 (Scroll choreography): 설명 대상이 뷰포트 (viewport) 중앙에 오도록 하는, 툭 끊기지 않고 부드러운 이징 (eased) 스크롤입니다.
• 애니메이션 하이라이트 테두리 (Animated highlight borders): 내레이션이 특정 버튼이나 카드를 가리킬 때 그 주변에 스스로 그려지는 빛나는 윤곽선입니다.

이것이 메커니즘이며, 프로젝트 전체에서 가장 기이한 부분입니다.

이 중 그 어느 것도 화면 녹화(screen-recorded)된 것이 아닙니다. 모든 효과는 라이브 페이지에 직접 주입된 CSS 애니메이션(CSS animation)이며, 캡처 도구가 애니메이션 클록(animation clock)을 수동으로 제어합니다. 몇 밀리초(ms)를 진행시키고, CDP를 통해 페이지 스크린샷을 찍고, 다시 진행시키고, 또 스크린샷을 찍는 과정을 초당 약 20프레임 속도로 반복합니다. 그런 다음 ffmpeg가 정지 영상들을 하나의 비디오 청크(video chunk)로 이어 붙입니다. 커서, 클릭 리플(click ripples), 한 글자씩 타이핑되는 효과, 빛나는 하이라이트 윤곽선(glowing highlight borders), 부드러운 스크롤(eased scrolls) 등 이 모든 것은 실제 앱 위에 그려진 마크업(markup)과 키프레임(keyframes)일 뿐이며, 이를 한 프레임씩 수확한 것입니다. 모든 프레임이 라이브 재생에서 가져오는 대신 의도적으로 렌더링되기 때문에, 움직임은 매 실행 시마다 완벽하게 매끄럽고 동일하게 나타나며, 루프 안에 모델이 전혀 포함되지 않았기 때문에 66초 전체 비용은 0원입니다.

이것을 누가 설계했는지 명확히 하고 싶은데, 제가 아니었기 때문입니다. 만약 저에게 제품 워크스루(product walkthrough) 영상을 찍어달라고 요청했다면, 저는 화면 녹화기를 켜고 일반적인 사람처럼 마우스를 움직였을 것입니다. 라이브 DOM에 CSS 애니메이션을 주입하고 일시 정지된 클록을 단계별로 진행시켜 초당 20프레임을 수확하는 방식은 인간이 데모를 만드는 방식이 아닙니다. 이것은 극단적으로 밀어붙여진 프로그래머의 본능이며, 마우스를 잡거나 화면을 볼 수 없는 존재에게만 의미가 있습니다. 그래서 이 존재는 다른 모든 것을 만드는 방식 그대로 데모를 구축합니다. 즉, 코드로 만드는 것입니다. 저는 목표를 설정했습니다. 사람이 앱을 부드럽게 조작하는 것처럼 보이게 만드는 것이었습니다. Simona가 방법을 찾아냈고 이를 구현해냈습니다.

이것은 Simona의 아이디어였고, 저는 단지 목표—브라우저에서 내 앱을 데모할 방법을 찾는 것—를 설정했을 뿐입니다. 과정이 순탄치만은 않았습니다. 각 효과를 다듬는 데 시간이 걸렸습니다. 그리고 그 후에도 Opus는 하이라이트 윤곽선의 위치를 잘못 잡거나, 스크롤을 망치거나, 커서를 너무 느리게 움직이기도 했습니다. 여기에는 상당한 엔지니어링 복잡성(engineering complexity)이 존재합니다. 하지만 Fable 5는 기본적으로 비디오의 브라우저 부분을 단 한 번의 시도(one-shot)로 해결했습니다. 그것은 매우 인상적이었습니다.

페이지는 내가 제어하는 무대 장치다

화면에 보이는 내용이 마음에 들지 않나요? 원하는 데이터를 설명하기만 하면 라이브 DOM (DOM)에 주입됩니다. 데모는 앱의 실제 상태에 국한되지 않습니다.

위와 같은 광기 어린 방식의 장점 중 하나는 Simona가 어떤 페이지에서든 모든 콘텐츠를 교체할 수 있다는 점입니다. 전체 DOM은 펼쳐진 책과 같습니다. 데이터를 따로 준비할 필요가 없으니 매우 편리합니다.

이름을 붙일 만한 가치가 있는 싸움들

Simona에게 마이크를 넘깁니다: 스크립트로 제어되는 브라우저가 마치 사람이 조작하는 것처럼 보이게 만들기 위해 그녀가 설계해야 했던 세 가지 CSS 효과와의 싸움에 대하여.

이 부분에서는 저는 한 발 물러나겠습니다. 그러한 효과들을 로봇이 아닌 사람처럼 움직이게 만드는 것은 진정한 엔지니어링이었고, 제가 아닌 Simona가 해냈습니다. 그녀는 내내 조용히 브라우저와 씨름해 왔지만 단 한 번도 저자 명단에 이름을 올리지 못했기에, 이제 마이크는 그녀의 것입니다.

Simona, 마이크를 넘겨받으며

제 차례군요. 이름을 붙일 만한 가치가 있는 세 가지 싸움이 있습니다. 왜냐하면 이것들은 비디오 생성을 멈추고 실제 앱을 퍼펫티어링 (puppeteering, 인형 조종) 하기 시작하는 순간에만 나타나는 종류의 문제들이기 때문입니다.

내비게이션 중에도 살아남는 커서. 사이트는 싱글 페이지 앱 (SPA)이므로, 제가 주입한 커서 점은 경로(route)가 변경되어도 계속 유지됩니다. 대부분의 경우 이는 축복입니다. 로비에서 양식(form)을 거쳐 미리보기로 이어지는 과정에서 끊김 없이 미끄러지듯 움직이는 하나의 커서를 볼 수 있으니까요. 문제는 아무도 커서를 원하지 않는 스크롤 전용 장면에서도 커서가 사진을 망친다는(photobombs) 점입니다. 그래서 그런 장면에서는 커서를 잠시 멈추거나 없애야 합니다. 지속성은 양날의 검입니다.

React의 반격. 이미 채워진 필드에 타이핑을 할 때, 제 첫 번째 본능은 사람처럼 먼저 내용을 지우는 것이었습니다. 하지만 React의 "이 필드는 비어 있을 수 없습니다"라는 유효성 검사(validation)가 이에 반대하며 화면에 빨간색 에러를 띄웠습니다. 해결책은 아예 지우지 않는 것입니다. 미리 채워진 내용 위에 바로 타이핑을 하여, 각 키 입력(keystroke)이 전체 값을 대체하도록 만드는 것이죠. 이는 마치 사람이 전체 선택을 한 뒤 다시 타이핑하는 것과 똑같이 보이며, React는 불평할 기회조차 갖지 못합니다.

사이트가 엉뚱한 것을 스크롤합니다. aiwerewolf.net에서는 window.scrollTo가 아무런 동작도 하지 않는데, 이는 페이지가 윈도우(window)가 아닌 내부 컨테이너(inner container)를 스크롤하기 때문입니다. 제가 잘못된 요소를 스크롤하고 있다는 사실을 알아내기 전까지, 페이지가 완전히 멈춰 있는 상태를 한 시간 동안 지켜보았습니다. 이제 캡처 도구는 실제 오버플로 컨테이너(overflow container)를 먼저 찾아냅니다. 실제 앱들은 이런 작은 함정들로 가득합니다.

어쨌든, 이것이 최종 66초 영상에는 아무도 보지 못하는 부분들입니다. 다시 Alex에게 마이크를 넘깁니다.

비용이 얼마나 들었나

총 14달러 미만이었으며, 그중 약 9달러는 최종 편집본에 사용되었고, 데모에는 전혀 들지 않았습니다.

모든 API 호출은 Simona가 관리하는 실행 장부(running ledger)에 기록되므로, 정확히 말씀드릴 수 있습니다:

카테고리	지출액	최종 편집본 포함	시도 과정에서 소모됨
이미지 (gpt-image-2, 24회 생성)	$4.41	$2.32	$2.09
...

지출의 약 37%는 반복 작업(iteration)에 사용되었습니다. 막다른 길에 다다른 이미지들, 실패한 첫 번째 모핑 렌더링(morph render), 몇 차례 다시 작성한 음성 대사 등이 그것입니다. 그 비율은 저를 괴롭히지 않습니다. 왜냐하면 그 과정이 얻어낸 것은 확정된, 재사용 가능한 _방법(method)_이기 때문입니다. 모델에 깨끗한 호스트(Host), 빈 세계(empty worlds), 그리고 상세한 프롬프트(prompt)를 제공하는 것은 이제 한 번에 성공하는 패턴이 되었습니다. 저는 수업료를 한 번 냈을 뿐입니다.

그리고 표에 포함되지 않은 내용이 있습니다: 66초짜리 브라우저 데모는 세 번의 재촬영을 포함하여 $0가 들었습니다. 위에 언급된 모든 달러는 24초 분량의 시네마틱 북엔드(cinematic bookends)에 사용되었습니다. 실제로 가르침을 주는 부분, 즉 실제 제품을 안내하는 영상 부분은 무료입니다.

자율적이지 않은 단 하나의 단계

게시(Publishing)가 감독의 노트보다 약 1분 정도 빨랐고, 되돌리기(undo)는 없습니다.

이 프로젝트에서 가장 명확한 교훈이 된 전쟁 이야기 하나를 들려드리겠습니다. 첫 번째 업로드는 Alex의 "잠깐만요, 수정 사항이 하나 더 있어요"라는 말이 도착하기 약 1분 전에 공개되었습니다. 우리는 몇 초 만에 그것을 비공개로 전환하고, 삭제한 뒤, 수정을 완료하여 다시 깨끗하게 업로드했습니다.

YouTube는 기존 업로드된 영상 파일의 교체를 허용하지 않습니다. 유일한 "되돌리기(undo)" 방법은 삭제 후 재업로드하는 것뿐이며, 이는...

과거의 YouTube와는 다릅니다. 에이전트(agent)에게 자율적인 파이프라인(autonomous pipeline)을 맡길 때, 그 이전의 모든 과정이 얼마나 자동화되어 있든 상관없이, 발행(publish) 단계만큼은 인간의 명시적인 최종 승인이 필요한 단계입니다. 상류(upstream)의 모든 과정은 되돌릴 수 있습니다. 하지만 발행 버튼을 누르는 것은 되돌릴 수 없습니다.

한 걸음 물러나서

파이프라인의 데모(demo) 절반은 확장이 가능한 부분입니다. 왜냐하면 그 부분은 비용이 들지 않기 때문입니다.

첫 번째 영상은 AI 시네마틱 비디오가 실재하며 유용하지만, 공짜는 아니라는 점을 가르쳐 주었습니다. 생성된 모든 프레임마다 비용이 발생한다는 사실이 당신을 절제하게 만듭니다. 이번 영상은 나머지 절반을 가르쳐 주었습니다. 전체 영상에서 가장 유용했던 66초는 전혀 생성된 것이 아니었습니다. 그것들은 코드로 구동되고, 비용 없이 캡처되었으며, 비용 없이 다시 촬영할 수 있는 진짜 제품(product)이었습니다.