바이브 비디오: 프런트엔드 코드를 작성해 영화를 만드는 코딩 모델

지난 한 달 동안 세계에서 가장 화제가 된 AI 영상은 비디오 모델이 만든 것이 아니었습니다. 애니메이션이 나타날 때까지 프런트엔드 코드를 작성한 코딩 모델이 만든 것이었습니다.

이 클립들은 Claude Opus 5.5에서 나왔습니다. 널리 공유된 한 사례에서 한 크리에이터는 참조 프롬프트와 Midjourney 접근 권한, 무드 보드를 활용해 약 12시간 만에 시네마틱한 디스토피아 단편을 완성했습니다. 그 게시물은 2,000만 뷰를 넘었습니다. 또 다른 크리에이터는 단 하나의 지시로 2분 16초짜리 문명사 작품을 만들어 이틀 만에 1,000만 뷰를 돌파했습니다. Opus 5.5 영상을 모은 GitHub 컬렉션에는 400개 이상의 항목이 모였고, 대부분 프롬프트와 코드가 공개되어 있습니다.

사람들은 이것을 바이브 비디오(Vibe Video)라고 부르기 시작했습니다. 이름은 어색하지만, 이 기법은 이해할 가치가 있습니다. 다른 모든 이들이 가고 있는 길과는 근본적으로 다른, 움직이는 이미지로 가는 경로이기 때문입니다.

렌더링 엔진으로서의 코드

일반적인 AI 영상 파이프라인은 픽셀을 예측하는 확산 모델입니다. 프롬프트나 정지 이미지를 넣으면 프레임이 나옵니다. 모델은 영상으로 학습되며, 움직임에 대한 감각은 그 데이터에서 배웁니다.

코드 렌더링은 다르게 작동합니다. 언어 모델이 애니메이션을 그리는 HTML, CSS, SVG 또는 JavaScript를 작성하면 브라우저가 이를 렌더링합니다. 프레임 단위로 예측되는 것은 아무것도 없습니다. 움직임은 위치, 타이밍, 이징(easing)을 명시적으로 기술하는 코드에서 나옵니다.

이 차이가 중요한 이유는, 확산 모델이 어려워하는 일부 작업을 코드는 쉽게 해내기 때문입니다. 정밀한 그래픽, 타이포그래피, 차트, 기하학적 움직임, 화면 간 전환은 코드일 때 trivial합니다. 바로 그 요소들이 비디오 모델에서는 뿌옇게 나오는 것들입니다. 대가는 코드 렌더링이 사실적인 움직이는 인간의 얼굴을 만들어내지 못한다는 점입니다. 코드가 기술할 수 있는 것만 그립니다.

크리에이터들이 열광한 이유

두 가지 속성이 이 열광을 설명합니다. 첫째는 재현성입니다. 확산 클립은 표본입니다. 다시 실행하면 쌍둥이가 아니라 사촌이 나옵니다. 코드로 만든 애니메이션은 프로그램입니다. 값 하나를 바꾸면 무슨 일이 일어날지 압니다. 그래서 수정이 저렴해지고, 실제로 대부분의 작업은 바로 그 수정에 있습니다.

둘째는 결과물이 이미 나머지 워크플로가 사용할 수 있는 형식이라는 점입니다. 브라우저 애니메이션은 캡처하거나 사이트에 삽입하거나 데이터 소스에 연결할 수 있습니다. 제품 페이지나 대시보드 안에 자연스럽게 자리 잡는데, 모션에 대한 상업적 수요가 실제로 많이 발생하는 곳이 바로 그곳입니다.

공급 측 이유도 있습니다. Claude Opus 5.5는 9월 22일에 230페이지 분량의 시스템 카드와 함께 출시되었고, API 가격은 입력 100만 토큰당 4달러, 출력 100만 토큰당 20달러였습니다. 대부분의 작업에서 이전 플래그십에 근접한 벤치마크를 의미 있게 낮은 비용으로 달성했습니다. 더 저렴한 프런티어 모델은 개인에게도 길고 반복적인 코드 생성이 실용적이 되게 해주며, 12시간짜리 작업이 실제로 요구하는 것이 바로 그것입니다.

또 다른 차선

같은 주에 또 다른 범용 모델이 다른 방향에서 영상으로 진입하고 있었습니다. GPT-6 Astra는 일종의 AI 감독으로서 스토리보드 기획과 화이트 모델 프리비주얼라이제이션을 담당하고, Blender, 언리얼 엔진, DaVinci Resolve에 접근해 장면을 만들고 샷을 블로킹하며 편집까지 처리하는 것으로 보도되었습니다.

둘을 나란히 놓으면 하나의 패턴이 보입니다. 범용 모델들은 Seedance나 Kling, MiniMax를 사실적인 모션에서 이기려 하지 않습니다. 그들은 상류로, 즉 기획과 제작 파이프라인으로 이동하고 있으며, 옆으로는 사진적이라기보다 프로그래밍적인 모션으로 이동하고 있습니다. 그 결과 특화된 비디오 모델들은 사실성을 계속 밀어붙이고, 범용 모델들은 소프트웨어처럼 보이는 공정의 일부를 가져갑니다.

워크플로는 실제로 어떻게 돌아가는가

좋은 결과를 얻는 크리에이터들이 설명하는 과정은 영화 제작보다 소프트웨어 개발에 가깝습니다. 분위기와 제약을 설정하는 프롬프트를 쓰면 모델이 코드를 생성하고, 코드가 브라우저에서 렌더링되며, 결과를 봅니다. 그리고 한 가지를 바꿔 다시 실행합니다. 루프가 짧고 결과물을 들여다볼 수 있기에 12시간짜리 작업이 가능합니다. 비디오 모델에 문단 하나를 12시간 동안 맡긴다면 잡음만 나올 것입니다. 코드를 12시간 동안 편집하면 완성된 작품이 나옵니다.

무드 보드와 참조 모델이 중요한 이유는 구도와는 아무 관련이 없습니다. 그것들은 스틸 이미지에 일관된 팔레트와 피사체를 부여해서, 코드가 그것들을 배치하고 그 주위를 애니메이션할 때 조각들이 한 편의 영화에 속한 것처럼 보이게 합니다. 코드는 모션과 타이포그래피를 공급합니다. 스틸은 세계를 공급합니다. 어느 한쪽도 다른 쪽 없이는 작동하지 않습니다.

비용은 실제로 어디에 발생하는가

렌더링이 자기 컴퓨터의 브라우저에서 일어나니 코드 렌더링 영상이 무료라고 생각하기 쉽습니다. 모델 호출은 무료가 아니고, 루프는 깁니다. 모든 재작성은 유료 요청이고, 수백 번의 편집이 있는 작품은 큰 컨텍스트가 붙은 수백 번의 요청입니다. Anthropic의 입력 100만 토큰당 4달러 가격 인하가 그 루프를 스튜디오뿐 아니라 개인에게도 감당 가능하게 만들었습니다. 모델이 저렴할수록 크리에이터는 더 자유롭게 반복할 수 있고, 반복이 바로 이 방법의 전부입니다.

여기서 이상한 결과가 나옵니다. 이 스타일의 병목은 렌더링용 컴퓨트가 아닙니다. 검토입니다. 누군가 각 렌더를 보고 무엇을 바꿀지 결정해야 하며, 그 주의력은 낮아진 API 가격에 따라 확장되지 않습니다. 바이브 비디오로 성공하는 크리에이터들은 기능적으로 데일리를 보며 노트를 주는 감독입니다. 다만 그 노트가 diff로 들어간다는 점만 다릅니다.

나란히 놓고 본 코드 렌더링과 생성 영상

어떤 스타일이 무엇을 하는지 정확히 아는 게 도움이 됩니다. 코드 렌더링은 재현 가능하고, 수정이 저렴하고, 그래픽과 텍스트에서 선명하며, 데이터와 잘 어울립니다. 사실적인 배우나 군중, 자연스러운 순간을 생성하지는 못합니다. 확산 영상은 그런 것을 잘하고, 나머지 모든 것을 근사치로 처리합니다. 비디오 모델로 렌더링한 로고는 거의 맞게 나옵니다. 코드로 렌더링한 로고는 정확합니다.

이 구분은 둘이 경쟁하기보다 공존할 것임을 시사합니다. 한 작품이 생성된 설정 샷으로 열고, 코드로 만든 애니메이션 차트로 전환하고, 생성 영상으로 마무리할 수 있습니다. 흥미로운 창작적 질문은 어떤 도구를 쓸 것인가가 아니라 어디에서 전환할 것인가가 됩니다. 그 이음매를 파악하는 팀들이 의도적으로 읽히는 작업을 만들 것입니다.

작동하지 않는 곳

코드 렌더링은 영상 생성의 대체물이 아니며, 그렇게 취급하면 사람들을 실망시키게 됩니다. 배우를 촬영할 수 없습니다. 다큐멘터리 프레임이나 설득력 있는 군중을 만들어낼 수 없습니다. 디자인, 추상적 모션, 정보, 인터페이스에는 강하고, 카메라가 거기 있었던 것처럼 보여야 하는 모든 것에는 약합니다.

아무도 말하지 않는 비용 구조도 있습니다. 한 프레임이 제대로 보이기 전까지 모델 토큰을 많이 태울 수 있습니다. 왜냐하면 루프가 작성하고, 렌더링하고, 검토하고, 다시 작성하는 것이기 때문입니다. 저렴한 모델은 그 비용을 낮추지만 없애지는 못합니다. 눈에 띄는 결과를 얻는 크리에이터들은 단지 프롬프트를 넣는 게 아니라 코드를 검토합니다.

이것이 분야에 말해주는 것

바이브 비디오에서 흥미로운 점은 코딩 모델이 멋진 클립을 만들 수 있다는 게 아닙니다. '영상 생성'과 '움직이는 것을 만드는 소프트웨어' 사이의 경계가 누구도 가정했던 것보다 훨씬 부드럽다는 사실이 드러났다는 점입니다. 언어 모델이 애니메이션을 직접 작성할 수 있을 때, 생성형 비디오에 대한 수요의 일부는 대신 코드로 충족됩니다.

비주얼을 만드는 사람들에게 실질적인 질문은 더 이상 하나의 도구를 고를지 여부가 아닙니다. 작품의 어느 부분이 예측된 프레임으로 가장 잘 처리되고, 어느 부분이 작성된 코드로 가장 잘 처리되는가입니다. 지금 그것을 파악하는 팀들이 단순히 생성된 것이 아니라 의도적으로 보이는 작업을 만들게 될 것입니다.