Claude Opus 5.5 를 연출, 애니메이션, 렌더링, 리뷰, 납품까지 모두 수행하는 프로페셔널 모션 제작 팀으로 만드는 방법.
대부분의 사람들은 AI 로 비디오를 만든다는 것이 프롬프트를 작성하고 결과를 기다리는 일이라고 생각합니다.
Opus 5.5 와 함께라면 훨씬 흥미로운 가능성이 열립니다. 바로 하나의 에이전트를 중심으로 전체 제작 스튜디오를 구축하는 것입니다.
스타트업이 제품 출시 영상이 필요할 때 보통 어떤 일이 벌어지는지 생각해 보세요. 누군가 크리에이티브 브리프를 작성합니다. 디자이너가 비주얼 방향성을 잡습니다. 모션 디자이너가 인터페이스에 애니메이션을 입힙니다. 비디오 편집자가 타이밍과 사운드를 담당합니다. 또 다른 누군가가 결과물을 검토하고 수정을 요청한 뒤 최종본을 내보냅니다.
20 초짜리 영상 하나를 위해 이 모든 제작 파이프라인이 돌아가는 것입니다.
이제 그 모든 책임을 하나의 Claude 에이전트에게 맡기되, 각 단계를 처리할 명확한 프로세스를 제공하는 상황을 상상해 보세요.
에이전트는 레퍼런스를 분석하고, 영상을 기획하고, 애니메이션 코드를 작성하고, 프리뷰를 렌더링하고, 자신의 실수를 점검한 뒤 결과물을 수정합니다. 당신은 모든 장면을 직접 만들지 않고도 중요한 크리에이티브 결정만 승인하면 됩니다.
이것이 바로 모션 엔지니어링(Motion Engineering) 이 가진 기회입니다.
Claude Opus 5.5 는 코딩, 시각적 이해력, 그리고 장시간 실행되는 에이전트 작업을 결합하기 때문에 이러한 워크플로우를 흥미롭게 만듭니다. 하지만 가장 중요한 부분은 모델 자체가 아닙니다. 모델을 둘러싸고 구축하는 제작 시스템입니다.
https://x.com/claudeai/status/2102435511222890900
일반적인 AI 비디오 생성과 무엇이 다른지 살펴보겠습니다.
Claude 가 최종 픽셀을 직접 생성할 필요가 없습니다. 대신 그 픽셀을 만들어내는 소프트웨어를 작성할 수 있습니다.
모델은 애니메이션 코드를 작성합니다. 렌더러가 그 코드를 프레임으로 변환합니다. 리뷰 과정에서 결함을 찾아냅니다. 에이전트가 소스 코드를 수정하고 다시 렌더링합니다.
즉, 첫 번째 영상이 다음 영상의 기반이 될 수 있다는 뜻입니다.
이 가이드에서는 5 개의 제작 부서, 재사용 가능한 컴포넌트, 크리에이티브 승인 게이트, 그리고 편집 및 검사가 가능한 영상을 만들어내는 워크플로우를 갖춘 원에이전트(one-agent) 모션 스튜디오를 구축하는 방법을 소개합니다.
목표는 인간의 모든 크리에이티브 판단을 대체하는 것이 아닙니다. 제대로 설정된 에이전트가 이미 처리할 수 있는 일을 사람이 직접 하는 것을 멈추는 것입니다.
저는 Substack에서 AI 에이전트, 자동화, 제작 워크플로우에 대한 실용적인 분석 글을 발행하고 있습니다.
파트 1. 원봇(ONE-BOT) 스튜디오
01. 하나의 에이전트, 다섯 개의 제작 부서
전통적인 스튜디오는 단계마다 요구되는 판단의 종류가 다르기 때문에 전문가들 사이에 업무를 분담합니다.
감독은 스토리를 생각합니다. 아트 디렉터는 구도를 생각합니다. 애니메이터는 움직임을 생각합니다. 테크니컬 아티스트는 렌더링을 생각합니다. 평론가는 결과물이 브리프에 부합하는지 판단합니다.
하나의 Opus 5.5 에이전트가 이 다섯 가지 역할을 순차적으로 모두 수행할 수 있습니다.
하지만 이는 책임 영역이 명확히 분리되어 있을 때만 가능합니다.
구조화되지 않은 단일 단계에서 Claude 에게 연출, 디자인, 애니메이션, 렌더링, 평가를 모두 맡기는 것은 겉보기엔 멋지지만 자세히 들여다보면 무너지는 데모를 얻는 지름길입니다.
대신 에이전트를 다섯 개의 부서로 구성하세요.
1부서 책임 산출물2────────────────────────────────────────────────────────3감독(DIRECTOR) 스토리 및 스토리보드 BRIEF.md4아트 디렉터(ART DIRECTOR) 비주얼 방향성 STYLE.md5애니메이터(ANIMATOR) 모션 및 타이밍 소스 코드6렌더 엔지니어(RENDER ENGINEER) 렌더링 및 내보내기 MP4 + 프리뷰7평론가(CRITIC) 시각적 품질 관리 리뷰 리포트
이들이 반드시 다섯 개의 독립된 에이전트일 필요는 없습니다. 하나의 조율된 워크플로우 안에서 고유한 지침, 파일, 합격 기준을 가진 다섯 개의 단계일 뿐입니다.
감독은 애니메이터가 코드를 건드리기 전에 영상이 무엇을 전달할지 결정합니다. 아트 디렉터는 Claude 가 색상과 트랜지션을 마음대로 발명하기 전에 비주얼 규칙을 정의합니다. 평론가는 애니메이터가 자신이 만든 것에 대해 설명한 내용을 그대로 믿지 않고, 렌더링된 결과물을 평가합니다.
프로세스는 다음과 같습니다.
1 당신의 브리프2 |3 v4 CLAUDE OPUS 5.55 |6 v7 감독8 스토리 + 대본9 |10 v11 아트 디렉터12 레퍼런스 + 디자인13 |14 v15 애니메이터16 코드 + 움직임17 |18 v19 렌더 엔지니어20 프레임 + 내보내기21 |22 v23 평론가24 리뷰 + 수정25 |26 v27 최종 영상
이 순서가 중요한 이유는 대부분의 시각적 실패가 렌더링 이전에 시작되기 때문입니다.
스토리가 불분명하다면 더 나은 모션으로도 살릴 수 없습니다. 비주얼 방향성이 평범하다면 효과를 더할수록 오히려 평범함이 더 뚜렷해집니다. 스토리보드가 잘못되었다면 기술적으로 완벽한 애니메이션조차 아무것도 전달하지 못할 수 있습니다.
첫 번째 과제는 이러한 실수를 방지하는 프로세스를 구축하는 것입니다.
02. 바이럴 원샷 영상이 마법이 아닌 이유
아마 이런 영상들을 본 적이 있을 것입니다.
누군가 전문 크리에이티브 에이전시에서 만든 것 같은 애니메이션을 올리며, Claude 가 프롬프트 하나로 전부 만들었다고 말합니다.
결과물은 실제로 한 번의 긴 자율 실행에서 나왔을 수도 있습니다. 하지만 그 과정이 단 한 문장으로 시작되었다는 뜻은 아닙니다.
Claude Code 팀의 Thariq 은 바이럴 데모 중 하나를 논의하며 이 차이를 강조했습니다.
https://x.com/trq212/status/2102870353781641416
바로 이 세부 사항에 주목해야 합니다.
강력한 프롬프트에는 완전한 크리에이티브 브리프, 레퍼런스 자료, 샷 리스트, 기술적 제약 조건, 에셋 요구 사항, 그리고 최종 결과물을 확인하는 규칙이 모두 담길 수 있습니다.
코딩 에이전트는 기존 프로젝트, 디자인 시스템, 컴포넌트, 렌더 파이프라인을 물려받을 수도 있습니다.
겉보기엔 원샷처럼 보이지만, 실제로는 훨씬 거대한 세팅의 눈에 보이는 끝자락인 경우가 많습니다.
그리고 이는 좋은 소식입니다.
마법 같은 형용사 조합을 발견할 필요가 없다는 뜻이기 때문입니다. 당신에게 필요한 것은 좋은 결정을 재현할 수 있는 제작 환경입니다.
동일한 요청에 대한 두 가지 접근 방식을 비교해 봅시다.
첫 번째는 Claude 에게 "프리미엄한 제품 출시 애니메이션을 만들어 줘"라고 요청합니다. 모델은 제품이 무엇을 하는지, 영상이 어떻게 보여야 하는지, 어떤 트랜지션을 사용할지, 시청자가 언제 헤드라인을 읽어야 하는지, 무엇이 성공적인 결과인지 스스로 결정해야 합니다.
두 번째는 실제 제품 에셋, 레퍼런스 영상, 디자인 규칙, 스토리보드, 타임라인, 리뷰 기준을 제공합니다.
둘 다 하나의 에이전트와 한 번의 주요 제작 실행을 포함할 수 있습니다. 하지만 두 번째 방식은 핵심적인 결정을 운에 맡기는 비율이 적기 때문에 쓸 만한 결과물을 얻을 확률이 훨씬 높습니다.
프롬프트는 영상 하나를 만듭니다. 스튜디오는 영상을 만드는 반복 가능한 방식을 만듭니다.
파트 2. 스튜디오 구축하기
03. 제작 환경 설치하기
이 세팅에서는 에이전트로 Claude Code 를, 비디오 프레임워크로 Remotion 을, 미디어 검사 및 처리용으로 FFmpeg 를 사용합니다.
Claude Code 는 크리에이티브 및 프로그래밍 작업을 처리합니다. Remotion 은 React 컴포넌트와 프레임 기반 애니메이션을 통해 영상을 제어 가능하게 만듭니다. FFmpeg 는 레퍼런스 분석, 출력물 검사, 보조 에셋 준비를 돕습니다.
시작하기 전에 Node.js, Claude Code, FFmpeg 를 설치하세요.
깨끗한 Remotion 프로젝트를 생성합니다.
1npx create-video@latest --yes --blank motion-studio23cd motion-studio45npx remotion skills add67npm run dev
Remotion Skills 인스톨러는 코딩 에이전트가 프레임워크를 다루며 작업할 때 활용할 수 있는 구현 가이드를 제공합니다.
motion-studio 디렉터리 내에서 다른 터미널을 열고 Claude Code 를 실행하세요. 환경에서 지원한다면 Opus 5.5 를 선택합니다.
이제 작업 공간을 정리합니다.
1motion-studio/2│3├── CLAUDE.md4├── BRIEF.md5├── STYLE.md6├── STORYBOARD.md7│8├── public/9│ ├── logos/10│ ├── screenshots/11│ ├── fonts/12│ └── audio/13│14├── src/15│ ├── compositions/16│ ├── components/17│ ├── animation/18│ └── Root.tsx19│20├── reviews/21│ ├── frames/22│ ├── contact-sheets/23│ └── findings.md24│25└── out/26 ├── previews/27 └── final/
이것이 스튜디오의 작업 공간입니다.
CLAUDE.md 에는 모든 제작에 적용되는 규칙이 담깁니다. BRIEF.md 는 현재 진행 중인 영상을 설명합니다. STYLE.md 는 비주얼 방향성을 기록합니다. STORYBOARD.md 는 샷의 순서와 주요 이벤트를 정의합니다.
소스 코드와 승인된 에셋은 리뷰 산출물과 분리됩니다.
이러한 분리는 프로젝트가 몇 시간 동안 실행되거나 다른 세션에서 재개될 때 매우 유용해집니다. Claude 는 작업 공간을 검사하여 무엇이 이미 승인되었는지, 어떤 장면이 존재하는지, 무엇이 리뷰에서 탈락했는지, 아직 무엇이 렌더링되어야 하는지를 파악할 수 있어야 합니다.
이 구조가 없으면 중요한 결정들이 채팅 기록 속에 묻혀버릴 수 있습니다.
스튜디오는 대화 하나가 완벽하게 유지되는 것에 의존하지 않고, 파일로부터 작업을 재개할 수 있어야 합니다.
04. 봇에게 영구적인 운영 매뉴얼 제공하기
대부분의 사람들은 영상을 만들 때마다 Claude 에게 새로운 지침 세트를 제공합니다.
이는 일관성을 해칩니다.
어떤 프로젝트는 타이트한 스프링 애니메이션을 사용하고, 다음 프로젝트는 과도한 바운싱을 도입합니다. 세 번째 프로젝트는 모델에게 영구적인 비주얼 규칙이 없기 때문에 모든 폰트, 색상, 트랜지션을 바꿔버립니다.
대신 스튜디오의 제작 표준을 CLAUDE.md 에 저장하세요.
프롬프트 1. 스튜디오 매뉴얼 만들기
1우리 모션 스튜디오를 위한 CLAUDE.md 를 작성해.23너는 코드로 만들어진 영상을 연출, 디자인, 애니메이션,4렌더링, 리뷰하는 책임을 진 제작 에이전트야.56운영 규칙781. 스토리보드를 만들기 전에는 절대 구현을 시작하지 마.9102. 승인된 제품 에셋만 사용해.11123. UI, 지표, 고객 후기, 제품 기능을 절대 임의로 지어내지 마.13144. 모든 애니메이션은 프레임 번호나 결정론적 시간을 기준으로 구동되어야 해.15165. 영상 전체에 걸쳐 하나의 주된 비주얼 방향성을 사용해.17186. 명확한 커뮤니케이션 목적 없이 요소에 애니메이션을 넣지 마.19207. 전체 영상을 만들기 전에 대표 프레임을 먼저 렌더링해.21228. 소스 코드뿐만 아니라 렌더링된 결과물도 리뷰해.23249. 결함은 가능하면 해당 부분만 국소적으로 수정해.252610. 편집 가능한 모든 소스 파일을 보존해.2728크리에이티브 제약2930피할 것:31- 흔한 그라데이션 배경32- 과도한 바운싱33- 빛나는 파티클34- 읽기 힘든 텍스트35- 가짜 제품 대시보드36- 목적 없는 카메라 무빙3738제작 규칙3940MP4 파일이 존재한다고 해서41영상이 완성된 것이 아니야.4243승인된 브리프와 검증 요건이44충족되었을 때 비로소 완성된 거야.
이 파일은 스튜디오의 기준선이 됩니다.
모든 영상이 똑같이 보여야 한다는 뜻이 아닙니다. 반복되는 제작 실수를 매번 처음부터 다시 발견할 필요가 없다는 뜻입니다.
Claude 가 동일한 시각적 실수를 반복한다면 운영 매뉴얼을 개선하세요. 다음 영상은 그 수정 사항을 물려받게 됩니다.
공유 애니메이션 컴포넌트, 타이포그래피 토큰, 세이프 에어리어 치수, 선호하는 내보내기 설정 등 재사용 가능한 제작 결정들도 프로젝트 내부에 저장할 수 있습니다.
스튜디오가 완료된 작업으로부터 배울수록, 다음 과제에서 기본기를 다시 익히는 데 드는 시간은 줄어듭니다.
05. 감독이 브리프를 작성하게 하기
구체적인 것을 만들어 봅시다.
정리 안 된 프로젝트 보드를 체계적인 스프린트 계획으로 바꿔주는 SaaS 제품을 출시한다고 가정해 보겠습니다.
단 하나의 변화, 즉 어수선한 태스크 보드가 명확한 우선순위 목록으로 바뀌는 모습을 보여주는 20 초짜리 제품 영상이 필요합니다.
시청자는 나레이션 없이도 가치를 이해할 수 있어야 합니다.
Claude 에게 멋진 영상을 만들어 달라고 요청하는 대신, 감독에게 제작 과제를 부여하세요.
프롬프트 2. 감독 과제
1너는 우리 모션 스튜디오의 감독이야.23프로젝트45생산성 앱 출시 영상.67핵심 메시지89어수선한 프로젝트 보드를10명확한 스프린트 계획으로 바꾼다.1112타깃 시청자1314창업자, 제품 팀, 개발자.1516길이171820 초.1920포맷212216:9 마스터239:16 소셜 버전241:1 정사각형 버전2526에셋2728public/ 폴더에 제공된 스크린샷, 로고, 폰트를 사용해.2930가상의 제품 화면을 만들지 마.3132네 역할33341. 사용 가능한 모든 에셋을 검사해.352. 누락된 정보를 파악해.363. BRIEF.md 를 작성해.374. 중심 비주얼 아이디어를 정의해.385. 영상의 스토리 구조를 만들어.396. 각 장면이 왜 존재하는지 설명해.4041아직 애니메이션 코드는 작성하지 마.4243크리에이티브 방향성을 제시하고44승인을 기다려.
감독은 단순히 움직임을 채워 넣기 위해서가 아니라, 각 단계에서 시청자가 무엇을 이해해야 하는지를 결정해야 합니다.
첫 번째 장면은 어수선한 태스크 보드를 보여줄 수 있습니다. 다음 장면은 이를 정리하는 행동을 소개합니다. 마지막 장면은 완성된 스프린트 계획을 유지합니다.
중요한 시각적 관계는 '변화 전'과 '변화 후'입니다.
다른 모든 요소는 이를 뒷받침해야 합니다.
브리프를 승인하기 전에, 실제로 제품에 당신이 묘사하려는 기능이 있는지, 제공된 스크린샷이 그것을 잘 보여주는지, 제안된 스토리가 과도한 설명 텍스트 없이도 이해될 수 있는지 확인하세요.
필수적인 제품 화면이 누락되었다면, 그럴듯한 가짜를 그려내는 대신 에이전트가 해당 자료를 요청해야 합니다.
이 단 하나의 규칙만으로 쓸모없는 AI 생성 제품 영상의 상당수를 막을 수 있습니다.
06. 레퍼런스를 비주얼 아이덴티티로 전환하기
AI 가 만든 영상들이 비슷해 보이는 주된 이유는 모델이 모호한 언어로부터 비주얼 방향성 전체를 스스로 지어내기 때문입니다.
"프리미엄하고, 미니멀하며, 시네마틱하고, 미래지향적인"이라는 표현은 모델에게 별다른 정보를 주지 못합니다.
더 나은 방법은 두세 개의 레퍼런스를 제공하고 각각에 구체적인 역할을 부여하는 것입니다.
하나의 레퍼런스는 타이포그래피를 정의할 수 있습니다. 다른 하나는 트랜지션을 보여줄 수 있습니다. 세 번째는 페이스나 구도를 제시할 수 있습니다.
아트 디렉터에게 원본 창작물을 복사하지 않으면서 유용한 디자인 원칙을 추출하도록 요청하세요.
프롬프트 3. 아트 디렉션
1아트 디렉터 역할을 해줘.23references 폴더에 있는 레퍼런스 이미지와 영상을 검사해.45다음 항목을 추출해:67타이포그래피89폰트의 성격10굵기 위계11헤드라인 크기1213구도1415여백16간격17시각적 위계18초점1920색상2122배경23주요 텍스트24포인트 컬러25대비 규칙2627모션2829등장 타이밍30안착 동작31카메라 무빙32텍스트 정지 시간3334질감3536노이즈(그레인)37그림자38테두리39표면 처리4041승인된 디자인 결정은 STYLE.md 에 저장해.4243정확한 구도, 아트워크, 브랜딩을 복사하지 마.4445우리 제품만의 독특한 비주얼 방향성을 만들어.4647구현하기 전에 스타일 제안을 먼저 보여줘.
이 지점에서 Claude 는 "프리미엄"이 무엇을 의미하는지 추측하는 것을 멈춥니다.
애니메이터가 작업을 시작할 때, 카드가 빛나야 하는지, 헤드라인이 튀어 올라야 하는지, 모든 장면에 또 다른 그라데이션이 필요한지 고민할 필요가 없습니다.
그런 결정들은 이미 내려졌기 때문입니다.
탄탄한 스타일 가이드는 영상이 어떻게 보여야 하는지만 설명하지 않습니다. 영상이 무엇을 피해야 하는지도 정의합니다.
레퍼런스가 절제된 타이포그래피와 느린 카메라 무빙을 사용했다면, AI 생성 데모에서 흔히 볼 수 있다는 이유만으로 회전하는 인터페이스와 파티클 폭발을 도입해서는 안 됩니다.
에이전트가 원본 대상을 베끼는 것이 아니라 디자인 언어를 이해하기를 원해야 합니다.
중요한 트랜지션의 경우, Claude 에게 FFmpeg 로 레퍼런스에서 프레임을 추출하고, 타이밍을 분석한 뒤, 그 결과를 STYLE.md 에 기록하도록 요청하세요.
이는 모델에게 "Apple 처럼 만들어 줘"라고 말하는 것보다 훨씬 유용한 결과물을 낳습니다.
파트 3. 애니메이터와 렌더 엔진
07. 스토리를 편집 가능한 타임라인으로 바꾸기
브리프와 스타일이 승인되면 애니메이터에게는 샷 리스트가 필요합니다.
우리의 20 초짜리 영상을 위해 다섯 개의 장면을 정의해 봅시다.
1장면 01: 문제200:00 - 00:0334어수선한 태스크 보드가 등장한다.5구도가 과부하 상태를 전달한다.67장면 02: 행동800:03 - 00:07910커서가 정리 기능을 선택한다.11인터페이스가 시각적으로 반응한다.1213장면 03: 변화1400:07 - 00:111516태스크들이 명확한 우선순위로 재배치된다.17하나의 연속적인 시각적 관계.1819장면 04: 결과2000:11 - 00:162122정돈된 스프린트 계획이 자리 잡는다.23이해할 수 있을 만큼 충분히 오래 유지한다.2425장면 05: 마무리2600:16 - 00:202728제품명, 로고, 콜 투 액션.29강렬한 마지막 프레임.
이제 모델은 알려진 상태 사이에서 모션을 설계할 수 있습니다.
애니메이션 코드를 작성하면서 동시에 영상의 주제를 발명할 필요가 없습니다.
유용한 원칙은 한 장면의 최종 상태가 다음 장면의 시작 방식을 애니메이터에게 알려주어야 한다는 것입니다.
태스크 보드가 80% 스케일로 중앙에 위치한 채 끝난다면, 다음 샷은 그 위치를 유지하거나 의도적으로 벗어나는 트랜지션을 취해야 합니다.
연관 없는 구도 사이를 무작위로 점프하면 영상이 AI 가 생성한 슬라이드 모음처럼 느껴집니다.
연속성은 영상이 연출된 것처럼 느끼게 만듭니다.
더 정교한 제어를 위해 타임스탬프를 프레임 번호로 변환하세요.
초당 30 프레임이라면 20 초 영상은 0 부터 599 까지 총 600 개의 프레임으로 구성됩니다.
이를 통해 에이전트는 주요 이벤트의 정확한 위치를 알 수 있습니다.
커서는 180 프레임에서 버튼에 도달할 수 있습니다. 클릭은 195 프레임에서 인식될 수 있습니다. 결과는 210 프레임에서 나타날 수 있습니다.
무언가가 너무 빨리 발생하면 해당 이벤트 프레임을 변경하면 됩니다.
트랜지션이 너무 빠르면 길이를 조정하면 됩니다.
타이밍이 나아지기만을 바라면서 완전히 다른 영상을 다시 생성할 필요가 없습니다.
08. 모델은 최종 영상이 아닌 애니메이션 코드를 작성한다
이것이 스튜디오를 가능하게 하는 기술적 차이점입니다.
Remotion 을 사용하면 Claude 는 현재 프레임에 따라 외형이 달라지는 React 컴포넌트를 작성할 수 있습니다.
렌더러는 시간이 흐름에 따라 이 컴포넌트들을 평가하여 실제 영상을 만들어냅니다.
간단한 등장 애니메이션은 다음과 같을 수 있습니다.
1import {2 useCurrentFrame,3 useVideoConfig,4 spring,5 interpolate,6} from "remotion";78export const ProductCard = () => {9 const frame = useCurrentFrame();10 const { fps } = useVideoConfig();1112 const progress = spring({13 frame,14 fps,15 config: {16 damping: 200,17 },18 });1920 const y = interpolate(21 progress,22 [0, 1],23 [60, 0]24 );2526 const scale = interpolate(27 progress,28 [0, 1],29 [0.94, 1]30 );3132 return (33 <div34 style={{35 transform:36 `translateY(${y}px) scale(${scale})`,37 }}38 >39 Product Interface40 </div>41 );42};
이 컴포넌트에는 일회성으로 생성된 영상이 기본적으로 제공하지 못하는 것이 있습니다. 바로 제어 가능한 파라미터입니다.
완전히 새로운 클립을 요청하지 않고도 이동 거리, 등장 타이밍, 이징 동작, 스케일을 변경할 수 있습니다.
카드가 너무 멀리 이동한다면 거리를 줄이면 됩니다.
너무 천천히 자리 잡는다면 스프링 값을 조정하세요.
헤드라인이 너무 일찍 나타난다면 타임라인에서 등장 시점을 뒤로 옮기세요.
소스 코드는 계속 편집 가능합니다.
이것이 제품 영상, UI 애니메이션, 설명 영상, 타이포그래피 중심 콘텐츠에서 코드로 만든 모션이 갖는 장점입니다.
실사 같은 장면, 복잡한 캐릭터, 유기적인 시네마틱 모션에는 자동으로 더 나은 선택이 되지 않습니다. 그런 경우에는 여전히 촬영 소스, 3D 도구, 생성형 비디오가 필요할 수 있습니다.
핵심은 당신이 실제로 만들고 있는 작업에 대한 통제권을 주는 제작 방식을 선택하는 것입니다.
그리고 제품 영상의 경우, 통제권은 예측 불가능성보다 훨씬 가치 있는 경우가 많습니다.
09. 렌더 엔지니어에게 정확한 요구 사항 제공하기
렌더링은 디자인과 별개의 책임입니다.
애니메이터가 영상을 구축합니다. 렌더 엔지니어는 해당 구도가 요구되는 해상도와 프레임 속도로 실제로 내보낼 수 있는지 확인합니다.
첫 번째 시도에서 600 프레임 전체를 최종 품질로 렌더링하지 마세요.
먼저 대표적인 정지 이미지를 렌더링하세요.
프롬프트 4. 렌더링 과제
1렌더 엔지니어 역할을 해줘.23BRIEF.md, STYLE.md,4STORYBOARD.md 를 읽어.56기존 컴포지션을 검사해.78최종 렌더링 전에:9101. 컴포지션 해상도를 확인해.112. 프레임 속도와 길이를 확인해.123. 모든 폰트가 로드되는지 확인해.134. 모든 제품 에셋이 존재하는지 확인해.145. 대표적인 정지 프레임을 렌더링해.156. 가벼운 모션 프리뷰를 렌더링해.167. 런타임 오류를 보고해.1718크리에이티브 방향성을 수정하지 마.1920프리뷰가 리뷰를 통과하기 전까지는21최종 결과물을 렌더링하지 마.
Remotion 을 사용하면 선택한 프레임을 직접 렌더링할 수 있습니다.
1mkdir -p out/previews23npx remotion still Launch \4 out/previews/opening.png --frame=3056npx remotion still Launch \7 out/previews/action.png --frame=15089npx remotion still Launch \10 out/previews/result.png --frame=3901112npx remotion still Launch \13 out/previews/closing.png --frame=570
여기서 Launch 는 예제 프로젝트의 컴포지션 ID 입니다. 본인의 Remotion 프로젝트에 설정된 ID 로 교체하세요.
이 네 장의 정지 이미지는 모션을 확인하기 전에도 주요 스토리를 전달해야 합니다.
오프닝이 평범해 보이거나, 제품을 읽을 수 없거나, 클로징의 위계가 엉망이라면 영상 전체를 내보낸 후에 고치는 것보다 지금 해결하는 것이 낫습니다.
집중적인 모션 프리뷰를 위해 상호작용 구간만 렌더링하세요.
1npx remotion render Launch \2 out/previews/interaction.mp4 \3 --frames=90-330 \4 --codec=h264
이제 에이전트는 검사할 수 있는 실제 영상 결과물을 갖게 됩니다.
단순히 자신이 만들려고 했던 것에 대한 설명이 아닙니다.
이 차이는 중요합니다. 소스 코드는 완벽해 보여도 결과물은 형편없을 수 있기 때문입니다.
애니메이션을 평가하는 유일하게 신뢰할 수 있는 방법은 렌더러가 실제로 만들어낸 것을 검사하는 것입니다.
파트 4. 평론가가 있어야 스튜디오가 된다
10. 애니메이터가 자기 작업을 승인하게 두지 마라
이 부서는 대부분의 사람들이 잊어버리는 곳입니다.
모델이 코드를 작성하고, 영상이 성공적으로 렌더링되며, 에이전트가 모든 것이 완료되었다고 선언합니다.
하지만 렌더링이 성공했다는 것은 파일이 존재한다는 것만 증명할 뿐입니다.
영상이 훌륭하다는 것을 증명하지는 못합니다.
커서가 헤드라인을 가리고 있을지도 모릅니다. 카드가 너무 늦게 자리 잡고 있을지도 모릅니다. 모바일에서 제품을 도저히 읽을 수 없을지도 모릅니다. 트랜지션이 기술적으로는 작동해도 싸구려처럼 보일지도 모릅니다.
전문 스튜디오는 소프트웨어가 MP4 를 내보냈다는 이유만으로 결과물을 배포하지 않습니다.
결과물을 리뷰합니다.
Claude 에게 별도의 비평 단계를 부여하세요. 이상적으로는 원래의 브리프와 렌더링된 프레임을 담은 새로운 컨텍스트에서 진행하는 것이 좋습니다.
그러면 리뷰 과정이 제작 중에 내린 결정을 그저 변호하는 상황으로 흐를 가능성을 줄일 수 있습니다.
프롬프트 5. 독립적인 모션 비평
1너는 평론가야.23너는 이 영상을 디자인하거나 애니메이션하지 않았어.45제공된 콘택트 시트, 정지 프레임,6영상 프리뷰를 리뷰해.781 에서 10 사이의 점수를 매겨:910- 시각적 구도11- 타이포그래피12- 제품 가독성13- 모션 품질14- 타이밍15- 연속성16- 브랜드 일관성1718가장 중요한 문제 세 가지를 찾아내.1920각 문제에 대해 다음을 제공해:2122프레임 또는 타임스탬프23어디서 발생하는가.2425관찰 내용26눈에 보이는 문제가 무엇인가.2728중요한 이유29그것이 영상을 어떻게 망치는가.3031가장 작은 유효 수정32무엇을 바꿔야 하는가.3334유지할 것35무엇을 그대로 둬야 하는가.3637애니메이터의 설명에만 근거해38승인하지 마.3940리포트는 reviews/findings.md 로 저장해.
이제 리뷰는 애니메이터가 즉시 조치할 수 있는 결과물을 만들어냅니다.
"영상을 좀 더 프로페셔널하게 만들어 줘" 대신, 평론가는 다음과 같이 보고할 수 있습니다.
1결함 0123프레임:421056문제점:7커서가 결과 라벨을 가로지릅니다.89원인:10커서가 빠져나가는 시점이 결과가 나타나는 시점과 겹칩니다.1112수정:13라벨이 보이기 전에 커서를 다른 곳으로 이동시키세요.1415유지할 항목:16클릭 타이밍17카드 크기18결과 애니메이션1920재확인:21195, 210, 225, 240 프레임
결과 애니메이션
재확인:
195, 210, 225, 240 프레임
이렇게 하면 주관적인 피드백이 엔지니어링 작업으로 바뀝니다.
크리틱(Critic)이 문제를 찾아내고, 애니메이터(Animator)가 수정하며, 렌더 엔지니어(Render Engineer)가 해당 프레임을 다시 내보냅니다.
영상 전체를 다시 생성할 필요가 없습니다.
본격적인 프로덕션 작업이라면 크리틱은 정지 프레임과 움직이는 프리뷰를 모두 점검해야 합니다.
정지 화면은 레이아웃 결함을 드러내고, 영상은 어색한 속도감, 부자연스러운 전환, 움직임의 위화감, 타이밍 문제를 보여줍니다.
어느 하나가 다른 하나를 완전히 대체할 수는 없습니다.
11. 언제 멈춰야 할지 아는 수정 루프를 구축하라
가장 유용한 프로덕션 루프는 단순합니다.
1 애니메이션2 |3 v4 프리뷰 렌더링5 |6 v7 크리틱 리뷰8 |9 +--------+--------+10 | |11 통과 실패12 | |13 v v14 납품 구체적인 문제점 발견15 |16 v17 부분 수정18 |19 v20 다시 렌더링21 |22 +----> 리뷰
여기서 중요한 단어는 '부분'입니다.
210 프레임에서 발생한 결함이 근본적인 크리에이티브 콘셉트를 망치지 않는 한, 스토리보드 전체를 다시 작성하게 만들어서는 안 됩니다.
헤드라인이 잘못 줄바꿈된다면 너비나 글꼴 크기를 조정하세요.
커서가 결과와 겹친다면 커서의 경로를 바꾸세요.
씬이 너무 갑작스럽게 끝난다면 타이밍이나 전환을 수정하세요.
에이전트는 승인된 작업은 그대로 유지하면서 실패한 부분만 고쳐야 합니다.
루프에는 제한을 두어야 합니다.
프롬프트 6. 수정 정책
1리뷰에 실패한 경우를 위한 수정 프로세스를 만드세요.23모든 결함에 대해 다음을 수행합니다:451. 크리틱의 증거를 읽습니다.62. 가장 작은 범위의 관련 변경 사항을 파악합니다.73. 승인된 결정 사항은 유지합니다.84. 영향을 받은 소스를 패치합니다.95. 영향을 받은 프레임을 렌더링합니다.106. 인접한 씬의 경계를 점검합니다.117. 새로운 증거를 반환합니다.1213최대 제한:14결함당 최대 두 번의 수정 라운드.1516두 번의 라운드 후에도 같은 문제가17해결되지 않는다면:1819중단하세요.20장애 요인을 설명하세요.21사람의 지시를 요청하세요.2223리뷰를 통과시키기 위해서24검증 요구사항을 절대 제거하지 마세요.
장애 요인을 설명하세요.
사람의 지시를 요청하세요.
검증 요구사항을 절대 제거하지 마세요
리뷰를 통과시키기 위해서 말입니다.
이렇게 하면 에이전트가 끝없는 수정의 굴레로 사라지지 않고 스스로 결과물을 개선할 수 있습니다.
스튜디오에는 반복(iterate)할 능력이 필요합니다.
동시에 예산과 중단 규칙도 필요합니다.
유용한 자율성과 통제 불능의 실험을 가르는 차이는, 시스템이 성공의 모습과 필요한 증거, 그리고 언제 도움을 요청해야 하는지를 아느냐에 달려 있습니다.
파트 5. 하나의 영상에서 진짜 스튜디오로
12. 렌더링 하나가 납품물 하나는 아니다
스타트업이 단 하나의 영상 파일만 필요로 하는 경우는 드뭅니다.
같은 제품 출시 영상이라도 웹사이트용 와이드 버전, X용 정사각형 버전, 릴스나 쇼츠용 세로 버전이 필요할 수 있습니다.
원본을 단순히 잘라내면 구도가 망가질 수 있습니다.
가로 장면에서는 제품과 헤드라인이 나란히 보일 수 있습니다.
세로 장면에서는 헤드라인을 먼저 보여주고 인터페이스가 화면을 채우도록 해야 할 수도 있습니다.
내러티브는 같지만 구도는 달라집니다.
1 하나의 영상2 |3 +-------------+-------------+4 | | |5 v v v6 16:9 1:1 9:167 | | |8 v v v9 웹사이트 X / 소셜 릴스10 유튜브 정사각형 게시물 쇼츠1112 더 넓은 균형 잡힌 세로형13 맥락 구도 계층 구조
에이전트에게 동일한 소스 에셋과 승인된 스토리를 바탕으로, 반응형 구도를 따로 만들거나 형식에 맞는 씬 레이아웃을 구성하도록 요청하세요.
가로 렌더링이 성공했다고 해서 세로 버전도 괜찮을 거라 짐작하지 마세요.
각 형식마다 고유한 정지 프레임과 리뷰가 필요합니다.
완성도 높은 납품 패키지에는 MP4 파일 세 개 이상이 포함되어야 합니다. 최종 영상, 포스터 프레임, 편집 가능한 소스, 승인된 에셋, 그리고 남아있는 제한 사항에 대한 간단한 메모가 들어가야 합니다.
그래야 클라이언트에게 달랑 내보내기 파일 하나만 남기고 실질적인 수정 방법조차 없는 상황을 피하고, 실제 출시에 활용할 수 있는 결과물이 됩니다.
13. 스튜디오는 유지하고 프로젝트만 교체하라
바로 이 지점에서 하나의 봇(Bot)이 진짜 프로덕션 시스템으로 변하기 시작합니다.
대부분의 사람들은 영상을 완성하면 채팅을 닫고, 다음번에 다시 처음부터 시작합니다.
스튜디오는 중요한 부분을 계속 간직합니다.
스타일링 규칙, 재사용 가능한 컴포넌트, 애니메이션 기법, 리뷰 체크리스트, 렌더링 명령어, 출력 구조는 살아남아야 합니다.
프로젝트별로 바뀌어야 하는 것은 입력값뿐입니다.
1첫 번째 영상23브리프 A4 |5 v6스튜디오 파이프라인7 |8 v9영상 A1011두 번째 영상1213브리프 B14 |15 v16동일한 스튜디오 파이프라인17 |18 v19영상 B2021세 번째 영상2223브리프 C24 |25 v26개선된 스튜디오 파이프라인27 |28 v29영상 C
크리틱이 "시청자가 다 읽기도 전에 헤드라인이 사라진다"는 같은 문제를 반복해서 지적한다고 상상해 보세요.
매번 영상을 수동으로 고칠 수도 있습니다.
아니면 스튜디오 규칙을 업데이트하여 명시적인 읽기 대기 시간을 요구하고, 리뷰 단계에서 이를 테스트할 수도 있습니다.
이제 모든 새 영상은 그 수정 사항을 물려받게 됩니다.
세로 내보내기에서 알아보기 힘들어지는 제품 스크린샷, 필수 정보를 가려버리는 전환, 인터페이스 라벨과 충돌하는 커서 애니메이션에도 똑같이 적용됩니다.
반복되는 모든 실수는 규칙, 재사용 가능한 컴포넌트, 혹은 새로운 리뷰 점검 항목이 될 수 있습니다.
최종 결과물만 보존하는 대신 프로덕션 과정 자체를 보존했을 때 얻는 이점이 바로 이것입니다.
다음 영상에도 여전히 크리에이티브 디렉팅은 필요합니다. 하지만 스튜디오 전체를 밑바닥부터 다시 구축할 필요는 없어야 합니다.
14. 프로세스를 재사용 가능한 스킬(Skill)로 만들어라
첫 프로젝트가 리뷰를 통과했다면, 스튜디오의 작업 절차를 Claude Code 스킬로 저장하세요.
스킬에는 특정 출시 제품의 이름, 스크린샷, 카피가 담겨서는 안 됩니다.
제작 방법을 설명해야 합니다.
프롬프트 7. 스튜디오 스킬 만들기
1motion-studio라는 이름의 재사용 가능한 스킬을 만드세요.23목적45승인된 크리에이티브 브리프를6전문적인 코드 렌더링 영상으로 변환합니다.78워크플로우910디렉터(DIRECTOR)11요청 사항을 분석합니다.12브리프와 스토리보드를 작성합니다.1314아트 디렉터(ART DIRECTOR)15레퍼런스를 점검합니다.16일관된 비주얼 방향성을 정의합니다.1718애니메이터(ANIMATOR)19편집 가능하고 프레임 기반의 모션을 구축합니다.2021렌더 엔지니어(RENDER ENGINEER)22정지 이미지와 프리뷰를 렌더링합니다.23기술적 결과물을 검증합니다.2425크리틱(CRITIC)26실제 렌더링 결과물을 점검합니다.27증거에 기반한 수정 사항을 반환합니다.2829납품(DELIVERY)30승인된 형식으로 내보냅니다.31소스와 제작 노트를 제공합니다.3233규칙3435- 제품 에셋을 임의로 만들지 마세요.36- 크리에이티브 승인 단계를 건너뛰지 마세요.37- 점검하지 않은 결과물을 승인하지 마세요.38- 수정은 부분적으로 유지하세요.39- 반복적인 수정 시도 횟수를 제한하세요.40- 모든 중요한 산출물을 저장하세요.4142결과물4344최종 영상45포스터 프레임46콘택트 시트47편집 가능한 소스48리뷰 보고서
이제 다음 작업의 규모는 훨씬 작아집니다.
당신은 제품, 타겟 고객, 비주얼 레퍼런스, 원하는 결과를 제공하기만 하면 됩니다.
절차는 스킬이 알아서 제공합니다.
에이전트가 채팅 기록을 뒤져가며 프로덕션 워크플로우 전체를 재구성할 필요가 없어집니다.
이 과정에서 경제성 또한 달라지기 시작합니다.
첫 번째 영상은 상당한 준비와 시행착오가 필요할 수 있습니다.
두 번째 영상은 씬 구조, 모션 컴포넌트, 렌더링 명령어, 시각적 QA 프로세스를 재사용할 수 있습니다.
세 번째 영상은 앞선 두 번의 과정에서 발견된 수정 사항의 혜택을 누릴 수 있습니다.
당신은 단순히 결과 파일을 쌓아가는 것이 아닙니다.
제작 역량을 축적하고 있는 것입니다.
파트 6. 당신의 첫 원봇(One-Bot) 스튜디오 프로젝트
15. 마스터 프롬프트
작업 공간, 규칙, 제작 단계가 갖춰지면 Opus에게 훨씬 더 큰 작업을 맡길 수 있습니다.
단발성 프롬프트와의 결정적인 차이는, 에이전트가 따라야 할 명확한 프로세스와 사람의 승인이 필요한 지점이 정해져 있다는 점입니다.
제가 사용할 마스터 프롬프트는 다음과 같습니다.
마스터 프롬프트. 모션 스튜디오 운영
1너는 내 모션 디자인 스튜디오를 운영하고 있다.23목표는 전문적인 수준의420초짜리 제품 출시 영상을 제작하는 것이다.56프로젝트78제품: [이름]9웹사이트: [URL]10타겟 고객: [고객층]11핵심 메시지: [한 문장]1213승인된 스크린샷, 로고,14글꼴, 레퍼런스를 사용하라.15161단계: 디렉터1718에셋을 점검하라.19BRIEF.md를 작성하라.20스토리보드를 만들어라.21핵심 비주얼 스토리를 정의하라.2223승인을 요청하라.24252단계: 아트 디렉터2627레퍼런스를 분석하라.28STYLE.md를 작성하라.29타이포그래피, 색상,30구도, 모션을 정의하라.3132승인을 요청하라.33343단계: 애니메이터3536Remotion을 사용해 영상을 구축하라.37결정론적이고 프레임 기반의 애니메이션을 사용하라.38승인된 제품 세부 사항과39씬의 연속성을 유지하라.40414단계: 렌더 엔지니어4243대표적인 정지 이미지를 렌더링하라.44러프컷 프리뷰를 렌더링하라.4546점검 항목:47- 해상도48- 프레임률49- 글꼴50- 에셋51- 런타임 오류52535단계: 크리틱5455실제 렌더링된 프레임을 리뷰하라.5657정확한 프레임 번호와 함께58가장 심각한 결함 세 가지를 찾아내라.5960부분적인 수정 방안을 제안하라.61626단계: 수정6364영향이 가장 큰 결함을 수정하라.65승인된 작업은 유지하라.66영향을 받은 프레임을 다시 렌더링하라.6768수정 라운드가 두 번 실패하면 중단하라.69707단계: 납품7172내보내기 형식:73- 16:974- 1:175- 9:167677포함 항목:78- MP4 파일79- 포스터 프레임80- 편집 가능한 소스81- 콘택트 시트82- QA 보고서8384중요 사항8586제품 화면이나 주장을 절대 임의로 만들지 마라.87리뷰 단계를 절대 건너뛰지 마라.8889내보내기가 성공했다고 해서90크리에이티브 품질이 증명되는 것은 아니다.9192중요한 크리에이티브 결정이나93게시 전에는 반드시 승인을 위해 멈춰라.
여전히 좋은 입력값을 제공하는 것은 당신의 몫입니다.
봇에게는 실제 제품 자료, 명확한 목표, 비주얼 방향성을 이해할 수 있을 만큼 충분한 레퍼런스가 필요합니다.
하지만 이제 당신은 단편적인 애니메이션 하나를 요청하는 것이 아니라, 프로덕션 워크플로우 전체를 위임하고 있습니다.
그리고 이것이 Opus 5.5 를 활용하는 훨씬 더 흥미로운 방식입니다.
봇 하나가 정말 모션 스튜디오를 대체할 수 있을까?
특정 유형의 제작물에 한정하면, 소규모 스튜디오가 수작업으로 처리했을 놀라운 분량의 작업을 대신 떠맡을 수 있습니다.
제품 출시 애니메이션, 인터페이스 데모, 타이포그래피 영상, 데이터 시각화, 짧은 설명 영상은 제어 가능한 코드로 표현될 수 있기 때문에 특히 적합합니다.
하지만 워크플로우를 대체하는 것과 모든 크리에이티브 판단을 대체하는 것은 다릅니다.
모델은 여러 가지 방향성을 제시할 수 있지만, 어떤 것이 브랜드를 올바르게 표현하는지 결정하는 것은 여전히 사람의 몫입니다.
프레임을 점검해 문제를 찾을 수는 있지만, 주관적인 품질은 테스트만으로 완전히 환원될 수 없습니다.
음악과 효과를 입힐 수는 있지만, 사용 권한, 고객의 기대치, 최종 게시 결정은 여전히 중요합니다.
진정한 가치는 업무의 균형을 바꿔놓는 데 있습니다.
에디터에서 요소를 옮기는 데 대부분의 시간을 쓰는 대신, 크리에이티브 방향성을 설정하고 결과물을 검토하며 프로덕션 프로세스를 개선하는 데 더 많은 시간을 쓰게 됩니다.
이는 기능을 출시할 때마다 제작 팀을 새로 꾸릴 여력 없이 강력한 제품 영상이 필요한 1인 창업자, 개발자, 인디 크리에이터, 소규모 팀에게 특히 매력적입니다.
이 접근법이 중요한 이유는 또 있습니다.
전통적인 AI 생성 영상은 정밀하게 수정하기 어려운 경우가 많습니다.
특정 장면은 마음에 드는데 전환 하나가 마음에 들지 않을 수 있습니다. 나머지 애니메이션은 건드리지 않고 스크린샷 하나만 교체해야 할 수도 있습니다. 정확히 같은 영상을 세 가지 형식으로 만들어야 할 수도 있습니다.
코드 기반 렌더링 제작물이라면, 이러한 변경 사항을 소스에 대한 제어된 편집으로 표현할 수 있는 경우가 많습니다.
헤드라인이 달라졌다고 해서 영상 전체를 새로 만들 필요는 없습니다.
브랜드 색상이 바뀌었다고 타임라인 전체를 재구성할 필요는 없습니다.
타이밍 수정은 문제가 발생하는 해당 프레임에서만 이루어질 수 있습니다.
이는 단순한 편의성이 아닙니다.
단순한 에셋 생성과 프로덕션 시스템 유지보수의 차이입니다.
진짜 변화
Opus 5.5 모션 디자인에서 가장 흥미로운 점은 하룻밤 사이에 바이럴 애니메이션을 만드는 것이 아닙니다.
그 역량을 반복 가능한 스튜디오로 탈바꿈시켰을 때 일어나는 일입니다.
하나의 에이전트가 크리에이티브 브리프를 관리하고, 비주얼 시스템을 확립하고, 애니메이션을 구현하고, 프리뷰를 렌더링하고, 결함을 비판하고, 최종 납품물을 준비할 수 있습니다.
렌더러는 영상을 재현 가능하게 만듭니다.
스토리보드는 스토리를 의도적으로 만듭니다.
리뷰 루프는 실수를 눈에 보이게 만듭니다.
저장된 컴포넌트와 스킬은 다음 프로젝트를 더 쉽게 만듭니다.
전통적인 단발성 프로세스는 이렇습니다.
프롬프트가 영상을 만들고, 영상이 내보내지며, 다음 프로젝트는 다시 처음부터 시작됩니다.
원봇 스튜디오는 다르게 작동합니다.
완료된 모든 프로젝트는 더 나은 템플릿, 더 나은 모션 컴포넌트, 더 강력한 리뷰 기준, 더 신뢰할 수 있는 납품 절차를 남겨둘 수 있습니다.
첫 번째 영상은 무엇이 가능한지 보여주기에 인상적입니다.
다섯 번째 영상은 프로덕션 프로세스가 반복되기 시작하기에 흥미롭습니다.
스무 번째 영상에서는 축적된 스킬, 컴포넌트, 점검 항목, 크리에이티브 규칙이 그 어떤 개별 프롬프트보다 가치 있어질 수 있습니다.
진짜 기회는 AI로 영상 하나를 만드는 것이 아닙니다. 영상을 만들 때마다 더 나아지는 스튜디오를 구축하는 것입니다.
그리고 제대로 세팅한다면, 그 스튜디오는 단 하나의 봇으로 시작할 수 있습니다.
여기까지 읽으셨다면
점점 복잡해지는 프롬프트로 AI 생성 영상을 고치며 밤을 지새우기 전에, 이 가이드를 북마크해 두세요.
X에서 저를 팔로우하세요: x.com/0xjmori
제 Substack을 구독하세요: substack.com/@lunarresearcher
다음에 제품 출시 영상이 필요할 때, 그냥 무언가를 움직여달라고 Claude에게 부탁하지 마세요.
운영할 스튜디오를 통째로 맡기세요.
참고 자료
