클로드 코드와 로컬 AI로 만드는 0원짜리 영상 (3) — 실제로 깨지는 지점들과 자동화

2편까지는 잘 됐을 때의 이야기였습니다. 실제로 돌려 보면 여기저기서 깨집니다. 그런데 문제는 깨지는 게 아니라, 깨졌는데 에러가 안 난다는 것입니다.

새까만 이미지가 "완료" 로그와 함께 나오고, 자막 없는 영상이 조용히 조립되고, 업로드가 실패했는데 성공 표시가 찍힙니다. 이 편은 그런 지점들의 목록이고, 전부 저희가 실제로 밟은 것들입니다.

후반부에는 이걸 사람 없이 매일 돌리는 구조를 씁니다. 결국 이 파이프라인의 값어치는 거기서 나옵니다.

되는 걸 만드는 것과 계속 돌리는 것은 다르다

한 편을 만드는 건 하루면 배웁니다. 어려운 건 같은 품질로 백 편을 만드는 것입니다.

차이는 실력이 아니라 실패를 어떻게 드러내느냐에 있습니다. 조용히 실패하는 지점을 하나씩 시끄럽게 바꾸는 작업이 사실상 파이프라인 구축의 본체입니다.

아래 함정들은 발견 순서가 아니라 초보자가 먼저 밟을 순서로 정리했습니다.

함정 ① VRAM이 모자라면 에러 없이 검은 화면이 나온다

가장 먼저, 가장 자주 밟는 함정입니다. 1편에서 짧게 언급한 걸 여기서 제대로 풀겠습니다.

이미지 엔진은 여유 VRAM을 보고 모델을 어떤 정밀도로 올릴지 스스로 고릅니다. 문제는 높은 쪽을 골라 놓고 실제로는 다 못 올렸을 때입니다. 이때 디코딩 결과가 NaN이 되는데, 예외가 발생하지 않습니다.

로그에 남는 건 이 한 줄뿐입니다.

RuntimeWarning: invalid value encountered in cast

샘플러는 8/8로 정상 완주하고 "완료"까지 찍힙니다. 성공한 것처럼 보입니다.

판별법은 파일 크기입니다.

🔴 이 표 한 줄이 사흘을 아껴 줍니다. 생성 스크립트에 파일 크기 검사를 넣어 두세요.

⚠ 다만 크기는 선별 기준이지 판정이 아닙니다. 이 글의 삽화를 만들면서도 1.6MB짜리가 하나 나와 실패로 분류했는데, 열어 보니 정상 이미지였습니다. 미세한 입자가 수천 개 들어간 그림이라 PNG 압축이 안 됐을 뿐이었습니다. 큰 파일은 "의심"이지 "실패 확정"이 아니니 눈으로 한 번 확인하세요. 반대로 4KB는 예외 없이 실패입니다.

그리고 언로드 명령으로는 실제로 안 비워진다

여기서 두 번째 함정이 이어집니다. 대부분의 엔진은 "모델 언로드" API를 제공하는데, 그걸 불러도 VRAM이 돌아오지 않습니다.

저희 실측입니다. 언로드 요청 후 실제 회수량이 0.27GB였고, 어떤 경우엔 음수(-0.17GB)였습니다. 프로세스가 메모리 할당자 캐시로 붙들고 있기 때문입니다.

확실한 방법은 하나뿐입니다. 프로세스를 내렸다 올리는 것.

서비스 중지 → nvidia-smi로 여유 VRAM 확인 → 서비스 시작

실측 대비가 명확합니다 — 여유 10GB에서 시작하면 계속 검정이 나왔고, 다른 서비스까지 내려 여유 15.6GB를 만든 뒤에는 27장 연속 정상이었습니다.

함정 ② 동시에 밀어 넣지 않는다

빨리 하려고 생성 요청을 한꺼번에 여러 개 보내면 어떻게 되는지 알려 드립니다.

전부 타임아웃이 나고, 큐에도 안 들어갑니다. 더 나쁜 건 그중 하나가 VRAM 잠금을 쥔 채 죽는다는 것입니다. 그 뒤로는 모든 생성이 막힙니다.

실측에서 잠금이 645초를 붙들고 있었고, 만료까지 20분이 걸렸습니다. 그동안 파이프라인 전체가 멈춰 있었습니다.

규칙은 단순합니다. 한 번에 하나씩 보냅니다. 요청을 큐에 넣고, 결과 파일이 생길 때까지 기다렸다가 다음으로 갑니다. 순차 큐잉은 생각보다 느리지 않습니다 — 어차피 GPU는 하나니까요.

함정 ③ 경로가 바뀌면 조용히 빈 폴더를 본다

이건 정말 허무하게 당합니다. 저장 공간이 부족해 출력 경로를 다른 드라이브로 옮겼는데, 옛 경로를 상수로 박아 둔 스크립트들이 있었습니다.

그 스크립트들은 오류를 내지 않았습니다. 빈 폴더를 열어 보고 "처리할 파일 없음"으로 조용히 넘어갔습니다. 이미지가 하나도 안 붙은 영상이 나오고 나서야 알았습니다.

대응은 경로를 하드코딩하지 않는 것입니다. 환경변수 → 새 경로 → 옛 경로 순으로 폴백하게 짜 두면 이사를 해도 안 깨집니다.

IMG_DIR = (환경변수
           or 새_경로 if 존재하면
           else 옛_경로)

그리고 "파일 0개"를 정상으로 취급하지 마세요. 0개면 경고를 띄우고 멈추는 게 맞습니다.

함정 ④ 자막 파일이 없으면 자막 없이 조립된다

같은 유형의 함정입니다. 화면 타이틀과 장면 키워드를 담은 설정 파일이 있는데, 이게 없으면 조립기가 그냥 자막 없이 만들어 버립니다. 경고도 없습니다.

저희는 이걸로 세 편을 자막 없이 내보냈습니다. 발행 후에 발견했습니다.

지금은 조립 직전에 파일 존재를 강제로 확인하고, 없으면 아예 진행을 막습니다. 이게 이 편 전체를 관통하는 원칙입니다 — "없어도 되는 것"으로 설계된 부분이 사고를 만듭니다. 필수인 것은 없을 때 시끄럽게 실패해야 합니다.

함정 ⑤ 재사용 이미지가 오염된다 — 그리고 파일 시각으로는 못 거른다

2편에서 "라이브러리를 쌓아 재사용한다"고 썼는데, 여기에 함정이 있습니다. 키워드만 맞으면 가져오기 때문에, 다른 편의 다른 스타일 이미지가 그대로 들어옵니다.

실제로 발견한 것들입니다.

• 한 장면에 "COST"라고 적힌 가격표 이미지
• 다른 장면에 숫자(59·55·60)가 그려진 만화풍 계기판 — 조립까지 끝난 뒤 발견해서 재조립

🔴 파일 시각(수정 시각)으로 걸러내려 하지 마세요. "최근 며칠 내 생성분은 안전하다"는 가정은 틀렸습니다. 같은 날 낮에 만든 오염분이 그 창에 들어와 통과했습니다. 파일 시각은 내용을 말해 주지 않습니다.

저희는 결국 라이브러리 460장을 전수 검사해서 185장만 남기고 305장을 격리했습니다. 격리는 삭제가 아니라 이동입니다 — 되돌릴 수 있어야 하니까요.

그리고 오염만 보는 게 아닙니다. "의미 불일치"도 봅니다. 글자도 없고 색감도 맞는데 내용이 정반대인 컷이 들어오는 경우가 있습니다. 실제로 "값이 점점 사라지는" 대목에 상승 화살표 그림이 배정된 적이 있습니다.

함정 ⑥ 검증 오탐 루프 — 시간만 태우고 품질은 안 오른다

2편에서 짧게 언급한 걸 여기서 강조합니다. 자동 검증이 실패를 많이 뱉으면, 재생성하지 말고 판정 기준을 의심하세요.

실측 사례입니다. 37라인 중 8라인이 세 라운드 연속 실패했습니다. 그래서 계속 다시 만들었는데, 열어 보니 전부 내용은 온전했고 받아쓰기 표기 차이로 인한 오탐이었습니다. 판정 기준을 고치자 첫 라운드에 전원 통과했습니다.

더 심한 경우도 있었습니다. 톤 검사를 하드 실패로 두었더니, 같은 대본을 두 번 돌렸을 때 걸리는 라인이 매번 바뀌었습니다(51·79번 → 25·55번). 전부 내용은 정상이었는데도 세 라운드 실패로 스크립트가 죽어 파이프라인 전체가 멈췄습니다. 무인으로 밤에 돌렸다면 그 편이 통째로 날아갔을 겁니다.

지금은 내용 유실과 속도 이탈만 하드 실패로 두고, 톤은 경고로만 남깁니다.

🔴 원칙: 결함이 그렇게 많을 확률보다 판정이 틀릴 확률이 높습니다.

함정 ⑦ 인코딩 — 한글이 깨지는 자리들

한국어로 작업하면 반드시 만나는 문제입니다. 저희가 실제로 겪은 자리들을 목록으로 남깁니다.

• 파워셸 스크립트의 BOM — BOM이 붙은 .ps1이 상황에 따라 실행에 실패합니다
• JSON 파일의 BOM — 파서가 첫 글자에서 죽습니다. 읽을 때 utf-8-sig로 여세요
• 파워셸 Set-Content의 기본 인코딩 — 시스템 코드페이지로 저장돼 다른 도구가 못 읽습니다. -Encoding utf8을 명시하세요
• 커밋 메시지의 따옴표 — 한글과 따옴표가 섞이면 셸에서 깨집니다
• REST 요청 본문 — 한글이 들어간 JSON은 UTF-8 바이트로 직접 만들어 보내는 편이 안전합니다

공통점은 에러 메시지가 원인을 안 알려준다는 것입니다. "파싱 실패"라고만 나오지 "BOM 때문"이라고 안 나옵니다. 한글이 관련된 실패는 일단 인코딩부터 의심하세요.

함정 ⑧ 표기 규칙을 메타데이터에 빼먹기

2편에서 발음 사전 이야기를 했는데, 함정은 그 규칙을 나레이션에만 적용하는 것입니다.

실제 사고입니다. 원문에 옛 표기가 남아 있었는데, 나레이션은 규칙대로 고쳐 놓고 영상 제목과 설명은 원문에서 그대로 복사했습니다. 결과적으로 제목이 틀린 채 발행됐습니다.

🔴 원문 제목을 그대로 복사해 영상 제목으로 쓰지 마세요. 표기 규칙은 제목·설명·썸네일·태그에도 전부 적용해야 합니다.

규칙을 문서에 적는 것만으로는 안 막힌다

여기가 이 편에서 가장 중요한 대목일 수 있습니다.

저희는 위 함정들을 전부 규칙 문서에 정리해 뒀습니다. 금지어 목록도, 함정어 표도 다 있습니다. 그리고 어느 날, 그 문서를 작업 시작할 때 통째로 읽고도 표에 이미 등재돼 있던 단어를 그대로 써서 사고를 냈습니다.

교훈이 분명했습니다. 문서를 읽는 것과, 쓰는 순간에 대조하는 것은 별개입니다. 사람이든 AI든 마찬가지입니다.

그래서 린터를 만들었다

대조를 기억에 맡기지 않고 스크립트에 맡겼습니다. 프롬프트를 파일에 모아 두고, 생성하기 전에 한 번 돌립니다.

python _prompt_lint.py --file prompts.txt

금지어가 있으면 BLOCK, 실측으로 확인된 함정어가 있으면 WARN을 뱉고 종료 코드 1로 실패합니다. 하나라도 걸리면 생성을 시작하지 못합니다.

설계에서 중요했던 건 규칙의 정본을 문서에 두고, 린터가 그 문서를 파싱하게 한 것입니다. 새 함정어가 나오면 문서에만 추가하면 린터가 자동으로 따라옵니다. 스크립트를 따로 고칠 필요가 없습니다.

실측 정확도는 그날 반려된 프롬프트 4건 전부 적발, 통과했던 12건 중 오탐 0건이었습니다.

⚠ 다만 린터는 단어만 봅니다. 개념 불일치·컷 간 중복·실사화 경향은 못 잡습니다. 컨택트 시트 검수를 대체하지 않습니다.

클로드 코드에게 무엇을 맡기나

이제 자동화 이야기입니다. 먼저 역할 분담부터 정리합니다.

맡기는 것은 판단이 필요하지만 정답 범위가 넓은 일입니다.

• 블로그 원문을 읽고 대화 대본으로 각색하기
• 장면마다 이미지 프롬프트 작성하기
• 대체 텍스트를 읽고 어느 장면에 맞는지 배정하기
• 여러 도구를 순서대로 호출하고 결과를 확인하기
• 실패했을 때 원인을 찾아 다시 시도하기
• 업로드 메타데이터(제목·설명·태그) 작성하기

마지막 항목이 특히 값이 큽니다. 실패 복구는 사람이 하면 왕복이 길고, 자동화 스크립트로 짜면 경우의 수가 너무 많습니다. 그 중간을 메우는 게 코딩 에이전트의 자리입니다.

무엇을 맡기지 않나

반대로 맡기면 안 되는 것이 분명히 있습니다.

• 최종 품질 판정 — 발음이 자연스러운지, 톤이 내용에 맞는지는 사람이 듣습니다
• 되돌리기 어려운 결정 — 파일 대량 삭제, 공개 발행은 확인을 받습니다
• 정확한 수치가 필요한 계산 — 챕터 시각 같은 건 어림하지 말고 스크립트로 뽑습니다
• 규칙 대조 — 위에서 봤듯 린터에 맡깁니다

원칙을 한 줄로 줄이면 이렇습니다. 기계적으로 확인 가능한 것은 기계에, 판단이 필요한 것은 에이전트에, 취향과 책임이 걸린 것은 사람에게.

스킬 — 반복 절차를 파일로 고정하기

같은 작업을 반복하면서 매번 설명을 다시 하는 것이 가장 큰 낭비입니다. 그래서 절차를 문서로 고정합니다.

클로드 코드에는 스킬이라는 개념이 있습니다. 마크다운 파일 하나에 언제 쓰는지 + 어떤 순서로 하는지 + 무엇을 조심하는지를 적어 두면, 관련 요청이 들어올 때 그 절차를 따릅니다.

저희 영상 제작 스킬에는 이런 것들이 들어 있습니다.

• 실전 최단 경로 — 실제로 손을 움직이는 순서
• 자산 비율 표 — 섹션 수로 장면·클립·이미지 개수를 정하는 규칙
• 표준 기본값 — 보이스, 길이, 배경음악 무드, 업로드 공개 여부
• 함정 목록 — 이 글에 쓴 것들
• 시간 예산 — 단계별 정상 소요

🔴 중요한 건 사고가 날 때마다 이 문서를 갱신하는 것입니다. 문서가 자산이 되려면 실측이 계속 쌓여야 합니다. 저희 스킬 문서에는 날짜와 함께 "이날 이래서 이 규칙이 생겼다"가 다 적혀 있습니다.

MCP — 로컬 서버를 도구로 연결하기

로컬 AI 서버들을 클로드 코드가 직접 호출하게 만드는 방법이 필요합니다. 그 표준이 MCP입니다.

구조는 단순합니다. 로컬 서버들 앞에 중계 서버를 하나 두고, 그게 "이미지 생성", "음성 합성", "서비스 시작", "GPU 상태 조회" 같은 도구 목록을 노출합니다. 클로드 코드는 그 도구를 부르기만 하면 됩니다.

이렇게 해 두면 대화 중에 이런 게 가능해집니다 — "GPU 상태 좀 보고, ComfyUI가 꺼져 있으면 켜고, 이미지 다섯 장 뽑아 줘."

⚠ 다만 긴 작업은 MCP로 부르지 마세요. 응답을 기다리다 타임아웃이 납니다. 작업을 큐에 넣고 바로 반환받은 뒤, 결과 파일이 생겼는지 직접 확인하는 방식이 안전합니다. 저희는 이걸 몇 번 밟고 나서 규칙으로 굳혔습니다.

러너 하나로 밀기 — 단계별 호출의 함정

여러 편을 돌릴 때 가장 중요한 구조 결정입니다.

단계마다 도구를 하나씩 부르면 편해 보이지만, 중간에 한 번 실패하면 그 상태로 멈춰 방치됩니다. 사람이 다시 볼 때까지 아무 일도 일어나지 않습니다. 밤에 돌리는 작업이면 아침에야 발견합니다.

그래서 편당 전체 흐름을 감싼 러너 스크립트 하나를 만들어 백그라운드로 분리 실행합니다. 로그 파일 하나만 지켜보면 됩니다.

순서를 정할 때는 GPU를 쓰는 작업이 겹치지 않게 사슬을 만듭니다. 이미지 생성과 음성 합성이 동시에 돌면 VRAM이 부족해져 함정 ①로 돌아갑니다.

크론 — 사람 없이 매일 도는 구조

마지막 단계입니다. 러너가 안정되면 정해진 시각에 자동으로 시작하게 겁니다.

저희 구성은 이렇습니다.

• 블로그 발행 — 하루 두 번, 뉴스를 모아 글을 씁니다
• 영상 제작 — 그날 발행된 글 중 아직 영상이 없는 것을 골라 만듭니다
• 정리 — 새벽에 중간 산출물을 지웁니다

⚠ 여기서 실제로 겪은 함정 하나를 남깁니다. 영상 작업이 "최근 24시간에 발행된 글"을 대상으로 잡았는데, 작업이 시작된 직후에 발행된 글은 그 회차에서 빠집니다. 실측으로 판정 시점에 0편이었는데 20분 뒤에 두 편이 올라왔습니다.

대응은 단순합니다. "대상 0편"으로 끝날 때, 작업 말미에 한 번 더 조회합니다.

업로드 — 유튜브 API와 쿼터

완성된 영상은 유튜브 API로 올립니다. 처음 한 번 구글 클라우드 콘솔에서 OAuth 클라이언트를 만들고 브라우저 인증을 하면, 그다음부터는 자동입니다.

비용 개념이 하나 있습니다. 쿼터입니다. 영상 하나를 올리는 데 드는 유닛이 이렇습니다.

• 롱폼 — 약 2,154유닛 (영상 + 자막 + 썸네일 + 재생목록)
• 쇼츠 — 약 1,704유닛 (자막 없음)

기본 한도가 하루 10,000유닛이라면 하루 네 세트 정도가 상한입니다. 알아 둘 점 셋입니다.

• 잔량은 API로 조회할 수 없습니다. 콘솔에서만 보입니다
• 쿼터는 채널별이 아니라 구글 클라우드 프로젝트별입니다. 채널을 늘려도 안 늘어납니다
• 리셋은 태평양 시간 자정 — 한국 시간 오후 4시(서머타임 기간) 무렵입니다

🔴 그리고 하나 더. OAuth 앱이 테스트 상태면 인증 토큰이 7일마다 만료됩니다. 만료되면 업로드가 브라우저 재동의를 기다리며 멈춥니다. 무인 야간 작업이면 그 회차가 통째로 멈춥니다. 근본 해결은 콘솔에서 앱을 정식 상태로 승격하는 것입니다.

새벽에는 발행하지 않는다

자동화하면 놓치기 쉬운 부분입니다. 야간 작업이 새벽 3시에 끝나면 영상이 새벽 3시에 공개됩니다. 아무도 안 볼 시간입니다.

그래서 업로드 시각이 밤 11시~아침 8시면 즉시 공개하지 않고 다음 날 오전 8시로 예약 발행하게 해 뒀습니다. 업로드 자체는 새벽에 하되 공개만 미루는 방식입니다.

사소해 보이지만 자동화의 값어치를 지키는 규칙입니다. 자동으로 만드는 이유는 편해지려는 것이지, 아무 때나 내보내려는 게 아니니까요.

업로드 후 확인 — 성공 로그를 믿지 않는다

이 편의 주제가 여기서 다시 나옵니다. 실패했는데 성공 표시가 찍히는 자리입니다.

업로드 스크립트는 보통 자막·썸네일·재생목록 등록을 각각 예외 처리로 감쌉니다. 썸네일 등록이 실패해도 나머지가 진행되게 하려는 의도인데, 부작용이 있습니다 — 전부 실패해도 "완료"가 찍힙니다.

실제로 썸네일 등록이 요청 한도 초과로 실패해서 두 편이 기본 썸네일인 채 올라갔고, 한참 뒤에야 알았습니다.

지금은 업로드가 끝나면 API로 되물어 자막·썸네일·재생목록이 실제로 붙었는지 확인하고, 그 결과를 로그에 따로 찍습니다. 확인 줄이 없으면 성공으로 치지 않습니다.

정리 — 24시간 유예 후 삭제

영상 한 편을 만들면 중간 산출물이 상당히 쌓입니다. 라인별 음성 파일, 장면 클립, 자막 없는 본문 영상, 검수용 프레임 같은 것들입니다.

바로 지우면 안 됩니다. 수정 요청이 들어올 수 있으니까요. 그래서 24시간 유예를 두고, 지난 것만 정리합니다.

• 지웁니다 — 라인별 음성, 중간 클립, 자막 전 본문, 검수 프레임, 임시 파일
• 남깁니다 — 최종 영상, 나레이션 원본, 자막 파일, 썸네일, 대본, 메타데이터, 그리고 라이브러리
• 건드리지 않습니다 — 아직 발행 안 된 프로젝트

첫 실행에서 863건 · 2.3GB가 정리됐습니다. 이걸 자동으로 돌려 두지 않으면 디스크가 금방 찹니다.

이 파이프라인의 한계

정직하게 적어 둡니다. 이 방식으로 안 되는 것들이 있습니다.

• 실사 인물이 연기하는 영상 — 나레이션 + 추상 배경 포맷에 최적화돼 있습니다
• 정교한 편집이 필요한 콘텐츠 — 컷 타이밍을 프레임 단위로 잡는 작업은 사람이 편집기로 하는 게 빠릅니다
• 매번 다른 포맷 — 이 파이프라인의 힘은 같은 포맷을 반복하는 데서 나옵니다. 편마다 구성이 다르면 자동화 이득이 사라집니다
• 최고 품질의 영상 클립 — 상용 영상 모델이 아직 앞섭니다

즉 이건 "영상 제작 자동화"가 아니라 "특정 포맷의 영상 반복 생산"입니다. 그 구분을 하고 시작하는 편이 실망이 적습니다.

처음 시작한다면 이 순서로

3편을 다 읽고 나면 할 게 많아 보일 텐데, 전부 한 번에 할 필요가 없습니다. 순서를 권해 드립니다.

1. 이미지 한 장을 뽑아 봅니다 (1편 설치 순서 5번). 파일 크기가 정상이면 통과입니다
2. 음성 한 문장을 합성해 들어 봅니다
3. 이미지 몇 장 + 음성 하나로 ffmpeg 조립을 해 봅니다. 여기까지가 "된다"의 확인입니다
4. 글 하나를 골라 수동으로 한 편을 끝까지 만들어 봅니다. 하루쯤 걸립니다
5. 그 과정에서 반복되는 부분을 스크립트로 빼냅니다
6. 절차를 스킬 문서로 고정합니다
7. 편당 흐름을 러너 하나로 묶습니다
8. 마지막에 크론을 겁니다

🔴 4번을 건너뛰고 자동화부터 하지 마세요. 손으로 한 번 끝까지 안 해 보면 어디가 깨지는지 모르고, 그러면 자동화 스크립트가 조용히 잘못된 결과를 내는 구조가 됩니다. 이 편 전체가 그 이야기였습니다.

핵심 정리

• 🔴 가장 위험한 실패는 에러를 내지 않습니다. 검은 이미지, 자막 없는 조립, 빈 폴더, 실패한 업로드의 성공 표시 — 전부 조용합니다.
• VRAM 부족은 파일 크기로 판별합니다 (4KB·1.5MB 초과 = 실패, 600KB~1.1MB = 정상).
• 언로드 API로는 VRAM이 안 돌아옵니다. 프로세스를 내렸다 올려야 실제로 회수됩니다.
• 동시에 여러 요청을 보내지 마세요. 잠금이 좀비로 남아 20분간 전체가 막힙니다.
• 경로를 하드코딩하지 말고, "파일 0개"를 정상으로 취급하지 마세요.
• 재사용 이미지는 파일 시각으로 못 거릅니다. 내용을 봐야 하고, 오염뿐 아니라 의미 불일치도 봅니다.
• 검증 실패가 많으면 판정 기준을 의심하세요. 실측에서 8라인 반복 실패가 전부 오탐이었습니다.
• 한글 관련 실패는 일단 인코딩부터 의심합니다.
• 🔴 규칙을 문서에 적는 것만으로는 안 막힙니다. 기계가 대조하게 만드세요 — 정본은 문서에, 린터가 그 문서를 읽게.
• 에이전트에는 판단을, 스크립트에는 대조와 계산을, 사람에게는 최종 품질과 책임을 맡깁니다.
• 단계별 호출 대신 러너 하나로 밉니다. 중간에 멈춰 방치되는 걸 막습니다.
• 업로드 쿼터는 롱폼 약 2,154유닛, 프로젝트별로 계산되고 잔량 조회가 안 됩니다.
• 새벽에는 공개하지 않습니다. 예약 발행으로 넘깁니다.
• 손으로 한 편을 끝까지 만들어 본 다음 자동화하세요.

시리즈를 마치며

세 편에 걸쳐 SVIL이 영상 124편을 만든 방식을 전부 풀었습니다. 정리하면 이렇습니다.

1편 — '0원'의 실체는 편당 전기요금 약 42원이고, 초기 비용은 GPU 한 대이며, 손익분기는 5~6개월입니다. 클로드 코드는 유료입니다.

2편 — 대본은 이미 쓴 블로그 글에서, 이미지의 3분의 2는 이미 만든 것에서, 클립과 음악은 라이브러리에서 나옵니다. 새로 만드는 건 3분의 1도 안 됩니다.

3편 — 실패는 대개 조용히 일어납니다. 그걸 시끄럽게 바꾸는 작업이 파이프라인 구축의 본체입니다.

마지막으로 하나만 덧붙이겠습니다. 이 파이프라인의 진짜 값어치는 비용 절감이 아니라 시도 횟수에 있습니다. 크레딧을 세면서 만들면 마음에 안 들어도 그냥 넘어가게 됩니다. 스무 번 다시 뽑아도 42원이라면, 스무 번째 것을 씁니다. 품질은 거기서 옵니다.

궁금한 점이나 막히는 부분이 있으면 언제든 문의 주세요. 실제로 돌려 보시고 겪은 함정이 있다면 그것도 듣고 싶습니다.

출처

1. YouTube Data API — Quota Cost 산정 기준
2. YouTube Data API — Uploading a Video
3. Model Context Protocol — 공식 문서
4. Anthropic — Claude Code 문서
5. Hugging Face — Tongyi-MAI/Z-Image-Turbo
6. GitHub — ComfyUI
7. FFmpeg — License and Legal Considerations
8. GitHub — SYSTRAN/faster-whisper

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