SaaS 모션 디자인
실제 제품 UI가 주인공이 되고 모든 움직임이 무언가를 설명하는 제품 필름을 만듭니다.
기본 설정 요약
| 설정 | 기본값 | 변경 조건 |
|---|---|---|
| 화면 비율 | 16:9 (1920×1080) | 사용자가 명시적으로 9:16을 요청하는 경우 |
| 프레임 레이트 | 60fps | 사용자가 다른 값을 요청하는 경우 |
| 배경 | 오프화이트 | 사용자가 다른 배경을 지정하는 경우 |
| 색상 | 제품 자체 UI 테마에서 가져옴 | 절대 하드코딩하지 않음 |
| 그라데이션 | 없음 | 사용자가 명시적으로 요청하는 경우 |
| 내레이션 | 없음 | 사용자가 명시적으로 요청하는 경우 |
| 음악 | 사용자가 선택하는 고에너지 Mixkit 트랙 | 사용자가 차분한 분위기를 원하거나, 적합한 트랙이 없거나, 필름이 방송용인 경우 (오디오 참조) |
실행당 하나의 비디오. 단일 화면 비율로 렌더링합니다. 16:9와 9:16을 함께 생성하지 마십시오. 9:16 컷은 사용자가 요청할 때만 만듭니다.
기술 스택
| 도구 | 버전 | 용도 |
|---|---|---|
| Remotion | 4.0.535 | 모든 장면을 React 컴포넌트로 제작, Remotion Studio에서 미리보기, 스틸 및 렌더링 내보내기 |
| FFmpeg | 최신 안정 버전 | 오디오 믹싱, 내레이션 아래 음악 덕킹, 콘택트 시트, 최종 인코딩 |
| Node.js | 24 | Remotion 및 빌드 스크립트 실행 |
- Remotion을 정확히 고정하세요. 모든
remotion및@remotion/*패키지를4.0.535버전으로^또는~없이 설치하세요. 일치하지 않는 Remotion 패키지 버전은 렌더링을 망가뜨립니다. - 먼저 Node를 확인하세요. 아무것도 설치하기 전에
node -v를 실행하세요. v24가 아니라면 진행하기 전에 사용자에게 알리세요. - 모든 모션을 프레임에서 파생시키세요.
useCurrentFrame()과 아래의 이징 프리셋을 사용한interpolate()/Easing.bezier()로 애니메이션을 적용하고, CSS 전환이나 타이머를 사용하지 마세요. 모든 렌더링이 프레임 정확하게 나오도록 합니다. - 컴포지션을 기본적으로 1920×1080, 60fps로 설정하거나, 9:16이 요청된 경우에만 1080×1920으로 설정합니다.
- 리뷰용 스틸:
npx remotion still <composition> --frame=<n> - 최종 렌더링:
npx remotion render <composition> out/<name>.mp4 --codec=h264
워크플로우
- 계획. 브리프를 수집하고 계획과 샷 리스트를 작성합니다 (아래 계획 참조). 사용자의 승인을 받습니다.
- 제품 읽기. 가능하면 프론트엔드 코드베이스를 읽고, 그렇지 않으면 라이브 UI를 읽고 테마를 추출합니다 (아래 제품 액세스 및 브랜딩 참조).
- 스크립트 작성 및 사용자 승인 획득 (아래 스크립트 참조).
- 필름 제작 아래의 모션, 코레오그래피, 카메라 및 전환 규칙을 사용하고 영감 참고 자료의 정신을 따릅니다.
- 오디오 추가: 사용자가 선택할 수 있도록 Mixkit 트랙을 숏리스트에 올리고 (아래 오디오 참조), SFX를 추가하고, 요청된 경우에만 내레이션을 추가합니다.
- 품질 점검 실행.
- 스틸 표시 및 대기. 사용자에게 리뷰 스틸을 보여주고, 질문에 답변하고 변경 사항을 적용합니다 (아래 스틸 리뷰 참조). 사용자가 승인할 때만 렌더링합니다.
승인 단계를 건너뛰지 마십시오. 각 단계는 다음 단계보다 수정하는 데 비용이 덜 듭니다.
계획
스크립트를 작성하기 전에 필름의 목적에 동의합니다.
1. 브리프 수집
스스로 알 수 없는 것만 사용자에게 물어보세요:
| 질문 | 제공되지 않은 경우 기본값 |
|---|---|
| 제품은 무엇이며, 프론트엔드 코드베이스를 공유해 주실 수 있나요? 그렇지 않다면 라이브 UI에 어떻게 접근할 수 있나요 (URL, 로컬 빌드, 로그인)? | 필수. 물어보세요. 코드베이스를 선호합니다. |
| 이 필름의 대상 시청자는 누구인가요? | 잠재 고객 |
| 시청자가 기억해야 할 한 가지는 무엇인가요? | 필수. 물어보세요. |
| 어떤 기능 또는 플로우를 보여줘야 하나요? | 핵심 메시지를 가장 잘 증명하는 2~3개의 플로우 |
| 길이는 얼마나 되어야 하나요? | 30~45초 |
| 어디에 게시될 예정인가요? TV나 라디오에서 방영되나요? | 웹사이트 및 X/LinkedIn (16:9), 온라인 전용 |
| 내레이션이 필요하며, 필요하다면 남성 또는 여성 음성인가요? | 내레이션 없음 |
| 콜투액션은 무엇인가요? | 제품 URL 방문 |
2. 계획 작성
사용자에게 승인받을 간단한 계획을 제공하세요:
- 목표: 필름이 달성해야 할 한 문장
- 대상: 시청자와 그들이 이미 알고 있는 내용
- 핵심 메시지: 시청자가 기억해야 할 한 줄
- 형식: 길이, 화면 비율 (9:16이 요청되지 않았다면 16:9), 내레이션 유무
- 스토리 아크: 이 제품에 맞게 채워진 구조 템플릿 (아래 스크립트 참조), 섹션당 한 줄
- 캡처할 플로우: 기록할 정확한 UI 화면과 상호 작용, 각각에 필요한 데이터 상태 (예: "12개의 작업이 있는 프로젝트 보드, 그중 3개는 기한 초과")
- 증거: 필름이 보여줄 증거 (있는 경우), 예를 들어 지표, 고객 로고, 인용문, 벤치마크 또는 수상 내역, 출처
3. 샷 리스트 작성
스토리 아크를 샷으로 나누고, 샷당 한 행:
| # | 섹션 | 샷 | 모션 | 지속 시간 |
|---|---|---|---|---|
| 1 | 후크 | 제품 검색창에 입력되는 질문 | 커서가 입력되고, 답변이 스트리밍됨 | 4초 |
샷 리스트는 스크립트의 "화면에 표시되는 내용" 열이 됩니다.
제품 액세스
필름은 제품에 대한 접근 권한만큼 좋습니다. 선호도 순서:
| 접근 방법 | 제공되는 것 |
|---|---|
| 1. 프론트엔드 코드베이스 (최고) | 정확한 디자인 토큰, 실제 컴포넌트, 실제 카피, 아이콘 및 로고 파일. UI를 픽셀 단위로 Remotion 내부에 재구축하고 자유롭게 애니메이션할 수 있습니다. |
| 2. 실행 중인 앱 (URL 또는 로컬 빌드, 테스트 로그인 포함) | 실제 테마와 플로우, 브라우저에서 캡처. 정확하지만 요소별로 애니메이션하기는 어렵습니다. |
| 3. 화면 녹화 또는 스크린샷 | 최후의 수단. 가능한 한 가깝게 화면을 재구축하고 결과가 덜 정확할 것이라고 사용자에게 알립니다. |
코드베이스가 없다면 더 낮은 옵션을 선택하기 전에 요청하세요.
코드베이스에서 작업하기
- 테마: 프로젝트가 디자인 토큰을 보관하는 곳(CSS 사용자 정의 속성, Tailwind 설정, 테마 파일 또는 디자인 토큰 패키지 등)에서 읽어옵니다.
- 컴포넌트: 제품의 자체 UI 컴포넌트를 Remotion 컴포지션에서 앱 외부에서 깔끔하게 렌더링되는 경우 재사용합니다. 그렇지 않으면 소스에서 충실하게 재생성합니다.
- 콘텐츠: 실제 레이블, 빈 상태, 아이콘 및 로고 파일을 소스에서 가져와서 직접 만들지 마십시오. 계획에 필요한 데이터 상태를 위해 시드 또는 픽스처 데이터를 사용합니다.
- 읽기 전용. 제품의 코드베이스를 편집하지 마십시오. 자체 Remotion 프로젝트에서 필름을 제작합니다.
브랜딩
고정된 브랜드 색상을 사용하지 마십시오. 모든 색상은 표시되는 제품에서 가져옵니다.
- 제품의 핵심 UI를 읽고, 코드베이스가 있을 때는 거기서, 그렇지 않으면 라이브 UI에서 테마를 추출합니다: 기본/강조 색상, 중립 색상, 표면 색상, 테두리 색상, 타이포그래피, 모서리 반경 및 그림자 스타일.
- 배경: 사용자가 달리 지정하지 않는 한 기본적으로 오프화이트 배경을 선호합니다.
- 강조: 강조, 커서 링, 캐럿 및 하이라이트에 제품 자체 강조 색상을 사용합니다.
- 그라데이션은 배경, 텍스트, 글로우 또는 전환에서 사용자가 명시적으로 요청하지 않는 한 사용하지 마십시오. 단색 채움을 사용합니다.
- 타이포그래피: 가능하면 제품 자체 서체를 사용하여 캡션이 UI에 자연스럽게 느껴지도록 합니다.
- 로고 및 워드마크: 제품의 실제 자산을 사용하십시오. 다시 그리거나 근사하지 마십시오.
스크립트
스크립트는 캡션, 타이밍, 그리고 내레이션이 있는 경우 내레이션까지 모든 것을 결정합니다. 승인된 계획과 샷 리스트에서 작성하고, 장면을 만들기 전에 사용자의 승인을 받으십시오.
형식
스크립트를 표로 작성하십시오. 한 줄에 한 행:
| # | 대사 (말하기 또는 화면 표시) | 화면에 표시되는 내용 | 지속 시간 |
|---|---|---|---|
| 1 | 팀은 상태 업데이트에 일주일에 6시간을 잃습니다. | 혼잡한 작업 목록 위로 카운터가 6까지 올라감 | 3초 |
규칙
- 처음 7초 안에 후크를 넣으세요. 문제, 놀라운 숫자 또는 제품이 매력적인 일을 하는 것으로 시작하고 제품 이름으로 시작하지 마십시오.
- 모든 대사에는 그림이 있습니다. 대사에 일치하는 시각적 비트가 없으면 자르거나 다시 작성하십시오.
- 평이한 언어. 짧은 문장, 한 줄에 한 가지 아이디어, 시청자가 해독해야 하는 전문 용어 없음.
- 속도: 음성일 때 초당 약 2.5단어. 단어 수에서 대사의 지속 시간을 예산하십시오.
- 강조는
*별표*로 표시하고, 한 줄에 최대 하나의 핵심 구문. - 모든 주장은 사실입니다. 숫자와 벤치마크는 실제여야 하며 필요한 경우 각주를 달아야 합니다.
- 브리프에 설정된 길이를 준수하십시오. 모션 속도를 높이기 전에 대사를 다듬으십시오.
- 기본적으로 내레이션 없음. 내레이션이 없으면 스크립트는 화면 캡션으로만 표시됩니다.
사람처럼 들리게, 모델처럼 들리지 않게
모든 대사는 실제 사람이 동료에게 말할 법한 내용처럼 들려야 합니다. AI 같은 카피는 시청자가 흥미를 잃게 만들고 제품이 평범하게 느껴지게 합니다. 이것은 스타일 선호도가 아니라 엄격한 규칙입니다.
이렇게 작성하세요:
- 구체적으로 작성하세요. 제품의 실제 기능 이름, 실제 숫자 및 사용자가 실제로 수행하는 작업을 사용하십시오("작업을 금요일로 드래그", "워크플로우를 쉽게 관리"가 아님).
- 청중이 느끼는 구체적인 고통을 말하세요. 그들의 언어로("데일리 스크럼이 또 40분이나 걸렸어요").
- 축약형과 일상적인 단어를 사용하세요: "you'll", "it's", "doesn't".
- 형용사보다 동사를 선호하세요. 제품이 얼마나 좋은지 설명하는 대신 제품이 무엇을 하는지 보여주세요.
- 짧은 대사도 괜찮습니다. 구체적인 내용을 말할 때는 ("회의가 옮겨집니다."는 그림이 정확히 그것을 보여주기 때문에 효과적입니다).
절대 이렇게 작성하지 마세요:
| 패턴 | 예시 |
|---|---|
| 대비 프레이밍 | "X가 아니라 Y", "단순한 X가 아니라 Y입니다", "X도 아니고 Y도 아닌 Z", "X가 문제가 아닙니다. Y가 문제입니다." |
| 삼박자 리스트 | "더 빠르게, 더 똑똑하게, 더 좋게", "계획. 구축. 출시." 세 단어가 구체적인 내용을 말하지 않을 때 |
| 쌓인 형용사 조각 |
...
[번역을 위해 잘림]