클로드 코드와 로컬 AI로 만드는 0원짜리 영상 (2) — 원고 한 편이 영상이 되기까지

1편에서는 준비물과 비용을 봤습니다. 이번 편은 실제 순서입니다. 블로그 글 한 편을 골라서 완성된 유튜브 영상이 나올 때까지, 손을 어떻게 움직이는지를 씁니다.

먼저 결론부터 말씀드리면, 이 파이프라인의 핵심은 기술이 아니라 "새로 만들지 않는 것"입니다. 대본은 이미 쓴 블로그 글에서 나오고, 이미지의 3분의 2는 이미 만들어 둔 것이고, 클립과 배경음악은 라이브러리에서 꺼냅니다. 실제로 새로 생성하는 건 전체의 3분의 1도 안 됩니다.

이번 편에서 만드는 것

목표물은 이렇습니다. 5~10분 길이 · 두 사람이 대화하는 인터뷰형 나레이션 · 24개 안팎의 장면 · 번인 자막 · 배경음악 · 챕터. 여기에 세로 쇼츠 한 편이 세트로 붙습니다.

총 소요는 편당 35~45분이고, 그중 사람이 실제로 판단해야 하는 건 대본 검토와 이미지 검수 두 번뿐입니다. 나머지는 대기 시간입니다.

전체 흐름 한눈에

순서를 먼저 통째로 보여드립니다. 뒤에서 하나씩 풀겠습니다.

1. 원본 고르기 — 아직 영상으로 안 만든 블로그 글 찾기
2. 원문 수집 — 본문 텍스트 + 원문 이미지 내려받기
3. 자산 계획 — 섹션 수로 장면·이미지·클립 개수 확정
4. 대본 작성 — 블로그 글을 인터뷰 대화로 각색
5. 음성 합성 — 라인마다 TTS
6. 음성 검증 — 받아쓰기로 잘림 잡기
7. 이미지 — 모자란 것만 생성 → 검수
8. 클립·배경음악 — 라이브러리에서 꺼내기
9. 조립 — ffmpeg
10. 쇼츠 + 업로드

① 왜 블로그 글이 먼저인가

여기가 이 파이프라인에서 제일 중요한 설계 결정입니다. 영상 대본을 백지에서 쓰지 않습니다. 이미 발행한 블로그 글을 원본으로 씁니다.

이유가 셋입니다.

• 사실 확인이 이미 끝나 있습니다. 출처를 다시 찾을 필요가 없습니다.
• 구조가 이미 잡혀 있습니다. 소제목(h2) 하나가 장면 하나가 됩니다.
• 🔴 이미지가 이미 있습니다. 블로그를 발행할 때 2섹션당 1장을 만들어 뒀고, 규격이 영상과 같습니다.

영상부터 만들려는 분들이 많은데, 글을 먼저 쓰는 쪽이 결과적으로 훨씬 빠릅니다. 글은 고치기 쉽고 영상은 고치기 어렵기 때문입니다.

② 자산 비율 — 섹션 수가 모든 걸 정한다

기준 단위는 원문의 소제목(h2) 개수입니다. 여기서 나머지가 전부 자동으로 결정됩니다.

24섹션짜리 글이면 이미지는 여섯 장만 새로 만들면 됩니다. 장당 10초니까 1분입니다. 이 표 하나가 제작 시간의 대부분을 설명합니다.

🔴 클립이 들어가는 장면에는 이미지를 만들지 않습니다. 클립이 그 자리를 덮으니 만들어 봐야 버려집니다.

③ 대본 분량 — 초당 6.4자

대본을 쓰기 전에 글자 수부터 정합니다. 안 그러면 매번 길이가 어긋나 다시 자르게 됩니다.

실측 공식은 이렇습니다.

목표 글자 수 = 목표 분 × 60 × 6.4

• 5분 → 약 1,900자
• 8분 → 약 3,100자
• 13분 → 약 5,000자

실측 근거는 이렇습니다 — 6,303자가 983.6초(6.41자/초), 5,906자가 912.7초(6.47자/초), 4,576자가 약 735초(6.23자/초)로 나왔습니다.

⚠ "초당 8자"로 계산하면 매번 25~30% 넘칩니다. 초당 8자는 말하는 구간만 잰 값이라 라인 사이의 침묵이 빠져 있습니다. 저희도 세 편 연속으로 이걸 밟고 나서야 6.4로 고쳤습니다.

④ 왜 인터뷰 형식인가

혼자 읽는 나레이션이 아니라 진행자와 답변자 두 사람의 대화로 만듭니다. 이유는 취향이 아니라 기술적인 것입니다.

• 목소리가 바뀌면 지루함이 줄어듭니다. 10분을 한 목소리로 들으면 이탈합니다.
• 질문이 자연스러운 챕터 구분점이 됩니다. 별도로 구조를 짤 필요가 없습니다.
• 짧은 질문 라인이 긴 답변 사이의 호흡이 됩니다.

분량 감각은 이렇습니다 — 질문·답변 32라인이면 대략 5분, 24라인이면 4분 정도입니다.

⑤ 첫 문장이 전부를 결정한다

대본 규칙 중 하나만 지켜야 한다면 이겁니다. 첫 문장은 호기심을 자극하는 훅이어야 합니다.

"오늘은 어떤 소식인가요?" 같은 밋밋한 시작은 금지입니다. 진행자가 오늘 주제를 궁금하게 던지고, 답변자가 이어받아 풀어 갑니다. 결론을 미리 말해 버리면 안 됩니다.

그리고 마지막 답변은 반드시 요약입니다. "정리하면…" 형태로 핵심 세 가지 정도를 묶습니다. 시청자가 끝까지 봤을 때 남는 게 있어야 합니다.

⑥ 문장 끝을 쉬운 구어체로 — TTS가 뭉갠다

이건 초보자가 절대 예상 못 하는 함정입니다. 음성 합성 모델은 딱딱한 한자어 어미를 문장 끝에서 뭉갭니다.

실제로 겪은 사례들입니다.

• 격하되는 겁니다 → "겪어졌습니다"로 발음됨
• 선언인 셈이니까요 → 끝이 끊김
• 본 거죠, 이어가요 → 뭉갬

규칙은 이렇습니다. 문장 끝 세 어절 안에 "한자어 2음절 + 되는/하는" 조합이나 "~인 셈"을 두지 않습니다. 끝은 ~예요 / ~거예요 / ~어요 / ~니까요 / ~습니다처럼 흔한 어미로 씁니다.

재미있는 건 이 규칙이 글의 품질과도 같은 방향이라는 점입니다. 낭독이 안 되는 표현은 시청자에게도 어렵습니다.

⑦ 발음 사전 — 기계가 못 읽는 말들

고유명사와 숫자는 따로 관리합니다. 발음 규칙을 JSON 파일 하나에 모아 두고, 대본을 쓰기 전에 매번 다시 읽습니다.

예를 들면 이런 것들입니다.

• 소수점은 "점"이 아니라 "쩜" — 5.6은 "오쩜육"
• 제품 등급명 Sol은 "솔"이 아니라 "쏠"
• 표기 통일 — 제미니가 아니라 제미나이

🔴 이 파일을 "기억으로" 대신하면 반드시 사고가 납니다. 규칙에 명시돼 있는데도 숙지 없이 대본을 써서 잘못된 발음으로 발행한 적이 있습니다. 규칙은 계속 늘어나므로 매번 다시 읽는 것이 유일한 방법입니다.

여기에 TTS 전용 치환도 따로 둡니다. 자막에는 원래 표기를 쓰고, 음성 합성 직전에만 발음용 표기로 바꾸는 항목들입니다.

⑧ 음성 합성 — 참조 길이가 품질을 결정한다

1편에서 "3초면 목소리를 복제한다"고 썼는데, 실제로는 참조 음성이 짧으면 긴 문장의 끝이 잘립니다.

저희가 숫자로 확인한 내용입니다.

• 참조 14초 → 발화 2.7초(참조의 0.23배) → 끊김 0건
• 참조 11.8초 → 발화 20.6초(참조의 1.74배) → 끊김 발생
• 참조를 27.2초로 늘림 → 평균 20.6초 답변을 덮으면서 해결

즉 제로샷 음성 합성은 참조보다 훨씬 긴 발화를 안정적으로 못 이어갑니다. 결론은 단순합니다 — 참조 음성을 30초쯤 넉넉하게 녹음해 두세요. 3초로도 되긴 하지만, 긴 나레이션에는 부족합니다.

⑨ 라인 단위로 만드는 이유 — 자막 싱크

대본 전체를 한 번에 합성하지 않고 라인 하나씩 따로 만듭니다. 파일이 수십 개로 늘어나는데도 이렇게 하는 이유가 있습니다.

자막 싱크입니다. 라인마다 오디오 파일이 따로 있으면 각 라인의 시작 시각과 길이를 정확히 알 수 있습니다. 통짜로 만들면 나중에 받아쓰기로 위치를 추정해야 하고, 그 추정이 어긋나면 자막이 밀립니다.

추가로, 긴 라인은 문장 경계에서 자동으로 쪼개 생성한 뒤 이어 붙입니다. 기준은 20초(약 110자)입니다.

⚠ 쉼표에서 자르면 안 됩니다. 마침표·물음표·느낌표 경계에서만 자릅니다. 쉼표에서 자르면 어색하게 끊깁니다. 그리고 기준을 11초로 줄여 봤더니 조각 수만 세 배가 되고(라인당 55초 vs 35초) 품질 이득은 없었습니다.

⑩ 검증 — 기계가 잡는 것, 사람이 잡는 것

합성이 끝나면 전 라인을 받아쓰기로 검사합니다. 이 단계를 건너뛰면 결함이 그대로 발행됩니다.

역할 분담이 핵심입니다.

🔴 검증기로 발음 품질을 잡으려 하지 마세요. 받아쓰기는 소리를 글자로 옮길 뿐이라, 표기가 같으면 이상하게 들려도 통과하고 표기가 다르면 멀쩡해도 실패합니다. 이 구분을 못 하면 임계값만 조였다 풀었다 하며 시간을 태웁니다.

판정 기준도 명확히 나눠 뒀습니다.

• 고칩니다 — 내용이 빠졌거나 뜻이 달라진 것 ("한국은" → "타국은")
• 넘어갑니다 — 같은 뜻인데 표기만 다른 것 (차순위/차순이, 3배/세 배, GPU/지피유)

실측으로, 두 편 87라인에서 검증 실패 6건이 떴는데 실제로 고쳐야 할 건 0건이었습니다.

⑪ 검증 실패가 다섯 줄을 넘으면 게이트를 의심한다

이것도 값비싸게 배운 규칙입니다. 검증 실패가 많이 뜨면 재생성하지 말고 판정 기준을 의심하세요.

실제 사례입니다 — 37라인 중 8라인이 세 라운드 연속으로 실패했는데, 열어 보니 전부 내용은 정상이고 받아쓰기 변이로 인한 오탐이었습니다. 판정 기준을 고치자 첫 라운드에 전원 통과했습니다.

원리는 단순합니다. 결함이 그렇게 많을 확률보다 판정이 틀릴 확률이 높습니다. 오탐 루프는 시간만 태우고 품질을 못 올립니다.

⑫ 이미지 — 대부분은 이미 있다

이제 그림 차례입니다. 앞의 자산 비율 표대로, 24섹션이면 새로 만드는 건 여섯 장입니다.

순서는 이렇습니다.

1. 블로그 원문의 이미지를 전부 내려받습니다.
2. 이미지의 대체 텍스트(alt)를 읽어 어느 장면에 맞는지 배정합니다.
3. 남는 장면에만 프롬프트를 씁니다.
4. 생성 → 검수 → 조립.

🔴 alt를 한글 설명문으로 써 두는 게 여기서 값을 합니다. "이미지1"이라고 써 두면 아무 쓸모가 없고, "어둠 속으로 가파르게 떨어지는 청록빛 궤적 — 급락 장세를 표현한 개념 이미지"라고 써 두면 그 문장만 보고 장면을 배정할 수 있습니다.

⑬ 프롬프트에 글자를 부르는 단어를 쓰지 않는다

1편에서 언급한 문제입니다. Z-Image Turbo는 cfg가 1.0으로 고정이라 네거티브 프롬프트가 무시됩니다. 게다가 알리바바 모델이라 글자를 그릴 때 중국어를 씁니다.

실제 사고를 하나 소개하면, 한 편의 이미지 24장 중 10장이 오염됐습니다. 중국어 인포그래픽, 화면 절반을 덮는 철자 틀린 영어, 가짜 표와 말풍선 텍스트가 나왔습니다.

막는 방법은 하나뿐입니다. 프롬프트에 그런 단어를 안 쓰는 것입니다. 대표적인 금지어들입니다.

chart graph diagram document report headline calendar timeline label list dashboard screen poster slide banner book sign

대신 추상 비유로 바꿔 씁니다.

⑭ 뜻이 뒤집히는 함정어들

금지어보다 더 골치 아픈 게 평소엔 멀쩡한데 특정 문맥에서 엉뚱하게 그려지는 단어입니다. 저희가 실제로 밟은 것들입니다.

• note(쪽지) → 음표가 그려짐
• plane(평면) → 비행기. 폭발·상승 문맥에서 특히
• seal(봉인) → 물개
• transformer(변압기) → 변신로봇
• plate(판) → 접시
• key(열쇠 은유) → 실제 열쇠
• shape·form(형체) → 실사 인물, 때로는 나체
• stream(빛의 흐름) → 실사 폭포

🔴 부정어로 막으려 하지 마세요. "no people"을 붙여도 안 통합니다. cfg 1.0에서는 프롬프트에 적힌 단어 자체가 개념을 불러오기 때문에, 주황 불꽃을 막으려고 "no orange"를 넣었더니 또 불꽃이 나온 적도 있습니다.

해법은 주어를 구체적인 도형 이름으로 못 박는 것입니다. shape 대신 cube·block·bar·panel처럼요.

⑮ 검수는 컨택트 시트 한 장으로

이미지가 열두 장이면 열두 번 열어 볼 것 같지만, 실제로는 그러다 건너뛰게 됩니다. 그래서 한 장으로 합쳐서 한 번만 봅니다.

ffmpeg로 타일 이미지를 만들면 됩니다.

ffmpeg -y -v error -f concat -safe 0 -i list.txt \
  -vf "scale=426:240,tile=4x3" -frames:v 1 sheet.webp

이 방식의 효과가 실측으로 드러났습니다. 같은 사람이 같은 기준으로 검수했는데 방식만 바꿨더니 결과가 달라졌습니다.

5회차에서 한 장에 여섯 건을 잡았고 그중 실사 인물 얼굴이 두 장이었습니다. 한 장씩 열었다면 열여섯 번째쯤엔 지쳐서 놓쳤을 양입니다. 비용이 낮아서 지키게 되는 절차라는 점이 핵심입니다.

볼 것은 네 가지입니다 — 글자·숫자 / 웜톤·적색 / 실사 인물 얼굴 / 옆 컷과 겹치는지.

⑯ 클립과 배경음악 — 라이브러리가 시간을 0으로 만든다

움직이는 클립은 4섹션당 하나씩, 장면 1·5·9·13… 위치에 균등하게 넣습니다. 시작은 항상 클립입니다.

문제는 시간입니다. 클립 하나에 약 8분이라, 24섹션짜리 영상에 여섯 개를 새로 뽑으면 48분입니다. 제작 시간이 두 배가 됩니다.

그래서 클립 라이브러리를 씁니다. 주제의 대표 키워드(AI, GPU, ROBOT 같은 영문 한 단어)로 파일명을 붙여 쌓아 두고, 같은 키워드가 있으면 생성 대신 재사용합니다.

지금 저희 라이브러리에는 클립 21개, 배경음악 36개, 이미지 967장이 쌓여 있습니다. 그래서 대부분의 편에서 클립 생성 시간은 0분입니다.

처음 시작하면 라이브러리가 비어 있으니 초반 몇 편은 느립니다. 이건 정상이고, 쌓일수록 빨라집니다.

배경음악도 같은 원리입니다. 무드별로 만들어 두고 재사용합니다. 저희 기본값은 일반 주제는 잔잔하게, 뉴스는 경쾌하고 빠르게입니다.

무드 프리픽스를 정해 두면 관리가 쉽습니다 — 피아노·앰비언트·오케스트라·일렉트로닉·팝·드럼앤베이스·재즈·기타 같은 식으로요. 무드당 10개가 쌓이면 그때부터는 랜덤 재사용으로 넘어갑니다.

볼륨은 나레이션 아래로 충분히 낮춥니다. 저희는 0.18배로 깔고 무한 루프시킵니다.

⑱ 오버레이 — 정보는 이미지가 아니라 자막이 전달한다

이게 이 포맷의 핵심 설계입니다. 그림은 분위기만 맡고, 정보는 화면 자막이 전달합니다.

그래서 오버레이 파일에 두 가지를 넣습니다.

• 타이틀 — 영상 시작에 화면 정중앙 큰 글씨. 저시력 가독성을 위해 96픽셀로 크게, 표시 시간도 넉넉하게 잡습니다.
• 장면별 키워드 — 장면마다 시작 3초간 정중앙에 핵심 개념 한 단어 또는 한 구절.

🔴 이 파일을 빼먹으면 조용히 자막 없이 조립됩니다. 에러가 안 납니다. 저희도 세 편을 그렇게 내보낸 적이 있어서, 지금은 조립 직전에 파일 존재를 강제로 확인합니다.

⑲ 조립 — ffmpeg가 하는 일

여기서 실제 영상이 나옵니다. 조립 단계가 하는 일을 순서대로 적으면 이렇습니다.

1. 나레이션 앞에 0.5초 무음 패딩 — TTS 첫 음절이 씹히는 걸 막습니다
2. 정지 이미지에 켄 번스 줌 (홀·짝 장면 줌 속도를 교차)
3. 클립이 있는 장면은 장면 길이에 맞춰 리타이밍
4. 장면 사이 전환 효과 (페이드·와이프·슬라이드 등에서 랜덤)
5. 자막 번인 — 반투명 다크 박스에 흰 글씨
6. 타이틀·키워드 오버레이
7. 배경음악 믹싱
8. 인트로·아웃트로 연결, 썸네일 3초 정지 화면 삽입
9. 최종 인코딩

소요는 약 6분입니다. 이 단계에서 GPU는 거의 안 씁니다.

⑳ 챕터 시각 — 13.8초를 더해야 맞는다

사소해 보이는데 실제로 사고가 났던 부분입니다. 유튜브 챕터 타임스탬프를 대본 라인의 시작 시각 그대로 적으면 틀립니다.

최종 영상의 앞부분 구조가 이렇기 때문입니다.

인트로(약 10초) + 타이틀 카드(3초) + 리드 패딩(0.8초) + 나레이션

그래서 나레이션 기준 시각에 13.8초 안팎을 더해야 실제 시각이 됩니다. 이걸 빼먹고 어림으로 적어서 세 편이 전부 20초씩 앞선 채 발행된 적이 있습니다.

⚠ 인트로 길이는 편마다 다를 수 있으니 실측하세요. 그리고 첫 줄은 반드시 0:00이어야 유튜브가 챕터로 인식합니다.

㉑ 쇼츠는 별도 조립기로

롱폼 조립기는 16:9 전용이라 세로 영상에 재사용할 수 없습니다. 쇼츠는 별도 스크립트로 1080×1920으로 만듭니다.

주의할 점 두 가지입니다.

• 가로 이미지는 세로 화면에서 잘립니다. 중요한 부분이 화면 밖으로 나가지 않게 미리 축소해 패딩을 넣습니다.
• 자막은 네 줄이 상한입니다. 라인당 48자를 넘으면 마지막 줄이 잘립니다.

롱폼을 먼저 올리고 그 영상 ID를 쇼츠 설명란에 넣어 유입을 연결합니다.

㉒ 시간 예산 — 어디서 막히는지 미리 알기

단계별 예산을 정해 두면 "지금 뭔가 잘못됐다"를 빨리 알아챌 수 있습니다.

3시간 걸린 편이 있었는데, 그 시간의 3분의 2가 제작이 아니라 느린 도구와 오탐 루프였습니다. 예산을 정해 두는 이유가 이겁니다.

㉓ 실제 사례 — 세 편을 연달아 돌릴 때

여러 편을 한 번에 만들 때는 요령이 하나 있습니다. 단계별로 나눠 부르지 말고, 편당 전체 흐름을 감싼 러너 하나를 백그라운드로 띄웁니다.

이유는 단순합니다. 단계별로 쪼개 부르면 중간에 한 번 실패했을 때 그대로 멈춘 채 방치됩니다. 사람이 다시 볼 때까지 아무 일도 안 일어납니다.

그리고 순서를 정할 때 GPU를 쓰는 작업이 겹치지 않게 배치합니다. 이미지 생성과 음성 합성은 둘 다 VRAM을 먹으니, 1편 이미지 → 1편 음성 → 2편 이미지 순으로 사슬을 만듭니다.

㉔ 핵심 정리

• 대본을 백지에서 쓰지 않습니다. 이미 발행한 블로그 글이 원본이고, 소제목 하나가 장면 하나입니다.
• 섹션 수가 모든 걸 정합니다. 24섹션 → 24장면 → 클립 6개 + 이미지 18장, 그중 새로 만드는 건 6장.
• 대본 분량은 초당 6.4자. "초당 8자"로 잡으면 매번 25~30% 넘칩니다.
• 🔴 문장 끝을 쉬운 구어체로. 딱딱한 한자어 어미는 TTS가 뭉갭니다.
• 제로샷 음성은 참조보다 훨씬 긴 발화를 못 이어갑니다. 참조를 30초쯤 녹음해 두세요.
• 라인 단위로 합성해야 자막 싱크가 정확합니다.
• 검증은 기계가 유실을, 사람이 어색함을 봅니다. 실패가 다섯 줄을 넘으면 판정 기준을 의심하세요.
• 프롬프트에 글자를 부르는 단어를 쓰지 않습니다. 부정어로는 못 막습니다 — 주어를 도형 이름으로 못 박으세요.
• 검수는 컨택트 시트 한 장으로. 실측에서 적발 건수가 3배로 늘었습니다.
• 라이브러리가 쌓일수록 빨라집니다. 클립 생성 8분이 0분이 됩니다.
• 챕터 시각에는 13.8초 안팎을 더해야 맞습니다.

다음 편에서

3편은 실제로 깨지는 지점들입니다. 지금까지 쓴 순서는 "잘 됐을 때"의 이야기이고, 실제로는 여기저기서 조용히 깨집니다.

에러 없이 나오는 검은 이미지, 동시에 밀어 넣었다가 걸리는 큐 교착, 경로가 바뀌었는데 빈 폴더를 보고 그냥 넘어가는 스크립트, 다른 편 이미지가 섞여 들어오는 사고, 한글이 깨지는 인코딩 문제 — 전부 저희가 실제로 밟은 것들입니다.

그리고 마지막으로 이 전부를 사람 없이 매일 돌리는 구조를 씁니다. 클로드 코드에게 무엇을 맡기고 무엇을 맡기지 않는지, 반복 절차를 어떻게 파일로 고정하는지가 거기 들어갑니다.

출처

1. GitHub — QwenLM/Qwen3-TTS (제로샷 음성 복제)
2. Hugging Face — Tongyi-MAI/Z-Image-Turbo (cfg 고정·모델 카드)
3. GitHub — Lightricks/ComfyUI-LTXVideo (클립 생성)
4. GitHub — ace-step/ACE-Step-1.5 (배경음악)
5. GitHub — SYSTRAN/faster-whisper (음성 검증)
6. FFmpeg — License and Legal Considerations
7. ComfyUI — LTX 워크플로 템플릿
8. ComfyUI Blog — ACE-Step 1.5 is Now Available in ComfyUI

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/