Opus 5.5 영상 생성: 코드로 MP4 만드는 법과 한계

Opus 5.5는 영상을 직접 생성하지 못합니다. 모델이 내놓는 것은 텍스트뿐이고, "Opus 5.5로 만든 영상"이라고 올라오는 결과물은 모델이 쓴 코드를 브라우저가 한 프레임씩 그리고 ffmpeg가 MP4로 묶은 것입니다. 2026년 9월 22일 공개 뒤 퍼진 설명 영상, 제품 홍보영상, 모션그래픽이 모두 이 방식으로 나왔습니다.

그래서 만들 수 있는 영상과 없는 영상의 경계가 분명합니다. 도형, 글자, 도표, UI 화면처럼 코드로 그릴 수 있는 장면은 잘 나오고, 실사 인물이나 촬영한 듯한 질감은 나오지 않습니다. 후자가 필요하면 영상 생성 모델을 써야 하고, Opus 5.5는 그 모델을 호출해 편집을 맡는 쪽으로 물러납니다.

코드로 그리는 방식이 맞는 작업이라면 준비물은 Node.js, Chrome, ffmpeg 세 가지입니다. 아래 스크립트로 12초짜리 1080p 장면을 Apple M4 한 대에서 렌더링했을 때 프레임 캡처에 약 26초가 걸렸고 MP4는 약 0.9MB였습니다.

Opus 5.5가 실제로 내놓는 것은 영상이 아니라 코드입니다

Anthropic의 모델 개요 문서는 현행 Claude 모델 전체에 대해 입력은 텍스트와 이미지, 출력은 텍스트라고 적습니다. 영상 출력도, 이미지 출력도 없습니다. Opus 5.5(claude-opus-5-5)도 여기에 포함됩니다. Claude 도움말 센터의 이미지 관련 문서 역시 Claude가 이미지 생성 도구처럼 사진이나 일러스트를 만들지는 않지만, HTML과 SVG로 다이어그램, 차트, 인터랙티브 시각 자료를 만들 수 있다고 설명합니다. 이미지 쪽 사정은 Claude는 이미지를 생성할 수 있을까에 따로 정리되어 있습니다.

영상은 이 "코드로 그린다"는 능력을 시간 축으로 늘린 것입니다. 흐름은 네 단계입니다.

1. 모델이 장면 하나를 HTML 문서로 씁니다. Canvas, SVG, CSS, 필요하면 Three.js 같은 라이브러리를 씁니다.
2. 화면 없이 도는 헤드리스 브라우저가 그 문서를 열고, 시각 t를 1/30초씩 옮겨 가며 장면을 다시 그리게 합니다.
3. 프레임마다 스크린샷을 찍습니다.
4. ffmpeg가 스크린샷을 순서대로 받아 H.264 MP4로 인코딩합니다.

공개된 구현 가운데 가장 읽기 쉬운 것이 LaunchVideo입니다. 저장소 이름이 diggerhq/shipvideo라서 ShipVideo로 소개되기도 하지만 제품 이름은 LaunchVideo입니다. README 첫머리가 방식을 그대로 요약합니다. 영상 모델은 쓰지 않고, Opus 5.5가 1920x1080 HTML 문서 한 장으로 영상 전체를 쓰며, 헤드리스 Chromium이 프레임 단위로 렌더링한 뒤 ffmpeg가 인코딩합니다. 결과물은 20~40초 길이의 출시 영상입니다.

한 가지 짚어 둘 점은, 이 쓰임새가 Anthropic이 내세운 기능이 아니라는 것입니다. Opus 5.5 발표문에는 영상, 애니메이션, 모션그래픽이라는 말이 나오지 않습니다. 사용자들이 모델의 코드 작성 능력을 영상 쪽으로 돌려 쓰면서 알려진 용법입니다.

코드로 그리는 영상에 맞는 것과 맞지 않는 것

화면의 모든 픽셀을 코드가 계산하므로, 코드로 표현할 수 있는 그림이면 정확하고 선명하게 나옵니다. 글자가 뭉개지지 않고, 숫자와 도표가 틀리지 않으며, 색과 위치를 한 줄 고쳐 다시 렌더링할 수 있습니다. 반대로 코드로 묘사하기 어려운 것, 곧 사람 얼굴이나 피부, 머리카락, 자연광이 드는 촬영 화면은 이 방식으로 나오지 않습니다.

이 구분은 공개 사례를 모은 opus-video-prompts 저장소의 정리와 맞습니다. 2026년 9월 22~25일 사례를 본 이 저장소는 모션그래픽, 손그림과 선화와 수묵 애니메이션, 설명 영상, 출시 영상, 가사 영상을 잘 되는 쪽으로, 실사 촬영 장면을 안 되는 쪽으로 꼽습니다. 실사 화면이 필요할 때는 Opus 5.5가 Seedance, Runway, Higgsfield 같은 영상 모델을 호출하고 자신은 구성과 편집을 맡는 것이 흔한 방법이라고 적습니다. 측정이 아니라 정리한 사람의 판단이라는 점은 감안해야 합니다.

사람들이 실제로 무엇을 만들고 있는지는 awesome-opus-5-5-videos의 집계가 보여 줍니다. 2026년 9월 26일까지 X에서 모은 영상 파일 1,401개 가운데 분류기가 Opus 관련으로 표시한 것이 1,119개이고, 그중 모션그래픽과 UI가 350개, 3D 렌더가 324개로 둘을 합쳐 60.2%입니다. 주제는 게임과 인터랙티브 230개, 광고와 출시 215개, AI를 다룬 AI 영상 201개 순입니다. 다만 저장소 스스로 밝히듯 라벨은 게시물 텍스트와 프레임 9장을 다른 모델이 읽어 붙인 것이어서, 각 영상을 정말 Opus 5.5가 만들었는지를 증명하지는 않습니다. 공개된 표본의 분포로만 읽으면 됩니다.

실사 영상이 필요하다는 결론이 났다면 출발점이 달라집니다. 영상 생성 모델은 초 단위로 요금을 매기므로 AI 동영상 생성 비용에서 초당 가격과 편당 예산을 먼저 확인하고, 코드로 호출하는 방법은 Seedance 2.5 API 연동을 참고하면 됩니다.

첫 MP4를 내 컴퓨터에서 렌더링하기

설치할 것은 세 가지입니다. Node.js, 이미 깔려 있는 Google Chrome, 그리고 ffmpeg입니다. 브라우저를 조종하는 라이브러리로는 playwright-core를 쓰는데, 설치된 Chrome을 그대로 쓰기 때문에 Chromium을 따로 내려받지 않습니다.

mkdir opus-video && cd opus-video
npm init -y
npm install playwright-core
ffmpeg -version   # 버전이 나오지 않으면 ffmpeg부터 설치

모델에게 줄 장면 규약

렌더링이 성공하느냐는 프롬프트의 멋보다 장면이 지키는 규약에 달려 있습니다. 핵심은 화면이 오로지 시각 t로만 결정되어야 한다는 것입니다. Claude Code에서 Opus 5.5에게 영상 내용을 설명한 뒤 아래 조건을 붙이면 됩니다.

scene.html 파일 하나로 1920x1080 영상을 만들어 줘.
- window.DURATION 에 전체 길이(초)를 숫자로 넣는다.
- window.seek(t) 를 정의한다. 호출되면 t초 시점의 화면을 처음부터 다시 그린다.
- 화면의 모든 요소는 t만으로 계산한다. 이전 프레임의 상태에 기대지 않는다.
- requestAnimationFrame, setTimeout, Date, performance.now 로 진행시키지 않는다.
- CSS transition 과 CSS animation 을 쓰지 않는다.
- 무작위 값이 필요하면 고정 시드를 쓰는 난수 함수를 직접 만든다. Math.random 금지.
- 외부 이미지, 외부 글꼴, video, audio, iframe 을 쓰지 않는다.
- 마지막 줄에서 seek(0) 을 한 번 호출한다.

이 금지 목록은 LaunchVideo README가 장면에 거는 제한과 같은 계열입니다. 그쪽은 video, audio, iframe 태그와 CSS transition, Math.random, 외부 이미지를 막고, 그 이유를 렌더링 결과가 매번 같아야 하기 때문이라고 설명합니다. CSS 애니메이션까지 막은 이유는 아래 스크립트가 브라우저의 시계를 바꿔치기하지 않기 때문입니다. LaunchVideo나 HyperFrames처럼 가상 시계를 주입하는 렌더러에서는 CSS 애니메이션도 쓸 수 있습니다.

규약을 지킨 장면은 가장 단순하게 쓰면 이런 모양입니다.

<!doctype html>
<meta charset="utf-8">
<style>html,body{margin:0;background:#0b1020}canvas{display:block}</style>
<canvas id="c" width="1920" height="1080"></canvas>
<script>
window.DURATION = 3;
const ctx = document.getElementById("c").getContext("2d");
window.seek = async (t) => {
  ctx.fillStyle = "#0b1020"; ctx.fillRect(0, 0, 1920, 1080);
  ctx.fillStyle = "#5be2a1";
  ctx.beginPath(); ctx.arc(200 + 500 * t, 540, 80, 0, Math.PI * 2); ctx.fill();
  ctx.fillStyle = "#fff"; ctx.font = "700 64px Menlo, monospace";
  ctx.fillText(`t = ${t.toFixed(3)} s`, 120, 160);
};
window.seek(0);
</script>

렌더링 스크립트

아래를 render.mjs로 저장합니다. 장면을 열고, 프레임 번호를 초로 바꿔 seek를 부르고, 스크린샷을 ffmpeg의 표준 입력으로 흘려보냅니다. 끝나면 프레임 수, 캡처 시간, 파일 크기, 전체 프레임의 해시를 한 줄로 출력합니다.

// node render.mjs scene.html out.mp4 [fps] [png|jpeg]
import { chromium } from "playwright-core";
import { spawn } from "node:child_process";
import { once } from "node:events";
import { createHash } from "node:crypto";
import { statSync } from "node:fs";
import path from "node:path";
import { pathToFileURL } from "node:url";

const [scene, out, fpsArg = "30", type = "png"] = process.argv.slice(2);
if (!scene || !out) throw new Error("Usage: node render.mjs scene.html out.mp4 [fps] [png|jpeg]");
const fps = Number(fpsArg);
const started = Date.now();
const browser = await chromium.launch({ channel: "chrome", headless: true });
const page = await browser.newPage({ viewport: { width: 1920, height: 1080 }, deviceScaleFactor: 1 });
await page.goto(pathToFileURL(path.resolve(scene)).href);
await page.waitForFunction(() => typeof window.seek === "function");
await page.evaluate(() => document.fonts.ready);
const total = Math.round((await page.evaluate(() => window.DURATION)) * fps);

const ff = spawn("ffmpeg", ["-y", "-loglevel", "error", "-f", "image2pipe", "-framerate", String(fps), "-i", "-",
  "-c:v", "libx264", "-pix_fmt", "yuv420p", "-crf", "18", "-movflags", "+faststart", out],
  { stdio: ["pipe", "inherit", "inherit"] });
const hash = createHash("sha256");
const shotOpts = type === "jpeg" ? { type: "jpeg", quality: 92 } : { type: "png" };
const captureStart = Date.now();
for (let i = 0; i < total; i++) {
  await page.evaluate((t) => window.seek(t), i / fps);
  const buf = await page.screenshot(shotOpts);
  hash.update(buf);
  if (!ff.stdin.write(buf)) await once(ff.stdin, "drain");
}
const captureMs = Date.now() - captureStart;
ff.stdin.end();
const [code] = await once(ff, "close");
await browser.close();
if (code !== 0) throw new Error(`ffmpeg exited with ${code}`);
console.log(JSON.stringify({
  scene, out, fps, frames: total, shot: type,
  capture_seconds: +(captureMs / 1000).toFixed(2),
  total_seconds: +((Date.now() - started) / 1000).toFixed(2),
  ms_per_frame: +(captureMs / total).toFixed(1),
  mp4_bytes: statSync(out).size,
  frames_sha256: hash.digest("hex").slice(0, 16),
}));

실행은 한 줄입니다.

node render.mjs scene.html out.mp4 30 png

결과 확인

MP4가 재생된다는 것만으로는 제대로 됐는지 알 수 없습니다. 세 가지를 확인합니다.

• 프레임 수와 길이: ffprobe out.mp4로 해상도, 프레임 레이트, 길이를 봅니다. 길이가 DURATION과 같아야 합니다.
• 시간이 맞는지: 장면 한구석에 t 값을 찍게 해 두고 ffmpeg -ss 1.5 -i out.mp4 -frames:v 1 check.png로 한 장을 뽑아, 화면에 찍힌 시각이 뽑은 위치와 같은지 봅니다.
• 두 번 돌려 같은지: 같은 명령을 한 번 더 실행해 frames_sha256과 mp4_bytes가 같은지 봅니다. 다르면 장면 어딘가가 t 말고 다른 것에 기대고 있다는 뜻입니다.

12초 장면 실측: 캡처 시간과 파일 크기

위 스크립트를 실제로 돌려 잰 값입니다. 장면은 Claude Code에서 Opus 5.5가 한 번에 쓴 12초짜리 Canvas 2D 애니메이션으로, 제목이 나타났다 사라지고 네 개의 상자가 차례로 올라오며 고정 시드 난수로 배치한 점 140개가 배경에서 움직입니다. 사람이 손댄 곳은 없습니다.

측정 환경은 2026년 10월 1일 기준 Apple M4(10코어), 메모리 16GB, macOS 26.1, Node 24.11.0, playwright-core 1.63.0, Chrome 154(헤드리스, 1920x1080), ffmpeg 8.0.1(libx264, crf 18, yuv420p)입니다.

읽을 만한 점은 세 가지입니다.

첫째, PNG로 두 번 렌더링한 결과는 프레임 해시가 같고 파일 크기도 바이트 단위까지 같았습니다. MP4를 다시 디코딩해 프레임별로 비교해도 동일했습니다. "결정적(deterministic)"이라는 말은 바로 이 성질, 곧 같은 입력을 넣으면 몇 번을 돌려도 같은 프레임이 나온다는 뜻입니다.

둘째, 스크린샷 형식이 속도를 크게 바꿉니다. JPEG로 바꾸면 캡처가 PNG의 절반 이하로 줄어 거의 영상 길이만큼만 걸리고, 대신 MP4가 19% 커졌습니다. LaunchVideo README가 JPEG 프레임을 쓰면서 30초 영상에 30~40초가 걸린다고 적은 것과 같은 방향입니다. 초안을 여러 번 돌려 볼 때는 JPEG, 최종본은 PNG로 나누면 됩니다.

셋째, 9.5초 지점에서 뽑은 프레임에는 "frame 285 / 360, t = 9.500 s"가 찍혀 있었습니다. 9.5초에 30을 곱하면 285이므로, 영상의 시간과 장면의 시간이 프레임 단위로 일치합니다. ffprobe 결과도 h264, 1920x1080, 30fps, 360프레임, 12.000초였습니다.

이 수치는 컴퓨터 한 대에서 오디오 없는 단순한 2D 장면 하나를 돌린 결과입니다. 3D 장면이나 요소가 많은 장면, Remotion이나 HyperFrames의 속도를 대신 말해 주지는 않습니다. 장면을 쓰는 데 든 토큰도 따로 재지 않았습니다.

실제 시계를 읽는 장면은 왜 깨지는가

브라우저에서 보통 쓰는 애니메이션은 requestAnimationFrame으로 돌면서 performance.now()로 경과 시간을 읽습니다. 미리 보기에서는 매끄럽지만 프레임 단위 캡처에서는 문제가 됩니다. 스크린샷 한 장을 찍는 데 걸리는 실제 시간과 영상 속 한 프레임의 길이(30fps에서 33.3ms)가 서로 상관없기 때문입니다.

같은 렌더러로 이런 장면을 일부러 만들어 돌려 봤습니다. 3초짜리 장면이 seek(t)를 무시하고 실제 시계로 진행하며, 점의 위치는 시드 없는 Math.random()으로 정합니다.

눈여겨볼 것은 이 실패가 겉으로 잘 드러나지 않는다는 점입니다. 이 테스트에서는 프레임당 캡처 시간이 33.6~38ms로 우연히 실시간에 가까워서, 결과 영상의 속도가 얼핏 맞아 보였습니다. 그런데도 1.5초 지점의 화면은 이미 0.072초 앞서 있었습니다. 앞의 12초 장면처럼 프레임당 72ms가 걸리는 조건이라면 한 프레임 사이에 장면 시간이 72ms씩 흐르므로, 계산상 영상 속 움직임이 약 2.2배 빨라집니다. 이 배속은 숫자에서 끌어낸 추론이고 따로 녹화해 확인한 값은 아닙니다.

모델이 쓴 장면이 이상하게 빠르거나, 렌더링할 때마다 배경이 달라지거나, 수정하지 않은 구간이 바뀌어 있다면 원인은 대개 여기에 있습니다. 고치는 방법은 둘입니다. 장면을 seek(t) 기준으로 다시 쓰게 하거나, 시계 자체를 가상 시계로 바꿔치기하는 렌더러를 쓰는 것입니다. LaunchVideo는 후자를 택해 rAF, 타이머, Date, CSS와 WAAPI 애니메이션을 모두 주입한 가상 시계로 구동하고, 렌더링 전에 check_scene 단계에서 여러 시점의 자바스크립트 오류와 화면에 보이는 글자를 점검합니다.

렌더링 방식 고르기

직접 짠 스크립트는 구조를 이해하고 짧은 영상을 뽑는 데는 충분하지만, 오디오와 여러 장면의 조합, 미리 보기까지 필요해지면 기존 도구로 옮기는 편이 낫습니다. 아래 표에서 직접 스크립트 외의 항목은 각 프로젝트의 문서에 적힌 내용이며, 위의 측정은 직접 스크립트에만 해당합니다.

판단 기준은 두 가지면 됩니다. 조직 인원이 4명 이상인 영리 회사라면 Remotion은 유료 라이선스 대상이므로 HyperFrames나 직접 스크립트가 먼저입니다. 그리고 모델에게 맡길 장면이 평범한 웹 애니메이션 문법(CSS 키프레임, GSAP 타임라인)에 가깝다면, 그 문법을 프레임 단위로 탐색하게 해 주는 렌더러가 장면 규약을 일일이 강제하는 것보다 실패가 적습니다.

HyperFrames는 Claude Code 플러그인을 제공합니다. README에 따르면 다음 두 명령으로 설치한 뒤 /hyperframes:hyperframes로 부릅니다.

claude plugin marketplace add heygen-com/hyperframes
claude plugin install hyperframes@hyperframes

음악과 내레이션은 별개의 작업입니다. opus-video-prompts 저장소는 공개 사례에서 음악은 Web Audio나 Python 합성으로, 내레이션은 TTS로 붙인다고 정리합니다. 위 스크립트는 영상 트랙만 만들므로 소리는 ffmpeg로 따로 합쳐야 합니다.

영상 한 편의 비용 추정

코드 렌더링에서 돈이 드는 곳은 렌더링이 아니라 모델이 장면을 쓰는 토큰입니다. 렌더링은 내 컴퓨터의 시간만 씁니다. Claude API 정가 기준 Opus 5.5는 100만 토큰당 입력 $4, 출력 $20이므로 식은 이렇습니다.

비용 = 입력 토큰 × $4 / 1,000,000 + 출력 토큰 × $20 / 1,000,000

넣을 숫자가 문제입니다. 영상 한 편에 토큰이 얼마나 드는지에 대한 공식 수치나 독립적으로 측정된 수치는 없고, 공개된 것은 제작자들의 자체 보고 두 건뿐입니다.

두 숫자가 세 배 차이 나는 것만으로도 편차가 크다는 것을 알 수 있습니다. 내 경우의 값을 올리는 요인은 세 가지입니다.

• 수정 횟수: 고쳐 달라고 할 때마다 장면 코드가 입력으로 다시 들어가고 새 코드가 출력으로 나옵니다. 세 번 고치면 첫 편의 계산을 그대로 쓸 수 없습니다.
• effort: Opus 5.5는 사고(thinking)가 항상 켜져 있고 사고 토큰은 출력 단가로 청구됩니다. 기본 effort는 medium인데, opus-video-prompts 저장소는 영상 작업에 high나 xhigh를 권합니다. 그만큼 출력 토큰이 늘어납니다.
• 따로 드는 것: 내레이션용 TTS, 음악, 영상 생성 모델로 뽑는 실사 컷은 이 식 밖의 비용입니다.

가장 믿을 만한 방법은 내 작업을 한 번 돌려 보고 API 응답에 찍힌 입력과 출력 토큰 수를 식에 넣는 것입니다. 반복 입력에는 캐시 읽기 단가(100만 토큰당 $0.20)가, 급하지 않은 작업에는 배치 50% 할인이 적용될 수 있습니다.

Claude 구독(Pro, Max)으로 Claude Code를 쓴다면 사정이 다릅니다. 토큰당 청구서가 나오지 않고 사용량 한도에서 차감되므로, 위 식은 "얼마가 나가는가"가 아니라 "한도를 얼마나 쓰는가"의 어림으로만 쓸 수 있습니다. 단가와 구독 한도의 관계는 Claude Opus 5.5 가격과 사용량 초기화권에서 자세히 다룹니다.

자주 묻는 질문

Opus 5.5에게 MP4 파일을 바로 받을 수 있나요?

모델만으로는 받을 수 없습니다. Opus 5.5의 출력은 텍스트이므로 받는 것은 장면 코드입니다. MP4는 그 코드를 실행할 환경이 있을 때 나옵니다. Claude Code처럼 내 컴퓨터에서 명령을 실행할 수 있는 환경이라면 모델이 장면을 쓰고 렌더링 스크립트까지 돌려 파일을 만들어 놓을 수 있습니다. 이때도 영상을 만든 것은 브라우저와 ffmpeg입니다.

Sonnet 5.5나 이전 Opus 모델로도 같은 방식이 되나요?

방식 자체는 모델을 가리지 않습니다. 현행 Claude 모델은 모두 텍스트를 출력하므로 어느 모델이든 장면 코드를 쓸 수 있고, 렌더러는 누가 쓴 코드인지 구분하지 않습니다. 다만 다른 모델이 쓴 장면의 품질을 Opus 5.5와 견준 공개 자료는 없습니다. 두 5.5 모델의 일반적인 선택 기준은 Sonnet 5.5 vs Opus 5.5 차이를 참고하면 됩니다.

영상 길이는 어느 정도까지 가능한가요?

기술적인 상한은 따로 없고, 길어질수록 장면 코드와 수정 비용이 커집니다. 공개 사례는 짧은 쪽에 몰려 있습니다. LaunchVideo는 20~40초 영상을 목표로 하고, awesome-opus-5-5-videos가 분류한 X 영상의 미리 보기 길이 중앙값은 39.20초입니다. 긴 영상은 장면을 여러 파일로 나눠 각각 렌더링한 뒤 이어 붙이는 편이 수정하기 쉽습니다.

렌더링한 영상이 미리 보기보다 빠르거나 매번 다르게 나옵니다. 왜 그런가요?

장면이 실제 시계나 시드 없는 난수에 기대고 있기 때문입니다. performance.now(), Date, requestAnimationFrame으로 진행하는 장면은 스크린샷에 걸린 실제 시간만큼 앞으로 가 버립니다. 같은 명령을 두 번 실행해 프레임 해시가 다르면 이 문제입니다. 장면을 seek(t) 기준으로 다시 쓰게 하고 Math.random을 고정 시드 난수로 바꾸면 해결됩니다.

실사 영상이 필요하면 어떻게 해야 하나요?

영상 생성 모델을 써야 합니다. 실사 컷만 영상 모델로 뽑고 자막, 그래픽, 컷 편집은 코드로 처리하는 조합이 흔합니다. 비용 구조가 토큰이 아니라 초 단위로 바뀌므로 예산을 먼저 잡는 것이 좋고, 시험 삼아 돌려 볼 경로는 무료 AI 영상 생성 API에 정리되어 있습니다.