Claude Code와 Opus 5.5로 15초 제품 모션그래픽 만드는 법

제품 스크린샷 몇 장과 로고를 주고 Claude Code에 15초짜리 소개 영상을 맡길 수 있을까. Opus 5.5로 완성도 높은 결과를 얻었다는 경험이 공유되면서 한 번의 지시로 어디까지 만들 수 있는지가 관심사가 됐다. 하지만 모델 이름보다 중요한 건 실제 제품 화면과 장면의 길이, 음악의 박자를 작업물에 어떻게 고정하느냐다.

한 번에 잘 나온 영상에서 확인할 수 없는 것

공유된 사례의 요청은 구체적이었다. 실제 제품 스크린샷과 로고를 쓰고 움직임을 음악에 맞추되, 임시 시연물처럼 보이지 않게 해달라는 내용이었다. 결과가 좋았다는 반응도 있었다. 다만 완성 파일과 프로젝트 구성은 확인되지 않아 어떤 렌더러를 썼는지 단정할 수 없다.

HTML과 타이포그래피를 움직여 영상을 만든 듯하다는 추측은 기술적으로 가능한 설명이다. Remotion은 React 컴포넌트를 프레임별 화면으로 렌더링하며 장면의 크기·프레임률·총 프레임 수를 Composition에 지정한다. 그렇다고 그 사례가 실제로 Remotion을 썼다고 볼 수는 없다. (remotion.dev)

Opus 5.5가 새로 나온 모델이라는 점은 확인된다. Anthropic은 2026년 9월 22일 모델을 발표했고 Claude Code에서도 사용할 수 있다고 안내한다. 다만 발표 자료의 코딩 성능이나 토큰 가격이 15초 영상의 완성도, 제작 시간, 총비용까지 보증하지는 않는다. 영상 작업에는 렌더링과 에셋 제작이 별도로 들어갈 수 있다. (anthropic.com)

재료를 먼저 고정하면 제품 화면을 지킬 수 있다

이 사례를 재현 가능한 작업으로 바꾸려면 프롬프트보다 파일 목록이 먼저다. 예를 들어 logo.png, dashboard.png, feature.png, 사용 허가를 받은 music.mp3를 준비한다. 스크린샷에 고객 정보나 테스트 계정이 보이지 않는지도 확인한다. 실제 제품 화면을 보여주려는 영상이라면 존재하지 않는 UI를 새로 그리지 말라는 조건도 명시해야 한다.

Remotion 공식 안내는 Node.js와 코딩 에이전트를 준비한 뒤 새 프로젝트를 만들도록 설명한다. npx create-video --yes --blank --no-tailwind my-video로 시작해 프로젝트에서 의존성을 설치하고 npx remotion skills add를 실행하는 순서다. Claude Code용 Remotion 플러그인을 설치하는 별도 경로도 있다. 두 경로 모두 영상 편집 기능을 Claude Code에 알려줄 뿐 브랜드 에셋을 대신 마련해주지는 않는다. (convert.remotion.dev)

파일은 프로젝트의 public/ 폴더에 두고 코드에서 staticFile('logo.png')처럼 참조할 수 있다. 이때 경로에 public/을 다시 쓰거나 컴퓨터의 절대경로를 넣으면 안 된다. 작업 디렉터리를 통째로 읽히기보다 필요한 화면만 따로 모으면 에이전트가 사용할 재료도 분명해진다. (cloudrun.remotion.dev)

15초를 장면과 프레임으로 나눠 지시한다

“전문 쇼릴처럼”은 분위기는 전하지만 편집 기준이 되지는 않는다. 0~3초에 제품 이름, 3~8초에 핵심 화면, 8~12초에 기능 변화, 12~15초에 로고를 보여주는 식으로 장면표부터 쓸 수 있다. 각 구간에 쓸 스크린샷과 화면을 얼마나 오래 멈춰 읽게 할지도 적는다. 초 단위 배치는 예시이므로 제품에 맞게 바꿔야 한다.

30fps로 만들면 15초는 450프레임이다. Claude Code에는 준비한 파일로 장면별 React 컴포넌트를 만들고 각 장면의 시작 프레임과 지속 시간을 지정해달라고 요청한다. 산출물은 막연한 ‘AI 영상’이 아니라 수정 가능한 프로젝트 코드와 렌더링된 영상 파일이다. Remotion은 프로젝트 미리보기와 CLI 렌더링을 지원하므로 특정 장면만 고쳐 다시 출력할 수도 있다. (remotion.dev)

금지할 동작도 프롬프트에 넣는다. 로고를 변형하지 말 것, 화면의 버튼 문구를 바꾸지 말 것, 스크린샷을 읽기 어려울 만큼 빠르게 넘기지 말 것. 화려한 전환보다 사용자가 실제로 무엇을 보게 되는지가 제품 소개 영상의 성패를 가른다.

음악 동기화는 감상이 아니라 타임라인으로 검수한다

음악과 모션을 맞춰달라는 요청만으로 모든 컷이 박자에 붙지는 않는다. 음악 파일을 프로젝트에 넣고 시작·전환·강조·마지막 로고가 등장할 시점을 초 또는 프레임으로 적어줘야 한다. Remotion은 이미지와 오디오의 타임라인 위치를 조정할 수 있다. 렌더링 후에는 소리를 켜고 컷 전환과 강조 동작을 다시 확인해야 한다. (remotion.dev)

써본 사람들 사이에서는 코드로 장면을 빠르게 구성할 수 있어 편리하다는 반응과 박자·가독성을 손으로 다시 다듬어야 한다는 반응이 함께 나온다. 공유된 사례에서 음악 관련 단어의 오탈자가 결과를 크게 해치지 않았다는 의견도 있었다. 이를 오탈자를 허용하는 제작법으로 받아들이기보다 중요한 조건을 파일과 타임라인에 남기는 편이 검수하기 쉽다.

개인 개발자나 작은 팀에는 수정 단위가 남는다는 점이 실익이다. 기능 화면이 바뀌어도 영상을 처음부터 다시 요청할 필요 없이 해당 스크린샷과 장면만 교체할 수 있다. 반대로 음악 사용 권한과 화면 속 정보까지 모델이 판단해줄 것이라 기대해선 안 된다.

Opus, Sol, Astra 비교는 같은 결과물로 해야 한다

공유된 대화에는 Opus의 결과를 기준으로 Sol·Astra에게도 제작을 맡기고 Luna로 검토해보자는 구상이 있었다. 비교가 실행됐는지, 어느 쪽이 더 나았는지는 확인되지 않았다. 모델별 영상을 견주려면 같은 원본 스크린샷, 음악, 장면표, 출력 규격을 제공해야 한다. 한 모델에만 더 긴 수정 시간을 주면 결과 차이를 모델 능력으로 해석하기 어렵다.

비교 항목으로는 제품 화면의 정확성, 읽을 시간, 전환 시점, 음악과의 어긋남, 수정에 필요한 작업량을 잡을 수 있다. 생성 영상 서비스도 대안이다. Runway의 제품 영상 안내는 실제 제품 이미지를 참조 자료로 주고 장면별 이미지를 확인한 뒤 움직임을 만들도록 권한다. 실사에 가까운 장면이 목표라면 이 경로를 비교할 만하다. 정확한 UI와 문구를 계속 고쳐야 한다면 코드 기반 편집이 더 직접적인 선택지다. (dev.runwayml.com)

한 번의 좋은 결과는 출발점이다. 같은 에셋으로 다시 만들고 한 장면을 고쳐도 품질이 유지되는지 확인해야 15초 영상이 반복 가능한 제작 방식인지 판단할 수 있다.