Claude Code 멀티 에이전트 토큰 절약: 왕복 횟수와 맥락 크기 줄이기

에이전트 세 개를 띄웠는데 토큰은 세 배보다 훨씬 많이 나갑니다. 각자 일한 양을 더해도 사용량이 설명되지 않습니다. 빠진 비용은 대개 에이전트끼리 주고받은 메시지 쪽에 있습니다.

세션 수만 세면 놓치는 비용

흔히 멀티 에이전트 비용을 에이전트 수에 비례한다고 이해합니다. Claude Code 비용 문서도 에이전트 팀의 토큰 사용량이 팀 크기에 대체로 비례한다고 설명합니다. 각자 맡은 일만 할 때는 맞는 말입니다. 그런데 세션끼리 대화를 시작하면 이 계산이 어긋납니다.

Claude Code 세션이 일하는 단위는 요청입니다. 메시지 한 통을 처리하려고 세션이 깨어나면 그 세션의 대화 맥락이 함께 모델로 들어갑니다. 저는 비용을 이렇게 보는 편이 맞다고 생각합니다.

비용 ≈ 세션이 깨어난 횟수 × 그때의 맥락 크기

세션을 하나 줄여도 나머지 세션이 더 자주 깨어나면 비용은 줄지 않습니다. 줄여야 할 숫자는 두 개입니다.

깨어날 때마다 내는 캐시 값

프롬프트 캐시가 있으니 괜찮다고 생각하기 쉽지만, 캐시 읽기도 공짜가 아닙니다. Anthropic 가격표 기준으로 Opus 5.5의 캐시 읽기는 기본 입력 가격의 0.05배입니다. 캐시 쓰기는 5분 캐시가 1.25배, 1시간 캐시가 2배입니다.

맥락이 10만 토큰인 세션을 깨우는 경우로 계산하면 차이가 분명합니다.

상황	입력 토큰으로 환산한 비용
캐시가 살아 있을 때	5,000 토큰분
5분 캐시가 만료돼 다시 쓸 때	125,000 토큰분
1시간 캐시가 만료돼 다시 쓸 때	200,000 토큰분

답변 토큰을 뺀 입력 비용만 계산했고, 캐시 수명 안에서는 그 맥락이 이미 저장돼 있다고 가정한 값입니다.

캐시가 만료된 세션을 깨우면 25배에서 40배를 냅니다. 오래 놀던 세션에 「확인했습니다」 한 줄을 보내는 일이 가장 비싼 메시지가 될 수 있습니다. 캐시 수명은 구독의 메인 대화가 1시간, API 키가 5분입니다. 서브에이전트는 구독에서도 기본이 5분이고 subagentPromptCacheTtl 설정으로 늘릴 수 있습니다.

확인 답장이 왕복을 두 배로 만드는 구조

지휘 세션이 작업자 세션에 일을 맡기는 가장 단순한 흐름을 보겠습니다. 맡기고 끝났다고 알리기만 하면 두 번 깨어납니다. 양쪽이 예의 바르게 「받았습니다」를 주고받으면 네 번이 됩니다. 작업은 그대로인데 호출만 두 배입니다.

그래서 저라면 메시지 규칙부터 정하겠습니다. 작업 지시와 완료 보고만 보내고, 수신 확인과 진행 상황 공유는 금지합니다. 답이 필요 없는 메시지는 보내지 않습니다.

전체 공지는 더 비쌉니다. 작업자가 N개일 때 한 세션의 공지는 나머지 세션을 모두 깨웁니다. 작업자끼리 자유롭게 대화하게 두면 한 세션이 던진 질문 하나가 전원의 요청이 됩니다. 저는 작업자끼리 직접 말하지 않고 지휘 세션만 거치는 구조를 기본으로 두는 쪽을 권합니다.

메시지 본문 대신 파일 경로

메시지에 담은 내용은 받은 세션의 맥락에 남아 이후 모든 요청에 다시 실립니다. 긴 조사 결과를 본문으로 보내면 받은 쪽은 그 내용을 쓰지 않더라도 계속 비용을 냅니다.

긴 결과물은 파일에 쓰고 경로와 두세 줄 요약만 보내면 됩니다. 필요한 세션만 읽으면 되고, 내용을 두 번 옮기지 않습니다. 서브에이전트가 메인 대화에 요약만 돌려주는 것도 같은 이유입니다.

가장 자주 깨어나는 지휘 세션의 맥락

지휘 세션은 모든 완료 보고를 받으니 깨어나는 횟수가 가장 많습니다. 같은 맥락 1만 토큰이라도 여기에 쌓이면 곱해지는 횟수가 다릅니다.

지휘 세션은 코드를 직접 읽지 않고 일을 나누고 결과를 판단하는 데만 쓰는 편이 좋습니다. 파일을 열어 보고 싶어질 때가 작업자에게 맡길 때입니다.

맥락을 줄일 때는 순서가 있습니다. 단계가 끝나면 필요한 결정만 파일에 남기고 /clear로 비우는 것이 가장 쌉니다. 비용 문서에 따르면 /clear에는 비용이 들지 않습니다. 대화를 이어 가야 해서 /compact를 쓴다면 캐시가 살아 있을 때 하는 것이 좋습니다. 압축도 요청 하나이고, 캐시가 만료된 뒤에는 압축할 대화를 캐시 없이 다시 처리합니다.

끝난 작업자도 그대로 두면 안 됩니다. 쓸 일이 없는 세션은 닫습니다. 다시 부를 일이 있어도 캐시가 만료된 뒤라면 새 세션이 더 쌀 때가 많습니다. 다만 앞서 쌓은 맥락이 다시 필요한 일이라면 그 맥락을 다시 읽는 비용과 비교해야 합니다.

모든 세션에 곱해지는 시작 맥락

세션을 열 때 들어가는 지침 파일과 스킬 목록은 세션 수만큼 곱해집니다. 긴 CLAUDE.md는 한 세션에서는 작아 보여도 작업자가 다섯이면 다섯 벌입니다. 비용 문서는 특정 작업에만 쓰는 긴 지침을 스킬로 옮기라고 권합니다. 쓰지 않는 MCP 서버도 끄는 것이 좋지만, 도구 정의는 기본적으로 필요할 때 불러오므로 효과는 지침보다 작을 수 있습니다. /context로 무엇이 얼마나 차지하는지 먼저 확인하는 것이 순서입니다.

맥락이 필요 없는 일에 쓰는 낮은 모델

메시지 전달이나 단순 확인에 가장 높은 모델을 쓸 이유는 없습니다. 서브에이전트는 정의 파일의 model 칸으로 Haiku 같은 낮은 모델을 지정하고, effort 칸으로 effort도 낮출 수 있습니다.

세션을 시작할 때 고르는 것이 중요합니다. 캐시 문서에 따르면 대화 도중 모델을 바꾸면 다음 요청이 대화 전체를 캐시 없이 읽습니다. 값을 아끼려고 바꾼 모델이 그 턴에는 오히려 비쌀 수 있습니다.

포크도 알아 둘 만합니다. 시스템 프롬프트, 도구, 대화 이력을 부모에게서 그대로 물려받아 첫 요청이 부모의 캐시를 읽습니다. 일반 서브에이전트는 자기 캐시를 처음부터 만듭니다. 같은 맥락이 필요한 일이라면 포크가 유리합니다.

나누지 말아야 할 일의 기준

토큰을 가장 많이 줄이는 방법은 애초에 나누지 않는 것입니다. 저는 두 가지만 묻습니다. 작업이 서로 독립적인가, 그리고 끝났을 때 결과만 받아도 되는가입니다. 둘 다 그렇다면 나눌 만합니다. 중간에 서로의 결정을 계속 확인해야 한다면 한 세션에서 순서대로 하는 편이 대체로 쌉니다. 에이전트 팀 문서도 순차 작업이나 의존 관계가 많은 일에는 단일 세션이나 서브에이전트가 낫다고 적고 있습니다.

위 배수는 API 가격 기준입니다. 구독 사용량 한도에 같은 비율로 반영되는지는 확인하지 못했습니다. 세션 간 메시지가 어떤 맥락으로 들어가는지도 오케스트레이션 도구마다 다릅니다. 그러니 이 글의 순서를 따르기 전에 /usage와 /context로 자기 구성에서 어디에 토큰이 쓰이는지부터 보시길 권합니다.