앞선 편들에서 컨텍스트를 아끼는 법을 봤습니다. 이력은 작업 경계마다 비우고(3편), 고정비는 짧게 설계하고(4편). 그런데 이렇게 아껴도 감당이 안 되는 작업이 있습니다. “이 코드베이스에서 결제 로직이 어떻게 흘러가는지 파악해줘” 같은 요청이 대표적이에요. 성실한 에이전트는 파일을 수십 개 읽을 테고, 1편에서 봤듯 읽은 내용은 전부 컨텍스트에 쌓입니다. 파악이 끝날 때쯤이면 정작 그 지식으로 할 일, 그러니까 코드를 고칠 컨텍스트가 남아 있지 않습니다.
이 문제를 구조적으로 푸는 게 이번 편 주제인 서브에이전트(subagent)입니다. 요점은 하나예요. 컨텍스트 윈도우는 하나가 아니어도 됩니다.
다른 컨텍스트에서 일하고, 결론만 가져온다
서브에이전트는 메인 에이전트가 만드는 별도의 에이전트 인스턴스입니다. 이 인스턴스가 자기만의 깨끗한 컨텍스트 윈도우를 새로 받는다는 게 핵심이에요.
흐름을 따라가 보면 이렇습니다. 메인 에이전트가 “결제 로직 흐름을 조사해서 요약해줘”라는 지시문 하나를 서브에이전트에 넘깁니다. 서브에이전트는 자기 컨텍스트에서 파일 수십 개를 읽고, 검색하고, 호출 관계를 추적합니다. 이 과정에서 수만 토큰이 쌓이지만 전부 서브에이전트의 컨텍스트 안 이야기입니다. 작업이 끝나면 서브에이전트는 정리된 보고 하나를 반환하고 사라져요. 메인 컨텍스트에 남는 건 지시문 한 개와 보고 한 개, 몇백에서 몇천 토큰이 전부입니다.
조직에서 익숙한 구조죠. 팀장이 시장 조사를 직접 하는 대신 조사원에게 맡기고 보고서 한 장을 받는 겁니다. 조사원이 훑은 자료 백 건이 팀장 책상에 쌓이지 않는 게 요점이에요. 팀장의 책상, 그러니까 메인 컨텍스트는 의사결정에 필요한 정보만 유지합니다.
어떤 일을 넘겨야 하나
위임이 이득인 작업에는 공통점이 있습니다. 과정은 무겁고 결론은 가볍다는 것.
첫째, 탐색과 조사입니다. “이 함수를 쓰는 곳 전부”, “이 버그와 관련된 코드 파악” 같은 작업은 읽어야 할 양은 많지만 최종 답은 목록 하나, 요약 하나입니다. 서브에이전트의 전형적인 일감이에요. Claude Code가 탐색 전용 에이전트를 따로 두는 것도 같은 이유입니다.
둘째, 병렬로 쪼개지는 작업입니다. 모듈 다섯 개를 각각 분석하는 일이라면 서브에이전트 다섯이 각자의 컨텍스트에서 동시에 진행할 수 있습니다. 시간이 줄어드는 것은 물론이고, 서로의 중간 산출물이 한 컨텍스트에 섞여 혼선을 부를 일도 없습니다.
셋째, 조금 결이 다른데, 신선한 시각이 필요한 작업입니다. 코드 리뷰가 대표적이에요. 방금 코드를 작성한 메인 에이전트의 컨텍스트에는 구현 과정의 가정과 시행착오가 가득합니다. 그 상태로 자기 코드를 리뷰하면 자기 가정에 갇혀 관대해지기 쉬워요. 아무 맥락 없는 서브에이전트에 코드만 넘기면, 낯선 리뷰어의 눈으로 봅니다. 여기서는 격리가 토큰 절약이 아니라 품질 장치로 작동하는 겁니다.
반대로 넘기면 손해인 작업도 있습니다. 파일 한두 개 읽기처럼 가벼운 일은 위임 왕복 비용이 더 큽니다. 지금까지의 대화 맥락에 깊이 의존하는 작업도 부적합해요. 이유는 바로 다음에 나옵니다.
격리의 대가, 서브에이전트는 아무것도 모른다
서브에이전트의 깨끗한 컨텍스트는 공짜가 아닙니다. 깨끗하다는 건 지금까지의 대화를 하나도 모른다는 뜻이기도 하니까요.
메인 세션에서 한 시간 동안 쌓은 전제들, 이 프로젝트는 레거시 API를 유지해야 하고, 테스트는 건드리면 안 되고, 사용자가 선호하는 방식은 이것이고. 서브에이전트는 전부 모릅니다. 지시문에 적어주지 않으면 존재하지 않는 정보예요. 그래서 위임의 품질은 지시문의 품질에 수렴합니다. 필요한 배경, 제약 조건, 원하는 결과물의 형태까지 지시문 하나에 담아야, 엉뚱한 전제로 작업한 보고서를 받는 사고를 피할 수 있습니다.
반환 방향도 마찬가지입니다. 메인이 받는 건 서브에이전트의 최종 보고뿐이라, 보고에 안 담긴 발견은 서브에이전트가 사라질 때 같이 사라집니다. 그래서 지시문에 “판단에 영향을 준 근거와 확인한 파일 목록을 포함해줘”처럼 보고 형식을 지정하는 습관이 유용해요. 2편에서 본 context poisoning도 여기서 다시 만납니다. 서브에이전트의 보고가 부정확하면 그 오류가 메인 컨텍스트에 압축된 형태로 이식되고, 메인은 검증할 원본이 없으니 그대로 믿게 됩니다. 중요한 결론일수록 근거를 함께 받아야 하는 이유입니다.
정리
- 서브에이전트는 별도의 깨끗한 컨텍스트에서 일하고 결론만 반환합니다. 과정의 수만 토큰이 메인 컨텍스트에 들어오지 않는 게 핵심입니다.
- 과정은 무겁고 결론은 가벼운 작업(탐색·조사·병렬 분석)이 위임 대상입니다. 리뷰처럼 신선한 시각이 필요한 작업은 품질 목적으로도 격리가 유효합니다.
- 격리의 대가는 맥락 단절입니다. 서브에이전트는 대화 이력을 모르니 지시문에 배경과 제약을 다 담아야 하고, 보고에는 근거를 요구해야 합니다.
이제 시리즈의 마지막 조각이 남았습니다. /clear를 하면 대화가 사라지고, 서브에이전트는 세션이 끝나면 사라집니다. 그런데 프로젝트는 계속되죠. 세션이 끝나도 살아남아야 하는 지식은 어디에 둬야 할까요. 다음 편은 컨텍스트 밖의 저장소, 그러니까 메모리와 외부화를 다룹니다.