30일 동안 2,250억 Claude Code 토큰 사용과 모델명을 명시하지 않은 서브 에이전트들

코딩 에이전트에 대한 저의 규칙은 '비싼 모델로 계획하고, 더 저렴한 모델로 실행하는 것'입니다. 그리고 지난 가장 바빴던 30일 동안 발생한 모든 Claude Code 토큰을 합산해 보았습니다. 9월 15일부터 10월 14일까지 총 736,633개의 API 응답에서 2,251억 개의 토큰이 사용되었습니다. 이 중 Opus 모델이 94%를 차지했습니다. 그 두 주 동안은 대부분의 서브 에이전트들이 모델명을 명시하지 않았기 때문에 부모 세션으로부터 Opus를 상속받았고 저는 이를 알아차리지 못했습니다.

저에게는 Mac과 가정용 PC가 있었을 뿐이며, 바쁜 날에는 동시에 10개 이상의 에이전트를 구동했습니다. 만약 에이전트 한두 개만 실행한다면, 여전히 적용되는 부분은 관련 없는 작업 사이에 /clear를 사용하는 것, 모든 서브 에이전트에 모델명을 명시하는 것, 그리고 로그가 보존되도록 cleanupPeriodDays를 높이는 것입니다.

97.9%는 모델이 컨텍스트를 다시 읽는 데 사용됨

다른 사람들도 훨씬 적은 로그에서 동일하게 97~98%라는 수치를 발견했습니다 ([AgentsRoom이 38억 토큰을 계산]). 모델은 상태가 없기 때문에(stateless), 에이전트가 매번 대화 전체를 다시 전송합니다: 시스템 프롬프트, 도구 정의, 읽었던 모든 파일, 이전 모든 메시지. 프롬프트 캐시(prompt cache)는 변경되지 않은 부분을 처리하며, 이 부분이 거의 전부입니다.

평균 응답은 약 305,000개의 컨텍스트 토큰을 사용했으며, 그중 299,000개는 캐시에서 왔고, 약 1,000개를 작성했습니다. 모델이 작성하는 모든 토큰에 대해 291개의 토큰을 다시 읽었습니다.

제 토큰의 73%를 처리한 Claude Opus 5.5의 경우, 캐시 읽기는 입력 가격의 5%가 비용이 듭니다 (pricing). 최소 가격으로 계산하면 제 월 사용료는 약 $97,000에 달하며, 캐시를 사용하지 않았다면 그보다 대략 열 배나 많았을 것입니다. 저는 고정 요금제인 여러 코딩 플랜을 사용하고 있어 이 수치는 단지 비교 기준일 뿐입니다.

재읽기(Re-reads)도 평면 요금제에 포함됩니다. Claude Code의 비용 문서에 따르면, "하루 종일 열려 있던 세션에서 한 줄짜리 질문이라도 전체 대화 내용만큼 사용량을 끌어당깁니다". 작성된 토큰 1개당 재읽기되는 토큰이 291개에 달하므로, /clear를 사용하여 관련 없는 작업 사이에 컨텍스트(context)를 작게 유지하는 것이 이득이며, 테스트 실행(test runs), 로그(logs), 문서 조회(doc lookups)와 같은 장황한 작업은 서브 에이전트(subagent)로 분리하여 보내고 요약본만 받도록 하는 것이 좋습니다.

더 많은 에이전트, 더 긴 운영 시간

8월 31일 주에 제 에이전트들은 40억 토큰을 사용했습니다. 네 주 후에는 일주일에 608억 토큰을 사용했습니다.

에이전트당 작업량은 거의 변하지 않았습니다. 에이전트 시간당 토큰 수는 매주 5,200만에서 8,000만 사이에 머물렀습니다. 두 가지 다른 것이 바뀌었습니다. 동시에 운영되는 평균 에이전트 수가 2.0개에서 6.9개로 늘어났고, 최소한 하나의 에이전트가 작동하는 시간이 주당 38시간에서 145시간으로 늘어났습니다. 이는 거의 하루 21시간에 달하므로, 제가 잠든 동안에도 에이전트들이 계속 작업하도록 했습니다.

세 가지를 곱하면 총량이 나옵니다: 첫째 주에는 2.0개 에이전트 × 38시간 × 5,200만 토큰 ≈ 40억 토큰, 그리고 네 주 후에는 6.9개 × 145시간 × 6,000만 토큰 ≈ 600억 토큰입니다.

오랫동안 병목 현상은 저였습니다. 한 번에 몇몇 에이전트가 동시에 작동하는 것도 저를 압도했습니다. 저는 금융학을 공부하면서 '관리 범위(span of control)'에 대해 배웠습니다. 이는 한 관리자가 이끌 수 있는 인원수를 의미합니다. McKinsey의 버전에 따르면, 복잡하고 다양한 업무에는 3명에서 5명의 직속 부하직원에게 적용되며, 일상적이고 표준화된 업무의 경우 15명이 넘는 인원에게 적용됩니다. 저는 에이전트에서도 같은 것을 발견했습니다. 모호한 작업은 몇 분마다 저를 필요로 합니다. 하지만 서면 브리핑(written brief)과 시작 전에 고정된 '완료 확인' 절차, 그리고 공유 작업 목록을 갖춘 작업은 제가 없어도 한 시간 동안 진행될 수 있습니다.

그래서 저는 작업을 더 일상적으로 만들었습니다. 각 에이전트에게 브리핑을 제공하고 상태를 파일에 기록하게 했습니다. 한 관리자 에이전트는 홈 PC에서 실행되어 누가 무엇을 하고 있는지 대시보드를 유지하며, 저에게 필요한 결정 사항만 가져옵니다. 다른 두 가지 요소가 도움이 되었고, 저는 그 효과를 제 것과 분리할 수 없습니다: Opus 5.5는 9월 23일에 출시되었고, 홈 PC는 9월 28일부터 작업을 시작했습니다.

성과 (What it built)

토큰(Tokens)과 에이전트 시간(agent-hours) 모두 투입 자원입니다. 같은 30일 동안 저와 제 에이전트들은 21개의 리포지토리에서 총 1,029개의 풀 리퀘스트(pull requests)를 병합했습니다: 406개의 기능 개선(features)과 293개의 수정 사항(fixes)입니다. 이는 병합된 풀 리퀘스트당 약 3 에이전트 시간을 사용한 것입니다. 이 중 거의 모든 것이 고객 대면 서비스와 관련되었습니다:

• 생산성 SaaS 제품의 전면 재구축: 새로운 로그인 기능, 팀 작업 공간, 웹훅을 갖춘 공개 API, AI 어시스턴트가 제품을 사용할 수 있는 MCP 서버, 자체 크레딧 원장을 통한 결제 시스템, 재구축된 변경 모니터링 및 알림, 그리고 재설계된 대시보드.
• 이벤트 플랫폼: 안드로이드 앱, 티켓팅, 워크숍 좌석 배정, 출입 확인(door check-in), 533개의 개인 요약 이메일, 그리고 15개의 파트너 보고서.
• 처음부터 구축한 디렉토리 사이트: 회사 및 위치 페이지, 3,555개 회사 로고, 로그인 및 유료 계정 기능.
• 금융 제품을 위한 200개의 세금 및 법률 설명 자료와 네 가지 무료 도구.

에이전트들은 또한 제가 수동으로 하던 대부분의 QA 작업(설계 대비 일치성 검사, 데이터 추출기에 대한 골든 테스트, 전환 전에 두 가지 결함을 발견한 섀도우 실행)을 수행했습니다. 로그가 알려주지 못하는 것은 어떤 토큰이 어떤 결과를 만들어냈는지, 또는 그것들이 얼마만큼의 가치가 있는지입니다.

4.5일 동안, 4080만 토큰 사용, 커밋은 제로

한 오픈소스 프로젝트에서 목표 모드(agent가 중지 조건이 충족될 때까지 계속 실행되는 방식)로 Codex를 한 번 실행했는데, 이 작업은 4.5일 동안 진행되었고 4080만 토큰을 사용했으며 커밋이나 제품 코드는 전혀 생성하지 못했고, 약 2GB의 아티팩트만 남겼습니다. 토큰 대시보드 상으로는 마치 4년 반 동안 꾸준히 작업한 것처럼 보입니다.

이 목표에는 두 가지 결함이 있었습니다. 첫째, 중지 조건은 오직 제가 수행할 수 있는 단계가 필요했기 때문에 실행이 끝날 수 없었습니다. 둘째, 반복 간의 규칙은 '열린 요구사항을 증거로 바꾸는 다음 행동을 취하라'였습니다. 가장 저렴한 증거는 더 많은 증거였으므로, 에이전트는 스키마, 히스토리, 그리고 1.7GB짜리 JSON 일정을 작성했습니다. 저는 이 목표를 작동하는 소프트웨어 중심으로 다시 작성하고, 카운트되지 않는 단축키 이름을 붙였으며, 세 번의 기회(three-strikes rule) 규칙을 추가했습니다. 다음 세션에서는 17개의 커밋이 이루어졌습니다.

회고 이메일 한 통에 34만 토큰 비용 발생

저는 에이전트들에게 534명의 이벤트 참석자 각각에게 개인적인 회고 이메일을 작성하고 검증하게 했습니다(533명에게 발송되었고, 한 명은 출입문에서 스캔된 적이 없었습니다). 각 사람의 이메일에는 약 34만 토큰이 소요되어 목록 전체로는 1억 8천만 토큰으로 예상되었습니다. 저는 약 5500만 토큰 사용 후 중단하고, 의도적으로 오류를 심은 다섯 개의 이메일을 더 저렴한 모델로 테스트했으며, 나머지 부분은 그 모델을 사용하여 약 5300만 토큰에 완료했습니다. 즉, 총 1억 1천만 토큰 정도가 소요되었으며, 이는 단위 토큰당 가격이 낮았습니다.

디렉토리를 위해 저는 4255개 회사 각각의 로고가 필요했습니다. 모든 홈페이지를 모델에 전송했다면 약 8500만 토큰이 들었을 것입니다. 일반 코드가 그중 2003개를 처리했고, 불분명한 1603개는 작은 Haiku 리뷰어들에게 보내져 1552개의 로고를 선택했습니다. 그리고 기본 설정으로 두 항목에 대한 Codex 스모크 테스트는 가장 유능한 모델을 최고 노력도로 사용하여 전체 5시간 사용 시간을 소진했습니다.

모델명을 명시하지 않은 서브 에이전트들

제가 직접 설정한 규칙과 로그를 비교해 보니, 저는 대부분 그 규칙을 따르지 않았습니다. 10월에는 제 서브 에이전트 토큰의 97%에서 98%가 Opus로 실행되었습니다. 9월 말부터 10월 초까지는 제 서브 에이전트 중 59%에서 80%가 모델명을 명시하지 않았고, 모델명을 명시하지 않은 서브 에이전트는 부모의 설정을 상속받습니다.

제가 머릿속으로 설계했던 라우팅(routing)은 설정에 반영되지 않았습니다. 그것이 실제로 구현된 것은 10월 11일이었는데, 이때 PC의 워커 세션들이 Z.ai의 더 저렴한 모델인 GLM-5.3으로 실행되기 시작했습니다. 그 다음 주에는 더 저렴한 모델들이 전체 출력 토큰의 약 5%를 차지하며 14%에 달하는 출력을 작성했습니다.

저가형 모델들은 자체적인 문제점들을 가져왔습니다. project 디렉토리에서, 저가형 모델 폴백(fallback)은 6센트에 84번 호출되었지만 잘못된 답변만 7개를 추가했을 뿐 올바른 답변은 없었습니다. 이제 폴백 기능은 알려진 답이 있는 소수의 경우에만 전환되는 것이 도움이 된다는 것을 보여줍니다. 제 Sonnet 테스트는 Opus가 사용한 토큰과 비슷한 양을 사용했기 때문에, 절약액은 오직 토큰당 가격에서 나옵니다.

세션 중간에 모델을 변경하면 캐시(cache)가 사라집니다. Claude Code에서는 각 모델이 자체적인 프롬프트 캐시를 가지고 있기 때문에, 전환 후 첫 번째 요청은 캐시 히트 없이 전체 대화를 재읽게 됩니다 (prompt caching docs). 대신 저가형 부분에 대해서는 서브 에이전트를 생성하는 것이 좋습니다.

제가 처음 모델을 비교했을 때 오해했습니다. MiniMax가 세션당 토큰을 두 배로 사용한다고 했지만, 그 56개 세션 중 53개가 하나의 프로젝트에 속해 있었습니다. 두 모델 모두 작업했던 단일 프로젝트에서는 결과가 역전되었으나, 어느 쪽으로도 의미를 부여할 만큼 충분히 적은 세션이었습니다. 저는 워크로드(workloads)를 비교하고 있었던 것입니다.

Claude Code에서 모델은 서브 에이전트 정의의 model 필드에 지정됩니다: haiku, sonnet, opus와 같은 전체 모델 ID, 또는 inherit을 사용할 수 있습니다. 별도로 모델명을 지정하지 않은 모든 서브 에이전트의 모델을 변경하려면 CLAUDE_CODE_SUBAGENT_MODEL 설정을 사용하세요 (subagent docs).

---
name: test-runner
description: "테스트 스위트를 실행하고 실패한 내용만 보고합니다"
...

작업 도중 충돌했던 제한 사항들

이렇게 많은 에이전트들을 실행하면서, 저는 다음 목록의 모든 항목을 최소 한 번씩 경험했습니다:

30개의 에이전트들이 돌아올 수 있었던 이유는 그들의 상태가 대화 내용에 있는 것이 아니라 파일과 공유 작업 목록에 저장되어 있었기 때문입니다. Claude Code는 기본적으로 세션당 20개의 실행 중인 서브 에이전트로 제한하며 (CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS로 변경 가능), 최신 버전에서는 사용량 제한이 리셋되기를 기다렸다가 중단된 작업을 스스로 계속할 수 있습니다.

신선한 검토자들, 그리고 0.48점을 준 심사위원

세금 및 법률 설명 시리즈를 위해, 작가 에이전트들은 자신들의 주장을 확인하고 녹색(green)으로 보고했습니다. 모든 진술에 대해 원본 자료를 열어보도록 지시받은 신선한 검토자들조차도 자신이 검토한 모든 게시물에서 수정을 발견했습니다. 제가 전체 개수를 가지고 있는 세 개의 게시물에서는, 그들이 각각 64개 중 11개, 44개 중 11개, 그리고 26개 중 17개의 진술을 수정했습니다.

또한 저는 검사기(checker)도 테스트했습니다. 한 실험에서 저는 나중에 질문했는지 여부에 따라 에이전트 보고서를 분류했는데, 약 7%가 그러했습니다. 각 주장을 에이전트의 도구 로그와 대조하는 LLM 심판은 이를 찾아내는 데 우연 이상의 성능을 보이지 못했습니다(AUROC 0.48): 모든 종류의 보고서에서 전체 주장 중 약 70%를 '증거 없음'으로 표시했습니다. 단순한 단어 수 계산 분류기(TF-IDF)는 같은 레이블에서 0.65점을 기록했습니다. 둘 다 사용하기에 충분히 좋지는 않았지만, 저렴한 기준선(baseline)이 심판보다 나았습니다.

제가 측정하고, 여러분의 것을 확인하는 방법