video-creator

목적

제품 데모 및 마케팅을 위한 비디오 콘텐츠 기획. 타임 마크가 포함된 내레이션 스크립트 작성, 장면별 스토리보드 정의, 쇼트 리스트 작성, 필요한 에셋 목록 작성. 완전한 제작 계획을 파일로 저장합니다. 이 스킬은 비디오 제작을 위한 **계획(PLAN)**을 생성합니다 — 실제 비디오 파일이 아닙니다.

호출 (인바운드)

marketing (L2): 데모/설명용 비디오 스크립트
launch (L1): 제품 데모 비디오

호출 대상 (아웃바운드)

없음 — 순수 L3 유틸리티입니다.

실행 가능한 지침

1단계: 브리프 수신

호출 스킬로부터 입력 수신:

topic — 비디오가 다루는 주제 (예: "Rune 플러그인 데모", "Feature X 둘러보기")
audience — 시청자 대상 (예: "개발자", "비기술 창업자", "기존 사용자")
duration — 목표 길이(초) (예: 60, 120, 300)
platform — 게시 플랫폼: youtube | twitter | tiktok | loom | internal
output_path — 계획을 저장할 경로 (기본값: marketing/video-plan.md)

플랫폼에서 제약 조건 도출:

YouTube: 엄격한 길이 제한 없음, 3분 이상일 경우 챕터 권장
Twitter/X: 최대 140초, 처음 3초 안에 후크 필요
TikTok: 최대 60초, 빠른 편집, 자막 필수
Loom: 비동기 친화적, 화면 녹화 중심, 음악 불필요

2단계: 스크립트

타임 마크가 포함된 내레이션 스크립트 작성. 한 줄도 쓰기 전에 아래 나레이션 공예 원칙을 적용하세요 — 시청자가 듣는 스크립트는 쇼트 리스트가 아닌 오프닝과 흐름에 따라 성패가 갈립니다.

구조:

후크 (0–5초): 주의를 끄는 첫 줄 — 문제 또는 보상을 설명
설정 (5–15초): 맥락 — 대상과 학습 내용
데모/본문 (15초–[duration-15초]): 장면으로 나뉜 주요 내용
CTA (마지막 10초): 행동 촉구 — 다음에 할 일 (저장소 스타, 가입, 공유)

각 섹션 포맷:

[00:00] 후크
내레이션: "..."
화면: [시청자가 보는 것]

[00:05] 설정
내레이션: "..."
화면: [시청자가 보는 것]

3단계: 스토리보드

장면별 세분화 작성:

각 장면:

장면 번호와 이름
지속 시간(초)
시각적 설명 (화면에 나타나는 것)
내레이션 텍스트 (2단계에서)
전환 유형: 컷 | 페이드 | 줌 | 슬라이드

예시:

장면 3: 라이브 데모 — 설치 명령어
지속 시간: 12초
시각: 터미널 창, 명령어 입력 "npm install -g @rune/cli", 출력 스크롤
내레이션: "한 명령어로 몇 초 만에 설치합니다."
전환: 컷

4단계: 쇼트 리스트

녹화 또는 표시해야 할 항목을 정확히 정의:

유형별 분류:

화면 녹화: 캡처할 각 화면 상태 나열 (URL, 앱 상태, 수행할 작업)
코드 스니펫: 표시할 각 코드 블록 나열 (파일 경로 + 줄 범위, 또는 인라인)
다이어그램/슬라이드: 필요한 각 정적 시각 자료 나열 (제목, 핵심 포인트)
터미널: 녹화할 각 명령어 시퀀스 나열

포맷:

쇼트 1 — 화면 녹화
  URL: https://myapp.com/dashboard
  동작: "New Project" 클릭 → 양식 작성 → Create 클릭
  지속 시간: ~8초

쇼트 2 — 터미널
  명령어: npm install -g @rune/cli && rune init my-project
  예상 출력: [출력 설명]
  지속 시간: ~10초

5단계: 필요한 에셋

녹화 시작 전에 필요한 모든 에셋 나열:

스크린샷 (어떤 페이지/상태)
코드 스니펫 (어떤 파일, 어떤 섹션)
다이어그램 (주제, 스타일: 순서도 | 아키텍처 | 비교 표)
슬라이드 배경 또는 제목 카드
썸네일 (플랫폼 기반 치수: YouTube 1280x720, Twitter 1200x628)

6단계: 보고서

Write를 사용하여 완전한 비디오 기획서를 marketing/video-plan.md (또는 지정된 output_path)에 저장:

# 비디오 기획서: [topic]

- **플랫폼**: [platform]
- **목표 길이**: [duration]초
- **대상**: [audience]
- **생성일**: [date]

## 스크립트
[2단계의 전체 타임스탬프 스크립트]

## 스토리보드
[3단계의 장면별 세분화]

## 쇼트 리스트
[4단계의 모든 쇼트]

## 필요한 에셋
[5단계의 체크리스트]

## 플랫폼 참고 사항
[대상 플랫폼의 제약 조건 및 팁]

그런 다음 호출 스킬에 요약 출력:

## 비디오 기획서 생성됨

- 파일: [output_path]
- 장면: [count]
- 쇼트: [count]
- 예상 녹화 시간: [n]분
- 준비할 에셋: [count]개

### 다음 단계
1. 기획서에 나열된 에셋 준비
2. 쇼트 리스트 순서대로 녹화
3. 스토리보드를 참조하여 편집

나레이션 공예 (스크립트가 후크를 하거나 지루하게 만드는 결정 요소)

데모 스크립트는 사람이 듣는 것이며, 슬라이드를 읽는 것이 아닙니다. 다음 원칙은 매력적인 스크립트와 평범한 보이스오버를 구분합니다 — 2단계에서 한 줄도 쓰기 전에 적용하세요.

9가지 원칙:

고통 우선 오프닝. 시청자의 가장 큰 고통 또는 이미 진행 중인 통계로 시작 ("만약 당신이…", "이 저장소는 9천 개의 스타를 가지고…"). 절대 평범한 카탈로그 오프닝 금지 ("오늘 우리는…을 살펴볼 것입니다", "이것은…하는 도구입니다") — 문제를 명명하지 않고 스크롤할 이유를 제공하지 않습니다.
대조 구조. "X일 뿐만 아니라 Y", "X가 아니라, Y입니다", "X와 같지만 Y가 있습니다". 대조는 주의를 끕니다.
2인칭 호칭. "당신은 바로 알게 될 것입니다", "M-시리즈 Mac에서 개발한다면…". 시청자를 대화에 참여시킵니다.
직시적 즉시성. "바로 여기", "이것", "지금 타임라인에". 구체적이고 현재적입니다.
구체적인 실제 이름을 사용하고, 전문 용어는 유지. 실제 파일, 명령어, 경쟁사 이름 지정 ("Final Cut", "Cursor", "ffmpeg"). 일반 용어 ("AI 도구", "프레임워크")는 금지입니다. 전문 용어를 어색한 단어로 강제 변역하지 마세요.
수량화된 사회적 증거 — 한 번. "9천 개 이상의 스타". 스타 + 포크 + 이슈를 연속으로 별도 조각으로 덤프하지 마세요.
짧은 절, 쉼표로 연결된 흐름. "트림, 교체 또는 재생성할 수 있습니다." 한 호흡에, 글머리 기호 조각이 아닙니다.
제한 사항을 기능으로. 정직한 한계 또는 "이것을 사용하지 말아야 할 사람"을 한 가지 명시합니다. 이것이 비디오에서 가장 신뢰를 쌓는 대사입니다 — 채우기 용이 아닌 유지 기능입니다.
사용 사례 착륙. "확인해 보세요"가 아닌 특정 시청자 시나리오로 마무리합니다.

이름 + 번호가 매겨진 "무기". 각 차별화 요소에 제목과 번호를 부여합니다 ("무기 01/02"). 명확하지 않은 2-3개의 특정 요소(정규식, 가드, 알고리즘, 폴백)를 찾아내십시오 — 정확히 하나의 놀라운 메커니즘이 일반적인 기능 목록보다 낫습니다.

장면 간 연결 장치. 첫 번째 이후의 각 장면은 이전 내용을 참조하는 언어적 연결 장치로 시작합니다 ("그 핵심은…", "구체적으로…", "하지만 주의할 점은…") — 따라서 전체 비디오가 N개의 전보식 자막이 아닌 하나의 독백으로 재생됩니다. 전체 스크립트를 순서대로 소리 내어 읽어보십시오 — 분리된 사운드바이트처럼 들리면 다시 작성하세요.

자동 실패 패턴 — 다음 중 하나라도 나타나면 스크립트를 거부:

❌ 후크/문제/해결책/CTA 빈칸 채우기를 별도 조각으로 처리
❌ 사이드바 통계(스타/포크/이슈)를 별도의 한 줄 장면으로 처리
❌ 모든 문장이 독립형 글머리 기호로 다시 시작 ("X는 하나의 파이프라인을 실행합니다. Y가 씁니다. Z가 내레이션합니다.")
❌ 일반적인 기능 주장 ("완전한 기능", "매우 강력한", "커뮤니티에서 인기 있는")
❌ 제품 대신 README/저장소 설명
❌ "확인해 보세요" / "시청해 주셔서 감사합니다"로 마무리

보이스오버: TTS 안전 내레이션 (내레이션이 기계로 읽힐 때)

내레이션이 TTS 엔진(AI 보이스오버, 인간 낭독 아님)에 의해 합성될 때, 들리는 내레이션과 화면의 텍스트는 별도의 채널입니다 — 하나는 듣고, 하나는 읽습니다. 각각 독립적으로 최적화하십시오. TTS에 원시 슬러그, 숫자 또는 기호를 그대로 넣고 음성이 올바르게 읽을 것이라고 기대하지 마십시오.

숫자 → 말로 표현된 단어 (많은 신경망 TTS 엔진이 숫자를 잘못 읽을 수 있음):

형식	TTS 오독	작성 방법
버전 소수점	`GPT 5.5` → "오 점 오"	`GPT 오 점 오`
통계 소수점	`82.7%`	`팔십이점칠 퍼센트`
사양	`200MP`	`이백 메가픽셀`
가격	`$5`	`오 달러`
배수/백분율	`2x` / `30%`	`두 배` / `삼십 퍼센트`

영어/브랜드명 → 내레이션에서는 음성 표기, 화면에서는 정확한 철자:

용어	내레이션 (들림)	표시 (읽힘)
README	`레드 미`	`README`
ffmpeg	`에프 에프 엠 펙`	`ffmpeg`
GitHub / repo	`깃 허브` / `레포`	`GitHub` / `repo`
API / GPT	`에이 피 아이` / `지 피 티`	`API` / `GPT`

들리는 내레이션에서 제거: 이모지, URL (깃허브 점 컴 슬래시…라고 말하세요), 기호 (→ & % $ # / @), 슬래시 명령어 ("the plugin install command"라고 말하세요), 문장 중간의 파일 확장자 ("the YAML file"이라고 말하세요), 카멜케이스 식별자, 말줄임표 … 및 대시 — (TTS가 잘못 읽음 — 두 개의 짧은 문장으로 나누세요). 자연스러운 휴지를 위해 모든 문장을 . 또는 ?로 끝내십시오.

전문 용어는 유지, 자연스러운 구어체 사용. 지식이 있는 친구가 말하는 방식으로 쓰십시오 — 하지만 표준 기술 용어 ("커밋", "엔드포인트", "프롬프트")는 일반적인 형태를 유지하십시오. 딱딱한 번역은 어색하고 의미를 잃습니다. 현지인들이 실제로 사용하는 단어일 경우에만 번역하십시오.

실제 제작될 비디오를 위한 프로덕션 노트 (계획만 하는 경우가 아닐 때):

모든 장면에서 하나의 음성, 하나의 제공자 — 비디오 중간에 음성/제공자 변경은 거슬립니다.
먼저 TTS 길이를 측정한 다음 각 장면의 시각 자료를 실제 오디오 길이에 맞게 크기 조정 — 지속 시간을 추정한 후 렌더링하면 A/V 드리프트가 발생합니다.
가라오케 자막은 단편 형식(TikTok/Reels/Shorts)에서 #1 프로 신호입니다: 하단 중앙 자막이 음성과 동기화되어 단어별로 채워지고 키워드가 강조됩니다. 음소거 자동 재생 이해도와 가장 강력한 "전문적" 신호 — 이를 위해 하단 자막 밴드를 예약하십시오.

참고 사항

이 스킬은 비디오 제작을 위한 **계획(PLAN)**을 생성합니다. 실제 녹화 및 편집은 인간 또는 전용 화면 녹화 도구가 수행해야 합니다.

출력 형식

비디오 기획서가 marketing/video-plan.md에 저장되며, 스크립트, 스토리보드, 쇼트 리스트, 에셋 체크리스트 및 플랫폼 참고 사항이 포함됩니다. 장면/쇼트 수 및 예상 녹화 시간이 포함된 요약 보고서. 자세한 내용은 위 6단계 보고서를 참조하십시오.

제약 조건

비디오 매개변수(길이, 해상도, 형식)를 생성 전에 확인해야 함
사용자 확인 없이 합리적인 파일 크기를 초과해서는 안 됨
프로젝트 자산 디렉토리에 저장해야 함

예리한 모서리

이 스킬의 알려진 실패 모드. 완료를 선언하기 전에 확인하십시오.

실패 모드	심각도	완화 조치
플랫폼 제약 조건 미적용 (예: Twitter 최대 140초 초과)	높음	1단계: 플랫폼에서 즉시 제약 조건 도출 — 이후 모든 항목에 영향을 미침
스크립트에 CTA 섹션 누락	중간	모든 스크립트에 CTA(마지막 10초) 필수 — 길이에 관계없이 예외 없음
파일로 저장하지 않음 (구두 출력만)	높음	제약 조건 3 + 6단계: output_path에 쓰기는 필수 — 구두만 = 지속성 없음
실제 비디오 파일 제공 약속	중간	명시: 이 스킬은 계획(PLAN)을 생성 — 실제 녹화는 인간이 수행
고통 우선 후크 대신 평범한 카탈로그 오프너 ("오늘 우리는…을 살펴볼 것입니다")	높음	나레이션 공예 #1: 시청자의 가장 큰 고통으로 시작 — 문제를 명명하지 않은 오프너는 2초 만에 스크롤을 잃음
내레이션에 TTS용 원시 슬러그/숫자/기호 유지 ("README", "82.7%", "5.5")	높음	보이스오버 섹션: 들리는 내레이션을 음성 표기 + 숫자 단어로 다시 작성; 표시 채널에만 정확한 철자 유지
스크립트가 N개의 분리된 사운드바이트처럼 읽힘	중간	나레이션 공예 연결 장치: 첫 번째 이후 각 장면은 이전 내용을 참조하여 시작 — 완료 전에 전체 스크립트 소리내어 읽기

완료 조건

플랫폼 제약 조건 식별 및 길이/형식에 적용됨
나레이션 공예 적용됨 — 고통 우선 오프닝, 장면 간 연결 장치, ≥1 기능으로서의 제한 사항, 자동 실패 패턴 없음
내레이션이 TTS로 읽힐 경우: 들리는 채널에서 숫자 단어 + 음성 표기 브랜드명, 표시에서 정확한 철자
타임 마크가 포함된 스크립트 작성 (후크, 설정, 데모/본문, CTA)
장면별 전환이 포함된 스토리보드 생성
유형별 분류된 쇼트 리스트 (화면 녹화, 터미널, 코드, 다이어그램)
필요한 에셋 체크리스트 생성
런타임의 파일 편집 기능을 사용하여 output_path에 video-plan.md 작성됨
장면 수, 쇼트 수 및 에셋 수가 포함된 비디오 기획서 생성됨 보고서 출력

비용 프로필

~500-1500 토큰 입력, ~500-1000 토큰 출력. 스크립트 품질을 위해 Sonnet 사용.

Rune-kit/rune

rune란 무엇인가요?

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

문서