학습 목표:
- 오케스트레이터-서브에이전트 아키텍처에서 오케스트레이터와 서브에이전트가 각각 무엇을 책임지는지 말하기
- "컨텍스트 격리"가 실제로 무엇을 격리하는지, 그리고 그것이 지난 레슨의 컨텍스트 오염과 어텐션 희석을 왜 완화하는지 설명하기
- 서브에이전트가 축적한 사고 과정 전체를 도로 밀어 넣는 대신, 왜 결론만 오케스트레이터에게 돌려줘야 하는지 설명하기
전제: 레슨 1을 마쳤고 "멀티 에이전트 시스템"의 정의와 그것이 어디에 맞는지 이해하고 있다 | 이전: 레슨 1 << | 다음: 레슨 3 >>
지난 레슨에서 "세 클라우드 제공업체의 가격을 조사한다" 같은 작업은 여러 에이전트로 나누기에 좋다고 결론지었지만, 그 나눔이 실제로 어떻게 돌아가는지는 짚지 않았습니다. 이를 위한 흔한 구조 하나가 오케스트레이터-서브에이전트 아키텍처입니다. 공식 정의는 "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results."1입니다. (하나의 중앙 LLM이 작업을 동적으로 쪼개고, 그것을 워커 LLM들에게 위임하며, 그 결과를 종합한다.)
그 정의는 세 가지 행동을 지목하고, 그것들은 오케스트레이터가 하는 세 가지 일에 대응합니다. 쪼개기 — 하나의 큰 작업을 보고 어떤 덩어리로 나뉘는지 가늠한다. 위임 — 각 덩어리를 그것에 필요한 배경과 함께 서브에이전트에게 넘겨 수행하게 한다. 종합 — 서브에이전트들이 결과를 돌려주고 나면, 그 결과들을 최종 답으로 합친다. 오케스트레이터 자신은 결코 내려가서 제공업체의 가격 페이지를 읽지 않습니다. 그 일은 일을 어떻게 나눌지, 누가 무엇을 맡을지, 여러 결과를 하나의 앞뒤가 맞는 답으로 어떻게 꿰맬지를 정하는 것입니다.
서브에이전트 쪽은 사뭇 다르게 돌아갑니다. 문서는 명확합니다. "Each subagent starts with a fresh, isolated context window. It doesn't see your conversation history, the skills you've already invoked, or the files Claude has already read. Claude composes a delegation message that summarizes the task, and the subagent works from there."2 (각 서브에이전트는 새롭고 격리된 컨텍스트 윈도로 시작한다. 여러분의 대화 기록도, 이미 호출한 스킬도, Claude가 이미 읽은 파일도 보지 못한다. Claude가 작업을 요약한 위임 메시지를 작성하면, 서브에이전트는 거기서부터 작업한다.) 다시 말해, 서브에이전트는 여러분이 오케스트레이터에게 처음 무슨 말을 했는지도, 오케스트레이터가 "이걸 나눠야 할까", "몇 조각으로 나눌까"를 내부적으로 어떻게 저울질했는지도 전혀 모릅니다. 볼 수 있는 것은 오케스트레이터가 건넨 하나의 작업 브리프뿐입니다.
이는 제약처럼 보이지만, 사실은 지난 레슨의 두 문제를 낫게 하는 처방입니다. 서브에이전트의 컨텍스트는 오케스트레이터의 대화 기록 전체를 지니지 않으므로, 오케스트레이터가 다른 데서 부딪힌 막다른 길이나 마주친 관련 없는 자료도 지니지 않습니다. 이것이 컨텍스트 격리입니다. 각 에이전트의 작업 범위를 자기 컨텍스트 윈도로 가두어, 한 에이전트 안의 컨텍스트 오염이 다른 에이전트로 번지지 않게 하는 것입니다. 서브에이전트는 자기 몫의 작업에 필요한 자료만 붙들고 세 회사의 콘텐츠를 한꺼번에 다룰 필요가 없으니, 어텐션 희석의 압박도 줄어듭니다. 대화 기록을 전혀 보지 못하는 서브에이전트가 혼자서도 좋은 작업을 해낼 만큼 명료한 작업 브리프를 어떻게 쓰는지는 다음 레슨에서 다룹니다.
세 제공업체 가격 예시로 돌아가 봅시다. 오케스트레이터가 일을 "첫째를 확인", "둘째를 확인", "셋째를 확인"으로 쪼개고 나면, 그것들을 한 번에 하나씩 줄 세우지 않습니다. 셋을 한꺼번에 넘깁니다. 이것이 정확히 프로덕션 시스템이 하는 일입니다. 리드 에이전트가 서브에이전트 3~5개를 순차가 아니라 병렬로 띄웁니다3. 그 "한꺼번에 넘긴다"는 움직임이 팬아웃입니다. 오케스트레이터가 쪼갠 하위 작업들을 그에 맞는 수의 서브에이전트에게 병렬로 분배해, 첫 서브에이전트가 끝나기를 기다렸다 둘째를 보내는 대신 각자 독립적으로 동시에 작업을 시작하게 하는 것입니다.
팬아웃의 이득은 직접적입니다. 세 서브에이전트가 병렬로 작업하면 총 시간이 세 건을 더한 것이 아니라 한 건의 조사에 가까워집니다. 프로덕션 시스템이 이런 병렬화를 도입한 뒤, 복잡한 질의의 조사 시간이 최대 90%까지 줄었습니다3. 하지만 팬아웃은 작업을 조각으로 쪼개 놓고 끝이 아닙니다. 어떻게 자르느냐가 중요합니다. 세 회사는 자연히 독립적이라 셋으로 자르는 것이 깔끔하게 맞습니다. "20쪽짜리 계약서를 검토한다"로 바꾸면 조항들이 서로 참조하고 제약할 수 있어, 잘못 자르면 서브에이전트들이 저마다 핵심 맥락을 놓치고 서로 모순되는 결론에 이릅니다. 어떻게, 얼마나 잘게 자를지는 지난 레슨의 시험으로 돌아갑니다. 잘라낸 각 덩어리가, 다른 덩어리의 중간 결과에 의존하지 않고 그 자체로 처리될 수 있는 것인가?
세 서브에이전트가 각자 자기 회사의 가격을 확인해 결과를 돌려주고 나면, 오케스트레이터가 하는 일은 세 덩어리의 텍스트를 끝과 끝을 이어 붙이는 것이 아닙니다. 서브에이전트들이 돌려주는 것은 저마다의 관점에서 나온 조사 결론이고, 오케스트레이터의 일은 취합입니다. 독립적으로 만들어진 여러 결과를 나란히 놓고, 비교하고, 드러나는 중복이나 모순을 해소하고, 최종 산출물의 모양으로 재구성하는 것입니다. 뚜렷한 이음매가 보이는 세 조각이 아니라 하나의 온전한 글로 읽히는 문서를 쓰는 것입니다.
문서는 서브에이전트가 순차적으로 넘겨주는 경우를 설명하며 이렇게 짚습니다. "Each subagent completes its task and returns results to Claude, which then passes relevant context to the next subagent."2 (각 서브에이전트가 자기 작업을 마치고 결과를 Claude에게 돌려주면, Claude가 관련 컨텍스트를 다음 서브에이전트에게 넘긴다.) 그러니 취합이 반드시 "모든 서브에이전트가 작업을 제출하기를 기다렸다가 오케스트레이터가 그것을 한꺼번에 모아 처리한다"만큼 단순하지는 않습니다. 어떤 경우에는 앞선 서브에이전트의 결과 자체가 다음 서브에이전트의 작업 브리프의 일부가 되고, 오케스트레이터는 모든 하위 작업에 결과가 생길 때까지 팬아웃과 취합을 오갑니다.
결과가 지나는 경로가 늘 오케스트레이터를 거쳐야 하는 것도 아닙니다. 서브에이전트가 만든 콘텐츠가 크고 온전히 보존해야 할 때, 문서는 한 가지 방식을 언급합니다. "Subagent output to a filesystem to minimize the 'game of telephone.' Direct subagent outputs can bypass the main coordinator for certain types of results, improving both fidelity and performance."3 (서브에이전트 출력을 파일 시스템에 내보내 '전화 놀이'를 최소화한다. 특정 종류의 결과는 서브에이전트 출력이 중앙 코디네이터를 우회할 수 있어, 충실도와 성능을 모두 높인다.) 파일 시스템에 곧장 쓰는 것은, 결국 "서브에이전트 → 오케스트레이터 → 최종 출력" 사슬을 지나며 결과가 바꿔 말해지고 압축되어 세부를 잃는 것을 막는 방법입니다.
작업을 끝내기 위해 서브에이전트는 도중에 관련 없는 자료를 여러 쪽 읽고, 아무 데로도 이어지지 않는 몇 갈래 길을 시도하고, 작은 실수를 하고 스스로 바로잡기도 합니다. 그 과정은 오케스트레이터의 컨텍스트에 그대로 도로 밀어 넣을 필요가 없으며, 밀어 넣어서도 안 됩니다. 오케스트레이터에게 필요한 것은 서브에이전트의 최종적이고 방어 가능한 결론과 그것을 뒷받침하는 핵심 근거이지, 우회로가 딸린 추론 과정 전체가 아닙니다.
이유는 레슨 1의 논점으로 돌아갑니다. 오케스트레이터도 자기 컨텍스트 윈도를 가지며, 그 역시 컨텍스트 오염과 어텐션 희석을 겪습니다. 문서는 이에 대해 직접적입니다. 서브에이전트가 완료되면 그 결과가 메인 대화로 돌아오는데, 각자 상세한 결과를 돌려주는 서브에이전트를 많이 돌리면 상당한 컨텍스트를 소모할 수 있습니다2. 세 서브에이전트가 저마다 수천 단어의 완전한 추론을 그대로 도로 밀어 넣으면, 오케스트레이터는 여러 에이전트가 완화하기로 했던 바로 그 문제를 자기 층위에서 다시 만나게 됩니다. 반환은 결론 자체만 담아야 하고, "어떻게 거기 이르렀는지"의 세부는 서브에이전트 자신의 컨텍스트에 남겨 둬야 합니다. 그 컨텍스트는 이미 다 쓰였고 곧 버려질 것입니다.
이것이 모든 위임이 백지에서 시작한다는 뜻은 아닙니다. 문서는 특별한 서브에이전트 유형인 포크를 언급합니다. "A fork is a subagent that inherits the entire conversation so far instead of starting fresh... The fork's own tool calls still stay out of your conversation and only its final result comes back, so your main context window stays clean."2 (포크는 백지에서 시작하는 대신 지금까지의 대화 전체를 물려받는 서브에이전트다. 그럼에도 포크 자신의 도구 호출은 여러분의 대화 밖에 머물고 최종 결과만 돌아오므로, 메인 컨텍스트 윈도는 깨끗이 유지된다.) 그러니 서브에이전트가 드물게 전체 기록을 봐야 하는 경우(가령 앞선 논의 전체에 근거한 깊은 요약을 만들어야 할 때)라도, 그 중간 사고는 여전히 오케스트레이터의 컨텍스트에 그대로 들어가지 않습니다. "결론만 돌려준다"는 원칙은 변함없고, 달라지는 것은 서브에이전트가 기록을 손에 쥔 채 출발하는지 여부뿐입니다.
"오케스트레이터-서브에이전트"는 한 벤더의 사적인 표현이 아닙니다. OpenAI의 Agents SDK 문서는 같은 구조를 매니저 패턴이라 부릅니다. "A central manager/orchestrator invokes specialized sub‑agents as tools and retains control of the conversation."4 (하나의 중앙 매니저/오케스트레이터가 특화된 서브에이전트를 도구로서 호출하고 대화의 제어권을 유지한다.) 단어만 바꿔 보면, 오케스트레이터 대신 매니저, 서브에이전트 대신 도구로서의 에이전트인데, 같은 것을 설명합니다. 하나의 중앙 노드가 작업을 쪼개고, 일을 넘기고, 전체의 제어권을 쥐는 한편, 실제 실행은 결과를 돌려주는 특화된 하위자들에게 가고, 중앙 노드는 다음에 무엇이 올지 계속 조종합니다. 이 분업의 모양을 알아보는 것이 한 프레임워크의 용어를 외우는 것보다 더 중요합니다. 거의 모든 멀티 에이전트 프레임워크의 문서에서 이 논리의 어떤 변형을 보게 될 것입니다.
Building effective agents (Anthropic Engineering) — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2
Create custom subagents (Claude Code Docs) — https://code.claude.com/docs/en/sub-agents ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
How we built our multi-agent research system (Anthropic Engineering) — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩2 ↩3 ↩4
Agents (OpenAI Agents SDK) — https://openai.github.io/openai-agents-python/agents/ ↩ ↩2