"이 캠페인 분석해서 슬랙으로 공유해줘"라고 한 LLM에 시키면 데이터 조회·분석·작성·전송을 모두 하나의 모델이 합니다. 그런데 작업이 길어질수록 모델이 헷갈리고, 한 단계 실패가 전체를 멈춥니다. multi-agent orchestration은 여러 에이전트가 역할을 나눠 협업하는 구조입니다. 3가지 표준 패턴과 마케팅 자동화에 적용하는 자리를 정리합니다.
마케터가 이 글을 읽어야 하는 이유: LLM 자동화가 한 단계 작업(요약·분류)을 넘어 여러 단계 작업(분석 + 보고 + 전송)으로 가면 단일 모델로는 안정적이지 않습니다. orchestration 패턴을 알면 자동화 설계의 전체 그림이 잡히고, 어느 자리에 어느 패턴이 맞는지가 분명해집니다.
중앙 통제냐 자율 협력이냐, 계획-실행 분리냐 — 자리에 따라 답이 다르다.
1. 단일 에이전트의 한계
단일 LLM에 복잡한 작업을 맡기면 다음 자리에서 깨집니다.
| 문제 | 증상 |
|---|---|
| 컨텍스트 누적 | 단계가 길어질수록 토큰 제곱 비용 증가 |
| 역할 혼동 | 분석 중인지 보고 작성 중인지 흐려짐 |
| 도구 선택 헷갈림 | 같은 도구를 반복 호출하거나 잘못된 도구 호출 |
| 한 단계 실패가 전체 멈춤 | 중간에 한 도구가 실패하면 복구 어려움 |
multi-agent는 이 문제를 "역할 분할"로 풉니다. 데이터 조회 에이전트, 분석 에이전트, 작성 에이전트가 각자 역할만 책임지고 다른 에이전트가 결과를 받아 다음 단계.
📌 이 글의 전제
function calling·tool use에 대한 기초 이해가 있다고 가정합니다(Function calling 글 참고). 코드를 직접 짠 적 없어도 OK입니다.
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 같은 도구 활용.
⚠️ multi-agent 도입 전에 한 번 더 점검
단일 에이전트로 충분한 자리에 multi-agent를 도입하면 비용·복잡도만 증가. 작업이 정말 여러 단계로 나뉘는지, 단일 모델이 헷갈리는 자리인지 확인 후 도입.
8. 마케팅 자동화의 적용 자리 4가지
8-1. 일일 캠페인 보고 자동화
조회(BigQuery) → 분석(이상치 탐지) → 작성(자유 산문) → 전송(Slack). Planner-Executor 패턴이 자연스럽게 맞음.
8-2. 사용자 의도 라우팅 챗봇
분류(FAQ vs 데이터 조회 vs 액션) → 적합한 워커로 라우팅. Supervisor 패턴.
8-3. 콘텐츠 작성 + 검수
작성 에이전트 → 검수 에이전트 → 수정 에이전트의 파이프라인. Planner가 큰 흐름 잡고 Executor들이 실행.
8-4. 실시간 알림 분석
이상치 감지 → 원인 분석 → 알림 전송. Supervisor가 단계 결정.
{/* TODO_HUNY: huny가 운영 중인 LLM 자동화 중 multi-agent로 만든 자리가 있다면 어떤 패턴을 썼고 왜 그 패턴을 골랐는지 한 단락 추가해주세요. */}
9. 마치며 — 자동화 설계의 한 단계 위
LLM 자동화가 단순 작업을 넘어 운영의 표준 도구로 자리 잡을수록 multi-agent orchestration이 자연스럽게 들어옵니다. supervisor·swarm·planner-executor 3가지 패턴 중 자리에 맞는 한 가지를 골라 도입하면 단일 에이전트의 한계를 넘어설 수 있습니다. 다만 비용·디버깅·loop 방지 같은 운영 안정성 항목을 미리 챙겨야 합니다.
다음 분기에 한 번만 시도해 볼 만한 것은 가장 자주 돌리는 단일 에이전트 자동화 한 자리에 supervisor 패턴을 도입해 단계별 디버깅이 쉬워지는지 비교하는 흐름입니다. 작은 자리부터 도입해 운영 감각을 쌓는 게 표준 경로입니다.
{/* TODO_HUNY: 사내 자동화에서 가장 단계가 많은 작업과 그 작업이 단일 에이전트로 충분한지 한 단락 추가해주세요. */}
다음에 읽을 글
- 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
Top comments (0)