작업을 여러 하위 에이전트에게 나누면 직관은 두 갈래로 갈라집니다. 추가 모델마다 비용을 더 내게 될 수도 있고, 오케스트레이터가 다시 읽지도 않을 파일 더미에 더는 파묻히지 않게 될 수도 있습니다. 연구 결과는 두 번째 쪽을 분명히 가리킵니다. 단, 반환값이 계속 compact하게 유지될 때만 그렇습니다.
하위 에이전트로 나누면 비용이 줄까, 늘까?
하위 에이전트로 작업을 분산하면 실제 압축이 일어날 때 비용이 줄어듭니다. 파일 약 6,100토큰을 읽고 약 420토큰짜리 요약을 반환하는 하위 에이전트는 약 9,500토큰의 중간 작업을 오케스트레이터의 컨텍스트 밖에 그대로 남겨둡니다 . 핵심 메커니즘은 위임이 아니라 압축입니다. 토큰을 아끼는 것은 모델 호출 수를 줄이는 일이 아니라, 관련 없는 컨텍스트를 공유 창에 덜 읽어들이는 일입니다.
빠른 답변: 오케스트레이터-워커 패턴은 하위 에이전트가 격리된 컨텍스트에서 작업하고 정제된 결과만 반환하기 때문에 토큰을 줄입니다. LangChain 벤치마크에 따르면 라우팅된 하위 에이전트 접근 방식은 5번의 호출에 약 9,000토큰을 쓰는 반면, 단일 구조 접근 방식은 약 15,000토큰을 씁니다. 모델 호출은 더 많지만 토큰은 40% 줄어듭니다.
가장 명확한 수치 사례는 LangChain의 멀티 에이전트 문서에서 나옵니다. 단일 구조의 “skills” 접근 방식은 로드된 컨텍스트가 누적되고 다시 처리되기 때문에 3번의 모델 호출에 약 15,000토큰이 들지만, 라우팅된 하위 에이전트 접근 방식은 5번의 호출에 약 9,000토큰이 듭니다 . 호출은 더 많고, 토큰은 40% 적습니다. 2025년 6월 13일 공개된 Anthropic의 Research 시스템도 같은 형태를 적용합니다. 리드 에이전트가 3~5개의 병렬 하위 에이전트를 띄우고 정제된 발견 사항만 종합하므로, 오케스트레이터 컨텍스트가 작업 범위에 비례해 커지지 않습니다 .
| 접근 방식 | 모델 호출 | 총 토큰 |
|---|---|---|
| 단일 구조 “skills” | 3 | 약 15,000 |
| 라우팅된 하위 에이전트 | 5 | 약 9,000 |
다만 기본 현실은 이런 기대를 조정하게 만듭니다. Anthropic은 에이전트가 채팅보다 대략 4배 많은 토큰을 쓰고, 멀티 에이전트 시스템은 약 15배에 이른다고 보고합니다 . 이 패턴은 각 하위 에이전트의 반환값을 compact하게 유지하는 출력 계약이 있을 때만 순효과가 납니다.
성능에서 “토큰 사용량 자체가 분산의 80%를 설명한다”는 점이 별도 컨텍스트 에이전트로 작업을 나누는 경험적 근거입니다 (source: Anthropic Engineering, 2025-06).
분해하기 전에 브리프 크기부터 정하기
브리프 크기를 정한다는 것은 각 하위 에이전트에게 쿼리와 제약 조건만 넘긴다는 뜻입니다. 전체 문서 코퍼스를 넘기면 안 됩니다. 위임 전에 오케스트레이터에 모든 것을 미리 로드하면 목적이 무너집니다. 핵심은 잡음 많은 읽기 작업이 아래쪽의 격리된 컨텍스트에서 일어나고, 리드는 그것을 직접 먹지 않는 데 있습니다. 규칙 로딩도 하위 에이전트별로 범위를 제한해야 합니다. 실제 한 모노레포에서 전체 범위 실행은 코드를 읽기도 전에 규칙을 약 16,800토큰 로드했지만, 백엔드 범위의 하위 에이전트는 약 4,300토큰만 로드했습니다. 파일 읽기가 시작되기도 전에 4배 줄어든 셈입니다.
작업을 나누기 전에 하위 작업들이 정말 병렬화 가능한지 확인해야 합니다. Anthropic은 코딩에는 연구보다 진정으로 분리 가능한 하위 작업이 적다고 지적합니다 . 서로 의존적인 작업에 하위 에이전트를 억지로 붙이면 중복 검색과 충돌하는 결과가 생깁니다. 그런 다음 모델 티어를 의도적으로 배정합니다. 리드는 frontier급 모델에 두고, 하위 에이전트는 Haiku처럼 더 빠르고 가벼운 모델에 맡기는 식입니다. 보고된 쿼리당 5–10배 절감은 분산 구조만이 아니라 이런 티어 분리에서 나옵니다.
아래쪽 전달마다 빡빡한 반환 계약을 강제하기
격리는 각 하위 에이전트가 장문의 텍스트가 아니라 압축된 결과를 반환할 때만 토큰을 아낍니다. 절감은 위임이 아니라 압축에서 나오므로, 어떤 하위 에이전트가 실행되기 전에 반환 계약을 먼저 정의해야 합니다. 내부적으로 10,000토큰의 작업을 하고 500토큰짜리 구조화 요약만 돌려주는 하위 에이전트는 9,500토큰을 아낍니다. 반대로 8,000토큰짜리 보고서를 반환하면 2,000토큰밖에 아끼지 못합니다 . 이를 고정하려면 네 단계를 따르세요.
- 출력 스키마를 먼저 정의합니다. 최대 bullet 수, 발견 사항별 필수 필드(심각도, 파일 참조, 한 문장 설명), 응답 본문에 대한 엄격한 글자 수 상한을 정합니다. 명시적인 상한이 없으면 하위 에이전트 격리는 공짜 컨텍스트 절감이 아닙니다.
- 저장한 뒤 참조만 넘깁니다. 하위 에이전트가 전체 출력을 파일시스템이나 아티팩트 저장소에 쓰게 하고, 오케스트레이터에는 가벼운 포인터만 반환하게 합니다. Anthropic은 대용량 출력을 대화 기록으로 복사하면 오버헤드가 커지고 충실도가 떨어지기 때문에 이를 권장합니다 . Microsoft의 Azure 가이드 역시 공유 상태를 외부에 저장하고 필요한 최소 범위로 제한하라고 조언합니다 .
- 권한으로 역할을 분리합니다. 위임(Task) 도구를 가진 에이전트에서는 편집/쓰기 권한을 제거하고, 실행자가 자기 하위 위임을 다시 생성하지 못하게 막습니다. Praetorian은 프로덕션에서 바로 이 분리를 강제해, 코디네이터가 직접 일을 해버리거나 실행자가 걷잡을 수 없는 컨텍스트 루프를 여는 일을 막습니다 .
- 경로가 아니라 결과를 평가합니다. 고정된 중간 경로를 따랐는지가 아니라 최종 사실성 및 인용 품질을 채점합니다. 하위 에이전트의 추론 흔적은 설계상 버려지므로, 경로를 검사하는 평가는 엉뚱한 것을 측정합니다.
“telephone game”을 최소화하려면 “하위 에이전트가 출력을 파일시스템에 쓰게 하라”고 Anthropic Engineering은 자사의 멀티 에이전트 연구 시스템에 대해 설명합니다 (source: Anthropic).
경유가 늘었는데도 청구액이 오르는 경우
위임은 그것을 정당화할 만큼의 압축이 일어나지 않을 때마다 비용을 끌어올립니다. 가장 흔한 실패는 하위 에이전트가 긴 글 덩어리를 그대로 돌려주는 경우입니다. 내부 추론에 10,000토큰을 쓰고 8,000토큰을 돌려준다면 절감분은 2,000토큰뿐입니다. 500토큰짜리 구조화 요약으로 돌려줄 때 절약되는 9,500토큰과는 차이가 큽니다 . 강제된 출력 계약이 없으면, 격리는 비용을 회수하지 못합니다.
반복해서 나타나는 실패 유형은 세 가지입니다.
- 공유 스레드 구조. AutoGen의 Group Chat Manager는 새 발화자에게 이전 참가자들의 모든 메시지를 노출하므로, 매 턴마다 컨텍스트가 누적됩니다. 제약을 걸지 않으면 격리는 유지되지 않습니다 .
- 겹치는 책임 범위. 중복 검색은 종합 단계의 부담을 키웁니다. Amazon Bedrock의 supervisor 지침도 협업자 사이의 중복을 최소화하라고 명시적으로 권고합니다 .
- 병렬화할 표면이 없음. 폭이 좁은 순차적 절차 작업에서는 2026년 arXiv 논문이 인컨텍스트 프롬프팅이 외부 오케스트레이션보다 더 나을 수 있다고 봅니다. 흩어 보낼 일이 없다면 분산 구조의 호출당 기본 비용이 어떤 절감분보다 커집니다 .
코딩에는 연구보다 진정으로 병렬화할 수 있는 작업이 더 적다는 Anthropic의 언급이 실무적 신호입니다. 패턴을 폭에 맞추지 않으면, 추가 경유는 비용만 더합니다.
비용 일부만으로 폭을 가로로 넓히기
반환 계약이 강제되면, 폭은 저렴하게 확장할 수 있는 축이 됩니다. Anthropic의 Research 시스템은 복잡한 다중 도메인 질의에서 병렬화로 연구 시간을 최대 90% 줄였다고 보고합니다 . 이 이득은 엄격한 출력 스키마가 각 하위 에이전트의 반환을 작게 유지할 때만 성립합니다. 폭은 품질도 끌어올립니다. OpenAI의 BrowseComp(2025년 4월 10일 공개, 검증 가능한 어려운 브라우징 문제 1,266개)에서는 샘플링한 출력 64개를 집계했을 때 단일 시도보다 성능이 15~25% 향상됐습니다 . 더 많은 문서를 하나의 프롬프트에 밀어 넣는 것보다 끈기와 검색 전략이 낫다는 증거입니다.
다음으로는 두 가지 레버가 있습니다. Claude Code의 하위 에이전트 문서는 파일 읽기나 로그 검색을 맡는 하위 작업자에게 Haiku급 모델을 권장합니다 . 출력 계약을 단단히 만든 뒤 적용할 수 있는 구체적인 모델 티어 분리입니다. 그리고 MAO-ARAG(arXiv, 2025년 8월 1일)는 coordinator를 비용 패널티가 있는 RL 정책으로 훈련해 질의 복잡도에 따라 executor를 선택합니다. 이는 손으로 짠 분해가 아니라 학습된 분해로 가는 방향을 보여줍니다. 결론은 이렇습니다. 폭이 필요할 때 fan out하고, 모든 반환을 제한하며, 단순 노동은 더 저렴한 티어로 라우팅하세요.
자주 묻는 질문
멀티 에이전트 시스템은 왜 일반 채팅보다 토큰을 15배 더 쓰나요?
각 에이전트 호출마다 자체적으로 전체 컨텍스트를 실어 나르고, 오케스트레이터는 각 하위 에이전트가 돌려주는 요약을 다시 모아 처리하기 때문입니다. Anthropic은 에이전트가 채팅 상호작용의 약 4배, 멀티 에이전트 시스템은 약 15배의 토큰을 사용한다고 보고합니다 . 이 수치는 호출 한 번당 비용이 아니라 시스템 전체 기준입니다. 하위 에이전트의 출력 계약을 빡빡하게 잡으면, 예를 들어 bullet 개수 제한, 필수 필드, 엄격한 글자 수 상한을 두면 이 비용은 크게 내려갑니다. 그래서 이 패턴은 작업 가치가 높을 때에만 비용 대비 효과가 납니다 .
서브에이전트는 실제로 오케스트레이터의 컨텍스트를 어떻게 작게 유지하나요?
하위 에이전트가 파일 읽기, 검색, 로그 탐색처럼 출력이 많은 작업을 자기만의 격리된 컨텍스트 창 안에서 처리하고, 최종적으로 정제된 요약만 반환합니다. 오케스트레이터가 받는 것은 원본 파일 내용이나 중간 추론 흔적이 아니라 결과이므로, 작업을 서브에이전트들로 나눠도 부모 컨텍스트가 복잡도에 비례해 커지지 않습니다 . Claude Code 문서도 같은 관점으로 설명합니다. 다시 참조하지 않을 출력으로 메인 대화가 넘쳐날 것 같은 부수 작업에는 서브에이전트를 쓰라는 것입니다 .
토큰을 실제로 아끼려면 반환 계약을 얼마나 구체적으로 정해야 하나요?
막연한 지시가 아니라 명시적인 스키마가 필요합니다. 최대 bullet 개수, 각 finding에 필요한 필드, 예를 들어 심각도, 파일 참조, 한 문장 설명을 지정하고, 여기에 엄격한 글자 수 상한까지 둡니다. 서브에이전트가 내부적으로 10,000토큰어치 작업을 하고 500토큰짜리 구조화 요약만 반환하면 9,500토큰을 아낍니다. 반대로 8,000토큰짜리 보고서를 반환하면 절감분은 2,000토큰뿐입니다 . “찾은 내용을 요약하라” 같은 지시는 대체로 길고 비싼 응답을 낳습니다. 절감은 위임 자체가 아니라 압축에서 나옵니다.
오케스트레이터-서브에이전트 패턴이 맞지 않는 경우는 언제인가요?
하위 작업들이 서로 강하게 의존해 실제로 병렬 실행할 수 없을 때, 또는 분산 구성의 호출당 기본 비용이 압축 이득보다 커지는 짧은 절차형 작업에서는 적합하지 않습니다. Anthropic은 코딩에는 연구보다 진정으로 병렬화할 수 있는 작업이 더 적다고 설명하고 , LangChain은 복잡한 작업이라고 해서 모두 멀티 에이전트 아키텍처가 필요한 것은 아니라고 경고합니다 . 또한 2026년 arXiv 논문은 절차형 작업에서는 인컨텍스트 프롬프팅이 외부 오케스트레이션보다 더 나은 성능을 낼 수 있다고 주장합니다.
Anthropic의 멀티 에이전트 Research 시스템은 실제 품질을 높이나요, 아니면 비용만 줄이나요?
둘 다입니다. Anthropic의 내부 벤치마크에서는 Claude Opus 4를 리드로, Claude Sonnet 4를 서브에이전트로 둔 멀티 에이전트 구성이 breadth-first 연구 질의에서 단일 에이전트 Claude Opus 4보다 90.2% 더 좋은 성능을 냈고, 복잡한 작업에서는 병렬화로 연구 시간이 최대 90% 줄었다고 보고했습니다 . 같은 연구는 토큰 사용량만으로도 성능 변동의 80%를 설명한다고 봤습니다. 이것이 모든 내용을 하나의 프롬프트에 밀어 넣는 대신, 서로 분리된 컨텍스트를 가진 에이전트들에 작업을 분산하는 경험적 근거입니다 .
이 글이 도움이 되셨다면, 새 글이 올라올 때마다 이메일로 받아보세요.
