오케스트레이터와 하위 에이전트

• 오케스트레이터-워커(orchestrator-worker): 관리자(오케스트레이터) 에이전트가 작업을 나눠 하위 에이전트(sub-agent, 워커)에게 맡기고 결과를 종합하는 구조.
• 멀티 에이전트 시스템의 중앙 집중 구조 + 모델 기반 전략. Claude Code·Codex의 subagent, 조사(Research) 기능 등 실제 제품에서 가장 많이 쓰는 형태.

에이전트를 도구로 쓰기

• 에이전트-도구(agent-as-tool): 하위 에이전트 하나를 함수 하나로 감싸 관리자에게 도구로 제공. 관리자 입장에서는 9주의 함수 호출과 같음.
• 라우팅(routing): 요청 종류에 맞는 하위 에이전트 하나에게 보냄(환불 문의 → 환불 에이전트).
• 병렬화(parallelization): 서로 의존하지 않는 하위 작업을 동시에 맡김. 시간은 가장 느린 하위 에이전트 수준.
• 종합(synthesis): 결과를 모아 최종 답을 만듦. 부족하면 더 부름.

flowchart TB
    U[사용자 요청] --> O[관리자 에이전트]
    O -->|하위 작업 1| S1[하위 에이전트 1]
    O -->|하위 작업 2| S2[하위 에이전트 2]
    O -->|하위 작업 3| S3[하위 에이전트 3]
    S1 -->|결과 요약| O
    S2 -->|결과 요약| O
    S3 -->|결과 요약| O
    O --> A[최종 답변]

컨텍스트 격리로서의 하위 에이전트

• 12주 컨텍스트 엔지니어링의 격리(isolation). 하위 에이전트는 빈 이력(blank history)으로 시작해 결과만 돌려줌(Breunig 2026).
• 효과: 검색 결과·실패한 시도는 하위 에이전트에만 남고 관리자에는 요약만 들어감 → 관리자의 컨텍스트가 짧고 깨끗함. 하위 에이전트마다 다른 지시문·도구·더 싼 모델 사용 가능.
• 대가: 요약 과정의 정보 손실, 하위 에이전트끼리 서로의 결정을 모름(맥락 공유 문제).
• 그래서 하위 작업은 "서로 독립적이고 결과를 짧게 요약할 수 있는" 것이 좋음. 조사(research)가 대표적.

출처: Drew Breunig(2026), The State of Context Engineering

사례

• Anthropic 조사 시스템(2025): 관리자(Claude Opus 4)가 전략을 세우고 하위 에이전트(Sonnet 4) 여럿을 병렬로 띄워 각자 다른 측면을 검색. 연구는 단서에 따라 경로가 바뀌는(경로 의존성) 개방형 문제라 경로를 나눠 넓게 훑는 데 유리. 출처: Anthropic(2025)
• Google AI Co-Scientist(2025): 관리(Supervisor) 에이전트가 생성·반성·순위·진화 등 전문 에이전트에 작업을 배정해 연구 가설을 만듦. 순위(Ranking) 에이전트는 가설끼리 토너먼트를 벌여 Elo 점수를 매김. 출처: Gottweis 외(2025), arXiv:2502.18864
• A2A(Agent2Agent) 프로토콜: 다른 회사·서버의 에이전트끼리 서로를 찾고 작업을 맡기는 개방형 규약(2025 Google 발표, 리눅스 재단 기증). 에이전트 카드(Agent Card, 이름·주소·할 수 있는 일을 적은 JSON)로 상대를 고름. MCP가 에이전트 ↔ 도구라면 A2A는 에이전트 ↔ 에이전트. 출처: A2A Protocol – Key Concepts

실습: 조사 에이전트 세 개를 병렬로 부르기

• 관리자에게 research 도구 하나를 줌. 호출하면 그 안에서 하위 에이전트가 빈 이력으로 시작해 조사(실습에서는 검색 도구 없이 모델 지식만 사용).

!pip install -q openai

from pathlib import Path
from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=Path("openrouter-key.txt").read_text().strip(),
)
model = "openai/gpt-4.1-mini"

• 하위 에이전트는 자세한 조사 노트를 쓴 뒤 3줄 요약을 만듦. 노트가 담긴 이력은 함수 안에만 있고 요약만 돌려줌(컨텍스트 격리).

def chat(messages, **kw):
    return client.chat.completions.create(model=model, messages=messages, **kw).choices[0].message

def run_subagent(topic):
    history = [{"role": "user", "content": f"조사 주제: {topic}\n근거와 반론을 포함해 자세한 조사 노트를 써라."}]
    history.append({"role": "assistant", "content": chat(history).content})
    history.append({"role": "user", "content": "관리자에게 보낼 핵심 결과를 3줄 이내 개조식으로 요약하라."})
    summary = chat(history).content
    return summary, sum(len(m["content"]) for m in history) + len(summary)

import json

tools = [{"type": "function", "function": {
    "name": "research", "description": "조사 에이전트에게 하위 주제 하나를 맡긴다.",
    "parameters": {"type": "object", "properties": {"topic": {"type": "string"}}, "required": ["topic"]}}}]
messages = [
    {"role": "system", "content": "너는 조사 관리자다. 질문을 겹치지 않는 하위 주제 3개로 나눠 research 도구를 "
                                  "한 번에 3번 호출하고, 결과를 종합해 답한다."},
    {"role": "user", "content": "대학 수업에서 과제에 생성형 AI 사용을 전면 허용해야 할까?"},
]
request = chat(messages, tools=tools)
topics = [json.loads(c.function.arguments)["topic"] for c in request.tool_calls]

from concurrent.futures import ThreadPoolExecutor

with ThreadPoolExecutor() as ex:  # 하위 에이전트 3개를 동시에 실행
    results = list(ex.map(run_subagent, topics))
for topic, (summary, full) in zip(topics, results):
    print(f"[{topic}] 이력 {full:,}자 → 요약 {len(summary):,}자")

[대학 수업에서 과제에 생성형 AI 사용의 장점] 이력 2,180자 → 요약 132자
[대학 수업에서 과제에 생성형 AI 사용의 단점] 이력 2,175자 → 요약 119자
[대학 수업에서 과제에 생성형 AI 사용 시 고려해야 할 윤리적 문제] 이력 2,466자 → 요약 145자

• 관리자가 한 응답에서 도구 호출 3개를 요청(병렬 도구 호출)했고, 위 실행에서는 장점·단점·윤리 문제로 나눔. 나누는 방식은 실행마다 다름.
• 하위 에이전트의 이력은 각 2,200-2,500자지만 관리자에게는 120-150자만 돌아감(약 6%).
• 종합: 요약을 tool 메시지로 돌려주고 관리자를 한 번 더 호출하면 최종 답을 씀. 요약에 없는 근거는 최종 답에도 없음 → 요약에 무엇을 담을지 지시하는 것이 중요.

생각해 볼 점

• 관리자가 하위 주제를 잘못 나누면(겹치거나 빠지면) 하위 에이전트가 잘해도 결과가 나쁨. 작업 분해가 관리자의 핵심 역할.
• 요약이 너무 짧으면 근거를 확인할 수 없음. 실제 시스템은 출처 목록을 함께 주거나 자세한 결과를 파일에 저장하고 경로만 돌려줌.
• 호출 수: 관리자 2번 + 하위 에이전트 3개 × 2번 = 8번. 단일 호출보다 비용이 몇 배.