제품 기능 비디오 스킬

실제 실행 중인 제품을 위한 데모/기능 비디오를 계획하고 제작합니다. Playwright로 실제 화면을 캡처하고, 실제 TTS로 내레이션하고, 실제 (오픈소스, 라이선스 문제 없는) 배경 음악을 입혀 Remotion으로 조립합니다. 이는 합성 모션 그래픽 제품 트레일러와는 다른 분야입니다. 푸티지는 이미 존재하며 계획에 맞춰 다시 그릴 수 없기 때문에, 계획이 푸티지에 맞춰져야 합니다.

합성 모션 그래픽 트레일러와의 핵심 차이점

많은 Remotion 비디오 워크플로우는 모든 픽셀을 제어하고 어떤 것이든 다시 타이밍을 조정할 수 있다고 가정합니다. 비디오 전체가 처음부터 구축되기 때문입니다: 목업, 생성된 배경, 발명된 UI. 이 가정은 실제 화면 녹화에서는 성립하지 않습니다. 실제 화면 녹화는 자체 시계로 실행됩니다. 실제 클릭은 스토리보드가 원하는 때가 아닌, 특정 한 프레임에서 발생합니다. 일부 순간(네이티브 OS 창, 브라우저의 자체 툴바, 0.5초 만에 완료되는 상호작용)은 계획에 맞춰 다시 촬영할 수 없습니다. 이 스킬은 처음부터 이 제약 조건을 기반으로 구축되었습니다. 모션 디자인 기술(이징, 전환, 모션 밀도)은 여전히 중요하며 8단계에서 다루지만, 파이프라인의 진정한 백본은 푸티지 기반 비디오에 특별히 필요한 것입니다: 캡처할 수 없는 순간에 대한 프로토타입-대체 감사, 실제 푸티지의 줌 및 클릭 강조를 위한 안정성 검증 타겟팅, 그리고 계획이 아닌 실제 자산 지속 시간에 따른 타이밍입니다.

핵심 원칙: 실제 푸티지 우선, 프로토타입 차선, 일러스트레이션 최후

모든 장면에 대해 다음 순서로 우선합니다:

실제 푸티지 — 실제 실행 중인 앱의 실제 Playwright 녹화.
검토된 HTML 프로토타입 — 실제 푸티지로 구조적으로 보여줄 수 없는 것을 동일한 방식으로 캡처(2단계 참조).
정직하고 명확하게 설명된 플레이스홀더 — 위의 두 가지 모두 아직 달성할 수 없고, 실제인 척 하지 않는 경우에만 사용합니다.

절대 3번을 실제처럼 꾸며서 1번을 위조하지 마십시오. 시청자는 데모 비디오가 정확히 실제이기 때문에 신뢰합니다. 하나라도 조작된 것처럼 보이는 순간은 모든 진정한 순간을 무너뜨립니다.

0단계: 브리핑

다른 무엇보다 먼저, 함께 한 번에 물어보세요:

제품 및 저장소 — 이름, 한 줄 설명, 실행 중인 앱 또는 저장소의 URL/로컬 경로.
대상 및 톤 — 누가 보고 있으며, 무엇을 느껴야 합니까 (감동 / 안심 / 흥분)?
길이 — 30초 티저, 60-90초 워크스루, 또는 더 긴 2-3분 둘러보기? 실제 푸티지는 빠르게 길어집니다. 범위에 대해 솔직해지십시오.
반드시 전달해야 할 한 순간 — 시청자가 정확히 한가지를 기억한다면, 그것은 무엇입니까? 이것이 클라이맥스/히어로 비트가 됩니다.
로그인/테스트 계정 — 앱을 캡처하는 데 계정이 필요합니까? 일회용 데모 계정을 만들 수 있습니까, 아니면 이미 존재합니까?
게시 컨텍스트 — 랜딩 페이지, 유튜브, 소셜 피드 (자동 재생 음소거는 캡션/화면 텍스트 결정에 큰 영향을 미칩니다).

제품이 브라우저 확장 프로그램인 경우, Manifest V3가 관련되어 있는지도 물어보십시오 (Playwright 실행 전략이 변경됩니다 — 6단계 참조).

1단계: 리콘 — 실제 디자인 시스템을 추출하고, 발명하지 마십시오

미적 결정 전에, 실제 제품을 읽으십시오:

앱 자체의 CSS/테마 파일에서 실제 색상 토큰, 글꼴 스택, 간격 척도를 가져오십시오. 있는 그대로 사용하십시오. 악센트 색상이 우연히 "일반적인 AI SaaS" 클리셰(인디고/보라색과 거의 검은색 조합은 실제 제품 팔레트에서도 매우 일반적입니다 — 발명된 기본값일 때만 위험 신호이고, 실제 제품일 때는 그렇지 않습니다)와 비슷하더라도 말입니다. 참신함보다 진정성이 우선합니다.
제품의 실제 UI 카피, 용어, 정보 아키텍처를 기록하십시오 — 비디오의 캡션과 음성 해설은 마케팅 의역이 아닌 앱 자체의 단어를 사용해야 합니다.
앱을 사용자처럼 한 번 처음부터 끝까지 실행하십시오. 식별하십시오: 가장 좋은 "히어로" 상호작용은 무엇입니까? 실시간으로 시연하기 어려운 것은 무엇입니까 (2단계 참조)?

추출된 토큰(색상, 글꼴)을 전체 비디오 프로젝트가 한 곳에서 가져오는 tokens.ts/tokens.css에 저장하십시오 — 모든 장면(실제 또는 코드로 제작된)은 동일한 제품에 속하는 것으로 시각적으로 보여야 합니다.

2단계: 프로토타입-대체 감사 (스토리보드 전에 하십시오)

계획된 기능 목록을 살펴보고 Playwright가 구조적으로 캡처할 수 없는 것을 표시하십시오:

OS 수준 브라우저 크롬 — 확장 프로그램 툴바 아이콘, chrome://extensions, 마우스 오른쪽 버튼 클릭 컨텍스트 메뉴, 네이티브 파일 선택기, 네이티브 OS 대화상자. Playwright의 recordVideo는 페이지 콘텐츠만 캡처하며, 브라우저 자체 UI는 절대 캡처하지 않습니다.
네이티브 데스크탑 셸 (Tauri, 패키징된 Electron, Qt 등) — Playwright가 전혀 연결할 수 없는 웹 페이지가 아닙니다.
너무 빠르거나 너무 작아서 안정적으로 보여주기 어려운 상호작용 — 0.5초 미만의 실제 푸티지에서 완료되는 토글 플립은 크롭-줌이나 클릭 강조 링의 좋은 대상이 아닙니다. 둘 다 착지할 안정적인 다중 프레임 윈도우가 필요합니다 (8단계의 ZoomCue/ClickRing 패턴 및 안정성 규칙 참조).

표시된 각 순간에 대해 결정하십시오: 해결 방법이 있는 실제 푸티지 (예: 6단계 참조, 실제 클릭 대신 API 호출로 시드 상태 설정), 검토된 HTML 프로토타입 (7단계), 또는 정직하게 레이블이 지정된 일러스트레이션 (최후의 수단이며, 코드 주석에 명시하십시오).

이 감사를 스토리보드 전에 수행하면, 스토리보드가 실제 캡처 단계에서 전달할 수 없는 타이밍과 범위를 약속하는 것을 방지합니다 — 이것은 TabNemo의 v1-v3에서 재작업의 가장 큰 원인이었습니다.

3단계: 스토리보드 및 장면 계획

내러티브 아크

푸티지가 실제든 합성이든 동일한 구조가 작동합니다:

막	목적	런타임 비중
후크	콜드 오픈 — 제품 이름이 나타나기 전에 문제 또는 인상적인 순간	5-8%
공개	브랜드/제품 이름 등장	8-10%
쇼케이스	3-5개의 실제 기능, 각각 하나의 비트	45-55%
클라이맥스	0단계에서 식별된 히어로 순간 — 가장 시각적인 공을 들이십시오	8-12%
종료	로고, 태그라인, CTA	8-10%

장면별 명세

모든 장면에 대해 미리 결정하고 기록하십시오:

소스: 실제 클립 / 프로토타입 캡처 / 코드 제작 B-roll (2단계의 감사에 따름).
내레이션: 정확한 텍스트 또는 null. 내레이션 길이는 실제 제약입니다 — TTS 오디오 지속 시간은 장면의 최소 길이가 됩니다 (4단계 참조).
실제 푸티지는 자체 시계로 실행됩니다 — 장면의 durationInFrames은 max(실제 클립 길이, 내레이션 길이)이며, 계획이 아닌 실제 렌더링된 자산에서 측정합니다. 내레이션이 클립보다 길면, 클립을 반복하거나 대사를 자르지 않고 클립의 마지막 프레임을 유지합니다.
카메라 계획: 실제 좌표를 사용한 펀치인/줌 또는 클릭 강조 — 추측이 아닌 실제 스틸 이미지에서 결정합니다 (8단계).

검토 체크포인트

단일 클립을 녹화하거나 오디오 음을 생성하기 전에 장면 목록 + 내레이션 텍스트를 보여주십시오. 사용 가능한 푸티지에 대한 잘못된 가정을 기반으로 한 계획은 TTS 및 Playwright 스크립트가 존재한 후에 되돌리기 어렵습니다.

4단계: 음성 해설 — 스크립트 및 생성

하나가 아닌 두 개의 문서를 작성하십시오:

검토 스크립트 — 장면당 하나의 블록, 계획된 타임코드 포함. 사람이 전체 내레이션 아크를 읽고 생성 전에 페이싱을 승인할 수 있습니다.
TTS 입력 스크립트 — 동일한 대사, 장면당 하나의 파일로 분할, 페이싱은 구두점(또는 엔진이 지원하는 경우 SSML <break>/<emphasis> 태그)으로만 전달됩니다. 각 장면은 자체 오프셋에 배치 가능한 자체 오디오 클립이 됩니다.

생성 도구

ttsmp3.com — 무료, 가입 불필요, Amazon-Polly 기반. 공개 API가 없으므로 브라우저 UI를 통해 한 번에 하나의 클립을 생성합니다 — 집중된 단일 세션으로 예산을 책정하고 출력 파일을 장면별로 이름을 지정하십시오 (scene-03.mp3, tts_export_1.mp3 아님).
무인 실행이 필요한 파이프라인(CI, 브라우저가 없는 에이전트)의 경우, 실제로 스크립팅 가능한 오픈소스/로컬 옵션을 선호하십시오: Piper(완전 오프라인, MIT 라이선스, 빠름, 괜찮은 음성) 또는 edge-tts(Microsoft Edge의 읽어주기 음성 래퍼, 무료, 키 불필요, 스크립팅 가능하지만 사용 가능한 외부 서비스에 의존). Gemini TTS 및 ElevenLabs는 API 비용이 허용된다면 강력한 비오픈 대안입니다. 어떤 엔진을 사용하든, 별도 호출 간 음성 일관성을 보장하지 않는다면, 모든 세그먼트를 단일 요청으로 생성하고 사이에 일시 중지 마커를 넣은 다음 감지된 무음을 기준으로 분할하십시오 — 이 한 가지 트릭은 엔진에 관계없이 "대사마다 다른 음성" 문제를 해결합니다.

생성 후 — 오디오가 진실의 원천입니다

생성된 모든 파일의 실제 길이를 측정하십시오 (추정치를 신뢰하지 마십시오). 실제 길이를 장면 계획의 타이밍에 다시 전파하십시오. 이 한 단계는 TabNemo 빌드에서 모든 타이밍 버그를 방지했습니다 — 내레이션은 시청자의 귀가 장면을 측정하는 기준이므로, 계획이 아닌 내레이션이 시계를 설정합니다.

5단계: 배경 음악 — 라이선스 문제 없이 매력적인 곡을 얻으십시오

평평한 패드-앤-드론 루프는 "매력적인" 배경이 아닌 엘리베이터 대기 음악처럼 들립니다. 차이는 거의 항상 화성 패드가 아닌 반복되는 멜로디 후크입니다. 세 가지 실제 옵션, "가장 안전한 라이선스"부터 "가장 확실히 매력적인" 순서입니다:

옵션 A — 절차적 합성 (라이선스 위험 제로, 평평하게 들리지 않도록 실제 노력 필요)

일반 Node/Python에서 짧고 완벽하게 반복 가능한 스테레오 WAV를 생성하십시오 — 모델, 의존성, 라이선스 문제 전혀 없음. 모든 샘플을 직접 작성했기 때문입니다. 실제로 작동했던 구체적인 레시피:

간단한 오실레이터(사인/삼각)와 느린 어택/릴리즈 엔벨로프를 사용한 짧은 (8-16마디) 코드 루프 — 이것만으로는 "엘리베이터 음악" 함정입니다. 후크가 아닙니다.
실제 후크: 패드보다 한 옥타브 위에서 고정된 반복 리듬 패턴으로 연주되는 Karplus-Strong 플럭 현 멜로디 — 이것이 합성 루프를 앰비언트 배경음악이 아닌 기억에 남게 만듭니다. 이 레이어를 건너뛰지 마십시오.
아래에 부드러운 킥 + 하트 펄스가 전진 동력을 제공하며, 내레이션 아래에 충분히 조용합니다.
헤드룸을 남기도록 정규화하고, 전체 진행이 마디 경계에서 완료되도록 루프 길이를 선택하십시오 (들을 수 있는 이음새 없음).

이것은 상업적으로 출시해도 완전히 안전하지만, 멜로디 후크 레이어가 "매력적인" 것과 "일반적인" 것을 구분합니다 — 실제 반복 작업을 예산에 포함시키고, 전체 렌더에 연결하기 전에 사용자의 듣기 및 확인을 받으십시오 (15-20초 루프를 다시 생성하는 것은 저렴합니다. 다른 것을 청취하기 위해 전체 비디오를 다시 렌더링하는 것은 그렇지 않습니다).

옵션 B — 오픈 가중치 생성 음악 모델 (더 "프로듀스된" 느낌, 매번 라이선스 확인)

Stability AI의 Stable Audio Open — 오픈 가중치, 텍스트 프롬프트, 실제 멜로디 콘텐츠가 있는 전체 편곡을 생성합니다. 라이선스 조건은 대부분의 생성 오디오 모델보다 더 허용적이지만 수익 기반 조건이 있습니다 — 상업적 사용 전에 현재 라이선스를 다시 읽으십시오. 이러한 조건은 변경됩니다.
Meta의 MusicGen (audiocraft 라이브러리 통해) — 뛰어난 품질이지만, 음악 모델 가중치는 일반적으로 CC-BY-NC (비상업적) 라이선스입니다 — 별도로 승인 없이 수익화된 제품의 런치 비디오에 생성된 출력을 사용하지 마십시오.
둘 다 로컬에서 실행 가능하거나 (GPU 권장) 로컬 컴퓨팅이 없는 경우 호스팅된 추론 엔드포인트(Replicate, Hugging Face Spaces)를 통해 실행할 수 있습니다.

옵션 C (권장 기본값) — 아이디어는 B 사용, 자산은 A로 출시

로컬에서 오픈 가중치 모델을 프롬프트하여 영감만 얻으십시오 ("매력적인 신스팝 후크, ~110bpm, 따뜻하고 낙관적인 기술 제품 느낌"), 몇 가지 생성물을 듣고 요소를 취합한 다음, 옵션 A의 절차적 접근 방식을 사용하여 라이선스 문제가 전혀 없는 고유한 멜로디 루프를 작성하십시오. 이것은 TabNemo v3에서 실제로 사용된 경로이며, 라이선스 위험 없이 비용이 들지 않으며, 멜로디 레이어에 대한 충분한 반복 작업을 통해 결과적으로 가장 신뢰할 수 있습니다.

어떤 옵션을 선택하든, 레벨을 정규화하고 렌더링 체인의 오디오 트랙에 배치할 때 음성 해설 아래에서 -18dB ~ -24dB로 감소시키십시오 (소셜 피드 자동 재생은 오디오 없이 시작되므로 배경 음악이 캡션 아래에 보일 첫 번째 것을 설정합니다).

6단계: Playwright 녹화 — 실제 앱을 캡처하는 방법

이 단계는 기존 제품의 실제 실행 인스턴스에 대해 Playwright를 실행하는 세부 사항을 다룹니다.

일반 설정

UI가 완전히 로드되고 준비될 때까지 기다리기 위해 적절한 waitForSelector / waitForLoadState를 사용하십시오. 실제 앱에는 지연 시간이 있습니다. 추측하지 말고 기다리십시오.
page.video().path()를 사용하여 비디오 파일 경로에 접근할 수 있도록 recordVideo 옵션과 함께 Playwright 브라우저를 실행하십시오.
뷰포트가 장면 계획의 의도된 화면 비율과 일치하는지 확인하십시오 (가로 1920x1080, 세로 1080x1920 등).
각 상호작용 전후에 스크린샷을 캡처하는 것을 고려하십시오 — 이 스틸 이미지는 8단계에서 줌/클릭 강조 좌표를 결정하는 데 도움이 됩니다.

브라우저 확장 프로그램 특별 고려 사항

Manifest V3: Playwright는 --disable-extensions 플래그 없이 브라우저를 실행하여 확장 프로그램을 로드할 수 있습니다. 확장 프로그램의 ID를 알고 chrome-extension://<id>/<path>를 통해 팝업/옵션 페이지에 접근해야 할 수 있습니다.
Manifest V2: 일반적으로 더 간단합니다. Playwright는 확장 프로그램의 백그라운드 페이지에 연결할 수 있는 경우가 많습니다.
중요한 제한 사항: 확장 프로그램 툴바 아이콘, chrome://extensions 페이지, 또는 OS 수준 브라우저 UI(오른쪽 클릭 메뉴, 경고 등)를 Playwright로 캡처할 수 없습니다. 이는 2단계의 프로토타입-대체 감사에서 처리해야 합니다.

까다로운 상호작용 해결 방법

빠른 전환/토글: 실제 클릭을 재현하는 대신, 녹화 전에 API 호출을 통해 앱의 상태를 원하는 상태로 시드하십시오 (예: fetch('.../api/settings', {method: 'POST', body: JSON.stringify({theme: 'dark'}) })). 그런 다음 Playwright로 결과 UI를 녹화하십시오.
네트워크 지연: 실제 앱이 느린 경우, 시작하기 전에 네트워크 상태를 "느린 3G"로 설정하는 것을 고려하십시오 (Playwright의 context.route 사용) — 이것은 또한 "로딩" 상태를 보여주는 귀중한 기회가 될 수 있습니다.
데이터 종속성: 특정 데이터가 있는 페이지(예: "주문 #12345")를 표시해야 하는 경우, 먼저 API 호출 또는 데이터베이스 시드 스크립트를 사용하여 해당 데이터를 생성하십시오.

체크포인트

각 녹화 후, 장면 계획과 일치하는지 확인하기 위해 재생을 검토하십시오. 추가 테이크가 필요한 경우, 이 단계에서 수행하십시오. 전체 비디오를 다시 캡처할 필요 없이 이 단계는 저렴합니다.

7단계: 코드 B-roll — 합성 (그러나 정직한) 요소 구축

이 단계는 Remotion 컴포지션을 사용하여 코드 기반 B-roll을 생성하여 실제 푸티지와 매끄럽게 혼합하는 방법을 다룹니다.

B-roll 유형

HTML 프로토타입 (2단계에서 식별된 경우): 실제 앱에서 추출한 디자인 토큰을 사용하는 정적 HTML 페이지를 만드십시오. 이를 Playwright를 통해 실행하고 캡처합니다. 특히 네이티브 UI 요소(팝업, 드롭다운)를 보여주는 데 유용합니다.
데이터 시각화: 실제 제품 데이터를 표시하는 차트/그래프를 렌더링합니다. Remotion의 <Video> 또는 <Img> 시퀀스를 사용할 수 있습니다.
화면 주석: 중요한 UI 영역을 강조하는 오버레이, 호출 레이블, 또는 투명한 도형을 렌더링합니다.
전환 요소: 장면 사이를 매끄럽게 전환하기 위해 생성된 배경, 형태, 또는 색상 와이프를 사용합니다.

1단계 토큰 재사용

1단계에서 추출한 tokens.ts/tokens.css 파일을 Remotion 프로젝트로 가져오십시오. 모든 코드 B-roll 요소는 검증된 제품 스타일을 준수해야 합니다.

Remotion 컴포지션 예시

// components/Badge.tsx
import {useCurrentFrame, interpolate} from 'remotion';
import {COLORS, FONT_FAMILY} from '../tokens';

export const Badge: React.FC<{label: string}> = ({label}) => {
  const frame = useCurrentFrame();
  const opacity = interpolate(frame, [0, 15], [0, 1], {
    extrapolateRight: 'clamp',
  });

  return (
    <div
      style={{
        fontFamily: FONT_FAMILY,
        backgroundColor: COLORS.accent,
        color: COLORS.accentText,
        padding: '8px 16px',
        borderRadius: 8,
        opacity,
      }}
    >
      {label}
    </div>
  );
};

체크포인트

B-roll이 실제와 동일한 분위기를 가지고 있는지, 그리고 3단계 장면 계획에 명시된 경우에만 사용되었는지 확인하십시오. 다른 모든 경우에는 실제 푸티지를 사용하십시오.

8단계: 카메라 워크 및 클릭 강조

실제 푸티지는 합성 푸티지와 동일한 시네마틱 관심이 필요하지만, 기술적 제약이 따릅니다.

ZoomCue 패턴

목적: 중요한 UI 요소(버튼, 입력 필드)를 확대하여 시청자의 주의를 끕니다.
규칙: 줌은 실제 푸티지에서 충분히 긴 안정적인 프레임(최소 15-20프레임)에만 적용하십시오. 빠르게 움직이는 장면에 적용하면 흐릿하고 역효과가 납니다.
구현: Remotion에서 interpolate()를 사용하여 zoom Prop을 페이드 인/아웃하고, 선택적으로 CSS transform: scale()을 적용하십시오. 대상 좌표를 실제 스틸 이미지에서 가져오십시오 (추측하지 마십시오).

ClickRing 패턴

목적: (Playwright가 이미 수행한) 실제 클릭 위치에 시각적 강조(원, 물결)를 추가합니다.
규칙: 클릭은 30fps에서 약 0.5초(15프레임) 지속되어야 합니다. 너무 길면 주의를 산만하게 하고, 너무 짧으면 알아차리기 어렵습니다.
구현: 클릭 지점 위에 절대 위치 지정된 <div>를 렌더링하고, 불투명도와 크기를 애니메이션하여 원하는 효과를 만듭니다.

안정성 규칙

장면이 너무 빨리 움직이거나, 흐릿하거나, 앱이 전환 중인 경우, ZoomCue 또는 ClickRing을 적용하지 마십시오. 이러한 효과가 적용되지 않은 클립을 유지하는 것이 불안정한 클립에 강제로 적용하는 것보다 낫습니다.

모션 디자인 (작성자의 선택 사항)

이징, 전환, 모션 밀도와 같은 고급 기술에 대해서는 Remotion 문서 및 모션 디자인 모범 사례를 참조하십시오. 이 스킬은 모션 디자인 코스가 아니라는 점에 유의하십시오 — 이 스킬의 핵심은 실제 푸티지를 캡처하고 계획하는 것입니다.

9단계: 렌더링 및 내보내기

전체 프로젝트 준비가 완료되면 Remotion의 렌더링 파이프라인을 사용하십시오.

렌더링 명령어

npx remotion render src/index.tsx MyComposition out/video.mp4

일반적인 문제

오디오 싱크: 오디오 트랙(음성 해설, 배경 음악)이 비디오와 올바르게 정렬되었는지 확인하십시오. 특히 변환된 코덱에서 Remotion이 예상치 못한 지연을 추가할 수 있습니다.
코덱: 대부분의 용도로 h264를 사용하고, 브라우저 호환성을 위해 h264-mkv 또는 h264-webm을 사용하십시오. 투명도가 필요한 경우 prores를 고려하십시오.
파일 크기: 실제 푸티지는 빠르게 커질 수 있습니다. 출력 크기를 10MB 미만으로 유지해야 하는 경우 비트 전송률을 적절히 조정하거나 더 공격적인 압축을 사용하십시오.

체크포인트

완료된 비디오를 시청하고 모든 장면이 올바르게 렌더링되었는지 확인하고, 동기화 문제, 깜박임, 또는 예상치 못한 동작이 없는지 확인하십시오. 수정 사항이 필요한 경우 이전 단계로 돌아가십시오.

10단계: 게시 (선택 사항이지만 권장)

비디오가 완료되면 적절한 플랫폼에 업로드하십시오.

모범 사례

소셜 미디어: 짧은 버전(30-60초)을 만들고, 자동 재생 환경에 최적화하십시오 (초기 2-3초 내에 강력한 후크, 자막).
랜딩 페이지: 비디오를 랜딩 페이지에 포함하고, 클릭 유도 문구를 근처에 배치하십시오.
유튜브: 더 긴 설명, 태그, 종료 화면 및 카드를 추가하여 참여를 유도하십시오.

검토

분석을 검토하여 시청자 유지율이 가장 높은 순간과 시청자가 이탈하는 순간을 확인하십시오. 이 데이터는 향후 비디오를 개선하는 데 도움이 됩니다.

최종 참고 사항

진정성이 핵심입니다: 시청자는 데모 비디오가 실제 제품을 보여주기 때문에 신뢰합니다. 합성 요소와 실제 요소를 혼합할 때는 항상 명확히 레이블을 지정하십시오.
반복: 완벽한 비디오를 한 번에 만드는 것은 거의 불가능합니다. 검토하고, 수집한 피드백을 바탕으로 다시 방문할 계획을 세우십시오.
라이선스: 모든 자산(글꼴, 음악, 스톡 푸티지)에 적절한 라이선스가 있는지 확인하십시오. 이 스킬은 오픈소스 및 라이선스가 명확한 소스에 중점을 둡니다.

이 스킬의 힘은 적응성에 있습니다 — 각 단계는 필요에 따라 조정되어야 하며, 그렇지 않을 때 조정하는 것보다 가능한 한 많이 실제 푸티지에 의존하십시오.

즐겨 사용하는 AI에게 물어보기

문서

제품 기능 비디오 스킬

합성 모션 그래픽 트레일러와의 핵심 차이점

핵심 원칙: 실제 푸티지 우선, 프로토타입 차선, 일러스트레이션 최후

0단계: 브리핑

1단계: 리콘 — 실제 디자인 시스템을 추출하고, 발명하지 마십시오

2단계: 프로토타입-대체 감사 (스토리보드 전에 하십시오)

3단계: 스토리보드 및 장면 계획

내러티브 아크

장면별 명세

검토 체크포인트

4단계: 음성 해설 — 스크립트 및 생성

생성 도구

생성 후 — 오디오가 진실의 원천입니다

5단계: 배경 음악 — 라이선스 문제 없이 매력적인 곡을 얻으십시오

옵션 A — 절차적 합성 (라이선스 위험 제로, 평평하게 들리지 않도록 실제 노력 필요)

옵션 B — 오픈 가중치 생성 음악 모델 (더 "프로듀스된" 느낌, 매번 라이선스 확인)

옵션 C (권장 기본값) — 아이디어는 B 사용, 자산은 A로 출시

6단계: Playwright 녹화 — 실제 앱을 캡처하는 방법

일반 설정

브라우저 확장 프로그램 특별 고려 사항

까다로운 상호작용 해결 방법

체크포인트

7단계: 코드 B-roll — 합성 (그러나 정직한) 요소 구축

B-roll 유형

1단계 토큰 재사용

Remotion 컴포지션 예시

체크포인트

8단계: 카메라 워크 및 클릭 강조

ZoomCue 패턴

ClickRing 패턴

안정성 규칙

모션 디자인 (작성자의 선택 사항)

9단계: 렌더링 및 내보내기

렌더링 명령어

일반적인 문제

체크포인트

10단계: 게시 (선택 사항이지만 권장)

모범 사례

검토

최종 참고 사항

관련 스킬

steipete/video-frames

steipete/summarize

openclaw/openclaw

obra/superpowers

affaan-m/ECC

affaan-m/everything-claude-code