Agent-Framework | The .NET Blog

Microsoft Foundry 2026년 4월: Foundry Local GA, GPT-5.5, Hyperlight를 통한 CodeAct

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

Microsoft Foundry에게 바쁜 달이었습니다. 가장 중요한 발표들을 소개합니다.

Foundry Local이 일반 출시됨

Foundry Local — Microsoft의 크로스플랫폼 로컬 AI 런타임 — 이 Windows, macOS (Apple Silicon) 및 Linux x64에서 미리 보기에서 GA로 전환됩니다. 개발자 친화적인 SDK를 갖춘 프로덕션 준비 로컬 모델 추론입니다. 버전 1.1에서는 전사, embeddings 및 Responses API 지원이 추가됩니다.

GPT-5.5

GPT-5 패밀리의 최신 모델이 이제 Foundry에서 사용 가능합니다. Tier 5 및 Tier 6 구독의 기본 할당량. 이전 GPT-5 변형으로 작업해왔다면 사용 사례에 맞게 평가해볼 가치가 있습니다.

Foundry에서의 Agent Framework 추적

이번 달 두 가지 추적 기능이 미리 보기로 제공됩니다:

Microsoft Agent Framework 추적 — MAF 에이전트가 이제 Foundry에 OpenTelemetry 추적을 내보낼 수 있습니다. 에이전트 동작을 디버그하고, 다단계 실행을 추적하고, 도구 호출 전반의 지연 및 오류를 표면화합니다. 이것은 실제 격차를 채웁니다: 반환한 것뿐만 아니라 에이전트가 프로덕션에서 실제로 무엇을 했는지 알기.

호스팅된 에이전트 추적 — 호스팅된 에이전트의 세션, 도구 호출 및 실행 단계도 Foundry 추적에 나타납니다. 동일한 관찰 가능성 스토리가 호스팅 계층으로 확장됩니다.

Hyperlight를 통한 CodeAct (Alpha)

이것이 기술적으로 가장 흥미로운 추가 기능입니다: Agent Framework가 이제 Hyperlight 마이크로 가상 머신 내에서 Python 코드를 실행할 수 있습니다.

CodeAct는 에이전트가 도구로 Python 코드를 생성하고 실행하는 패턴입니다. 명백한 우려는 보안 — 모델이 생성한 코드를 실행하고 있습니다. Hyperlight의 마이크로 VM은 네이티브에 가까운 시작 시간으로 프로세스 수준의 격리를 제공하여, 전체 컨테이너나 VM의 오버헤드 없이 샌드박스 코드 실행을 실용적으로 만듭니다.

코드 실행이 필요한 에이전트 워크플로우에서 이것은 호스트 프로세스에서 코드를 실행하는 것보다 상당한 보안 개선입니다.

에이전트 모니터링 대시보드 (미리 보기)

토큰 사용량, 지연, 실행 성공률 및 평가자 점수를 한 뷰에 결합한 통합 운영 대시보드. 일반 관찰 가능성 대시보드와의 차이점: 운영 메트릭과 함께 평가 결과가 포함되어 “에이전트가 더 느려졌다"를 “평가자 점수가 하락했다"와 상관시키거나 관련이 없음을 확인할 수 있습니다.

지속적 평가 커스텀 평가자 (미리 보기)

이제 지속적 평가 파이프라인에 자체 코드 기반 또는 프롬프트 기반 평가자를 가져올 수 있습니다. 이전에는 지속적 평가가 내장 평가자로 제한되었습니다. 커스텀 평가자를 사용하면 프로덕션 모니터링 루프에서 팀별 품질 기준을 적용할 수 있습니다.

제어 플레인의 에이전트 인벤토리

Foundry 제어 플레인 Operate 뷰에서 이제 구독 전체의 모든 지원되는 에이전트가 표시됩니다: Foundry 에이전트, Azure SRE Agent, Logic Apps 에이전트 루프 및 등록된 커스텀 에이전트. 무엇이 어디에 배포되어 있는지 이해하기 위한 하나의 뷰.

원본 게시물: What’s new in Microsoft Foundry | April 2026

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

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

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

로컬 MAF 에이전트가 드디어 프로덕션에 자리를 잡았습니다

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

에이전트를 로컬에서 작동시키는 것은 재미있는 부분입니다. 어려운 부분은 그 이후의 모든 것입니다: 정신을 잃지 않고 배포하기, 세션 관리, ID 설정, 관찰성 연결. 보통 이는 많은 커스텀 인프라 연결 작업을 의미합니다.

Foundry Hosted Agents는 Microsoft Agent Framework (MAF) 사용자를 위해 그러한 연결 작업의 대부분을 제거했습니다.

Foundry Hosted Agents가 실제로 하는 것

MAF 에이전트를 Foundry Hosted Agents에 배포하면, 플랫폼이 직접 만들어야 했을 놀랍도록 긴 목록의 것들을 처리합니다:

제로로 스케일 — 에이전트가 유휴 상태일 때 비용이 들지 않고 자동으로 재시작됩니다
세션당 VM 격리 샌드박스 — 각 사용자 세션은 스케일 다운 이벤트를 견디는 파일시스템 지속성을 가진 자체 샌드박스를 얻습니다
내장 Entra ID — 각 에이전트는 이미지에 시크릿 없이 Foundry 모델, Toolbox, Azure 서비스를 호출할 수 있는 자체 ID를 얻습니다
버전이 지정된 배포 — 각 배포는 불변 스냅샷으로, blue/green 및 카나리 롤아웃 지원이 있습니다
설정 없는 관찰성 — APPLICATIONINSIGHTS_CONNECTION_STRING이 런타임에 주입되어 MAF의 OpenTelemetry 트레이스가 App Insights로 자동으로 흐릅니다

마지막은 정말 편리합니다. 추가 배선 없음, 추가 설정 없음. 트레이스가 그냥 나타납니다.

코드 차이는 최소

이 통합에서 가장 마음에 드는 부분입니다. 에이전트를 다시 작성할 필요가 없습니다. 그냥 래핑하면 됩니다:

.NET의 경우:

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

Python의 경우:

server = ResponsesHostServer(agent)
server.run()

그게 다입니다. 로컬에서 테스트한 것과 동일한 로직이 프로덕션에서 실행됩니다. 플랫폼은 세션 관리, ID, 스케일링 인프라로 이를 래핑합니다.

두 가지 프로토콜, 하나의 에이전트

Hosted Agents는 두 가지 엔드포인트 스타일을 지원합니다:

Responses (/responses) — OpenAI 호환, 대화 기록과 스트리밍을 관리합니다. 채팅 형태의 에이전트에 좋은 기본값.
Invocations (/invocations) — 요청/응답 스키마를 직접 정의합니다. 비대화적 워크플로우에 적합.

대화처럼 보이는 것을 만들고 있다면 Responses로 시작하세요. 구조화된 입력을 받아 구조화된 출력을 반환하는 API 형태의 에이전트를 만들고 있다면 Invocations가 유연성을 제공합니다.

`azd`를 사용한 배포 흐름

MAF 에이전트로 azd up을 실행하면:

선택적으로 Foundry 프로젝트를 생성하고 모델을 배포
코드를 패키징하고 Azure Container Registry에 이미지를 푸시
ACR 이미지에서 컴퓨팅 프로비저닝
에이전트에 전용 Entra ID 할당
안정적인 엔드포인트 노출 (https://{project_endpoint}/agents/{agent_name})
그 이후 모든 것을 처리

세션은 최대 30일 동안 지속됩니다. 유휴 컴퓨팅은 15분 후 디프로비저닝되고 다음 요청 시 투명하게 복원됩니다. 에이전트 입장에서는 아무것도 변하지 않았습니다.

마무리

“로컬에서 작동"에서 “프로덕션에서 실행"까지의 거리는 AI 에이전트에게 역사적으로 길고 고통스러웠습니다. Foundry Hosted Agents + MAF는 그 격차를 크게 줄입니다. Agent Framework로 구축된 로컬 에이전트가 이미 있다면 오늘 시도해볼 만합니다.

팀은 GA가 곧 온다고 합니다 — 현재 프리뷰 중입니다. 시작하려면 MAF Hosted Agent 통합 문서와 .NET 샘플을 확인하세요.

원본 게시물: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

에이전트를 만드는 건 쉬운 부분 — 안전하게 실행하는 게 어려운 부분

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

AI 에이전트 개발에서 “데모 후회"라고 부르기 시작한 패턴이 있습니다. 에이전트는 데모에서 완벽하게 작동합니다. 그런 다음 누군가가 묻습니다: 잘못된 도구를 호출하면 어떻게 되나요? 접근하면 안 되는 데이터에 접근한다면? 누가 감사했나요?

Microsoft Agent Framework는 구축과 오케스트레이션을 지원합니다. Agent Governance Toolkit(AGT)은 그 이후 부분을 담당합니다 — 거버넌스, 정책 적용, 런타임 감사 가능성.

각 프로젝트가 실제로 하는 것

**Microsoft Agent Framework (MAF)**는 프로그래밍 모델을 제공합니다: 멀티 에이전트 워크플로우, A2A 프로토콜 상호 운용성, 미들웨어 훅, 메모리, Foundry Agent Service를 통한 관리형 호스팅. 모델 입출력 레벨에서 콘텐츠 안전성을 처리합니다.

**Agent Governance Toolkit (AGT)**는 동일한 미들웨어 파이프라인에 연결되어 액션을 제어합니다. 모든 도구 호출, 리소스 접근, 에이전트 간 메시지가 실행 전에 정책에 대해 평가됩니다. 서브밀리초 오버헤드. 사이드카 없음, 프록시 없음, 수정된 프롬프트 없음.

에이전트 액션 --> 정책 검사 --> 허용 / 거부 --> 감사 로그 (< 0.1 ms)

서로 다른 레이어, 완전한 커버리지, 하나의 파이프라인.

연결은 미들웨어 추가만 하면 됩니다

Python에서 AGT는 로깅이나 콘텐츠 필터에 사용하는 것과 동일한 middleware 매개변수에 추가됩니다:

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

.NET에서는 .Use()를 통해 같은 패턴:

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

같은 에이전트, 같은 오케스트레이션, 같은 도구. AGT는 에이전트 로직을 건드리지 않고 거버넌스 기능을 추가합니다.

무엇을 얻나요

GovernancePolicyMiddleware — 선언적 정책 규칙에 대해 모든 액션 평가
CapabilityGuardMiddleware — 에이전트가 호출 가능한 도구의 허용 목록(approve_small_loan 도구는 위 허용 목록에 의도적으로 없음)
RogueDetectionMiddleware — 런타임에서 비정상적인 동작 패턴 감지
AuditTrailMiddleware — 모든 액션을 암호학적으로 변조 방지하는 Merkle 체인 감사 로그

마지막 것은 규정 준수에 중요합니다. Merkle 체인은 누군가 로그를 수정하면 체인이 끊긴다는 것을 의미합니다. 감사가 증거입니다.

다섯 가지 산업 시나리오

AGT 저장소에는 5개의 완전한 엔드투엔드 시나리오가 포함되어 있습니다: 금융 서비스(대출 담당자), 의료(환자 데이터), 법률(계약 검토), 정부(시민 서비스), 제조(품질 관리). 각각은 실제 MAF 에이전트와 실제 AGT 거버넌스 미들웨어를 결합합니다.

장난감 데모가 아닙니다. 실제로 프로덕션에서 거버넌스가 필요한 시나리오입니다.

결론

실제 데이터를 다루거나, 결과를 수반하는 결정을 내리거나, 프로덕션에서 무인으로 실행되는 에이전트를 구축하고 있다면 — 거버넌스는 선택 사항이 아닙니다. MAF + AGT의 조합이 전체 스택을 제공합니다: Agent Framework로 구축하고, AGT로 관리하세요.

두 프로젝트 모두 오픈 소스입니다. 원본 문서에는 전체 코드 샘플 링크가 있습니다.

원본 게시글: Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

A2A v1 출시: Microsoft Agent Framework for .NET의 크로스플랫폼 에이전트 통신

Emiliano Montesdeoca — Mon, 04 May 2026 00:00:00 +0000

이 게시물은 자동으로 번역되었습니다. 원본 버전은 여기를 클릭하세요.

A2A v1 출시: Microsoft Agent Framework for .NET의 크로스플랫폼 에이전트 통신 — A2A 프로토콜이 v1.0에 도달했으며, .NET용 A2A Agent(클라이언트)와 A2A Hosting(서버) 패키지가 모두 업데이트되었습니다.

A2A v1이 실제로 무엇인가

A2A는 AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, ServiceNow의 대표자들로 구성된 기술 운영 위원회가 지원하는 AI 에이전트를 위한 오픈 상호운용 프로토콜입니다. v1 레이블은 이제 안정적이고 프로덕션 준비가 된 표준임을 의미합니다. 이를 구현하는 SDK 및 Agent Framework 패키지는 아직 프리뷰 상태이지만, 프로토콜 자체는 확정되었습니다.

v1은 멀티 테넌시 지원, 암호화 ID를 위한 서명된 Agent Cards, 개선된 보안 흐름, 웹 정렬 아키텍처로 v0.3을 개선합니다.

원격 A2A 에이전트에 연결하기

원격 A2A 에이전트는 코드에서 단순히 AIAgent입니다 — 동일한 RunAsync, 동일한 스트리밍, 동일한 세션 처리:

// Well-known URI를 통한 검색
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = await resolver.GetAIAgentAsync();
Console.WriteLine(await agent.RunAsync("What's the weather in Seattle?"));

// 직접 구성
A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(name: "my-agent", description: "A helpful assistant.");

// 스트리밍도 동일하게 작동
await foreach (var update in agent.RunStreamingAsync("Write a short summary..."))
 Console.Write(update.Text);

에이전트를 A2A 엔드포인트로 노출하기

Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic 또는 AWS Bedrock에서 구축한 모든 AIAgent를 ASP.NET Core에서 두 줄로 A2A 엔드포인트로 노출할 수 있습니다:

builder.Services.AddKeyedSingleton<AIAgent>("weather-agent", (sp, _) => ...);
builder.AddA2AServer("weather-agent");

에이전트 카드는 /.well-known/agent-card.json에서 자동으로 제공됩니다.

실제로 이것이 의미하는 바

안정적인 v1 프로토콜은 파괴적 변경에 대한 걱정 없이 .NET 에이전트를 Python, Java 또는 다른 언어로 구축된 에이전트와 연결할 수 있음을 의미합니다. 서명된 Agent Cards의 암호화 ID는 에이전트 간 신뢰 검증의 기반도 제공합니다.

전체 변경 로그와 v0.3에서의 마이그레이션 노트는 전체 게시물을 참조하세요.

Agent Framework의 CodeAct: 에이전트 지연 시간을 절반으로 줄이는 방법

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

이 게시물은 자동으로 번역되었습니다. 원본 버전은 여기를 클릭하세요.

모든 에이전트 프로젝트에서 트레이스를 보며 “왜 이렇게 오래 걸리는 거야?“라고 생각하는 순간이 있습니다. 모델은 괜찮고, 도구도 작동합니다. 하지만 한 번에 계산할 수 있는 결과를 위해 일곱 번의 왕복이 발생합니다.

이것이 바로 CodeAct가 해결하는 문제입니다. Agent Framework 팀이 새 agent-framework-hyperlight 패키지를 통해 알파 지원을 출시했습니다.

CodeAct란?

CodeAct 패턴은 우아하게 단순합니다. 모델에 도구 목록을 주고 하나씩 호출하게 하는 대신, 단일 execute_code 도구를 주고 전체 계획을 짧은 Python 프로그램으로 표현하게 합니다.

방식	시간	토큰
기존 방식	27.81초	6,890
CodeAct	13.23초	2,489
개선	52.4%	63.9%

보안: Hyperlight 마이크로 VM

agent-framework-hyperlight 패키지는 Hyperlight 마이크로 VM을 사용합니다. 각 execute_code 호출은 자체 새로운 마이크로 VM을 받습니다. 시작 시간은 밀리초 단위입니다. 격리는 사실상 무료입니다.

도구는 계속 호스트에서 실행됩니다. 모델이 생성한 글루 코드는 샌드박스에서 실행됩니다. 올바른 분리입니다.

최소 설정

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

CodeAct 사용 시기 (그리고 사용하지 않을 때)

CodeAct를 사용하는 경우:

많은 소규모 도구 호출을 연결하는 작업 (조회, 조인, 계산)
지연 시간과 토큰 비용이 중요한 경우
모델 생성 코드에 강력한 격리가 필요한 경우

기존 도구 호출을 사용하는 경우:

에이전트가 턴당 한두 번만 도구를 호출하는 경우
각 호출에 개별 승인이 필요한 부작용이 있는 경우
도구 설명이 부족하거나 모호한 경우

지금 시도해보세요

pip install agent-framework-hyperlight --pre

Agent Framework 블로그의 전체 게시물에서 심층적인 내용을 확인하세요.

GPT-5.5가 Azure Foundry에 출시됐다 — .NET 개발자가 알아야 할 것들

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

이 게시물은 자동 번역되었습니다. 원문을 보려면 여기를 클릭하세요.

Microsoft가 GPT-5.5가 Microsoft Foundry에서 일반 출시됐다고 발표했습니다. Azure에서 에이전트를 구축해 왔다면, 이것이 기다리던 업데이트입니다.

GPT-5 발전 과정

GPT-5: 추론과 속도를 단일 시스템으로 통합
GPT-5.4: 더 강력한 다단계 추론, 기업용 초기 에이전트 기능
GPT-5.5: 더 깊은 장문맥 추론, 더 신뢰할 수 있는 에이전트 실행, 향상된 토큰 효율성

실제로 무엇이 바뀌었나

향상된 에이전트 코딩: GPT-5.5는 대규모 코드베이스 전체에서 컨텍스트를 유지하고, 아키텍처 수준 오류를 진단하며, 테스트 요구사항을 예측합니다. 수정이 다른 무엇에 영향을 미치는지 행동 전에 추론합니다.

토큰 효율성: 더 적은 토큰과 더 적은 재시도로 더 높은 품질의 출력. 프로덕션 배포에서 비용과 지연이 직접 감소합니다.

가격

모델	입력 ($/M tokens)	캐시 입력	출력 ($/M tokens)
GPT-5.5	$5.00	$0.50	$30.00
GPT-5.5 Pro	$30.00	$3.00	$180.00

Foundry가 중요한 이유

Foundry Agent Service를 사용하면 YAML로 에이전트를 정의하거나 Microsoft Agent Framework, GitHub Copilot SDK, LangGraph 또는 OpenAI Agents SDK와 연결할 수 있습니다. 영구 파일시스템, 별도의 Microsoft Entra 아이덴티티, 제로 스케일 가격으로 격리된 호스팅 에이전트로 실행합니다.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "당신은 유용한 어시스턴트입니다.", name: "내에이전트");

전체 발표를 확인하세요.

당신의 에이전트는 어디서 기억하나요? 채팅 기록 저장소 실용 가이드

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

이 게시물은 자동 번역되었습니다. 원문을 보려면 여기를 클릭하세요.

AI 에이전트를 구축할 때 대부분의 에너지를 모델, 도구, 프롬프트에 씁니다. 대화 기록이 어디에 저장되는가라는 질문은 구현 세부사항처럼 보이지만, 실제로 가장 중요한 아키텍처 결정 중 하나입니다.

이 결정은 사용자가 대화를 분기할 수 있는지, 응답을 취소할 수 있는지, 재시작 후 세션을 재개할 수 있는지, 그리고 데이터가 인프라를 벗어나는지를 결정합니다. Agent Framework 팀이 심층 분석을 공개했습니다.

두 가지 기본 패턴

서비스 관리형: AI 서비스가 대화 상태를 저장합니다. 앱은 참조를 유지하고 서비스가 각 요청에 관련 기록을 자동으로 포함시킵니다.

클라이언트 관리형: 앱이 전체 기록을 유지하고 각 요청마다 관련 메시지를 보냅니다. 서비스는 무상태입니다. 모든 것을 제어합니다.

Agent Framework의 추상화 방식

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("내 이름은 Alice입니다.", session);
var second = await agent.RunAsync("내 이름이 뭔가요?", session);

session = agent.create_session()
first = await agent.run("내 이름은 Alice입니다.", session=session)
second = await agent.run("내 이름이 뭔가요?", session=session)

공급자 빠른 참조

공급자	저장 위치	모델	압축
OpenAI/Azure Chat Completions	클라이언트	N/A	당신
Foundry Agent Service	서비스	선형	서비스
Responses API (기본값)	서비스	분기형	서비스
Anthropic Claude, Ollama	클라이언트	N/A	당신

선택 방법

분기 또는 “취소” 기능이 필요한가? → 서비스 관리형 Responses API
데이터 주권이 필요한가? → 데이터베이스 백엔드가 있는 클라이언트 관리형
단순 챗봇인가? → 서비스 관리형 선형으로 충분

전체 의사결정 트리를 보려면 전체 게시물을 읽어보세요.

.NET의 Agent Skills가 정말 유연해졌다

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

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

Microsoft Agent Framework로 에이전트를 구축해왔다면 흐름은 알고 있을 겁니다: 스킬을 정의하고, provider에 연결하고, 에이전트가 어떤 것을 호출할지 결정하게 합니다. 새로운 것은 스킬을 만드는 방법이고, 유연성의 향상이 상당합니다.

최신 업데이트는 에이전트 스킬에 대한 세 가지 작성 패턴을 도입합니다: 파일 기반, 클래스 기반, 인라인 코드 정의. 세 가지 모두 단일 AgentSkillsProviderBuilder에 연결되므로 라우팅 로직이나 특별한 접착 코드 없이 자유롭게 조합할 수 있습니다. 각 패턴과 언제 사용해야 하는지 설명하겠습니다.

파일 기반 스킬: 시작점

파일 기반 스킬은 말 그대로입니다 — SKILL.md 파일, 선택적 스크립트, 참조 문서가 있는 디스크의 디렉토리입니다. 에이전트에 새로운 기능을 부여하는 가장 직접적인 방법입니다:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

SKILL.md의 프론트매터에서 스킬 이름과 설명을 선언하고, 지시 섹션에서 에이전트에게 스크립트와 참조를 어떻게 사용하는지 알려줍니다:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

그런 다음 SubprocessScriptRunner.RunAsync로 스크립트 실행을 연결합니다:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

에이전트는 자동으로 스킬을 발견하고 계정 상태를 확인해야 할 때 프로비저닝 스크립트를 호출합니다. 깔끔하고 간단합니다.

클래스 기반 스킬: NuGet으로 배포

여기서 팀에게 흥미로워집니다. 클래스 기반 스킬은 AgentClassSkill<T>에서 파생하며 [AgentSkillResource]와 [AgentSkillScript] 같은 속성을 사용하여 프레임워크가 리플렉션을 통해 모든 것을 발견합니다:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

멋진 점은 팀이 이것을 NuGet 패키지로 패키징할 수 있다는 것입니다. 프로젝트에 추가하고, 빌더에 넣으면 파일 기반 스킬과 함께 조율 없이 동작합니다:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

두 스킬 모두 에이전트의 시스템 프롬프트에 나타납니다. 에이전트가 대화에 따라 어떤 것을 사용할지 결정합니다 — 라우팅 코드가 필요 없습니다.

인라인 스킬: 빠른 브릿지

다른 팀이 정확히 필요한 스킬을 만들고 있는데 다음 스프린트까지 완성되지 않는 그 순간 아시죠? AgentInlineSkill이 당신의 브릿지입니다:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

다른 것들처럼 빌더에 추가합니다:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

NuGet 패키지가 최종 출시되면 인라인 스킬을 클래스 기반 버전으로 교체하면 됩니다. 에이전트는 차이를 모릅니다.

하지만 인라인 스킬은 브릿지만을 위한 것이 아닙니다. 런타임에 동적으로 스킬을 생성해야 할 때 — 구성에서 로드되는 비즈니스 유닛별 스킬을 생각해보세요 — 또는 스크립트가 DI 컨테이너에 속하지 않는 로컬 상태를 캡처해야 할 때도 올바른 선택입니다.

스크립트 승인: 휴먼 인 더 루프

프로덕션 에이전트를 구축하는 .NET 개발자로서 이 부분이 배포 논의를 정말로 열어줍니다. 일부 스크립트에는 실제 결과가 있습니다 — 누군가를 복리후생에 등록하거나 프로덕션 인프라를 조회하는 것. UseScriptApproval을 활성화하면 에이전트가 스크립트 실행 전에 일시 중지합니다:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

에이전트가 스크립트를 실행하려 할 때, 대신 승인 요청을 반환합니다. 앱이 결정을 수집하고 — 승인 또는 거부 — 에이전트가 그에 따라 계속합니다. 규제 환경에서는 “이것을 배포할 수 있다"와 “법무팀이 안 된다고 했다” 사이의 차이입니다.

왜 이 조합이 중요한가

진정한 힘은 개별 패턴이 아니라 구성에 있습니다. 다음이 가능합니다:

파일 기반 스킬로 작게 시작하고, 지시를 반복하고, C#을 작성하지 않고도 게시
다른 팀이 한 줄로 추가할 수 있는 NuGet 패키지로 재사용 가능한 스킬을 배포
지금 필요한 것이 있을 때 인라인 스킬로 격차를 메움
에이전트가 로드해야 할 것만 로드하도록 프레디케이트로 공유 디렉토리를 필터링
프로덕션 시스템을 건드리는 스크립트에 인간 감독을 추가

이 모든 것이 AgentSkillsProviderBuilder를 통해 구성됩니다. 특별한 라우팅 없이, 조건 로직 없이, 스킬 타입 체크 없이.

마무리

.NET의 에이전트 스킬은 이제 진정으로 유연한 작성 모델을 갖추었습니다. 파일 기반 스킬로 프로토타이핑하는 솔로 개발자이든 NuGet을 통해 패키지된 기능을 배포하는 엔터프라이즈 팀이든 패턴이 맞습니다. 그리고 스크립트 승인 메커니즘이 인간 체크포인트가 필요한 환경에서 프로덕션 준비를 가능하게 합니다.

원본 발표, Microsoft Learn의 Agent Skills 문서, GitHub의 .NET 샘플을 확인하고 시작하세요.

블랙박스처럼 느껴지지 않는 실시간 멀티 에이전트 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로 오늘 바로 시작할 수 있습니다. 빠른 시작 가이드와 샘플을 확인해서 직접 경험해 보세요.

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

Microsoft Agent Framework의 백그라운드 응답: 더 이상 타임아웃 걱정 없이

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

o3나 GPT-5.2 같은 추론 모델로 무언가를 만들어 본 적이 있다면, 그 고통을 알 것입니다. 에이전트가 복잡한 작업을 생각하기 시작하고, 클라이언트는 기다리고, “괜찮아"와 “크래시한 건가?” 사이 어딘가에서 연결이 타임아웃됩니다. 그 모든 작업은? 사라집니다.

Microsoft Agent Framework가 백그라운드 응답을 출시했습니다 — 솔직히, 이건 처음부터 있었어야 할 기능 중 하나입니다.

블로킹 호출의 문제

전통적인 요청-응답 패턴에서는 에이전트가 끝날 때까지 클라이언트가 블로킹됩니다. 빠른 작업에는 잘 작동합니다. 하지만 추론 모델에 깊은 연구, 다단계 분석, 20페이지 보고서 생성을 요청하면? 실제 시간으로 몇 분이 걸립니다. 그 시간 동안:

HTTP 연결이 타임아웃될 수 있음
네트워크 끊김이 전체 작업을 죽임
사용자는 스피너를 보며 무슨 일이 일어나고 있는지 궁금해 함

백그라운드 응답은 이것을 뒤집습니다.

연속 토큰의 작동 방식

블로킹 대신, 에이전트 작업을 시작하고 연속 토큰을 받습니다. 수리점의 픽업 티켓처럼 생각하세요 — 카운터에서 서서 기다릴 필요 없이, 준비되면 돌아오면 됩니다.

흐름은 간단합니다:

AllowBackgroundResponses = true로 요청 전송
에이전트가 백그라운드 처리를 지원하면 연속 토큰을 받음
토큰이 null을 반환할 때까지 폴링 — 결과가 준비되었다는 의미

.NET 버전은 다음과 같습니다:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// 완료까지 폴링
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

에이전트가 즉시 완료하면(간단한 작업, 백그라운드 처리가 필요 없는 모델), 연속 토큰이 반환되지 않습니다. 코드는 그냥 작동합니다 — 특별한 처리가 필요 없습니다.

재개가 가능한 스트리밍: 진짜 마법

폴링은 fire-and-forget 시나리오에 괜찮지만, 실시간 진행 상황을 원한다면? 백그라운드 응답은 내장 재개 기능이 있는 스트리밍도 지원합니다.

각 스트리밍 업데이트는 자체 연속 토큰을 가집니다. 스트리밍 중에 연결이 끊기면, 중단된 정확한 지점에서 재개합니다:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // 네트워크 중단 시뮬레이션
}

// 중단된 정확한 지점에서 재개
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

클라이언트에 무슨 일이 일어나든 에이전트는 서버 측에서 계속 처리합니다. 재시도 로직이나 서킷 브레이커를 작성하지 않고도 내장된 장애 허용입니다.

언제 실제로 사용해야 하나

모든 에이전트 호출에 백그라운드 응답이 필요한 것은 아닙니다. 빠른 완료에는 이유 없이 복잡성을 추가하는 것입니다. 하지만 다음에서 빛을 발합니다:

복잡한 추론 작업 — 다단계 분석, 깊은 연구, 추론 모델을 진지하게 생각하게 만드는 모든 것
긴 콘텐츠 생성 — 상세 보고서, 다중 파트 문서, 광범위한 분석
불안정한 네트워크 — 모바일 클라이언트, 엣지 배포, 불안정한 기업 VPN
비동기 UX 패턴 — 작업을 제출하고, 다른 일을 하고, 결과를 가지러 돌아옴

엔터프라이즈 앱을 구축하는 .NET 개발자에게 마지막 포인트가 특히 흥미롭습니다. 사용자가 복잡한 보고서를 요청하는 Blazor 앱을 생각해 보세요 — 에이전트 작업을 시작하고, 프로그레스 인디케이터를 보여주고, 계속 작업하게 합니다. WebSocket 곡예 없이, 커스텀 큐 인프라 없이, 토큰과 폴링 루프만 있으면 됩니다.

마무리

백그라운드 응답은 Microsoft Agent Framework를 통해 .NET과 Python 모두에서 지금 사용할 수 있습니다. 단순한 Q&A 이상을 하는 에이전트를 구축하고 있다면, 툴킷에 추가할 가치가 있습니다. 연속 토큰 패턴은 매우 현실적인 프로덕션 문제를 해결하면서 것을 심플하게 유지합니다.

전체 API 참조와 더 많은 예제는 전체 문서를 확인하세요.

Agent-Framework | The .NET Blog

Microsoft Foundry 2026년 4월: Foundry Local GA, GPT-5.5, Hyperlight를 통한 CodeAct

Foundry Local이 일반 출시됨

GPT-5.5

Foundry에서의 Agent Framework 추적

Hyperlight를 통한 CodeAct (Alpha)

에이전트 모니터링 대시보드 (미리 보기)

지속적 평가 커스텀 평가자 (미리 보기)

제어 플레인의 에이전트 인벤토리

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

Handoff 작동 방식

최소한의 예

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

백엣지와 Human-in-the-Loop

마무리

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

핵심 구성 요소

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

Durable Task로 지속성 추가

Azure Functions 호스팅

왜 이것이 중요한가

로컬 MAF 에이전트가 드디어 프로덕션에 자리를 잡았습니다

Foundry Hosted Agents가 실제로 하는 것

코드 차이는 최소

두 가지 프로토콜, 하나의 에이전트

azd를 사용한 배포 흐름

마무리

에이전트를 만드는 건 쉬운 부분 — 안전하게 실행하는 게 어려운 부분

각 프로젝트가 실제로 하는 것

연결은 미들웨어 추가만 하면 됩니다

무엇을 얻나요

다섯 가지 산업 시나리오

결론

A2A v1 출시: Microsoft Agent Framework for .NET의 크로스플랫폼 에이전트 통신

A2A v1이 실제로 무엇인가

원격 A2A 에이전트에 연결하기

에이전트를 A2A 엔드포인트로 노출하기

실제로 이것이 의미하는 바

Agent Framework의 CodeAct: 에이전트 지연 시간을 절반으로 줄이는 방법

CodeAct란?

보안: Hyperlight 마이크로 VM

최소 설정

CodeAct 사용 시기 (그리고 사용하지 않을 때)

지금 시도해보세요

GPT-5.5가 Azure Foundry에 출시됐다 — .NET 개발자가 알아야 할 것들

GPT-5 발전 과정

실제로 무엇이 바뀌었나

가격

Foundry가 중요한 이유

당신의 에이전트는 어디서 기억하나요? 채팅 기록 저장소 실용 가이드

두 가지 기본 패턴

Agent Framework의 추상화 방식

공급자 빠른 참조

선택 방법

.NET의 Agent Skills가 정말 유연해졌다

파일 기반 스킬: 시작점

클래스 기반 스킬: NuGet으로 배포

인라인 스킬: 빠른 브릿지

스크립트 승인: 휴먼 인 더 루프

왜 이 조합이 중요한가

마무리

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

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

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

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

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

제 생각

마무리

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

짧은 요약

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

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

가장 중요한 기능들

주목할 만한 프리뷰 기능

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

마무리

Microsoft Agent Framework의 백그라운드 응답: 더 이상 타임아웃 걱정 없이

블로킹 호출의 문제

연속 토큰의 작동 방식

재개가 가능한 스트리밍: 진짜 마법

`azd`를 사용한 배포 흐름