Minbook
EN
멀티 에이전트 워크플로 6 패턴 — Supervisor부터 Swarm까지
에이전트 & 아키텍처

멀티 에이전트 워크플로 6 패턴 — Supervisor부터 Swarm까지

M. · · 9 분 소요

멀티 에이전트 워크플로의 6가지 패턴(Supervisor / Sequential / Hierarchical / Network / Swarm / Map-Reduce)을 1차 자료 기반으로 정리. 각 패턴의 토폴로지와 적합 task, production에서 패턴 선택 의사결정 기준.

직전 글 싱글 vs 멀티 에이전트 — 같은 자료, 반대 결론에서 멀티 에이전트의 정의를 “다수 LLM이 분산된 의사결정과 위임 구조로 협업하는 시스템”으로 좁혔다. 본문이 비교에 사용한 두 사례 — Anthropic Multi-Agent Research System과 Cognition Devin — 은 모두 lead agent가 동적으로 위임을 결정하는 dynamic delegation 사례였다.

그러나 production에서 운영되는 multi-agent의 다수는 다르다. 사전 정의된 흐름 안에 여러 에이전트를 배치하는 hybrid 구조가 더 흔하다. LangGraph Supervisor, CrewAI Sequential Process, AutoGen GroupChat — 이름은 다르지만 모두 같은 영역에 속한다. 이 영역을 Anthropic은 “Workflows”, LangGraph는 “Multi-Agent Workflow”, OpenAI Agents SDK는 “Manager-style orchestration”이라 부른다.

이 글은 그 hybrid 영역의 6가지 핵심 패턴을 1차 자료 기준으로 정리한다. 각 패턴의 토폴로지, 적합 task, 안 맞는 task, 대표 구현을 살펴보고, 패턴 선택 의사결정으로 마무리한다.

Multi-Agent Workflow란 무엇인가

직전 글에서 정의한 3분류를 다시 가져오면 다음과 같다.

  • Workflow: LLMs and tools are orchestrated through predefined code paths (Anthropic)
  • Single Agent: 단일 LLM이 자신의 절차와 도구 사용을 동적으로 결정
  • Multi-Agent System (MAS): 다수 LLM이 분산된 의사결정과 위임으로 협업

세 정의 사이의 빈 공간이 Multi-Agent Workflow다. 흐름은 사전 정의된 코드(Workflow의 특성)이지만, 그 흐름 안에 여러 에이전트(MAS의 특성)가 배치되는 구조다. 직전 글의 정의 표를 확장하면 다음과 같다.

차원WorkflowMulti-Agent WorkflowMulti-Agent System (dynamic)
다음 행동 결정자코드 (predefined)코드 (predefined)LLM (dynamic delegation)
에이전트 수보통 1개다수다수
라우팅 방식조건문 / sequentialsupervisor가 사전 정의된 후보 중 선택, 또는 명시적 그래프lead가 자유롭게 위임
디버깅 난도낮음중간높음
비용 예측 가능성매우 높음높음낮음 (15x, variance 큼)
대표 구현LangChain Chain, prompt chainingLangGraph Supervisor, CrewAI Sequential, AutoGen GroupChatAnthropic Multi-Agent Research, custom orchestrator

LangGraph 공식 문서가 같은 구분을 명확히 한다.

“Workflows have predetermined code paths and are designed to operate in a certain order. Agents are dynamic and define their own processes and tool usage.” (LangGraph Docs)

핵심 차이는 흐름 결정자다. 누가 다음 행동을 결정하는가가 코드면 Multi-Agent Workflow, LLM이면 진짜 Multi-Agent System. 이 한 가지 차이가 디버깅 난도, 비용 예측 가능성, 운영 복잡도를 결정한다.

왜 Multi-Agent Workflow가 production에서 더 흔한가

직전 글에서 정리한 dynamic delegation의 트레이드오프 — 비용 폭증, sync bottleneck, rainbow deployment, 비결정성 디버깅, cascade failure — 는 모두 흐름이 LLM 결정에 의존한다는 점에서 비롯된다. Multi-Agent Workflow는 흐름을 코드로 못 박아 이 트레이드오프 다수를 완화한다.

  • 디버깅 가능성: 흐름이 graph 또는 sequential code로 정의되어 trace가 결정적이다. LangGraph는 각 노드의 state 변화를 step-by-step 추적할 수 있다.
  • 비용 예측 가능성: 호출 수의 상한이 흐름에서 명시적이다. dynamic delegation은 lead의 판단으로 50+ subagent까지 spawn될 수 있는 반면, Supervisor 패턴은 worker 수가 코드에 박혀 있다.
  • Sync bottleneck 회피: 명시적 fan-out/fan-in으로 어디서 병렬, 어디서 동기화할지가 코드에서 보인다.
  • 권한 분리: 각 에이전트가 어떤 도구를 사용 가능한지가 흐름 정의 시점에 결정된다. dynamic 위임은 lead가 권한을 가진 도구를 자유롭게 사용하도록 허용하는 경향이 있다.

OpenAI Agents SDK의 가이드 문서가 이 운영적 우위를 다음과 같이 정리한다.

“Manager-style orchestration: A central manager agent… routing tasks to specialist agents while maintaining oversight. Recommended for predictable cost and easier debugging.” (OpenAI Agents SDK)

production 운영팀이 dynamic delegation의 90.2% 향상을 기꺼이 포기하고 Multi-Agent Workflow를 택하는 이유다. 가능성보다 예측 가능성을 산다.

6가지 핵심 패턴

LangGraph 공식 문서가 5분류(Network / Supervisor / Hierarchical / Custom / Swarm)를 제시하고, 여기에 production에서 흔한 Sequential과 Map-Reduce를 더하면 6개 핵심 패턴이 된다.

Pattern 1 — Supervisor (Hub-and-Spoke)

가장 흔하고 가장 단순한 패턴. 중앙에 supervisor agent 하나가 있고, 여러 worker agent가 supervisor를 hub 삼아 hub-and-spoke 토폴로지를 이룬다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TD
    User --> Supervisor
    Supervisor --> Worker1[Worker 1]
    Supervisor --> Worker2[Worker 2]
    Supervisor --> Worker3[Worker 3]
    Worker1 --> Supervisor
    Worker2 --> Supervisor
    Worker3 --> Supervisor
    Supervisor --> Done

    classDef entry fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0c4a6e
    classDef exit fill:#ecfccb,stroke:#65a30d,stroke-width:2px,color:#365314
    class User entry
    class Done exit

흐름은 간단하다. supervisor가 사용자 요청을 받고, 자기 도구 목록(= worker agent 이름들) 중 하나를 골라 호출한다. worker가 결과를 supervisor에게 반환하고, supervisor가 다음 worker를 호출하거나 종료를 결정한다.

LangGraph가 langgraph-supervisor-py 라이브러리로 이 패턴을 표준화한다. CrewAI는 같은 구조를 Hierarchical Process (manager_llm 인자에 supervisor LLM 지정)로 부른다.

항목내용
적합 task다양한 전문 worker 중 task별 라우팅 (예: 고객 문의 → 결제팀 / 배송팀 / 환불팀)
안 맞는 task모든 worker가 매번 호출되어야 하는 task, worker 간 직접 통신이 필요한 task
대표 구현LangGraph Supervisor, CrewAI Hierarchical Process, OpenAI Agents SDK Manager pattern
핵심 결정점supervisor의 라우팅 정확도. 잘못 라우팅하면 wrong worker가 task를 시도

Pattern 2 — Sequential (Pipeline)

사전 정의된 순서대로 에이전트가 task를 pass하는 가장 단순한 흐름. CrewAI의 기본 Process가 이것이다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    User --> A1[Researcher Agent]
    A1 --> A2[Writer Agent]
    A2 --> A3[Editor Agent]
    A3 --> Done

    classDef entry fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0c4a6e
    classDef exit fill:#ecfccb,stroke:#65a30d,stroke-width:2px,color:#365314
    class User entry
    class Done exit

각 agent는 이전 agent의 출력을 입력으로 받는다. 분기·조건이 없는 linear chain이다. CrewAI Sequential Process 공식 문서는 다음과 같이 명시한다.

“Sequential Process: Tasks are executed one after another, where each task can build upon the results of previous tasks.” (CrewAI Docs)

항목내용
적합 task정해진 단계가 있는 task — 리서치 → 작성 → 편집 / 데이터 수집 → 분석 → 리포트
안 맞는 task분기·조건·재시도가 필요한 task, 단계 중 일부만 수행하는 task
대표 구현CrewAI Sequential Process, LangChain SequentialChain (legacy)
핵심 결정점각 단계 출력의 형식 일관성. 다음 agent가 이전 출력을 정확히 파싱할 수 있어야 함

가장 단순한 만큼 가장 견고하다. production에서 첫 multi-agent를 도입할 때 sequential로 시작해 supervisor로 진화하는 패턴이 흔하다.

Pattern 3 — Hierarchical (Multi-level Supervisor)

Supervisor 패턴을 다층으로 쌓은 구조. top-level supervisor 아래 sub-team supervisor들이 있고, 각 sub-team이 자기 worker를 갖는다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TD
    Top[Top Supervisor]
    Top --> S1[Research Team Supervisor]
    Top --> S2[Writing Team Supervisor]
    S1 --> W1[Web Researcher]
    S1 --> W2[Fact Checker]
    S2 --> W3[Writer]
    S2 --> W4[Editor]

    classDef entry fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0c4a6e
    class Top entry

LangGraph 공식 튜토리얼 “Hierarchical Agent Teams”가 이 패턴의 reference 구현이다. research_team과 writing_team이 각각 sub-supervisor를 갖고, top_level_supervisor가 두 팀 사이를 조율한다.

항목내용
적합 task도메인 분리 + 각 도메인 안에서 다중 worker가 협업하는 task. 큰 조직의 업무 분담 구조와 매핑
안 맞는 task단순한 task, 도메인이 1~2개에 그치는 task (불필요한 layer)
대표 구현LangGraph Hierarchical Agent Teams
핵심 결정점도메인 경계 설정. 잘못 자르면 sub-team 간 통신이 잦아지고 top supervisor가 병목이 됨

복잡도가 높아 작은 조직·간단한 task에는 over-engineering이다. Anthropic이 “start simple”을 강조하는 이유 중 하나도 이런 다층 구조의 유혹이다.

Pattern 4 — Network (Pre-defined DAG)

명시적으로 정의된 directed acyclic graph(DAG)를 따라 agent들이 호출되는 패턴. supervisor가 없고, 각 agent가 다음에 어떤 agent를 호출할지가 graph edges로 박혀 있다.

LangGraph의 StateGraph로 임의의 graph를 정의하는 것이 이 패턴의 일반형이다. 노드는 agent, edges는 명시적 호출 관계다. supervisor 패턴이 hub-and-spoke라면, network 패턴은 mesh다.

항목내용
적합 task복잡한 의존성이 명확히 정의 가능한 task. 컴파일 파이프라인, 다단계 데이터 처리
안 맞는 task흐름이 task별로 가변하는 task (graph가 task마다 달라야 한다면 dynamic이 더 맞음)
대표 구현LangGraph custom StateGraph
핵심 결정점graph 자체의 정확성. 사이클·dead-end·무한 루프를 design time에 제거해야 함

이 패턴은 가장 표현력이 높지만 가장 손이 많이 간다. supervisor와 sequential로 충분한데 network로 가면 over-engineering이다. 반대로 진짜 mesh 의존성이 필요한 task에서 supervisor를 쓰면 supervisor가 graph 로직 전부를 떠안아 한 노드에 복잡도가 집중된다.

Pattern 5 — Swarm (Handoff-based)

현재 active agent가 다음 agent에게 명시적으로 control을 handoff하는 패턴. supervisor가 아니라 현재 일을 하는 agent가 직접 다음 agent를 지정한다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    Triage[Triage Agent] -->|handoff| Math[Math Agent]
    Triage -->|handoff| Code[Code Agent]
    Math -->|handoff| Code
    Code -->|handoff| Math

    classDef entry fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0c4a6e
    class Triage entry

OpenAI가 2024년 말 experimental 라이브러리 swarm으로 이 패턴을 발표했고, 이후 production-ready Agents SDK의 handoff primitive로 정착했다. LangGraph도 langgraph-swarm-py로 같은 패턴을 지원한다.

OpenAI Agents SDK 공식 문서가 handoff의 핵심을 다음과 같이 명시한다.

“Handoffs allow an agent to delegate to another agent, transferring full message history. This is different from manager-style orchestration, where the manager retains control.” (OpenAI Agents SDK)

항목내용
적합 task전문성이 다른 agent들 사이에서 자연스러운 인계가 필요한 task. 고객 문의에서 분류 → 전문가로 직접 이관
안 맞는 task중앙 제어·감시가 필요한 task, audit trail이 단일 통제점에서 보여야 하는 규제 산업
대표 구현OpenAI Agents SDK Handoff, LangGraph Swarm, original OpenAI Swarm (experimental)
핵심 결정점무한 핑퐁 방지. agent A → B → A → B의 무한 handoff를 코드 레벨에서 차단해야 함

Swarm의 가장 큰 장점은 supervisor 병목이 없다는 점이고, 가장 큰 단점은 handoff 결정이 분산되어 누가 책임자인지 불명확하다는 점이다. supervisor 패턴이 “중앙 통제”라면 swarm은 “동료 간 인계”다.

Pattern 6 — Map-Reduce (Fan-out + Aggregator)

병렬 task fan-out + 결과 aggregator로 통합하는 패턴. classic Map-Reduce의 multi-agent 버전이다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TD
    Start --> Splitter[Splitter Agent]
    Splitter --> W1[Worker 1]
    Splitter --> W2[Worker 2]
    Splitter --> W3[Worker 3]
    W1 --> Agg[Aggregator Agent]
    W2 --> Agg
    W3 --> Agg
    Agg --> Done

    classDef entry fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0c4a6e
    classDef exit fill:#ecfccb,stroke:#65a30d,stroke-width:2px,color:#365314
    class Start entry
    class Done exit

LangGraph가 Send API로 이 패턴을 standard화한다. Send(node, state)로 동일 노드를 여러 state로 동시 호출하면, 각 호출이 병렬로 실행되고 결과는 자동으로 list에 모인다.

항목내용
적합 task병렬화 가능하고 결과를 합칠 필요가 있는 task. 다중 source 리서치, 대량 문서 분류, batch 처리
안 맞는 task순차 의존성이 강한 task, sub-task 간 통신이 잦은 task
대표 구현LangGraph Send (Parallelization), Anthropic의 multi-agent research에서 부분적 사용
핵심 결정점aggregator의 통합 로직. raw concatenation이면 LLM이 처리 가능하지만, 의미적 통합이면 aggregator 자체가 또 하나의 design challenge

Anthropic Research System이 부분적으로 이 패턴을 사용한다 — lead가 search query를 fan-out하고 subagent들이 병렬 검색, lead가 결과를 aggregate. 단 lead가 dynamic하게 fan-out 수를 결정한다는 점에서 순수 Map-Reduce(=고정 splitter)와 다르다.

보조 패턴 — Group Chat과 Evaluator-Optimizer

위 6가지 외에 production에서 마주치는 두 보조 패턴이 있다.

  • Group Chat (Round-Robin) — AutoGen이 표준화한 패턴. 여러 agent가 정해진 turn 순서로 발화하며 공유 context에 메시지를 누적한다. AutoGen GroupChat + GroupChatManager. 적합한 use case는 brainstorming·debate처럼 여러 관점을 누적하는 task. 한국어 자료에서 가장 자주 “멀티 에이전트”라고 잘못 동의어로 쓰이는 패턴이기도 하다 — 실제로는 매우 특수한 한 패턴이다.
  • Evaluator-Optimizer (Critic-Actor) — Anthropic Building Effective Agents 가이드의 6 패턴 중 하나. Generator agent가 출력을 만들고, Evaluator agent가 평가, 만족스러우면 종료, 아니면 Generator가 재시도. 코딩 task에서 작성+리뷰 루프, 글쓰기에서 작성+편집 루프에 자연스럽다. 단 evaluator의 기준이 명확하지 않으면 무한 루프가 된다.

두 패턴은 위 6가지의 변형으로 환원 가능하다. Group Chat은 “Turn-taking을 명시한 Sequential의 변형”이고, Evaluator-Optimizer는 “두 노드 사이의 conditional loop을 가진 Network의 변형”이다.

패턴 선택 — 의사결정

6+2 패턴을 마주한 production 팀의 첫 질문은 “내 task에는 어느 패턴인가”다. 토폴로지 + 코디네이션 두 차원으로 매트릭스를 그리면 선택이 보인다.

토폴로지 \ 코디네이션Sync (synchronous wait)Async fan-outConditional / branching
Hub-and-spokeSupervisorSupervisor + Map-Reduce 안Supervisor (라우팅)
LinearSequential(드뭄)Sequential w/ conditions
Mesh / DAGNetworkMap-ReduceNetwork
Multi-levelHierarchicalHierarchical + Map-ReduceHierarchical
Handoff (peer-to-peer)Swarm(드뭄)Swarm
---
config:
  look: handDrawn
  theme: neutral
---
flowchart TD
    A[Task 정의] --> B{여러 worker 중 라우팅?}
    B -->|예| C{도메인 layer 다중?}
    C -->|예| D[Hierarchical]
    C -->|아니오| E[Supervisor]
    B -->|아니오| F{정해진 순서가 있는가?}
    F -->|예| G[Sequential]
    F -->|아니오| H{병렬 fan-out + 통합?}
    H -->|예| I[Map-Reduce]
    H -->|아니오| J{명시적 graph로 의존성 정의?}
    J -->|예| K[Network]
    J -->|아니오| L{Agent 간 자율 인계?}
    L -->|예| M[Swarm]
    L -->|아니오| E

    classDef entry fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0c4a6e
    classDef exit fill:#ecfccb,stroke:#65a30d,stroke-width:2px,color:#365314
    class A entry
    class D,E,G,I,K,M exit

의사결정의 첫 분기는 “여러 worker 중 라우팅인가, 정해진 흐름인가”다. 이 한 분기가 절반의 패턴을 가른다.

실전은 패턴 조합 — Hybrid가 진짜 production

위 6+2 패턴을 단일하게 쓰는 production은 드물다. 대부분 두 패턴 이상을 조합한다.

  • Supervisor + Map-Reduce: supervisor가 task를 받고, 일부 단계는 fan-out으로 worker들에게 병렬 배분 후 aggregator가 통합. Anthropic Research System의 실제 구조에 가장 가까운 hybrid.
  • Hierarchical + Sequential: top supervisor가 sub-team을 라우팅하고, 각 sub-team 안은 Sequential. 큰 조직의 업무 흐름과 매핑.
  • Sequential + Evaluator-Optimizer: pipeline 중 한 단계에 critic-actor 루프 삽입. 작성 → (작성+리뷰 루프) → 편집.
  • Supervisor + Swarm: supervisor가 초기 분류만 하고, 그 이후는 worker 간 swarm handoff. 고객 응대 시스템에서 자주 보임.

OpenAI Agents SDK 공식 가이드가 이 hybrid를 다음과 같이 정리한다.

“These patterns are not mutually exclusive. A common production setup combines a manager (Supervisor) for top-level routing with handoffs (Swarm) at the leaf level for specialist-to-specialist transfer.” (OpenAI Agents SDK)

production 의사결정에서 가장 흔한 실수는 “한 패턴으로 전체를 풀려는 것”이다. 단일 패턴은 reference이고, 실제 시스템은 hybrid다. 패턴을 알아야 hybrid를 design할 수 있다.

다음 영역 — 평가

이 글은 패턴 카탈로그와 선택 기준에 한정했다. 패턴을 골라 시스템을 만든 다음 단계는 평가다.

  • 멀티 에이전트를 어떻게 평가하는가 — 비결정적 시스템의 evaluation 방법론. LLM-as-judge, human eval, 벤치마크의 한계 (UC Berkeley CRDI는 2026-04에 SWE-bench·GAIA·AgentBench 등이 reward hacking에 취약하다고 보고). 단일 호출과 달리 multi-agent는 trace 단위 evaluation이 핵심이고, evaluator agent 자체의 신뢰성도 평가 대상이 된다.

평가는 패턴 선택과 별개의 큰 영역이다. 본 글의 범위는 패턴 자체에 한정한다.

Sources

#multi-agent #agent-workflow #langgraph #autogen #crewai #swarm #supervisor #agent-architecture #agentic-workflow
공유

관련 글