AI 4명을 한 자리에 앉혀놓고 숏폼 자동화 파이프라인을 다시 설계했다

📝 한줄 요약

GPTers 스터디원들 사례글 12개 + 허샘 블로그 + Codex(GPT-5)와의 토론 + 가상 시니어 리뷰까지 한 세션에서 종합해서, 에피소드 20편 넘으면 무너질 운명이던 숏폼 파이프라인을 v6로 전면 재설계했어요. 한 줄도 코딩 안 했는데 Linear에 작업 15개가 자동으로 깔리고 601줄짜리 설계 문서가 나왔습니다.

바쁘시면 이것만 읽어도 돼요: 

- 도구는 Claude Code 1개지만 그 안에서 서브에이전트(Explore), Codex CLI, Linear API를 동시에 굴려서 "1인 컨설팅 팀"처럼 씀

- 핵심 깨달음: AI 영상 파이프라인은 단계 가 중요한 게 아니라 단계 사이의 데이터 계약(JSON 스키마) 이 중요함

- Codex한테 의논하니까 내가 못 본 사각지대(롱폼/숏폼 추상화 조급함, anti-text OCR 과민) 잡아줌

- 제가 "Remotion 쓰는데 ffmpeg를 또 써야 되냐?" 한 마디 던진 거에서 5단계 후처리가 1단계로 압축됨

- 결과적으로 코딩 시작 전에 반나절을 더 쓰는 게 코딩 시작하고 일주일 헤매는 것보다 낫다

🎯 이런 분들께 도움돼요

  • AI로 콘텐츠 자동화 파이프라인을 만들고 있는데 자꾸 깨지는 분

  • 혼자 일하는데 "리뷰해 줄 시니어가 옆에 있었으면" 싶은 분

  • Claude Code 안에서 다른 AI(Codex, Gemini)를 같이 굴리는 패턴이 궁금한 분

  • 작업 시작 전에 Linear 같은 도구로 정리하는 게 의미 있는지 고민하는 분

😫 문제 상황 (Before)

저는 매일 한국어 숏폼 영상(15-20초)을 자동으로 만드는 파이프라인을 굴리고 있어요. Remotion(React로 영상 만드는 도구) + Gemini로 이미지 생성 + Supertone으로 한국어 TTS 로 정지 이미지를 영상으로 변환 — 이 조합으로 동작은 합니다.

문제는 에피소드를 한두 편 만들 때는 멀쩡한데, 이 상태로 100편 가면 반드시 어딘가에서 무너진다는 게 보였어요. 

구체적으로:

- 캐릭터는 그나마 일관되는데 소품(뇌, 봉투 같은 거)은 매번 다르게 그려짐

- TTS 길이랑 영상 길이가 안 맞아서 자막이 어긋남

- 무엇보다 왜 잘 되는지/왜 깨지는지를 모르는 채 동작 중

지난주 GPTers 21기 스터디에서 다른 분들이 비슷한 파이프라인을 어떻게 만들고 있는지 사례글 12편을 쭉 봤고, 스터디장(허샘)이 본인 파이프라인을 블로그에 정리한 글을 공유했어요. 둘 다 우리 거랑 비교할 거리가 많아 보였습니다.

그래서 결심했어요: 

새 코드 한 줄 짜기 전에 설계만 다시 하자.

🛠️ 사용한 도구

  • 메인: Claude Code (Opus 4.6, 1M context)

  • 세컨드 의견: Codex CLI (gpt-5, reasoning effort=high)

  • 검색·탐색: Claude Code 내 Explore 서브에이전트 3개 (병렬)

  • 이슈 관리: Linear GraphQL API (curl 직접 호출)

  • 참고: 허샘 블로그 1편, GPTers 사례글 12편(Obsidian에 미리 정리됨)

  • 특이사항: 사람과 1:1 대화가 아니라 패널 토론 형식 — Claude가 사회자, Codex가 비판적 시니어, Explore 에이전트들이 리서처


🔧 작업 과정

1. "지난주 사례글이랑 허샘 블로그 같이 분석해줘" 한 줄로 시작

처음에는 단순했어요. "GPTers 스터디원들 사례 정리한 게 옵시디언에 있고, 스터디장이 이번에 블로그 올린 거 있는데, 우리 파이프라인에 응용할 거 뭐 있는지 분석해줘."

GPters 내 스터디 영상 저번주 분석한거랑 스터디원들 사례글 분석한것중에 
여기에 반영하거나 응용하면 좋은거 뭐가 있는지 분석해줘

Claude가 한 게 흥미로웠어요. 혼자 다 읽지 않고 Explore 서브에이전트를 병렬로 쏘더라고요. 사례글 12개는 한 에이전트가 한 번에 훑고, 블로그는 본인이 직접 읽고. 5분 만에 두 결과를 합쳐서 "10가지 응용 포인트 + 우선순위 high/med/low" 표가 나왔습니다.

이 시점에서 저는 3개 갈래 중 어떤 거부터 할까 만 고르면 되는 상태였어요. 깜짝 놀란 건 분석 자체보다 — 내가 막연하게 느꼈던 "뭔가 부족하다" 가 8개 항목으로 쪼개져서 눈앞에 떨어진 거.

2. "여기에 등록된 Linear 작업도 다 같이 봐. 그리고 Codex한테도 물어봐. ultrathink"

여기서 한 번 더 욕심을 냈어요. 분석만 받고 끝나는 게 아니라, 현재 Linear 백로그에 있는 작업들이랑 같이 매칭해서 통합 계획을 짜달라고. 그리고 한 마디 덧붙였습니다 — "Codex랑도 의논해봐."

추가로 여기에 연결된 프로젝트에 등록된 작업들 다 조회해서 관련해서 분석하고 
codex 랑도 의논해보고 분석해서 정리하고 계획 작성해 ultrathink

여기서 두 가지 일이 동시에 일어났어요:

(1) Linear API 직접 조회. Claude가 GraphQL로 PAI 팀의 "Short/Long Video Pipeline" 프로젝트 미완료 이슈 8건을 가져옵니다. 제가 머릿속으로 "그 작업 하나 있었지" 했던 것들이 전부 텍스트로 펼쳐졌어요.

(2) Codex CLI에 의논 패키지 던지기. Claude가 허샘 인사이트 8개 + GPTers 패턴 + Linear 8건을 한 묶음으로 만들어서 Codex(GPT-5, high reasoning)에게 6개 질문을 던졌어요. "이거랑 이거 어떻게 매핑해야 돼? 함정은 뭐야? 데이터 계약 우선순위는?"

여기가 "오!" 한 순간이었어요. 혼자 일하면 절대 못 받는 종류의 답변이 돌아왔거든요.

예를 들면:

  • "롱폼/숏폼 추상화 조급함 — Scene/Container 2계층을 v1에서 동시 도입 금지" — 내가 의식 못 했던 함정

  • "데이터 계약 성급 고정 — v1 minimum field, optional 확장 규칙 명문화" — 내가 욕심내고 있던 부분 정확히 찌름

  • "1순위는 audio_report.json이다. 도미노 효과 최대" — 내가 막연히 "다 중요해" 라던 걸 명확히 정리

Codex가 던진 답변을 Claude가 다시 받아서, 자기 분석이랑 합쳐서 "1-2주 실행 순서 + 신규 Linear 이슈 10개 제안 + 리스크 6가지" 까지 정리해줬어요.

3. "10년차 시니어 입장에서 리뷰해줘. 필요하면 웹 검색도 하고. YouTube 자동 업로드까지"

분석 받고 나니 욕심이 더 커졌어요. "이게 정말 100편 가도 안 무너지는 설계야?" 를 검증받고 싶었거든요. 그리고 어차피 마지막에 YouTube에 올려야 되니까 그것까지 한 번에 묻기로 했습니다.

분석에 대해서 장기적으로 퀄러티를 높이고 확장이 가능한 파이프라인을 제대로 
구축할수 있는지 숏폼 혹은 롱폼 영상 제작을 10년이상 해온 숙련자 입장에서 
리뷰 해주고 YouTube Data API v3: 영상 자동 업로드 하는것 까지 하려고 해. 
필요하면 웹 검색도 하고

여기서 Claude가 또 영리하게 행동했어요. Plan 모드로 들어가서:

  1. Explore 에이전트 1개 → 우리 워크스페이스 현재 코드 인벤토리 만들기 (어떤 스크립트가 뭘 출력하는지, 라인 번호까지)

  2. Explore 에이전트 1개 → YouTube Data API v3 + "10년차 베테랑 시니어" 페르소나로 비판적 리뷰 (병렬 실행)

10분 후에 받은 리포트에 이런 게 있었어요:

  • "지속 가능한 파이프라인은 의존성 순서로 변수를 잠근다. 오디오 → 이미지 → 비디오 → 합성. 잠그는 순서가 흔들리면 에피소드 20에서 무너진다."

  • "한국어 자막은 한 줄 ≤20자, CPS ≤12, 조사 직전에 줄바꿈 금지"

  • "썸네일 자동화 금지 — 후보 5개 자동 생성하고 사람이 1택. 얼굴 크기/텍스트 가독성은 사람 눈만 잡음"

  • "첫 5편은 unlisted로 올려라. 카피라이트 false positive 모니터링용"

이런 건 코딩하면서 절대 안 떠올랐을 디테일이에요. Claude가 페르소나 입혀서 만든 "가상 시니어 리뷰" 인데, 진짜 멘토 한 명이 옆에서 두 시간 코칭한 것 같은 느낌이었어요.

4. "Remotion 쓰는데 ffmpeg를 또 써야 돼?" — 한 줄 질문이 5단계를 1단계로 압축

여기가 제가 가장 좋아하는 순간이었어요. Plan 초안에 "Editor 5단계 후처리 (무음 트림 → 패딩 → 속도 조절 → concat → 자막 번인) by ffmpeg" 라고 되어 있는 걸 보고 의심이 들었습니다.

파이프라인으로 단계별로 나누었는데 ... Remotion: ffmpeg는 후처리인데 
remotion 을 사용하는데 ffmpeg 을 사용해랴할까?

Claude가 즉답했어요. 5단계를 표로 만들어서 각 단계를 Remotion으로 대체할 수 있는지 체크하더니:

단계

Remotion으로?

무음 트림

✅ <Audio trimBefore>

패딩

✅ <Sequence from>

속도 보정

✅ <Video playbackRate>

Concat

✅ TransitionSeries

자막 번인

✅ SrtSubtitle 컴포넌트

LUFS 정규화

❌ Remotion 미제공

5단계 중 5개가 Remotion으로 처리 가능, ffmpeg는 마지막 LUFS 정규화 1pass만 남으면 됨. 한 줄짜리 질문 하나로 후처리 복잡도가 80% 줄었어요. 내가 만든 도구도 아닌데, 제대로 안 쓰고 있었다는 걸 깨달은 순간이었습니다.

5. "팩트 체크 좀 해. 최신 정보로" — AI가 자기 출력을 의심하게 만들기

설계가 거의 끝났을 때 한 가지 더 시켰어요. "이 계획에 들어간 숫자랑 사실들 진짜 맞아? 검색해서 확인해."

Claude가 병렬로 두 에이전트를 쏴서:

- YouTube Data API quota (1600 unit이라는 소문 vs 100 unit) — 100 units 확정

- LUFS 타겟 (-13 vs -14) — -14 LUFS 확정 (제가 -13으로 잘못 쓰고 있었음)

- Remotion startFrom prop — deprecated, trimBefore 써야 됨 (4.0.319부터)

youtube.upload 스코프로 captions까지 가능한가 — 불가youtube.force-ssl 필요

- Apple Vision OCR이 한국어 지원하는지 — 지원, 무료 로컬

5분 만에 9개 사실이 검증되거나 수정되었어요. 만약 이걸 안 했으면 일주일 코딩한 후에 "어, captions가 권한 부족 에러를 뱉네?" 하고 OAuth 처음부터 다시 했을 거예요.

6. Linear 이슈 15개 자동 생성

마지막 단계. 설계 문서를 그대로 둘 순 없고, 실행 가능한 단위로 쪼개야 했어요. 보통 같으면 한 시간 들여서 손으로 했을 겁니다.

A. 한꺼번에 — 14건 생성 + PAI-309 description 업데이트 자동 실행
어떤게 제일 잘 워킹이 되는건가?

Claude가 추천한 거 골랐고, 30초 만에:

- Linear 신규 이슈 15개 생성

- 각 이슈에 parent-child 연결, priority, 한국어 description, 의존성 명시

- 기존 PAI-309를 "v6 엄브렐러"로 재정의 + 15 sub-task 표 박기

- 기존 관련 이슈 6개에 v6 연계 코멘트 자동 추가

손으로 했으면 한 시간이었을 작업이 30초.


✅ 결과 (After)

Before vs After

항목

Before

After

파이프라인 설계 명확도

"뭔가 부족함" (정성적)

16개 ISC + 15 Linear sub-task로 분해

다음 작업 우선순위

모름

audio_report.json이 1순위 (도미노 효과로 확정)

검증된 팩트

추정

9개 항목 웹 검증 (LUFS, OAuth scope, deprecated API 등)

시니어 리뷰 받은 시간

0

가상 페르소나 + Codex GPT-5 high = 2시간 분량

설계 문서

없음

601줄 Plan 문서 1개 (Plans/eager-sprouting-music.md)

작업 단위

머릿속

Linear 15개 이슈, 의존성 그래프 포함

잘못 알고 있던 것

-13 LUFS, startFrom prop, youtube.upload만으로 충분

전부 수정 (-14 LUFS, trimBefore, force-ssl)

코딩 시작 전 제거된 함정

0

최소 6개 (이중 합성, OCR 과민, Veo 4/6/8s 강제 배속, 추상화 조급함, 등)

결과물

  • 설계 문서: Plans/eager-sprouting-music.md (601줄, 1.4KB → 약 35KB)

  • Linear 엄브렐러: PAI-309 (15 sub-task)

  • 기존 이슈 통합 정리: PAI-260/264/168/256/263/163 코멘트로 v6 연계 명시

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

  1. AI한테 패널 토론 시키기 — 분석 한 번에 끝내지 말고 "Codex한테 물어봐", "10년차 시니어처럼 리뷰해줘" 같이 역할/관점을 다양하게 주문하면 사각지대가 드러남. 한 모델한테 여러 번 묻는 것보다 다른 모델의 의견을 받아오는 게 효과 큼

  2. "팩트 체크해" 한 줄로 자기 출력 검증시키기 — AI는 그럴듯한 숫자/스펙을 자신 있게 말하는데, 명시적으로 "검색해서 확인해" 하면 본인이 만든 거 안에서 9개 수정 사항을 찾아내요. 코딩 전에 한 번 돌리는 게 일주일 살림

  3. "이걸 정말 X로 해야 돼?" 라고 의심 한 번 던지기 — Claude가 ffmpeg 5단계를 제안했을 때 그냥 받았으면 그대로 코딩 시작했을 거예요. "다른 도구로 안 되나?" 한 마디가 80% 복잡도를 날려버림. AI 답을 너무 빨리 받지 말 것

  4. 설계 단계에서도 Linear에 작업 단위로 박기 — 머릿속에만 있는 건 잊혀요. 15개 이슈로 박으니까 다음 세션에서 "어디부터 시작하지?" 가 사라짐. AI가 자동으로 의존성 연결까지 해줘서 손으로 할 때보다 정확함

  5. Plan 모드 적극 사용 — Claude Code에는 "Plan 모드" 가 있어서, 설계 단계에선 코드 수정을 강제로 막아요. 덕분에 "분석 받다가 충동적으로 코딩 시작" 을 방지할 수 있었음

이렇게 하면 안 돼요

  1. "한 번에 다 해줘" 식으로 두루뭉술하게 던지기 — 단계를 잘게 쪼개서 각 단계마다 결과를 확인하면서 가야 내가 어떤 가정에 이의를 제기할 기회 가 생김. 통째로 받으면 그냥 받게 됨

  2. AI의 첫 답을 그대로 수용하기 — 첫 답은 항상 좋아 보입니다. 두세 번 의심해보면 더 나은 게 나옴. 특히 "이거 정말 X 써야 돼?" 같은 도구 선택은 거의 항상 재검토 가치 있음

  3. 세션 컨텍스트 욕심내기 — 분석이 길어지면 컨텍스트가 부풀어요. 저는 "분석 + 설계 + 이슈 생성" 까지만 하고, 실제 코딩은 새 세션에서 시작하기로 했어요 (PAI 컨벤션상 컨텍스트 40% 이하 유지). 깨끗한 세션에서 시작해야 코드 퀄리티가 더 잘 나옵니다

  4. 모든 사례를 다 흡수하려 하기 — GPTers 사례글 12편 + 허샘 8 인사이트를 받았을 때, 다 적용하려 하면 압도돼요. Codex가 "이건 v0에서 빼라" 라고 잘라준 게 컸음. 덜어내는 의견 도 능동적으로 요청할 것

🌍 다른 업무에 적용한다면?

이번에 쓴 패턴은 영상 자동화 가 아니라 복잡한 의사결정 전에 다각도 검토가 필요한 모든 일 에 적용 가능해요:

  • 신규 사이드 프로젝트 시작 전: 비슷한 사례 5개 → 시니어 리뷰 페르소나 → 팩트체크 → 작업 단위로 쪼개기. 코딩 시작 전 반나절이 시작 후 한 달을 살림

  • 이직/커리어 결정: 본인 상황을 자세히 정리 → "10년차 헤드헌터 입장에서", "내 분야 시니어 입장에서" 두 페르소나로 동시 리뷰 → 사실 검증

  • 외주 받기 전 견적: 비슷한 프로젝트 사례 + 함정 리스트 + 시간 추정. 첫 답을 의심하는 한 번이 견적의 정확도를 30% 올림

  • 블로그 글 쓰기 (이 글처럼!): 템플릿 보고 "이 섹션 정말 다 필요해?" 의심 → 핵심만 추려서 쓰기. 지금 이 글이 정확히 그렇게 쓰임

핵심은 똑같아요: AI를 단일 답변기로 쓰지 말고, 토론 패널로 써라.

🚀 앞으로의 계획

이 세션은 설계만 끝났어요. 다음 세션부터 진짜 코딩 시작합니다:

  1. PAI-311audio_report.json v1 스키마 + generate-tts.sh 통합 — 도미노 시작점

  2. PAI-313: AI 이미지 anti-text 가드 (Apple Vision OCR로 글자 박힌 이미지 자동 reject + 재생성)

  3. PAI-316: Remotion 합성 + ffmpeg loudnorm 1-pass — "단일 도구 원칙" 검증

  4. PAI-321~324: YouTube Data API v3 OAuth → QA 게이트 → 자동 업로드 → 24h analytics

  5. 모든 단계가 끝나면 롱폼 자동화로 확장 (PAI-256). 이번에 만든 데이터 계약을 그대로 상속

목표: 4월 말까지 매주 2-3편씩 자동으로 YouTube에 올라가는 한국어 숏폼 채널.

📋 재사용 가능한 프롬프트

프롬프트 1: 다른 사람 사례글이랑 내 작업 합쳐서 응용 포인트 뽑기

{옵시디언 폴더 또는 URL}에 있는 사례글 N개랑 {블로그 URL}을 분석해줘. 우리 {프로젝트명/스택}에 응용하거나 반영할 거 뭐 있는지 우선순위 high/med/low로 정리해줘. 그리고 우리한테 없는 인사이트가 뭔지도.

프롬프트 2: Codex/다른 모델한테 의논 위임

추가로 여기 관련 작업들 다 조회해서 분석하고 codex랑도 의논해보고 정리해서 계획 작성해 ultrathink

프롬프트 3: 시니어 페르소나로 리뷰 요청

분석에 대해서 장기적으로 퀄리티를 높이고 확장 가능한 {시스템}을 제대로 구축할 수 있는지 {분야}를 10년 이상 해온 숙련자 입장에서 리뷰해주고, {추가 요구사항}까지 고려해줘. 필요하면 웹 검색도 하고.

프롬프트 4: 자기 출력 팩트체크 강제

계획에 나온 내용들 중에 팩트 체크 필요한 거 최신 내용 검색해서 한번 해줘

프롬프트 5: 도구 선택 의심 던지기

파이프라인으로 단계별로 나누었는데 X 쓰는데 Y를 또 써야 할까? 각 단계가 진짜 Y 없이 X로만 처리 안 되는지 표로 보여줘

2
1개의 답글

뉴스레터 무료 구독

👉 이 게시글도 읽어보세요