안녕하세요! 야마짱입니다.

저는 디자인 감각이 전혀 없는 사람입니다. 영상 편집 소프트웨어는 여는 순간 조용히 닫아버릴 정도입니다.

그런데도 매주 AWS 업데이트 해설 영상을 YouTube에 배포하고 있습니다.

영상을 만들고 있는 것은 제가 아니라, AWS Batch 위에서 동작하는 자작 파이프라인입니다.

이번에는 「영상 생성을 AWS 위에서 어떻게 구동할 것인가」에 집중하겠습니다. 캐릭터 소재 제작 방법, 립싱크(Lip-sync) 합성 구현 상세, Remotion 컴포넌트 작성법은 별도 기사로 넘기겠습니다.

코드에서 태어난 영상이 바로 이것입니다

매주 일요일 18시에 배치가 기동하여, 「이번 주의 AWS 업데이트」를 캐릭터가 해설하는 영상이 완성됩니다. 자막, 업데이트 카드, BGM/효과음, 입 모양 맞추기(Lip-sync)까지 모두 코드로 합성하고 있으며, 영상 편집 소프트웨어는 일절 등장하지 않습니다. 영상 편집을 할 수 없다면, 영상을 코드로 쓰면 된다. React 컴포넌트로서 영상을 선언적으로 작성할 수 있는 Remotion이라는 프레임워크 덕분에 이것이 정말로 가능해졌습니다.

전체 아키텍처: LLM은 5단계 중 단 하나만 사용

단계	처리	LLM 관여
phase0	claude -p 스모크 테스트 (행(Hang) 감지 · fail fast)	통신 확인만
phase1	What's New RSS를 전주 일~토 7일분 취득 · 병합	없음
phase2	대본 생성 → 구조 검증(Validation) → 팩트 체크 → S3 저장	★이 단계만
phase3	음성 합성 → props 생성 → Remotion 렌더링 + 립싱크 합성	없음
phase4	final.mp4를 S3 저장 → SNS 성공 알림	없음

유일하게 LLM을 호출하는 것은 phase2입니다. RSS로 취득한 업데이트 목록으로부터 claude -p를 통해 대본(episode JSON)을 생성시키고, 구조 검증과 후술할 팩트 체크를 모두 통과한 것만 S3에 저장하여 다음 단계로 진행합니다. 그 외의 단계(RSS 취득 · 음성 합성 · 렌더링 · 저장 · 알림)는 전부 결정론적인(Deterministic) Python 스크립트입니다.

왜 Lambda가 아니라 AWS Batch인가

음성 합성 ~ 렌더링 ~ 립싱크 합성 등의 처리가 포함되어 영상 하나당 30분 코스가 되므로, Lambda의 15분 제한으로는 시작조차 할 수 없습니다. 렌더링에서 CPU/메모리를 대량으로 사용하기 때문에, 작업 정의(Job Definition)에서 16vCPU/32GB로 유연하게 지정할 수 있고, 주 1회만 동작하므로 컨테이너 상주에 따른 낭비도 없습니다.

작업(Job)의 타임아웃은 3시간이며, 인프라 기인 에러만 자동 재시도(Retry)하고, 대본 검증 실패와 같은 애플리케이션 측의 실패는 즉시 EXIT 시킵니다.

각 컴포넌트의 구성

필요한 환경(Node/Python/ffmpeg/Remotion/Claude Code CLI + 캐릭터 소재 일체)을 담은 이미지를 ECR에 푸시하고, 컨테이너 기동 시에는 entrypoint.sh가 소지품 검사만 수행한 뒤 본체의 run_pipeline.py로 바통을 넘깁니다 (로직은 전부 Python 측).

ScheduleExpression: cron(0 18 ? * SUN *)
ScheduleExpressionTimezone: Asia/Tokyo

이 스케줄이 Batch 작업을 1개 기동합니다. 인증 정보는 Aivis의 API 키와 Claude Code의 장기 OAuth 토큰 두 가지이며, 둘 다 Secrets Manager에 저장되어 있습니다. Claude Code와 Aivis 모두 구독 플랜(정액제)의 장기 토큰으로 운용하고 있어, 음성 생성도 대본 생성도 팩트 체크도 호출할 때마다 추가 비용이 발생하지 않습니다.

설계의 핵심: 비결정성을 1단계에 가두기

이 파이프라인의 가장 큰 특징은 중간에 비결정적인(Non-deterministic) LLM이 끼어 있다는 점입니다. 같은 RSS를 입력해도 대본의 관점은 매번 바뀌지만, 이는 오히려 재미있는 요소입니다. 문제는 제어 불가능한 가차(Gacha)로 만들지 않는 것입니다. LLM이라는 비결정적인 워커를 대본 생성 단계(phase2)에만 가두고, 그 전후는 전부 결정론적인 코드로 고정하는 것입니다.

업데이트 내용의 채택 기준, 사용할 수 있는 아이콘이나 모션의 화이트리스트 (whitelist), 말투나 건수와 같은 원고 규칙 등, 흔들리지 말아야 할 부분을 명문화하여 고정하고 있습니다.

하지만 아무리 정중하게 지시하더라도 정말로 지켜지고 있다는 보장은 없습니다.

나온 결과물을 경계(boundary)에서 검증하는 메커니즘이 필요합니다. 그것이 다음 장의 이야기입니다.

검증은 3단계: 기계적 검증 (Machine Validation), LLM 팩트 체크 (Fact Check), 그리고 인간

LLM은 아무렇지도 않게 틀립니다. RSS 제목만으로 내용을 "추측"하여 부풀리는 케이스는 특히 위험합니다. 이 파이프라인에서는 검증을 3단계로 구성했습니다.

1단계: 기계적 검증 (Machine Validation) (fail fast)

대본이 생성되면 먼저 기계적으로 검사합니다. JSON 형식이 깨지지 않았는지, 아이콘이나 모션이 화이트리스트 (whitelist)에 포함되어 있는지, 건수가 너무 많지는 않은지 (12건 초과 시 즉시 에러) 등을 확인합니다. 여기서 걸러지면 다음 단계로 넘어가지 않고, 후술할 자동 수정 루프 (automatic correction loop)로 돌립니다.

2단계: LLM 팩트 체크 (Fact Check) —— 쓰는 LLM과 체크하는 LLM을 분리

구조가 올바르더라도 내용이 올바르다는 보장은 없습니다. 그래서 대본 생성과는 별도의 claude -p 호출 (대본 생성과는 다른 모델)로 팩트 체크를 수행하는 메커니즘으로 만들었습니다.

대본 생성, 검증, 팩트 체크를 하나의 시도로 취급하며, 지적 사항이 남아 있으면 최대 3회까지 자동 수정 루프 (최근 유행하는 그것)를 돌립니다.

재시도(retry) 시에는 이전의 episode JSON 전문과 지적 리스트를 통째로 동봉하여 "지적된 부분만 수정하여 전문을 다시 출력하라"고 요청하는 방식입니다.

최종 시도에서도 에러 (error)가 남아 있으면 실패로 간주하고, 경고 (warning)만 있다면 무인 운용이므로 멈추지 않고 진행합니다 (어차피 공개 전에 사람의 눈을 거치기 때문입니다).

3단계: 인간 (나)에 의한 최종 체크

그럼에도 불구하고, 공개 전 최종 확인은 반드시 직접 합니다. "기계적 검증을 통과했으니 OK"가 아니라, 내가 업데이트 내용을 이해한 상태에서 체크합니다.

이 파이프라인은 **S3에 final.mp4를 저장하는 것까지가 스코프 (scope)**이며, YouTube로의 업로드는 의도적으로 포함하지 않았습니다.

공개 전에는 반드시 인간의 체크가 개입되는 구조이며, 자동화하는 것은 작업이지, 이해와 책임이 아니다 —— 이것이 운용해 본 결과 얻은 결론입니다.

궁금한 러닝 코스트 (Running Cost)

대략적인 개산입니다 (2026년 7월 시점의 도쿄 리전 요금 기준 추산. 단가는 변동되므로 정확한 내용은 Fargate 요금 페이지를 참조해 주세요).

항목	개산
Fargate (16vCPU / 32GB · ARM64)	작동하는 동안만, 약 120엔/시
...

월 500엔으로, 매주 쉬지 않고 납품해 오는 영상 크리에이터를 고용할 수 있다고 생각하면 파격적인 가격입니다. LLM을 대본 생성과 팩트 체크에 두 번 호출하더라도, **정액 구독 범위 내에서 LLM 비용은 제로 (zero)**라는 점이 고마운 부분입니다.

요약

"AI 에이전트 × 배치 처리 (Batch Processing)"는 아직 설계 패턴이 확립되지 않은 영역이지만, 그렇기에 더욱 설계하는 보람이 있습니다. 여러분의 지견도 꼭 들어보고 싶습니다.

끝까지 읽어주셔서 감사합니다!

채널 구독과 좋아요를 눌러주신다면 기뻐서 눈물을 흘릴지도 모릅니다.

Discussion