쇼츠·릴스 로컬 자동화 제작기: 대본부터 아바타, 검수까지

영상 한 편 만드는 게 귀찮아서 시작했습니다. 소재를 정하고 대본을 쓰는 것까지는 괜찮았습니다. 그런데 녹음하고, 자료를 모으고, 컷을 나누고, 자막을 한 줄씩 맞추다 보면 반나절이 지나갔습니다. 계속 올려야 하는 콘텐츠를 이 방식으로 만들기는 어렵겠더군요.

그래서 2026년 7월부터 두 달 동안 대본을 넣으면 목소리·자막·화면·편집·기술 검사를 거쳐 세로 영상이 나오는 파이프라인을 만들었습니다. 제가 만든 시스템에 소재 URL과 제작 조건을 던지면, 자료 수집부터 대본·음성·화면·검수까지 순서대로 진행되고 릴스와 쇼츠 영상 파일이 나옵니다. 실제 결과와 이 구조를 만들면서 겪은 실패를 함께 보여드리겠습니다.

먼저 결과부터: 같은 소재로 릴스와 쇼츠 두 벌

Octop 소개 영상

첫 번째 소재는 TencentCloud의 Octop 저장소와 Octop 소개 페이지입니다. 제품 설명과 화면 자료를 모아 대본으로 만들고, 아바타를 포함한 두 버전을 출력했습니다.

Octop 릴스 버전 보기

Octop 쇼츠 버전 보기

YouTube 원본: Octop 릴스 · Octop 쇼츠

두 영상은 본편을 공유하고 마지막 행동 유도 문구를 다르게 만듭니다. 비교할 때는 초반 훅, 아바타의 위치, 마지막 멘트가 어떻게 달라지는지 보시면 됩니다.

제가 만든 시스템에는 이렇게 요청합니다

아래는 제가 구축한 영상 자동화 시스템에 실제로 넣은 제작 요청입니다. 소재 URL 두 개와 아바타 사용 여부, 릴스·쇼츠 두 벌을 만들어 달라는 조건을 주면 시스템이 작업을 시작합니다. 제가 편집 단계를 하나씩 지시하지 않아도, 미리 연결해 둔 스킬과 실행 절차가 자료 수집 → 대본 선택 → 음성 합성 → 화면 구성 → 렌더와 검수까지 이어갑니다.

https://github.com/TencentCloud/Octop
https://octop.cloud/#why (여기선 브라우저 돌면서 쓸만한 어셋 수집)
로 릴스·쇼츠 2벌 만들어줘. 아바타 on, production.
대본은 reel-script-shapes top-1 추천안을 네가 골라 확정하고, CTA 키워드도 한글로 네가 정해.
묻지 말고 끝까지 가서 마스터 2벌 + 컨택트 시트 + REPORT 로 보고해.
난 자러가야해.
낼 이거 만든거 시연이 있어

이 요청에서 reel-script-shapes는 소재에 맞는 대본 구조를 고르는 제 스킬이고, production은 검토용이 아닌 최종 제작 모드입니다. 마스터 2벌은 릴스와 쇼츠 파일, 컨택트 시트는 여러 장면을 한눈에 보는 이미지, REPORT는 제작 결과와 검사 상태를 정리한 보고서입니다. 즉, 위 프롬프트는 이미 만들어 둔 시스템을 실행시키는 주문서입니다. 이 요청으로 만들어진 영상이 바로 위의 Octop 예시입니다.

제작을 맡겨두고 자리를 비울 수 있도록 대본 선택과 CTA 문구 결정도 함께 위임했습니다. 결과 파일이 나오면 마지막에는 제가 직접 보고 듣고 게시 여부를 판단합니다.

lean-deck 소개 영상과 썸네일

두 번째 소재는 lean-deck 저장소입니다. 다른 소재를 넣어도 같은 제작 순서를 타도록 구성했습니다.

lean-deck 릴스 버전 보기

lean-deck 쇼츠 버전 보기

YouTube 원본: lean-deck 릴스 · lean-deck 쇼츠

썸네일은 매번 새 그림을 생성하는 대신 정해진 템플릿에 대본의 핵심 표현과 자료를 넣습니다. 로고는 로고 모음, 아이콘은 아이콘 모음도 참고했습니다. 자료를 찾는 경로와 실제 사용 권한은 별개이므로, 최종 제작에는 사용 가능한 어셋을 골라 넣습니다.

‘no API, 로컬’은 어디까지인가

제가 말하는 ‘편당 미디어 비용 0원’은 로컬에서 미디어를 한 번 더 생성할 때 외부 생성 서비스에 지불하는 호출 요금이 없다는 뜻입니다. 장비 구입비, 전기료, 작업 시간까지 0원이라는 뜻은 아닙니다.

Claude Code와 Codex는 작업 순서를 판단하고 코드를 작성하는 개발 도구입니다. 저는 구독으로 사용했고, 구독에는 사용량 한도가 있습니다. 따라서 무제한 제작이나 완전한 오프라인 작업을 뜻하지도 않습니다. 웹에서 소재를 수집하거나 개발 도구에 내용을 전달하는 단계와, 로컬에서 미디어를 만드는 단계를 구분해야 합니다.

이미지 생성용 외부 서비스 Higgsfield를 연결할 자리도 열어두었지만, 꺼도 영상이 완성됩니다. 다른 사람에게 전달하려고 준비한 구성에서는 이 외부 이미지 생성 경로를 껐습니다. 로컬 실행 가능 여부와 도구·모델의 이용 조건은 별개입니다. 도입할 때는 각 프로젝트의 공식 안내를 확인해야 합니다.

수치가 나온 장비와 실험 범위

CPU는 AMD Ryzen 9 9950X, RAM은 DDR5-5600 64GB, GPU는 RTX 5090 32GB입니다. 아래 속도와 오류 사례는 이 장비와 당시 설정에서 제가 기록한 값입니다. 같은 GPU라도 해상도, 모델 설정, 영상 길이에 따라 시간이 달라집니다.

개발 기간은 2026년 7월 19일부터 9월 20일까지입니다. 그동안 커밋 274개, 영상 프로젝트 87개, 완성 마스터 테스트 영상 54편, 스킬 40종, 자동 검사 32개가 쌓였습니다. 운영 성과나 고객 전환 수치가 아니라 제 개발 기록의 집계입니다.

전체 흐름: 대본에서 마스터 파일까지

소재 URL·자료
  → 대본 후보 작성과 선택
  → 발음용 대본 확정
  → 음성 합성
  → 자막 타이밍 추출
  → 화면·모션 구성
  → 아바타 생성 (선택)
  → 검토용 렌더와 기술 검사
  → 사람이 직접 보고 듣기
  → 릴스·쇼츠 최종 마스터 2벌

씬은 영상의 한 장면이고, 렌더는 코드와 자료를 실제 영상 파일로 만드는 과정입니다. 게이트는 ‘통과하거나 멈추게 하는 자동 검사’입니다. 이 세 단어를 구분하면 아래 과정이 훨씬 읽기 쉽습니다.

1. 대본: 여러 후보를 만들되 내용은 사람이 고른다

처음 정한 원칙은 대본을 사람이 쓴다는 것이었습니다. 다만 개발 중에는 소재를 넣으면 구조가 다른 후보 세 개를 만들고, 그중 하나를 선택하는 방식도 실험했습니다. 앞의 원샷 요청처럼 테스트를 끝까지 돌릴 때는 AI에게 선택까지 맡기기도 했습니다.

제가 원하는 최종 운영 방식은 사람이 후보를 비교하고 고쳐 쓰는 쪽입니다. 백지에서 시작하는 수고는 줄이되, 무엇을 말할지에 대한 판단까지 놓지는 않으려 합니다.

영상 레퍼런스를 단순히 링크로 모으지 않고, 어떤 문장으로 시작하고 어떤 순서로 설명하며 어떻게 끝내는지 구조로 나눴습니다. 아래 DB는 적용 분야와 타깃층도 함께 정리해 소재에 맞는 구조를 고를 때 참고하는 자료입니다.

대본 구조를 스킬에서 활용하기 쉽게 만들기 위해, 수집한 텍스트를 CSV로 정리했습니다. 화면 왼쪽에는 이미지의 7개 열을 유지하고 줄바꿈과 한글 인코딩을 처리한 과정이, 오른쪽에는 변환된 표가 보입니다.

대본 구조를 자료로 모아두고 스킬에서 참고하게 만들었습니다. 여기서 스킬은 AI가 작업할 때 읽는 지침과 실행 절차입니다. 좋은 문서를 많이 쌓아두는 것만으로는 부족했고, 실제 대본을 만드는 단계에서 그 지침을 읽도록 연결해야 했습니다.

2. 목소리: 합성보다 한국어 읽기를 먼저 고친다

대본이 정해지면 Fish Speech로 제 목소리를 합성합니다. 제로샷 보이스클론은 참조 녹음을 넣어 별도 개인화 학습 없이 목소리를 재현하는 방식입니다. 구체적인 음성 비교는 오픈소스 TTS 보이스클론 실측 글에 따로 정리해 두었습니다.

GPU를 쓰지 않는 경로에는 Supertonic을 넣었습니다. 당시 사용한 구성은 내장 목소리를 고르는 방식이었고, 제 장비에서 실시간의 약 9~12배 속도로 합성됐습니다. 30초 분량이면 몇 초 안에 목소리가 나오는 셈입니다. 이것은 해당 실험 구성의 기록이며 모든 버전과 PC에 적용되는 성능 보장은 아닙니다.

막상 영상을 들어보니 속도보다 더 거슬리는 문제가 있었습니다. 4장을 ‘네 장’이 아니라 ‘사 장’이라고 읽었습니다.

TTS 발음 실패 예시: 19초 부근 듣기

처음에는 숫자의 크기와 단위를 묶은 규칙표로 해결하려고 했습니다. 그런데 개수를 세는지, 번호를 말하는지에 따라 읽기가 달랐습니다. 제가 만든 단순 규칙으로는 놓치는 경우가 생겼습니다.

그래서 화면에 보여줄 표기와 음성 합성에 넣을 표기를 분리했습니다. 문맥을 보고 확정한 읽기는 사전에 저장하고, 미등록 숫자나 영문이 남아 있으면 합성 단계에서 멈추도록 했습니다. 아래는 원리를 설명하기 위해 이 글에서 정리한 예시이며, 실제 프로젝트 파일 형식을 그대로 공개한 것은 아닙니다.

{
  "display": "카드 4장으로 41개 항목을 정리합니다.",
  "spoken": "카드 네 장으로 마흔한 개 항목을 정리합니다."
}

실제로 쓰고 있는 읽기 사전에서 숫자 부분만 그대로 옮기면 다음과 같습니다. 파일 머리 주석에 이 사전을 만든 이유도 남아 있습니다.

# `4장` 이 "사 장" 으로 읽혔다. 사전은 영문 브랜드명만 다루고 숫자는 범위 밖
# 이어서 아라비아 숫자가 그대로 FishSpeech 에 들어갔고, 샘플링 모델이 매번 읽기를
# 새로 골랐다 — "잘 읽을 때도 있고 못할 때도 있던" 이유가 이것이다.

tts_pronunciation:
  # ── 숫자 + 계수사 · 오너 확정 (2026-07-30) ──
  "4장": 네 장
  "12주": 열두 주
  "24개": 스물네 개
  "41개": 마흔한 개
  "208번": 이백팔 번
  # ── 에이전트 판정 (오너 선례에 맞춤) ──
  "100자": 백 자
  "13,808개": 만 삼천팔백팔 개
  # ── 제품명·약어 ──
  "Audio8": 오디오에잇
  "0.6B": 영 점 육 비
  "CPU": 씨피유

41개는 마흔한 개(고유어)인데 208번은 이백팔 번(한자어)입니다. 둘 다 "20 이상 + 계수사"인데 읽는 법이 반대라서 규칙표로는 못 맞춘다는 판단이 이 파일의 출발점이었습니다. 그래서 읽기는 에이전트가 문맥을 보고 정하고, 정한 결과를 여기 쌓아서 다음 편에서 같은 표기를 다시 판정하지 않게 했습니다. 사전은 공용(1,151항목) → 저장소(20항목) → 편별 순서로 겹쳐 적용됩니다.

사전을 거친 대본이 실제로 어떻게 바뀌어 합성되는지는 합성 로그에 남습니다. 49초짜리 시험 편의 로그 앞부분입니다.

dict[공용] 1151항목  .../config/presets/student/tts_dictionary.yaml
dict[저장소] 20항목  .../config/tts_readings.yaml
dict[워크스페이스] 1항목  .../audio/tts_dict.yaml
beats=9
beat 001  5.50s  전 세계 개발자들이 지금 이 무료 AI 비서에 미쳐 있습니다.
beat 002  7.04s  이름은 OpenClaw, 구 개월 만에 GitHub 스타 삼십팔만 개를 넘긴 오픈소스입니다.
beat 003  8.43s  설치는 명령 한 줄이면 끝나고, WhatsApp, Telegram, Slack, 쓰던 메신저로 비서가 들어옵니다.
...
beat 007  6.41s  와인 셀러 관리 스킬은 채팅으로 부탁하니 삼십 분 만에 만들어 냈습니다.
{"speed": 1.08, "total_syl": 210, "raw_duration": 53.22, "duration": 49.331}

화면 자막에는 "9개월", "38만"으로 나가는 숫자가 합성기에는 "구 개월", "삼십팔만 개"로 들어갔습니다. 마지막 줄은 9개 문장을 붙인 원래 길이가 53.22초였고, 1.08배 속도로 맞춰 49.331초가 됐다는 기록입니다. 문장(beat)별 길이가 남기 때문에 자막과 장면 길이를 이 숫자에 맞춰 자동으로 자릅니다.

같은 문제를 직접 확인해 보려면 한국어 TTS 발음용 대본 실습을 읽어보셔도 좋습니다. 함께 제작했던 한국어 TTS 비교 영상과 보이스클론 비교 영상도 남깁니다.

3. 자막: 대본을 아는데 왜 다시 전사할까

Whisper로 합성된 음성을 다시 받아 적습니다. 필요한 것은 새 대본이 아니라 어느 단어가 언제 들리는지입니다. 글만으로는 실제 발화 시각을 정확히 알 수 없기 때문에, 음성에서 얻은 타이밍에 자막을 맞춥니다.

GPU 없는 경로에서는 실측한 문장 경계 안에서 글자 수에 비례해 시간을 나눴습니다. 제 테스트에서는 약 0.15초 수준의 오차를 기록했지만, 발화 속도나 쉬는 구간에 따라 달라질 수 있습니다. 빠른 단어 강조까지 같은 정확도가 나온다고 보지는 않습니다.

목소리를 바꾸면 길이도 바뀝니다. 그래서 ‘F2 목소리로 다시 합성해 줘’로 끝내지 않고 씬 길이와 자막 시각도 함께 갱신하도록 했습니다. 이 연결을 빼먹으면 음성만 바뀌고 자막은 이전 영상의 박자를 따라갑니다.

4. 화면: 매번 생성하는 대신 고칠 수 있게 그린다

릴스의 뼈대는 Remotion 코드입니다. 실제 스크린샷, 카드, 도형, 타이포그래피를 시간에 맞춰 배치합니다. 이미지·영상 생성도 선택적으로 쓰지만, 모든 장면을 새로 생성해 이어 붙이는 구조는 아닙니다.

제가 코드로 화면을 만든 이유는 수정 때문입니다. ‘저 글자를 8픽셀 내려줘’처럼 위치를 지정할 수 있고, 같은 자료와 설정으로 다시 렌더할 수 있습니다. 이런 작은 수정이 자동화에 잘 맞았습니다.

초기에는 설명을 눈에 띄게 만들려고 강조 그래픽을 덧붙였습니다. 아래 메일 화면에서는 사각형과 커서가 줄지어 나타나고, 다음 장면에서는 탐색기와 문서 사이에 선이 떠 있습니다. 효과는 움직이지만, 시청자가 어디를 왜 봐야 하는지는 분명하지 않았습니다.

처음에는 제 영상이 너무 많이 움직여서 산만한 줄 알았습니다. 그런데 레퍼런스와 프레임을 비교하니 반대였습니다.

이 수치는 제가 당시 표본 영상을 비교한 기록입니다. 이벤트 정의와 원시 측정 로그를 이 글에서 제공하는 것은 아니므로, 모든 영상에 적용할 제작 기준으로 쓰지는 않습니다.

레퍼런스는 더 많이 움직이는데도 편안했습니다. 제가 찾은 원인은 컷마다 화면 구성을 새로 짜는 습관이었습니다. 틀을 고정하고 그 안의 내용만 바꾸자 시선이 덜 헤맸습니다. 비교한 레퍼런스에서는 자막 전환이 48회, 컷 전환이 19회였는데, 이 경험 이후로 컷 수보다 자막의 박자를 더 보게 됐습니다.

강조 영역 정렬 실패 영상 보기

5. 아바타: 로컬로 옮기고 GPU 작업 순서를 나눈다

립싱크 아바타는 가장 오래 헤맨 부분입니다. 처음에는 유료 API를 쓰다가 최종적으로 InfiniteTalk을 ComfyUI에서 실행하도록 옮겼습니다. 공식 저장소에도 이미지·음성 기반 생성과 ComfyUI 연결 경로가 안내되어 있습니다.

당시 이용한 API에서는 한 편의 아바타 분량에 약 0.6~0.8달러가 들었습니다. 현재 가격표가 아니라 당시 제 사용 기록입니다. 로컬에서는 호출 요금이 없어졌지만, RTX 5090에서 30초 분량의 아바타 생성에 약 25분이 걸렸습니다. 전체 영상 제작 시간과는 별도입니다.

WaveSpeed의 아바타 립싱크 목록에서 InfiniteTalk, video-to-video, fast 항목을 비교한 화면입니다. 같은 아바타 작업도 사진에서 시작하는지, 기존 영상을 바꾸는지에 따라 입력과 용도가 달라집니다. 저는 이런 서비스 경로를 살펴본 뒤 로컬 InfiniteTalk 실행으로 옮겼습니다. 화면의 가격은 캡처 당시 표시입니다.

로컬로 옮기면서 세 가지를 고쳤습니다.

1. 입력 오디오를 미리 저음질로 만들지 않았습니다. 낮아진 품질이 최종 결과에 남을 수 있어 원본 음질을 유지했습니다.
2. 오디오 길이에 맞춰 영상 길이를 정리했습니다. 이 설정을 놓쳤을 때 5초 음성에 6.12초 영상이 나왔습니다.
3. 음성 합성과 아바타 생성을 순서대로 실행했습니다. 제 구성에서는 동시에 돌리자 GPU 메모리 경쟁이 생기고 스텝당 65초까지 느려지는 경우가 있었습니다.

GPU 작업은 하나를 끝내고 메모리를 정리한 다음 다른 작업을 시작하는 쪽이 안정적이었습니다. 모든 하드웨어에 병렬 실행이 나쁘다는 뜻은 아니고, 제가 사용한 모델 조합에서 확인한 병목입니다.

아바타와 마무리 문구의 기술적 실패 예시 보기

6. 자동 검사 32개가 통과해도 직접 봐야 한다

자동으로 파일이 나오는 것보다 어려운 일은, 나온 영상을 올릴 만하게 만드는 일이었습니다. 눈으로 발견한 문제를 다음 실행에서 자동으로 잡도록 옮겼습니다.

음량 목표는 제 제작 기준입니다. 모든 플랫폼의 필수 규격이라는 의미는 아닙니다. 검사도 많을수록 무조건 좋지는 않았습니다. 32개까지 늘린 뒤에는 과하게 반려하는 조건을 찾아 줄이는 작업을 하고 있습니다.

한 번은 검사 12개가 모두 통과한 영상을 보고도 바로 반려했습니다. 파일은 깨지지 않았지만 화면은 마음에 들지 않았습니다. 그래서 완료 판정을 네 가지로 나눴습니다.

이 네 가지를 한꺼번에 ‘PASS’라고 보고하면 문제가 가려집니다. 기계 검사 통과는 좋은 출발점이지만, 게시할 만한 영상이라는 보증은 아닙니다.

실제로 같은 49초 시험 편을 렌더했을 때 끝에 찍힌 검사 결과입니다. 파일은 정상으로 나왔는데 검사 하나가 실패로 막았습니다.

DONE renders/smoke.mp4 (49.33s single pass + supplied audio mux)
[post-gates] PASS scene_event_gate --map
[post-gates] FAIL scene_event_gate --render
    FAIL undeclared still 41.417-42.500s (1.083s) is outside declared holds
[post-gates] PASS stage_rotation_check
    WARN scene cuts 3.04/10s clear the rejection floor but sit below every design band (>= 3.6)
[post-gates] FAIL — 렌더 파일은 남겼습니다. 위 처방대로 맵·씬을 고치고 다시 렌더합니다.

41.4초부터 1.08초 동안 화면이 멈춰 있었는데, 설계에 "여기서 멈춘다"고 선언하지 않은 정지라서 실패입니다. 두 번째 경고는 10초당 장면 전환이 3.04회로, 반려 기준은 넘었지만 디자인 목표(3.6회 이상)에는 못 미친다는 뜻입니다. 사람이 보면 "좀 심심하다"고 느낄 부분을 숫자로 먼저 알려주는 장치입니다.

위 요청은 영상 한 편을 다시 고치라는 말에서 멈추지 않습니다. 검수 중 수정했던 부분에서 재발 가능한 문제를 찾고, 어떤 스킬을 어떻게 바꾸면 좋을지 보고서로 정리한 뒤 다음 세션에서 이어받을 프롬프트까지 작성하게 했습니다.

잘 나온 편도 그대로 끝내지 않았습니다. 어떤 지침이 작동했고 어디서 불필요한 수정이 생겼는지 별도로 점검했습니다. 문서에 규칙을 더 쓰는 것보다, 실행 단계에 검사를 붙이고 실패 메시지에 수정 방법을 넣는 편이 효과가 있었습니다.

7. 렌더: 검토본과 최종본을 구분한다

최종 출력은 1080×1920, 60fps 세로 영상입니다. 기본 모드는 테스트로 두고, 절반 해상도로 먼저 검토합니다. 최종 마스터는 제작 모드를 명시했을 때만 나오게 했습니다. 예전에 검토용 저해상도 영상을 잘못 올린 경험을 구조로 막은 것입니다.

49초짜리 영상에 대해 제가 남긴 단계별 기록은 다음과 같습니다.

당시 메모에는 합계 32.6초라고 적었지만, 위 값을 단순 합산하면 38.9초입니다. 이번에 원본 기록을 찾아 확인했습니다. 32.6초는 시험 편을 재현 검사의 기준값으로 기록한 아래 파일(expected.json)의 합계였고, 위 표는 같은 실행의 값이 아니었습니다.

"measured_on": {
  "date": "2026-09-02",
  "platform": "Windows-11-10.0.26200-SP0",
  "cpu": "AMD Ryzen 9 9950X 16-Core Processor (32 threads)",
  "supertonic_voice": "M1",
  "asr": { "use": "off" }
},
"wall_s": {
  "tts": 7.5,
  "words": 0.7,
  "render": 23.5,
  "qa_render": 0.6,
  "total": 32.6
}

목소리 합성 7.5초, 단어 타이밍 0.7초, 절반 해상도 렌더 23.5초, 렌더 검사 0.6초입니다(단계 합 32.3초에 나머지 0.3초는 단계 사이 시간). 조건은 GPU 없이 CPU(9950X)로, 음성 전사(ASR)를 끈 49.33초 검토본입니다. 이 숫자는 같은 PC에서 다시 돌렸을 때 크게 벗어나는지 확인하는 기준값이라, ‘33초 만에 완성’이라는 결론으로는 쓰지 않습니다.

더구나 이 기록은 아바타를 포함한 최종 제작 전체 시간이 아닙니다. 소재 수집, 대본 결정, 재생성, 사람의 검수를 포함하면 두 시간 이상 걸린 작업도 있었습니다. 제가 줄인 것은 반복 편집의 수고이며, 모든 과정이 수십 초 안에 끝난다는 뜻은 아닙니다.

GPU 없이도 어디까지 할 수 있나

GPU가 없는 구성에서는 Supertonic으로 목소리를 만들고, 문장 경계 기반으로 자막 시각을 추정하며, 스크린샷과 코드 그래픽을 렌더하도록 했습니다. 아바타와 생성 영상은 끄고도 한 편을 완주하게 하는 것이 목표였습니다.

다만 이 글이 모든 PC에서 동작을 검증한 설치 패키지를 제공하는 것은 아닙니다. 배포판을 다듬는 일은 후속 작업입니다. 필요한 운영체제와 실행 환경, 개발 도구 사용량까지 별도로 점검해야 합니다.

처음 재현한다면 저는 범위를 이렇게 자르겠습니다. 아래 순서는 이 글을 위해 정리한 시작 제안입니다.

1. 짧은 대본 하나와 사용할 스크린샷을 고릅니다.
2. 발음용 문장을 확정하고 음성만 먼저 들어봅니다.
3. 아바타 없이 자막과 화면을 붙여 검토본을 만듭니다.
4. 잘린 글자, 음성 끝점, 사실관계를 확인합니다.
5. 직접 재생해 본 뒤 최종 해상도로 출력합니다.
6. 이 흐름이 안정되면 아바타와 플랫폼별 마무리를 추가합니다.

남은 일: 자동 업로드와 운영 성과는 다음 단계

지금까지 자동화한 범위는 영상 파일, 제목, 설명, 해시태그, 커버 이미지까지입니다. 플랫폼 업로드까지 완료되는 시스템으로 소개하는 것은 아직 이릅니다. 업로드 연결은 다음 개발 단계로 남겨두었습니다.

본래 목적이었던 리드 수집도 실제로 운영하며 확인해야 합니다. 영상을 54편 테스트했다는 기록이 조회수나 고객 전환을 증명하지는 않습니다. 어떤 소재와 훅이 사람들의 반응으로 이어지는지 따로 측정할 계획입니다.

개발 도구의 컨텍스트도 병목이었습니다. 한 번 돌릴 때 사용량이 80% 이상까지 올라간 사례가 있어, 중복 검수와 불필요한 지침을 줄이려 합니다. 화면에 보이는 사용량은 해당 세션의 기록이며 모든 작업의 평균은 아닙니다.

두 달 동안 바뀐 생각

처음에는 영상 제작을 전부 맡기면 편해질 줄 알았습니다. 실제로 도움이 된 것은 맡길 수 있는 일을 더 잘 나누는 것이었습니다. 대본의 뜻과 마지막 품질은 제가 보고, 반복되는 합성·배치·검사는 프로그램이 맡습니다.

이 구조는 보고서나 뉴스레터에도 적용할 수 있습니다. 숫자의 출처, 빈 페이지, 잘린 글자처럼 반복해서 발견하는 문제부터 검사로 옮기는 겁니다. 전체 흐름을 처음 설계하는 분이라면 1인 업무 자동화 로드맵도 함께 보시면 좋겠습니다.

다음 목표는 더 많은 기능을 붙이는 것보다, 제가 자리를 비운 사이에도 어떤 단계에서 멈췄고 무엇을 고쳐야 하는지 알 수 있게 만드는 것입니다. 영상이 나왔다는 보고보다, 직접 재생했을 때 납득할 수 있는 결과가 더 중요했습니다.

사용 도구의 공식 문서

미디어 생성 도구의 공식 안내는 Fish Speech, Supertonic, Whisper, InfiniteTalk, MiniMax H3 모델 카드, Remotion 문서에서 확인할 수 있습니다. 모델과 실행 환경은 달라질 수 있으므로, 이 글의 당시 설정과 최신 안내를 구분해 보시면 됩니다.