소프트웨어 제품 런칭 동영상
누군가가 제품을 이해하고 원하게 만드는 30~60초 분량의 동영상을 제작합니다.
모든 것을 결정짓는 선택: 녹화하지 말고 재구축하라
화면 녹화는 당신과 싸웁니다. 실제 지연 시간은 죽은 공기입니다. 재촬영은 비용이 많이 듭니다. 프레임을 고정할 수 없고, 한 박자를 느리게 하고 다른 박자를 빠르게 할 수 없으며, 압축 아티팩트 없이 가까이 자를 수 없습니다.
따라서 Remotion 내에서 UI를 프레임 기반 React로 재구축하십시오. 모든 시각적 요소는
useCurrentFrame()의 순수 함수입니다. 타이핑은 정확한 곡선 위에 떨어지고,
로딩 상태는 비트 위에서 해결되며, 재촬영은 숫자 하나를 바꾸는 것에 불과합니다.
이것은 제품의 실제 코드(로컬인 경우)나 DOM+CSS(호스팅된 경우)를 읽고 충실히 재현할 수 있기 때문에 합리적입니다. 실제 클래스 이름, 실제 색상, 실제 카피를 가져오십시오. 재구축은 녹화와 구별할 수 없어야 하며, 더 나아가야 합니다.
녹화해야 하는 경우: 무거운 3D, 제품 내부의 동영상 콘텐츠, 캔버스/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 레이블 → 기능] → 슬레이트
제품이 게이트(gated) 되어 있고 랜딩 페이지에서 작업 중이거나, 기능들이 진정으로 사용자 여정을 공유하지 않거나, 하나의 제작물에서 세 개의 독립적인 클립을 원할 때 사용하십시오. 세 개가 숫자입니다 — 네 개는 모두 임팩트가 떨어집니다.
시퀀스를 챕터로 나누지 마십시오. 기능들이 단일 세션에서 연속적으로 발생한다면(연구 → 초안 → 편집), 이는 하나의 워크플로우이며, 세 가지 기능으로 레이블을 붙이는 것은 재료와 맞지 않습니다. 누군가가 순차적 제품에 챕터를 요청하면 대신 중간 경로를 제안하십시오: 단일 내러티브를 유지하고 각 기능이 나타날 때 레이블을 위에 배치하십시오. 동일한 가독성, 동일한 클립 경계, 런타임 비용 없음, 이야기 유지.
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 | 6가지 분위기 중 하나로 배경 음악을 합성하며, 편곡을 컷에 맞춥니다. 동일한 의존성. |
assets/useCamera.ts | 초점 포인트 카메라 훅 — src/hooks/에 복사하십시오. |
assets/ChapterCard.tsx | 챕터 형식의 챕터 카드 — src/components/에 복사하십시오. |
간단 요약
녹화보다 재구축하십시오. 하나의 이야기, 하나의 결과물 — 단, 제품이 게이트되었거나 기능이 진정으로 분리된 경우 평이한 레이블이 있는 세 개의 챕터를 사용하십시오. 모든 도메인 사실을 근거 있게 하십시오. 프레임이 모든 것의 단위입니다. 페이지를 자르기보다 컴포넌트를 격리하십시오. UI 모션은 150~300ms, 카메라 이동은 약 1초입니다. 네 개의 사운드면 충분합니다. 음악을 만들기 전에 물어보십시오. 렌더링 전에 스틸을 확인하십시오. 확인할 수 없었던 것과 추론한 것을 말하십시오.