멀티 에이전트 아키텍처 패턴: 업계가 정리한 8가지 디자인 패턴

· 10min

멀티 에이전트 아키텍처 패턴

Google ADK의 8가지 멀티 에이전트 디자인 패턴과 다른 벤더의 비슷한 정의 정리

⸻

들어가며

최근 OpenAI 밋업에서 에이전트 아키텍처 발표를 듣다가 눈에 띈 게 있었다. Google, OpenAI, Anthropic, Microsoft가 거의 같은 시기에 비슷한 패턴을 정리하고 있었다.

2025~2026년은 멀티 에이전트 시스템의 “패턴 정립기”라고 볼 수 있다. 벤더마다 따로 만들던 에이전트 아키텍처를 이제 비슷한 이름으로 부른다. Google ADK(Agent Development Kit)가 8가지 패턴을 명시적으로 정의한 뒤로는 이 목록이 사실상 기준처럼 쓰인다.

이 글에서는 그 8가지 패턴을 정리하고 실제 적용 사례를 본다.

⸻

핵심 패턴 8가지

1. Sequential Pipeline (순차 파이프라인)

Agent A → Agent B → Agent C → Result

조립 라인처럼 각 에이전트가 결과를 다음으로 전달하는 가장 단순한 패턴이다. 선형적이고 결정론적이라 디버깅이 쉽다.

사용 사례:

  • PDF 처리: 파서 → 추출기 → 요약기
  • 콘텐츠 파이프라인: 작성 → 편집 → 검수

⸻

2. Coordinator/Dispatcher (조정자-디스패처)

         ┌→ Billing Agent
User → Coordinator
         └→ Tech Support Agent

중앙 에이전트가 의도를 분석한 후 전문 에이전트로 라우팅하는 패턴. Orchestrator-Subagents, Manager Pattern이라고도 부른다.

OpenAI의 정의:

“In a manager/orchestrator pattern, a central manager invokes specialized sub-agents as tools and retains control of the conversation.”

사용 사례:

  • 고객 서비스봇: 청구 문의 vs 기술 지원으로 분기
  • 개발 도구: 코드 작성 vs 테스트 vs 문서화 담당 분리

⸻

3. Parallel Fan-Out/Gather (병렬 방사형)

         ┌→ Security Agent  ─┐
Request → Coordinator        → Aggregator → Result
         ├→ Style Agent     ─┤
         └→ Perf Agent      ─┘

여러 에이전트가 동시에 작업하고 결과를 합치는 패턴. 일을 나눠 동시에 돌리므로 전체 지연 시간이 줄어든다.

Anthropic의 Research 기능이 이 패턴을 쓴다.

“a lead agent coordinates the process while delegating to specialized subagents that operate in parallel.”

Anthropic 내부 리서치 평가에서 Opus 4 리드 에이전트와 Sonnet 4 서브에이전트 조합은 단일 Opus 4 에이전트보다 90.2% 높은 성능을 냈다.

사용 사례:

  • PR 리뷰: 보안/스타일/성능 동시 검사
  • 리서치: 여러 소스 동시 조사

⸻

4. Hierarchical Decomposition (계층적 분해)

High-level Agent
    ├→ Sub-task Agent 1
    │      ├→ Worker 1.1
    │      └→ Worker 1.2
    └→ Sub-task Agent 2

복잡한 목표를 재귀적으로 세부 작업으로 분해하는 패턴. 대규모 리포트 작성이나 복잡한 소프트웨어 프로젝트에 적합하다.

⸻

5. Generator and Critic (생성-검증)

Generator → Output → Critic → Pass? → Done
              ↑                 ↓ No
              └─────────────────┘

한 에이전트가 생성하고, 다른 에이전트가 검증/비평하는 패턴. Plan-Execution-Verification의 핵심 요소이기도 하다.

Google ADK의 설명:

“The generator agent proposes, the critic agent validates. Conditional looping continues until quality criteria are met.”

사용 사례:

  • SQL 쿼리 생성 + 구문 검증
  • 코드 생성 + 테스트 검증

⸻

6. Iterative Refinement (반복적 개선)

Generator → Critic → Refiner → (반복) → Final

Generator-Critic의 확장으로, 품질 기준 충족까지 반복한다. 정확성보다 정성적 개선에 초점을 맞춘다.

사용 사례:

  • 코드 성능 최적화
  • 문서 품질 개선

⸻

7. Peer-to-Peer / Handoff (분산형)

Agent A ←→ Agent B ←→ Agent C

중앙 조율자 없이 에이전트들이 직접 제어권을 전달하는 패턴. 유연하지만 전역 일관성 유지가 어렵다.

OpenAI Agents SDK의 정의:

“Handoffs are a one-way transfer that allow an agent to delegate to another agent. In the Agents SDK, a handoff is a type of tool.”

⸻

8. Human-in-the-Loop (인간 개입)

Agent → High-stakes action? → Human Approval → Execute

중대한 결정 앞에서 사람의 검토를 기다리는 패턴. 준비는 에이전트가 하고, 되돌리기 어려운 실행은 사람이 승인한다.

Google의 설명:

“Agents handle the groundwork, but a human must authorize high-stakes actions.”

사용 사례:

  • 금융 거래 승인
  • 프로덕션 배포
  • 민감한 데이터 접근

⸻

복합 패턴: 실제 시스템은 조합이다

실제 프로덕션 시스템은 대개 여러 패턴을 섞어 쓴다. 예를 들면 이런 구조다.

┌──────────────────────────────────────────────────┐
│  Coordinator (Pattern 2)                          │
│    ├→ Parallel Research (Pattern 3)              │
│    │    ├→ Web Search Agent                      │
│    │    ├→ Code Analysis Agent                   │
│    │    └→ Doc Search Agent                      │
│    ├→ Generator-Critic Loop (Pattern 5)          │
│    │    ├→ Generator Agent                       │
│    │    └→ Critic Agent                          │
│    └→ Human Review (Pattern 8)                   │
└──────────────────────────────────────────────────┘

⸻

핵심 트레이드오프

패턴을 선택할 때 고려해야 할 축:

특성중앙집중형분산형
일관성높음낮음
병목있음없음
디버깅용이어려움
유연성낮음높음
복잡성낮음높음

⸻

산업 사례

Anthropic Research System

  • 패턴: Coordinator + Parallel Fan-Out
  • 구조: Opus 4 (리드) + Sonnet 4 (서브에이전트)
  • 성과: 내부 리서치 평가에서 단일 Opus 4 에이전트보다 90.2% 높은 성능

Claude Code

실제로 매일 사용하는 Claude Code는 Hierarchical + HITL 패턴의 조합이다. Task tool로 탐색이나 분석 같은 작업을 서브에이전트에게 위임하고, 민감한 작업(파일 삭제, 배포 커맨드 등)은 반드시 사용자 승인을 받는다.

이 조합이 효과적인 이유는 탐색은 자율적으로, 변경은 신중하게라는 원칙 때문이다. 코드베이스를 이해하는 데는 빠른 병렬 탐색이 필요하지만, 실제로 코드를 수정하는 건 사람의 판단이 필요하다.

OpenAI Agents SDK

  • 지원 패턴: Manager (tools), Handoffs (peer-to-peer)
  • 특징: 코드 우선 접근, 동적 오케스트레이션

Deep Agents (LangChain)

  • 기반: BSP (Bulk Synchronous Parallel) 모델
  • 특징: Superstep 기반 실행, 병렬 → Barrier → 상태 병합

⸻

2026 프로덕션 현실

반대 목소리도 있다. Devin을 만든 Cognition의 Walden Yan은 2025년 6월 글 Don’t Build Multi-Agents에 이렇게 썼다.

“it is evident that in 2025, running multiple agents in collaboration only results in fragile systems.”

그가 권하는 방향과 업계 조사 결과를 함께 보면 이렇다.

  • Cognition의 권장: 멀티 에이전트 대신 단일 스레드 에이전트 + 컨텍스트 압축
  • 복잡성 관리가 핵심 과제
  • 응답자의 57%가 이미 에이전트를 프로덕션에서 쓴다 (LangChain 조사)
  • 가장 큰 장벽은 품질이다 (32%)

멀티 에이전트가 늘 답은 아니다. 단일 에이전트의 컨텍스트를 잘 관리하는 쪽이 더 나은 경우도 있다.

⸻

시사점

이 패턴을 알아 두면 좋은 점이 네 가지 있다.

1. 새로운 프레임워크 빠르게 이해하기 새로운 에이전트 프레임워크가 나와도 “이건 어떤 패턴의 구현인가?”로 분류할 수 있다. LangGraph, CrewAI, AutoGen 등이 결국 이 8가지의 변형이다.

2. 디버깅 관점 에이전트가 이상하게 동작할 때 “이 패턴의 어느 부분에서 문제가 생겼나?”로 진단할 수 있다.

3. 설계 가이드 자신의 에이전트를 만들 때 “어떤 패턴이 이 문제에 적합한가?”로 시작할 수 있다.

4. 복잡성 경계 인식 가장 중요한 점이다. 패턴을 안다고 해서 시스템을 복잡하게 만들 필요는 없다. Anthropic이 Building effective agents에서 권하듯 복잡성은 필요할 때만 더한다.

시작점: 단일 LLM + 기본 프롬프트
    ↓ (부족하면)
1단계: 프롬프트 체이닝
    ↓ (부족하면)
2단계: 라우팅/병렬화
    ↓ (부족하면)
3단계: 오케스트레이터-워커
    ↓ (정말 필요하면)
최종: 자율 에이전트

⸻

참고 자료