서브에이전트(Subagent)를 생성해야 할 때와 토큰만 낭비하게 될 때

현재 모든 가이드가 똑같은 말을 하고 있습니다. 코딩 에이전트(Coding agent)의 컨텍스트(Context)가 오염되고 있으니, 깨끗한 컨텍스트 창(Context window)을 가진 서브에이전트(Subagent)에게 작업을 위임하라는 것입니다. 좋은 조언입니다. 하지만 이는 제가 본 방식 중 사람들이 실수로 토큰 비용을 7배나 급증시키는 가장 빠른 방법이기도 합니다.

서브에이전트(Subagent)는 자신만의 새로운 컨텍스트(Context)를 가지고 실행되는 모델의 두 번째 복사본입니다. 부모 대화(Parent conversation)는 따라오지 않습니다. 자식(Child)은 당신이 전달한 프롬프트(Prompt)만 가지고 시작하여, 하나의 작업을 수행하고 단일 문자열을 반환합니다. 그 격리(Isolation)가 핵심입니다. 지저분하고 미완성된 탐색 과정은 자식에게 남겨두고, 메인 스레드(Main thread)는 오직 깔끔한 결과만을 보게 됩니다.

함정은 "서브에이전트(Subagent)를 생성하라"는 말을 아무런 대가 없는 반사적인 행동으로 취급하는 것입니다. 그렇지 않습니다. 각 서브에이전트(Subagent)는 시스템 프롬프트(System prompt), 도구 정의(Tool definitions), 그리고 당신이 전달하는 모든 파일의 복사본을 매번 개별적으로 가집니다. 커뮤니티의 측정 결과에 따르면, 서브에이전트(Subagent) 중심의 워크플로우(Workflow)는 단일 스레드(Single-threaded) 세션보다 약 7배 더 많은 토큰을 사용합니다. 공포스러운 사례들은 실재합니다. 한 금융 서비스 팀은 23개의 서브에이전트(Subagent)가 코드베이스(Codebase)를 분석하도록 방치했다가, 3일 만에 47,000달러의 청구서를 받았습니다. 약 49개의 병렬 서브에이전트(Subagent)가 오케스트레이션(Orchestrated)된 단 한 번의 실행 비용은 8,000~15,000달러로 추정되었습니다. 누구도 그렇게 쓰고 싶어 하지 않았습니다. 그들은 그저 기본 설정대로 서브에이전트(Subagent)를 생성했을 뿐입니다.

따라서 진짜 기술은 "어떻게 서브에이전트(Subagent)를 생성하는가"가 아닙니다. 그것은 언제 서브에이전트(Subagent)를 생성하는 것이 오버헤드(Overhead)를 감수할 가치가 있는가 — 그리고 언제 아무런 이득 없이 세금(Tax)만 내고 있는가 하는 점입니다.

단 하나의 규칙

서브에이전트(Subagent)를 생성함으로써 메인 스레드(Main thread)가 절약하는 컨텍스트(Context)가, 서브에이전트(Subagent)를 시작하는 데 소요되는 컨텍스트(Context)보다 더 가치 있을 때만 생성하십시오.

그게 전부입니다. 작업을 읽고 다음 두 가지 질문을 던지십시오:

1. 이 작업을 인라인(Inline)으로 수행한다면 내 메인 스레드(Main thread)에 얼마나 많은 쓰레기(Junk)가 생성될 것인가? (방대한 grep 덤프, 10개의 탐색 파일, 소음이 심한 테스트 실행, 긴 브라우저 세션 등)
2. 서브에이전트(Subagent)를 가동하기 위해 지불해야 하는 비용은 얼마인가? (서브에이전트의 시스템 프롬프트(System prompt), 도구 스키마(Tool schemas), 그리고 컨텍스트(Context)를 볼 수 없기 때문에 다시 전달해야 하는 파일들)

(1)이 (2)보다 훨씬 크다면, 생성(spawn)하세요. 두 값이 비슷하거나 (2)가 더 크다면, 인라인(inline)으로 처리하세요.

실패 사례는 단 두 줄짜리 셸 명령(shell command)을 위임하는 것입니다. 서브에이전트(Subagent)의 시작 오버헤드(프롬프트 + 도구 정의 + 추가적인 왕복 시간)는 직접 git status를 실행할 때 발생하는

4. 진정으로 병렬적이고 독립적인 작업. 상태(state)를 공유하지 않는 서로 관련 없는 세 개의 모듈은 동시에 세 개의 서브에이전트(Subagent)로 처리할 수 있으며, 이는 실제 실행 시간(wall-clock speedup)을 단축합니다. 하지만 "독립적"이라는 조건은 매우 중요합니다. 만약 이들이 동일한 파일에 접근한다면, 머지 혼란(merge chaos)이 발생할 것이며 결국 세 개의 컨텍스트(context) 비용을 모두 지불하게 될 것입니다. 실제로 병렬 처리가 가능한 작업만을 병렬화하세요.

안티 패턴(Anti-pattern): 작고 결정론적(deterministic)인 작업을 위해 서브에이전트를 화려한 함수 호출(function call)처럼 사용하는 것입니다. 변수 이름 변경, 린트(lint) 명령 한 번 실행, 이미 알고 있는 단일 파일 읽기 등이 이에 해당합니다. 보호해야 할 컨텍스트도 없고 격리할 것도 없습니다. 그저 시작 비용(startup tax)을 지불하고 왕복 시간(round trip)만 추가할 뿐입니다. 이런 작업은 인라인(inline)으로 처리하세요.

비용을 합리적으로 유지하는 두 가지 습관

"혹시 모르니까 전부 다"가 아니라, 최소한만 전달하세요. 서브에이전트는 사용자의 컨텍스트를 볼 수 없기 때문에, "필요한 것을 갖추도록" 10개의 파일을 미리 전달하고 싶은 유혹에 빠지기 쉽습니다. 하지만 서브에이전트를 생성할 때마다 그 토큰 비용을 매번 지불해야 합니다. 작업 내용, 정말로 필요한 한두 개의 파일, 그리고 무엇을 반환해야 하는지에 대한 명확한 정의만을 전달하세요. 만약 더 많은 정보가 필요하다면, 서브에이전트가 직접 읽으러 가면 됩니다. 그것이 바로 서브에이전트에게 별도의 컨텍스트를 부여하는 이유입니다.

반환 값(return value)을 제한하세요. 서브에이전트가 비용을 절감해 주는 이유는 최종 메시지가 작기 때문입니다. 만약 서브에이전트가 3,000단어짜리 에세이를 반환하게 둔다면, 비대해진 데이터(bloat)를 제거한 것이 아니라 위치만 옮긴 것에 불과합니다. 답변의 형태를 지정해 주세요: "파일 경로와 한 문장만 반환해줘", "PASS/FAIL 여부와 최대 세 개의 불렛 포인트 이유를 반환해줘", "실패한 테스트 이름만 반환해줘"와 같이 말입니다. 엄격한 반환 계약(return contract)이 있어야 이 모든 거래가 가치가 있습니다.

멘탈 모델 (Mental Model)

서브에이전트를 옆에 서 있는 무료 조수가 아니라, 특정 범위의 작업을 수행하기 위해 고용한 계약업체(contractor)라고 생각하세요. 당신은 그들에게 브리핑을 하고(비용 발생), 그들은 당신이 어지러운 과정을 볼 수 없는 자신만의 사무실에서 작업하며(이점), 마지막에 한 페이지짜리 보고서를 제출합니다(보상). 스테이플러를 가져다 달라고 계약업체를 고용하지는 않을 것입니다. 여기서도 같은 직관을 적용하세요. 넓고, 복잡하거나, 독립적인 작업은 위임하고 — 작고, 저렴하며, 결정론적인 작업은 당신의 책상 위에 그대로 두세요.

이 결정 하나를 제대로 내린다면, 당신의 긴 세션은 — 깨끗한 메인 컨텍스트를 유지하여 데이터가 오염되지 않는 — ‘정확성(accurate)’과, 7배의 비용 폭탄을 맞지 않는 — ‘경제성(affordable)’을 모두 유지할 수 있습니다. 반대로 결정을 잘못 내린다면, 불어난 비용과 불어난 컨텍스트라는 최악의 상황을 동시에 맞이하게 됩니다.

이 모든 것이 생소하고 "컨텍스트 윈도우 (context window)"나 "서브에이전트 (subagent)"라는 단어가 여전히 모호하게 느껴진다면, 그것이 바로 제가 **AI Learning Ladder***를 만든 이유입니다. 이 과정은 "AI가 두렵다"는 단계에서 "자신감 있는 일상적 사용자"로 나아가는 Level 1을 제공하며, 전문 용어 없이 쉬운 영어로 단돈 9달러에 제공됩니다. penloomstudio.com에서 확인하세요. 멘탈 모델 (mental models)을 한 번 제대로 익히고 나면, 이후의 모든 도구 사용이 훨씬 쉬워질 것입니다.