소프트웨어 제품 런칭 비디오
누군가가 제품을 이해하고 원하게 만드는 30~60초 비디오를 제작합니다.
모든 것을 결정짓는 핵심 결정: 녹화하지 말고 재구축하라
화면 녹화는 당신과 싸웁니다. 실제 지연 시간은 데드 에어로 이어집니다. 재촬영은 비용이 많이 듭니다. 프레임을 고정할 수 없고, 한 박자를 늦추고 다른 박자를 빠르게 할 수 없으며, 압축 아티팩트 없이 좁게 자를 수도 없습니다.
따라서 UI를 Remotion 내부의 프레임 기반 React로 재구축하세요. 모든 시각적 요소는
useCurrentFrame()의 순수 함수입니다. 타이핑은 정확한 곡선 위에 도착하고,
로딩 상태는 박자에 맞춰 해결되며, 재촬영은 숫자 하나만 바꾸면 됩니다.
이것은 제품의 실제 코드(로컬인 경우)나 DOM+CSS(호스팅된 경우)를 읽고 충실히 재현할 수 있기 때문에만 가능합니다. 그렇게 하세요 — 실제 클래스 이름, 실제 색상, 실제 카피를 가져오세요. 재구축은 녹화와 구분할 수 없어야 하며, 더 나아가야 합니다.
녹화해야 할 때: 무거운 3D, 제품 내부의 비디오 콘텐츠, Canvas/WebGL 표면, 또는 네이티브 데스크톱 앱. 특정 표면을 재구축할 수 없다면 해당 표면만 녹화하고 <OffthreadVideo>로 합성하세요.
1단계 — 제품 이해하기
이 단계를 시작하기 전에 references/discovery.md를 읽으세요. 탐색 및 분류 절차, 자격 증명 대화, 라이브 사이트에서 디자인 시스템 추출 방법을 다룹니다.
간략 버전:
- URL이 주어진 경우: 브라우징하세요. 먼저 랜딩 페이지(제품이 어떻게 자신을 포지셔닝하는지 알려줍니다), 그다음 앱 자체를 탐색하세요. 제품이 누구를 위해 어떤 일을 하는지 파악하세요.
- 로컬 리포지토리/개발 서버가 주어진 경우: 코드를 읽으세요. 훨씬 풍부합니다 — 실제 컴포넌트, 실제 테마 토큰, 실제 시드 데이터를 얻을 수 있습니다.
- 페이지 분류하기 대부분의 제품에는 20개의 화면과 3개의 중요한 화면이 있습니다. 인증, 설정, 결제, 개인정보, 계정, 온보딩 보일러플레이트 — 이것들은 거의 스토리에 포함되지 않습니다. 제품이 오직 자신만 할 수 있는 일을 하는 화면을 찾으세요.
- 좋은 콘텐츠가 로그인 뒤에 있는 경우, 먼저 요청하세요 — 테스트 자격 증명 또는 로컬 개발 환경의 시드 계정. 둘 다 사용할 수 없다면 포기하지 말고 보지 않은 세션을 위조하지 마세요: 챕터 형태로 전환하고 랜딩 페이지 자체의 기능 카드, 카피 및 컴포넌트로 구축하세요.
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 레이블 → 기능] → 슬레이트
제품이 게이트되어 있고 랜딩 페이지에서 작업하는 경우, 또는 기능이 진정으로 사용자 여정을 공유하지 않는 경우, 또는 하나의 빌드에서 세 개의 독립된 클립을 원하는 경우 사용하세요. 세 개가 숫자입니다 — 네 개는 모두 기억되지 않습니다.
순서를 챕터화하지 마세요. 기능이 단일 세션에서 차례로 발생하는 경우(연구 → 초안 → 편집), 이는 하나의 워크플로우이며, 세 가지 기능으로 레이블을 붙이는 것은 자료와 싸우게 됩니다. 누군가 순차적 제품에 챕터를 요청하면 대신 중간 경로를 제안하세요: 단일 내러티브를 유지하고 각 기능이 나타날 때 레이블을 위에 덮어씌우는 것입니다. 동일한 가독성, 동일한 클립 경계, 런타임 비용 없음, 스토리 유지.
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개의 이벤트가 필요합니다. 팝 소리는 무언가가 나타났음을 의미하고, 스위시는 요소가 샷 내에서 움직였음을 의미하며, 우쉬는 샷 자체가 움직였음을 의미합니다.
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 머신에서는 동시성을 약 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초. 네 개의 사운드면 충분. 음악을 만들기 전에 요청하세요. 렌더링 전에 스틸을 확인하세요. 확인할 수 없었던 것과 추론한 것을 말하세요.