감독자/오케스트레이터-워커 패턴(Supervisor / Orchestrator-Worker Pattern)

하나의 리드 에이전트(Lead Agent)가 계획을 세워 일을 위임하고, 전문화된 워커(Worker)들이 각자의 병렬 컨텍스트(Context)에서 작업을 수행한 뒤 결과를 보고합니다. 이것이 앤트로픽(Anthropic) 리서치(Research) 시스템의 바탕이 되는 패턴이며, 리드 역할에는 Claude Opus 4가, 서브에이전트(Subagent) 역할에는 Sonnet 4가 사용되었습니다. 앤트로픽 내부 리서치 평가(Research Eval)에서 단일 에이전트(Single-Agent) 기반 Opus 4 대비 +90.2%의 성능 향상이 측정되었고, 앤트로픽 엔지니어링 블로그(Anthropic Engineering Post)는 BrowseComp 점수 분산의 80%가 오로지 토큰 사용량(Token Usage)만으로 설명된다고 보고합니다. 멀티 에이전트(Multi-Agent)가 우세한 가장 큰 이유는 서브에이전트마다 새로운 컨텍스트 윈도(Fresh Context Window)를 받기 때문입니다. 이 강의는 가장 기초적인 요소(Primitive)에서부터 감독자 패턴(Supervisor Pattern)을 만들어 보고, 실제 운영 배포(Production Deployment)에서 도출된 2026년 시점의 엔지니어링 교훈을 함께 다룹니다.

유형: Learn + Build 언어: Python(stdlib, threading) 선수 조건: Phase 16 · 04(원시 모델 패턴, Primitive Model) 예상 시간: 약 75분

문제

리서치(Research)는 단일 에이전트(Single-Agent) 시스템이 실패하는 대표적인 과제입니다. 예를 들어 "2023년부터 2026년 사이에 멀티 에이전트 시스템(Multi-Agent System)에서 무엇이 바뀌었는가?"라는 질문을 던졌다고 가정해 봅시다. 단일 에이전트는 논문 다섯 편을 순차적으로 읽으면서 자기 컨텍스트의 절반을 그 본문으로 채우고, 그 다음 그 모두를 동시에 종합해 추론해야 합니다. 다섯 번째 논문에 도달할 때쯤이면 첫 번째 논문의 내용을 잊어버리고, 게다가 병렬화도 할 수 없습니다.

감독자 패턴(Supervisor Pattern)은 이 문제를 해결합니다. 하나의 리드 에이전트가 검색 계획을 세우고, 각 하위 질문(Sub-Question)을 워커에게 위임한 뒤, 마지막에 결과를 종합(Synthesize)합니다. 각 워커는 좁은 질문 하나에 대해 자기만의 200k 토큰 윈도를 받고, 리드는 원본 논문(Raw Paper)을 직접 읽지 않으며 워커가 정리한 요약(Summary)만 봅니다.

앤트로픽의 운영 환경 리서치 시스템은 내부 리서치 평가에서 단일 Opus 4 대비 +90.2%를 보고했습니다. 같은 글은 BrowseComp 분산의 80%가 토큰 사용량만으로 설명된다고 말합니다. 서브에이전트마다 새로운 컨텍스트를 부여하는 것이 핵심 메커니즘입니다.

개념

패턴

                 ┌──────────────┐
                 │   Lead       │  plans, decomposes,
                 │  (Opus 4)    │  synthesizes
                 └──┬────┬───┬──┘
                    │    │   │
            ┌───────┘    │   └───────┐
            ▼            ▼           ▼
      ┌─────────┐  ┌─────────┐  ┌─────────┐
      │ Worker1 │  │ Worker2 │  │ Worker3 │
      │(Sonnet) │  │(Sonnet) │  │(Sonnet) │
      └─────────┘  └─────────┘  └─────────┘
         fresh       fresh        fresh
         context     context      context

리드는 원본 자료(Raw Material)를 직접 읽지 않습니다. 워커들은 리드가 종합 단계를 시작하기 전까지 서로의 작업 결과를 보지 않습니다. 각 화살표는 좁은 산출물(Artifact) 하나가 오가는 인계(Handoff)입니다.

왜 이 패턴이 유리한가

세 가지 메커니즘이 작용합니다.

1. 서브에이전트마다 새로운 컨텍스트(Fresh Context)를 받습니다. "FIPA-ACL 계보(Heritage)"를 탐색하는 워커는 리드가 계획 수립(Planning)에 사용한 40k 토큰을 짊어지고 다니지 않습니다. 하나의 좁은 질문에 대해 200k 윈도를 온전히 씁니다.
2. 프롬프트(Prompt)를 통한 전문화입니다. 리드의 프롬프트는 "리서치하라"가 아니라 "분해하고 종합하라(Decompose and Synthesize)"입니다. 각 워커의 프롬프트는 "X에서 무엇이 바뀌었는지 찾아라"처럼 좁습니다. 집중된 프롬프트는 집중된 출력을 만듭니다.
3. 병렬성(Parallelism)을 활용합니다. 워커가 동시에 실행되므로, 전체 벽시계 시간(Wall-Clock Time)은 sum(worker_times)가 아니라 대략 max(worker_times) + plan + synthesis가 됩니다.

엔지니어링 교훈(Engineering Lessons; 앤트로픽 2025)

앤트로픽의 블로그 글에는 2026년 시점에도 여전히 유효한 운영 환경 교훈이 여럿 정리되어 있습니다.

• 질의 복잡도(Query Complexity)에 맞춰 노력을 조절하기(Scale Effort). 단순한 질의는 에이전트 하나에 툴 호출(Tool Call) 3~10번이면 충분합니다. 복잡한 질의는 10개 이상의 에이전트가 필요할 수 있습니다. 이 추정의 주체는 호출자(Caller)가 아니라 리드입니다.
• 먼저 넓게, 그 다음 좁게(Broad then Narrow). 우선 넓은 하위 질문으로 분해한 뒤, 답에 더 깊이가 필요하다고 판단되면 하위 질문별로 워커를 추가로 띄웁니다.
• 무지개 배포(Rainbow Deployment). 에이전트는 장시간 동작하면서 상태를 가진(Stateful) 프로세스입니다. 전통적인 블루-그린(Blue-Green) 배포가 잘 맞지 않습니다. 앤트로픽은 새 버전을 점진적으로 롤아웃(Rollout)하면서 옛 버전이 자연스럽게 빠져나가도록(Drain) 하는 무지개 방식을 사용합니다.
• 토큰 사용량이 지배적이다(Token Usage Dominates). 멀티 에이전트는 단일 에이전트 대비 약 15배의 토큰을 사용합니다. 과제의 가치가 비용을 정당화하는 경우에만 실행해야 합니다.

LangGraph의 방향 전환

LangGraph는 원래 상위 수준 헬퍼(High-Level Helper)인 create_supervisor를 포함한 langgraph-supervisor 라이브러리를 제공했습니다. 2025년에 LangChain은 감독자 패턴을 직접 툴 호출(Tool Calling) 방식으로 구현하라는 방향으로 권장 사항을 옮겼습니다. 툴 호출이 감독자가 무엇을 보는지를 더 정밀하게 제어할 수 있게 해 주기 때문입니다(컨텍스트 엔지니어링, Context Engineering). 라이브러리는 여전히 동작하지만, 공식 문서는 이제 툴 호출 형태를 권장합니다.

실패 모드(Failure Modes)

• 리드가 계획을 환각함(Hallucinate the Plan). 리드가 실제 질문을 제대로 분해하지 못한 하위 질문을 만들면, 워커들은 잘못된 대상을 매우 정확하게 리서치합니다.
• 워커의 과도한 탐색(Over-Explore). 명시적인 범위 경계(Scope Boundary)가 없으면 워커가 배정받은 하위 질문을 벗어나 종합 단계를 오염시킵니다.
• 종합 충돌(Synthesis Conflict). 두 워커가 서로 모순되는 사실을 반환하는 경우입니다. 리드는 다시 물어 한 라운드를 추가하거나, 불일치(Disagreement)를 명시적으로 기록해야 합니다. 가장 나쁜 실패는 조용히 한쪽 답을 고르는 것입니다. 사용자는 불일치가 있었다는 사실 자체를 알 수 없게 됩니다.

감독자 패턴이 적절하지 않은 경우

• 순차적 작업(Sequential Tasks). 2단계가 말 그대로 1단계의 출력을 필요로 한다면 병렬성은 이득이 없습니다. 파이프라인(Pipeline)을 쓰는 편이 낫습니다(CrewAI Sequential, LangGraph 선형 그래프).
• 단순한 질의(Simple Queries). 단일 에이전트가 더 빠르고 저렴하게 처리합니다. 워커를 띄우기 전에 리드의 "노력 조절(Scale Effort)" 점검을 거치세요.
• 엄격한 결정성(Strict Determinism)이 필요한 경우. 감독자 패턴은 LLM이 선택한 위임(LLM-Selected Delegation)을 사용합니다. 적응성(Adaptability)보다 감사/재현(Audit/Replay)이 더 중요하다면 정적 그래프(Static Graph)가 낫습니다.

만들어보기

code/main.py는 threading을 사용해 세 개의 병렬 워커를 가진 감독자를 구현합니다. 리드는 질의를 하위 질문으로 분해하고, 워커는 각 하위 질문을 동시에 실행하며, 리드가 마지막에 결과를 종합합니다. 실제 LLM 호출은 없습니다. 워커는 가져오기-요약(Fetch-and-Summarize)을 시뮬레이션하는 스크립트 함수입니다.

핵심 구조는 다음과 같습니다.

• Lead.plan(query)는 질의를 세 개의 하위 질문으로 나눕니다.
• Worker.run(sub_q)는 가짜 요약(Summary)을 반환합니다. 운영 환경에서는 툴을 사용하는 에이전트가 그 자리를 차지할 수 있습니다.
• Lead.run(query)는 워커 스레드(Thread)를 시작하고, 스레드를 모두 기다린 뒤(join) 종합합니다.

실행:

python3 code/main.py

출력에는 계획(plan), 시작/종료 타임스탬프가 붙은 병렬 워커 트레이스(Trace), 최종 종합 결과가 표시됩니다. 벽시계 시간 이득도 직접 확인할 수 있습니다. 0.3초짜리 워커 세 개가 약 0.35초 만에 끝나며, 0.9초가 걸리지 않습니다.

사용해보기

outputs/skill-supervisor-designer.md는 사용자의 질의를 받아 감독자 패턴 설계(Supervisor-Pattern Design)를 만들어 줍니다. 리드의 시스템 프롬프트(System Prompt), 워커 역할, 하위 질문 분해 규칙, 종합 템플릿(Synthesis Template)을 생성합니다. 새로운 리서치형 에이전트 시스템을 만들기 전에 이 스킬을 활용하세요.

산출물 만들기

감독자 패턴을 배포하기 전에 점검해야 할 체크리스트입니다.

• 모델 페어링(Model Pairing). 리드는 추론 등급(Reasoning-Tier) 모델(Opus 계열, o3 계열)에 두고, 워커는 더 빠르고 저렴한 모델(Sonnet, o4-mini)에 둡니다.
• 워커 타임아웃(Worker Timeout). 중앙값 실행 시간(Median Runtime)의 2배를 넘는 워커는 종료(kill)합니다. 리드는 더 좁은 범위로 다시 띄우거나, 해당 워커 없이 진행합니다.
• 워커별 토큰 상한(Token Cap per Worker). 예를 들어 예상 종합 입력의 10배 같은 엄격한 상한(Hard Limit)을 둬서, 폭주하는 워커(Runaway Worker)가 예산을 터뜨리지 못하게 합니다.
• 관측성(Observability). 리드의 계획, 각 워커의 툴 호출, 종합 과정을 모두 추적(trace)합니다. 이것이 사후 디버깅(Post-hoc Debugging)의 기반이 됩니다.
• 무지개 롤아웃(Rainbow Rollout). 상태를 가진 채 오래 동작하는 에이전트는 즉시 교체(Hot Swap)가 아니라 점진적인 버전 전환(Gradual Version Transition)이 필요합니다.

연습문제

1. (쉬움) code/main.py를 실행한 뒤, 리드가 워커 3개 대신 5개를 띄우도록 수정해 보세요. 벽시계 시간 변화를 관찰하세요. 이 데모에서는 워커 수가 몇 개에 도달했을 때 스폰 오버헤드(Spawn Overhead)가 병렬 이득을 넘어섭니까?
2. (중간) 워커 타임아웃을 구현하세요. 0.5초보다 오래 실행되는 워커는 종료하고, 리드가 남은 결과만으로 종합하게 만드세요. 어떤 워커가 잘렸다는 사실을 알기 위해서는 어떤 관측성 지표가 필요합니까?
3. (중간) 리드의 종합 단계에 충돌 감지(Conflict Detection) 단계를 추가하세요. 두 워커가 모순되는 답을 반환하면 리드가 한쪽을 임의로 고르지 않고 불일치를 기록하도록 합니다. LLM을 호출하지 않고 모순을 어떻게 감지할 수 있을까요?
4. (중간) 앤트로픽의 리서치 시스템 엔지니어링 글을 읽으세요. 이 토이 데모(Toy Demo)가 운영 환경에서 동작하려면 채택해야 할 실천(Practice) 세 가지를 정리해 보세요.
5. (어려움) LangGraph의 create_supervisor(레거시)와 새 툴 호출 권장 방식을 비교하세요. 어느 쪽이 감독자가 보는 내용을 더 잘 제어할 수 있습니까? 앤트로픽은 왜 원본 워커 컨텍스트(Raw Worker Context)가 아니라 하위 답(Sub-Answer)만 종합에 명시적으로 넘기는 것일까요?

핵심 용어

더 읽을거리

• Anthropic engineering — How we built our multi-agent research system — 감독자 패턴의 운영 환경 레퍼런스입니다.
• LangGraph workflows and agents — 툴 호출 기반 감독자가 현재의 권장 형태(Recommended Form)임을 안내합니다.
• LangGraph supervisor reference — 2026년 운영 환경에서도 여전히 사용되는 레거시 헬퍼(Legacy Helper)입니다.
• OpenAI cookbook — Orchestrating Agents: Routines and Handoffs — 인계(Handoff) 기반의 감독자 변형(Variant)입니다.