AI 코딩 에이전트 서브에이전트 설계: 모델 계층 분담과 문맥 격리 기준

함수 하나가 어디서 호출되는지 찾으려고 에이전트가 파일 스무 개를 연달아 읽고, 빌드 오류 스택 트레이스 수백 줄을 터미널에서 받아 적습니다. 그러고 나서 마지막에 권한 검사 로직을 고쳐 달라고 하면, 에이전트는 방금 읽은 스무 개 파일의 지엽적인 코드에 끌려다니다가 맨 처음에 일러둔 설계 제약을 놓칩니다.

흔히 서브에이전트(Subagent)를 쓰는 이유를 "가벼운 모델로 토큰 비용을 아끼려는 것"이나 "여러 작업을 동시에 돌리려는 것"으로만 이해합니다. 하지만 단일 모델로도 속도가 충분한 작업에서까지 굳이 하위 에이전트를 따로 띄우는 진짜 이유는 비용보다 **문맥 격리(Context Isolation)**에 있습니다. 상위 에이전트의 문맥 창(Context Window)은 돈을 주고도 넓힐 수 없는 가장 비싼 작업대이기 때문입니다.

문맥 창이 넓어져도 중간에 낀 탐색 기록이 추론을 흐리는 현상

모델이 한 번에 받을 수 있는 최대 입력이 20만 토큰, 100만 토큰으로 늘어났으니 파일 수십 개를 한 세션에 다 넣어도 괜찮을 것처럼 보입니다. 스탠퍼드대 연구진이 발표한 Lost in the Middle: How Language Models Use Long Contexts(Liu et al., 2023)는 이 가정이 어디서 깨지는지 보여줍니다. 언어 모델은 입력의 맨 앞(Primacy)과 맨 끝(Recency)에 있는 정보는 잘 찾아 쓰지만, 가운데에 묻힌 정보를 꺼내 쓰는 정확도는 문맥이 길어질수록 U자 곡선을 그리며 급격히 떨어집니다. 심지어 긴 문맥을 지원하도록 학습된 모델도 입력 한도를 채워 넣으면 아예 문맥 없이 답할 때보다 낮은 점수를 내기도 했습니다.

단일 세션에서는 파일 탐색과 빌드 로그가 본 문맥에 쌓이지만, 서브에이전트로 분리하면 시행착오 기록을 하위 세션에서 버리고 요약만 돌려받습니다.

코딩 에이전트 세션에서 가장 먼저 들어가는 것은 시스템 프롬프트와 사용자의 첫 지시이고, 가장 끝에 남는 것은 방금 실행한 도구 출력입니다. 그 사이에 grep 결과, 파일 목록, 실패한 테스트 로그가 수만 토큰씩 쌓이면 앞서 합의한 아키텍처 제약은 정확히 그 '중간'에 파묻힙니다. 탐색 과정을 하위 에이전트의 독립된 문맥 창에 가두고, 탐색이 끝나면 수만 토큰의 시행착오 기록은 버린 채 다섯 줄짜리 결과 요약만 상위 세션으로 돌려보내야 상위 모델의 판단력이 유지됩니다.

판단의 무게와 되돌리는 비용으로 나눈 네 단계 모델 계층

문맥을 격리하기로 했다면, 분리된 각 작업에 같은 급의 모델을 쓸 이유가 없습니다. Anthropic의 에이전트 아키텍처 가이드(Building Effective Agents)가 제시하는 오케스트레이터-워커(Orchestrator-Workers) 패턴처럼, 중앙 모델은 문제를 쪼개고 종합하는 일만 맡고 하위 작업은 성격에 맞는 작업자 모델에 넘기는 편이 낫습니다. 이때 모델을 가르는 기준은 작업의 길이가 아니라 틀렸을 때 되돌리는 비용과 한 번에 엮어야 하는 파일의 범위입니다.

모델 계층	맡기는 일	실제 작업 예
Haiku · Flash	판단이 거의 없는 찾기, 세기, 목록 뽑기	특정 행위 이름이 쓰인 곳 세기, 파일 목록 추출, 문구 일괄 치환
Sonnet · Argon	정해진 설계대로 고치기, 범위가 분명한 조사	변수·함수 이름 바꾸기, 단위 시험 추가, 화면 필드와 API 연결
Opus	여러 파일을 엮어 판단해야 하는 일, 틀리면 비싼 일	권한 흐름 검토, 코어 파이프라인 수정, DB 마이그레이션, 설계 검증
Fable (상위 오케스트레이터)	전체 설계와 종합, 작업 경계 나누기	요구사항을 독립된 일감으로 쪼개고 작업자 보고를 받아 최종 판단

찾기나 세기처럼 정답이 정해져 있는 일에 무거운 추론 모델을 쓰면 시간만 늦어질 뿐 결과가 달라지지 않습니다. 반대로 권한 흐름이나 데이터베이스 마이그레이션처럼 파일 대여섯 개의 암묵적 가정을 동시에 읽어야 하는 일을 중간 급 모델에 맡기면, 겉보기에 타입 검사는 통과하지만 경계 조건이 뚫린 코드가 나옵니다.

오케스트레이터(Fable)는 대상 파일과 검증 명령만 내려보내고, 작업자 모델(Haiku·Sonnet·Opus)은 독립된 하위 문맥에서 시험과 빌드를 통과한 뒤 요약만 보고합니다.

하위 에이전트에게 배경 대신 완료 조건을 넘기는 위임 규칙

오케스트레이터가 하위 에이전트를 부를 때 가장 흔히 저지르는 실수는 자신이 가진 대화 맥락 전체를 그대로 복사해 넘기는 것입니다. 그렇게 하면 하위 에이전트도 똑같이 흐려진 문맥에서 출발하게 되고, 모호한 지시를 받은 작업자 모델은 자기 나름대로 설계를 추측하기 시작합니다.

Claude Code의 서브에이전트 문서가 권장하듯 하위 에이전트는 부모 세션의 대화 이력을 물려받지 않는 빈 상태에서 시작해야 합니다. 오케스트레이터가 넘겨야 하는 것은 '왜 이 기능이 기획되었는가' 같은 배경 이야기가 아니라 세 가지 경계 조건입니다.

첫째는 수정해야 할 대상 파일과 건드리지 말아야 할 폴더의 범위입니다. 둘째는 타입 검사, 단위 시험, 빌드처럼 통과 여부를 기계적으로 판정할 수 있는 검증 명령입니다. 셋째는 작업이 끝났을 때 상위 세션에 돌려줄 보고 형식입니다. 하위 에이전트가 작업 도중 수십 번의 테스트 실패를 겪더라도, 최종적으로 검증 명령을 통과한 커밋 해시와 변경 요약 두 문단만 오케스트레이터에 돌아오면 상위 세션의 문맥은 처음과 거의 같은 크기로 유지됩니다.

서브에이전트로 쪼개면 오히려 손해가 나는 경계

모든 작업을 이 네 단계 계층으로 쪼갤 수 있는 것은 아닙니다. 멀티 에이전트 구조를 과하게 쓰면 단계마다 미묘한 맥락이 유실되고(Lost Context), 에이전트를 띄우고 결과를 주고받는 왕복 지연과 토큰 비용이 단일 루프보다 커집니다.

어디서부터 고쳐야 할지조차 모르는 초기 버그 원인 파악이나, 파일 세 개를 동시에 고쳐야 비로소 타입이 맞는 밀결합 리팩터링은 하위 에이전트에 나눠 주면 실패합니다. 작업자 모델 하나가 인터페이스를 살짝 바꾸는 순간 다른 작업자 모델의 가정이 깨지기 때문입니다. 무엇을 고칠지 한 문장으로 적어 줄 수 없는 작업이라면, 아직 위임할 단계가 아니라 상위 모델(Opus나 Fable)이 직접 코드를 읽으며 경계를 먼저 그어야 할 단계입니다.