SaaS 설명 영상 만드는 법: 7단계 워크플로

1. 게시 위치, 대상, 다음 행동을 각각 하나로 정하기

기능 목록으로 시작하지 마세요. 영상이 게재될 페이지나 channel부터 정하세요.

홈페이지 설명 영상은 보통 세 가지 질문에 빠르게 답해야 합니다.

• 누구를 위한 영상인가요?
• 제품이 어떤 문제를 이해하거나 처리하도록 돕나요?
• 시청 후 무엇을 하게 할 것인가요?

InvoiceFlow 테스트의 대상은 여러 도구에서 송장을 관리하는 freelancer였습니다. 이야기의 역할은 하나였습니다. 송장이 생성되고 결제 상태를 거쳐 월간 summary로 이동하는 과정을 보여 주는 것입니다. CTA는 “한곳에서 한 달을 확인하세요”로 고정했습니다.

이 경계는 영상이 모든 dashboard를 둘러보는 tour가 되는 것을 막아 줍니다. 동시에 acceptance test도 제공합니다. 시청자가 이 경로를 따라가는 데 도움이 되지 않는 scene은 이 버전에 들어갈 필요가 없습니다.

게시 위치는 pacing에도 영향을 줍니다. 홈페이지 영상은 제품 동작을 알아볼 수 있도록 몇 초를 남길 수 있습니다. paid social cut은 더 빠른 scene 전환이 필요할 수 있고, onboarding 영상은 정확한 control을 더 오래 보여 줄 수 있습니다. 목표 길이를 정하기 전에 게시 위치부터 선택하세요.

2. 단일 source-of-truth brief 만들기

source brief에서는 승인된 사실과 creative direction을 분리해야 합니다. 긴 설명형 prompt 하나보다 영상 시스템이 무엇을 설명할 수 있고 무엇을 만들어 내면 안 되는지 더 명확히 알려 줍니다.

SaaS 설명 영상에는 다음을 포함하세요.

• 시청자와 게시 위치.
• 승인된 제품 동작.
• 정확한 CTA.
• 계속 일치해야 하는 sample data.
• 표시되면 안 되는 주장, 값, interface label.
• format, 언어, voiceover, 대략적인 길이.

이번 테스트에서 승인한 제품 mechanism은 의도적으로 작게 제한했습니다.

freelancer가 한곳에서 송장 하나를 만들고 보냅니다. 결제가 들어오면 같은 송장이 하나의 ledger에 들어갑니다. 월간 summary에는 결제된 작업과 미결제 작업이 표시됩니다.

sample record도 Client A, INV-001, $1,200으로 고정했습니다. 이 세 값을 하나의 identity로 취급하는 것이 중요합니다. 뒤 scene에서 고객이나 송장 번호가 바뀌면 시청자는 더 이상 같은 record를 따라가지 못합니다.

이때 화면 문구 whitelist가 유용합니다. motion graphics에 표시해도 되는 단어와 값의 짧은 목록입니다. blacklist는 피해야 할 몇 가지만 알려 주지만 whitelist는 훨씬 명확한 경계를 설정합니다.

TapVid의 SaaS 설명 영상 제작 도구는 제공된 자료를 scene과 narration으로 구성할 수 있습니다. 이야기를 만들 수 있을 만큼의 제품 사실을 제공하되, 제품 팀이 답해야 할 빈칸까지 채우게 하지는 마세요.

3. 이야기를 화면에 보이는 상태 변화로 바꾸기

scene outline에는 narrator가 하는 말뿐 아니라 화면에서 무엇이 바뀌는지도 적어야 합니다.

InvoiceFlow 이야기는 다섯 beat를 사용했습니다.

각 행에 상태 변화가 있다는 점에 주목하세요. “dashboard를 보여 준다”만으로는 부족합니다. “결제가 도착하면 같은 송장을 Sent에서 Paid로 바꾼다”는 완성 영상에서 확인할 수 있습니다.

narration도 같은 범위로 좁혀야 합니다. 승인된 script의 중간 문장은 다음과 같았습니다.

한곳에서 송장을 만들고 보냅니다.

결제가 들어오면 하나의 ledger에 기록됩니다.

화면은 mechanism을 전달하고 voiceover는 시청자가 흐름을 따라가게 합니다. narration 한 문장에 제품 동작 세 개를 넣으면 scene은 작은 card 모음이 되기 쉽습니다.

4. render를 사용하기 전에 plan 검토하기

영상을 생성하기 전에 scene table과 script를 함께 살펴보세요. timing, 연속성, 근거 없는 표현, 텍스트 밀도를 확인해야 합니다.

이 pre-render checklist를 사용하세요.

• 각 scene에는 주요 idea가 하나뿐인가요?
• scene 전체에서 sample data가 동일한가요?
• 말로 한 각 주장을 뒷받침하는 화면 동작이 있나요?
• 할당된 초에 비해 너무 긴 문장이 있나요?
• CTA가 의역이 아니라 정확한 문구인가요?
• embed에서도 읽을 수 있도록 주요 interface가 16:9 화면에서 충분히 크게 보이나요?

이번 실행에서 처음 제안된 문제 narration은 6초 scene에 약 39단어였습니다. 보통 속도로 명확히 말할 수 없었습니다. 그래서 “송장과 결제 상태가 서로 다른 도구에 흩어질 수 있습니다”로 바꿨습니다.

마지막 narration도 정확한 CTA로 교체했습니다. 이 script 수정은 적용됐고 최종 transcript에는 승인된 다섯 문장이 올바른 순서로 들어갔습니다.

그렇다고 render까지 올바른 것은 아닙니다. script 승인과 영상 승인은 별도의 gate입니다.

5. 영상을 생성한 뒤 실제 cut 확인하기

생성된 cut은 1280×720, 30 fps, mono AAC audio였습니다. 측정 길이는 16.83초였습니다. narration 다섯 문장은 모두 있었지만 계획한 timing은 1.9~4.9초의 다섯 chapter로 압축됐습니다.

생성·전송 scene은 처음에는 깔끔해 보였습니다. 주요 card는 읽을 만큼 컸고 승인된 고객, 송장, 금액, button도 표시됐습니다.

자세히 보면 scene에는 Draft, field label, animation 초반의 $0.00 상태도 있습니다. 이는 화면 문구 whitelist 밖입니다. 전체 visual을 사용할 수 없다는 뜻은 아니지만 승인된 데이터 경계를 따르지 않았다는 뜻입니다.

더 심각한 연속성 실패는 다음 scene에 나타났습니다. ledger가 record를 Acme Corp와 #INV-2024-001로 바꿨습니다.

금액은 $1,200으로 같았지만 값 하나만 일치해서는 부족합니다. 시청자에게는 다른 송장으로 보입니다. 생성에서 전송, 결제까지 이어지는 인과 경로가 끊어졌습니다.

월간 summary에는 $0, FULLY SETTLED, NO OUTSTANDING이라는 승인되지 않은 결과도 추가됐습니다.

해롭지 않아 보이지만 이런 추가는 주장을 바꿉니다. “결제 및 미결제 작업을 보여 준다”는 미결제 작업이 없거나 모든 작업이 정산됐다는 사실을 증명하지 않습니다.

그래서 완성된 explainer는 매력적인 frame 모음이 아니라 sequence로 검토해야 합니다. 먼저 멈추지 않고 한 번 본 뒤 각 mechanism scene의 이름, 값, 상태 변화, transition을 정확히 확인하세요.

6. 약한 결과를 거절하고 render별 수정 지시 작성하기

결함이 있는 첫 번째 cut에 항상 “더 좋게 만들어 줘”라고 답하는 것이 올바르지는 않습니다. 그런 지시는 시스템이 script, style, data를 다시 바꿀 여지를 줍니다.

수정을 네 가지 lock으로 나누세요.

Timing lock. 각 scene에 고정 길이를 할당합니다. 다음 버전에는 6, 8, 8, 9, 4초, 총 35초를 요청했습니다. 마지막 4초는 CTA에 배정했습니다.

Identity lock. 표시할 수 있는 유일한 record를 Client A, INV-001, $1,200으로 명시합니다. 같은 행이 Sent에서 Paid로 이동하도록 요구합니다.

Visible-copy lock. 표시할 수 있는 단어와 값을 나열한 다음 실제 cut에서 발견한 잘못된 copy를 명시적으로 제거합니다. 관찰된 실패에 대응하므로 원래 brief를 반복하는 것보다 강한 지시입니다.

Composition lock. 읽을 수 있는 크기 목표를 설정합니다. 주요 interface가 frame의 55~70%를 차지하고 작은 floating card나 시선을 빼앗는 두 번째 record를 배치하지 않도록 요청했습니다.

유용한 pattern은 다음과 같습니다.

현재 transcript를 바꾸지 않는다. 같은 다섯 scene을 고정 길이로 다시 render한다. [client], [invoice], [amount] record 하나만 사용한다. 같은 record에서 [state A]가 [state B]로 바뀌는 것을 보여 준다. 승인된 [whitelist] 문구만 표시한다. 관찰된 오류 [actual incorrect labels and values]를 제거한다. 정확한 CTA를 [seconds]초 동안 유지한다.

CTA frame 자체는 선명했지만 chapter 길이가 1.9초뿐이어서 요청한 hold보다 짧았습니다.

마지막 frame이 좋아 보인다는 이유로 cut을 승인하지 마세요. 전체 경로가 정확하고 읽기 쉬울 때만 승인하세요.

다음 render는 수정본도 자체 acceptance check가 필요한 이유를 보여 줍니다. 수정된 cut은 송장 생성 scene에서 승인된 record를 유지하고 그 identity를 ledger까지 이어 갔습니다.

ledger도 두 번째 가상 고객으로 바꾸지 않고 같은 송장을 사용했습니다. 수정된 월간 summary에서는 승인된 record가 Paid work 아래에 나타났고, Outstanding work category도 임의의 합계나 “fully settled” 주장 없이 유지됐습니다.

의미 있는 개선입니다. visible-copy lock과 identity lock은 작동했지만 timing lock은 작동하지 않았습니다.

TapVid project chat은 6, 8, 8, 9, 4초 scene으로 총 35초를 만들었다고 설명했습니다. 그러나 download한 MP4는 16.833초였고 player에도 압축된 다섯 chapter가 남았습니다. checksum과 file size가 이전 render와 달랐으므로 새 file이지 오래된 download가 아닙니다. revision engine은 visual을 바꿨지만 요청한 pacing은 적용하지 않았습니다.

따라서 최신 버전은 revision evidence로는 유용하지만 최종 승인된 homepage explainer는 아닙니다. editor가 제약을 적용했다고 보고하더라도 publishable로 판단하기 전에 export 길이, chapter timing, 전체 재생을 확인하세요.

7. export한 뒤 실제 게시 위치에서 테스트하기

버전이 content review를 통과하면 export하고 실제 file을 검사하세요. editor label에만 의존하지 말고 길이와 resolution을 확인하세요.

publish 전에 다음을 확인하세요.

• aspect ratio가 게시 위치와 맞습니다.
• voiceover와 자막 내용이 같습니다.
• 자막이 동기화되고 주요 control을 가리지 않습니다.
• 실제 embed size에서 제품 label을 읽을 수 있습니다.
• 모든 scene에서 같은 sample data가 유지됩니다.
• CTA 문구가 정확하고 인식할 만큼 오래 표시됩니다.
• watermark, 자막, resolution 설정이 의도한 channel에 맞습니다.

녹화된 media의 accessibility를 위해 자막은 말한 정보를 나타내고 동기화되어야 합니다. W3C Web Accessibility Initiative 자막 가이드는 audio를 들을 수 없는 사람에게 자막이 하는 역할을 설명합니다.

마지막으로 영상이 실제로 놓일 page에서 재생하세요. 큰 editor에서 읽을 수 있는 scene도 homepage column이나 mobile viewport에서는 너무 작을 수 있습니다. interface가 읽기 어렵다면 composition을 단순화하거나 게시 위치 전용 cut을 만드세요.

재사용 가능한 SaaS explainer brief

다음 project에서 이 구조를 복사하세요.

승인된 source 자료 [paste or attach source]를 사용해 [specific audience]를 위한 [duration] [aspect ratio] SaaS explainer를 만든다. 시청자가 [one product path]를 이해하고 [CTA]를 실행하게 한다. 화면에는 [scene actions] 상태 변화를 보여 준다. [whitelist]의 sample 이름, 값, status만 사용한다. 주장, 합계, integration, outcome, customer data를 추가하지 않는다. render 전에 scene plan과 narration을 반환해 review를 받는다.

그다음 source brief, scene action, narration, 첫 render, 전체 재생, file metadata, 게시 위치 순서로 review하세요. 이 순서를 따르면 문제가 source, script, renderer 중 어디에서 생겼는지 더 쉽게 구분할 수 있습니다.

제품 copy나 script가 이미 있다면 TapVid의 AI 설명 영상 generator로 시작하고 review 중에는 source-of-truth brief를 project 옆에 두세요.

실제로 publish할 수 있는 SaaS 설명 영상 만드는 법

가장 안전한 workflow는 간단합니다. export file이 script와 같은 검사를 통과할 때까지 모든 생성 영상을 draft로 취급하세요. source brief는 제품 사실을 통제해야 하고 scene plan은 중요한 주장을 모두 화면에 보여 줘야 합니다. 최종 review에서는 실제 MP4의 identity, 상태 변화, timing, copy 가독성, 자막, CTA 문구를 확인해야 합니다.

이번 테스트는 시도 횟수보다 revision quality가 더 중요하다는 것도 보여 줍니다. 두 번째 render는 sample record를 수정하고 근거 없는 outcome label을 제거했지만 요청한 35초 timing plan은 여전히 무시했습니다. 따라서 모든 revision에는 완전한 artifact QA가 필요합니다.

SaaS explainer video creator를 사용한다면 승인된 source 자료와 정확한 제약을 제공하고 editorial approval은 사람이 맡으세요. 그래야 생성된 세부 내용이 우발적인 주장으로 바뀌지 않으면서 실제 제품을 설명할 수 있습니다.

자주 묻는 질문