에이전트 5개 동시에 돌려서 숏폼 600개 자동화 파이프라인 설계한 날

에이전트를 하나씩 순서대로 돌리는 건 느리다. 세션 1개, 에이전트 5개를 동시에 올리면 어떻게 될까.

TL;DR shortsmaker 기획 세션에서 에이전트 5개를 병렬로 실행해 TTS, 영상 조립, SNS 업로드, 콘텐츠 생성, 숏폼 트렌드를 동시에 리서치했다. 1h 23min, 10 tool calls. 코드는 0줄이지만 기술 스택 선정은 끝났다.

왜 병렬인가

FortuneLab 숏폼 영상 600개 자동 생산 파이프라인을 기획하고 있었다. 사주 콘텐츠를 TikTok/YouTube Shorts용으로 대량 생산하는 프로젝트다.

기술적으로 결정해야 할 게 한꺼번에 너무 많았다. TTS 어떤 걸 쓸지, 영상은 어떻게 조립할지, SNS 업로드 자동화는 가능한지, 600개 스크립트 생성 비용은 얼마나 드는지, 그리고 2024년에 만든 기획서의 영상 길이(18-22초)가 지금도 맞는지.

각 영역을 순서대로 조사하면 4-5시간짜리 세션이 된다. 그래서 Claude Code에게 직접 요청했다.

너가 생각하기에 에이전트 구성해서 계획을 좀 더 구체화하고 수정, 보완해도 돼.
진짜로 되는 방법, 자동화가 쉽고 확실한 방법, 퀄리티가 좋게 나오는 방법으로
서칭해서 최신소식 기준으로 확실한걸로

구체적인 에이전트 구성을 지시하지 않았다. “니가 알아서 에이전트 짜봐”라는 식의 프롬프트였다. 어떻게 구성할지는 Claude에게 맡겼다.

5개짜리 에이전트 팀이 떴다

Claude는 5개 에이전트를 동시에 띄웠다.

콘텐츠 대량 생성 리서치, 영상 자동 조립 리서치, TTS 최신 기술 리서치, SNS 자동 업로드 리서치, 숏폼 트렌드 리서치. 각각 독립적인 서브에이전트로 실행됐고, tool calls 기준으로 Agent 5번이 한 메시지에서 동시에 발생했다.

Claude가 판단한 병렬화 기준은 단순했다. 각 도메인이 서로 의존성이 없다. TTS 조사가 끝나야 영상 조립 조사를 시작하는 게 아니다. 전부 독립적으로 진행 가능하다. 그래서 병렬로 올렸다.

결과는 순서 없이 완료됐다. 콘텐츠 생성, 영상 조립, TTS 순으로 먼저 들어왔고, 트렌드가 그 다음이었다. SNS 업로드 에이전트는 웹 리서치를 더 오래 했다.

각 에이전트가 반환한 내용은 진짜로 쓸 수 있는 수준이었다.

콘텐츠 생성 에이전트는 모델 비교를 해왔다. Haiku 3.5 + Batch API 조합이면 600개 스크립트를 $1 미만에 생성할 수 있다는 결론이었다. Batch API는 비동기 처리 대신 50% 할인을 받는다. 시간이 좀 걸려도 괜찮으니 비용이 문제인 프로젝트에서는 맞는 선택이다.

TTS 에이전트는 Edge TTS를 메인으로 추천했다. 마이크로소프트가 관리하는 무료 TTS 엔진인데, 한국어 퀄리티가 나쁘지 않다. 태국어는 별도 스토리가 있었다. FortuneLab의 타겟이 동남아를 포함하는데, 태국어 Edge TTS 품질이 불안정해서 Google Cloud TTS를 백업으로 준비하라는 권고가 나왔다.

영상 조립 에이전트는 Pillow + FFmpeg 하이브리드 방식을 제안했다. MoviePy는 내부적으로 FFmpeg를 감싼 건데 오버헤드가 있다. 직접 Pillow로 프레임을 생성하고 FFmpeg로 인코딩하면 더 빠르고 제어가 쉽다. 특히 CJK 폰트 렌더링 문제가 MoviePy에서 자주 터지는데, Pillow에서 직접 처리하면 이 문제를 피할 수 있다.

트렌드 에이전트가 기획서를 흔들었다

네 번째 에이전트에서 예상 못한 결과가 나왔다.

트렌드 리서치 에이전트가 숏폼 영상 최적 길이를 2025-2026 기준으로 분석해왔다. 결론은 45-90초였다. 원래 기획서에 있던 18-22초는 2024년 기준이고, 지금은 플랫폼 알고리즘이 완성도 높은 롱숏폼을 선호한다는 내용이었다.

여기서 수정이 들어왔다.

아 아니야 쇼츠만 할 거야. tiktok 쇼츠 길이 기준으로 해줘

TikTok과 YouTube Shorts의 실제 최적 범위는 15-60초다. 45-90초는 다른 포맷 얘기였다. 사용자가 맥락을 바로 잡았고, Claude는 영상 길이 기준을 즉시 재조정했다. 원래 18-22초를 유지하거나, 훅 + 내용 + CTA 구성을 제대로 넣으려면 30-45초 정도가 낫다는 방향으로.

에이전트 리서치가 잘못된 게 아니다. 에이전트는 주어진 키워드로 최신 데이터를 가져온 것이고, 사용자가 실제 범위를 더 좁게 정의한 거다. 이런 수정이 세션 중간에 자연스럽게 일어났다.

도구 사용 통계

1h 23min, tool calls 10번.

Agent(5) — 병렬 에이전트 실행
Read(3)  — 기존 플랜 문서, 샘플 JSON 확인
Bash(2)  — 프로젝트 상태 확인

수정 파일 0개, 생성 파일 0개.

세션 전체가 설계에 집중된 거다. 코드를 짜기 전에 기술 스택을 제대로 고르는 게 더 중요하다고 판단했고, 그 판단이 맞았다. 잘못된 TTS 라이브러리를 골랐다면 나중에 태국어 지원 문제로 파이프라인을 갈아엎어야 했다.

에이전트 5개 병렬 실행의 실질적 효과는 이렇다. 순서대로 조사했다면 각 영역당 15-20분씩 잡아먹었을 텐데, 병렬로 올리니 가장 오래 걸린 에이전트 기준으로 전체 시간이 정해졌다. SNS 업로드 에이전트가 웹 리서치를 가장 오래 했는데, 그 에이전트가 끝날 때 나머지 4개도 이미 완료된 상태였다.

기획 결과물

세션 종료 시점 기준 기술 스택은 확정됐다.

Python 단독. 영상 처리 생태계에서 TypeScript는 의미 없다. FFmpeg 바인딩, TTS 라이브러리, Claude API 모두 Python이 강하다. 조립은 Pillow + FFmpeg 하이브리드, TTS는 Edge TTS에 태국어 백업으로 Google Cloud TTS, 스크립트 생성은 Claude Haiku 3.5 + Batch API.

다음 세션에서는 Phase 1을 실제로 짠다. 환경 설정, 샘플 데이터로 영상 1개 조립, TTS 출력 품질 확인 순서로 간다.

리서치를 병렬로 돌리면 1/5 시간이 아니라 가장 느린 에이전트의 시간만 쓴다. 병목을 알면 최적화 대상도 보인다.