Multi-agent orchestration — supervisor·swarm·planner-executor 패턴 비교

“이 캠페인 분석해서 슬랙으로 공유해줘”라고 한 LLM에 시키면 데이터 조회·분석·작성·전송을 모두 하나의 모델이 합니다. 그런데 작업이 길어질수록 모델이 헷갈리고, 한 단계 실패가 전체를 멈춥니다. multi-agent orchestration은 여러 에이전트가 역할을 나눠 협업하는 구조입니다. 3가지 표준 패턴과 마케팅 자동화에 적용하는 자리를 정리합니다.

마케터가 이 글을 읽어야 하는 이유: LLM 자동화가 한 단계 작업(요약·분류)을 넘어 여러 단계 작업(분석 + 보고 + 전송)으로 가면 단일 모델로는 안정적이지 않습니다. orchestration 패턴을 알면 자동화 설계의 전체 그림이 잡히고, 어느 자리에 어느 패턴이 맞는지가 분명해집니다.

supervisor 패턴, swarm 패턴, planner-executor 패턴 3가지를 좌우 비교한 다이어그램 — 중앙 통제냐 자율 협력이냐, 계획-실행 분리냐 — 자리에 따라 답이 다르다.

1. 단일 에이전트의 한계

단일 LLM에 복잡한 작업을 맡기면 다음 자리에서 깨집니다.

문제	증상
컨텍스트 누적	단계가 길어질수록 토큰 제곱 비용 증가
역할 혼동	분석 중인지 보고 작성 중인지 흐려짐
도구 선택 헷갈림	같은 도구를 반복 호출하거나 잘못된 도구 호출
한 단계 실패가 전체 멈춤	중간에 한 도구가 실패하면 복구 어려움

multi-agent는 이 문제를 “역할 분할”로 풉니다. 데이터 조회 에이전트, 분석 에이전트, 작성 에이전트가 각자 역할만 책임지고 다른 에이전트가 결과를 받아 다음 단계.

2. 패턴 1 — Supervisor (중앙 통제)

가장 직관적인 패턴. 중앙에 supervisor 에이전트가 있고, 그 supervisor가 여러 worker 에이전트에게 작업을 분배합니다.

사용자 요청
     │
     ▼
┌─ Supervisor 에이전트 ─┐
│ "이 작업을 어느 워커에│
│  맡길지 결정"        │
└────┬─────┬─────┬────┘
     │     │     │
     ▼     ▼     ▼
  워커1  워커2  워커3
 (조회) (분석) (작성)
     │     │     │
     └─────┴─────┘
           │
           ▼
      Supervisor에게 결과 반환
           │
           ▼
      사용자에게 답변

2-1. 적합한 자리

작업 단계가 명확히 나뉨 (조회 → 분석 → 작성)
워커들이 서로 독립 (한 워커의 결과가 다른 워커에 강하게 의존하지 않음)
디버깅·모니터링 중요

2-2. 한계

supervisor가 병목이 됨 (모든 결정이 한 곳을 거침)
워커 간 직접 협업 어려움
supervisor 한 번 호출이 비싸 비용 증가

대부분의 실무 자리에서 첫 번째로 시도할 패턴. LangGraph의 supervisor architecture가 이 패턴의 표준 구현.

3. 패턴 2 — Swarm (자율 협력)

supervisor 없이 에이전트들이 서로에게 작업을 직접 패스합니다. handoff 기반 구조.

사용자 → 에이전트 A (분류 담당)
              │
              "이건 데이터 조회야" handoff
              │
              ▼
         에이전트 B (조회 담당)
              │
              "분석이 필요해" handoff
              │
              ▼
         에이전트 C (분석 담당)
              │
              ▼
            사용자

3-1. 적합한 자리

작업 흐름이 동적이고 미리 정해두기 어려움
에이전트들이 자기 영역을 명확히 알고 자율 결정
빠른 반응이 중요

3-2. 한계

디버깅 어려움 (handoff 흐름이 복잡)
무한 loop 위험 (A → B → A → B…)
비용 예측 어려움

OpenAI의 Swarm framework, AutoGen의 GroupChat이 이 패턴의 구현. 마케팅 운영보다는 연구·실험적 자리에 더 자주 등장.

4. 패턴 3 — Planner-Executor

큰 LLM이 계획을 세우고, 작은 LLM이 단계별로 실행합니다. 비용·정확도 둘 다 잡는 하이브리드 패턴.

사용자 요청
     │
     ▼
┌─ Planner (대형 모델, 한 번 호출) ─┐
│ "다음 4단계로 진행:                │
│  1. ROAS 데이터 조회               │
│  2. 변화 추세 분석                 │
│  3. 보고서 초안 작성              │
│  4. 슬랙 전송"                     │
└────────────┬────────────────────┘
             │
             ▼
┌─ Executor (소형 모델, 단계별 호출) ─┐
│ 단계 1 실행 → 결과 저장             │
│ 단계 2 실행 → 결과 저장             │
│ 단계 3 실행 → 결과 저장             │
│ 단계 4 실행 → 완료                  │
└────────────┬────────────────────┘
             │
             ▼
        사용자에게 답변

4-1. 적합한 자리

작업이 중장기적이고 계획이 명확히 잡힘
비용 통제 중요 (큰 모델은 한 번만 호출)
단계별 결과를 사용자에게 점진적 보여주는 UX

4-2. 한계

planner의 잘못된 계획이 전체에 영향
동적 변화(예: 중간에 데이터 부족 발견)에 약함
두 모델 통합 운영 부담

LangChain의 Plan-and-Execute, OpenAI Assistants API의 일부 패턴이 이 구조. 보고서 자동화·다단계 분석 자리에 적합.

5. 코드 한 묶음 — Supervisor 패턴 의사코드

이게 글에 박는 유일한 코드입니다. 마케팅 보고 자동화의 supervisor 흐름.

# 의사코드 — 핵심 흐름만
SUPERVISOR_PROMPT = """다음 워커 중 하나를 선택해 작업을 패스하라:
- data_worker: BigQuery·광고 API 조회
- analysis_worker: 추세·비교 분석
- writer_worker: 보고서 작성
- slack_worker: 슬랙 전송
- finish: 작업 완료"""

def supervisor_step(messages):
    resp = call_llm("gpt-5", messages=messages,
                    system=SUPERVISOR_PROMPT,
                    response_format={"next": str, "task": str})
    return resp["next"], resp["task"]

WORKERS = {
    "data_worker": call_data_worker,
    "analysis_worker": call_analysis_worker,
    "writer_worker": call_writer_worker,
    "slack_worker": call_slack_worker,
}

def run_workflow(user_request, max_steps=10):
    messages = [{"role": "user", "content": user_request}]
    for step in range(max_steps):
        next_worker, task = supervisor_step(messages)
        if next_worker == "finish":
            break
        result = WORKERS[next_worker](task)
        messages.append({"role": "tool", "name": next_worker,
                         "content": result})
    return messages

supervisor가 매 단계마다 다음 워커를 결정하고, 워커가 작업을 실행해 결과를 messages에 추가. 무한 loop 방지 위한 max_steps 필수.

6. 패턴 선택 결정 트리

자리	작업 단계	흐름	패턴
FAQ 챗봇	1-2단계	단순	단일 에이전트
데이터 조회+답변	2-4단계	정해짐	Supervisor
일일 보고 자동화	4-6단계	정해짐	Planner-Executor
사용자 의도에 따라 분기	동적	가변	Supervisor 또는 Swarm
연구·실험	매우 동적	예측 어려움	Swarm

대부분의 마케팅 자동화는 Supervisor 또는 Planner-Executor가 적합. Swarm은 운영 안정성이 약해 일반 자리에 부적합.

7. 운영 안정성 — multi-agent의 함정

7-1. 무한 loop

에이전트 간 handoff가 순환할 위험. max_steps·max_handoffs 상한 필수. 보통 10-15 단계 이내로 제한.

7-2. 컨텍스트 누적

각 에이전트가 이전 단계의 모든 컨텍스트를 받으면 토큰이 폭발. 결과 요약·관련 정보만 다음 에이전트에 전달하는 컨텍스트 다이어트.

7-3. 비용 폭주

각 에이전트 호출이 별도 LLM 호출이라 단일 에이전트보다 비용이 5-10배. caching·작은 모델 활용으로 보완. LLM token economics 참고.

7-4. 디버깅 어려움

어느 에이전트에서 깨졌는지 추적이 어려움. 단계별 로그·trace ID 필수. LangSmith·Langfuse 같은 도구 활용.

8. 마케팅 자동화의 적용 자리 4가지

8-1. 일일 캠페인 보고 자동화

조회(BigQuery) → 분석(이상치 탐지) → 작성(자유 산문) → 전송(Slack). Planner-Executor 패턴이 자연스럽게 맞음.

8-2. 사용자 의도 라우팅 챗봇

분류(FAQ vs 데이터 조회 vs 액션) → 적합한 워커로 라우팅. Supervisor 패턴.

8-3. 콘텐츠 작성 + 검수

작성 에이전트 → 검수 에이전트 → 수정 에이전트의 파이프라인. Planner가 큰 흐름 잡고 Executor들이 실행.

8-4. 실시간 알림 분석

이상치 감지 → 원인 분석 → 알림 전송. Supervisor가 단계 결정.

LLM 자동화가 단순 작업을 넘어 운영의 표준 도구로 자리 잡을수록 multi-agent orchestration이 자연스럽게 들어옵니다. supervisor·swarm·planner-executor 3가지 패턴 중 자리에 맞는 한 가지를 골라 도입하면 단일 에이전트의 한계를 넘어설 수 있습니다. 다만 비용·디버깅·loop 방지 같은 운영 안정성 항목을 미리 챙겨야 합니다.

다음 분기에 한 번만 시도해 볼 만한 것은 가장 자주 돌리는 단일 에이전트 자동화 한 자리에 supervisor 패턴을 도입해 단계별 디버깅이 쉬워지는지 비교하는 흐름입니다. 작은 자리부터 도입해 운영 감각을 쌓는 게 표준 경로입니다.

다음에 읽을 글

Function calling 설계 패턴 — multi-agent의 기반 도구 호출
LLM 에이전트 평가 — multi-agent 시스템 평가 프레임워크
LLM token economics — multi-agent의 단위 경제학

참고

LangGraph, “Multi-agent supervisor”: https://langchain-ai.github.io/langgraph/tutorials/multi_agent/agent_supervisor/
OpenAI, “Swarm framework”: https://github.com/openai/swarm
Microsoft AutoGen: https://microsoft.github.io/autogen/
“Plan-and-Execute” (LangChain): https://blog.langchain.dev/planning-agents/
“ReAct” (Yao et al., 2022): https://arxiv.org/abs/2210.03629