최근 저는 고통스러울 정도로 상세한 프롬프트(Prompt)를 사용하는 바이브 코딩(vibe coding)을 통해 짧은 세로형 비디오를 만드는 방법을 연구하고 있었습니다.

저는 실수를 방지하기 위해 내레이션, 타이밍, 종횡비(aspect ratio), 색상 팔레트(color palette), 자막 규칙, 전환 효과(transitions), 증거 스크린샷, 음악 방향, 심지어 피해야 할 시각적 클리셰(visual clichés) 목록까지 프롬프트에 작성했습니다. 저는 결과물을 실제 모델의 응답, 강조된 필드, 예산 비교, 깔끔한 모니터링 인터페이스가 포함된 "AI 검색 조사"라고 묘사했습니다.

결과물로 돌아온 것은 해상도가 정확하고, 장면들이 대략 올바른 순서로 나타나며, 숫자가 정확한 유효한 MP4 파일이었습니다. 하지만 그것은 마치 애니메이션 파워포인트(PowerPoint)처럼 보였습니다.

원, 사각형, 진행 바(progress bars), 그리고 매우 큰 텍스트들이 있었습니다. 한 장면에서는 링 안에 "300,000"이 표시되었습니다. 다른 장면에서는 평평한 수평 막대 옆에 범위가 표시되었습니다. 실제 시각적 스토리의 대부분—AI 인터페이스, 검색 증거, 비용 항목, 순위 변화—은 조용히 사라져 버렸습니다.

AI는 체크리스트를 따랐습니다. 하지만 핵심은 완전히 놓쳤습니다.

프롬프트는 상세했지만, 시각적으로 구체적이지 않았다

저의 첫 번째 반응은 프롬프트가 여전히 충분히 상세하지 않다는 것이었습니다.

그 후 다시 살펴보았습니다. 이미 여러 페이지 길이에 달했습니다. 비디오를 "더 세련되게(more polished)", "더 영화처럼(more cinematic)", 또는 "더 하이테크하게(more high-tech)" 만들어 달라는 문단을 추가한다고 해서 문제가 해결되지는 않았을 것입니다.

문제는 제가 두 가지 서로 다른 요소를 하나의 문서에 섞어 놓았다는 점이었습니다:

• 제작 요구사항 (Production requirements)
• 크리에이티브 디렉션 (Creative direction)

제작 요구사항은 검증하기 쉽습니다. 비디오가 1080×1920이거나 아니거나, 장면이 6초 동안 지속되거나 아니거나, 자막이 세이프 에어리어(safe area) 안에 나타나거나 아니거나 하는 식입니다.

크리에이티브 디렉션은 훨씬 더 어렵습니다.

“진짜 수사물 같은 느낌으로 만들어줘”라는 말은 사람에게는 명확하게 들리지만, 수십 가지의 결정 사항을 해결되지 않은 상태로 남겨둡니다. 인터페이스가 브라우저를 닮아야 할까요, 터미널을 닮아야 할까요, 아니면 분석 대시보드(analytics dashboard)를 닮아야 할까요? 화면의 밀도는 어느 정도여야 할까요? 스마트폰에서 자막은 어느 정도 크기로 느껴져야 할까요? 무엇이 프레임을 기업용(corporate) 느낌이 아닌 수사물(investigative) 느낌이 나게 만들까요?

이러한 선택지들이 부재할 때, 에이전트(agent)는 자신이 아는 가장 안전한 시각적 어휘를 사용했습니다. 바로 카드, 원, 큰 숫자, 그리고 부드러운 슬라이드 전환(slide transitions)입니다.

다시 말해, 에이전트는 모호함을 기하학(geometry)으로 변환한 것입니다.

프로그래매틱 비디오(Programmatic video)는 다른 문제를 해결합니다

이 경험을 통해 저는 AI 생성 비디오의 기반이 되는 도구들을 더 주의 깊게 살펴보게 되었습니다.

Remotion은 React 코드를 신뢰할 수 있는 단일 원천(source of truth)으로 취급합니다. 장면(scenes)은 컴포넌트(components)로 작성될 수 있으며, 데이터와 연결되고, 브라우저에서 미리 볼 수 있으며, 배치(batches) 단위로 렌더링될 수 있습니다. 비디오에 반복적인 레이아웃, 동적 데이터, 재사용 가능한 컴포넌트, 또는 대규모로 생성해야 하는 콘텐츠가 포함될 때 특히 매력적입니다.

HyperFrames는 다른 접근 방식을 취합니다. 컴포지션(composition)은 HTML과 CSS로 작성되며, 타이밍은 데이터 속성(data attributes)과 탐색 가능한 애니메이션(seekable animations)을 통해 설명됩니다. 이는 GSAP, Lottie, Three.js, CSS 애니메이션 및 기타 브라우저 네이티브 도구와 함께 작동할 수 있으며, 그 결과를 headless Chrome과 FFmpeg를 통해 렌더링합니다.

이 차이는 중요합니다.

Remotion은 React의 구조와 컴포넌트 모델을 제공합니다. HyperFrames는 에이전트가 이미 끊임없이 생성하고 있는 형식인 HTML과 CSS를 제공합니다. 둘 중 어느 것도 자동으로 '취향(taste)'을 제공하지는 않지만, 두 방식 모두 타이밍, 레이아웃, 에셋(assets), 렌더링을 생성된 비디오 파일 안에 숨겨버리는 대신 편집 가능한 상태로 만들어 줍니다.

이것이 제가 생각하는 프로그래매틱 비디오(programmatic video)의 진정한 장점입니다. 실수를 수정할 수 있게 해준다는 점입니다.

자막이 너무 크다면 토큰(token) 하나만 바꾸면 됩니다. 모든 장면에 빈 공간이 너무 많다면 공유 레이아웃을 업데이트하면 됩니다. 내레이션을 녹음한 후 타이밍이 바뀌었다면, 타임라인(timeline)을 따라 모든 클립을 수동으로 옮기는 대신 설정 파일(configuration file)을 조정하면 됩니다.

하지만 코드는 누군가가 올바른 시각적 결정을 내린 이후에야 비로소 제어권을 제공합니다.

다음에 제가 다르게 할 일

가장 큰 실수는 시각적 언어(visual language)를 검증하기 전에 전체 비디오를 생성해 버린 것이었습니다.

다음에는 가장 어려운 10~15초 구간부터 시작할 것입니다. 이 사례의 경우, 세 개의 AI 모델이 동일한 브랜드를 추천하고 네 번째 모델이 놀라운 답변을 내놓는 순간이 될 것입니다.

전체 렌더링(render)을 시작하기 전에, 해당 샘플이 몇 가지 질문에 답할 수 있어야 합니다:

• 스크린샷이 증거처럼 느껴지는가, 아니면 단순한 장식인가?
• 스마트폰 화면에서도 텍스트를 읽을 수 있는가?
• 애니메이션에 속도 변화와 일시 정지(pause)의 변주가 있는가?
• 인터페이스가 조사(investigation)를 수행하는 듯한 느낌을 주는가?
• 시각적 레이어(visual layers)가 단순히 나레이션을 반복하는 것 이상의 역할을 하고 있는가?

만약 그 몇 초가 제대로 작동하지 않는다면, 동일한 스타일로 다른 1분을 더 렌더링하는 것은 단지 더 긴 실수를 만들어낼 뿐입니다.

또한 저는 모호한 미적 표현들을 눈에 보이는 규칙들로 대체할 것입니다.

"첨단적인 느낌이 나게 해줘"라고 말하는 대신, 흑연색 배경, 하나의 강조 색상(accent color), 작은 기술적 라벨, 절제된 스캐닝 애니메이션, 메인 레이어로 사용되는 실제 스크린샷, 그리고 과도하게 크고 둥근 카드(rounded cards)를 사용하지 말 것과 같이 구체적으로 지정할 수 있습니다.

"현대적인 자막을 사용해줘"라고 말하는 대신, 폰트, 굵기(weight), 최대 너비, 줄 수, 위치, 그림자, 그리고 어떤 세 문장이 전체 화면 타이틀이 될 수 있는지를 정의할 수 있습니다.

참조 프레임(Reference frames)은 훨씬 더 도움이 될 것입니다. 몇 개의 주석이 달린 스크린샷은 500단어의 형용사보다 계층 구조(hierarchy), 밀도(density), 질감(texture)을 훨씬 더 잘 설명할 수 있습니다.

에셋은 의존성(dependencies)으로 취급되어야 합니다

또 다른 교훈은 누락된 시각적 에셋(visual assets)이 조용히 추상적인 도형으로 대체되어서는 안 된다는 점입니다.

만약 한 장면에서 네 개의 실제 AI 응답이 필요한데 스크린샷이 두 개뿐이라면, 에이전트(agent)는 작업을 중단하고 나머지 두 개를 누락된 것으로 표시해야 합니다. 증거가 필요하지 않았던 것처럼 가장하는 세련된 애니메이션보다는 명확하게 라벨이 붙은 플레이스홀더(placeholder)가 훨씬 더 유용합니다.

이제 저는 비디오 에셋이 코드의 의존성(dependencies)과 매우 유사하게 처리되어야 한다고 생각합니다:

1. 필요한 모든 에셋(asset)을 나열합니다.
2. 이를 장면(scene)에 매핑합니다.
3. 해당 에셋이 존재하는지 검증합니다.
4. 누락되었거나 저해상도인 파일을 표시합니다.
5. 그 후에야 전체 컴포지션(composition)을 빌드합니다.

이것은 한 번에 완성된 비디오를 프롬프트(prompting)로 요청하는 것보다 덜 흥미롭게 들릴 수 있지만, 전체 제작 과정이 원래의 아이디어에서 벗어나는 것을 방지해 줍니다.

어쩌면 AI는 비디오를 만들기 전에 시스템을 먼저 구축해야 할지도 모릅니다

저는 여전히 AI 코딩 에이전트(coding agents)가 비디오 제작에 진정으로 유용하다고 생각합니다.

에이전트는 장면의 스캐폴딩(scaffold)을 구성하고, 타이밍을 중앙 집중화하며, 재사용 가능한 애니메이션 컴포넌트(component)를 만들고, 자막 파일을 생성하며, 키프레임(keyframe)을 검사하고, 여러 버전을 렌더링(render)할 수 있습니다. Remotion이나 HyperFrames와 같은 도구들은 이러한 워크플로우(workflow)를 훨씬 더 접근하기 쉽게 만들어 줍니다.

지금 제가 덜 신뢰하는 것은 "여기 내 스크립트가 있어. 완성된 비디오를 만들어줘"와 같은 원샷(one-shot) 요청입니다.

더 나은 업무 분담은 다음과 같을 수 있습니다:

1. 인간이 시각적 언어(visual language)를 정의합니다.
2. 에이전트가 이를 바탕으로 재사용 가능한 시스템을 구축합니다.
3. 양측이 짧은 샘플을 바탕으로 반복(iterate)합니다.
4. 해당 시스템이 검토를 통과한 후에만 전체 비디오를 렌더링합니다.

이 프로세스는 처음 15초 동안은 더 느리지만, 나머지 60초 동안은 훨씬 더 빠릅니다.

저는 프롬프팅(prompting)이 어디서 끝나고 크리에이티브 디렉션(creative direction)이 어디서 시작되는지 여전히 파악 중입니다. 어쩌면 프로그래매틱 비디오(programmatic video)가 결국 그 경계를 사라지게 만들지도 모릅니다. 현재로서는 AI가 자신이 검증할 수 있는 것을 구축하는 데 매우 능숙하며, 그 외의 모든 것은 사각형으로 근사(approximate)하려는 경향이 매우 강해 보입니다.

여러분은 이 간극을 어떻게 다루시나요? 시각적 참조(visual references)를 제공하시나요, 한 장면을 먼저 프로토타입(prototype)으로 만드시나요, 아니면 크리에이티브 디렉션의 마지막 단계는 여전히 수작업으로 이루어져야 한다는 점을 받아들이시나요?