클로드 코드로 9:16 모션그래픽 영상 렌더하기 — HyperFrames 레시피, AI 영상 모델 없이

HyperFrames 가 무엇인가?

HyperFrames 는 "Write HTML. Render video. Built for agents." 를 내건 오픈소스 프레임워크다. 라이선스는 Apache 2.0. 컴포지션은 평범한 HTML 파일이다. 타이밍과 트랙은 data-start·data-duration·data-track-index 같은 data-* 속성으로 적고, 클립에는 class="clip" 을 붙이고, 움직임은 GSAP·CSS·Lottie·Three.js·Anime.js·Web Animations API 어댑터로 seek 할 수 있는 런타임이 만든다. 렌더러는 헤드리스 Chrome 에서 프레임마다 seek 하고, 프로젝트 설명 그대로 "FFmpeg 로 인코딩"한다. CLI 는 init·preview·render·add·skills 를 갖고 있다.

Duchamp 레시피는 그 위에 한 층을 얹는다. 에이전트가 TypeScript 로 React 컴포지션을 쓰면 작은 도우미가 esbuild 로 index.html 하나에 묶고, HyperFrames CLI 가 그 파일을 렌더한다. HyperFrames 는 HTML 만 본다. 영상에 필요한 런타임이 브라우저 하나인 이유다.

Duchamp 은 2026년 10월 6일 레시피 렌더러를 HyperFrames 로 바꿨다. 결정적 이유는 라이선스였다. 레시피는 사용자의 컴퓨터에서 돌아가니 렌더러가 요구하는 것이 곧 사용자에게 요구되는 것이고, Apache 2.0 은 실행하는 사람에게 의무를 얹지 않는다. 우리 실측에서는 같은 컴포지션이 이전 렌더러보다 눈에 띄게 빠르고 메모리도 훨씬 적게 썼다.

같은 5.4초 컴포지션, 30fps, 같은 기계	이전 렌더러	HyperFrames
렌더 시간(데운 상태)	41.4초	10.1초
최대 메모리(브라우저·node·ffmpeg 합)	약 5.5GB	약 1.8~2.2GB

Duchamp 영상 레시피는 무엇이 있나?

글 쓰는 시점에 3개다. 전부 9:16·1080×1920·무음 MP4 이고, 예시는 가상 브랜드로 그 레시피를 실제로 실행한 결과다.

레시피	하는 일	길이	컷	프레임률	이럴 때
변경 안내	장부에 고쳐 적듯 바뀌는 것을 하나씩 전→후로. 옛 값에 펜 줄이 그어지고 화살표가 그려지고 새 값이 올라오고 형광 띠가 깔린다	약 12초	3~5개	30fps	영업시간·휴무·가격이 바뀌는 날
오픈 카운트다운	화면을 꽉 채운 일력. 컷 하나가 하루고, 앞 장이 말려 올라가며 찢겨 다음 장이 드러난다. D-3 부터 오픈 당일까지	약 11초	3~5개	30fps	가게·공간·서비스 오픈을 며칠 앞두고
행사 안내	무엇·언제·어디·참여·맺음. 장면마다 글자가 빨리 들어와 완전히 멈춰 읽히고, 가속해 빠지는 순간 다음 장면이 같은 속도로 밀고 올라온다	약 14초	장면 3~4개	60fps	장터·북토크·모임처럼 날짜와 장소가 정해진 행사

MCP id 는 video.change-notice-video·video.open-countdown-video·video.event-info-video 다.

흐름은 어떻게 되나?

1. 레시피를 복사한다. 웹에서는 레시피 페이지의 복사 버튼, MCP 에서는 search_image_templates 에 use: video 를 주고 get_template 으로 받는다.
2. 클로드 코드나 Codex 에 붙여 넣고 맨 위 빈칸을 채운다. 브랜드명, HEX 색 3개(종이·먹·포인트), 주제, 장면별 글자. 빈칸이 [ ] 그대로면 에이전트는 지어 넣지 않고 멈춰서 묻도록 되어 있다.
3. 에이전트는 코드 파일을 그대로 저장하고 props.json 하나만 내 답으로 쓴다. 내가 주지 않은 사실은 null 로 남는다. 날짜·가격·인원을 짐작해 채우는 것은 금지다.
4. npm install 이 HyperFrames·esbuild·React·정적 FFmpeg 를 그 폴더 안에만 받는다. 첫 실행 때 HyperFrames 가 헤드리스 Chrome(약 190MB)을 프로젝트의 .render/home 에 받는다.
5. node render.mjs mp4 가 장면별 정지 화면, 컨택트 시트, 비트맵, MP4 를 만들고 아래 검사를 돈다. 행사 안내 레시피는 30초~1분 정도라고 적혀 있다.
6. 에이전트는 정지 화면을 직접 열어 체크리스트와 대조하고, 경로·움직임 프로파일과 함께 한 줄을 보고한다. 이 영상은 무음이니 음악은 편집 앱에서 붙이라고.

어떤 타이밍 규칙이 슬라이드쇼가 아닌 모션 디자인을 만드나?

행사 안내 레시피는 실제 행사 예고 영상을 프레임 단위로 뜯어 재서 만들었다. 거기서 뽑은 규칙은 멈춤 + 빠른 움직임이다. 글자가 빨리 들어와 읽을 수 있게 완전히 멈추고, 가속하며 빠지는 동안 다음 장면이 같은 속도로 밀고 들어온다. 페이드 없음, 카메라 흐름 없음, 흔들림 없음.

요소	코드의 규칙
들어옴	지수 감속. 30fps 한 프레임마다 남은 거리의 85% 를 좁힘(τ 0.205초), 648~675px 아래에서 시작, 오버슈트 없음
투명도	줄마다 0.2~0.23초 간격의 계단. 묶음은 한 번에 오르고 투명도만 차례로
정지	장면마다 1.3~2초 완전 정지. 0.8초 + 글자당 0.03초로 계산
나감	지수 가속. 프레임마다 ×1.23(τ 0.161초). 라벨은 0.07초 먼저, 1.3배 빠르게
전환	밀기 한 번. 다음 장면이 0.6초 뒤 같은 방향·나감 끝 속도로 들어오고, 약 5프레임 겹침
맺음	포인트색 면이 0.3초에 채우고 띠로 정리되고 세 줄로 갈라져 0.75초 동안 추상 마크로 휜다
움직임 프로파일	레퍼런스 실측 멈춤 53%·느린 흐름 15%·큰 움직임 32%. 코드는 5661 / 1624 / 15~26 에 들어온다

행사 안내 레시피는 60fps 로 렌더하면서 프레임마다 1/240초씩 비켜 그린 서브프레임 4장을 평균한다. 움직이는 글자는 카메라처럼 번지고, 멈추는 순간 칼같이 선명해진다. 30fps 인 두 레시피는 움직임 자체를 그림에 구워 넣는다. 말려 올라가는 종이, 그어지는 펜 줄.

코드는 파일을 넘기기 전에 무엇을 검사하나?

장면마다 정지 화면에서 검사한다. 화면의 글자를 이으면 입력과 한 글자도 다르지 않은지, 위 12%·아래 35%·좌우 64px 안전 영역을 침범하지 않는지, 대비가 나오는지, 큰 글자가 하한 위에 있는지, 글자가 서로나 그래픽과 겹치지 않는지. 그 다음 MP4 를 잰다. 전체 길이의 4065% 가 멈춤, 느린 흐름 30% 이하, 장면당 정지 1.02.2초, 튀는 프레임 0, 규격과 프레임률, 오디오 트랙 없음.

검사가 실패하면 이유 이름과 함께 멈춘다. 글자가 너무 길거나 포인트색이 바탕과 너무 가까운 입력 문제는 질문으로 돌아온다. 코드 문제는 그대로 보고되고, 에이전트는 렌더러를 고치지 말라고 되어 있다.

이 방법이 맞지 않는 경우는?

영상에 실사 푸티지·사람·생성 장면이 필요할 때. 음악을 영상 안에 구워 넣어야 할 때. 10~15초 안내가 아니라 1분짜리 콘텐츠를 원할 때. 이 레시피는 화면의 모든 글자가 내가 준 사실인 세로 안내 영상을 위한 것이고, 그 밖의 것에는 의도적으로 손대지 않는다.