Azure Functions | The .NET Blog

Microsoft Agent Framework의 지속적 워크플로우: In-Memory에서 Azure Functions까지

Emiliano Montesdeoca — Sun, 31 May 2026 00:00:00 +0000

초기 AI 에이전트 워크플로우의 문제점 중 하나: 취약성입니다. 단일 프로세스에 묶인 장시간 실행 멀티스텝 워크플로우는 프로세스 재시작 = 상태 손실을 의미합니다. 간단한 데모에는 괜찮습니다. 프로덕션 워크로드에는 그렇지 않습니다.

Microsoft Agent Framework의 워크플로우 프로그래밍 모델이 이제 Azure Functions 호스팅으로 Durable Task 프레임워크를 기반으로 한 지속적 실행을 지원합니다. 프로그래밍 모델이 어떻게 작동하는지, 그리고 내구성 이야기가 왜 중요한지 알아보겠습니다.

핵심 구성 요소

Executor는 작업의 기본 단위입니다. 각각은 타입이 지정되어 있어 특정 입력을 받아 특정 출력을 생성합니다:

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // 주문 조회, 반환
 return new Order(Id: message.OrderId, ...);
 }
}

Workflow는 Fluent 빌더를 사용해 executor를 방향 그래프로 연결합니다. 프레임워크가 실행, 단계 간 데이터 흐름, 오류 전파를 처리합니다.

모델링할 수 있는 것:

순차 체인 (단계 A → 단계 B → 단계 C)
병렬 Fan-out/Fan-in (에이전트 A, B, C를 병렬로 실행하고 결과 집계)
조건부 분기
Human-in-the-loop 승인 (워크플로우 일시 중지, 외부 신호 대기)

로컬 개발을 위한 In-Memory 러너

시작은 빠릅니다:

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

핵심 패키지에는 가벼운 인프로세스 러너가 포함되어 있습니다. 외부 종속성 없음, 데이터베이스 없음, Azure 리소스 없음. 로컬 개발과 단위 테스트에 완벽합니다.

Durable Task로 지속성 추가

워크플로우가 프로세스 재시작을 견뎌야 할 때 — 장시간 실행이기 때문에, human-in-the-loop 단계가 있기 때문에, 많은 병렬 에이전트 호출에 분산되기 때문에 — in-memory 러너로는 충분하지 않습니다.

MAF의 Durable Task 통합은 워크플로우 상태를 Azure Storage에 저장합니다. 프로세스가 재시작되면 워크플로우는 중단된 곳에서 재개됩니다. 프로그래밍 모델은 동일하게 유지됩니다. 러너만 교체하면 됩니다.

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

동일한 executor, 동일한 워크플로우 그래프 — 지속적인 상태로 지원됩니다.

Azure Functions 호스팅

세 번째 레이어는 Azure Functions 호스팅입니다. 워크플로우가 Function 앱이 됩니다. HTTP 엔드포인트를 통해 워크플로우를 트리거하고, 지속적 런타임이 확장, 상태, 안정성을 관리합니다.

이는 병렬 호출, 조건부 분기, 인간 승인을 포함하는 멀티에이전트 워크플로우가 사용자 정의 상태 관리 없이 서버리스 Functions 환경에서 확장될 수 있음을 의미합니다.

왜 이것이 중요한가

이 조합은 실제 AI 시스템에 중요합니다:

병렬 에이전트 호출 — 차단 없이 여러 전문 에이전트에 동시에 분산하고 모두 완료되면 결과 집계
장시간 실행 프로세스 — 인간 승인이나 외부 이벤트를 포함하는 워크플로우가 시간이나 일에 걸쳐 일시 중지하고 재개 가능
확장성 — Azure Functions가 실행을 수평 확장; Durable Task 프레임워크가 병렬 상태 조정 관리

간단한 로컬 데모를 넘어 MAF 워크플로우를 구축하고 있다면, 이것이 프로덕션 품질 실행으로 가는 길입니다.

원본 게시물: Durable Workflows in the Microsoft Agent Framework

고생하는 종속성을 계속 두드리지 마세요: Azure Functions + Service Bus의 재시도 패턴

Emiliano Montesdeoca — Thu, 21 May 2026 00:00:00 +0000

Functions 앱에서 복구 가능한 오류가 장애로 변하는 방식은 이렇습니다: 종속성이 타임아웃하기 시작하고, 모든 Functions 인스턴스가 즉시 무기한으로 재시도하고, 종속성은 수백 개의 동시 실패 요청으로 두드려 맞고, 일시적인 문제로 시작한 것이 시스템 전체 백프레셔 이벤트가 됩니다.

이 이야기를 알고 있을 것입니다. Azure Functions는 빠르게 스케일 아웃됩니다 — 그것이 핵심입니다. 그러나 “빠른 스케일 아웃"과 “즉각적인 재시도"가 함께하면 장애를 극적으로 악화시킬 수 있습니다.

두 가지 패턴이 도움이 됩니다. 지수 백오프와 서킷 브레이커. 둘 다 이제 Service Bus로 트리거되는 Azure Functions에서 기본 지원됩니다.

두 가지 패턴, 다른 역할

이 패턴들은 대안이 아닌 보완적입니다:

지수 백오프는 답합니다: 언제 다시 시도해야 하는가? 종속성이 복구할 시간을 확보하기 위해 재시도 사이의 지연을 증가시킵니다. 메시지 수준에서 재시도 타이밍을 조절합니다.

서킷 브레이커는 답합니다: 지금 이 종속성을 호출해야 하는가? 오류 임계값에 도달한 후 비정상적인 종속성에 대한 반복 호출을 중단하고, 쿨다운 기간 후 신중하게 탐색합니다. 시스템 수준에서 재시도 폭풍을 방지합니다.

둘 다 필요합니다. 백오프는 메시지별 재시도 페이싱을 처리합니다. 서킷 브레이커는 집계 상태 결정을 처리합니다.

Service Bus에 특히 중요한 이유

큐는 버스트 트래픽을 흡수합니다, 이는 좋은 일입니다. 그러나 제어 없이는 워커가 실패할 호출에 컴퓨팅 리소스를 계속 낭비하는 동안 큐가 증가할 수 있습니다. 포이즌 메시지가 있어야 할 시간보다 더 오래 활성 상태를 유지합니다. 핫 파티션이나 제한된 다운스트림 용량이 계단식 문제를 일으킵니다.

더 안전한 설계:

일시적인 오류 감지
지수 백오프로 다음 시도 지연
오류 임계값에 도달하면 종속성 호출 중단 (서킷 오픈)
쿨다운 기간 후 신중하게 재개 (서킷 탐색)
복구 불가능한 작업을 dead-letter 또는 격리 경로로 이동

네이티브 지원의 모습

새로운 지원은 기존 Azure Functions 호스트 모델과 통합됩니다 — 추가 라이브러리 없음, 사용자 정의 구현 없음. 구성은 host.json에 들어갑니다:

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

서킷 브레이커 구성은 비정상 종속성이 복구 중에 두드려 맞지 않도록 오류 임계값과 재설정 간격을 설정합니다.

지원되는 언어

.NET만을 위한 것이 아닙니다. 이 기능은 dotnet, JavaScript, TypeScript, Python을 포함합니다 — Azure Functions의 Service Bus 트리거에서 지원되는 전체 언어 세트입니다.

마무리

재시도 패턴은 다운스트림 장애가 Functions를 우아하게 저하되는 대신 문제를 악화시키는 첫 번째 사태가 발생할 때까지 설정하기에 흥미롭지 않습니다. 이를 사전에 설정하는 것은 저렴합니다. 인시던트 중에 개조하는 것은 그렇지 않습니다.

원본 게시물: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

Azure Functions의 MCP 서버를 Foundry 에이전트에 연결하는 방법

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

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

MCP 생태계에서 제가 좋아하는 점이 있습니다: 서버를 한 번 구축하면 어디서나 작동한다는 것입니다. VS Code, Visual Studio, Cursor, ChatGPT — 모든 MCP 클라이언트가 여러분의 도구를 발견하고 사용할 수 있습니다. 이제 Microsoft가 그 목록에 또 다른 소비자를 추가하고 있습니다: Foundry 에이전트입니다.

Azure SDK 팀의 Lily Ma가 Azure Functions에 배포된 MCP 서버를 Microsoft Foundry 에이전트에 연결하는 실용 가이드를 발표했습니다. 이미 MCP 서버가 있다면 순수한 부가가치입니다 — 재구축이 필요 없습니다.

이 조합이 합리적인 이유

Azure Functions는 MCP 서버 호스팅을 위한 확장 가능한 인프라, 기본 제공 인증, 서버리스 과금을 제공합니다. Microsoft Foundry는 추론하고, 계획하고, 행동할 수 있는 AI 에이전트를 제공합니다. 둘을 연결하면 커스텀 도구 — 데이터베이스 쿼리, 비즈니스 API 호출, 검증 로직 실행 — 가 엔터프라이즈 AI 에이전트가 자율적으로 발견하고 사용할 수 있는 기능이 됩니다.

핵심 포인트: MCP 서버는 그대로 유지됩니다. Foundry를 또 다른 소비자로 추가하는 것뿐입니다. VS Code 설정에서 작동하는 동일한 도구가 이제 팀이나 고객이 상호작용하는 AI 에이전트를 구동합니다.

인증 옵션

여기서 이 글이 진정한 가치를 제공합니다. 시나리오에 따른 네 가지 인증 방법:

방법	사용 사례
키 기반 (기본)	개발 또는 Entra 인증 없는 서버
Microsoft Entra	관리 ID를 사용한 프로덕션
OAuth 아이덴티티 패스스루	각 사용자가 개별 인증하는 프로덕션
인증 없음	개발/테스트 또는 공개 데이터만

프로덕션에서는 에이전트 ID를 사용한 Microsoft Entra가 권장 경로입니다. OAuth 아이덴티티 패스스루는 사용자 컨텍스트가 중요할 때 사용합니다 — 에이전트가 사용자에게 로그인을 요청하고, 각 요청이 사용자 자신의 토큰을 전달합니다.

설정하기

대략적인 흐름:

MCP 서버를 Azure Functions에 배포 — .NET, Python, TypeScript, Java 샘플 제공
함수 앱에서 기본 제공 MCP 인증 활성화
엔드포인트 URL 가져오기 — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Foundry에 MCP 서버를 도구로 추가 — 포털에서 에이전트로 이동, 새 MCP 도구 추가, 엔드포인트와 자격 증명 제공

그런 다음 Agent Builder 플레이그라운드에서 도구 중 하나를 트리거할 프롬프트를 보내 테스트합니다.

제 의견

여기서의 조합성 이야기는 정말 강력해지고 있습니다. .NET(또는 Python, TypeScript, Java)으로 MCP 서버를 한 번 구축하고, Azure Functions에 배포하면, 모든 MCP 호환 클라이언트가 사용할 수 있습니다 — 코딩 도구, 채팅 앱, 그리고 이제 엔터프라이즈 AI 에이전트. 실제로 작동하는 “한 번 작성, 어디서나 사용” 패턴입니다.

특히 .NET 개발자에게 Azure Functions MCP 확장이 이를 간단하게 만들어줍니다. 도구를 Azure Functions로 정의하고, 배포하면, Azure Functions가 제공하는 모든 보안과 확장성을 갖춘 프로덕션 등급의 MCP 서버를 갖게 됩니다.

마무리

Azure Functions에서 MCP 도구를 실행하고 있다면, Foundry 에이전트에 연결하는 것은 빠른 성과입니다 — 커스텀 도구가 적절한 인증을 갖춘 엔터프라이즈 AI 기능이 되며, 서버 자체의 코드 변경은 없습니다.

각 인증 방법에 대한 단계별 안내는 전체 가이드를, 프로덕션 설정에 대해서는 상세 문서를 확인하세요.

MCP Apps에 Fluent API 도입 — .NET에서 3단계로 풍부한 AI 도구 UI 구축

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

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

MCP 도구는 AI 에이전트에게 기능을 부여하는 데 훌륭합니다. 하지만 도구가 사용자에게 무언가를 보여줘야 한다면요? 대시보드, 폼, 인터랙티브 시각화 같은 것들이요. 바로 여기서 MCP Apps가 등장하며, 이제 훨씬 더 쉽게 만들 수 있게 되었습니다.

Azure SDK 팀의 Lilian Kasem이 .NET Azure Functions의 MCP Apps를 위한 새로운 Fluent 구성 API를 발표했습니다. 왜 처음부터 이렇게 간단하지 않았을까 싶은 그런 개발자 경험 개선입니다.

MCP Apps란?

MCP Apps는 Model Context Protocol을 확장하여 도구가 자체 UI 뷰, 정적 에셋, 보안 제어를 가질 수 있게 합니다. 단순히 텍스트를 반환하는 대신 MCP 도구가 완전한 HTML 경험을 렌더링할 수 있습니다 — 인터랙티브 대시보드, 데이터 시각화, 구성 폼 — 모두 AI 에이전트가 호출 가능하고 MCP 클라이언트를 통해 사용자에게 표시됩니다.

문제는 이 모든 것을 수동으로 연결하려면 MCP 스펙을 깊이 이해해야 했다는 것입니다: ui:// URI, 특수 MIME 타입, 도구와 리소스 간의 메타데이터 조정. 어렵지는 않지만 번거로웠습니다.

Fluent API 3단계

1단계: 함수를 정의합니다. 표준 Azure Functions MCP 도구:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

2단계: MCP App으로 승격시킵니다. 프로그램 시작 시:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

3단계: HTML 뷰를 추가합니다. 필요한 UI로 assets/hello-app.html을 생성합니다.

끝입니다. Fluent API가 MCP 프로토콜의 모든 배관 작업을 처리합니다 — 합성 리소스 함수 생성, 올바른 MIME 타입 설정, 도구와 뷰를 연결하는 메타데이터 주입.

API 설계가 훌륭합니다

특히 마음에 드는 점 몇 가지:

뷰 소스가 유연합니다. 디스크의 파일에서 HTML을 제공하거나, 독립 배포를 위해 리소스를 어셈블리에 직접 포함할 수 있습니다:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP가 조합 가능합니다. 최소 권한 원칙에 따라 앱에 필요한 출처를 명시적으로 허용합니다. WithCsp를 여러 번 호출하면 출처가 누적됩니다:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

가시성 제어. 도구를 LLM에만 표시, 호스트 UI에만 표시, 또는 둘 다에 표시할 수 있습니다. UI만 렌더링하고 모델에서 호출되지 않아야 하는 도구를 원하시나요? 간단합니다:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

시작하기

프리뷰 패키지를 추가합니다:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

이미 Azure Functions로 MCP 도구를 만들고 있다면 패키지 업데이트만 하면 됩니다. 개념이 처음이라면 MCP Apps 빠른 시작이 가장 좋은 출발점입니다.

마무리

MCP Apps는 AI 도구 분야에서 가장 흥미로운 발전 중 하나입니다 — 단순히 무언가를 하는 것이 아니라 사용자에게 무언가를 보여줄 수 있는 도구. Fluent API는 프로토콜 복잡성을 제거하고 중요한 것에 집중하게 해줍니다: 도구의 로직과 UI.

완전한 API 리퍼런스와 예제는 전체 게시물을 읽어보세요.