서브에이전트(Subagent)의 진짜 목적: 병렬처리와 컨텍스트 격리
서브에이전트는 '많이 돌리는 것'이 아니다
클로드 코드(Claude Code)와 코덱스(Codex)에는 서브에이전트(subagent)1 기능이 있습니다.[1] 클로드 코드는 여기서 한 발 더 나가서 '에이전트 팀(Agent Teams)2'이라는 확장 기능까지 제공합니다. 요즘 "서브에이전트 수십 개 동시에 돌렸다"는 자랑이 흔하지만, 무작정 따라하기보다는 왜 이 기술이 나왔는지를 먼저 짚어보는 게 좋을 것 같습니다.
(1) 서브에이전트(subagent) — 메인 LLM 에이전트가 별도의 컨텍스트와 도구를 가진 보조 에이전트를 호출하는 패턴. 격리된 작업 공간에서 작업을 수행하고 결과만 메인에 돌려주기 때문에 메인 세션의 컨텍스트가 오염되지 않습니다.
(2) 에이전트 팀(Agent Teams) — Claude Code의 확장 기능. 미리 정의된 여러 서브에이전트를 하나의 팀으로 묶어 역할과 호출 흐름을 사전에 설계해 운영하는 방식입니다.
-
병렬처리 - 서브에이전트는 여러개를 동시에 돌릴 수 있고, 서로 독립적인 업무 N개가 있고, 거기에 맞는 N개의 에이전트가 있을 때 적합합니다. 이론상 병렬화로 크게 단축되지만, 에이전트마다 작업 복잡도가 다르고 메인 에이전트가 결과를 받아 정리하는 비용도 붙기 때문에 선형적으로 N배까지는 가지 않습니다. 그래도 직렬 처리보다는 확실히 빨라집니다.[2]
-
컨텍스트 격리(context isolation) - 메인 에이전트가 서브에이전트에 위임해서 결과만 받는 형태이기 때문에, 불필요한 데이터를 별도의 공간에 격리 시킬수 있다는 장점이 있습니다. 사실 이건 굳이 논문을 들이밀지 않아도, 클로드(Claude)나 챗GPT(ChatGPT)를 좀 써보신 분들은 다 체감하셨을 겁니다. 하나의 세션에서 계속 작업을 이어가다 보면 어느 순간부터 답변이 둔해지고, 앞에서 알려준 내용을 까먹거나 엉뚱한 방향으로 가는 경험 - 다들 한 번쯤은 있으실 거라 생각합니다. 이 현상은 관련 연구에서도 확인되어 있고[3][4], 일부 에이전트 도구는 긴 컨텍스트(context)를 요약·압축해 세션을 재구성하는 방식으로 이 문제를 우회합니다.[5]
위의 두가지 관점에서 사용하는 것이 가장 유리하다는 것이 제 생각입니다. 서브에이전트를 구성할 때는 스스로 해당 업무를 메인 에이전트와 돌려보고 그걸 바탕으로 만드는 것이 좋습니다. 단순히 당신은 ㅇㅇ 전문가입니다. 식의 페르소나(persona)3 주입 또는 추상적인 역할부여는 에이전트에게 선택지를 굉장히 넓혀주게 되고, 일관성 없는 결과물이 나오게 됩니다. 또 중복요소가 많은 에이전트로 나누게 되면 서로 결과물을 건들여 충돌하게 될 가능성이 높고, 병렬처리로 빠르게 소모된 토큰(token)4은 공중에 날려버리는 결과로 남을 가능성이 높습니다.
결국 서브에이전트는 "많이 돌리는 것"이 목적이 아니라, 병렬화로 시간을 벌고 격리로 컨텍스트를 지키는 것이 목적입니다. 이 두 가지가 안 보이는 작업이라면 굳이 서브에이전트로 갈 이유가 없습니다.
요즘은 '에이전트로 구성된 회사', '다수의 에이전트가 협업하는 팀'을 소개하는 영상과 글도 제법 보입니다. 이 글에서는 서브에이전트를 중심으로 이야기했지만, 에이전트 회사나 에이전트 팀이라는 표현도 결국 같은 기준으로 봐야 한다고 생각합니다.
중요한 것은 에이전트가 몇 개인지가 아닙니다. 작업이 명확히 분해되어 있는지, 각 단계의 입력과 출력이 분명한지, 중간 결과를 검증할 수 있는지가 중요합니다. 여러 에이전트가 동시에 움직이는 화면은 멋있어 보일 수 있지만, 그것만으로 실무 가치가 증명되지는 않습니다.
새로운 기술을 실험하는 과정에서 시행착오는 피하기 어렵습니다. 다만 과장된 데모나 그럴듯한 표현만 보고 큰 비용을 지불하기 전에, 그 구조가 내 업무에서 병렬화·컨텍스트 격리·검증 가능성이라는 실질적 이점을 주는지는 냉정하게 따져볼 필요가 있습니다.
(3) 페르소나(persona) 주입 — "당신은 ㅇㅇ 전문가입니다" 식의 역할 부여 프롬프트 패턴. 일반 대화형 사용에선 유효하지만, 서브에이전트 설계에서는 행동 범위를 지나치게 넓혀 결과물 일관성을 해치기 쉽습니다.
(4) 토큰(token) — LLM이 텍스트를 처리하는 최소 단위. 한 단어가 1~3개 토큰으로 쪼개지며, 입력·출력 모두 토큰 단위로 과금되고 컨텍스트 한도도 토큰으로 셉니다.
참고자료
[1] OpenAI Developers — "Subagents (Codex)" 코덱스(Codex)의 공식 문서. 코덱스는 전문화된 서브에이전트를 병렬로 실행하고 결과를 모아 반환할 수 있으며, 복잡한 코드베이스 탐색·테스트·분석처럼 독립적으로 나눌 수 있는 작업에 적합하다고 설명합니다. 메인 대화에 탐색 로그·테스트 출력·스택트레이스 같은 중간 결과가 과도하게 쌓이면 신뢰성이 떨어질 수 있어, bounded work를 서브에이전트로 분리하는 패턴을 권장합니다. OpenAI Developers →
[2] Anthropic Engineering — "How we built our multi-agent research system" (2025.06.13) 앤트로픽(Anthropic)의 리서치 기능에 적용된 멀티에이전트 시스템(multi-agent system) 사례 분석. 리드 에이전트(lead agent)가 질의를 분해하고 여러 서브에이전트가 서로 다른 방향을 병렬로 조사한 뒤 결과를 압축해 반환하는 구조를 설명합니다. 복잡한 질의에서 단일 에이전트 대비 90.2% 성능 향상, 병렬화로 리서치 작업 시간 최대 90% 단축 사례를 보고하는 동시에, 멀티에이전트가 일반 채팅 대비 약 15배 토큰을 사용할 수 있다는 비용 문제와 코딩처럼 의존성이 높은 작업에는 항상 적합하지 않다는 한계도 함께 제시합니다. 본문에서는 "에이전트를 많이 띄울수록 좋다"는 근거가 아니라, 병렬 탐색과 컨텍스트 분리의 장단점을 보여주는 실무 사례로 인용합니다. Anthropic Engineering →
[3] Liu et al. — "Lost in the Middle: How Language Models Use Long Contexts" TACL 2024 (arXiv:2307.03172). 긴 컨텍스트를 지원하는 모델이 실제로 입력 전체를 균등하게 활용하는지 검증한 논문. 다중 문서 질의응답과 key-value retrieval 실험에서 관련 정보가 입력의 중간에 위치할 때 성능이 떨어지는 위치 편향(positional bias)을 보고합니다. "긴 컨텍스트를 넣을 수 있다"와 "긴 컨텍스트를 안정적으로 활용한다"가 같은 말이 아님을 보여주는 근거로 인용하며, 세션 장기 사용으로 인한 모든 품질 저하를 직접 설명하는 논문은 아니라는 점에 한정해 해석합니다. arXiv:2307.03172 →
[4] Du et al. — "Context Length Alone Hurts LLM Performance Despite Perfect Retrieval" Findings of EMNLP 2025 (arXiv:2510.05381). 필요한 정보를 완벽하게 찾아낼 수 있는 조건에서도 입력 길이가 길어지면 수학·질의응답·코딩 과제 성능이 떨어질 수 있음을 5개 오픈·폐쇄형 모델 실험으로 보고합니다. 불필요한 토큰을 공백으로 바꾸거나 attention에서 마스킹한 조건에서도 성능 저하가 관찰돼, 단순한 검색 실패나 방해 문서 문제만으로 설명하기 어렵다는 점을 보입니다. 최신 대형 폐쇄형 모델은 작은 오픈소스 모델보다 더 강건한 경향을 보이므로, 본문에서는 "긴 컨텍스트는 항상 망한다"가 아니라 "긴 컨텍스트로부터 완전히 자유롭지는 않다"는 제한적 근거로 인용합니다. arXiv:2510.05381 →
[5] Anthropic — "Create custom subagents" (Claude Code Docs) 클로드 코드(Claude Code)의 공식 문서. 서브에이전트가 특정 작업을 자체 컨텍스트에서 수행하고 요약 결과만 부모 세션에 반환함으로써, 검색 결과·로그·파일 내용 같은 대용량 중간 출력을 메인 대화에 쌓지 않는 패턴을 설명합니다. 별도 컨텍스트 윈도우(context window), 전용 시스템 프롬프트, 제한된 도구 권한을 가질 수 있어 본문에서 말하는 컨텍스트 격리(context isolation)의 직접 근거로 사용합니다. Claude Code Docs →