Home / 멀티에이전트 시스템 / 멀티에이전트 설계
Module

멀티에이전트 설계

여러 에이전트가 협업하는 시스템의 설계 패턴과 구현

⏱ 60분 104 / 189

멀티에이전트 시스템 설계

Supervisor · Pipeline · Swarm · AWS 구현

한 에이전트로 안 되면 팀을 설계한다

6가지 멀티에이전트 패턴 비교와 AWS 구현 전략

멀티에이전트 개요

한계 · 장점 · 설계 원칙 · 패턴 비교표

PART 1 · 개요

멀티에이전트 개요

단일 에이전트의 4대 한계에서 출발하는 6가지 패턴 지형

한계 → 원칙 → 패턴 지형

단일 에이전트의 4대 한계를 확인하고, 설계 원칙과 함께 6가지 패턴을 2축으로 분류합니다.

  • 4대 한계 — 컨텍스트 비대화 · 전문성 희석 · 단일 장애점 · 디버깅 불가
  • 설계 원칙 — 전문화 · 격리 · 관측 가능성 · 우아한 실패
  • 6가지 패턴 — 제어 방식 × 에이전트 자율성 2축 분류
  • 조율 비용 — 에이전트 수에 따라 조합적(n²) 증가
takeaway

한계를 아는 것이 패턴 선택의 출발점입니다 — 여기서 그린 패턴 지형을 파트 2~4에서 하나씩 파고듭니다.

PART 1 · 개요

단일 에이전트 한계 vs 멀티에이전트 장점

왜 여러 에이전트가 필요한가 — 4가지 근본적 한계

✗ 단일 에이전트 한계

  • System Prompt 비대화 · 문맥 한계 초과
  • 전문성 희석 — 도메인별 최적화 불가
  • 단일 장애점 — 오류 전파 차단 불가
  • 디버깅 불가 — 내부 추론 추적 어려움

모든 도메인 지식을 하나의 시스템 프롬프트에 담으면 문맥 한계를 초과하고 도메인별 최적화가 불가능해집니다. 오류가 발생해도 전파를 차단할 수 없고, 내부 추론을 추적하기 어려워 디버깅이 막힙니다.

✓ 멀티에이전트 장점

  • 전문화 — 각 에이전트가 단일 도메인 담당
  • 병렬 처리 — 독립 태스크 동시 실행
  • 격리 — 오류가 다른 에이전트에 전파 안 됨
  • 확장성 — 에이전트 추가만으로 기능 확장

각 에이전트가 단일 도메인만 담당해 프롬프트가 짧고 명확해집니다. 독립 태스크는 병렬로 실행하고, 오류는 해당 에이전트 안에서 격리되며, 기능 확장은 에이전트 추가만으로 해결합니다.

takeaway

멀티에이전트 전환은 기능 추가가 아니라 네 가지 한계를 구조로 해소하는 결정입니다 — 전문화 · 병렬 처리 · 격리 · 확장성이 그 반대편에 놓입니다.

PART 1 · 개요

설계 원칙 — 아키텍처가 성패 결정

3개 이상 에이전트가 협력하는 순간 조율 비용이 조합적(n²)으로 증가

전문화

각 에이전트가 단일 도메인만 담당 — 짧고 명확한 프롬프트

격리

오류와 컨텍스트가 에이전트 경계 안에 갇히는 구조

관측 가능성

어느 에이전트가 무엇을 왜 했는지 추적 가능한 설계

우아한 실패

일부 에이전트가 실패해도 전체는 대안으로 지속

takeaway

네 원칙 모두 초기 설계 결정입니다 — 잘못된 구조는 시스템이 커진 뒤 고칠수록 비용이 커지므로, 시나리오에 맞는 패턴 선택과 함께 처음부터 적용합니다.

PART 1 · 개요

6가지 패턴 비교

시나리오에 맞는 패턴 선택이 첫 번째 결정

패턴제어 방식적합한 시나리오복잡도
Supervisor중앙 집중명확한 위임·소규모★★
Hierarchical다계층 재귀대규모 조직·팀 단위★★★
Pipeline순차 전달단계별 변환·ETL★
Router의도 기반 분기도메인별 전문 응답★★
Swarm자율 핸드오프동적 협업·탐색★★★
Debate토론·검증고품질 추론·팩트체크★★★
takeaway

첫 번째 축은 제어 방식입니다 — 중앙 집중이면 파트 2, 흐름 고정이면 파트 3, 자율 협업이면 파트 4에서 패턴을 고릅니다.

중앙 제어 패턴

Supervisor · Hierarchical

PART 2 · 중앙 제어

중앙 제어 패턴

중앙 오케스트레이터가 위임과 통합을 책임지는 가장 예측 가능한 구조

Supervisor · Hierarchical

중앙 LLM이 태스크를 분해·배정하고 결과를 통합합니다 — 병목이 보이면 계층화로 확장합니다.

  • Supervisor — 요청 분석 → 위임 → 결과 수집 → 응답 합성
  • docstring 라우팅 — 도구 설명이 위임 품질을 결정
  • Hierarchical — Root → Mid → Worker 재귀 위임
  • 적합 — 작업 분해가 명확하고 실행 순서가 정해진 경우
takeaway

단순하고 예측 가능해서 가장 먼저 검토하는 패턴입니다 — 위임 흐름 → 장단점 → 계층 확장 순서로 살펴봅니다.

PART 2 · 중앙 제어

Supervisor 패턴

중앙 Supervisor가 모든 Sub-agent를 직접 지시하고 결과 수집

  1. 1
    요청 분석

    오케스트레이터가 사용자 메시지를 분석. 복합 요청이면 하위 태스크로 분해하여 각 전문가에게 할당할 준비

  2. 2
    Sub-agent 선택

    @tool의 docstring(description)이 각 전문가의 "능력 설명". 모델이 이를 읽고 가장 적합한 전문가를 선택

  3. 3
    위임 (Delegation)

    선택된 전문가 도구를 호출 — 내부적으로 해당 Agent가 독립 실행. 오케스트레이터의 컨텍스트와 분리됨

  4. 4
    결과 수집

    Sub-agent 실행 완료 후 str(result)로 텍스트 추출. 여러 전문가를 순차 호출한 경우 결과를 모두 수집

  5. 5
    응답 합성

    수집된 결과를 기반으로 오케스트레이터가 최종 응답 생성. 필요 시 추가 전문가 호출 판단 (ReAct 루프)

takeaway

Sub-agent는 오케스트레이터와 컨텍스트가 분리된 채 독립 실행됩니다 — 위임 품질은 도구 docstring의 구체성이 좌우합니다.

PART 2 · 중앙 제어

Supervisor 장단점

명확한 책임 분리와 확장성 — 그러나 병목 위험

✓ 장점

  • 명확한 책임 분리 — 각 Sub-agent가 전담 도메인만 처리
  • 에이전트 추가·제거 용이 — Supervisor 코드 변경 없이 확장
  • 중앙 집중 오류 처리 — 실패 시 재시도·폴백 전략 일원화

✗ 단점

  • Supervisor 병목 — 모든 요청이 단일 지점 통과
  • 지연 누적 — Sub-agent 순차 호출 시 대기 시간 합산
  • Supervisor 복잡도 — 도메인 늘어나면 라우팅 로직 비대화
takeaway

책임 분리와 오류 처리 일원화를 얻는 대신 단일 지점 병목과 지연 누적을 감수합니다 — 규모가 커지면 계층화(Hierarchical)를 검토합니다.

PART 2 · 중앙 제어

Hierarchical 패턴

Mid Supervisor가 팀 단위로 재귀 위임 — 대규모 확장 구조

takeaway

Mid Supervisor가 팀 단위 위임을 흡수해 Root의 병목을 분산합니다 — 재귀 구조로 수십 개 에이전트까지 확장합니다.

흐름 제어 패턴

Pipeline · Router

PART 3 · 흐름

흐름 제어 패턴

순서 또는 분기 기준이 명확할 때 흐름을 구조로 고정하는 패턴군

Pipeline · Router

흐름이 데이터 구조로 고정됩니다 — 순서가 정해졌으면 Pipeline, 유형이 나뉘면 Router를 선택합니다.

  • Pipeline — 직렬 처리, 이전 출력이 다음 입력 (ETL · 문서 처리)
  • Router — 의도 분석 후 전문 에이전트로 분기
  • 적합 — 태스크 유형이 구분되거나 순서가 고정된 경우
  • 복잡도 — 6패턴 중 가장 낮은 축 (★~★★)
takeaway

흐름을 미리 그릴 수 있다면 예측 가능성이 가장 높은 이 두 패턴으로 충분합니다.

PART 3 · 흐름

Pipeline 패턴

순차 처리 체인 — 이전 에이전트 출력이 다음 에이전트 입력으로 자동 전달

  1. 1
    Agent 1 — 추출 (Extract)

    문서 파싱 및 원시 데이터 추출

  2. 2
    Agent 2 — 분석 (Analyze)

    패턴 인식 및 통계 분석

  3. 3
    Agent 3 — 변환 (Transform)

    분석 결과를 최종 포맷으로 변환

takeaway

순서가 고정되고 각 단계의 입출력 포맷이 명확할 때 최적입니다 — ETL · 문서 처리 · 코드 리뷰 파이프라인이 대표 사례입니다.

PART 3 · 흐름

Router 패턴

LLM이 사용자 의도를 분석하여 적합한 전문 에이전트에 동적 라우팅

takeaway

분기 품질은 의도 분류가 좌우합니다 — 키워드·신뢰도 점수로 분류해 도메인 전문 에이전트가 최적 응답을 만듭니다.

분산 협업 패턴

Blackboard · Swarm · Debate

PART 4 · 분산

분산 협업 패턴

중앙 제어 없이 에이전트들이 스스로 판단하고 협업하는 자율성 최상위 패턴군

Blackboard · Swarm · Debate

흐름을 미리 그리지 않습니다 — 에이전트가 핸드오프하거나 토론하며 스스로 경로를 만듭니다.

  • Swarm — handoff_to_agent로 자율 핸드오프
  • Debate — Proposer · Critic · Verifier 토론 검증
  • Blackboard — 공유 저장소 기반 보조 패턴
  • 적합 — 동적 상황 · 다양한 관점 · 높은 자율성
takeaway

자율성이 높아질수록 예측 가능성은 낮아집니다 — 경로가 불확실하거나 관점이 여럿 필요할 때 선택합니다.

PART 4 · 분산

3가지 분산 협업 패턴

중앙 제어 없이 에이전트들이 자율적으로 협업

Blackboard

공유 상태 저장소에 비동기 읽기/쓰기 — 이벤트 기반 트리거로 자율 개입

Swarm

중앙 Supervisor 없이 에이전트가 스스로 다음 에이전트 결정 — 자율 핸드오프

Debate

Proposer·Critic·Verifier 토론으로 답변 품질 향상 — 자기 검증 루프

takeaway

Swarm과 Debate가 분산 협업의 두 축입니다 — Blackboard는 6패턴 분류 밖의 보조 패턴으로, 공유 저장소 관점을 보탭니다.

PART 4 · 분산

Swarm 상세

에이전트가 스스로 다음 에이전트를 결정 — 자율 핸드오프 패턴

구조

  • 중앙 Supervisor 없음 — 분산 의사결정
  • 현재 에이전트가 조건 충족 여부 직접 판단
  • handoff_to_agent 도구로 제어권 이전
  • 핸드오프 메시지 + shared_context로 컨텍스트 전달 (대화 히스토리는 미전달)

적합한 시나리오

  • 고객 서비스 (라우팅 → 전문가 핸드오프)
  • 탐색적 문제 해결 (경로 불확실)
  • 동적 워크플로우 (사전 정의 불가)
takeaway

핸드오프에서 대화 히스토리는 넘어가지 않습니다 — 핸드오프 메시지와 shared_context가 다음 에이전트가 받는 컨텍스트의 전부입니다.

PART 4 · 분산

Debate 패턴

Proposer·Critic·Verifier 3역할 토론으로 답변 품질 자가 검증

  1. 1
    Proposer

    가장 유력한 솔루션으로 초안 답변을 생성합니다. 근거를 함께 제시해 이후 검증 대상을 명확히 합니다.

  2. 2
    Critic

    초안의 논리적 허점과 오류를 지적합니다. 반론과 대안 관점을 제시해 초안을 다시 검토하게 만듭니다.

  3. 3
    Verifier

    제안과 반론을 종합해 검증합니다. 남은 쟁점을 정리하고 최종 답변의 품질을 판정합니다.

takeaway

고위험 의사결정(금융·의료·법률)에서 단일 에이전트의 환각을 구조적으로 방지하는 패턴입니다.

AWS 멀티에이전트 구현

Bedrock · Strands · AgentCore · 전담 모듈 브리지

PART 5 · AWS 멀티에이전트 구현

AWS 구현 전략

관리형 · SDK · 혼합 — 코드 최소화부터 세밀 제어·운영 위임까지의 전략 지도

전략 3종 + 전담 모듈 브리지 2개

관리형 → SDK → 혼합의 전략 지도를 그리고, 구현 코드와 프로토콜 표준은 전담 모듈로 넘깁니다.

  • Bedrock 네이티브 — 콘솔/API 설정, 코드 최소화
  • Strands SDK — 코드로 세밀 제어, 구현 4패턴
  • AgentCore 배포 — 컨테이너 → Runtime → 자동 스케일링
  • 브리지 — Strands 멀티에이전트 · 에이전트 프로토콜 모듈
takeaway

이 파트는 전략 지도까지만 그립니다 — 구현 코드는 Strands 멀티에이전트, 표준 프로토콜은 에이전트 프로토콜 모듈이 전담합니다.

PART 5 · AWS 멀티에이전트 구현

3가지 구현 전략

관리형 → SDK → 혼합 — 복잡도와 제어력의 트레이드오프

Bedrock 네이티브

콘솔/API 설정으로 에이전트 구성 — 코드 최소화, 빠른 시작

Strands SDK

Python으로 에이전트 동작 세밀 제어 — Agents-as-Tools · Swarm · Graph · Workflow

AgentCore 배포

컨테이너 패키징 → Runtime 배포 → Gateway 라우팅 → 자동 스케일링

takeaway

관리형은 시작이 빠르고 SDK는 제어가 깊습니다 — 복잡도와 제어력의 트레이드오프에서 프로덕션은 Strands 구현 + AgentCore 배포 혼합이 기본 조합입니다.

PART 5 · AWS 멀티에이전트 구현

다음 단계 — Strands 구현 패턴

명시적 흐름의 Graph와 암묵적 흐름의 Swarm — 워크플로우 복잡도가 가르는 갈림길

Graph — 명시적 흐름

  • GraphBuilder로 노드·엣지 정의
  • 조건 분기·병렬 실행을 코드로 제어
  • 복잡한 워크플로우에 적합

Swarm — 암묵적 흐름

  • handoff_to_agent로 자율 핸드오프
  • 다음 에이전트를 에이전트가 결정
  • 동적 라우팅에 적합
takeaway

가장 빠른 구현은 @tool로 Sub-agent를 도구처럼 등록하는 Agents-as-Tools입니다 — 4가지 구현 패턴(Agents-as-Tools · Swarm · Graph · Workflow)의 코드와 실행 제어는 Strands 멀티에이전트 모듈이 전담합니다.

PART 5 · AWS 멀티에이전트 구현

다음 단계 — 통신 프로토콜

프레임워크를 넘는 협업의 표준 — 도구 연결은 MCP, 에이전트 간 위임은 A2A

MCP + A2A

도구 연결은 MCP, 에이전트 간 위임은 A2A — 두 표준이 N×M 통합 폭발을 끊습니다.

  • MCP — 에이전트 ↔ 도구 (수직)
  • A2A — 에이전트 ↔ 에이전트 (수평)
  • N×M 커넥터 → 에이전트당 1개
  • 크로스 프레임워크 호환
takeaway

N×M 문제의 구조, MCP 3대 Primitive, A2A Agent Card·Task Lifecycle은 에이전트 프로토콜 모듈이 전담합니다 — 이 모듈의 패턴들을 프레임워크 경계 밖으로 확장할 때 그 모듈로 이어가세요.

만능 패턴은 없습니다 — 시나리오가 구조를 결정합니다.

Supervisor · Hierarchical · Pipeline · Router · Swarm · Debate