서브에이전트 출력 압축 — 토큰 절약의 잊힌 세 번째 축, 메인 컨텍스트 예산

AI 에이전트에게 일을 시킬 때, 나는 작은 일을 서브에이전트(subagent, 메인 대화가 특정 작업만 떼어 맡기는 하위 에이전트)에게 자주 위임한다. "이 함수 어디서 정의됐는지 찾아와", "이 파일 한 군데만 고쳐와" 같은 것들이다. 위임은 공짜처럼 느껴졌다. 메인 대화는 깨끗하게 유지되고, 지저분한 탐색은 서브에이전트가 대신 해주니까.

그런데 긴 세션에서 이상한 일이 반복됐다. 위임을 열댓 번쯤 하고 나면 메인 대화의 컨텍스트(context, 모델이 한 번에 기억할 수 있는 대화 창)가 바닥나 작업이 중간에 끊겼다. 이유를 뜯어보고 나서야 알았다. 서브에이전트가 돌려준 결과 텍스트는 메인 대화에 그대로(verbatim) 삽입된다. 위임이 끝날 때마다 그 결과가 메인 컨텍스트를 조금씩 갉아먹고 있었던 것이다. 위임은 공짜가 아니었다.

토큰 절약에는 세 번째 축이 있다

토큰(token, 모델이 글을 처리하는 최소 단위이자 비용·용량의 계량 단위)을 아끼는 이야기를 하면 보통 두 가지를 떠올린다. 입력을 줄이거나, 출력을 줄이거나. 그런데 여러 서브에이전트에게 일을 나눠 주는 오케스트레이션(orchestration, 메인 대화가 지휘자처럼 하위 에이전트들에게 일을 분배·조립하는 구조)에서는 세 번째 축이 하나 더 있다.

다이어그램 설명. "AI 에이전트 토큰 절약"이 세 갈래로 갈라지는 구조를 보여준다. "입력 토큰"과 "출력 토큰"은 익히 아는 두 축이다. 잘 안 보이는 세 번째가 "메인 컨텍스트 예산"이다 — 서브에이전트에게 일을 위임할 때마다 그 결과가 메인 대화에 쌓여 컨텍스트 한도를 조금씩 소모하는데, 이 소모량 자체를 줄이는 축이다. 핵심은 이 축이 한 번의 요청 크기가 아니라 세션 전체의 수명을 결정한다는 것이다. 입력·출력은 요청 하나의 비용이지만, 메인 컨텍스트 예산은 "이 세션이 몇 번의 위임을 견디고 끝까지 갈 수 있는가"를 정한다.

왜 위임 한 번이 메인 컨텍스트를 갉아먹는가

서브에이전트를 부르면, 그 에이전트는 자기만의 컨텍스트에서 탐색하고 마지막에 결과 한 덩어리를 돌려준다. 문제는 그 결과가 메인 대화에 요약 없이 그대로 붙는다는 점이다. 흔히 쓰는 vanilla(기본 제공, 별도 개조 없는) 탐색 에이전트는 발견한 내용을 친절한 산문으로 설명한다. "이 심볼은 여기에 정의돼 있고, 이런 맥락에서 쓰이며, 아마 이렇게 고치면 좋을 것 같습니다" 하는 식으로. 이 산문 한 편이 대략 2,000토큰이다. 그리고 그 2,000토큰이 통째로 메인 컨텍스트에 눌러앉는다.

여기서 소재로 삼은 도구가 caveman이다. caveman-speak(원시인 말투처럼 관사·조사·수식어를 걷어내고 핵심 뼈대만 남긴 압축 표기)로 결과를 돌려주도록 서브에이전트를 개조한 프리셋 모음을 cavecrew라고 부른다. 같은 발견을 산문 대신 "경로:라인 — 심볼 — 짧은 메모" 형태의 구조화된 목록으로만 반환한다. 같은 탐색 결과가 2,000토큰에서 약 700토큰으로 줄어든다. 대략 3분의 1이다.

이 차이는 한 번만 보면 사소하다. 하지만 위임을 20번 반복하는 긴 세션에서는 이야기가 달라진다.

▲ vanilla — 산문 결과가 쌓이는 경우

다이어그램 설명. vanilla 탐색 에이전트에게 20번 위임했을 때의 누적을 보여준다. "위임 20회 · 매번 2,000토큰 산문"이 그대로 메인 대화에 붙어 "약 40,000토큰 누적"에 이르고, 결국 "컨텍스트 한도 초과 — 세션 중단"으로 끝난다. 정작 작업 자체는 아직 끝나지 않았는데, 위임 결과를 담아 두느라 대화 창이 먼저 차 버린 것이다.

▲ cavecrew — 압축 결과가 쌓이는 경우

다이어그램 설명. 같은 20번의 위임을 caveman 압축 결과로 받으면 "약 14,000토큰 누적"에 그쳐 "여유 있음 — 세션 완주"로 이어진다. 앞의 vanilla 경우와 발견한 정보의 양은 같다 — 어느 파일 몇 번째 줄에 무엇이 있는지는 똑같이 다 담겨 있다. 줄어든 건 그것을 감싸던 산문 설명뿐이다. 위임당 소모를 3분의 1로 낮추면, 같은 컨텍스트 한도로 세 배 더 오래 일할 수 있다는 게 이 그림의 결론이다.

그렇다고 항상 압축이 답은 아니다

여기서 성급하게 "그럼 무조건 압축된 서브에이전트를 쓰면 되겠네"로 넘어가기 쉽다. 그런데 압축은 공짜가 아니다. caveman 출력은 경로와 라인 번호 중심이라, "왜 그런가"에 대한 근거나 대안 제시가 빠져 있다. 뼈대만 남기느라 살을 버린 것이다. 이게 필요할 때가 분명히 있다.

다이어그램 설명. "서브에이전트에게 무엇을 원하나?"라는 하나의 질문에서 선택이 갈린다. 위치를 찾거나 좁은 수정을 맡길 때처럼 "경로·라인 중심 구조화 결과"만 있으면 되는 경우엔 "cavecrew 프리셋"을 골라 메인 컨텍스트를 아낀다. 반대로 설계 판단이나 코드 리뷰처럼 "근거·대안이 담긴 산문 설명이 필요"한 경우엔 토큰을 더 쓰더라도 "vanilla" 에이전트를 쓴다. 판단 기준은 한 문장으로 압축된다 — 결과를 3분의 1 토큰의 목록으로 받아도 충분하면 압축, 근거와 대안을 읽어야 하면 산문. 압축을 골라 놓고 나중에 "근데 왜 이렇게 고쳐야 하지?"라며 서브에이전트를 다시 부르면, 아낀 토큰을 되레 더 쓰게 된다는 게 놓치기 쉬운 함정이다.

압축의 진가는 체이닝에서 나온다

압축이 특히 빛나는 자리가 체이닝(chaining, 여러 서브에이전트를 순서대로 이어 붙여 한 흐름으로 처리하는 패턴)이다. 위치를 찾고, 고치고, 검토하는 세 단계를 각기 다른 서브에이전트에게 맡기는 흔한 흐름을 생각해 보자.

다이어그램 설명. 하나의 수정 작업이 세 서브에이전트를 거치는 흐름을 보여준다. "위치 찾기"가 경로·라인 목록을 돌려주면, 메인 대화가 그중 한두 곳을 골라 "1~2파일 수정"에 넘기고, 그 변경을 다시 "diff 검토"가 훑는다. 중요한 건 마지막의 "세 단계의 압축 결과가 모두 메인 컨텍스트에 누적"이다 — 체이닝은 한 작업에 위임을 여러 번 쌓는 구조라, 단계마다 결과가 산문이면 세 배로 빨리 컨텍스트가 찬다. 각 단계 결과가 caveman으로 압축돼 있으면 세 단계를 이어 붙여도 메인 대화에 남는 자국이 얕아, 이 체이닝을 한 세션에서 여러 번 반복할 여력이 생긴다. 위임을 많이 겹치는 흐름일수록 압축의 이득이 곱해진다.

정리 — 위임의 진짜 비용은 결과가 남기는 자국이다

서브에이전트에게 일을 넘기면 메인 대화가 깨끗해진다고 착각하기 쉽지만, 그 결과 텍스트는 메인 컨텍스트에 그대로 눌러앉는다. 위임의 진짜 비용은 일을 시키는 순간이 아니라, 결과가 대화 창에 남기는 자국에 있다. 토큰 절약을 입력과 출력의 문제로만 보면 이 세 번째 축 — 메인 컨텍스트 예산 — 을 통째로 놓친다.

개인 작업에 적용하는 방법은 단순하다. 서브에이전트를 부르기 전에 한 번 묻는다. "이 결과를 경로·라인 목록으로 받아도 되는가, 아니면 근거가 담긴 산문이 필요한가." 목록으로 충분한 위임을 압축된 프리셋으로만 돌려도, 긴 세션이 중간에 마르지 않고 끝까지 가는 폭이 눈에 띄게 넓어진다.

---

참고한 공개 자료:

• Anthropic — Building effective agents: https://www.anthropic.com/research/building-effective-agents
• Anthropic — How we built our multi-agent research system: https://www.anthropic.com/engineering/built-multi-agent-research-system
• Anthropic — Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.