Final Plan

YouTube 자동화 파이프라인 최종 설계안

목표는 범용적으로 재사용 가능한 faceless YouTube long-form 제작 시스템을 만드는 것입니다. v1은 “1편을 안정적으로 끝까지 완주하는 파이프라인”에 집중하고, Omni 기반 긴 시퀀스 chaining은 구조를 열어두되 본격 구현은 다음 단계로 미룹니다.

단일 비디오 모델: Kling 3.0 Omni 오디오 분리: TTS 별도 범용 장르: 역사/설명/미스터리/경제 v1 핵심: 작동하는 1편 완주

1. 최종 의사결정 요약

결정

비디오 모델

Kling direct API 중심으로 간다. fal.ai는 참고자료용이고, 실제 운영 비용/전략 기준은 Kling 직접 가격표를 사용한다.

결정

일관성 전략

멀티모델 혼합 금지. 롱폼 시각 일관성을 위해 단일 모델 원칙을 유지한다. “프랑켄슈타인 효과”를 피하는 것이 중요하다.

결정

Omni 긴 시퀀스

개념은 v1에 포함, 강한 구현은 v1.5~v2. 먼저 5초 클립 생성과 end-to-end 완주를 검증한 뒤 chaining을 키운다.

2. 사용자 관점 사용 시나리오

주인님은 복잡한 내부 단계를 신경 쓸 필요가 없습니다. 실제 사용은 아래처럼 단순해야 합니다.

주제 입력
예: 조선 왕의 공포
→
기획/대본
Hook + 구조 생성
→
장면 설계
시퀀스/클립 계획
→
Kling 생성
클립 렌더링
→
TTS/편집
오디오 + ffmpeg
→
패키징
mp4 + 썸네일 + 메타

3. v1 범용 파이프라인 구조

Core

반드시 들어가야 하는 구성

  • 채널 설정 로더
  • 주제 → video brief 생성
  • video brief → 유튜브용 대본 생성
  • 대본 → sequence/clip planning
  • Kling clip generation (5초 중심)
  • 단일 narrator TTS
  • ffmpeg assembly
  • 제목/설명/챕터/썸네일 패키징
Later

v2 이후로 미뤄도 되는 구성

  • 멀티보이스 자동 캐스팅
  • 뉴스/정치 사실검증 레이어
  • 실제 사건용 출처/권리 레이어
  • 강한 continuity chain
  • 자동 업로드/예약 공개 고도화
  • 채널별 복잡한 role-play scene engine

4. 세부 단계 설계

Stage 0. Channel Config

채널명, 톤, 타깃 시청자, 영상 길이, 시각 스타일, 기본 narrator voice를 설정값으로 분리한다.

Stage 1. Topic → Brief

주제를 영상 기획안으로 변환한다. Hook, 타깃 시청자, 예상 길이, 섹션 구조를 정한다.

Stage 2. Script Writer

영상용 대본을 생성한다. 오프닝 훅, 본문 섹션, 마무리, 내레이션 문장을 만든다.

Stage 3. Sequence Planner

대본을 시퀀스와 클립 계획으로 쪼갠다. v1에서는 5초 중심 클립 단위로 설계한다.

Stage 4. Prompt Builder

subject anchor, environment, action progression, camera motion, continuity notes, negative prompt를 구조화한다.

Stage 5. Kling Render

Kling direct API로 짧은 클립을 생성한다. 저장/재시도/로그를 남긴다.

Stage 6. Narration TTS

단일 narrator voice로 문단별 오디오를 생성한다. pause와 emphasis 정도만 적용한다.

Stage 7. Assembly & Packaging

비디오/오디오/자막/BGM을 조립하고 최종 mp4, 썸네일, 설명문, 챕터를 만든다.

5. Omni 긴 시퀀스에 대한 냉정한 판단

주의

왜 처음부터 full chain을 넣지 않나

  • clip 1개 품질 검증도 아직 안 끝남
  • video reference / continuity / drift / 비용이 한 번에 겹침
  • 실패 시 복구 로직이 복잡해짐
  • 구현 속도가 크게 느려짐
권장

그래서 어떻게 가져가나

  • v1: 5초 클립 generation + end-to-end 완주
  • v1.5: 2~3 clip continuity 실험
  • v2: 진짜 sequence chaining 안정화

즉, 긴 시퀀스는 “너무 중요해서 빼면 안 되지만”, “너무 무거워서 첫 구현 핵심으로 넣으면 위험”하다.

6. 비용 구조 정리 (Kling 3.0 Omni 가격표 기준)

모드 조건 초당 가격 시간당 환산 메모
Standard no video / no audio $0.084/s $302.4/h 첫 클립 시작용
Standard with video / no audio $0.126/s $453.6/h 연속 clip chaining용
Pro no video / no audio $0.112/s $403.2/h 고급 시작용
Pro with video / no audio $0.168/s $604.8/h 고급 chaining용

해석: 롱폼 전체를 풀 체인으로 다 만들면 비싸다. 그래서 v1은 비용 검증을 위해 짧은 clip 단위로 먼저 완주시키는 게 합리적이다.

7. 디렉토리 구조 표준안

youtube-automation/
├── README.md              # 구조/규칙 요약
├── docs/
│   ├── current/           # 지금 기준으로 봐야 하는 현재 문서
│   └── history/           # 날짜가 붙은 설계/조사/기록 문서
├── archive/               # 레거시 문서, 종료된 공개본, 비교용 테스트 자산
├── assets/
│   ├── diagrams/          # 현재 쓰는 도식/시각화 산출물
│   └── screenshots/       # 현재 쓰는 참조 스크린샷
├── configs/               # 채널/파이프라인 설정
├── outputs/               # 최종 영상/썸네일/메타 결과물
├── samples/               # 샘플 입력/출력
├── scripts/               # 파이프라인 유틸 스크립트
└── logs/                  # 렌더/실행 로그

핵심은 research/ 아래에 섞어두지 않고, YouTube 자동화 관련 자산을 전용 상위 폴더로 분리하는 것이다.

8. Kling API 페이지를 읽기 위한 현실적 옵션

현재 한계

직접 추출 실패 원인

  • JS 렌더링 기반 문서
  • 봇/스크래퍼 접근 제한
  • web_fetch/crawl로는 셸만 읽힘
조사 우선순위

주인님이 비용을 써서 확보할 만한 옵션

  • Browser Rendering API (Cloudflare Browser Rendering / Playwright SaaS)
  • Apify 같은 JS 렌더링 크롤러
  • Firecrawl / Browser-use 계열의 JS 지원 플랜
  • 공식 OpenAPI / Postman / SDK 문서 접근 경로 확보
  • 직접 로그인 세션 기반 브라우저 수집 (마지막 수단)

9. 실행 순서 제안

1
v1 설계 고정
→
2
Kling 5초 clip 검증
→
3
1편 end-to-end 완주
→
4
2~3 clip continuity 실험
→
5
v2 chaining 확대

10. 최종 결론

정답은 “모든 상황을 다 시뮬레이션하고 시작”이 아니다. 지금은 범용 기본형을 먼저 고정하고, 확장 슬롯을 남겨두는 설계가 맞다.

그리고 Omni 긴 시퀀스는 중요하지만, 첫 구현에서 무겁게 넣으면 프로젝트가 커진다. 따라서 v1은 작동하는 최소 완성형, v2는 continuity 강화형으로 나누는 것이 가장 건강하다.