소프트웨어 제품 런칭 비디오

제품을 이해시키고 원하게 만드는 30–60초 비디오를 제작합니다.

모든 것을 결정짓는 선택: 녹화하지 말고, 다시 빌드하라

화면 녹화는 적과 싸우는 것과 같습니다. 실제 지연 시간은 데드 에어가 되고, 재촬영은 비용이 많이 듭니다. 프레임을 고정할 수 없고, 한 비트를 늦추고 다른 비트를 빠르게 할 수 없으며, 압축으로 인한 뭉개짐 없이 자르는 것도 불가능합니다.

따라서 UI를 Remotion 내에서 프레임 기반 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 레이블 → 기능] → 슬레이트

제품이 게이트되어 있고 랜딩 페이지에서 작업하는 경우, 또는 기능이 진정으로 사용자 여정을 공유하지 않는 경우, 또는 하나의 빌드에서 세 개의 독립적인 클립을 원하는 경우 사용하십시오. 세 개가 숫자입니다 — 네 개면 어느 것도 임팩트가 없습니다.

순차적인 것을 챕터로 나누지 마십시오. 기능이 단일 세션에서 차례로 발생하는 경우(연구 → 초안 → 편집), 이는 하나의 워크플로우이며, 세 가지 기능으로 레이블을 지정하면 소재와 충돌합니다. 순차적인 제품에 챕터를 요청하는 사람이 있다면 대신 중간 경로를 제안하십시오: 단일 내러티브를 유지하고 각 기능이 나타날 때 액션 위에 레이블을 배치하십시오. 동일한 가독성, 동일한 클립 경계, 런타임 비용 없음, 스토리 손상 없음.

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초입니다. 네 가지 사운드면 충분합니다. 음악을 만들기 전에 물어보십시오. 렌더링하기 전에 스틸을 확인하십시오. 확인할 수 없었던 것과 추론한 것을 말하십시오.

LaunchReel — URL→Remotion 런치 필름