고충 (The Pain): A2A 사고를 위해 이메일, 견적, 보고서, 재무, 지원 등 5개의 에이전트로 나눕니다. 각 에이전트는 혼자서는 잘 작동하지만, 복잡한 작업을 위해 협업할 때: 누가 순서를 결정할까요? 누가 충돌을 해결할까요? 누가 실패를 백업할까요? 리더 없는 협업은 혼돈이 됩니다.
학습 내용: Supervisor (관리자) 아키텍처 — 멀티 에이전트 시스템 (multi-agent systems)을 위한 최적의 조직 구성 방식, 그리고 왜 "하나의 관리자 + 다수의 작업자"가 "동료 협업 (peer collaboration)"보다 우수한지에 대해 알아봅니다.

뜨거운 배경: 왜 2026년에 Supervisor가 주류가 되었는가

2026년, 기업용 멀티 에이전트 시스템의 주류 아키텍처는 "동료 협업 (peer collaboration)"에서 "Supervisor + Worker (관리자 + 작업자)"로 전환되었습니다.

이유는 무엇일까요? 세 가지 이유가 있습니다:

1. 동료 협업의 "의사결정 진공 (decision vacuum)" 상태: 5명의 동료 에이전트가 "누가 먼저, 누가 다음인가"를 두고 충돌할 때 — 중재자가 없습니다. 교착 상태(Deadlock)에 빠지거나, 모두가 동시에 일을 하게 됩니다.
2. 단일 책임 원칙의 한계: 작업과 결정을 동시에 수행하는 에이전트는 의사결정 로직에 의해 컨텍스트 (context)가 오염되어 — 작업 품질이 저하됩니다.
3. 관측 가능성 (Observability) 요구: 기업은 모든 에이전트의 행동을 균일하게 감사할 수 있는 "마스터 컨트롤 (master control)"이 필요하며 — Supervisor가 바로 그 마스터 컨트롤 역할을 합니다.

한 줄 요약: 에이전트가 많아질수록 관리자가 더 많이 필요합니다. Supervisor 아키텍처는 멀티 에이전트 시스템을 위한 2026년의 조직적 해답입니다.

문제점: 동료 협업의 세 가지 함정

저는 서로를 볼 수 있고 필요에 따라 서로를 호출할 수 있는 5개의 "동료 (peer)" 에이전트로 시작했습니다. 세 가지 문제가 발생했습니다:

함정 1: 누가 먼저인가?

사용자: 요율 확인 → 견적 업데이트 → 고객에게 이메일 발송

동료 협업 (Peer collaboration):
...

함정 2: 누가 중재하는가?

요율 에이전트가 두 가지 가능성(해상/항공)을 반환함
  견적 에이전트 (Quoting Agent): 해상 사용
  재무 에이전트 (Finance Agent): 항공 사용 (과거 견적은 항공을 사용함)
...

함정 3: 누가 백업하는가?

이메일 에이전트 실패 (클라이언트의 이메일 형식이 변경됨)
  3회 재시도하지만, 여전히 실패
  그다음은? 아무도 처리하지 않음 — 작업이 영원히 멈춰버림

근본 원인 (Root cause): 동료 협업 (peer collaboration) 방식은 "작업"과 "결정"을 혼합합니다. 모든 에이전트가 작업자이자 관리자 역할을 동시에 수행하므로, 어느 쪽도 제대로 수행되지 않습니다.

Supervisor 아키텍처: 한 명의 관리자, 다수의 작업자

Supervisor 아키텍처의 핵심은 다음과 같습니다: 하나의 "관리자 에이전트 (manager agent)"가 스케줄링 (scheduling)을 담당하고, 여러 "작업자 에이전트 (worker agents)"가 실행 (execution)을 담당합니다. 관리자는 직접 작업하지 않으며, 작업자는 결정하지 않습니다.

┌─────────────────────────────┐
│      Supervisor Agent        │
│  (manager: decide/schedule)  │
...

책임의 분리 (Division of responsibility):

나의 실습: 물류 Supervisor

나는 물류 Supervisor로서 "스케줄러 에이전트 (Scheduler Agent)"를 추가했습니다:

class SupervisorAgent:
    """Manager agent: 오직 스케줄링만 수행하며, 직접적인 작업은 절대 하지 않음"""

...

핵심 설계:

• Supervisor의 컨텍스트 (context)에는 "스케줄링 로직 (scheduling logic)" (어떻게 분해/순서 지정/조정할 것인가)만 포함되며, "비즈니스 지식 (business knowledge)" (요율을 어떻게 계산할 것인가)는 포함되지 않습니다.
• Worker의 컨텍스트에는 "비즈니스 지식"만 포함되며, "스케줄링 로직"은 포함되지 않습니다.
• 두 컨텍스트 모두 깨끗하게 유지되어 상호 오염 (cross-contamination)이 발생하지 않습니다.

결과: "혼란스러운 협업"에서 "질서 있는 파이프라인 (Ordered Pipeline)"으로

Supervisor vs Peer: 언제 무엇을 사용할 것인가

Peer로 충분한 경우: 에이전트가 2~3개이며, 작업이 단순하고, 복잡한 의존 관계가 없는 경우 — Peer 방식은 계층을 절약할 수 있습니다.

Supervisor가 필요한 경우:

1. 5개 이상의 에이전트 (더 많은 인원에는 관리가 필요합니다)
2. 순차적 의존 관계가 있는 작업 (순서가 틀리면 모든 것이 망가집니다)
3. 통합된 감사/추적 (Audit/Tracking)이 필요한 경우 (엔터프라이즈 요구사항)
4. 충돌이 빈번하게 발생할 가능성이 있는 경우

현재 당신의 위치

당신은 "에이전트를 나누어 놓고 알아서 하게 두자"라는 순진함에서 벗어나, "에이전트 팀에게 관리자를 부여한다"라는 성숙한 단계로 진화했습니다.

Supervisor 아키텍처는 멀티 에이전트 시스템 (Multi-agent systems)에서 "협업할 수 있는 상태"와 "신뢰할 수 있게 협업하는 상태"를 가르는 분기점입니다. 이는 복잡한 것이 아니라, 단지 "스케줄링만 담당하는" 에이전트 하나를 두는 것뿐입니다. 하지만 바로 이 "아무것도 하지 않는" 관리자가 전체 시스템을 질서 있고, 제어 가능하며, 추적 가능한 상태로 만듭니다.

기억하세요: 에이전트 팀은 인간 팀과 같습니다. 사람이 많다고 좋은 것이 아니라, 조직화되어 있는 것이 좋습니다. Supervisor는 "다수"를 "질서"로 바꾸는 관리자입니다.

저자 소개: Wu Ji (无记) — 에이전트 엔지니어링 (Agent engineering), 루프 엔지니어링 (Loop Engineering), 디지털 전환 (Digital transformation)에 집중하는 AI 및 디지털화 실무자. 실용적이고 직접적인 튜토리얼 — 따라 하기만 하면 바로 작동합니다.