단일 에이전트 vs 멀티 에이전트 — 언제 뭘 쓰나

문제 정의: 에이전트가 많으면 좋은 건가?

"멀티 에이전트"가 2025년 AI 업계의 최대 화두였다. 72%의 엔터프라이즈 AI 프로젝트가 멀티 에이전트 아키텍처를 채택하고 있다(2024년 23% 대비 급증). 하지만 실제로 멀티 에이전트가 필요한 경우는 생각보다 적다.

에이전트 설계에서 가장 중요한 질문은 **"이 업무에 어떤 패턴이 적합한가?"**이다. 단순한 업무에 멀티 에이전트를 적용하면 오버엔지니어링이고, 복잡한 업무에 단일 에이전트만 고집하면 관리 불가능한 스파게티 프롬프트가 된다.

4가지 설계 패턴

패턴 1: 단일 에이전트 + 도구 호출 (Function Calling)

┌─────────────────────────────────┐
│         단일 에이전트             │
│  ┌───────────────────────────┐  │
│  │      LLM (GPT-4o)        │  │
│  │   System Prompt + Tools   │  │
│  └─────────┬─────────────────┘  │
│            │                    │
│  ┌─────────▼─────────────────┐  │
│  │   도구 1   도구 2   도구 3  │  │
│  │  (DB조회) (이메일) (슬랙)  │  │
│  └───────────────────────────┘  │
└─────────────────────────────────┘

• 구조: LLM 하나가 모든 판단을 하고, 필요한 도구를 직접 호출
• 적합한 업무: 명확한 입력 → 명확한 출력 (FAQ 응답, 데이터 조회, 단순 작업)
• 구현 복잡도: 낮음
• 장점: 단순함, 디버깅 용이, 지연시간 최소
• 단점: 도구가 10개 넘으면 정확도 저하, 복잡한 판단 로직 한계

from openai import OpenAI
 
client = OpenAI()
 
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "이메일을 분석하고 적절한 조치를 취하세요."},
        {"role": "user", "content": email_content}
    ],
    tools=[search_tool, reply_tool, forward_tool, label_tool],
    tool_choice="auto"
)

패턴 2: 체인 (Sequential Agent Chain)

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ 에이전트1 │───▶│ 에이전트2 │───▶│ 에이전트3 │───▶│ 에이전트4 │
│ 분류     │    │ 요약     │    │ 번역     │    │ 포맷팅   │
│          │    │          │    │          │    │          │
│ 이메일   │    │ 핵심내용 │    │ 한→영    │    │ JSON    │
│ 카테고리 │    │ 3문장   │    │ 변환     │    │ 변환    │
└──────────┘    └──────────┘    └──────────┘    └──────────┘
     입력 ─────────────────────────────────────────▶ 출력

• 구조: 여러 에이전트가 순차적으로 실행, 이전 출력이 다음 입력
• 적합한 업무: 단계별 처리 (문서 파이프라인, ETL, 콘텐츠 생성)
• 구현 복잡도: 낮음~중간
• 장점: 각 단계의 역할이 명확, 중간 결과 검증 가능
• 단점: 한 단계 실패 시 전체 중단, 단계 수에 비례해 지연 증가

패턴 3: 라우터 (Router Agent)

                    ┌──────────┐
                    │  라우터   │
                    │ 에이전트  │
                    └────┬─────┘
                         │
           ┌─────────────┼─────────────┐
           │             │             │
           ▼             ▼             ▼
    ┌──────────┐  ┌──────────┐  ┌──────────┐
    │ 전문가 A │  │ 전문가 B │  │ 전문가 C │
    │ (고객CS) │  │ (기술지원)│  │ (영업)   │
    └──────────┘  └──────────┘  └──────────┘

• 구조: 라우터가 요청을 분석하고, 적합한 전문 에이전트로 분배
• 적합한 업무: 다양한 유형의 요청을 처리 (고객센터, 내부 헬프데스크)
• 구현 복잡도: 중간
• 장점: 각 전문가의 프롬프트가 짧고 명확, 확장 용이
• 단점: 라우터 정확도에 전체 성능 의존, 오분류 시 잘못된 응답

# 라우터 패턴 구현 예시
ROUTER_PROMPT = """
사용자 요청을 분석하고 적합한 전문가를 선택하세요.
 
전문가 목록:
- customer_support: 주문, 배송, 환불 관련
- tech_support: 기술 문제, 버그 리포트
- sales: 견적, 제품 문의, 계약
 
JSON으로 응답: {"expert": "전문가_id", "reason": "선택 이유"}
"""
 
async def route_request(user_message: str) -> str:
    # 1단계: 라우터가 전문가 선택
    routing = await call_llm(ROUTER_PROMPT, user_message)
    expert_id = json.loads(routing)["expert"]
 
    # 2단계: 선택된 전문가가 처리
    expert_prompt = EXPERT_PROMPTS[expert_id]
    return await call_llm(expert_prompt, user_message)

패턴 4: 멀티 에이전트 오케스트레이션

┌────────────────────────────────────────────┐
│              오케스트레이터                   │
│  (작업 분해 → 할당 → 수집 → 종합)           │
└────────┬──────────┬──────────┬─────────────┘
         │          │          │
         ▼          ▼          ▼
  ┌──────────┐ ┌──────────┐ ┌──────────┐
  │ 리서처   │ │ 분석가   │ │ 작성자   │
  │          │ │          │ │          │
  │ - 웹검색 │ │ - 데이터 │ │ - 보고서 │
  │ - 문서   │ │ - 비교   │ │ - 요약   │
  │   수집   │ │ - 평가   │ │ - 시각화 │
  └──────────┘ └──────────┘ └──────────┘
       │            │            │
       └────────────┼────────────┘
                    ▼
            ┌──────────────┐
            │  최종 결과물  │
            │  (보고서)    │
            └──────────────┘

• 구조: 오케스트레이터가 작업을 분해하고, 전문 에이전트에게 할당, 결과를 종합
• 적합한 업무: 복잡한 다단계 작업 (리서치 보고서, 코드 리뷰, 복합 분석)
• 구현 복잡도: 높음
• 장점: 병렬 처리 가능, 복잡한 워크플로우 표현력
• 단점: 디버깅 어려움, LLM 호출 비용 증가, 에이전트 간 통신 오버헤드

선택 기준: 업무 복잡도 x 자율성 매트릭스

자율성 (높음)
    │
    │  ┌─────────────┐  ┌─────────────────┐
    │  │ 패턴 3      │  │ 패턴 4          │
    │  │ 라우터      │  │ 멀티 에이전트    │
    │  │             │  │ 오케스트레이션   │
    │  │ 고객센터    │  │ 리서치 자동화   │
    │  │ 헬프데스크  │  │ 복합 보고서     │
    │  └─────────────┘  └─────────────────┘
    │
    │  ┌─────────────┐  ┌─────────────────┐
    │  │ 패턴 1      │  │ 패턴 2          │
    │  │ 단일+도구   │  │ 체인            │
    │  │             │  │                 │
    │  │ FAQ 응답    │  │ 문서 처리       │
    │  │ 데이터 조회 │  │ 콘텐츠 생성     │
    │  └─────────────┘  └─────────────────┘
    │
    └──────────────────────────────────────▶ 업무 복잡도 (높음)

판단 기준 3가지:

1. 도구가 5개 이하이고 분기 로직이 단순 → 패턴 1 (단일 에이전트)
2. 처리 순서가 고정되어 있고 단계별 검증 필요 → 패턴 2 (체인)
3. 입력 유형이 다양하고 각각 다른 전문성 필요 → 패턴 3 (라우터)
4. 작업 분해, 병렬 처리, 결과 종합이 모두 필요 → 패턴 4 (오케스트레이션)

실전 예시: 이메일 자동화를 4가지 패턴으로

"수신 이메일을 분류하고, 중요한 것은 요약하고, 필요하면 자동 회신"하는 업무를 각 패턴으로 구현한다면?

대부분의 이메일 자동화는 패턴 1 또는 패턴 3으로 충분하다. 패턴 4는 비용 대비 효과가 떨어지는 경우가 많다.

프레임워크 비교: LangGraph vs CrewAI vs AutoGen

# LangGraph로 라우터 패턴 구현 (패턴 3)
from langgraph.graph import StateGraph, END
from typing import TypedDict
 
class EmailState(TypedDict):
    email: str
    category: str
    response: str
 
def classify_email(state: EmailState) -> EmailState:
    """이메일 분류 노드"""
    category = call_llm("이메일을 분류하세요: urgent/normal/spam", state["email"])
    return {"category": category}
 
def handle_urgent(state: EmailState) -> EmailState:
    """긴급 이메일 처리 노드"""
    response = call_llm("긴급 이메일에 대한 즉시 회신을 작성하세요", state["email"])
    return {"response": response}
 
def handle_normal(state: EmailState) -> EmailState:
    """일반 이메일 처리 노드"""
    response = call_llm("일반 이메일을 요약하고 회신 초안을 작성하세요", state["email"])
    return {"response": response}
 
def route_email(state: EmailState) -> str:
    """조건부 라우팅"""
    if state["category"] == "urgent":
        return "handle_urgent"
    elif state["category"] == "spam":
        return END
    return "handle_normal"
 
# 그래프 구성
graph = StateGraph(EmailState)
graph.add_node("classify", classify_email)
graph.add_node("handle_urgent", handle_urgent)
graph.add_node("handle_normal", handle_normal)
 
graph.set_entry_point("classify")
graph.add_conditional_edges("classify", route_email)
graph.add_edge("handle_urgent", END)
graph.add_edge("handle_normal", END)
 
app = graph.compile()
result = app.invoke({"email": "서버 장애 발생 — 즉시 확인 요청"})

권장 선택 기준:

• **"제대로 된 프로덕션"**이 목표 → LangGraph
• **"빠른 프로토타입"**이 목표 → CrewAI
• MS 생태계(Azure, Teams)와 통합 → AutoGen (2026 Q1 Semantic Kernel 통합 예정)

결론

에이전트 설계의 핵심은 "가장 단순한 패턴으로 시작하는 것"이다. 패턴 1(단일 에이전트)로 시작해서, 실제로 한계에 부딪힐 때 패턴 2나 3으로 진화시키면 된다. 멀티 에이전트(패턴 4)는 진짜 필요할 때만 도입하라. 72%의 프로젝트가 멀티 에이전트를 채택했다고 하지만, 그 중 상당수는 패턴 1이나 3으로 충분한 경우다.

우리 업무에 맞는 에이전트 아키텍처가 궁금하다면 → 기술 상담 신청