SaviourV2/비즈니스 모션 필름

비즈니스 모션 필름은(는) 무엇을 하나요?

프리미엄 SaaS 런치 필름처럼 보이지만 실제 비즈니스 결과를 판매하는 단편(15~40초) 광고를 만듭니다. 서비스를 설명하고, 견적 요청을 유도하며, 견적 후속 조치를 하거나, 광고를 새롭게 단장합니다. 영상은 야심 차게 만들 수 있지만, 주장은 사실에 기반해야 합니다.

현재 단계에 필요한 참조 파일만 읽으십시오:

단계	읽을 파일
수직 시장, 오퍼, 파일럿 범위, 가격 앵커 선택	references/business-offers.md
스토리보드 및 모션 디자인	references/motion-grammar.md, 그 다음 구체적인 모멘트를 위해 references/launch-film-notes.md
3D 컴포넌트 구축	references/three-js-patterns.md, templates/component-lab.html, templates/projected-overlays.js
실제처럼 움직여야 하는 3D 제품 히어로(펼쳐지고, 닫히고, 드러나는)	references/product-hero-realism.md
모든 리뷰 라운드	references/gauntlet.md, references/critic-prompts.md, references/quality-bar.md
음악, 사운드 효과, 믹스	references/audio.md
전체 워크플로 예시	references/case-study-alder.md (차분한 서비스 필름), references/case-study-duo.md (Three.js 제품 필름), references/case-study-home-display.md (비평가가 SHIP을 선언한 후 클라이언트가 변경한 사항)

절대 규칙

1. 진실. 평가, 평점, 완료된 작업, 진단, 절감액, 보증 또는 확정된 약속을 절대 허위로 만들지 마십시오. 콘셉트 필름은 콘셉트임을 명시해야 합니다("가상 브랜드 · 콘셉트 필름 · AI 생성 이미지"). 클라이언트 필름은 클라이언트가 승인한 영상과 사실을 사용해야 합니다.
2. 음소거 상태에서도 비즈니스 목적이 드러나야 함. 처음 보는 사람이 음소거 상태에서도 영상이 끝날 때까지 비즈니스가 무엇을 하는지, 다음에 무엇을 해야 하는지 알 수 있어야 합니다.
3. 독립적 판단. 제작자는 자신의 작업을 평가하지 않습니다. 모든 컴포넌트와 모든 최종 컷은 렌더링, 브리프 및 참조 파일(references/gauntlet.md)만 보고 판단하는 새로운 비평가에게 전달되어야 합니다.
4. 결정론적 모션. 모든 애니메이션 상태는 타임라인 시간의 순수 함수여야 합니다. 자유 실행 requestAnimationFrame, Date.now(), 시드 없는 난수 또는 물리 히스토리를 사용하지 마십시오. 어떤 프레임을 찾아가도 동일한 픽셀을 얻을 수 있어야 합니다.
5. "버그 없음"이 "좋음"은 아닙니다. 깨끗하고 부드럽고 오류 없는 버전이라도 기본적이거나, 텅 비었거나, 느리다는 이유로 거부될 수 있습니다. 측정(scripts/)하고 창의적으로 판단하십시오.

워크플로

1. 브리핑 (15분)

BRIEF.md 작성: 비즈니스, 구매자, 시청자의 문제, 단일 행동(CTA), 증명 가능한 사실, 사용 가능한 실제 에셋, 길이, 화면비, 브랜드(팔레트, 서체), 그리고 절대 주장해서는 안 되는 사항. 사용자가 실제 에셋을 가지고 있지 않다면, 레이블이 붙은 콘셉트임에 동의합니다.

2. 참조

references/launch-film-notes.md에서 스토리에 맞는 메커니즘을 가진 3~6개의 모멘트를 선택하십시오(예: 전경 비행 통과, 지속적으로 선택된 객체, 또는 계층화된 분해도). 사용자가 참조 비디오를 제공하면 프레임을 추출하고(scripts/contact-sheet.sh), 정확한 타임스탬프를 인용하십시오. 메커니즘만 차용하고, 레이아웃, 로고 또는 영상은 절대 차용하지 마십시오.

3. 구축 전 스토리보드

하나의 테이블: 시간 → 시청자가 보는 것 → 비트의 비즈니스 역할 → 전환 방식(어떤 객체가 유지되는지 포함). 규칙:

• 30초 필름 기준 12~15개의 뚜렷한 구도. 스케일 다양화: 매크로 → 와이드 → 오버헤드 → UI 클로즈업 → 타이포그래피 임팩트.
• 주요 피처 비트에서는 리드 대상이 사용 가능한 프레임의 60~85%를 채워야 합니다. 넓은 빈 필드에 떠 있는 작은 카드는 안 됩니다.
• 모든 비트는 읽기 쉬운 랜딩을 가진 후, 가속화된 이그제트로 이어져야 합니다. 약 0.6초 이상 모션 없이 정지하지 마십시오.
• 효과 이름 없이 설명할 수 있는 3개의 시그니처 변환을 지정하십시오(예: "검사 사진이 리포트의 히어로 이미지가 됨").
• 3D는 물리적이거나 공간적인 것을 설명할 때만 사용하십시오. 타이포그래피와 UI는 선명한 HTML/SVG로 유지하십시오. 스토리보드 자체에 대해 빠른 비평가 패스를 받으십시오(시간 순서, 비즈니스 논리, 진실성).

4. 에셋

• AI 스틸: 먼저 키 프레임을 생성한 다음, 이미지-투-비디오로 애니메이션화하십시오. 프로덕션 브리프 스타일로 프롬프트: 렌즈, 조명, 노출("밝고, 경쾌하며, 검은색으로 뭉개진 부분 없음"), 타이포그래피를 위한 네거티브 공간, 필요할 때 "사람 없음 / 텍스트 없음 / 로고 없음 / 워터마크 없음".
• AI 비디오: 짧은(4~5초) 클립으로 카메라 움직임을 제한하십시오("안정적인 짐벌 달리, 약 25cm 이동, 정확한 지오메트리 유지, 모핑 없음"). 720p/24fps를 예상하고 보간/업스케일링하십시오(네이티브 디테일이 아님). 지오메트리가 왜곡되는 클립은 거부하고, 숨기지 말고 재생성하십시오.
• 생성 원장 유지: 모델, 프롬프트, 시드, 작업 ID, 허용된 윈도우. API 키를 절대 커밋하지 마십시오.

5. 컴포넌트를 격리하여 빌드

각 사용자 정의 컴포넌트(3D 씬, 리포트 UI, 예약 흐름, 로고 마크)는 자체 랩 페이지(templates/component-lab.html)를 가지며, 스틸과 짧은 모션 증명으로 렌더링된 후, 필름에 합류하기 전에 컴포넌트 건틀릿 라운드를 거쳐야 합니다.

6. 조립

하나의 루트 타임라인; 각 씬은 하위 컴포지션; Three.js 씬은 루트 시계에서 렌더링됨; 라벨, 핀, 리더 라인과 같은 오버레이는 매 프레임 투영된 3D 앵커에서 위치가 지정됨(templates/projected-overlays.js). 씬 간에 객체를 정확한 픽셀 좌표로 전달하여, 씬 A의 마지막 프레임이 전달된 객체에 대해 씬 B의 첫 번째 프레임과 동일하도록 합니다.

7. 전체 필름 건틀릿

전체 필름을 렌더링합니다. scripts/frozen-time.sh 및 scripts/loudness.sh를 실행합니다. 새로운 비평가에게 references/critic-prompts.md(전체 필름 프롬프트)와 함께 보냅니다. 영향력이 가장 큰 항목을 수정하고, 다시 렌더링한 후, 이전 목록을 항목별로 확인하는 새로운 비평가에게 보냅니다. 품질 기준에 도달하거나 개선 효과가 미미해질 때까지 중단합니다(보통 3~5라운드).

8. 오디오는 마지막에, 하지만 부차적인 것이 아님

references/audio.md를 따릅니다. 픽처-락된 음악의 경우, 실제 트랙을 백-타임하여 자체 엔딩이 엔드 카드에 맞춰지고, 모든 컷이 비트에 맞춰 하나의 연속적인 곡으로 재생되도록 합니다(scripts/backtime-music.py). 같은 픽처 아래에서 여러 트랙을 제공하고 클라이언트가 귀로 선택하게 합니다. 음악은 구매자의 고객과 일치시키고 효과음보다 훨씬 작게 유지합니다(가정 서비스의 경우 로파이 또는 따뜻한 어쿠스틱). 실제 전환당 부드럽고 럼블 없는 스우시 한 번; 실제 액션에만 깨끗한 UI 사운드; 각 이벤트 레벨은 각 효과의 밴드 내에서 해결(scripts/solve-sfx-gains.py); 후보는 scripts/sfx-candidates.py로 선별. 항상 음악 전용 폴백을 제공하고, 이를 통해 불만 사항을 분리합니다. 클라이언트가 효과를 싫어하면 더 깔끔한 효과로 교체하고, 삭제하지 마십시오. 히어로 모멘트를 들을 수 있게 만드십시오.

9. 납품

마스터 MP4(모션 작업용 1080p60), 포스터 프레임, 콘택트 시트, 편집 가능한 소스, 생성 원장, 건틀릿 원장(각 비평가가 발견한 사항 → 변경된 사항 → 수정 전후 측정값). 한계를 정직하게 명시: 측정한 것과 청취한 것, 샘플 검토와 전체 검토. 납품물에 프로젝트 고유 이름을 지정하고, 각 라운드를 자체 이름이 있는 폴더에 넣고, 클라이언트가 열어볼 수 있게 하십시오. 비평가들이 SHIP을 선언한 후 클라이언트의 자체 검토를 예상하고, 타임스탬프(references/gauntlet.md)를 기준으로 처리하십시오.

이 플레이북에서 클라이언트가 기대했던 작업 스타일

• 계획을 명확히 세우고(스토리보드), 모든 단계의 승인을 위해 멈추지 않고 구축하십시오.
• 오랜 시간 작업할 때는 한 줄로 상태를 보고하십시오.
• 시간이 부족하면 데드라인 모드(references/gauntlet.md)로 전환하십시오: 하드 스톱, 통합, 한 명의 비평가, 상위 수정, 납품.
• API 키를 파일에 절대 작성하지 마십시오. 키를 사용해야 한다면 사용자가 자신의 터미널에서 단일 명령을 실행하도록 하고, 채팅에 붙여넣은 키는 교체를 제안하십시오.
• 작업 결과를 보여주십시오: 콘택트 시트, 측정된 수치, 비평가 판정.