CH07-혼자보다 팀 — 멀티 에이전트 협업(Multi-Agent Collaboration) 완벽 정리

AGENTIC AI DESIGN PATTERNS · 07

혼자보다 팀 — 멀티 에이전트 협업(Multi-Agent Collaboration) 완벽 정리

한 명의 천재 LLM을 넘어 전문가 팀으로 — 6가지 협업 형태와 6가지 통신 구조, Supervisor·Swarm·Hierarchical, LangGraph·CrewAI·Google ADK 3프레임워크, CRM·ERP·Groupware 적용까지

🟢 입문~중급⏱️ 약 22분🤝 LangGraph·CrewAI·ADK🏢 엔터프라이즈

TL;DR — 멀티 에이전트 협업은 복잡한 작업을 여러 전문화된 AI 에이전트가 나눠 맡아 협력하는 패턴입니다. 한 마디로 “AI 시스템에 회사 조직도를 그려 주는 것”이죠. 단일 에이전트의 4대 한계(컨텍스트 과부하·전문성 부족·확장성 제한·검증 불가)를 분업과 협업으로 넘어섭니다. 두 축으로 설계합니다 — 협업 형태 6가지(순차·병렬·토론·계층·전문가팀·비평검토)와 통신 구조 6가지(단일·네트워크·Supervisor·Supervisor-as-Tool·계층·커스텀). 핵심 설계 패턴은 Supervisor(중앙 조율)·Swarm/Handoff(자율 전달)·Hierarchical(다층 위임)입니다. LangGraph(Command·핸드오프 도구)·CrewAI(Process.hierarchical)·Google ADK(output_key)로 구현하고, CRM·ERP·Groupware에 단계적으로 적용합니다. 단, 비용·무한 루프·SPOF를 막을 안전장치(HITL·롤백·Critic)가 처음부터 필요합니다.

목 차

1. 왜 멀티 에이전트인가2. 한계와 정의3. 협업 형태·통신 구조4. 핵심 설계 패턴5. LangGraph6. CrewAI7. Google ADK8. 프레임워크 비교9. 토폴로지 선택10. 엔터프라이즈11. 케이스 & 안전장치12. 베스트 프랙티스

1. 왜 멀티 에이전트인가 — 한 명의 천재 vs 한 팀의 전문가

앞선 여섯 편을 빠르게 되짚어 봅시다. 1편 프롬프트 체이닝은 작업을 순서대로 쪼갰고, 2편 라우팅은 길을 나눴으며, 3편 병렬화는 독립 작업을 동시에 던졌고, 4편 리플렉션은 쓴 결과를 읽고 고쳤습니다. 5편 도구 사용은 손과 발을 달았고, 6편 플래닝은 목표를 단계로 쪼개는 청사진을 그렸죠. 그런데 그 모든 일을 여전히 ‘한 에이전트’가 혼자 했습니다. 여기서 결정적인 질문이 남습니다 — “계획을 세웠다면, 그 계획의 각 단계는 누가 실행하지?”

한 사람에게 조사도, 분석도, 글쓰기도, 검수도 전부 시키면 어떻게 될까요? 평범한 결과가 나옵니다. “Jack of all trades, master of none” — 두루 하지만 어느 것도 통달하지 못하죠. 멀티 에이전트 협업은 이 문제를 회사가 푸는 방식 그대로 풉니다. 조사는 리서처에게, 분석은 애널리스트에게, 글은 라이터에게, 검수는 리뷰어에게. 본질은 ‘분업과 협업(Division of Labor & Collaboration)’을 AI에 적용하는 것 — 다시 말해 AI 시스템에 조직도를 그려 주는 일입니다.

🧍 단일 에이전트 — 4대 한계

🧠 컨텍스트 과부하 — 너무 많은 역할 = 품질 저하

🎯 전문성 부족 — 모든 도메인에 능숙할 수 없음

📈 확장성 제한 — 복잡한 워크플로우에 취약

🔍 검증 불가 — 자기 검증의 한계(동료 검토 ✗)

🤝 멀티 에이전트 — 4대 장점

🧩 전문성 — 역할 분담으로 품질 향상

🔧 모듈성 — 독립 개발·테스트·유지보수

🛡️ 강건성 — 한 에이전트 실패 ≠ 전체 실패

✨ 시너지 — 합 이상의 결과(집단 지성)

그림 1. 한 명에게 다 시키는 단일 에이전트의 한계와, 전문가 팀으로 넘어서는 멀티 에이전트의 장점

💡

지금 기업들이 주목하는 이유. 사내 업무의 대부분은 여러 전문 영역을 거치는 협업입니다 — 제안서 하나도 시장조사·재무분석·디자인·법무검토를 거치죠. 단일 AI로 이걸 흉내 내면 어느 단계도 깊지 못합니다. 멀티 에이전트는 각 단계에 진짜 전문가를 배치하고, 서로의 결과를 검토하게 만들어 사람 조직의 강점을 그대로 가져옵니다. 6편 플래닝이 “청사진”이었다면, 7편은 그 청사진을 함께 짓는 팀입니다.

2. 한계와 정의 — 언제 팀을 꾸리는가

정의부터 못 박겠습니다. 멀티 에이전트 협업은 “복잡한 문제를 여러 전문화된 에이전트가 협력해 해결하는 설계 패턴”입니다. 핵심 3요소는 전문화된 역할(Specialization), 분산된 작업(Distributed Tasks), 에이전트 간 통신(Communication)입니다. 이 셋이 갖춰져야 단순한 “여러 번 호출”이 아니라 협업이 됩니다.

그렇다고 모든 일에 팀이 필요한 건 아닙니다 — 오히려 대부분의 작업엔 과합니다. 판단 기준(Rule of Thumb)은 이렇습니다. “단일 에이전트로 처리하기엔 복잡하고, 전문 기술·도구가 필요한 하위 작업으로 분해할 수 있는가?” “예”라면 팀, “아니오”라면 혼자가 낫습니다.

단일 에이전트의 한계	멀티 에이전트가 주는 답	메커니즘
컨텍스트 과부하	전문성	역할별로 컨텍스트를 좁게
전문성 부족	시너지	서로 다른 관점의 결합
확장성 제한	모듈성	에이전트 추가/제거로 확장
검증 불가	강건성	동료 검토(Critic)로 상호 검증

⚠️

팀이 손해인 경우. 단순 질의응답·단일 문서 요약·간단한 데이터 변환처럼 한 번에 끝나는 일, 실시간 응답이 필수(레이턴시 민감)이거나 저비용 운영이 필수(다중 LLM 호출 비용)인 경우엔 단일 에이전트가 더 빠르고 싸고 안전합니다. 팀은 “복잡함”에만 값을 합니다.

3. 협업 형태와 통신 구조 — 6 × 6 지도

멀티 에이전트를 설계할 땐 두 개의 다른 축을 구분해야 헷갈리지 않습니다. 협업 형태(무엇을 하나)와 통신 구조(어떻게 연결되나)입니다. “순차로 일한다”는 형태이고, “Supervisor가 조율한다”는 구조죠. 둘을 조합해 시스템을 짓습니다.

① 협업 형태 6종 — 무엇을 하나

➡️ Sequential Handoffs

조사 → 분석 → 작성 → 검토 순차 전달
콘텐츠 파이프라인 · 문서 승인

🔀 Parallel Processing

독립 분석을 동시에 → 통합자가 합침
다각적 시장분석 · 다중 소스

💬 Debate & Consensus

관점이 다른 에이전트가 토론 → 합의
정책 검토 · 의사결정 · 코드리뷰

🪜 Hierarchical

매니저가 위임 → 결과 통합
대규모 프로젝트 · 엔터프라이즈

👥 Expert Teams

도메인 전문가 병렬 → Synthesizer 수렴
제품 개발 · 컨설팅

🔁 Critic-Reviewer

Generator → Reviewer → Refiner 반복
환각 감소 · 컴플라이언스

② 통신 구조 6종 — 어떻게 연결되나

🔘

Single

[A] + 도구

🕸️

Network

P2P 완전연결

⭐

Supervisor

중앙 1:N 조율

🛠️

Supervisor-as-Tool

필요시 호출

🌳

Hierarchical

다층 트리

🧭

Custom

Hub-Spoke·Ring

그림 2~3. ‘무엇을 하나(협업 형태)’와 ‘어떻게 연결되나(통신 구조)’는 다른 축 — 둘을 조합해 시스템을 짓는다

예를 들어 “Critic-Reviewer 형태”를 “Supervisor 구조”로 구현할 수도, “Network 구조”로 구현할 수도 있습니다. 형태가 일이라면 구조는 조직표죠. 이번 편에서 깊게 볼 것은 가장 실무적인 세 가지 구조 — Supervisor·Swarm/Handoff·Hierarchical입니다.

4. 핵심 설계 패턴 — Supervisor · Swarm · Hierarchical

실무에서 쓰이는 핵심 설계 패턴은 다섯입니다 — Manager/Supervisor, Swarm/Handoff, Pipeline, Parallel Fan-out/Fan-in, AgentTool. 이 중 통신 구조를 좌우하는 Manager/Supervisor와 Swarm/Handoff, 그리고 이를 여러 층으로 펼친 Hierarchical까지 세 가지를 깊이 봅시다.

⭐ Supervisor (중앙 조율)

한 명의 Supervisor가 작업을 분배하고 결과를 모읍니다. Worker는 Supervisor에게만 보고하죠. 권한이 명확하고 디버깅이 쉽습니다.

✓ 명확한 권한 · 일관된 조율 · ✗ 병목(SPOF)

🤝 Swarm / Handoff (자율 전달)

중앙 관리자 없이 에이전트가 서로에게 직접 제어권을 넘깁니다. 마치 릴레이 경주의 바통 터치 같죠. 유연하지만 추적이 어렵습니다.

✓ 유연한 라우팅 · 분산 · ✗ 디버깅·무한루프

🪜 Hierarchical (다층 위임)

Executive → Manager → Worker로 여러 층의 위임이 일어납니다. 대규모 팀을 책임 단위로 쪼개 관리하죠.

✓ 대규모 관리 · 책임 분산 · ✗ 레이턴시·통신비용

🎯

Supervisor의 본질 = 권한 비대칭. 잘 만든 Supervisor 시스템은 Supervisor에겐 ‘위임 도구’만, Worker에겐 ‘복귀 도구’만 줍니다. 즉 Supervisor는 일을 넘길 수만 있고 직접 못 하며, Worker는 끝나면 Supervisor에게 돌아갈 수만 있죠. 프롬프트로 “직접 일하지 마”라고 부탁하는 게 아니라, 도구 권한으로 허브-스포크 구조를 코드에 못 박는 것 — 이것이 다음 장 LangGraph 구현의 핵심입니다.

5. 구현 ① LangGraph — Supervisor와 Command 객체

LangGraph는 협업을 상태 그래프(StateGraph)로 표현합니다. 각 에이전트가 노드가 되고, 한 노드에서 다른 노드로 제어가 넘어가는 게 핸드오프죠. 그 핸드오프를 도구(tool)로 만든다는 게 LangGraph 방식의 특징입니다. 먼저 핸드오프 도구 팩토리를 봅시다.

PYTHON · create_handoff_tool + Command + Supervisor

from langgraph.graph import StateGraph, START, MessagesState from langgraph.prebuilt import create_react_agent, InjectedState from langgraph.types import Command from langchain_core.tools import tool, InjectedToolCallId from typing import Annotated def create_handoff_tool(agent_name, description): # 핸드오프 도구 팩토리 @tool(f"transfer_to_{agent_name}", description=description) def handoff_tool( state: Annotated[dict, InjectedState], # 상태 자동 주입(LLM 비노출) tool_call_id: Annotated[str, InjectedToolCallId], ) -> Command: msg = {"role": "tool", "content": f"Transferred to {agent_name}", "tool_call_id": tool_call_id} return Command( goto=agent_name, # 다음 실행 노드(Worker) update={"messages": state["messages"] + [msg]}, # ToolMessage 누적 graph=Command.PARENT) # 부모 그래프로 제어 복귀 return handoff_tool supervisor = create_react_agent( # Supervisor — 위임 도구만 보유 model="openai:gpt-4o", tools=[create_handoff_tool("researcher", "연구 작업 할당"), create_handoff_tool("analyst", "데이터 분석 할당"), create_handoff_tool("writer", "문서 작성 할당")], prompt="당신은 팀을 조율하는 Supervisor입니다. 직접 일하지 말고 위임하세요.")

마법은 Command 한 객체에 있습니다. “어디로 갈지(goto)”와 “상태를 어떻게 바꿀지(update)”를 한 번에 반환하죠. graph=Command.PARENT는 “자식 그래프에서 처리하지 말고 부모 그래프로 제어를 돌려보내라”는 뜻 — 그래야 Supervisor가 다음 Worker로 다시 라우팅할 수 있습니다. 이제 Worker와 그래프 조립을 봅시다.

PYTHON · Worker(복귀 도구만) + StateGraph 조립

researcher = create_react_agent( # Worker — 복귀 도구 1개만 model="openai:gpt-4o", tools=[create_handoff_tool("supervisor", "작업 완료 보고")], prompt="당신은 연구 전문가입니다. 끝나면 Supervisor에게 보고하세요.") graph = ( # StateGraph 조립 — (이름, 노드) StateGraph(MessagesState) .add_node("supervisor", supervisor) # goto 문자열과 노드명 일치 .add_node("researcher", researcher) .add_node("analyst", analyst).add_node("writer", writer) .add_edge(START, "supervisor") # 진입점은 Supervisor .compile()) # 라우팅은 Command가 동적으로

권한 비대칭이 보이시나요? Supervisor는 위임 도구 3개, 각 Worker는 복귀 도구 1개. 모든 길이 Supervisor를 통하는 허브-스포크가 코드 레벨에서 강제됩니다. 모든 노드가 MessagesState를 공유해 대화 이력이 누적되고요.

⭐ Supervisor (위임 도구 3개)

🔬
Researcher

📊
Analyst

✍️
Writer

↓ transfer_to_*　　↑ transfer_to_supervisor

Worker는 복귀 도구 1개만 — 허브-스포크 강제

Command 객체 분해

goto → 어디로(노드)

update → 상태 변경

graph=PARENT → 부모 복귀

그림 4. Supervisor 허브-스포크 제어 흐름과, 라우팅+상태변경을 한 객체에 담는 Command

📝

학습용 코드 안내. 본문 코드는 실제 langgraph.prebuilt.create_handoff_tool·create_react_agent API에 맞춘 형태입니다. 학습 저장소의 예제는 동일 인터페이스를 가진 시뮬레이션 클래스로 개념을 보여 주며, 라우팅 판정도 시연용으로 단순화되어 있습니다. 프로덕션에선 종료 조건과 max_iterations 상한을 반드시 함께 거세요.

6. 구현 ② CrewAI — 역할 기반 계층 Crew

CrewAI는 발상이 다릅니다. 그래프를 그리는 대신 “전문가 팀을 꾸린다”는 메타포로 접근하죠. Agent를 역할(role)·목표(goal)·배경(backstory)으로 정의하면, backstory가 LLM에게 역할극을 부여합니다. 레거시 ERP를 클라우드로 옮기는 마이그레이션 프로젝트를 팀으로 짜 봅시다.

PYTHON · Agent(role/goal/backstory) + Task(context) + Crew(hierarchical)

from crewai import Agent, Task, Crew, Process manager = Agent( # 매니저 — 위임 권한 O role="ERP 프로젝트 매니저", goal="마이그레이션 성공·리스크 관리", backstory="PMP 자격의 15년 경력 PM...", # 페르소나(구체적일수록 ↑) allow_delegation=True) architect = Agent(role="테크니컬 아키텍트", goal="마이그레이션 아키텍처 설계", backstory="클라우드 네이티브·MSA 전문가...", allow_delegation=False) arch_task = Task(description="As-Is/To-Be 아키텍처를 설계하세요...", expected_output="기술 아키텍처 문서", agent=architect) data_task = Task(description="ETL·데이터 매핑 계획을 수립하세요...", expected_output="데이터 마이그레이션 계획서", agent=data_engineer, context=[arch_task]) # ← 아키텍처 결과를 입력으로 주입 crew = Crew(agents=[architect, data_engineer, qa_lead], # 워커만 등록 tasks=[arch_task, data_task, qa_task], process=Process.hierarchical, # 계층적 — 매니저가 조율 manager_agent=manager) # 커스텀 매니저(자동 생성 땐 manager_llm="gpt-4o") result = crew.kickoff()

세 가지가 핵심입니다. 첫째, context=[arch_task] — 이전 Task의 결과를 다음 Task로 명시적으로 흘려보내 의존성 체인을 코드로 박습니다(아키텍처 → 데이터 → QA). 둘째, allow_delegation — 매니저만 True, 워커는 False로 둬야 위계가 코드로 강제됩니다. 셋째, Process.hierarchical — 켜는 순간 매니저가 Task 분석 → 할당 → 검증 → 통합을 조율합니다.

➡️ Process.sequential

Task 1 → Task 2 → Task 3 → 완료
정해진 순서대로, 마지막 결과만 반환

✓ 예측 가능 · 오버헤드 적음 · 단순 파이프라인

🪜 Process.hierarchical

Manager LLM이 위임·검증·통합
의존성 분석 → 할당 → 결과 종합

✓ 복잡한 프로젝트 · 동적 조율 · 팀 협업

그림 5. 순서대로 가는 Sequential vs 매니저가 지휘·통합하는 Hierarchical — 두 모드의 본질은 ‘통합 방식’의 차이

학습 곡선이 가장 낮고 역할 기반 분업이 네이티브라, “사람 팀이 일하듯” 협업을 빠르게 시뮬레이션할 때 제격입니다. 다만 함정도 있습니다 — hierarchical에서 매니저는 agents가 아니라 manager_agent로 넘겨야 하며(자동 생성을 원하면 manager_llm만 지정), 둘 중 하나는 줘야 조율 주체가 생깁니다. context를 누락하면 다음 Task가 이전 결과를 못 봅니다. 그리고 병렬·반복 워크플로우 지원은 제한적이라, 그 영역은 다음 ADK가 강합니다.

7. 구현 ③ Google ADK — 4대 오케스트레이터 + output_key

Google ADK는 워크플로우 에이전트를 조립식 블록으로 제공합니다. 개별 LlmAgent를 만든 뒤 SequentialAgent·ParallelAgent·LoopAgent로 감싸죠. 상태 전달의 핵심은 output_key 단 하나입니다.

PYTHON · output_key 자동 상태 공유 + SequentialAgent

from google.adk.agents import LlmAgent, SequentialAgent, ParallelAgent, LoopAgent from google.adk.tools import AgentTool researcher = LlmAgent(name="Researcher", instruction="시장을 조사하세요: {user_input}", output_key="research_result") # 결과 → state["research_result"] analyst = LlmAgent(name="Analyst", instruction="조사 결과 {research_result}를 분석하세요", # 자동 치환! output_key="analysis_result") pipeline = SequentialAgent( # 순차 — output_key로 자동 연결 name="ReportPipeline", sub_agents=[researcher, analyst, writer])

진짜 일은 output_key가 합니다. 에이전트 결과가 세션 상태에 자동 저장되고, 다음 에이전트의 instruction에서 {변수}로 쓰면 알아서 치환됩니다 — 상태를 손으로 넘기는 코드가 사라지죠. 나머지 세 블록도 직관적입니다.

PYTHON · Parallel · Loop · AgentTool

parallel = ParallelAgent( # 병렬 — 실제 ADK는 asyncio.gather name="ParallelAnalysis", sub_agents=[technical, business, risk]) loop = LoopAgent( # 반복 — 조건 충족 또는 상한까지 name="ImprovementLoop", sub_agents=[generator, reviewer], max_iterations=5) expert_tool = AgentTool(agent=domain_expert, # Agent를 '도구'로 래핑 description="도메인 전문 질문이 필요할 때 호출") main_agent = LlmAgent(name="MainAgent", # 필요시 전문가 호출 instruction="요청을 처리하세요: {user_input}", tools=[expert_tool])

🧩

핵심 멘탈 모델 — sub_agents는 직원, AgentTool은 외부 컨설턴트. sub_agents는 조직도에 늘 있는 직원(항상 함께 실행되는 영구 계층)이고, AgentTool은 필요할 때만 부르는 외부 컨설턴트(LLM이 판단해 호출하는 도구)입니다. 세 블록은 서로 중첩됩니다 — Sequential 안에 Parallel을, 그 안에 Loop를 — 복잡한 오케스트레이션을 레고처럼 쌓죠. 단, 학습 예제의 ParallelAgent는 시뮬레이션 특성상 순차로 도는 등 단순화가 있으니, 실제 동작은 google.adk 라이브러리로 확인하세요.

8. 세 프레임워크 — 같은 협업, 다른 철학

셋 다 “전문 에이전트가 협력한다”는 본질은 같습니다. 다른 건 무엇을 일급 시민으로 보느냐입니다 — LangGraph는 그래프(상태·흐름), CrewAI는 역할(팀), ADK는 워크플로우 블록이 주인공입니다.

LangGraph

Command + 핸드오프 도구

주인공: 그래프·상태
협업: 노드 + Command
제어수준: 가장 높음
복잡 워크플로우 · 프로덕션

CrewAI

Crew + hierarchical

주인공: 역할 Agent
협업: role + delegation
학습: 가장 쉬움
팀 시뮬레이션 · 승인 프로세스

Google ADK

Sequential/Parallel/Loop

주인공: 워크플로우 블록
상태: output_key 자동
강점: 병렬·반복
Gemini 네이티브 · 표준화

그림 6. 같은 협업, 세 가지 철학 — 그래프 중심 / 역할 중심 / 블록 중심

실행 패턴	LangGraph	CrewAI	Google ADK
순차 실행	조건부 엣지	Process.sequential	SequentialAgent
병렬 실행	Fan-out/Fan-in	지원 제한	ParallelAgent
반복 실행	사이클 그래프	수동 구현	LoopAgent
계층 구조	서브그래프	Process.hierarchical	sub_agents
Agent-as-Tool	핸드오프 도구	allow_delegation	AgentTool
상태 관리	MessagesState+Command	Task.context	output_key+{key}
학습 곡선	중간	낮음	낮음
추천 환경	복잡한 워크플로우	팀 협업 시뮬레이션	병렬·반복 표준화

고르는 법은 간단합니다. 세밀한 제어·실시간 핸드오프·커스텀 통합이면 LangGraph, 역할 기반 팀·계층적 승인 프로세스면 CrewAI, 병렬·반복을 표준 블록으로 쌓고 Gemini를 쓰면 Google ADK. 제어 수준은 LangGraph > ADK > CrewAI 순으로 높고, 학습 곡선은 정확히 그 반대입니다.

9. 토폴로지 선택 — 중앙집중 vs 분산은 트레이드오프다

어떤 통신 구조를 고를지는 그 자체가 트레이드오프입니다. 정답은 없고, 무엇을 포기할지를 고르는 일이죠. 핵심 축은 중앙집중(Supervisor) ↔ 분산(Network/Swarm)입니다.

패턴	장점	대가
Supervisor	명확한 권한 · 디버깅 용이	병목(SPOF) · 유연성 제한
Swarm/Handoff	유연한 라우팅 · 분산	디버깅 난이도 · 무한 루프
Hierarchical	대규모 관리 · 책임 분산	레이턴시 · 통신 오버헤드
Parallel	처리 속도 · 리소스 효율	동기화 · 결과 통합 복잡
Loop/Iterative	품질 점진 개선 · 자기 수정	종료 조건 설계 · 비용 증가

5편의 LangGraph로 돌아가 보면, graph=Command.PARENT가 바로 이 선택의 도구입니다 — 자식 서브그래프에서 처리하다가 부모 그래프로 제어를 되돌려 중첩된 계층을 만들 수 있죠. Network(완전연결)는 복원력이 높지만 에이전트가 많아질수록 통신 오버헤드와 레이턴시가 폭증하고, Custom(Hub-and-Spoke/Ring)은 둘을 섞은 하이브리드입니다.

🧭

선택 가이드. 예측 가능성·감사 추적이 중요하면 Supervisor/Hierarchical(중앙집중), 유연성·창발적 협업이 중요하면 Network/Swarm(분산)을 고르세요. 대부분의 엔터프라이즈는 “책임이 명확해야 한다”는 이유로 Supervisor에서 시작해, 필요한 부분만 분산을 섞는 길을 택합니다.

10. 엔터프라이즈 적용 — CRM · ERP · Groupware

기업 업무 대부분은 여러 시스템과 전문 영역을 거치는 협업입니다 — 정확히 멀티 에이전트가 노리는 지점이죠. 시스템별로 전문 에이전트 팀을 붙이면, 기대효과는 숫자로 그려집니다. (아래는 적용전략 문서의 도입 기대효과(목표치)이며 실측 사례가 아닙니다.)

CRM고객 관계 관리

첫 응답2시간 → 15분

상담 생산성30 → 80건/일

처리 비용$15 → $4 /건

ERP전사 자원 관리

주문 처리4시간 → 30분

승인 사이클3일 → 4시간

데이터 오류5% → 0.5%

Groupware협업 시스템

결재 처리3일 → 4시간

회의록 작성2시간 → 10분

문서 검색15분 → 1분

단계적 도입 로드맵 — 한 번에 하지 않는다

Phase 1 · 파일럿

3~4개월

2-3 Agent 파이프라인
문서 분류→요약→검토

Phase 2 · 확장

6개월

5-7 Agent 부서별
CRM 고객 응대 워크플로우

Phase 3 · 통합

9개월

10+ Agent 크로스시스템
CRM-ERP-GW 연계

Phase 4 · 최적화

12개월~

자가 개선
성능 모니터링→자동 튜닝

18개월

평균 투자 회수(ROI)

-35%

3년 TCO 절감

10개+

자동화 프로세스

그림 7. 시스템별 도입 기대효과와 4단계 로드맵 — 작게 시작해(2-3 Agent) 크로스시스템(10+)으로 키운다

기술적으로는 레거시를 그대로 두고 위에 얹는 계층 구조가 정석입니다. 요청은 인증·권한·감사를 맡는 Security Layer를 지나, Enterprise Orchestrator(요청 파싱→에이전트 할당→SLA 모니터링)가 지휘하고, Domain Agent(CRM/ERP/GW)가 Integration Layer·ESB(Salesforce·SAP·MS365)를 통해 실제 시스템을 두드립니다. 그 모든 행동을 Policy Engine이 통제하죠.

11. 케이스 스터디 — Supervisor CRM과 안전장치

실제 시나리오를 봅시다. 고객이 “구매한 AI 솔루션의 API 연동이 안 됩니다. 긴급히 해결이 필요합니다”라고 문의했습니다. CRM Supervisor(고객 서비스 팀장)가 이 한 줄을 받아 팀을 지휘합니다.

TEXT · 문의 한 줄 → Supervisor 협업 흐름

문의: "구매한 AI 솔루션의 API 연동이 안 됩니다. 긴급히 해결이 필요합니다." Supervisor(CRM 팀장)가 조율 → 1. [inquiry_analyzer] 문의 분류 — 유형:기술 · 긴급도:상 · 감정:불안 2. [product_expert] API 연동 진단 + 단계별 해결책 제시 3. [supervisor] 응대 종합 → 고객 메시지 생성 4. [CRM 기록] 처리 이력 저장 + 후속 체크리스트 # 금액 변경·데이터 수정이 끼면 → Human-in-the-Loop 승인으로 전환

Supervisor가 inquiry_analyzer로 분류시키고, 결과(기술/긴급)를 보고 product_expert에게 배정하죠. 5편에서 본 핸드오프 도구가 정확히 이 흐름을 구현합니다(학습 예제는 분류·전문가 배정까지 구현하고, 기록·HITL 전환은 권장 설계 흐름입니다). 그런데 자율성이 커질수록 고삐가 중요해집니다.

안전장치 ① 어디까지 자동인가 — Policy Engine

엔터프라이즈 멀티 에이전트의 첫 번째 원칙은 “어떤 에이전트도 프로덕션 데이터를 직접 수정하지 않는다”입니다. 권한을 에이전트별로 잘게 쪼개고, 위험한 동작은 승인 게이트를 거치게 합니다.

🟢 자동 실행

정보 조회·분석·분류
응대 초안 생성
저위험·되돌릴 수 있는 작업

🟡 승인 필요(HITL)

금액·계약 변경
고객 데이터 수정/삭제
외부 시스템 쓰기 작업

🔴 정책 차단

PII 접근 시 마스킹 강제
재무 데이터 읽기 전용
프로덕션 직접 수정 불가

안전장치 ② 협업이기에 더 위험한 6가지 함정

① 무한 루프 — Swarm·Loop에서 종료 조건 부재 → max_iterations + 명확한 종료 키워드 필수

② 토큰 폭발 — 전체 맥락을 그대로 넘기면 비용 폭증 → 필요한 정보만 선별 전달

③ 단일 실패점(SPOF) — Supervisor 장애 = 전체 정지 → fallback·헬스체크 설계

④ 통신 오버헤드 — Network에서 에이전트↑ → 레이턴시↑ → 불필요한 통신 최소화

⑤ 할루시네이션 전파 — 한 에이전트 오류가 체인으로 증폭 → Critic-Reviewer 3중 방어

⑥ 암묵적 의존 — 상태 계약 없이 정보 전달 → 명시적 입출력 스키마(output_key/context)

🔒

그 위에 거버넌스. RBAC로 에이전트별 권한을 정의하고, OAuth 2.0·mTLS로 에이전트 간 통신을 암호화하며, 감사 추적(Audit Trail)으로 모든 의사결정 근거를 로깅합니다. GDPR·SOX·ISO 27001 같은 규제 대응도 이 계층에서 자동화하죠. “자율성을 주되, 모든 행동에 책임 추적이 남게”가 엔터프라이즈 멀티 에이전트의 황금률입니다.

12. 베스트 프랙티스 & 트레이드오프

팀을 꾸릴지 말지 — 의사결정

✅ 팀이 빛나는 곳

• 다양한 전문성이 필요한 복잡한 작업
• 독립 작업의 병렬 처리가 유리할 때
• 다단계 워크플로우(조사→분석→작성→검토)
• 상호 검증으로 품질을 높여야 할 때
• 엔터프라이즈 크로스시스템 프로세스

❌ 혼자가 나은 곳

• 단순 질의응답·단일 문서 요약
• 간단한 데이터 변환
• 실시간 응답이 필수(레이턴시 민감)
• 저비용 운영이 필수(다중 LLM 호출)

트레이드오프 — 시너지엔 대가가 따른다

멀티 에이전트는 품질·강건성·확장성을 주는 대신 다중 LLM 호출 비용, 레이턴시 증가, 동기화·결과 통합 복잡성, 분산 디버깅의 어려움을 떠안깁니다. 그래서 “팀을 만들 수 있다”가 아니라 “이 작업에 팀이 정말 필요한가”를 먼저 물어야 합니다. 그리고 에이전트 입자도(granularity) — 너무 잘게 쪼개면 통신 오버헤드가, 너무 뭉치면 단일 에이전트의 한계로 회귀합니다. “각 에이전트에 명확하고 단일한 책임”이 균형점입니다.

다른 패턴과의 조합 — 멀티 에이전트는 ‘종합’이다

멀티 에이전트는 앞선 여섯 패턴을 한 무대에 모으는 종합 패턴입니다. 각 에이전트는 내부에서 체이닝하고, 라우터가 팀을 고르며, 독립 에이전트는 병렬로 돌고, Critic이 검토하죠.

조합	시너지
+ 프롬프트 체이닝(1편)	각 에이전트 내부에서 작업을 단계별로 분해
+ 라우팅(2편)	작업 유형에 따라 전문 Agent 팀으로 라우팅
+ 병렬화(3편)	독립 Agent를 병렬 실행해 성능 향상(Fan-out/in)
+ 리플렉션(4편)	Critic이 다른 Agent 결과를 검토(Critic-Reviewer)
+ 도구 사용(5편)	각 Agent가 외부 API·DB 도구로 작업 수행
+ 플래닝(6편)	계획의 각 단계를 전문 Agent가 분담(Hierarchical)

설계 체크리스트

• ✅ 각 에이전트에 명확하고 단일한 책임 · 입자도(너무 많지도 적지도) 균형
• ✅ 명시적 입출력 계약(스키마) + 상태 전달 메커니즘(output_key·context·Command.update)
• ✅ 무한 루프 차단 — max_iterations + 명확한 종료 조건
• ✅ 에러 처리·폴백·롤백 + 타임아웃·재시도 + 비용·SLA 모니터링
• ✅ 단위 테스트(개별 Agent) + 통합 테스트(협업 흐름) + Human-in-the-Loop

★ 마치며

체이닝(1편)이 “순서대로 쪼개기”, 라우팅(2편)이 “입력에 따라 길 나누기”, 병렬화(3편)가 “독립 작업 동시에”, 리플렉션(4편)이 “쓴 다음 읽고 고치기”, 도구 사용(5편)이 “못 하면 도구를 써라”, 플래닝(6편)이 “목표만 주면 길은 내가 그린다”였다면, 멀티 에이전트 협업은 “혼자 다 하지 말고, 전문가 팀을 꾸려라”입니다. 여기서 우리는 한 명의 천재 LLM에서 한 팀의 전문가로 옮겨 왔습니다. 핵심은 셋 — 형태(무엇을 하나)와 구조(어떻게 연결되나)를 구분해 설계하고, Supervisor의 권한 비대칭처럼 협업 규칙을 코드로 강제하며, 시너지의 대가인 비용·무한 루프·SPOF를 막을 안전장치(HITL·롤백·Critic)를 처음부터 두는 것. 그리고 멀티 에이전트의 진짜 위력은 앞선 모든 패턴을 지휘할 때 나옵니다 — 각 에이전트가 체이닝하고, 도구를 부르고, 병렬로 돌고, 서로를 검토하죠. 다음 8편에서는 이 팀이 대화와 작업을 가로질러 기억을 공유하는 법 — 메모리 관리(Memory Management)를 다룹니다. 한 팀이 함께 일하려면, 함께 기억해야 하니까요.

#멀티에이전트#MultiAgent#Supervisor#Handoff#Hierarchical#LangGraph#CrewAI#GoogleADK#AgenticAI

시리즈: 01 Prompt Chaining → 02 Routing → 03 Parallelization → 04 Reflection → 05 Tool Use → 06 Planning → 07 Multi-Agent → (다음) 08 Memory