소프트웨어 제품 런치 비디오 제작
누군가가 제품을 이해하고 원하게 만드는 30~60초 분량의 비디오를 제작합니다.
모든 것을 결정짓는 선택: 녹화하지 말고 재구축하라
화면 녹화는 당신과 싸웁니다. 실제 지연 시간은 데드 에어(dead air)가 됩니다. 재촬영은 비용이 많이 듭니다. 프레임을 잡을 수 없고, 한 박자를 늦추고 다른 박자를 빠르게 할 수 없으며, 압축으로 인한 깨짐 없이 좁게 크롭할 수도 없습니다.
따라서 UI를 Remotion 내에서 프레임 기반 React로 재구축하세요. 모든 시각 요소는
useCurrentFrame()의 순수 함수입니다. 타이핑은 정확한 곡선 위에 떨어지고,
로딩 상태는 박자에 맞춰 해소되며, 재촬영은 숫자 하나를 바꾸는 것으로 끝납니다.
이 방법은 제품의 실제 코드(로컬인 경우)나 DOM+CSS(호스팅인 경우)를 읽어 충실히 재현할 수 있을 때만 합리적입니다. 실제 클래스 이름, 실제 색상, 실제 카피를 사용하세요. 재구축 결과는 녹화와 구별할 수 없어야 하며, 더 나아가야 합니다.
대신 녹화해야 할 경우: 무거운 3D, 제품 내부의 비디오 콘텐츠, Canvas/WebGL 표면, 또는 네이티브 데스크톱 앱. 특정 표면을 재구축할 수 없다면 해당 표면만 녹화하고 <OffthreadVideo>로 합성하세요.
1단계 — 제품 이해하기
이 단계를 시작하기 전에 references/discovery.md를 읽으세요. 여기에는 브라우징 및 트라이지 절차, 자격 증명 대화, 라이브 사이트에서 디자인 시스템을 추출하는 방법이 포함되어 있습니다.
간략 버전:
- URL이 주어진 경우: 브라우징하세요. 랜딩 페이지가 먼저입니다(그들이 자신을 어떻게 포지셔닝하는지 알려줍니다), 그다음 앱 자체를 보세요. 제품이 누구를 위해 어떤 일을 하는지 파악하세요.
- 로컬 리포지토리/개발 서버가 주어진 경우: 코드를 읽으세요. 훨씬 풍부한 정보를 얻습니다 — 실제 컴포넌트, 실제 테마 토큰, 실제 시드 데이터를 얻을 수 있습니다.
- 페이지 트라이지. 대부분의 제품에는 20개의 화면이 있고 그중 중요한 것은 3개뿐입니다. 인증, 설정, 결제, 개인정보, 계정, 온보딩 관련 기본 화면은 거의 이야기의 중심이 아닙니다. 제품이 오직 그것만 할 수 있는 일을 하는 화면을 찾으세요.
- 중요한 내용이 로그인 뒤에 있다면, 먼저 물어보세요 — 테스트 자격 증명, 또는 로컬 개발 환경의 시드 계정이 있는지. 둘 다 없으면 포기하지 말고 본 적 없는 세션을 가짜로 만들지도 마세요: 대신 챕터 형식(Shape B)으로 전환하고 랜딩 페이지의 자체 기능 카드, 카피 및 컴포넌트를 기반으로 구축하세요.
discovery.md에 수집 절차와 정직성 규칙이 있습니다.
그런 다음 빌드를 시작하기 전에 사용자와 함께 읽은 내용을 확인하세요 — 제품을 잘못 읽으면 전체 빌드가 낭비됩니다. 다음을 보여주세요: 제품이 무엇을 한다고 생각하는지, 계획한 2~4개의 화면, 히어로 시나리오, 샷 리스트, 그리고 음악 질문(4단계 참조). 체크포인트 한 번, 그다음 실행.
2단계 — 형식 선택하기
references/structure.md를 읽으세요. 두 가지 형식이 있으며; 잘못 선택하면 빌드가 실패합니다.
형식 A — 단일 내러티브. 기본값. 한 사용자가 하나의 작업을 수행하고 하나의 결과물을 얻습니다. 기능 투어가 아닙니다.
| 비트 | 역할 |
|---|---|
| 후크 (0~5초) | 시청자의 언어로 문제를 진술합니다. 아직 UI는 없습니다. |
| 요청 (5~12초) | 사용자가 무언가를 요청합니다. 입력 필드에 집중합니다. |
| 작업 (12~25초) | 제품이 눈에 띄게 어려운 일을 수행합니다. 증거를 보여줍니다. |
| 결과물 (25~35초) | 출력물을 전체 크기로 읽을 수 있게 표시합니다. |
| 제어 (35~45초) | 사용자가 그것을 변경하고 통제권을 유지합니다. |
| 슬레이트 (45~50초) | 로고, 한 줄 설명, 도메인. |
작업과 제어 비트가 실제 데모와 목업을 구분짓습니다. "추측하지 않고 나에게 물어봤다"와 "내가 만든 것을 편집할 수 있었다"는 신뢰 인수이며, 런치 비디오가 실제로 판매하는 것은 바로 신뢰입니다.
사람이 쉽게 스스로 할 수 없는 일을 제품이 하는 순간을 선택하고, 출력물을 구체적이고 시각적으로 만드세요 — 생성된 문서, 만들어진 차트, 수정된 버그, 배포된 사이트. 구체적인 결과물이 사람들이 기억하는 것입니다.
형식 B — 챕터 형 피처 필름. 세 가지 기능, 각각 평이한 언어의 레이블 카드로 소개된 후 보여집니다.
후크 → [01 레이블 → 기능] → [02 레이블 → 기능] → [03 레이블 → 기능] → 슬레이트
제품이 **게이트형(gated)**이고 랜딩 페이지에서 작업하는 경우, 또는 기능들이 진정으로 하나의 사용자 여정을 공유하지 않는 경우, 또는 하나의 빌드에서 세 개의 독립적인 클립을 원할 때 사용하세요. 3이 적절한 숫자입니다 — 4개면 어느 것도 제대로 전달되지 않습니다.
시퀀스를 챕터로 나누지 마세요. 기능들이 단일 세션에서 차례로 발생한다면(연구 → 초안 → 편집), 그것은 하나의 워크플로우이며, 그것을 세 가지 기능으로 레이블링하는 것은 본질과 맞서는 것입니다. 순차적 제품에 대해 누군가가 챕터를 요청하면 대신 중간 경로를 제안하세요: 단일 내러티브를 유지하고 각 기능이 나타날 때 위에 레이블을 배치하는 것입니다. 동일한 가독성, 동일한 클립 경계, 런타임 비용 없음, 이야기는 그대로 유지됩니다.
structure.md는 챕터 카드 디자인, 레이블 작성 방법(메커니즘보다 결과 이름을 지정하고, 제품 자체의 단어를 사용), 전환 및 순서를 다룹니다.
3단계 — 모든 것을 현실에 기반 두기
제품이 어떤 도메인에 있든, 그 내용을 발명하지 마세요. 법률 제품이면 법령이 실제여야 합니다. 분석 도구이면 숫자가 그럴듯하고 내부적으로 일관되어야 합니다. 코드 도구이면 코드가 보는 이의 머릿속에서 컴파일되어야 합니다.
리포지토리, API, 시드 데이터 또는 문서에서 실제 데이터를 가져오세요. 도메인 전문가들이 이 비디오를 보며, 하나라도 발명된 세부 사항은 그들 모두를 잃게 만듭니다. 당사자 이름, 날짜 및 금액은 발명해도 괜찮습니다 — 그것들은 특정 고객에 대한 것이지 세계에 대한 주장이 아닙니다.
데이터 파일에 각 사실이 어디서 왔는지 출처 주석을 남기세요. 미래의 당신이 필요로 할 것입니다.
4단계 — 빌드하기
실제로 함께 작동하는 버전을 고정하고 설정을 작성하는 스캐폴드를 실행하세요:
python3 <skill-dir>/scripts/scaffold_video.py <target-dir> \
--name "product-launch" --fps 60 --seconds 45
이 명령은 독립적인 Remotion 프로젝트(자체 git 리포지토리 — 요청하지 않는 한 비디오 도구를 제품 리포지토리에 추가하지 마세요)를 생성하고 useCamera.ts를 복사한 후, 채울 타임라인 모듈을 남깁니다.
그런 다음 순서대로:
-
src/timeline.ts— 프레임 수학과 샷 경계. 박자가 정수 프레임인 BPM을 선택하세요(60fps에서: 120 BPM = 30프레임, 90 BPM = 40). 모든 샷 경계를 박자 위에 놓으세요. 음악이 없어도 이는 컷에 내부 리듬을 부여하며, 나중에 배경 음악을 추가할 때 재편집 없이 추가할 수 있습니다. -
src/data/script.<lang>.ts— 모든 문자열, 모든 숫자, 모든 문서 콘텐츠를 하나의 파일에 출처 주석과 함께 넣으세요. 컴포넌트에 하드코딩된 것은 없습니다. 리타이밍과 번역이 모두 간단해집니다. -
컴포넌트 — 제품의 UI를 재현하세요. 실제 클래스 이름을 복사하세요. 제품이 Tailwind를 사용하면 해당 설정과 테마 CSS를 가져오세요; 색상에 CSS 변수를 사용하면 이를 반드시 가져와야 합니다, 그렇지 않으면 모든 것이 무색으로 렌더링됩니다.
-
src/scenes/ProductScene.tsx— 각 비트를 절대 프레임 번호로 갖는 하나의 내보낸B객체입니다. 모든 것(DOM, 카메라, 사운드)이 이 객체를 읽습니다. 리타이밍은 이 블록만 편집하면 됩니다.
샷 시스템에 대해서는 references/camera.md, 지속 시간과 타이포그래피에 대해서는 references/motion.md를 읽으세요.
5단계 — 오디오
두 트랙, 두 파일, 두 개의 <Audio> 태그: 효과와 음악. 서로 분리하여 둘 중 하나를 다른 것을 재생성하지 않고 교체할 수 있게 하세요.
효과 — references/sound.md. 절제가 핵심 규율입니다: 45초 비디오는 보통 총 3~5개의 이벤트만 필요합니다. 팝(popping)은 무언가가 나타났음을 의미하고, 스위시(swishing)는 요소가 샷 내에서 움직였음을 의미하며, 우슉(whooshing)은 샷 자체가 움직였음을 의미합니다.
python3 <skill-dir>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
음악 — references/music.md. 비디오를 만들기 전에 물어보세요. 대부분의 사람들은 의견이 있고 이미 트랙을 가지고 있는 경우가 많습니다; 물어보는 것은 한 문장의 비용으로 전체 노력을 절약할 수 있습니다:
배경 음악을 원하시나요? 트랙이 있으면 보내주시면 맞춰서 편집하겠습니다. 없으면 제가 합성할 수 있습니다 — 에너제틱, 차분, 시네마틱, 미니멀, 따뜻함, 또는 긴장감?
트랙이 있으면 그에 맞춰 편집하세요: BPM을 찾고, 타임라인을 일치시키고, 샷 경계를 해당 마디 위로 옮기세요. 그렇지 않으면 당신의 컷에 맞춰 배치가 변경되는 베드를 합성하세요:
python3 <skill-dir>/scripts/make_music.py music.spec.json public/music.wav
각 실제 샷 경계에 sections 항목을, 가장 큰 컷에 hits 항목 하나를, 그리고 느껴지기보다 읽히길 원하는 모든 유지된 라인 아래에 ducks 항목을 넣으세요. 음악은 최대 ~0.30, 효과는 ~0.62 수준입니다. 제품이 무엇인지에 따라 분위기를 선택하세요 — 진지한 주제는 더 차분한 베드가 필요하고, 바쁜 컷은 더 드문 베드가 필요합니다.
6단계 — 렌더링 전에 스틸로 검증하기
이것이 빠른 피드백 루프이며, 이를 건너뛰면 시간이 낭비됩니다.
npx remotion still <CompositionId> out/f0700.png --frame=700
그런 다음 실제로 PNG를 보세요. 샷당 하나씩, 각 전환 지점에서 하나씩 스틸을 렌더링하세요. 확인: 대상이 프레임 안에 있는지, 어떤 것이 단어 중간에 잘렸는지, 데드 스페이스가 있는지, 텍스트가 맞는지.
오디오 파일이 없어도 스틸이 작동하도록 무음 컴포지션(defaultProps: { withAudio: false })을 추가하세요.
가능한 곳에서는 숫자로 조정하세요. 이징 곡선, 스크롤 거리, 스펙트럴 콘텐츠 — 이 모든 것은 계산 가능합니다. 곡선을 샘플링하고 추측 대신 출력하는 간단한 Python 스크립트를 작성하세요. 렌더링보다 빠르고 정확합니다.
스틸이 제대로 나온 후에만 전체 렌더링을 진행하세요.
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
16GB 머신에서는 concurrency를 4 정도로 제한하세요 — Remotion은 슬롯당 Chrome 탭을 생성하며 기본값(코어 수)은 스와핑을 유발할 수 있습니다.
7단계 — 정직하게 인계하기
파일을 보냅니다. 그런 다음 명확히 말하세요:
- 검증할 수 없었던 것. 스틸은 읽을 수 있지만, 8초가 어떻게 느껴지는지는 판단할 수 없으며, 오디오도 들을 수 없습니다. 그렇게 말하세요.
- 특히 게이트형 제품에서, 관찰보다 재구성한 화면. 그것들을 나열하고, 접근 권한을 공유해 준다면 해당 비트를 다시 하겠다고 제안하세요.
- 당신이 내린 판단 중 사용자가 동의하지 않을 수 있는 부분.
- 음악 교체 방법:
public/music.wav에 WAV 또는 MP3 파일을 넣고 다시 렌더링하세요. - 빌드 중 제품에서 발견한 모든 것 — 렌더링 버그, 잘못된 레이블, 누락된 상태. 당신은 대부분의 사람들보다 더 세심하게 그들의 UI를 읽었습니다. 그 관찰은 종종 비디오 자체보다 더 가치 있습니다.
참고 파일
해당 단계에 도달했을 때 읽으세요 — 자세하므로 미리 모두 로드할 필요가 없습니다.
| 파일 | 시점 |
|---|---|
references/discovery.md | 1단계 — 브라우징, 페이지 트라이지, 자격 증명, 디자인 시스템, 및 게이트형 제품의 랜딩 페이지에서 빌드하기 |
references/structure.md | 2단계 — 단일 내러티브 vs 챕터, 챕터 카드 디자인, 기능 레이블 작성, 전환, 순서 |
references/camera.md | 샷 구축 — 레이아웃 공간, 초점 포인트 카메라, 컷 vs 푸시 vs 모프, 컴포넌트 격리 |
references/motion.md | 애니메이션 지속 시간, 타이포그래피, 후크 패턴, 질문 릴 |
references/sound.md | 사운드 디자인 — 팝/스위시/우슉 용어집, 절제, 키보드 및 클릭 합성 |
references/music.md | 베드 소싱 vs 합성, 분위기 선택, 컷에 섹션 정렬, 효과 아래 믹싱 |
references/pitfalls.md | 첫 번째 렌더링 전에 읽으세요. 실제 시간을 소모하는 버그와 각각의 수정 방법. |
번들 스크립트
아래 <skill-dir>은 이 스킬 자체의 디렉터리입니다 — 스킬이 로드될 때 제공된 경로입니다. 고정된 설치 위치를 가정하지 마세요; 스킬은 개인적으로 설치되거나, 플러그인으로, 또는 프로젝트에 체크아웃될 수 있습니다.
| 스크립트 | 설명 |
|---|---|
scripts/scaffold_video.py | 작동하는 버전 핀과 설정을 포함한 Remotion 프로젝트를 생성합니다 |
scripts/make_sfx.py | JSON 이벤트 목록에서 사운드 효과 트랙을 합성합니다. 샘플 없음, numpy 외 의존성 없음. |
scripts/make_music.py | 여섯 가지 분위기 중 하나로 배경 음악을 합성하며, 배치가 당신의 컷에 맞춰집니다. 동일한 의존성. |
assets/useCamera.ts | 초점 포인트 카메라 훅 — src/hooks/에 복사하세요 |
assets/ChapterCard.tsx | 챕터 형식용 챕터 카드 — src/components/에 복사하세요 |
요약
녹화 대신 재구축하세요. 하나의 이야기, 하나의 결과물 — 단, 제품이 게이트형이거나 기능이 진정으로 분리된 경우 평이한 레이블의 세 챕터를 사용하세요. 모든 도메인 사실을 현실에 기반 두세요. 프레임이 모든 것의 단위입니다. 페이지를 자르는 대신 컴포넌트를 격리하세요. UI 움직임은 150~300ms, 카메라 이동은 약 1초입니다. 네 가지 사운드면 충분합니다. 음악을 만들기 전에 물어보세요. 렌더링 전에 스틸을 확인하세요. 확인하지 못한 것과 추론한 것을 말하세요.