AI로 12인 제작팀을 굴린 영상 제작과 토큰 소모
Codex 사용 화면에는 다음이 표시되어 있었습니다:
ERROR: You've hit your usage limit.
try again at Sep 24th, 2026 1:36 PM.그 후 5일 동안은 더 사용할 수 없었습니다. 영상 시리즈 51개 에피소드 중 38개를 완료했고, 아직 13개가 남아 있었습니다.
바로 직전에, Codex를 얼마나 사용했느냐는 질문을 받았을 때 저는 이렇게 답했습니다:
Approximately 7.4 million tokens, 101 times다른 기기에서 숫자를 다시 계산해 보니 다음과 같았습니다:
ai-boardroom approximately 159,366,148 tokens about 94% of total Codex usage20배나 착각하고 있었습니다. 이 글에서는 그 내역과 제가 왜 계산을 잘못했는지 설명합니다.
제가 만들고 있던 것
실제 인물의 경영진과 엔지니어를 캐리커처로 등장시키는, 1편당 약 15초짜리 세로형 숏폼 영상 시리즈였습니다. 각 에피소드는 다음과 같이 제작됩니다:
Script (JSON) → Synthetic Voice (TTS)
→ Caricature (FLUX / ComfyUI)
→ Lip Sync (InfiniteTalk)
→ Subtitles, screen, and props composited with ffmpeg → 1080×1920제가 중간에 제작 워크플로를 바꿨습니다. 클라이언트의 지시는 다음과 같았습니다:
먼저 시나리오를 만들고 Codex에게 영상 제작팀을 구성하게 합니다. 그 팀 안에서 리뷰를 진행하고, 대본과 제작 지시서를 만들게 합니다. 그 결과를 바탕으로 시각화한 뒤, 다시 Codex 팀에 리뷰를 요청하고, 피드백을 반영해 피드백이 소진되면 에피소드를 완성합니다.
팀에는 12개의 역할을 배정했습니다: 프로듀서, 콘텐츠 라이터, SNS 마케터, 시나리오 작가, 감독, 출연자(목소리와 연기), 촬영감독, 편집자, 모션 디자이너, 음향 엔지니어, SNS 운영자, 데이터 분석가. 그리고 교정자도 하나 더 두었습니다. 저는 Codex에게 회의 로그를 “요약하지 말고, 폐기된 아이디어와 충돌까지 그대로 포함해 원문 그대로 기록하라”고 지시했습니다.
잘 작동한 점
먼저 긍정적인 부분부터 말씀드리겠습니다. 비용만 이야기하면 이 방식 전체가 무시될 수도 있으니까요.
상호 불신이 효과적이었습니다. 미리보기 리뷰 회의에서 팀은 제가 대본을 옮기면서 실수로 포함한 과장 표현들을 지적했습니다. 예를 들어, 엔드 카드 문구(“진정으로 컴퓨터를 모든 가정에 가져다준 남자”)를 “성과의 단정적 귀속”이라며 거부했는데, 저는 이것을 오래된 대본에서 그대로 가져온 것이었습니다.
반대의 경우도 있었습니다. 별도 세션에서 SNS 게시물을 작성하게 한 뒤 대본과 비교해 보니, 두 차례의 검토에서 여섯 가지 차이가 드러났습니다:
Post draft: "The person who stated the correct answer at the beginning of the meeting"
Script: Sam worked alone on the document, and Pichai joined on page 42 → Not at the beginning
Post draft: "They never denied it"
Script: 8.81 seconds: "You haven't reverted it." → Denying the other person's point작성자 본인도 두 문제를 알아채지 못했습니다.
규칙을 저장소에 넣어 두니 지시를 간결하게 할 수 있었습니다. 중간쯤부터는 Codex에 대한 지시를 다음 한 줄로 줄였습니다:
Please complete one vertical short video, 1080×1920.
Script: scripts/v2/ep13_ellison.json
Both the process and assets are in this repository.
Verify the final output as a still image and make any necessary corrections at your discretion.회사 로고 금지, 재생 시간, 손을 얼굴 높이까지 올리지 말 것 같은 제약은 docs/PRODUCTION.md에 문서화해 두었습니다. Codex는 이를 스스로 읽고, 겹치는 텍스트나 얼굴 색 누락 같은 문제를 수정한 뒤 결과물을 내보냈습니다.
무인으로 돌아갔습니다. 저는 한 에피소드의 워크플로를 처리하는 프로덕션 드라이버를 작성했습니다: “회의 → 대본 및 캐리커처 → 오디오 → 립싱크 → 마무리 → 출시 준비.” 15화부터 38화까지 연속으로 실행되었고, 에피소드당 약 1시간이 걸렸으며 실패나 건너뛴 경우는 없었습니다.
문제는 내부에서 일어나고 있었습니다.
실제 사용량
Codex는 각 실행을 ~/.codex/sessions에 JSONL로 기록합니다. 각 세션의 마지막 항목에서 token_count를 합산하고 작업 디렉터리별로 분류하면 다음과 같았습니다:
| 세션 수 | 총 토큰 수 | |
|---|---|---|
| ai-boardroom | 344 | 159,366,148 |
| 기타 5개 프로젝트 | 31 | 약 9,860,000 |
ai-boardroom의 세부 내역은 다음과 같습니다:
Input 158,022,372
Of which cached: 147,115,008 (approx. 93%)
Output 1,343,776출력된 토큰은 고작 134만 개였습니다. 사용량의 99%는 입력이었고, 그중 90% 이상은 캐시된 입력이었습니다. 사실상 같은 컨텍스트를 계속 다시 전송한 셈입니다.
모든 실행에 사용된 모델은 gpt-6-astra였고, 별도로 지정한 적은 없었습니다. CLI 기본값을 계속 사용했습니다.
왜 20배나 잘못 계산했는가
저는 codex exec가 끝에서 출력하는 이 줄만 세었습니다:
tokens used
84,294이 방식에는 세 가지 문제가 있었습니다:
1. 회의가 뒤에서 별도 에이전트를 생성했습니다
12개 역할 회의를 맡기면 Codex는 각 역할마다 별도 에이전트를 생성했습니다. 실제로 10화의 회의록에는 다음과 같이 적혀 있습니다:
제작 책임자가 다섯 가지 역할을 위해 별도의 에이전트를 만들고, 첫 번째 라운드에서는 각 에이전트가 입력을 읽게 한 뒤, 두 번째 라운드에서는 대본 수정 R2를 진행했습니다.
이 하위 에이전트들은 별도의 세션으로 기록되었고, 그 토큰 사용량은 부모의 tokens used에 포함되지 않았습니다. 저는 101개 세션을 셌지만, 실제로는 344개였습니다.
2. 종료된 실행은 요약 줄을 출력하지 않음
10분 타임아웃이나 메모리 고갈로 중단된 실행은 최종 tokens used 줄을 출력하지 않습니다. 부분 사용량만 기록됩니다.
3. 이동할 때마다 모든 것을 다시 보냄
에이전트는 이동할 때마다 전체 대화 기록과 모든 파일을 다시 보냅니다. 제가 대본, 제작 지침, 참고용 최근 3개 에피소드, 미리보기 스틸을 매번 읽게 했기 때문에, 입력 크기는 세션 길이에 따라 이차적으로 증가했습니다. 캐싱이 있어도 이것은 사용량에 포함되었습니다.
사용량을 올바르게 계산하는 방법
CLI 출력에 의존하는 대신, 세션 로그에서 계산하세요:
import glob, json, os, collections
rows = collections.defaultdict(lambda: [0, 0]) # Sessions, Total Tokens
for f in glob.glob(os.path.expanduser("~/.codex/sessions/**/*.jsonl"), recursive=True):
cwd, last = None, None
for ln in open(f, encoding="utf-8", errors="replace"):
j = json.loads(ln)
p = j.get("payload", j)
cwd = cwd or p.get("cwd")
t = (p.get("info") or {}).get("total_token_usage")
if t:
last = t # Use the last value as it's cumulative
if last:
key = os.path.basename(cwd or "unknown")
rows[key][0] += 1
rows[key][1] += last["total_tokens"]
for k, (n, tok) in sorted(rows.items(), key=lambda x: -x[1][1]):
print(f"{k:24s} {n:4d} sessions {tok:>13,}")total_token_usage는 세션 내에서 누적되므로 마지막 항목만 사용합니다. 하위 에이전트들도 개별 세션으로 나타나므로, 누락되는 것이 없습니다.
다른 자동화의 함정
잘못된 사용량 제한 감지. 처음에는 드라이버가 출력의 "usage limit"를 제한 위반으로 표시했습니다. Codex가 드라이버 자신의 소스 코드를 읽었을 때 이 문자열이 출력에 나타나 30분 동안 멈췄습니다. 저는 실제 오류 줄만 확인하도록 수정했습니다:
if re.search(r"^ERROR: You've hit your usage limit", text, re.M):잘못된 세션 재개. 두 에피소드를 동시에 실행할 때 codex exec resume --last는 가장 최근 활성 세션을 선택합니다. 그것이 다른 에피소드의 세션이면 잘못된 대본을 수정하게 됩니다. 저는 출력에 있는 session id:를 추적하고, ID를 지정해 재개하도록 했습니다.
이미지 생성 서버가 메모리를 점유함. ComfyUI는 대기 중에도 약 11GB의 메모리를 유지했습니다. Codex를 동시에 실행하자 메모리 고갈이 발생했고, Codex가 충돌했습니다. 이미지를 생성하지 않을 때는 ComfyUI를 종료했습니다.
바꿔야 할 것
작업에 맞게 모델을 선택하세요. 최종 확정된 대사를 JSON으로 옮기거나, 정해진 절차에 따라 스틸을 검증하는 작업은 가장 무거운 모델이 필요하지 않았습니다. 품질 판단이 필요한 것은 기획 회의뿐이었습니다. 앞으로는 작업별로 codex exec -m로 모델을 지정하겠습니다.
회의에서 하위 에이전트를 생성하지 마세요. 각 역할에 대해 별도 맥락으로 나누는 것은 필요하지 않았으므로, 12개 역할을 모두 하나의 세션 안에서 작성하겠습니다.
읽는 파일 수를 제한하세요. 매번 참고용으로 최근 3개 에피소드를 제공하던 것을 멈추고, 작업에 필요한 것만 포함했습니다.
실행 전에 추정하세요. 에피소드당 토큰 수에 에피소드 수를 곱해, 무인 실행을 시작하기 전에 남은 주간 한도와 비교하세요. 각 에피소드는 약 500만 토큰을 사용했고, 13개 에피소드는 6500만 토큰이 필요했습니다.
"사용되지 않음"이라고 말하기 전에 남은 한도를 확인하세요. 한도에 도달하기 몇 분 전, 저는 "한도에 도달하지 않았다"고 말했습니다. 최신 로그만 확인했지, 남은 한도는 확인하지 않았습니다.
결론
12인 팀을 두겠다는 생각 자체는 틀리지 않았습니다. 회의는 과장을 잡아냈고, 대본상의 불일치는 비교를 통해 해결되었으며, 영상은 두 줄의 지침만으로 완성되었습니다.
부족했던 것은 그것을 움직이는 원리에 대한 인식이었습니다. 인원이 많아질수록 인건비가 늘어나듯, 에이전트가 많아질수록 토큰도 늘어납니다. 회의를 여는 데는 기록 담당자의 비용도 듭니다.
출처
- 원문: https://dev.to/orca_forge/aini12ren-nozhi-zuo-timuwoyan-zisasetara-1ri-ban-de1yi-6qian-mo-tokungaxiao-eta-30h7 (2026-09-27 · orca_forge)