Multi-Agent | The .NET Blog

핸드오프 패턴: 에이전트 하나로는 부족할 때

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

어느 시점에서 모든 멀티에이전트 시스템은 단순한 라우터를 넘어섭니다. 첫 번째 신호는 보통 전문 에이전트가 후속 질문을 해야 할 때, 또는 턴 중간에 다른 에이전트가 계속해야 한다는 것을 깨달을 때입니다. 고정 파이프라인은 거기서 실패합니다. 원샷 라우터도 거기서 실패합니다.

그것이 바로 Microsoft Agent Framework의 Handoff 오케스트레이션 패턴이 해결하도록 설계된 문제입니다.

Handoff 작동 방식

개발자가 그래프를 선언합니다: 에이전트들과 그들 사이의 엣지들. 프레임워크가 나머지를 합니다 — 각 출력 엣지마다 핸드오프 도구를 합성하고 각 에이전트에 주입합니다. 에이전트가 제어를 넘기기로 결정하면 도구를 호출합니다. 프레임워크가 토폴로지를 강제합니다.

이것을 단순히 에이전트들이 서로를 호출하는 것과 다르게 만드는 세 가지:

하나의 공유 트랜스크립트 — 수신 에이전트는 전체 대화 기록을 봅니다. 처음부터 다시 시작하지 않습니다.
토폴로지 강제 — 에이전트는 선언된 대상에만 핸드오프할 수 있습니다. 라우팅 버그는 작성 시점에 감지되고 프로덕션에서는 감지되지 않습니다.
자연스러운 종료 — 활성 에이전트가 핸드오프 도구를 호출하지 않고 턴을 마치면 워크플로가 사용자에게 양보합니다. 폴링 없음, 명시적 종료 조건 없음.

최소한의 예

.NET에서 handoff 워크플로 구축은 이렇게 보입니다:

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triage는 두 전문가 모두에게 보낼 수 있습니다. 두 전문가 모두 triage로 다시 보낼 수 있습니다. 그래프는 비순환을 지원하지만 필요할 때 (“더 많은 정보가 필요해” → 연구로 돌아가기) 백엣지를 지원합니다.

Handoff를 사용할 때 (그리고 언제 사용하지 않을 때)

Handoff가 좋은 선택인 경우:

소유권이 대화 중간에 바뀔 수 있음 — 에이전트가 자신이 잘못된 전문가라는 것을 깨달을 수 있음
백엣지가 중요함 — 재시작 없이 이전 단계를 재방문해야 할 수 있음
라우팅 결정이 미묘함 — 핸드오프 결정이 상황에 따라 다르고 타입된 술어보다 모델이 결정하는 것이 더 나음

적합하지 않은 경우:

파이프라인이 고정되고 순차적 — 그런 경우 Sequential 워크플로 사용
각 단계가 독립적 — 에이전트들이 한 명만 필요했던 트랜스크립트를 공유하는 것은 노이즈
엄격한 처리 보장이 필요 — 모델 기반 라우팅의 비결정론은 원하는 것이 아님

백엣지와 Human-in-the-Loop

Handoff가 가능하게 하는 가장 흥미로운 형태 중 하나는 진정한 백엣지입니다. 에이전트는 “정보가 충분하지 않다"고 결정하고 연구 단계로 다시 라우팅할 수 있습니다 — 하드코딩된 루프가 아니라 모델이 그것이 올바른 결정이라고 결정하기 때문입니다.

Human-in-the-loop 상호작용도 자연스럽게 구성됩니다. 전문가가 사용자 입력이 필요할 때 워크플로는 기본 턴 루프를 통해 사용자에게 양보하고, 응답을 수집하고, 완전한 컨텍스트로 재개합니다. 에이전트는 대화를 잃지 않았습니다.

마무리

Handoff는 내면화하면 많은 것을 가능하게 하는 단순해 보이는 패턴 중 하나입니다: 분산 라우팅, 공유 컨텍스트, 강제된 토폴로지, 자연스러운 종료. 에이전트들이 “실제로 다른 사람이 이것을 처리해야 한다"고 말하기 시작할 때 올바른 다음 단계입니다.

원본 포스트에서 전체 튜토리얼 읽기: A Tour of the Handoff Orchestration Pattern

블랙박스처럼 느껴지지 않는 실시간 멀티 에이전트 UI 구축하기

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 원문은 여기에서 확인하세요.

멀티 에이전트 시스템의 문제는 이렇습니다: 데모에서는 놀라울 정도로 멋져 보입니다. 세 개의 에이전트가 작업을 주고받고, 문제를 해결하고, 의사결정을 내립니다. 그런데 실제 사용자 앞에 놓으면… 침묵. 돌아가는 로딩 인디케이터. 어떤 에이전트가 뭘 하고 있는지, 왜 시스템이 멈췄는지 전혀 알 수 없습니다. 이건 제품이 아닙니다 — 신뢰 문제입니다.

Microsoft Agent Framework 팀이 MAF 워크플로우를 AG-UI와 결합하는 훌륭한 워크스루를 발표했습니다. AG-UI는 Server-Sent Events를 통해 에이전트 실행 이벤트를 프론트엔드로 스트리밍하는 오픈 프로토콜입니다. 솔직히? 이건 우리에게 빠져있던 바로 그 다리입니다.

.NET 개발자에게 중요한 이유

AI 기반 앱을 만들고 있다면, 아마 이 벽에 부딪혀 봤을 겁니다. 백엔드 오케스트레이션은 완벽하게 동작합니다 — 에이전트들이 서로 작업을 넘기고, 도구가 실행되고, 결정이 내려집니다. 하지만 프론트엔드는 뒤에서 무슨 일이 벌어지고 있는지 전혀 모릅니다. AG-UI는 에이전트 이벤트(RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_* 등)를 SSE를 통해 UI 레이어로 직접 스트리밍하는 표준 프로토콜을 정의하여 이 문제를 해결합니다.

데모는 세 개의 에이전트로 구성된 고객 지원 워크플로우입니다: 요청을 라우팅하는 트리아지 에이전트, 환불을 처리하는 환불 에이전트, 교체를 관리하는 주문 에이전트. 각 에이전트는 자체 도구를 가지고 있으며, 핸드오프 토폴로지가 명시적으로 정의되어 있습니다 — “프롬프트에서 알아내라"는 식이 아닙니다.

핸드오프 토폴로지가 진짜 주인공

제 눈을 사로잡은 것은 HandoffBuilder로 에이전트 간 방향성 라우팅 그래프를 선언할 수 있다는 점입니다:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

각 add_handoff는 자연어 설명이 포함된 방향성 엣지를 생성합니다. 프레임워크는 이 토폴로지를 기반으로 각 에이전트의 핸드오프 도구를 생성합니다. 따라서 라우팅 결정은 오케스트레이션 구조에 기반하며, LLM이 마음대로 결정하는 것이 아닙니다. 이것은 프로덕션 안정성에 있어 엄청난 차이입니다.

실제로 작동하는 Human-in-the-loop

데모는 실제 에이전트 앱에 필요한 두 가지 인터럽트 패턴을 보여줍니다:

도구 승인 인터럽트 — 에이전트가 approval_mode="always_require"로 표시된 도구를 호출하면, 워크플로우가 일시 중지되고 이벤트를 발생시킵니다. 프론트엔드는 도구 이름과 인수가 포함된 승인 모달을 렌더링합니다. 토큰을 소모하는 재시도 루프 없이, 깔끔한 일시중지-승인-재개 흐름입니다.

정보 요청 인터럽트 — 에이전트가 사용자로부터 더 많은 컨텍스트(예: 주문 ID)가 필요할 때, 일시 중지하고 질문합니다. 프론트엔드가 질문을 표시하고, 사용자가 응답하면, 실행이 멈춘 바로 그 지점에서 재개됩니다.

두 패턴 모두 표준 AG-UI 이벤트로 스트리밍되므로, 프론트엔드에 에이전트별 커스텀 로직이 필요 없습니다 — SSE 연결을 통해 들어오는 이벤트를 그대로 렌더링하면 됩니다.

연결이 놀라울 정도로 간단합니다

MAF와 AG-UI의 통합은 단 하나의 함수 호출입니다:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factory는 스레드마다 새로운 워크플로우를 생성하여, 각 대화가 격리된 상태를 가집니다. 엔드포인트는 모든 SSE 배관을 자동으로 처리합니다. 이미 FastAPI를 사용하고 있다면(또는 경량 레이어로 추가할 수 있다면), 거의 마찰 없이 사용할 수 있습니다.

제 생각

우리 .NET 개발자들에게 즉각적인 질문은 “C#으로 할 수 있나?“입니다. Agent Framework는 .NET과 Python 모두에서 사용 가능하고, AG-UI 프로토콜은 언어에 구애받지 않습니다(그냥 SSE입니다). 따라서 이 특정 데모가 Python과 FastAPI를 사용하지만, 패턴은 직접 적용할 수 있습니다. 동일한 AG-UI 이벤트 스키마를 따르는 SSE 엔드포인트가 있는 ASP.NET Core 최소 API를 구성할 수 있습니다.

더 큰 시사점은 멀티 에이전트 UI가 사후 고려사항이 아닌 일급 관심사가 되고 있다는 것입니다. 에이전트가 인간과 상호작용하는 무엇이든 구축하고 있다면 — 고객 지원, 승인 워크플로우, 문서 처리 — MAF 오케스트레이션과 AG-UI 투명성의 조합이 따라야 할 패턴입니다.

마무리

AG-UI + Microsoft Agent Framework는 두 세계의 장점을 모두 제공합니다: 백엔드의 강력한 멀티 에이전트 오케스트레이션과 프론트엔드의 실시간 가시성. 더 이상 블랙박스 에이전트 인터랙션은 없습니다.

전체 워크스루와 AG-UI 프로토콜 저장소를 확인하여 더 깊이 알아보세요.

Microsoft Agent Framework 1.0 출시 — .NET 개발자에게 정말 중요한 것들

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 원문은 여기를 클릭하여 확인하세요.

Semantic Kernel과 AutoGen 초기부터 Agent Framework의 여정을 지켜봐 왔다면, 이번 소식은 의미가 큽니다. Microsoft Agent Framework가 버전 1.0에 도달했습니다 — 프로덕션 준비 완료, 안정적인 API, 장기 지원 약속. .NET과 Python 모두에서 사용할 수 있으며, 실제 워크로드를 처리할 준비가 되어 있습니다.

발표의 소음을 걷어내고 .NET으로 AI 기반 앱을 구축하는 분들에게 중요한 내용에 집중하겠습니다.

짧은 요약

Agent Framework 1.0은 기존의 Semantic Kernel과 AutoGen을 하나의 오픈소스 SDK로 통합합니다. 하나의 에이전트 추상화. 하나의 오케스트레이션 엔진. 다수의 AI 제공업체. 엔터프라이즈 패턴을 위한 Semantic Kernel과 연구용 멀티 에이전트 워크플로를 위한 AutoGen 사이를 오갔다면, 이제 그만해도 됩니다. 이것이 유일한 SDK입니다.

시작하기가 거의 불공평할 정도로 쉽습니다

.NET에서 작동하는 에이전트 코드입니다:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

이게 전부입니다. 몇 줄의 코드로 Azure Foundry에서 실행되는 AI 에이전트가 완성됩니다. Python 버전도 마찬가지로 간결합니다. 함수 도구, 멀티턴 대화, 스트리밍은 필요할 때 추가하면 됩니다 — API 표면이 이상해지지 않으면서 확장됩니다.

멀티 에이전트 오케스트레이션 — 이것이 진짜입니다

단일 에이전트는 데모에는 괜찮지만, 프로덕션 시나리오는 보통 조율이 필요합니다. Agent Framework 1.0은 Microsoft Research와 AutoGen에서 직접 가져온 실전 검증된 오케스트레이션 패턴을 탑재하고 있습니다:

순차적 — 에이전트가 순서대로 처리 (작성자 → 검토자 → 편집자)
동시적 — 여러 에이전트에게 병렬로 분배하고, 결과를 수렴
핸드오프 — 하나의 에이전트가 의도에 따라 다른 에이전트에게 위임
그룹 채팅 — 여러 에이전트가 논의하고 해결책으로 수렴
Magentic-One — MSR의 연구용 멀티 에이전트 패턴

모두 스트리밍, 체크포인팅, 인간 참여 승인, 일시 중지/재개를 지원합니다. 체크포인팅 부분이 중요합니다 — 장시간 실행되는 워크플로가 프로세스 재시작을 견뎌냅니다. Azure Functions로 지속성 있는 워크플로를 구축해 본 .NET 개발자에게는 익숙한 느낌일 겁니다.

가장 중요한 기능들

알아둘 가치가 있는 항목 목록입니다:

미들웨어 훅. ASP.NET Core에 미들웨어 파이프라인이 있는 거 아시죠? 같은 개념인데, 에이전트 실행용입니다. 모든 단계를 가로채서 — 콘텐츠 안전, 로깅, 컴플라이언스 정책을 추가 — 에이전트 프롬프트를 건드리지 않고 할 수 있습니다. 이것이 에이전트를 엔터프라이즈 수준으로 만드는 방법입니다.

플러거블 메모리. 대화 이력, 영속적 키-값 상태, 벡터 기반 검색. 백엔드를 선택하세요: Foundry Agent Service, Mem0, Redis, Neo4j, 또는 직접 구현. 메모리는 상태 없는 LLM 호출을 실제로 컨텍스트를 기억하는 에이전트로 바꿔주는 핵심입니다.

선언적 YAML 에이전트. 에이전트의 지시사항, 도구, 메모리, 오케스트레이션 토폴로지를 버전 관리되는 YAML 파일에 정의합니다. 단일 API 호출로 로드하고 실행합니다. 이것은 코드를 재배포하지 않고 에이전트 동작을 반복하고 싶은 팀에게 게임 체인저입니다.

A2A 및 MCP 지원. MCP(Model Context Protocol)는 에이전트가 외부 도구를 동적으로 발견하고 호출할 수 있게 합니다. A2A(Agent-to-Agent 프로토콜)는 크로스 런타임 협업을 가능하게 합니다 — .NET 에이전트가 다른 프레임워크에서 실행되는 에이전트와 조율할 수 있습니다. A2A 1.0 지원은 곧 출시 예정입니다.

주목할 만한 프리뷰 기능

1.0에서 프리뷰로 출시된 기능들이 있습니다 — 작동하지만 API가 변경될 수 있습니다:

DevUI — 에이전트 실행, 메시지 흐름, 도구 호출을 실시간으로 시각화하는 브라우저 기반 로컬 디버거. Application Insights의 에이전트 추론 버전이라고 생각하면 됩니다.
GitHub Copilot SDK 및 Claude Code SDK — 오케스트레이션 코드에서 직접 Copilot이나 Claude를 에이전트 하네스로 사용합니다. 같은 워크플로에서 코딩 가능한 에이전트를 다른 에이전트와 함께 구성할 수 있습니다.
Agent Harness — 에이전트에게 셸, 파일 시스템, 메시징 루프에 대한 접근을 제공하는 커스터마이즈 가능한 로컬 런타임. 코딩 에이전트와 자동화 패턴을 떠올려 보세요.
Skills — 에이전트에게 즉시 사용 가능한 구조화된 기능을 제공하는 재사용 가능한 도메인 능력 패키지.

Semantic Kernel 또는 AutoGen에서 마이그레이션

기존 Semantic Kernel 또는 AutoGen 코드가 있다면, 코드를 분석하고 단계별 마이그레이션 계획을 생성하는 전용 마이그레이션 어시스턴트가 있습니다. Semantic Kernel 마이그레이션 가이드와 AutoGen 마이그레이션 가이드가 모든 과정을 안내해 줍니다.

RC 패키지를 사용하고 계셨다면, 1.0으로의 업그레이드는 버전 번호만 바꾸면 됩니다.

마무리

Agent Framework 1.0은 엔터프라이즈 팀이 기다려온 프로덕션 마일스톤입니다. 안정적인 API, 멀티 제공업체 지원, 실제로 대규모에서 작동하는 오케스트레이션 패턴, 그리고 Semantic Kernel과 AutoGen 모두에서의 마이그레이션 경로.

프레임워크는 GitHub에서 완전한 오픈소스이며, dotnet add package Microsoft.Agents.AI로 오늘 바로 시작할 수 있습니다. 빠른 시작 가이드와 샘플을 확인해서 직접 경험해 보세요.

“프로덕션에서 안전하게 사용할 수 있다"는 신호를 기다리고 있었다면 — 바로 이것입니다.