Microsoft 공식 AI 에이전트 오케스트레이션 (Orchestration) 패턴

멀티 에이전트 구성은 다음과 같은 공개 자료와 같이 용도나 목적에 따라 구성이 다릅니다.

각 패턴에 대해 정리하여 요약합니다.

1. 빠른 참조표

Microsoft가 공개하고 있는 오케스트레이션 (Orchestration) 패턴은 다음 5가지입니다.

하나씩 확인해 보겠습니다.

2. 패턴 ①: 시퀀셜 (Sequential) 오케스트레이션

포인트는 각 에이전트의 순서가 도중에 바뀌지 않는다는 점입니다.

2.1 이미지

공장의 컨베이어 벨트와 같은 이미지입니다.

이전 공정이 끝나면 다음 공정으로, 누가 언제 무엇을 할지는 사전에 결정되어 있는 것입니다.

2.2 개요

순차 오케스트레이션 패턴은 각 스테이지가 이전 스테이지를 기반으로 구축되는, 스텝 바이 스텝 (Step-by-step) 처리가 필요한 문제를 해결합니다. 이는,

명확한 의존성을 가지며, 단계적인 개선을 통해 출력 품질을 향상시키는 워크플로우 (Workflow)에 적합합니다. ( https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/guide/ai-agent-design-patterns#sequential-orchestration )

입력 → Agent 1 → Agent 2 → … → Agent n → 결과라는 흐름입니다.

각 에이전트는 고유한 모델이나 지식(Knowledge), 도구(Tool)를 가지며, 모든 에이전트가 공통된 상태를 공유합니다.

2.3 이 패턴을 선택해야 하는 시나리오

이 패턴은 다음과 같은 시나리오에 부합합니다.

• ⭕ 예측 가능함 (예: 초안 → 리뷰 → 마무리)
• ⭕ 각 단계에서 다음 스테이지가 필요로 하는 값이 확실히 존재함
• ⭕ 단계가 선형적이며 의존성이 있음

반면 다음과 같은 시나리오는 적합하지 않습니다.

• ❌ 병렬 실행이 가능함
• ❌ 초기 단계의 에러가 누적되어 후속 단계에서 이를 멈출 수 없는 상황임
• ❌ 백트래킹 (Backtrack)이나 중간 결과에 의한 동적 라우팅이 필요함

2.4 예: 법률 사무소의 계약서 생성

4체의 에이전트가 순서대로 계약서를 완성함:

• 템플릿 선택 에이전트 — 계약 종류·관할·관계자로부터 기본 템플릿을 선택
• 조항 커스터마이징 에이전트 — 지불 일정·책임 제한 등 비즈니스 조건을 반영
• 규제 컴플라이언스 (Compliance) 에이전트 — 적용 법령·업계 규제와의 정합성을 확인
• 리스크 평가 에이전트 — 책임 발생 확률·분쟁 해결 메커니즘을 종합 분석

3. 패턴 ②: 컨커런트 (Concurrent) 오케스트레이션

포인트는 에이전트끼리는 대화하지 않고, 결과만 집약된다는 점입니다. 병렬로 실행하므로 대기 시간을 압축할 수 있습니다.

3.1 이미지

이미지는 같은 문제를 3명의 전문가에게 동시에 물어보고, 답을 대조하는 것과 같습니다.

예를 들어, 요리사, 영양사, 절약가에게 "이 식재료 어때?"라고 동시에 문의하는 것과 같습니다.

3.2 개요

이 패턴은 동일한 문제에 대해 다양한 분석 정보 또는 접근 방식이 필요한 시나리오를 다룹니다. 순차적 처리 대신 모든 에이전트가 병렬로 동작하기 때문에, 전체적인 실행 시간이 단축되고 문제 영역이 포괄적으로 커버됩니다. ( https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/guide/ai-agent-design-patterns#concurrent-orchestration )

입력 → 이니시에이터(Initiator) & 수집 에이전트 → 복수의 에이전트로 병렬 투입 → 중간 결과 → 집약 (결합·비교·선별) → 최종 결과라는 흐름입니다.

3.3 이 패턴을 선택해야 하는 시나리오

이 패턴은 다음과 같은 시나리오에 적합합니다.

• ⭕ 병렬 실행이 가능한 태스크
• ⭕ 다각도·다전문성으로 동일한 문제에 접근하고 싶을 때 (브레인스토밍 / 투표 / 앙상블 추론 (Ensemble Inference))
• ⭕ 시간이 중요한 시나리오

반면 다음과 같은 시나리오에는 적합하지 않습니다.

• ❌ 에이전트 간에 상태(State)를 인계할 필요가 있을 때
• ❌ 상충하는 결과를 잘 정리할 전략이 없을 때
• ❌ 모델 쿼터(Quota) 등의 리소스 제약으로 인해 병렬 처리가 비효율적이 될 때

3.4 예: 금융 기관의 종목 평가

동일한 종목 심볼을 4개의 에이전트에 동시에 투입하여 독립된 관점을 집약:

• 펀더멘털 분석 (Fundamental Analysis) 에이전트 — 재무제표·수익 동향·경쟁 포지션
• 기술적 분석 (Technical Analysis) 에이전트 — 가격 패턴·거래량·모멘텀
• 감성 분석 (Sentiment Analysis) 에이전트 — 뉴스·SNS·애널리스트 리포트
• ESG 에이전트 — 환경·사회·거버넌스 관점

4. 패턴 ③: 그룹 채팅 오케스트레이션 (회의실 방식)

포인트는 인간이 참여할 수 있다는 점입니다. 이 패턴은 토론이 메인입니다.

4.1 이미지

회의실에서의 토론과 같은 이미지입니다.

사회자 (채팅 매니저)가 "다음은 누구, 다음은 당신"이라며 순서를 넘기고, 참가자는 공유 스레드에 발언을 쌓아갑니다.

4.2 개요

이 패턴은 그룹 디스커션을 통해 결정에 도달하는 것이 최적인 시나리오를 다룹니다.

(중략)

이 패턴은 인간이 필요에 따라 동적 채팅 매니저의 역할을 맡아 생산적인 결과로 대화를 이끌 수 있는, 인간 참여형 (Human-in-the-Loop, HITL) 시나리오에 적합합니다. 이 오케스트레이션 패턴에서 에이전트는 통상적으로 읽기 전용 (Read-only) 모드입니다. 실행 중인 시스템에서 도구를 사용하여 변경을 가하지 않습니다. ( https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/guide/ai-agent-design-patterns#group-chat-orchestration )

입력 → 그룹 채팅 매니저 (사회자) → 에이전트 1, 2, …, n이 공유 스레드에 작성 → 결과. 인간이 스레드에 참여하는 것이 가능합니다.

4.3 이 패턴을 선택해야 하는 시나리오

이 패턴은 다음과 같은 시나리오에 적합합니다.

협업 계열

• ⭕ 브레인스토밍
• ⭕ 토론을 통한 컨센서스(Consensus) 형성
• ⭕ 반복을 통해 정밀도를 높이는 의사결정
• ⭕ 부서 간 횡단적인 문제

검증·품질 관리 계열

• ⭕ 구조화된 리뷰 + 반복
• ⭕ 복수의 전문가를 통한 컴플라이언스(Compliance) 검증
• ⭕ 제작자 vs 검토자를 분리한 편집 리뷰

반면 다음과 같은 시나리오에는 적합하지 않습니다.

• ❌ 단순한 위임이나 선형 파이프라인 (Linear Pipeline)으로 충분할 때
• ❌ 실시간성이 요구되어 토론의 오버헤드(Overhead)를 허용할 수 없을 때
• ❌ 계층적, 결정론적(Deterministic)으로 결정하는 것이 더 빠를 때
• ❌ 태스크 완료를 객관적으로 판정할 수 없을 때

4.4 다른 형태: maker-checker 루프 (제작자 / 검토자)

Maker 에이전트가 작성한 것을 Checker 에이전트가 평가하여 Maker 에이전트에게 돌려보내고, 이를 반복하는 방식입니다.

그룹 채팅 패턴에서는 에이전트가 순서대로 채팅을 할 필요는 없지만, Maker-Checker 루프에는 채팅 매니저가 조작하는 공식적인 턴제(Turn-based) 시퀀스가 필요합니다.

(중략)

이 패턴에서는 Checker 에이전트가 일관된 합격 또는 실패 결정을 내릴 수 있도록 명확한 수락 기준 (Acceptance Criteria)이 필요합니다. ( https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/guide/ai-agent-design-patterns#maker-checker-loops )

다른 이름: Evaluator-Optimizer / Generator-Verifier / 비평 루프 (Critique Loop) / Reflection 루프

승인될 때까지 또는 최대 반복 횟수에 도달할 때까지 반복합니다.

무한 루프를 방지하기 위해, 반복 횟수 상한(Iteration Limit)을 반드시 설정해야 합니다.

4.5 예: 시청의 공원 계획 검토

공원 개발 제안을 그룹 단위로 평가:

커뮤니티 참여 (Community Engagement) 에이전트— 접근성·주민 피드백·이용 패턴 -
환경 계획 (Environmental Planning) 에이전트— 생태계 영향·지속 가능성·규제 적합성 -
예산 및 운영 (Budget & Operations) 에이전트— 건설비·유지비·인력·장기 운영

사회자 (Chat Manager)가 논의를 진행하며, 공원 부서 직원도 인간으로서 스레드에 참여할 수 있습니다.

주민들에게 제시하기 전에 예상되는 반론을 미리 준비할 수 있는 구조입니다.

5. 패턴 ④: 핸드오프 오케스트레이션 (Handoff Orchestration)

핵심은 작동하고 있는 주체가 항상 단 하나라는 점입니다.

그리고 각 에이전트는 자신의 기능적 한계와 다음으로 적합한 에이전트가 누구인지 이해하고 있습니다.

5.1 이미지

병원의 종합 접수처 → 내과 → 순환기 내과 → 외과 → ... 와 같이 소개를 통해 전달되는 이미지입니다.

누구에게 넘길지는 그 시점의 에이전트가 스스로 판단합니다.

5.2 개요

이 패턴은 작업에 가장 적합한 에이전트를 사전에 알 수 없거나, 작업 요구사항이 처리 과정 중에 명확해지는 시나리오에 대응합니다. 이를 통해 지능적인 위임이 가능해지며, 작업이 가장 역량 있는 에이전트에게 확실히 도달할 수 있게 합니다. 일반적으로,

이 패턴의 에이전트는 병렬로 동작하지 않습니다. 하나의 에이전트에서 다른 에이전트로의 완전한 제어권 이전 (Full Control Transfer)이 이루어집니다. ( https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/guide/ai-agent-design-patterns#handoff-orchestration )

각 에이전트가 스스로 처리할지, 아니면 더 적절한 누군가에게 넘길지를 판단합니다.

작동하고 있는 것은 항상 단 하나이며, 제어권이 완전히 이양됩니다.

핸드오프 체인이 계속되어 최종적으로 인간(예: 고객 지원 직원)에게 전달되는 것도 설계에 포함됩니다.

5.3 이 패턴을 선택해야 하는 시나리오

이 패턴은 다음과 같은 시나리오에 적합합니다.

• ⭕ 전문 지식이 필요하지만, 필요한 에이전트의 수나 순서를 사전에 결정할 수 없는 경우
• ⭕ 처리 과정 중에 비로소 "어떤 전문가가 필요한지" 알 수 있는 경우
• ⭕ 하나의 에이전트가 기능적 한계에 도달했을 때, 다음 단계를 논리적으로 결정할 수 있는 경우

반면, 다음과 같은 시나리오에는 적합하지 않습니다.

• ❌ 첫 입력에서 적절한 에이전트(열)를 판별할 수 있는 경우 → 결정론적 라우팅 (Deterministic Routing) 또는 단순 디스패처(Dispatcher)로 충분함
• ❌ 규칙 기반 분기(Rule-based branching)로 해결 가능한 경우
• ❌ 잘못된 라우팅이 UX를 해치는 경우
• ❌ 여러 가지 일을 동시에 수행해야 하는 경우 (병렬 요구사항)
• ❌ 무한 핸드오프 루프 방지가 어려운 경우

5.4 예: 통신사 CRM 고객 지원

트리아지 (Triage) 지원 에이전트— 1차 접수. 스스로 답변 가능한 범위는 답변하고, 한계에 도달하면 전문가에게 전달 -
기술 인프라 (Technical Infrastructure) 에이전트— 네트워크 장애 관련 -
재무 해결 (Financial Resolution) 에이전트— 과금 관련 -
계정 액세스 (Account Access) 에이전트— 로그인·권한 관련

6. 패턴 ⑤: 매제스틱 오케스트레이션 (Majestic Orchestration / PM형 동적 계획)

핵심은 예측 불가능하고 복잡한 문제에 대응하기 위해, 동적으로 계획을 변경해가며 해결까지 나아간다는 점입니다.

6.1 이미지

무슨 일이 일어날지 알 수 없는 재난 현장에 달려온 팀 리더와 같은 이미지입니다.

상황을 보면서 작업 목록 (Task Ledger)을 만들고, 전문가를 불러오고, 보고를 받을 때마다 계획을 다시 작성합니다.

6.2 개요

Magentic Orchestration (마젠틱 오케스트레이션) 패턴은 사전에 정의된 접근 계획이 없는 오픈 엔드(Open-ended) 방식의 복잡한 문제에 대응하도록 설계되었습니다. 일반적으로 이 패턴의 에이전트는 외부 시스템에 직접 변경을 가하는 데 도움이 되는 도구(Tool)를 가지고 있습니다. 이 접근 방식을 구현할 때와 마찬가지로,

문제를 해결하기 위한 접근 방식을 구축하고 문서화하는 데 중점을 둡니다.

(중략)

몇 가지 측면에서 이 오케스트레이션 패턴은 Group Chat (그룹 채팅) 패턴의 확장입니다. ( https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/guide/ai-agent-design-patterns#magentic-orchestration )

**Manager Agent (매니저 에이전트)**가 중심입니다.

태스크와 진행 상황의 장부(Ledger)를 보유하며, 에이전트를 호출하여 정보를 수집하고, 목표 달성 여부를 평가하면서 루프를 돌립니다.

외부 시스템 변경 도구를 가진 에이전트를 사용하는 것이 특징입니다.

6.3 이 패턴을 선택해야 하는 시나리오

이 패턴은 다음과 같은 시나리오에 적합합니다.

• ⭕ 사전에 해결 절차가 정해지지 않은 문제
• ⭕ 여러 전문가의 의견을 통합하여 계획을 세워야만 진행할 수 있는 경우
• ⭕ AI가 세운 계획을 인간이 사전에 검토할 수 있는 형태로 남기고 싶은 경우
• ⭕ 외부 시스템을 변경하는 도구를 사용하는 에이전트가 포함된 경우

반면, 다음과 같은 시나리오에는 적합하지 않습니다.

• ❌ 해결 절차가 이미 정해져 있는 경우 / 결정론적(Deterministic)이어야 하는 경우
• ❌ 장부를 만들 필요가 없는 단순 태스크
• ❌ 시간 제약이 있는 경우 (이 패턴은 속도보다 계획의 품질을 우선시함)
• ❌ 빈번하게 정체되거나 무한 루프에 빠질 징후가 있는 경우

6.4 그룹 채팅과의 차이점

Group Chat은 에이전트 간의 토론을 통한 합의가 목적입니다.

Magentic은 토론이라기보다는 계획 실행에 가깝습니다. Manager Agent가 동적으로 계획을 관리하며 목표 달성을 지향합니다.

6.5 예: SRE의 인시던트 대응 자동화

서비스 중단이 발생했을 때, 시스템이 복구 계획을 동적으로 생성하고 구현하는 경우 (사전에 절차가 정해져 있지 않음):

• SRE Automation Manager — 태스크 장부를 만들어 전체를 총괄
• Diagnosis Agent (진단 에이전트) — 로그, 메트릭, 에러 패턴으로부터 원인 후보 도출
• Infrastructure Agent (인프라 에이전트) — 현황 파악 + 복구 옵션 제시
• Rollback Agent (롤백 에이전트) — 배포 복구가 필요할 경우 호출됨
• Communication Agent (통신 에이전트) — 이해관계자 통지, 인간 SRE에게 에스컬레이션

예: 진단 결과가 데이터베이스 연결 문제인 경우 → 매니저는 '배포 롤백 계획'에서 'DB 연결 복구 계획'으로 플랜 전체를 전환합니다.

가드레일(Guardrail)은 과도한 중단 모니터링, 무한 복구 루프 방지, 진화하는 계획에 대한 **완전한 감사 추적(Audit Trail)**을 유지하는 것입니다.

7. 구현 시 주의사항

고려해야 할 사항으로는 다음과 같은 것들이 있습니다.

8. 요약

Microsoft가 공개한 멀티 에이전트 구성 5가지 패턴을 정리했습니다.

이 패턴들은 조합하여 사용하는 것도 상정되어 있습니다.

워크로드의 다양한 단계에는 서로 다른 특성이 있으며, 서로 다른 패턴을 사용하여 각 단계에서 이점을 얻을 수 있는 경우에는 하나의 워크플로우를 하나의 패턴에만 맞추지 마십시오. ( https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/guide/ai-agent-design-patterns#combining-orchestration-patterns )

또한, Agent Framework를 이용하면 이러한 오케스트레이션 패턴이 내장되어 지원됩니다. 멀티 에이전트 구성 구축에 도움이 되기를 바랍니다.

Discussion