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

01

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

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

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

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

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

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

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

02

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 설명 영상 제작 도구는 제공된 자료를 장면과 내레이션으로 구성할 수 있습니다. 이야기를 만들기에 충분한 제품 정보를 제공하되, 제품 팀이 답해야 할 빈칸까지 채우도록 맡기지는 마세요.

03

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

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

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

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

내레이션도 같은 범위 안에서 간결하게 유지해야 합니다. 승인된 대본의 중간 문장은 다음과 같았습니다:

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

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

화면은 작동 원리를 보여 주고, 보이스오버는 시청자가 흐름을 놓치지 않도록 이끕니다. 내레이션 한 문장에 제품 동작 3개를 넣으면 장면은 작은 카드 모음처럼 보이기 쉽습니다.

04

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

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

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

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

이번 실행에서 처음 제안된 문제 제기용 내레이션은 6초짜리 장면에 약 39단어가 들어 있었습니다. 보통 속도로는 명확하게 말할 수 없는 분량이었습니다. 그래서 다음 문장으로 바꿨습니다. 송장과 결제 상태가 서로 다른 도구에 흩어질 수 있습니다.

마무리 내레이션도 정확한 CTA 문구로 교체했습니다. 이러한 대본 수정은 제대로 반영됐고, 최종 대화록에는 승인된 5개 문장이 올바른 순서로 모두 들어갔습니다.

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

05

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

생성된 영상은 1280×720 해상도, 30 fps, 모노 AAC 오디오였으며, 측정된 길이는 16.83초였습니다. 내레이션 5개 문장은 모두 들어갔지만, 계획한 타이밍은 각각 1.9~4.9초인 5개 챕터로 압축되었습니다.

생성·전송 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을 정확히 확인하세요.

06

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를 반복하는 것보다 강한 지시입니다.

구성 잠금. 읽기 쉬운 크기 목표를 설정하십시오. 우리는 기본 인터페이스가 프레임의 55%에서 70%를 차지하도록 요청했으며, 작은 떠다니는 카드와 주목을 두고 경쟁하는 두 번째 레코드가 없도록 했습니다.

유용한 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, 전체 재생을 확인하세요.

07

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을 만드세요.

08

재사용 가능한 SaaS explainer brief

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

이 승인된 원본 자료를 사용해 [특정 시청자]를 위한 [길이] [화면비] SaaS 설명 영상을 만드세요: [원본 붙여넣기 또는 첨부]. 시청자는 [하나의 제품 사용 경로]를 이해하고 [CTA]를 실행해야 합니다. 화면에 다음 상태 변화를 보여 주세요: [장면 동작]. 다음 샘플 이름, 값, 상태만 사용하세요: [허용 목록]. 주장, 합계, 연동, 결과 또는 고객 데이터를 추가하지 마세요. 렌더링 전에 검토할 수 있도록 장면 계획과 내레이션을 반환하세요.

그다음 원본 브리프, 장면 동작, 내레이션, 첫 렌더링 결과, 전체 재생, 파일 메타데이터, 게시 위치 순서로 검토하세요. 이 순서로 보면 문제가 원본, 대본, 렌더러 중 어디에서 생겼는지 더 쉽게 구분할 수 있습니다.

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

09

실제로 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은 사람이 맡으세요. 그래야 생성된 세부 내용이 우발적인 주장으로 바뀌지 않으면서 실제 제품을 설명할 수 있습니다.

10

자주 묻는 질문