Ai | The .NET Blog

NL2SQL는 에이전트 시대의 SQL 인젝션이다

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

완벽하게 들리는 NL2SQL 피치의 버전이 있습니다: 사용자가 자연어로 질문하고, 에이전트가 SQL을 생성하고, 데이터가 반환됩니다. 화면 더 적게, 쿼리 더 적게, 코드 더 적게. 단순합니다.

그런 다음 5분 더 생각합니다.

데모에서 아무도 이야기하지 않는 문제들

스키마는 사물을 설명하도록 설계되지 않았습니다. 암호화된 테이블 이름, 일관성 없는 열 이름, 추가 술어 없이는 의미적으로 유효하지 않은 기술적으로 유효한 관계들 — 이것은 기업 데이터베이스에서 일반적입니다. 버그가 아니라 비즈니스 변경의 누적된 역사입니다. 하지만 의도를 전달하도록 설계되지 않은 스키마에서 의도를 추론하도록 모델에게 요청하면, 모델은 어떻게든 시도할 것입니다. 포기하지 않습니다. 최선의 쿼리를 생성하고 자신감 있게 결과를 반환합니다.

모델은 결정론적이지 않습니다. 같은 데이터베이스에 같은 질문을 두 번 하면 다른 SQL을 얻을 수 있습니다. 모델은 확률을 계산하고 있으며, 컨텍스트의 약간의 변화가 다른 출력을 만들어냅니다. 에이전트가 항상 올바른 쿼리를 생성한다는 보장을 테스트로 달성할 수 없습니다.

사용자 검토는 확장되지 않습니다. “실행 전에 모든 쿼리를 검토하기만 하면 됩니다"는 안전하게 들립니다. 하지만 이는 사용자가 데이터 모델과 SQL 모두의 전문가라고 가정합니다 — 정확히 자연어 인터페이스가 필요하지 않았던 사람들입니다. 또한 인지 과부하와 새로운 종류의 확증 편향을 초래하며, 쿼리 복잡성에 압도된 사용자들이 조사하는 대신 유효하지 않은 쿼리를 승인합니다.

그리고 인젝션이 있습니다. 전통적인 SQL 개발에서 매개변수화가 인젝션을 해결했습니다. 사용자 입력이 SQL 구조가 아니라 매개변수를 채웠기 때문입니다. NL2SQL에서는 모델이 SQL 자체를 생성합니다. 프롬프트, 스키마 컨텍스트, 대화 기록, 검색된 데이터 모두 실행되는 것에 영향을 미칩니다. 누군가가 모델이 생성하는 것을 변경하는 프롬프트를 만든다면, 그것은 인젝션입니다 — 매개변수 수준이 아니라 쿼리 생성 수준에서. 그리고 테이블 삭제(명백하고, 복구 가능)와 달리 NL2SQL 인젝션은 눈에 보이는 오류 없이 잘못된 결과를 반환하는 쿼리를 생성합니다. 비즈니스 결정이 잘못된 데이터에 기반하여 이루어집니다.

SQL MCP Server가 실제로 해결하는 것

여기서 기사가 가장 유용한 실용적인 요점을 제시합니다. 에이전트에게 임의의 스키마 접근을 주고 최선을 바라는 대신, SQL MCP Server는 Data API builder 위에 구축된 엄선된 API 표면을 노출합니다.

차이가 중요합니다: 에이전트는 SQL을 생성하지 않습니다. 사전 정의된 결과 형태를 반환하는 이름 있는 엔드포인트를 호출합니다. SQL은 개발자가 한 번 작성하며 결정론적입니다. 에이전트의 비결정성은 임의의 쿼리를 구성하는 것이 아니라 어떤 엔드포인트를 호출할지 선택하는 것으로 제한됩니다.

이것은 전통적인 앱 모델에서 매개변수화가 SQL 인젝션에 대해 한 것 — 신뢰할 수 없는 입력에서 임의의 쿼리를 구성하는 능력을 제거하는 것 — 과 유사합니다.

올바른 질문

기사는 “NL2SQL을 절대 사용하지 마세요"라고 말하지 않습니다. 어디에 적용하고 무엇을 노출할지에 대해 신중하게 생각하라고 말합니다. 범위가 제한된 스키마와 읽기 전용 접근이 있는 통제된 환경에서의 탐색적 분석에는 NL2SQL이 괜찮을 수 있습니다. 비즈니스 결정이 결과에 의존하는 프로덕션 시스템에는 엄선된 API 레이어가 훨씬 더 안전합니다.

솔직히 말하면: 어떤 문제는 자연어에서 SQL보다 이름 있는 엔드포인트 뒤의 구조화된 쿼리로 진정으로 더 잘 해결됩니다. SQL MCP Server는 에이전트 인터페이스를 완전히 포기하지 않고 그 옵션을 제공합니다.

원본 게시물: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

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

Foundry Local 1.1: 실시간 전사, Embeddings, Responses API

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

Foundry Local 1.0은 개념을 증명했습니다: 개발자 친화적인 SDK로 Windows, macOS(Apple Silicon), Linux x64에서 AI 모델을 로컬로 실행할 수 있다는 것. 버전 1.1은 많은 실제 프로덕션 사용 사례를 다루는 세 가지 기능을 추가합니다.

라이브 오디오 전사

가장 중요한 새 기능: 마이크에서 직접 실시간 음성-텍스트 스트리밍. 자막, 음성 UI, 회의 전사, 접근성 도구 — 클라우드 의존성 없이 모두 로컬에서 실행됩니다.

API는 세션 기반이며 결과가 도착할 때 스트리밍하고, 중간 텍스트와 최종 텍스트를 구분하는 is_final 마커를 사용합니다. JavaScript, C#, Python, Rust의 모든 언어 바인딩에서 사용 가능합니다.

카탈로그에서 스트리밍 음성 모델을 로드하고, 오디오 설정(샘플 레이트, 채널, 언어)으로 세션을 생성하고, 시작하고, 원시 PCM 오디오 청크를 푸시하고, 결과의 비동기 스트림을 소비합니다. 게시물에는 Python과 C#의 전체 예제가 있습니다.

텍스트 Embeddings

시맨틱 검색, RAG 파이프라인, 클러스터링, 유사성 매칭 — 이 모든 것에는 embeddings가 필요합니다. Foundry Local 1.1은 embedding 모델 지원을 추가하여 클라우드 엔드포인트에 데이터를 보내지 않고 같은 SDK에서 로컬로 벡터를 생성할 수 있습니다.

데이터 거주지가 중요하거나 민감한 콘텐츠를 처리하는 애플리케이션의 경우, 로컬 embedding 생성은 중요한 기능입니다.

Responses API

Foundry Local은 이제 Responses API — 에이전틱 상호작용을 위해 설계된 구조화된 인터페이스 — 를 지원합니다. 이것은 다음을 추가합니다:

도구 호출 — 로컬에서 실행되는 모델이 정의한 도구를 호출하도록 허용합니다
멀티모달 비전-언어 입력 — 비전 지원 모델에 이미지 + 텍스트를 전달합니다
표준 API 형태와 호환되므로 OpenAI의 Responses API를 대상으로 하는 기존 에이전트가 로컬 모델에 대해 작동합니다

패키지 크기 개선

두 가지 변경으로 JavaScript 패키지 크기가 줄어듭니다:

koffi FFI 레이어가 사용자 정의 Node-API C 애드온으로 교체되었습니다
WebGPU 실행 공급자가 별도의 플러그인으로 제공되므로 GPU 가속이 필요 없는 애플리케이션은 크기 비용을 지불하지 않아도 됩니다

C# SDK는 이제 광범위한 .NET 호환성을 위해 더 낮은 프레임워크 버전을 대상으로 합니다.

왜 중요한가

세 가지 기능 — 전사, embeddings, 도구 호출 — 은 많은 AI 애플리케이션의 핵심 구성 요소를 다룹니다. 로컬에서 실행하면 다음을 의미합니다:

인터넷 불필요
토큰 비용 없음
머신을 떠나는 데이터 없음
네트워크 상태에 관계없이 일관된 지연

Foundry Local은 엣지 시나리오, 프라이버시에 민감한 워크로드, 오프라인 애플리케이션, 또는 개발 중 클라우드 의존성을 피하고 싶은 모든 경우에 적합합니다.

원본 게시물: Foundry Local 1.1: Live Transcription, Embeddings, and Responses API

Cosmos DB Shell이 공개 미리 보기 중 — 그리고 MCP 서버가 내장되어 있습니다

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

Cosmos DB 질문 하나에 답하기 위해 포털 탭, SDK 샘플, 반쯤 완성된 스크립트 사이를 왔다갔다 해야 했던 경험이 있다면, 이 프로젝트가 제거하려는 마찰을 이미 알고 있을 것입니다.

Azure Cosmos DB Shell이 방금 공개 미리 보기에 들어갔습니다. bash와 유사한 구문을 가진 오픈 소스 CLI이며 — 이것을 흥미롭게 만드는 부분 — 통합된 MCP 서버를 갖추고 있습니다.

다른 데이터베이스 CLI와의 차별점

CLI 자체는 유용합니다: 친숙한 명령, 스크립팅 지원, CI/CD 통합. 이 부분은 개발자 중심 데이터베이스 도구의 기본입니다.

흥미로운 부분은 MCP 서버 통합입니다. CLI가 노출하는 모든 명령이 AI 에이전트가 호출할 수 있는 MCP 도구로 사용 가능해집니다. 사용자 정의 API 레이어가 없고, 작성할 통합 코드도 없습니다. 에이전트가 다음을 수행할 수 있습니다:

cd, ls, pwd로 데이터베이스 계층 구조 탐색
query로 SQL 쿼리를 실행하고 구조화된 결과 받기
create item, update, rm으로 항목 생성 및 수정
mkdb, mkcon, rmdb, rmcon으로 데이터베이스 및 컨테이너 관리
endpoint, pwd로 현재 컨텍스트 확인

핵심 변화: 에이전트가 Cosmos DB API와 대화하는 것이 아니라 — 당신이 사용하는 것과 동일한 셸 인터페이스와 대화합니다. 명령은 결정론적이고, 감사 가능하며, 정확히 무슨 일이 일어나고 있는지 검사할 수 있도록 오픈 소스입니다.

오픈 소스 기반이 중요합니다

이것은 블랙박스 관리형 서비스가 아닙니다. 셸은 오픈 소스이며, 이것이 의미하는 바는:

보안 팀이 구현을 감사할 수 있음
플랫폼 팀이 특정 표준에 맞게 포크하고 확장할 수 있음
개발자들이 모두에게 도움이 되는 개선 사항을 기여할 수 있음

AI 도구를 채택하는 기업 팀에게 “정확히 어떻게 작동하는지 볼 수 있습니까"는 점점 더 선택적인 요구 사항이 아닙니다. 여기서 오픈 소스는 의미 있는 차별화 요소입니다.

더 쉬워지는 세 가지 시나리오

지능적인 데이터 분석 — 에이전트를 셸에 연결하고, 자연어로 질문하고, 구조화된 쿼리 결과를 얻습니다. 에이전트는 쿼리 구성을 처리하고, 셸은 실행을 처리합니다.

자율적인 데이터 관리 — Cosmos DB에서 데이터를 생성, 업데이트 또는 제거해야 하는 워크플로우는 사용자 정의 통합 없이 MCP 도구를 통해 수행할 수 있습니다.

실시간 모니터링 및 알림 — 에이전트가 주기적으로 컨테이너를 쿼리하고, 결과를 비교하며, 적절한 알림 채널을 통해 이상 징후를 표시할 수 있습니다.

MCP 인터페이스는 이러한 시나리오를 MCP를 지원하는 모든 AI 플랫폼과 조합 가능하게 만듭니다 — Microsoft 도구만이 아닙니다.

시작하기

셸은 공개 미리 보기 중입니다. 설치하고, Cosmos DB 연결을 구성하고, MCP 서버를 활성화합니다. 거기서부터 MCP 호환 에이전트 호스트라면 어디서든 도구를 검색하고 사용할 수 있습니다.

원본 게시물: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

Azure SQL이 이제 임베딩을 생성할 수 있습니다 — 순수 T-SQL로, 앱 레이어 없이

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

RAG 파이프라인을 구축해본 적이 있다면 파이프라인 세금을 알 것입니다: 데이터는 SQL에 있지만 임베딩을 생성하려면 데이터를 추출하고, 임베딩 API를 호출하고, 배치 처리와 속도 제한을 처리하고, 벡터 검색이 가능한 곳에 결과를 저장해야 합니다. 종종 완전히 다른 데이터베이스에.

Azure SQL은 현재 일반 공개된 두 가지 기능으로 그 대부분을 제거했습니다: CREATE EXTERNAL MODEL과 AI_GENERATE_EMBEDDINGS.

무엇을 하는가

이 두 T-SQL 기능은 통합 파이프라인으로 작동합니다:

CREATE EXTERNAL MODEL — 외부 AI 모델 엔드포인트를 명명된 데이터베이스 객체로 등록합니다. 위치, API 형식, 모델 유형, 자격 증명을 한 번 설정합니다. 어디서나 재사용하세요.

AI_GENERATE_EMBEDDINGS — 등록된 모델을 호출하고 벡터 값의 JSON 배열을 반환하는 스칼라 T-SQL 함수입니다. SELECT, INSERT, UPDATE, MERGE 문에서 작동합니다.

함께 SQL 엔진을 벗어나지 않고 엔드투엔드 임베딩 파이프라인을 형성합니다.

전체 워크플로우

-- 1단계: 임베딩 공급자를 한 번 등록
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- 2단계: T-SQL에서 인라인으로 임베딩 생성
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- 3단계: 벡터 거리로 검색
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

이것이 전체 파이프라인입니다: SQL의 데이터, SQL에서 생성된 임베딩, SQL에서의 유사성 검색. 오케스트레이션 레이어 없음, ETL 없음, 별도의 벡터 데이터베이스 없음.

지원되는 API 형식과 옵션

GA에서 API_FORMAT은 Azure OpenAI와 OpenAI를 지원합니다. MODEL_TYPE은 현재 EMBEDDINGS로 고정되어 있습니다. PARAMETERS JSON을 통해 재시도 횟수를 포함한 모델 수준의 기본값을 설정할 수 있습니다:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

인증은 데이터베이스 자격 증명을 사용하므로 비밀은 애플리케이션 코드 외부에 보관됩니다.

.NET 애플리케이션에서 무엇이 가능해지는가

기존 SQL 데이터 위에 AI 기능을 구축하는 .NET 개발자에게 이것은 중요합니다. 다음이 필요하지 않습니다:

임베딩을 위해 중간 저장소로 데이터 추출
외부 임베딩 파이프라인 관리
별도의 벡터 데이터베이스 설정 (완전한 기능의 벡터 저장소가 필요하면 Azure AI Search를 사용할 수 있지만)
애플리케이션의 데이터 액세스 레이어 변경

이미 보유한 동일한 T-SQL 도구를 사용하여 기존 SQL 애플리케이션에 의미 검색을 점진적으로 추가할 수 있습니다.

마무리

SQL 데이터에 대한 RAG 패턴이 극적으로 단순해졌습니다. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL은 기존 SQL 애플리케이션이 새로운 인프라를 추가하지 않고도 벡터 검색 기능을 얻을 수 있음을 의미합니다.

두 기능 모두 오늘 Azure SQL Database와 Azure SQL Managed Instance에서 GA입니다.

원본 게시물: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

당신의 AI 에이전트에는 신원 문제가 있습니다 (그리고 이것이 그것을 해결하는 템플릿입니다)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

모든 AI 에이전트 프로젝트에는 이런 순간이 있습니다: 데모가 완벽하게 작동하고, 에이전트가 자연어를 해석하고, 올바른 API를 호출하고, 올바른 데이터를 반환합니다. 그런 다음 실제 사용자에 대해 생각하기 시작합니다.

한 사용자의 에이전트 세션이 다른 사용자의 데이터를 보는 것을 무엇이 막을까요? 에이전트가 프롬프트 인젝션으로 속임을 당하면 어떻게 될까요? 예상치 못한 방법으로 도구를 호출하면 어떻게 될까요?

이것들은 엣지 케이스가 아닙니다. 이것들은 출시 전에 해야 할 설계 결정입니다.

Curity와 Microsoft의 새로운 azd 템플릿은 정확히 이 문제에 대한 작동하는 참조를 제공합니다.

핵심 문제: 인증 ≠ 인가

대부분의 에이전트 샘플은 사용자 인증을 잘 처리합니다. 인가는 잘 처리하지 못합니다. 사용자가 누구인지 아는 것이 그들이 봐야 할 데이터가 무엇인지 알려주지는 않습니다.

전통적인 클라이언트 앱은 예측 가능한 API 호출을 합니다. AI 에이전트는 비결정론적입니다 — 자연어를 해석하고 무엇을 호출할지 결정합니다. 창의적일 수 있습니다. 틀릴 수도 있습니다. 프롬프트 인젝션으로 조작되는 경우, AI가 잘 동작하는 것에 의존하지 않는 규칙이 필요합니다.

이 템플릿이 보여주는 해결책: 각 홉에 정확히 올바른 정보를 전달하는 단기 토큰.

토큰 체인 작동 방식

템플릿은 OAuth 2.0 액세스 토큰과 토큰 교환을 사용하여 각 단계에서 권한을 좁힙니다. 사용자 토큰은 MCP 서버에 도달하기 전에 두 번 교환됩니다:

첫 번째 교환 — 스코프를 좁히고 불투명한 토큰을 JWT로 변환
두 번째 교환 — 에이전트 신원과 MCP 서버 홉을 위한 새 오디언스 추가

MCP 서버 토큰이 어떻게 보이는지:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

customer_id는 에이전트가 제어하는 매개변수로 전달되는 것이 아니라 인가 서버에 의해 토큰에 내장됩니다. API는 에이전트의 지시가 아닌 토큰을 확인합니다.

이것이 의미하는 것: 누군가가 에이전트를 속여 다른 고객의 데이터를 가져오려 해도, 토큰이 이를 인가하지 않습니다.

템플릿이 배포하는 것

몇 가지 azd 명령으로 다음을 얻습니다:

Microsoft Foundry의 백엔드 에이전트 (C#, Microsoft A2A 및 MCP SDK)
샘플 포트폴리오 API를 노출하는 MCP 서버
인증을 위한 Entra ID와 함께 인가 서버로 Curity Identity Server
토큰 교환 및 감사 로깅을 처리하는 외부 및 내부 API 게이트웨이
모든 Azure 인프라를 위한 Bicep: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, 스토리지

전체 패턴은 검사 가능하고 사용자 정의 가능합니다.

빌려올 가치 있는 설계 원칙

Curity를 사용하지 않더라도 패턴은 이전 가능합니다: 에이전트는 절대 영구적인 API 액세스를 가져서는 안 됩니다. 모든 작업은 해당 특정 호출에 필요한 최소 스코프를 가진 단기 토큰을 사용하고, 특정 에이전트 신원에 발급되며, API가 인가 결정을 내리는 데 필요한 클레임을 전달해야 합니다.

이것은 “에이전트가 나쁜 일을 하지 않도록 그냥 확인하세요"가 절대 견딜 수 없는 방식으로 창의적인 에이전트, 실수, 프롬프트 인젝션에 대해 견딥니다.

결론

AI 에이전트를 위한 보안 패턴은 여전히 업계 전반에 걸쳐 정리되고 있습니다. 이 템플릿은 내가 본 가장 완전한 참조 구현 중 하나입니다 — 인증만이 아니라 실제 인가 흐름을 다룹니다.

원본 게시물: Least privilege AI agents: A new azd template from Curity and Microsoft

Aspire 13.3: Kubernetes 지원, 브라우저 로그 및 Aspireify 스킬

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

5주는 릴리스로서 긴 시간이 아니지만 Aspire 13.3은 그렇게 느껴지지 않습니다. 주요 항목들은 의미 있습니다: Helm을 사용한 Kubernetes 및 AKS 퍼스트클래스 배포, Aspireify라는 에이전트 지원 온보딩 스킬, 대시보드에서 직접 브라우저 로그 캡처, 구조화된 명령 결과. 여기에 45개의 새 기능, 134개의 개선 사항, 93개의 버그 수정도 포함됩니다.

하이라이트를 살펴보겠습니다.

Aspireify: 에이전트 지원 온보딩

기존 프로젝트에 Aspire를 추가하는 것은 간단해 보입니다 — AppHost를 추가하면 끝. 실제로는 많은 조사가 필요합니다: 어떤 포트가 중요한지, 어떤 환경 변수가 실제 의존성인지, 어떤 Docker Compose 서비스를 Aspire 통합에 매핑해야 하는지.

새로운 Aspireify 스킬은 코딩 에이전트에게 정확히 이를 위한 가이드 워크플로우를 제공합니다. aspire init이 스켈레톤 AppHost를 만들 때, Aspireify 스킬은 에이전트가 저장소를 검사하고, 이미 어떻게 작동하는지 이해하고, 앱에 맞게 AppHost를 연결하는 데 도움을 줍니다 — 반대가 아닙니다.

기본 입장은 “코드 변경을 최소화"입니다. 앱이 이미 DATABASE_URL을 읽는다면, 에이전트는 구성을 다시 작성하도록 요청하는 대신 WithEnvironment()로 매핑합니다. 포트가 하드코딩된 경우 스킬은 에이전트에게 언제 보존해야 하는지 알려줍니다.

이것이 검토할 작업을 더 생성하는 것이 아니라 실제로 시간을 절약하는 AI 툴링의 유형입니다.

퍼스트클래스 Kubernetes 및 AKS 배포

이것은 한동안 위시리스트에 있었습니다. Aspire 13.3은 Helm을 사용한 Kubernetes 및 AKS 퍼스트클래스 배포 지원을 제공합니다. 이제 Aspire 도구에서 직접 AKS를 배포 대상으로 지정할 수 있습니다.

AKS에서 이미 프로덕션 워크로드를 실행 중인 팀에게 이것은 중요한 격차를 메웁니다. Aspire 앱 모델은 이제 Helm 차트를 수동으로 작성할 필요 없이 로컬 개발에서 Kubernetes로의 깔끔한 경로를 갖게 됩니다.

대시보드의 브라우저 로그

이것은 프론트엔드 문제를 디버깅하기 전까지는 작아 보이는 기능 중 하나입니다.

새로운 WithBrowserLogs() API는 엔드포인트를 지원하는 모든 리소스에 추적된 브라우저 리소스를 첨부합니다. Aspire는 개인 CDP 파이프를 사용하여 Chromium을 시작하고 콘솔 로그, 네트워크 요청 및 오류를 리소스의 로그 스트림으로 직접 스트리밍합니다:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost도 동일하게 지원합니다:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

콘솔 오류, 실패한 네트워크 요청, 클라이언트 측 예외 — 이미 트레이스와 메트릭을 관찰하고 있는 동일한 대시보드에서 모두 볼 수 있습니다. 기본적인 것들을 위해 브라우저 DevTools로 탭을 전환할 필요가 없습니다.

구조화된 명령 결과

리소스 명령이 중요한 업그레이드를 받았습니다. 이전에는 명령이 성공/실패를 반환했습니다. 이제 구조화된 결과를 반환합니다: 모델, 대시보드 UI, CLI 및 MCP 도구를 통해 흐르는 텍스트, JSON 또는 Markdown입니다.

대시보드는 헤더의 새로운 알림 센터로 이 모든 것을 묶습니다. 명령 결과는 Markdown 렌더링과 “응답 보기” 작업이 있는 타임스탬프된 알림으로 나타납니다.

이는 리소스 명령을 진정으로 조합 가능하게 만듭니다. 이제 통합은 단순히 어딘가의 상태를 변경하는 것이 아니라 터널 URL과 같은 의미 있는 출력을 반환하는 명령을 노출할 수 있습니다.

결론

Aspire 13.3은 Kubernetes 지원만으로도 업데이트할 가치가 있습니다. 브라우저 로그와 구조화된 명령 결과는 일상적인 개발 워크플로우에서 빠르게 쌓이는 삶의 질 향상 유형입니다.

전체 릴리스 노트: What’s New in Aspire 13.3

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026은 2026년 5월 11일~15일 런던의 Barbican Centre에서 개최됩니다. 3일간의 핵심 컨퍼런스는 화요일부터 목요일까지이며, 월요일과 금요일에는 선택적 전일 워크숍이 있습니다.

78개 세션과 14개 워크숍을 갖춘 유럽에서 가장 알찬 개발자 컨퍼런스 중 하나입니다.

주제

아키텍처적 사고
C# 13에서의 함수형 코드
서버리스 디자인
시맨틱 AI
Azure Kubernetes Services
린 DevOps 전략
모델 컨텍스트 프로토콜 (MCP)
.NET에서의 에이전틱 AI
모놀리스 리팩토링
LLM으로 더 빠르게 코딩
포스트 양자 세계의 암호학
로컬 퍼스트 개발

발표자

Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm, Raju Gandhi를 포함한 세계적 수준의 라인업.

티켓 및 정보

SDD 2025 참가자의 98%가 전체 경험을 좋음, 매우 좋음 또는 우수로 평가했습니다.

.NET의 Composable Stack으로 AI 기반 컨퍼런스 앱 만들기

Emiliano Montesdeoca — Wed, 06 May 2026 00:00:00 +0000

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

.NET의 Composable Stack으로 AI 기반 컨퍼런스 앱 만들기 — Microsoft는 다섯 개의 .NET 확장 라이브러리를 조합하여 라이브 컨퍼런스 세션용 Blazor Server 앱인 ConferencePulse를 구축했습니다. MVP Summit에서 사용되었습니다.

ConferencePulse가 하는 일

ConferencePulse는 라이브 세션 중에 실행되며 다음을 제공합니다: 세션 콘텐츠에서 AI가 생성하는 폴, 라이브 지식 베이스에서 가져오는 RAG 파이프라인을 통한 청중 Q&A, 자동 생성된 인사이트, 여러 동시 AI 에이전트가 생성하는 세션 요약. 스택은 .NET 10, Blazor Server, Aspire이며 다섯 개의 프로젝트로 분할됩니다: Web, Core, Ingestion, Agents, Mcp, AppHost.

Microsoft.Extensions.AI: 모든 것을 위한 하나의 추상화

IChatClient는 통합 추상화입니다 — 한 번 설정하면 동일한 인터페이스가 Azure OpenAI, OpenAI, Anthropic 또는 다른 공급자에서 작동합니다. 함수 호출, OpenTelemetry 추적 및 로깅 미들웨어가 포함된 완전히 구성된 클라이언트를 얻기 위한 여섯 줄:

services.AddChatClient(new AzureOpenAIClient(...).GetChatClient("gpt-4o"))
 .UseFunctionInvocation()
 .UseOpenTelemetry()
 .UseLogging();

동일한 IChatClient는 나중에 데이터 수집 보강 단계에 재사용됩니다 — 그를 위한 별도의 클라이언트가 필요 없습니다.

DataIngestion 파이프라인

세션 콘텐츠는 파이프라인을 통해 흐릅니다: MarkdownReader → HeaderChunker (500 토큰, 50 토큰 오버랩) → SummaryEnricher + KeywordEnricher → VectorStoreWriter (Qdrant). 보강기는 인덱싱 전에 요약을 생성하고 키워드를 추출하기 위해 동일한 IChatClient를 사용합니다. 청중 질문, Q&A 쌍, 폴 결과는 세션이 진행되면서 실시간으로 수집됩니다 — 지식 베이스는 발표 중에 성장합니다.

VectorData: 공급자에 독립적인 검색

VectorStoreCollection.SearchAsync()는 백킹 스토어가 Qdrant이든 Azure AI Search이든 동일하게 작동합니다. 하이브리드 검색 (벡터 + 전체 텍스트)이 지원됩니다. 청중 Q&A를 위한 RAG 파이프라인은 이 컬렉션을 쿼리하고 채팅 클라이언트에 컨텍스트로 전달할 관련 청크를 가져옵니다.

MCP: 도구로서의 세션 콘텐츠

세션 콘텐츠는 MCP를 통해 노출되어 MCP 호환 클라이언트가 접근할 수 있습니다. 서버와 클라이언트 모두 구현됩니다 — 서버는 세션 지식을 MCP 도구로 노출하고, 클라이언트는 에이전트 파이프라인 내에서 해당 도구를 호출할 수 있게 합니다.

Agent Framework: 병렬 멀티 에이전트 요약

세션 요약은 동시에 실행되는 세 에이전트에 의해 생성됩니다 — PollSummaryAgent, QuestionSummaryAgent, InsightSummaryAgent — 그런 다음 병합됩니다. 이는 Microsoft Agent Framework의 그룹 채팅 또는 병렬 실행 패턴을 사용합니다. 각 에이전트는 하나의 관심사를 처리하고, 오케스트레이터가 출력을 병합합니다.

설계 원칙

이 게시물은 기억할 만한 포인트를 제시합니다: 맞는 가장 단순한 도구를 사용하세요. 간단한 생성 작업에는 직접 IChatClient 호출. 구조화된 데이터 추출에는 도구/함수 호출. 자율적인 멀티 스텝 추론이 필요할 때만 전체 에이전트를 사용. 라이브러리 레이어링이 이를 강제합니다 — 전체 Agent Framework를 가져오지 않고도 Microsoft.Extensions.AI를 사용할 수 있습니다.

전체 프로젝트 구조와 소스 링크를 보려면 전체 게시물을 참조하세요.

Microsoft Agent Framework 3부: 도구에서 워크플로우까지 — 빌딩 블록이 딱 맞게 자리를 잡다

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

.NET의 Building Blocks for AI 시리즈를 따라왔다면, 1부에서 IChatClient(범용 모델 인터페이스)를, 2부에서 Microsoft.Extensions.VectorData(시맨틱 검색 및 RAG)를 다뤘다는 것을 알 것입니다. 둘 다 기본적이고 각각 유용합니다. 하지만 여기서부터 모든 것이 연결되기 시작합니다.

3부는 Microsoft Agent Framework에 관한 것입니다 — 솔직히 말하면, .NET에서 보고 싶었던 바로 그 피스입니다. 1.0은 4월에 출시되었습니다. API는 안정적입니다. 이제 진짜 에이전트를 만들 때가 됐습니다.

에이전트란 무엇인가 (vs. 챗봇)

코드로 들어가기 전에 이 구분을 명확히 해봅시다. 챗봇은 입력을 받고, 모델을 호출하고, 출력을 반환합니다. 단순한 루프입니다.

에이전트는 자율성을 갖습니다. 작업에 대해 추론하고, 어떤 도구를 사용할지 결정하고, 그 도구를 호출하고, 결과를 평가하고, 다음에 무엇을 할지 결정할 수 있습니다 — 모든 시나리오에 대해 단계별 로직을 작성할 필요 없이. 도구와 지침을 주면, 오케스트레이션을 알아서 처리합니다.

이렇게 생각해보세요: IChatClient는 대화를 나누는 것과 같습니다. 에이전트는 누군가에게 할 일 목록을 위임하는 것과 같습니다.

10줄로 첫 번째 에이전트 만들기

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

.AsAIAgent() 확장 메서드가 다리 역할을 합니다. MEAI의 .AsIChatClient()와 같은 패턴 — 프로바이더의 SDK를 안정적인 추상화로 래핑합니다. Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry 또는 로컬 모델과 함께 작동합니다.

스트리밍도 가능합니다:

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

에이전트에게 도구 제공하기

여기서 에이전트가 정교한 챗봇에서 벗어납니다. 도구는 사용자의 요청에 따라 모델이 호출하기로 결정할 수 있는 함수입니다. 라우팅 로직이 필요 없습니다 — 모델이 스스로 파악합니다.

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

두 가지에 주목하세요. 첫째, AIFunctionFactory는 MEAI에서 옵니다 — 일반 IChatClient와 함께 사용하는 것과 같은 도구 팩토리입니다. 채팅 시나리오용으로 이미 도구를 정의했다면 여기서도 작동합니다.

둘째, Description 속성이 매우 중요합니다. 이것이 모델이 도구가 무엇을 하는지, 언제 사용해야 하는지 이해하는 방법입니다. 인간이 아닌 AI를 위한 문서로 취급하세요.

세션: 진짜 기억하는 대화

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

세션 없이는 각 RunAsync 호출이 상태 비저장입니다. 세션이 있으면 에이전트는 어떤 농담을 말하는지 알고 있습니다. AgentSession은 턴 사이에 대화 기록을 보존합니다.

프로덕션 상태 비저장 서비스의 경우 세션은 깔끔하게 직렬화됩니다:

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... 어딘가에 저장 ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

에이전트가 서버리스 또는 수평 확장 환경에서 실행되는 경우 매우 중요합니다.

AIContextProvider: 세션을 넘나드는 영구 메모리

세션은 세션 내의 대화 기록을 보존합니다. 그렇다면 세션 간에 사용자에 대한 정보를 알고 있는 것은 어떨까요? AIContextProvider가 이를 처리합니다.

두 가지 훅이 있습니다:

ProvideAIContextAsync — 각 인터랙션 이전에 실행되어 에이전트에 컨텍스트를 주입
StoreAIContextAsync — 각 인터랙션 이후에 실행되어 학습하고 지속

패턴이 우아합니다: 여러 프로바이더를 쌓을 수 있습니다 — 사용자 선호도용, 최근 인터랙션용, 관련 문서를 위해 VectorData 스토어를 쿼리하는 것 등. 마지막 것이 바로 2부의 RAG 패턴이며, 이제 모든 에이전트 호출의 일부로 자동으로 실행됩니다.

멀티 에이전트 워크플로우

여기서 프레임워크가 이름값을 합니다. 익스큐터(에이전트, 함수, 무엇이든)가 엣지를 통해 연결되는 그래프 기반 워크플로우 시스템을 포함합니다.

기본으로 지원되는 패턴:

순차적: 에이전트 A의 출력이 에이전트 B에게 흘러들어감
동시(팬아웃/팬인): 여러 에이전트에 병렬 디스패치, 결과 수집
조건부 라우팅: 출력에 따라 다른 에이전트에게 작업 라우팅
작가-비평가 루프: 한 에이전트가 쓰고, 다른 에이전트가 평가하고, 승인될 때까지 루프
서브 워크플로우: 계층적으로 워크플로우 구성

작가-비평가 예시:

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

깔끔하고 읽기 쉬우며, 조건 기반 라우팅 덕분에 루프 로직을 직접 작성할 필요가 없습니다.

휴먼-인-더-루프

모든 것이 완전 자율적으로 실행되어서는 안 됩니다. 민감한 작업 — 데이터베이스 쓰기, 금융 거래, 통신 발송 — 에는 에이전트가 실행하기 전에 사람의 승인이 필요합니다.

프레임워크는 FunctionApprovalRequestContent와 FunctionApprovalResponseContent를 통해 이에 대한 내장 지원을 제공합니다. 에이전트가 도구 호출을 제안하면 애플리케이션 코드가 사용자에게 제시하고, 응답이 실행 계속 여부를 결정합니다.

이것이 엔터프라이즈 환경에서 에이전트를 생각하는 올바른 방식입니다: 완전 자율이 아니라 가드레일이 있는 자율성.

전체 그림

한 발 물러서면:

MEAI는 어떤 모델에도 범용 인터페이스를 제공
VectorData는 시맨틱 검색을 통해 에이전트가 조직의 지식에 접근하도록 지원
Agent Framework는 모든 것을 오케스트레이션 — 내부적으로 IChatClient 사용, 컨텍스트 프로바이더와 결합, 워크플로우를 통해 조율

각 부분은 다른 부분과 구성되도록 설계되었습니다. Jeremy Likness의 원본 포스트와 Agent Framework GitHub 레포지토리에서 전체 샘플을 확인하세요.

마무리

Microsoft Agent Framework 3부 포스트는 빌딩 블록 시리즈의 루프를 닫습니다. 도구를 사용하고, 기억하고, 조율하는 진짜 AI 에이전트를 구축하고 싶은 .NET 개발자라면 이것이 바로 앞으로 나아가는 길입니다.

안정적인 1.0 릴리스는 프로덕션에서 이것을 기반으로 구축할 수 있음을 의미합니다. .NET에서 에이전트 개발에 뛰어들 기회를 기다리고 있었다면, 지금이 바로 그 시입니다.

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 블로그의 전체 게시물에서 심층적인 내용을 확인하세요.

Azure MCP Server 이제 .mcpb — 런타임 없이 설치하기

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

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

MCP 서버 설정에서 번거로웠던 것이 무엇인지 아시나요? 런타임이 필요했습니다. npm 버전에는 Node.js, pip/uvx에는 Python, dotnet 버전에는 .NET SDK.

Azure MCP Server가 이를 바꿨습니다. 이제 .mcpb — MCP Bundle — 로 제공되며 설정은 드래그 앤 드롭입니다.

MCP Bundle이란?

VS Code 확장(.vsix)이나 브라우저 확장(.crx)처럼 생각하세요. 단, MCP 서버용입니다. .mcpb 파일은 서버 바이너리와 모든 종속성을 포함한 독립적인 ZIP 아카이브입니다.

설치 방법

1. 플랫폼용 번들 다운로드

GitHub Releases 페이지에서 OS와 아키텍처에 맞는 .mcpb 파일을 다운로드합니다.

2. Claude Desktop에 설치

가장 쉬운 방법: 확장 설정 페이지(☰ → 파일 → 설정 → 확장)가 열린 상태에서 .mcpb 파일을 Claude Desktop 창에 드래그 앤 드롭합니다. 서버 세부 정보를 확인하고 설치를 클릭합니다.

3. Azure 인증

az login

끝입니다. Azure MCP Server는 기존 Azure 자격 증명을 사용합니다.

할 수 있는 것

AI 클라이언트에서 직접 100개 이상의 Azure 서비스 도구에 접근:

Cosmos DB, Storage, Key Vault, App Service, Foundry 쿼리 및 관리
모든 작업을 위한 az CLI 명령 생성
Bicep 및 Terraform 템플릿 생성

시작하기

다운로드: GitHub Releases
저장소: aka.ms/azmcp
문서: aka.ms/azmcp/docs

전체 게시물을 확인하세요.

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
데이터 주권이 필요한가? → 데이터베이스 백엔드가 있는 클라이언트 관리형
단순 챗봇인가? → 서비스 관리형 선형으로 충분

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

Foundry Toolboxes: AI 에이전트 도구를 위한 단일 엔드포인트

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

직접 겪기 전까지는 사소해 보이는 문제가 있다: 조직이 여러 AI 에이전트를 구축하고, 각 에이전트는 도구가 필요하며, 각 팀은 처음부터 다시 구성한다. 같은 웹 검색 통합, 같은 Azure AI Search 설정, 같은 GitHub MCP 서버 연결 — 하지만 다른 저장소에, 다른 팀이, 다른 자격증명으로, 공유 거버넌스 없이.

Microsoft Foundry가 공개 프리뷰로 Toolboxes를 출시했으며, 이는 그 문제에 대한 직접적인 해답이다.

Toolbox란

Toolbox는 Foundry에서 한 번 정의하고 단일 MCP 호환 엔드포인트를 통해 노출하는 명명된 재사용 가능한 도구 번들이다. MCP를 사용하는 모든 에이전트 런타임이 소비할 수 있다 — Foundry Agents에 종속되지 않는다.

제안은 간단하다: build once, consume anywhere. 도구를 정의하고, 인증을 중앙에서 설정하고 (OAuth 패스스루, Entra 관리 ID), 엔드포인트를 게시한다. 그 도구가 필요한 각 에이전트는 엔드포인트에 연결하면 모두 가져온다.

4개의 기둥 (오늘 2개 사용 가능)

기둥	상태	기능
Discover	출시 예정	수동 검색 없이 승인된 도구 발견
Build	사용 가능	도구를 재사용 가능한 번들로 구성
Consume	사용 가능	단일 MCP 엔드포인트가 모든 도구 노출
Govern	출시 예정	모든 도구 호출의 중앙 인증 + 가시성

실제 예시

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="문서를 검색하고 GitHub 이슈에 응답",
 tools=[
 {"type": "web_search", "description": "공개 문서 검색"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

게시 후 Foundry는 통합 엔드포인트를 제공한다. 한 번 연결하면 모든 도구를 사용할 수 있다.

Foundry Agents에 종속되지 않는다

Toolboxes는 Foundry에서 생성·관리되지만 소비 면은 오픈 MCP 프로토콜이다. Microsoft Agent Framework나 LangGraph로 만든 커스텀 에이전트, GitHub Copilot 및 기타 MCP 지원 IDE에서 사용할 수 있다.

지금 왜 중요한가

멀티 에이전트 물결이 프로덕션에 도달하고 있다. 새로운 에이전트마다 중복 설정, 오래된 자격증명, 일관성 없는 동작의 새로운 표면이 생긴다. Build + Consume 기반은 중앙화를 시작하기에 충분하다. Govern 기둥이 출시되면 전체 에이전트 플리트에 완전히 관찰 가능하고 중앙 제어되는 도구 계층을 갖게 된다.

마무리

아직 초기 단계다 — 공개 프리뷰, Python SDK 우선, Discover와 Govern은 예정되어 있다. 하지만 모델은 견고하고, MCP 네이티브 설계는 이미 구축 중인 도구와 함께 작동한다는 것을 의미한다. 공식 발표를 확인해 시작해보자.

Windows App Dev CLI v0.3: 터미널에서 F5 디버그와 에이전트를 위한 UI 자동화

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

Visual Studio의 F5 경험은 훌륭합니다. 하지만 CI 파이프라인, 자동화 워크플로우, 또는 AI 에이전트가 테스트를 수행할 때 패키지된 Windows 앱을 시작하고 디버그하기 위해 VS를 열어야 한다면 너무 번거롭습니다.

Windows App Development CLI v0.3이 출시되었으며, 두 가지 핵심 기능으로 이를 직접 해결합니다: winapp run과 winapp ui.

winapp run: 어디서나 F5

winapp run은 언패키지된 앱 폴더와 매니페스트를 받아, VS가 디버그 시작 시 수행하는 모든 작업을 실행합니다: 루스 패키지 등록, 앱 시작, 재배포 간 LocalState 보존.

# 앱을 빌드한 다음 패키지 앱으로 실행
winapp run ./bin/Debug

WinUI, WPF, WinForms, Console, Avalonia 등에서 동작합니다. 모드는 개발자와 자동화 워크플로우 모두를 위해 설계되었습니다:

--detach: 시작 후 즉시 터미널에 제어권을 반환합니다. CI/자동화에 적합합니다.
--unregister-on-exit: 앱 종료 시 등록된 패키지를 정리합니다.
--debug-output: OutputDebugString 메시지와 예외를 실시간으로 캡처합니다.

새로운 NuGet 패키지: 패키지 앱을 위한 dotnet run

.NET 개발자를 위한 새로운 NuGet 패키지가 있습니다: Microsoft.Windows.SDK.BuildTools.WinApp. 설치 후 dotnet run이 전체 이너 루프를 처리합니다: 빌드, 루스 레이아웃 패키지 준비, Windows 등록 및 시작 — 모두 한 단계로.

winapp init
# 또는
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: 커맨드 라인에서 UI 자동화

이것이 에이전트 시나리오를 여는 기능입니다. winapp ui는 터미널에서 실행 중인 모든 Windows 앱(WPF, WinForms, Win32, Electron, WinUI3)에 대한 완전한 UI 자동화 액세스를 제공합니다.

가능한 작업:

모든 최상위 창 나열
창의 전체 UI 자동화 트리 탐색
이름, 유형 또는 자동화 ID로 요소 검색
클릭, 호출 및 값 설정
스크린샷 캡처
요소 나타날 때까지 대기 — 테스트 동기화에 이상적

winapp ui와 winapp run을 결합하면 터미널에서 완전한 빌드 → 시작 → 검증 워크플로우가 가능합니다. 에이전트가 앱을 실행하고, UI 상태를 검사하고, 프로그래밍 방식으로 상호작용하여 결과를 검증할 수 있습니다.

기타 새로운 기능

winapp unregister: 완료 후 사이드로드된 패키지를 제거합니다.
winapp manifest add-alias: 터미널에서 이름으로 앱을 시작하는 별칭을 추가합니다.
탭 자동완성: 단일 명령으로 PowerShell 완성을 구성합니다.

설치 방법

winget install Microsoft.WinAppCli
# 또는
npm install -g @microsoft/winappcli

CLI는 공개 미리 보기 중입니다. 전체 문서는 GitHub 저장소를, 모든 세부 정보는 원본 발표를 참조하세요.

VS Code 1.117: 에이전트가 전용 Git 브랜치를 갖게 됐다, 완전 찬성이다

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

“AI 어시스턴트"와 “AI 팀원” 사이의 경계가 계속 얇아지고 있다. VS Code 1.117이 출시됐고 전체 릴리스 노트는 내용이 가득하지만, 이야기는 분명하다: 에이전트가 개발 워크플로의 일등 시민이 되고 있다.

진짜 중요한 것들을 정리했다.

Autopilot 모드가 드디어 설정을 기억한다

이전에는 새 세션을 시작할 때마다 Autopilot을 다시 활성화해야 했다. 짜증났다. 이제 권한 모드가 세션 간에 유지되고, 기본값도 설정할 수 있다.

Agent Host는 세 가지 세션 설정을 지원한다:

Default — 도구가 실행 전에 확인을 요청
Bypass — 모든 것을 자동 승인
Autopilot — 완전 자율, 스스로 질문에 답하고 계속 진행

마이그레이션, Docker, CI와 함께 새 .NET 프로젝트를 스캐폴딩하고 있다면 — Autopilot으로 한 번 설정하고 잊어버리면 된다. 그 설정이 유지된다.

에이전트 세션을 위한 worktree와 git 격리

이게 핵심이다. 에이전트 세션이 이제 완전한 worktree와 git 격리를 지원한다. 에이전트가 작업을 수행할 때 자체 브랜치와 작업 디렉토리를 갖게 된다는 뜻이다. 메인 브랜치는 전혀 영향을 받지 않는다.

더 좋은 건 — Copilot CLI가 이 worktree 세션에 의미 있는 브랜치 이름을 생성해준다. 더 이상 agent-session-abc123 같은 이름은 없다. 에이전트가 실제로 무엇을 하고 있는지 설명하는 이름을 받게 된다.

여러 피처 브랜치를 관리하거나 긴 스캐폴딩 작업이 실행되는 동안 버그를 수정하는 .NET 개발자에게 이건 게임 체인저다. 한 worktree에서 에이전트가 API 컨트롤러를 빌드하는 동안 다른 worktree에서 서비스 레이어 문제를 디버깅할 수 있다. 충돌 없음. 스태시 없음. 혼란 없음.

서브에이전트와 에이전트 팀

Agent Host Protocol이 이제 서브에이전트를 지원한다. 에이전트가 작업의 일부를 처리하기 위해 다른 에이전트를 생성할 수 있다. 위임이라고 생각하면 된다 — 메인 에이전트가 조율하고, 전문 에이전트가 각 부분을 담당한다.

아직 초기 단계지만 .NET 워크플로에 대한 잠재력은 분명하다. 한 에이전트가 EF Core 마이그레이션을 처리하고 다른 에이전트가 통합 테스트를 설정하는 모습을 상상해보라. 아직 완전히 도달하지는 않았지만, 프로토콜 지원이 지금 들어왔다는 것은 도구가 빠르게 따라올 것이라는 뜻이다.

에이전트가 입력을 보낼 때 터미널 출력이 자동으로 포함

작지만 의미 있다. 에이전트가 터미널에 입력을 보내면 터미널 출력이 이제 자동으로 컨텍스트에 포함된다. 이전에는 에이전트가 무슨 일이 일어났는지 읽기 위해 추가 턴이 필요했다.

에이전트가 dotnet build를 실행하고, 실패하고, 에러를 보기 위해 또 한 번 왕복하는 걸 본 적이 있다면 — 그 마찰이 사라졌다. 출력을 즉시 보고 반응한다.

macOS Agents 앱 자동 업데이트

macOS의 독립형 Agents 앱이 이제 자동 업데이트된다. 더 이상 새 버전을 수동으로 다운로드할 필요가 없다. 그냥 최신 상태를 유지한다.

알아둘 만한 작은 것들

package.json 호버가 이제 설치된 버전과 최신 사용 가능 버전을 모두 표시한다. .NET 프로젝트와 함께 npm 도구를 관리하는 경우 유용하다.
JSDoc 주석의 이미지가 호버와 자동완성에서 올바르게 렌더링된다.
Copilot CLI 세션이 VS Code에서 생성됐는지 외부에서 생성됐는지 표시한다 — 터미널 간에 이동할 때 편리하다.
Copilot CLI, Claude Code, Gemini CLI가 셸 타입으로 인식된다. 에디터가 무엇을 실행하고 있는지 알고 있다.

핵심 정리

VS Code 1.117은 화려한 기능 나열이 아니다. 인프라다. Worktree 격리, 영구 권한, 서브에이전트 프로토콜 — 이것들은 에이전트가 코드를 건드리지 않으면서 실제 병렬 작업을 처리하는 워크플로를 위한 기반이다.

.NET으로 개발하면서 아직 에이전트 워크플로에 뛰어들지 않았다면, 솔직히 지금이 시작할 때다.

Azure에서의 AI 실험이 돈을 태우고 있다 — 해결 방법은 이것이다

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

지금 Azure에서 AI 기반 앱을 구축하고 있다면, 아마 한 가지 눈치챈 게 있을 겁니다: 클라우드 청구서가 예전과 다르게 보인다는 것입니다. 단순히 높아진 게 아니라 — 이상해졌습니다. 들쭉날쭉하고, 예측하기 어렵습니다.

Microsoft가 여전히 중요한 클라우드 비용 최적화 원칙에 대한 훌륭한 글을 방금 게시했는데, 솔직히 이보다 더 좋은 타이밍은 없었을 겁니다. AI 워크로드가 비용에 관한 게임의 규칙을 바꿔놓았으니까요.

AI 워크로드가 다른 이유

핵심은 이겁니다. 전통적인 .NET 워크로드는 비교적 예측 가능합니다. App Service 티어를 알고, SQL DTU를 알고, 월별 지출을 꽤 정확하게 추정할 수 있습니다. AI 워크로드는요? 그렇지 않습니다.

어떤 모델이 맞는지 여러 모델을 테스트하고 있습니다. 파인튜닝을 위해 GPU 지원 인프라를 올리고 있습니다. 프롬프트 길이와 사용자 행동에 따라 토큰 소비가 크게 달라지는 Azure OpenAI API를 호출하고 있습니다. 모든 실험에는 실제 비용이 들고, 올바른 접근 방식을 찾기까지 수십 번을 실행해야 할 수도 있습니다.

이 예측 불가능성이 바로 비용 최적화가 중요한 이유입니다 — 나중에 생각할 것이 아니라, 첫날부터.

관리 vs. 최적화 — 차이를 알아야 합니다

기사에서 개발자들이 간과하는 것 같은 구분이 있습니다: 비용 관리와 비용 최적화에는 차이가 있다는 것입니다.

관리는 추적과 보고입니다. Azure Cost Management에서 예산을 설정하고, 알림을 받고, 대시보드를 봅니다. 이건 기본 중의 기본입니다.

최적화는 실제로 결정을 내리는 곳입니다. 정말 S3 티어가 필요한 건지, S1으로 부하를 감당할 수 있는 건지? 항상 켜져 있는 컴퓨트 인스턴스가 주말에 놀고 있지는 않은지? 학습 작업에 스팟 인스턴스를 사용할 수는 없는지?

.NET 개발자로서 우리는 코드에 집중하고 인프라 결정은 “운영팀"에 맡기는 경향이 있습니다. 하지만 Azure에 배포하고 있다면, 그 결정은 여러분의 결정이기도 합니다.

실제로 효과가 있는 것

기사와 제 개인적인 경험을 바탕으로, 실제로 차이를 만드는 것들입니다:

무엇에 얼마를 쓰고 있는지 파악하세요. 리소스에 태그를 달아주세요. 진심입니다. 어떤 프로젝트나 실험이 예산을 잡아먹고 있는지 구분할 수 없다면, 아무것도 최적화할 수 없습니다. 적절한 태깅이 된 Azure Cost Management가 가장 좋은 친구입니다.

실험하기 전에 가드레일을 설정하세요. Azure Policy를 사용해 dev/test 환경에서 비싼 SKU를 제한하세요. Azure OpenAI 배포에 지출 한도를 설정하세요. 누군가가 주말 동안 GPU 클러스터를 켜둔 채 놔뒀다는 걸 청구서가 도착하고 나서야 알게 되는 일은 없어야 합니다.

지속적으로 적정 규모를 유지하세요. 프로토타이핑 중에 선택한 그 VM? 프로덕션에는 아마 맞지 않을 겁니다. Azure Advisor가 추천을 해줍니다 — 실제로 살펴보세요. 1년에 한 번이 아니라 매달 검토하세요.

라이프사이클을 생각하세요. 개발 리소스는 종료되어야 합니다. 테스트 환경이 24시간 돌아갈 필요는 없습니다. 자동 종료 정책을 사용하세요. AI 워크로드의 경우 특히, 컴퓨트를 계속 켜두는 대신 실행당 과금되는 서버리스 옵션을 고려하세요.

비용만이 아닌 가치를 측정하세요. 이건 잊기 쉽습니다. 비용은 더 들지만 훨씬 더 나은 결과를 제공하는 모델이 올바른 선택일 수 있습니다. 목표는 가장 적게 쓰는 것이 아니라 — 똑똑하게 쓰는 것입니다.

핵심 요약

클라우드 비용 최적화는 일회성 정리가 아닙니다. 습관입니다. AI 워크로드로 인해 지출이 그 어느 때보다 예측하기 어려워진 지금, 이 습관을 일찍 들이면 나중에 고통스러운 깜짝 놀랄 일을 방지할 수 있습니다.

Azure에서 구축하는 .NET 개발자라면, 클라우드 청구서를 코드 다루듯 대하기 시작하세요 — 정기적으로 리뷰하고, 지저분해지면 리팩토링하고, 비용을 이해하지 않은 채 절대 배포하지 마세요.

Foundry의 RFT가 더 저렴하고 스마트해졌습니다 — 변경된 내용 정리

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

파인튜닝된 모델에 의존하는 .NET 앱을 개발하고 있다면, 이번 달 Foundry 업데이트에 주목할 필요가 있습니다. Reinforcement Fine-Tuning이 더 접근하기 쉬워지고 비용이 크게 낮아졌습니다.

자세한 내용은 공식 발표에 있지만, 여기서 실용적인 요약을 정리해 드리겠습니다.

o4-mini 글로벌 트레이닝

o4-mini는 추론 중심 및 에이전트 워크로드에 가장 적합한 모델입니다. 큰 소식: 이제 13개 이상의 Azure 리전에서 파인튜닝 작업을 시작할 수 있으며, Standard 트레이닝 대비 토큰당 트레이닝 비용이 더 낮습니다. 동일한 인프라, 동일한 품질, 더 넓은 범위.

팀이 여러 지역에 분산되어 있다면 이것은 중요합니다. 더 이상 트레이닝을 위해 소수의 리전에 묶여 있을 필요가 없습니다.

글로벌 트레이닝 작업을 시작하는 REST API 호출은 다음과 같습니다:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

trainingType: globalstandard 플래그가 핵심적인 차이점입니다.

새로운 모델 그레이더: GPT-4.1 패밀리

그레이더는 모델이 최적화하는 보상 신호를 정의합니다. 지금까지 모델 기반 그레이더는 소수의 모델로 제한되어 있었습니다. 이제 세 가지 새로운 옵션이 추가되었습니다: GPT-4.1, GPT-4.1-mini, GPT-4.1-nano.

결정적 그레이더 대신 모델 그레이더를 사용해야 할 때는? 태스크 출력이 개방형일 때, 여러 차원에서 부분 점수가 필요할 때, 또는 도구 호출의 정확성이 의미적 맥락에 따라 달라지는 에이전트 워크플로를 구축할 때입니다.

핵심은 티어링 전략이 실용적이라는 것입니다:

GPT-4.1-nano 초기 반복용. 낮은 비용, 빠른 피드백 루프.
GPT-4.1-mini 평가 기준이 안정되고 더 높은 정확도가 필요할 때.
GPT-4.1 프로덕션 평가 또는 모든 점수 결정이 중요한 복잡한 기준용.

단일 RFT 작업에서 그레이더 유형을 혼합할 수도 있습니다. “정답” 차원에는 string-match를 사용하고 추론 품질 평가에는 모델 그레이더를 사용하세요. 솔직히 이 유연성이 실제 워크로드에서 유용한 이유입니다.

RFT 데이터 형식 주의사항

많은 사람들이 여기서 실수합니다. RFT 데이터 형식은 SFT와 다릅니다. 각 행의 마지막 메시지는 User 또는 Developer 역할이어야 합니다 — Assistant가 아닙니다. 예상 답변은 그레이더가 직접 참조하는 reference_answer와 같은 최상위 키에 넣습니다.

지금까지 지도 파인튜닝을 해왔고 RFT로 전환하고 싶다면, 트레이닝 데이터를 재구성해야 합니다. 이 단계를 건너뛰면 작업이 조용히 실패합니다.

.NET 개발자에게 왜 중요한가

Azure OpenAI SDK를 통해 .NET 앱에서 파인튜닝된 모델을 호출하고 있다면, 더 저렴한 트레이닝은 더 공격적으로 반복할 수 있다는 뜻입니다. 모델 그레이더 옵션은 정확 일치 시나리오뿐만 아니라 미묘한 태스크에 대해서도 파인튜닝할 수 있다는 것을 의미합니다. 그리고 GitHub의 모범 사례 가이드는 실제 디버깅 시간을 절약해 줄 것입니다.

작게 시작하세요. 10개에서 100개 샘플. 간단한 그레이더. 루프를 검증하세요. 그다음 확장하세요.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026은 2026년 4월 18일 마드리드 Alcobendas의 Kinépolis Diversia에서 개최됩니다. 스페인 최대의 커뮤니티 주도 Azure 이벤트로, AI 에이전트, Azure 네트워킹, Cosmos DB, Fabric, IoT, 보안 등을 다루는 3개 병렬 트랙에 38명의 발표자가 참여합니다.

이벤트는 08:30부터 18:30까지 진행되며, 키노트, 커피 브레이크, 점심, 클로징 Q&A 세션을 포함합니다.

어젠다 하이라이트

Domando Agentes de IA: Azure AI Foundry와 Azure API Management를 활용한 거버넌스, 도구, API
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: 멀티 에이전트 시스템 실전
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

티켓

등록은 상징적인 기부입니다 — 티켓 전체 금액은 Plan International에 직접 기부되어 전 세계 아동 권리와 평등을 지원합니다. 정원이 제한되어 있으니 서둘러 등록하세요.

Azure Tour 2026

마드리드 외에도 Global Azure Tour 2026은 사라고사, 테네리페, 세비야에서도 개최됩니다.

Docker Sandbox로 Copilot 에이전트가 머신 위험 없이 코드를 리팩터링할 수 있게 되었다

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

Copilot의 에이전트 모드를 작은 편집 이상의 용도로 써본 적이 있다면, 그 고통을 알 겁니다. 파일 쓰기마다, 터미널 명령마다 — 또 권한 프롬프트. 이제 이걸 50개 프로젝트에서 한다고 상상해 보세요. 전혀 재미없죠.

Azure 팀이 GitHub Copilot 에이전트를 위한 Docker Sandbox에 관한 포스트를 공개했는데, 솔직히 제가 본 에이전틱 툴링 개선 중 가장 실용적인 것 중 하나입니다. 마이크로VM을 활용해 Copilot에게 완전히 격리된 환경을 제공하여 패키지 설치, 빌드 실행, 테스트 실행까지 — 호스트 시스템을 전혀 건드리지 않고 자유롭게 작업할 수 있게 합니다.

Docker Sandbox가 실제로 제공하는 것

핵심 아이디어는 간단합니다: 완전한 Linux 환경을 갖춘 경량 마이크로VM을 띄우고, 워크스페이스를 그 안에 동기화한 다음, Copilot 에이전트가 내부에서 자유롭게 작업하게 하는 것입니다. 작업이 끝나면 변경 사항이 다시 동기화됩니다.

단순히 “컨테이너 안에서 실행하는 것” 이상으로 만드는 요소들입니다:

양방향 워크스페이스 동기화로 절대 경로가 보존됩니다. 프로젝트 구조가 샌드박스 안에서도 동일하게 보입니다. 경로 관련 빌드 실패가 없습니다.
프라이빗 Docker 데몬이 마이크로VM 안에서 실행됩니다. 에이전트는 호스트의 Docker 소켓을 마운트하지 않고도 컨테이너를 빌드하고 실행할 수 있습니다. 보안 측면에서 큰 발전입니다.
HTTP/HTTPS 필터링 프록시가 에이전트의 네트워크 접근을 제어합니다. 어떤 레지스트리와 엔드포인트를 허용할지는 여러분이 결정합니다. 샌드박스 내 악의적인 npm install로 인한 공급망 공격? 차단됩니다.
YOLO 모드 — 네, 정말로 그렇게 부릅니다. 에이전트가 호스트를 말 그대로 손상시킬 수 없기 때문에 권한 프롬프트 없이 실행됩니다. 모든 파괴적 행위가 격리됩니다.

.NET 개발자가 주목해야 하는 이유

지금 수많은 팀이 직면하고 있는 현대화 작업을 생각해 보세요. 30개 프로젝트가 있는 .NET Framework 솔루션이 있고, .NET 9로 마이그레이션해야 합니다. 수백 개의 파일 변경이 필요합니다 — 프로젝트 파일, 네임스페이스 업데이트, API 교체, NuGet 마이그레이션.

Docker Sandbox를 사용하면 Copilot 에이전트를 프로젝트에 지정하고, 마이크로VM 안에서 자유롭게 리팩터링하게 한 다음, dotnet build와 dotnet test로 검증하고, 실제로 작동하는 변경 사항만 받아들일 수 있습니다. 실험 과정에서 로컬 개발 환경을 실수로 망가뜨릴 위험이 없습니다.

포스트에서는 병렬 에이전트 플릿 운영도 설명합니다 — 각각 자체 샌드박스에서 서로 다른 프로젝트를 동시에 처리합니다. 대규모 .NET 솔루션이나 마이크로서비스 아키텍처에서는 엄청난 시간 절약입니다. 서비스당 에이전트 하나, 모두 격리 실행, 모두 독립 검증.

보안 관점이 중요하다

대부분의 사람들이 놓치는 점이 있습니다: AI 에이전트에게 임의의 명령 실행을 허용하면, 여러분의 전체 머신을 맡기는 겁니다. Docker Sandbox는 이 모델을 뒤집습니다. 에이전트는 일회용 환경에서 완전한 자율성을 얻습니다. 네트워크 프록시가 승인된 소스에서만 다운로드할 수 있도록 보장합니다. 호스트 파일시스템, Docker 데몬, 자격 증명은 그대로 유지됩니다.

컴플라이언스 요구사항이 있는 팀 — 대부분의 엔터프라이즈 .NET 기업이 해당합니다 — 에게 이것은 “에이전틱 AI를 사용할 수 없다"와 “안전하게 도입할 수 있다"의 차이입니다.

정리

Docker Sandbox는 에이전틱 코딩의 근본적인 긴장을 해결합니다: 에이전트가 유용하려면 자유가 필요하지만, 호스트 머신에서의 자유는 위험합니다. 마이크로VM은 둘 다 가능하게 합니다. 대규모 .NET 리팩터링이나 현대화를 계획하고 있다면, 지금 설정할 가치가 있습니다. Copilot의 코드 인텔리전스와 안전한 실행 환경의 조합은 프로덕션 팀이 기다려온 바로 그것입니다.

Azure에서 AI 에이전트를 어디에 호스팅해야 할까? 실용적인 의사결정 가이드

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

지금 .NET으로 AI 에이전트를 구축하고 있다면, 아마 눈치챘을 겁니다: Azure에서 호스팅하는 방법이 정말 많다는 것을. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — 실제로 하나를 선택해야 할 때까지는 모두 합리적으로 들립니다. Microsoft가 방금 Azure AI 에이전트 호스팅에 대한 종합 가이드를 발표했고, .NET 개발자의 실용적인 관점에서 정리해 보겠습니다.

6가지 옵션 한눈에 보기

옵션	최적 용도	관리 대상
Container Apps	K8s 복잡성 없이 전체 컨테이너 제어	관측성, 상태, 라이프사이클
AKS	엔터프라이즈 컴플라이언스, 멀티 클러스터, 커스텀 네트워킹	모든 것 (그것이 포인트)
Azure Functions	이벤트 기반 단기 에이전트 작업	거의 없음 — 진정한 서버리스
App Service	단순 HTTP 에이전트, 예측 가능한 트래픽	배포, 스케일링 설정
Foundry Agents	포털/SDK를 통한 코드 불필요 에이전트	거의 없음
Foundry Hosted Agents	관리형 인프라의 커스텀 프레임워크 에이전트	에이전트 코드만

처음 4개는 범용 컴퓨팅입니다 — 에이전트를 실행할 수는 있지만 그것을 위해 설계된 것은 아닙니다. 마지막 2개는 에이전트 네이티브로, 대화, 도구 호출, 에이전트 라이프사이클을 일급 개념으로 이해합니다.

Foundry Hosted Agents — .NET 에이전트 개발자를 위한 최적점

제 주목을 끈 부분입니다. Foundry Hosted Agents는 정확히 중간에 위치합니다: 자신의 코드를 실행할 수 있는 유연성(Semantic Kernel, Agent Framework, LangGraph — 무엇이든)을 얻으면서 플랫폼이 인프라, 관측성, 대화 관리를 처리합니다.

핵심은 Hosting Adapter입니다 — 에이전트 프레임워크를 Foundry 플랫폼에 연결하는 얇은 추상화 레이어입니다. Microsoft Agent Framework의 경우:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

이것이 호스팅의 전부입니다. 어댑터가 프로토콜 변환, server-sent events를 통한 스트리밍, 대화 이력, OpenTelemetry 트레이싱을 자동으로 처리합니다. 커스텀 미들웨어도, 수동 배관 작업도 필요 없습니다.

배포가 진짜 간단합니다

이전에 Container Apps에 에이전트를 배포해 봤고 작동하지만, 상태 관리와 관측성을 위한 글루 코드를 많이 작성하게 됩니다. Hosted Agents와 azd를 사용하면:

# AI 에이전트 익스텐션 설치
azd ext install azure.ai.agents

# 템플릿에서 초기화
azd ai agent init

# 빌드, 푸시, 배포 — 완료
azd up

이 하나의 azd up이 컨테이너를 빌드하고, ACR에 푸시하고, Foundry 프로젝트를 프로비저닝하고, 모델 엔드포인트를 배포하고, 에이전트를 시작합니다. 다섯 단계가 하나의 명령어로 압축됩니다.

내장 대화 관리

프로덕션에서 가장 많은 시간을 절약하는 부분입니다. 자체 대화 상태 저장소를 구축하는 대신 Hosted Agents가 네이티브로 처리합니다:

# 영구 대화 생성
conversation = openai_client.conversations.create()

# 첫 번째 턴
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# 두 번째 턴 — 컨텍스트 유지
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Redis 불필요. Cosmos DB 세션 스토어 불필요. 메시지 직렬화를 위한 커스텀 미들웨어 불필요. 플랫폼이 그냥 처리합니다.

나의 결정 프레임워크

6가지 옵션을 모두 검토한 후의 빠른 멘탈 모델:

인프라가 필요 없다면? → Foundry Agents (포털/SDK, 컨테이너 없음)
커스텀 에이전트 코드가 있지만 관리형 호스팅을 원한다면? → Foundry Hosted Agents
이벤트 기반 단기 에이전트 작업이 필요하다면? → Azure Functions
K8s 없이 최대한의 컨테이너 제어가 필요하다면? → Container Apps
엄격한 컴플라이언스와 멀티 클러스터가 필요하다면? → AKS
예측 가능한 트래픽의 간단한 HTTP 에이전트라면? → App Service

Semantic Kernel이나 Microsoft Agent Framework로 구축하는 대부분의 .NET 개발자에게 Hosted Agents가 적절한 출발점일 것입니다. Kubernetes를 관리하거나 자체 관측성 스택을 구축하지 않고도 scale-to-zero, 내장 OpenTelemetry, 대화 관리, 프레임워크 유연성을 얻을 수 있습니다.

마무리

Azure의 에이전트 호스팅 환경은 빠르게 성숙하고 있습니다. 오늘 새 AI 에이전트 프로젝트를 시작한다면, 습관적으로 Container Apps나 AKS를 선택하기 전에 Foundry Hosted Agents를 진지하게 고려해 보세요. 관리형 인프라가 실질적인 시간을 절약하고, hosting adapter 패턴으로 프레임워크 선택을 유지할 수 있습니다.

Microsoft의 전체 가이드와 Foundry Samples 저장소에서 작동하는 예제를 확인하세요.

.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 샘플을 확인하고 시작하세요.

Azure MCP Server 2.0 출시 — 자체 호스팅 에이전트형 클라우드 자동화가 이제 시작됩니다

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

최근에 MCP와 Azure로 뭔가를 구축해본 분이라면 로컬 환경에서는 잘 작동한다는 걸 아실 겁니다. MCP 서버를 연결하고, AI 에이전트가 Azure 리소스와 대화하도록 하고, 끝. 하지만 그 설정을 팀 전체에서 공유해야 하는 순간? 그곳이 바로 복잡해지던 지점이었습니다.

이제 더 이상 그럴 필요 없습니다. Azure MCP Server 방금 2.0 안정 버전에 도달했고, 이번 주요 기능은 정확히 엔터프라이즈 팀들이 요청해온 것입니다: 자체 호스팅 원격 MCP 서버 지원.

Azure MCP Server란?

간단히 정리하겠습니다. Azure MCP Server는 Model Context Protocol 명세를 구현하고 Azure의 기능을 구조화되고 발견 가능한 도구로 노출하여 AI 에이전트가 호출할 수 있도록 합니다. 에이전트와 Azure 사이의 표준화된 브릿지라고 생각하면 됩니다. 프로비저닝, 배포, 모니터링, 진단, 모든 것이 하나의 일관된 인터페이스를 통해 이루어집니다.

숫자만 봐도 충분합니다: 57개 Azure 서비스에 걸친 276개의 MCP 도구. 정말 강력한 커버리지입니다.

핵심: 자체 호스팅 원격 배포

이게 중요한 이유는 뭘까요. 로컬 머신에서 MCP를 실행하는 건 개발과 실험에는 충분합니다. 하지만 실제 팀 환경에서는 다음이 필요합니다:

개발자와 내부 에이전트 시스템을 위한 공유 액세스
중앙 집중식 구성(테넌트 컨텍스트, 구독 기본값, 텔레메트리)
엔터프라이즈 네트워크 및 정책 경계
CI/CD 파이프라인 통합

Azure MCP Server 2.0은 이 모든 것을 다룹니다. HTTP 기반 전송, 적절한 인증, 일관된 거버넌스와 함께 중앙에서 관리되는 내부 서비스로 배포할 수 있습니다.

인증에 대해서는 두 가지 견고한 옵션이 있습니다:

Managed Identity — Microsoft Foundry와 함께 실행할 때
On-Behalf-Of (OBO) flow — 로그인한 사용자의 컨텍스트를 사용하여 Azure API를 호출하는 OpenID Connect 위임

이 OBO 흐름은 우리 .NET 개발자들에게 특히 흥미롭습니다. 이는 에이전트형 워크플로우가 과도한 권한을 가진 서비스 계정이 아닌 실제 사용자의 권한으로 작동할 수 있다는 의미입니다. 최소 권한 원칙이 처음부터 내장되어 있는 것입니다.

보안 강화

단순한 기능 릴리스가 아닙니다. 보안 측면의 업그레이드이기도 합니다. 2.0 릴리스는 다음을 추가합니다:

더 강화된 엔드포인트 검증
쿼리 지향 도구의 주입 패턴에 대한 보호
개발 환경을 위한 더 엄격한 격리 제어

MCP를 공유 서비스로 노출할 거라면, 이러한 보안 조치들은 정말 중요합니다.

어디서 사용할 수 있나요?

클라이언트 호환성 범위는 매우 넓습니다. Azure MCP Server 2.0은 다음과 함께 작동합니다:

IDE: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
CLI 에이전트: GitHub Copilot CLI, Claude Code
독립 실행형: 간단한 설정을 위한 로컬 서버
자체 호스팅 원격: 2.0의 새로운 주인공

또한 Azure US Government와 21Vianet에 의해 운영되는 Azure를 위한 소버린 클라우드 지원이 있으며, 이는 규제 대상 배포에 필수적입니다.

.NET 개발자에게 왜 중요한가요?

Semantic Kernel, Microsoft Agent Framework, 또는 자체 오케스트레이션이든 .NET으로 에이전트형 애플리케이션을 구축하고 있다면, Azure MCP Server 2.0은 에이전트가 Azure 인프라와 상호작용할 수 있는 프로덕션 준비 방식을 제공합니다. 커스텀 REST 래퍼 없음. 서비스별 통합 패턴 없음. 오직 MCP뿐입니다.

며칠 전에 출시된 MCP Apps용 유창한 API와 함께라면, .NET MCP 생태계는 빠르게 성숙해지고 있습니다.

시작하기

자신의 경로를 선택하세요:

GitHub Repo — 소스 코드, 문서, 모든 것
Docker Image — 컨테이너화된 배포
VS Code Extension — IDE 통합
Self-hosting guide — 2.0의 주요 기능

마치며

Azure MCP Server 2.0은 데모에서는 화려해 보이지 않지만 실제로는 모든 것을 바꾸는 인프라 업그레이드입니다. 적절한 인증, 보안 강화, 소버린 클라우드 지원과 함께하는 자체 호스팅 원격 MCP는 MCP가 Azure에서 실제 에이전트형 워크플로우를 구축하는 실제 팀을 위해 준비되었다는 의미입니다. “엔터프라이즈 준비 완료"라는 신호를 기다리고 있었다면, 이것이 바로 그 신호입니다.

.NET Aspire 13.2는 AI 에이전트의 가장 친한 친구가 되고 싶어한다

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

AI 코딩 에이전트가 꽤 괜찮은 코드를 작성해서 기대했는데, 그것을 실제로 실행하려고 하면 전부 무너지는 그 순간 아시죠? 포트 충돌, 고스트 프로세스, 잘못된 환경 변수 — 갑자기 에이전트가 기능을 만드는 대신 시작 문제를 디버깅하느라 토큰을 소모합니다.

Aspire 팀이 바로 이 문제에 대한 정말 사려 깊은 글을 발표했고, 그들의 답은 설득력이 있습니다: Aspire 13.2는 인간만을 위한 것이 아니라 AI 에이전트를 위해서도 설계되었습니다.

문제는 현실입니다

AI 에이전트는 코드 작성에 놀라운 능력을 보여줍니다. 하지만 작동하는 풀스택 앱을 배포하려면 파일 생성 이상의 것이 필요합니다. 서비스를 올바른 순서로 시작하고, 포트를 관리하고, 환경 변수를 설정하고, 데이터베이스를 연결하고, 문제가 생겼을 때 피드백을 받아야 합니다. 현재 대부분의 에이전트는 이 모든 것을 시행착오로 처리합니다 — 명령 실행, 에러 출력 읽기, 재시도.

Markdown 지침, 커스텀 스킬, 프롬프트를 쌓아올려 가이드하려 하지만, 이것들은 예측 불가능하고 컴파일할 수 없으며 파싱하는 것만으로도 토큰이 듭니다. Aspire 팀은 핵심 인사이트를 정확히 짚었습니다: 에이전트에게 필요한 것은 컴파일러와 구조화된 API이지, 더 많은 Markdown이 아닙니다.

에이전트 인프라로서의 Aspire

Aspire 13.2가 에이전틱 개발 테이블에 가져오는 것들:

전체 스택을 타입이 있는 코드로. AppHost가 앱의 전체 토폴로지 — API, 프론트엔드, 데이터베이스, 캐시 — 를 컴파일 가능한 TypeScript 또는 C#로 정의합니다:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

에이전트는 이것을 읽어 앱 토폴로지를 이해하고, 리소스를 추가하고, 연결을 설정하고, 검증을 위해 빌드할 수 있습니다. 컴파일러가 뭔가 잘못되면 즉시 알려줍니다. 추측 불필요, 설정 파일에 대한 시행착오 불필요.

하나의 명령으로 모두 지배. 에이전트가 docker compose up, npm run dev, 데이터베이스 시작 스크립트를 저글링하는 대신, 모든 것이 aspire start 하나입니다. 모든 리소스가 올바른 순서로, 올바른 포트에, 올바른 설정으로 시작됩니다. 장시간 실행 프로세스도 에이전트를 멈추지 않습니다 — Aspire가 관리합니다.

병렬 에이전트를 위한 격리 모드. --isolated를 사용하면 각 Aspire 실행이 자체 랜덤 포트와 별도의 사용자 시크릿을 갖습니다. 여러 에이전트가 git worktree에서 작업 중인가요? 충돌하지 않습니다. 이것은 VS Code의 백그라운드 에이전트처럼 병렬 환경을 생성하는 도구에 매우 중요합니다.

텔레메트리를 통한 에이전트의 눈. 여기서 정말 강력해집니다. Aspire CLI는 개발 중 완전한 OpenTelemetry 데이터를 노출합니다 — 트레이스, 메트릭, 구조화된 로그. 에이전트가 콘솔 출력을 읽고 최선을 바라는 것이 아닙니다. 서비스 간 실패한 요청을 추적하고, 느린 엔드포인트를 프로파일링하고, 정확히 어디서 문제가 발생하는지 파악할 수 있습니다. 개발 루프에 프로덕션급 관찰 가능성이 있는 것입니다.

볼링 범퍼 비유

Aspire 팀은 훌륭한 비유를 사용합니다: Aspire를 AI 에이전트를 위한 볼링 레인 범퍼라고 생각하세요. 에이전트가 완벽하지 않다면 (그리고 완벽하지 않을 것입니다), 범퍼가 거터볼을 치지 않도록 막아줍니다. 스택 정의가 잘못된 구성을 방지하고, 컴파일러가 오류를 잡고, CLI가 프로세스 관리를 담당하고, 텔레메트리가 피드백 루프를 제공합니다.

이것을 Playwright CLI 같은 것과 결합하면, 에이전트가 실제로 앱을 사용할 수 있습니다 — 플로우를 클릭하고, DOM을 확인하고, 텔레메트리에서 깨진 것을 보고, 코드를 수정하고, 재시작하고, 다시 테스트합니다. 빌드, 실행, 관찰, 수정. 이것이 우리가 추구해온 자율 개발 루프입니다.

시작하기

Aspire가 처음이세요? get.aspire.dev에서 CLI를 설치하고 시작 가이드를 따르세요.

이미 Aspire를 사용 중이세요? aspire update --self를 실행하여 13.2를 받고, 좋아하는 코딩 에이전트를 레포에 연결하세요. Aspire의 가드레일이 있으면 에이전트가 얼마나 더 멀리까지 갈 수 있는지 놀라실 수 있습니다.

마무리

Aspire 13.2는 더 이상 단순한 분산 앱 프레임워크가 아닙니다 — 필수적인 에이전트 인프라가 되고 있습니다. 구조화된 스택 정의, 원커맨드 시작, 격리된 병렬 실행, 실시간 텔레메트리가 AI 에이전트에게 코드 작성에서 앱 배포로 넘어가는 데 필요한 모든 것을 제공합니다.

Aspire 팀의 전체 포스트에서 모든 세부사항과 데모 비디오를 확인하세요.

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 리퍼런스와 예제는 전체 게시물을 읽어보세요.

Microsoft Foundry 2026년 3월 — GPT-5.4, Agent Service GA, 그리고 모든 것을 바꾸는 SDK 리프레시

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

월간 “Microsoft Foundry 새 소식” 포스트는 보통 점진적 개선과 가끔의 헤드라인 기능이 섞여 있습니다. 2026년 3월판은요? 기본적으로 전부 헤드라인 기능입니다. Foundry Agent Service가 GA에 도달하고, GPT-5.4가 프로덕션용으로 출시되고, SDK가 대규모 안정 릴리스를 받고, Fireworks AI가 오픈 모델 추론을 Azure에 가져옵니다. .NET 개발자에게 중요한 것이 무엇인지 살펴보겠습니다.

Foundry Agent Service가 프로덕션 준비 완료

이것이 가장 큰 뉴스입니다. 차세대 에이전트 런타임이 정식 출시되었습니다 — OpenAI Responses API 위에 구축되었으며, OpenAI 에이전트와 와이어 호환되고, 여러 제공업체의 모델에 개방되어 있습니다. 오늘 Responses API로 구축하고 있다면, Foundry로 마이그레이션하면 기존 에이전트 로직 위에 엔터프라이즈 보안, 프라이빗 네트워킹, Entra RBAC, 전체 트레이싱, 그리고 평가가 추가됩니다.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

주요 추가 사항: 엔드투엔드 프라이빗 네트워킹, MCP 인증 확장(OAuth 패스스루 포함), 음성 대 음성 에이전트를 위한 Voice Live 프리뷰, 6개 신규 리전에서의 호스팅 에이전트.

GPT-5.4 — 순수한 지능보다 신뢰성

GPT-5.4는 더 똑똑해지는 것이 아닙니다. 더 신뢰할 수 있게 되는 것입니다. 긴 상호작용에서의 강력한 추론, 더 나은 지시 준수, 워크플로 중간 실패 감소, 통합된 컴퓨터 사용 기능. 프로덕션 에이전트에게는 이러한 신뢰성이 벤치마크 점수보다 훨씬 중요합니다.

모델	가격 (백만 토큰당)	최적 용도
GPT-5.4 (≤272K)	$2.50 / $15 출력	프로덕션 에이전트, 코딩, 문서 워크플로
GPT-5.4 Pro	$30 / $180 출력	심층 분석, 과학적 추론
GPT-5.4 Mini	비용 효율적	분류, 추출, 경량 도구 호출

스마트한 전략은 라우팅입니다: GPT-5.4 Mini가 대용량·저지연 작업을 처리하고 GPT-5.4가 추론이 무거운 요청을 담당합니다.

SDK가 드디어 안정화

azure-ai-projects SDK가 모든 언어에서 안정 릴리스를 발표했습니다 — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0, 그리고 .NET 2.0.0 (4월 1일). azure-ai-agents 의존성은 사라졌습니다 — 모든 것이 AIProjectClient 아래에 있습니다. pip install azure-ai-projects로 설치하면 패키지가 openai과 azure-identity를 직접 의존성으로 번들합니다.

.NET 개발자에게 이는 Foundry 전체 기능에 대한 단일 NuGet 패키지를 의미합니다. 더 이상 별도의 에이전트 SDK를 겹쳐 사용할 필요가 없습니다.

Fireworks AI가 오픈 모델을 Azure에 제공

아마도 아키텍처적으로 가장 흥미로운 추가: Fireworks AI가 매일 13조 이상의 토큰을 ~180K 요청/초로 처리하며, 이제 Foundry를 통해 사용 가능합니다. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, MiniMax M2.5가 출시 시 제공됩니다.

진짜 이야기는 bring-your-own-weights — 서빙 스택을 변경하지 않고 어디에서나 양자화되거나 파인튜닝된 가중치를 업로드할 수 있습니다. 서버리스 토큰당 과금 또는 프로비저닝된 처리량으로 배포하세요.

기타 하이라이트

Phi-4 Reasoning Vision 15B — 차트, 다이어그램, 문서 레이아웃을 위한 멀티모달 추론
Evaluations GA — Azure Monitor에 연결된 지속적 프로덕션 모니터링과 함께 즉시 사용 가능한 평가기
Priority Processing (프리뷰) — 지연 민감 워크로드를 위한 전용 컴퓨트 레인
Voice Live — Foundry 에이전트에 직접 연결되는 음성 대 음성 런타임
Tracing GA — 정렬 및 필터링이 가능한 엔드투엔드 에이전트 트레이스 검사
PromptFlow 지원 종료 — 2027년 1월까지 Microsoft Framework Workflows로 마이그레이션

마무리

2026년 3월은 Foundry의 전환점입니다. Agent Service GA, 모든 언어의 안정 SDK, 신뢰할 수 있는 프로덕션 에이전트를 위한 GPT-5.4, Fireworks AI를 통한 오픈 모델 추론 — 플랫폼이 본격적인 워크로드를 위해 준비되었습니다.

전체 요약을 읽고 첫 번째 에이전트를 구축하여 시작하세요.

SQL MCP Server — AI 에이전트에게 데이터베이스 접근을 제공하는 올바른 방법

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

솔직히 말합시다: 오늘날 사용 가능한 대부분의 데이터베이스 MCP 서버는 무섭습니다. 자연어 쿼리를 받아서 즉석에서 SQL을 생성하고 프로덕션 데이터에 대해 실행합니다. 뭐가 잘못될 수 있을까요? (전부요. 전부 잘못될 수 있습니다.)

Azure SQL 팀이 방금 SQL MCP Server를 발표했는데, 근본적으로 다른 접근 방식을 취합니다. Data API builder(DAB) 2.0의 기능으로 구축되어, AI 에이전트에게 구조화되고 결정론적인 데이터베이스 작업 접근을 제공합니다 — NL2SQL 없이, 스키마 노출 없이, 매 단계마다 완전한 RBAC와 함께.

왜 NL2SQL이 아닌가?

이것이 가장 흥미로운 설계 결정입니다. 모델은 결정론적이지 않으며, 복잡한 쿼리가 미묘한 오류를 생성할 가능성이 가장 높습니다. 사용자가 AI가 생성해주길 바라는 바로 그 쿼리가 비결정론적으로 생성될 때 가장 많은 검토가 필요한 쿼리이기도 합니다.

대신, SQL MCP Server는 NL2DAB 접근 방식을 사용합니다. 에이전트는 Data API builder의 엔티티 추상화 레이어와 내장 쿼리 빌더로 작업하여 정확하고 잘 형성된 T-SQL을 결정론적으로 생성합니다. 사용자에게는 같은 결과이지만, 환각된 JOIN이나 우발적인 데이터 노출 위험이 없습니다.

7개의 도구, 700개가 아닌

SQL MCP Server는 데이터베이스 크기에 관계없이 정확히 7개의 DML 도구를 노출합니다:

describe_entities — 사용 가능한 엔티티 및 작업 발견
create_record — 행 삽입
read_records — 테이블 및 뷰 쿼리
update_record — 행 수정
delete_record — 행 삭제
execute_entity — 저장 프로시저 실행
aggregate_records — 집계 쿼리

이것은 현명합니다. 컨텍스트 윈도우는 에이전트의 사고 공간이기 때문입니다. 수백 개의 도구 정의로 채우면 추론을 위한 공간이 줄어듭니다. 7개의 고정 도구는 에이전트를 탐색이 아닌 사고에 집중하게 합니다.

각 도구는 개별적으로 활성화하거나 비활성화할 수 있습니다:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

세 가지 명령으로 시작

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

이것으로 Customers 테이블을 노출하는 SQL MCP Server가 실행됩니다. 엔티티 추상화 레이어는 이름과 열에 별칭을 지정하고, 역할별로 필드를 제한하며, 에이전트가 보는 것을 정확히 제어할 수 있게 합니다 — 내부 스키마 세부 정보를 노출하지 않으면서.

보안 이야기는 탄탄합니다

여기서 Data API builder의 성숙도가 빛을 발합니다:

모든 계층에서 RBAC — 각 엔티티가 어떤 역할이 읽기, 생성, 업데이트, 삭제할 수 있는지, 어떤 필드가 표시되는지 정의
Azure Key Vault 통합 — 연결 문자열과 비밀을 안전하게 관리
Microsoft Entra + 커스텀 OAuth — 프로덕션 등급 인증
Content Security Policy — 에이전트는 원시 SQL이 아닌 통제된 계약을 통해 상호작용

스키마 추상화는 특히 중요합니다. 내부 테이블 및 열 이름은 에이전트에게 절대 노출되지 않습니다. AI 상호작용에 의미 있는 엔티티, 별칭, 설명을 정의합니다 — 데이터베이스 ERD 다이어그램이 아니라.

멀티 데이터베이스 및 멀티 프로토콜

SQL MCP Server는 Microsoft SQL, PostgreSQL, Azure Cosmos DB, MySQL을 지원합니다. DAB의 기능이므로 동일한 구성에서 REST, GraphQL, MCP 엔드포인트를 동시에 얻을 수 있습니다. 동일한 엔티티 정의, 동일한 RBAC 규칙, 동일한 보안 — 세 가지 프로토콜 모두에서.

DAB 2.0의 자동 구성은 빠른 프로토타이핑을 위해 추상화를 줄이고 싶다면 데이터베이스를 검사하고 구성을 동적으로 빌드할 수도 있습니다.

제 의견

이것이 AI 에이전트를 위한 엔터프라이즈 데이터베이스 접근이 작동해야 하는 방식입니다. “LLM아, SQL 좀 써줘, 프로덕션에 YOLO 할게"가 아닙니다. 대신: 잘 정의된 엔티티 레이어, 결정론적 쿼리 생성, 매 단계의 RBAC, 캐싱, 모니터링, 텔레메트리. 최고의 의미로 지루합니다.

.NET 개발자에게 통합 이야기는 깔끔합니다 — DAB는 .NET 도구이고, MCP Server는 컨테이너로 실행되며, 대부분이 이미 사용하고 있는 Azure SQL과 함께 작동합니다. 데이터 접근이 필요한 AI 에이전트를 구축한다면 여기서 시작하세요.

마무리

SQL MCP Server는 무료, 오픈소스이며 어디서나 실행됩니다. AI 에이전트에게 안전한 데이터베이스 접근을 제공하기 위한 Microsoft의 규범적 접근 방식입니다. 시작하려면 전체 게시물과 문서를 확인하세요.

블랙박스처럼 느껴지지 않는 실시간 멀티 에이전트 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 프로토콜 저장소를 확인하여 더 깊이 알아보세요.

VS Code 1.115 — 백그라운드 터미널 알림, SSH 에이전트 모드 등

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115가 출시되었습니다. 주요 기능 면에서는 가벼운 릴리스이지만, AI 코딩 어시스턴트를 매일 사용하고 있다면 에이전트 관련 개선사항들이 정말 유용합니다.

실제로 알아둘 가치가 있는 것들을 짚어보겠습니다.

백그라운드 터미널이 에이전트에게 알림을 보냅니다

이번 릴리스의 핵심 기능입니다. 백그라운드 터미널이 이제 명령이 완료되면 종료 코드와 터미널 출력을 포함하여 에이전트에게 자동으로 알림을 보냅니다. 백그라운드 터미널의 입력 프롬프트도 감지되어 사용자에게 표시됩니다.

왜 중요할까요? Copilot의 에이전트 모드로 빌드 명령이나 테스트 스위트를 백그라운드에서 실행해 본 적이 있다면, “그거 끝났나?“라는 고통을 알 것입니다. 백그라운드 터미널은 기본적으로 실행 후 잊어버리는 방식이었습니다. 이제 에이전트가 dotnet build나 dotnet test가 완료되면 알림을 받고, 출력을 확인하고, 그에 따라 대응할 수 있습니다. 작은 변화지만 에이전트 기반 워크플로우의 신뢰성을 크게 향상시킵니다.

또한 새로운 send_to_terminal 도구가 추가되어 에이전트가 사용자 확인을 거쳐 백그라운드 터미널에 명령을 보낼 수 있게 되었습니다. 이로써 run_in_terminal에 타임아웃을 설정하면 터미널이 백그라운드로 이동하고 읽기 전용이 되는 문제가 해결되었습니다.

SSH 원격 에이전트 호스팅

VS Code가 이제 SSH를 통해 원격 머신에 연결하고, CLI를 자동으로 설치하여 에이전트 호스트 모드로 시작할 수 있습니다. 이는 AI 에이전트 세션이 원격 환경을 직접 타겟팅할 수 있다는 의미입니다. Linux 서버나 클라우드 VM에서 빌드하고 테스트하는 .NET 개발자에게 유용합니다.

에이전트 세션의 편집 추적

에이전트 세션 중에 수행된 파일 편집이 이제 diff, 실행 취소/다시 실행, 상태 복원과 함께 추적되고 복원됩니다. 에이전트가 코드를 변경했는데 문제가 생기면, 정확히 무엇이 변경되었는지 확인하고 롤백할 수 있습니다. 에이전트가 코드베이스를 수정하도록 맡길 때 마음의 평화를 줍니다.

브라우저 탭 인식 및 기타 개선사항

몇 가지 추가적인 생활의 질 개선사항:

브라우저 탭 추적 — 채팅이 세션 중 열린 브라우저 탭을 추적하고 링크할 수 있어 에이전트가 보고 있는 웹 페이지를 참조할 수 있습니다
터미널 파일 붙여넣기 — Ctrl+V, 드래그 앤 드롭 또는 우클릭으로 터미널에 파일(이미지 포함)을 붙여넣기
미니맵의 테스트 커버리지 — 테스트 커버리지 표시가 이제 미니맵에 나타나 빠른 시각적 개요를 제공합니다
Mac에서 핀치 투 줌 — 통합 브라우저가 핀치 투 줌 제스처를 지원합니다
세션의 Copilot 사용 권한 — 상태 표시줄이 세션 보기에서 사용량 정보를 표시합니다
파일로 이동의 파비콘 — 열린 웹 페이지가 빠른 선택 목록에 파비콘을 표시합니다

마무리

VS Code 1.115는 점진적인 릴리스이지만, 에이전트 개선 — 백그라운드 터미널 알림, SSH 에이전트 호스팅, 편집 추적 — 이 합쳐져 AI 지원 개발에서 눈에 띄게 부드러운 경험을 제공합니다. .NET 프로젝트에서 Copilot의 에이전트 모드를 사용하고 있다면, 이런 것들이 매일의 마찰을 줄여주는 생활의 질 개선입니다.

모든 세부사항은 전체 릴리스 노트를 확인하세요.

Aspire 13.2에 문서 CLI가 탑재 — AI 에이전트도 사용할 수 있습니다

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

Aspire AppHost 깊숙이 들어가서 통합을 연결하는 중에, Redis 통합이 정확히 어떤 파라미터를 기대하는지 확인해야 하는 그 순간을 아시죠? Alt-Tab으로 브라우저로 전환하고, aspire.dev를 뒤지고, API 문서를 눈을 가늘게 뜨고 보다가, 다시 에디터로 돌아옵니다. 컨텍스트를 잃었고, 플로우가 끊겼습니다.

Aspire 13.2가 바로 그 해결책을 출시했습니다. aspire docs CLI를 사용하면 터미널에서 직접 Aspire 공식 문서를 검색하고, 탐색하고, 읽을 수 있습니다. 그리고 재사용 가능한 서비스에 기반하고 있어서, AI 에이전트와 스킬이 같은 명령어를 사용해 문서를 조회할 수 있습니다. 존재하지 않는 API를 환각하는 대신에요.

이것이 실제로 해결하는 문제

David Pine이 원문에서 정확히 짚었습니다: AI 에이전트는 개발자가 Aspire 앱을 구축하는 것을 돕는 데 끔찍했습니다. aspire run 대신 dotnet run을 추천하고, aspire.dev에 있는 문서에 대해 learn.microsoft.com을 참조하고, 오래된 NuGet 패키지를 제안하고, 그리고 — 개인적으로 가장 좋아하는 — 존재하지 않는 API를 환각했습니다.

왜 그럴까요? Aspire가 폴리글랏이 된 것보다 .NET 전용이었던 기간이 훨씬 길었고, LLM은 최신 기능보다 앞선 학습 데이터로 작동하기 때문입니다. AI 에이전트에게 현재 문서를 실제로 조회할 수 있는 능력을 주면, 추측을 멈추고 유용해지기 시작합니다.

세 가지 명령어, 브라우저 탭은 제로

CLI는 상쾌할 정도로 간단합니다:

모든 문서 나열

aspire docs list

aspire.dev에서 사용 가능한 모든 문서 페이지를 반환합니다. 기계가 읽을 수 있는 출력이 필요하세요? --format Json을 추가하세요.

주제 검색

aspire docs search "redis"

가중 관련성 점수로 제목과 콘텐츠 모두를 검색합니다. 내부적으로 문서 도구를 구동하는 것과 같은 검색 엔진입니다. 제목, 슬러그, 관련성 점수가 포함된 순위별 결과를 얻을 수 있습니다.

전체 페이지 읽기 (또는 한 섹션만)

aspire docs get redis-integration

전체 페이지를 마크다운으로 터미널에 스트리밍합니다. 한 섹션만 필요하세요?

aspire docs get redis-integration --section "Add Redis resource"

외과적 정밀도. 500줄을 스크롤할 필요 없습니다. 필요한 부분만.

AI 에이전트 관점

AI 도구로 개발하는 우리 개발자들에게 흥미로워지는 부분입니다. 같은 aspire docs 명령어가 스킬, MCP 서버, 또는 간단한 CLI 래퍼를 통해 AI 에이전트의 도구로 작동합니다.

AI 어시스턴트가 오래된 학습 데이터를 기반으로 Aspire API를 지어내는 대신, aspire docs search "postgres"를 호출하고, 공식 통합 문서를 찾고, 올바른 페이지를 읽고, 문서화된 접근 방식을 제공할 수 있습니다. 실시간이고 최신인 문서 — 모델이 6개월 전에 기억한 것이 아닙니다.

이 뒤의 아키텍처는 의도적입니다. Aspire 팀은 일회성 통합 대신 재사용 가능한 서비스(IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache)를 구축했습니다. 이는 같은 검색 엔진이 터미널의 사람, 에디터의 AI 에이전트, CI 파이프라인의 자동화를 위해 작동한다는 의미입니다.

실제 시나리오

터미널에서 빠른 조회: 파일 세 개 깊이에 있고 Redis 설정 파라미터가 필요합니다. 두 개의 명령어, 90초, 다시 작업으로:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI 지원 개발: VS Code 스킬이 CLI 명령어를 래핑합니다. “내 AppHost에 PostgreSQL 데이터베이스를 추가해"라고 물으면 에이전트가 답변하기 전에 실제 문서를 조회합니다. 환각 없음.

CI/CD 검증: 파이프라인이 공식 문서에 대해 AppHost 설정을 프로그래밍 방식으로 검증합니다. --format Json 출력은 jq 및 다른 도구와 깔끔하게 연결됩니다.

커스텀 지식 베이스: 자체 AI 도구를 구축하고 있나요? 구조화된 JSON 출력을 지식 베이스에 직접 파이프:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

웹 스크래핑 없음. API 키 없음. 문서 도구가 내부적으로 사용하는 것과 같은 구조화된 데이터.

문서는 항상 최신 상태

이것이 제가 가장 높이 평가하는 부분입니다. CLI는 스냅샷을 다운로드하지 않습니다 — ETag 기반 캐싱으로 aspire.dev를 조회합니다. 문서가 업데이트되는 순간, CLI와 그 위에 구축된 모든 스킬이 이를 반영합니다. 오래된 복사본도 없고, “하지만 위키에는…“하는 순간도 없습니다.

마무리

aspire docs는 실제 문제를 깔끔하게 해결하는 작은 기능 중 하나입니다. 사람은 터미널 네이티브 문서 접근을 얻습니다. AI 에이전트는 추측을 멈추고 실제 문서를 참조할 수 있는 방법을 얻습니다. 그리고 모든 것이 같은 진실의 원천에 의해 뒷받침됩니다.

.NET Aspire로 개발하고 있고 아직 CLI를 시도해보지 않았다면, aspire docs search "여러분의-주제" 를 실행하고 어떤 느낌인지 확인해 보세요. 그런 다음 사용 중인 AI 스킬이나 자동화 설정에 이 명령어들을 래핑하는 것을 고려해 보세요 — 여러분의 에이전트가 감사할 것입니다.

문서 도구가 어떻게 만들어졌는지에 대한 David Pine의 심층 분석과 모든 세부 사항이 담긴 공식 CLI 레퍼런스를 확인해 보세요.

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로 오늘 바로 시작할 수 있습니다. 빠른 시작 가이드와 샘플을 확인해서 직접 경험해 보세요.

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

Aspire 13.2 대시보드에 텔레메트리 API가 추가됐다 — 그리고 모든 것이 바뀐다

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

.NET Aspire로 분산 앱을 구축해왔다면, 대시보드가 전체 경험에서 가장 훌륭한 부분이라는 걸 이미 알고 있을 겁니다. 모든 트레이스, 로그, 메트릭이 한 곳에 — 외부 Jaeger도 필요 없고, Seq 설정도 필요 없고, “다른 터미널 확인해 볼게” 같은 순간도 없습니다.

Aspire 13.2가 이를 크게 개선했습니다. James Newton-King이 업데이트를 발표했는데, 솔직히? 텔레메트리 내보내기와 API 기능만으로도 업그레이드할 가치가 있습니다.

텔레메트리를 제대로 내보내기

우리 모두 겪어본 시나리오입니다: 분산 문제를 디버깅하면서 20분간의 설정 끝에 마침내 재현했는데, 이제 팀에게 무슨 일이 있었는지 공유해야 합니다. 이전에는? 스크린샷. 트레이스 ID 복사 붙여넣기. 항상 그러는 것처럼.

Aspire 13.2는 로그 및 텔레메트리 관리 대화상자를 추가했습니다:

모든 텔레메트리 삭제 (재현 시도 전에 유용)
선택한 텔레메트리를 표준 OTLP/JSON 형식의 ZIP 파일로 내보내기
나중에 해당 ZIP을 아무 Aspire 대시보드에 다시 가져오기

마지막 부분이 핵심 기능입니다. 버그를 재현하고, 텔레메트리를 내보내고, 작업 항목에 첨부하면, 팀원이 자신의 대시보드에 가져와서 당신이 본 것과 정확히 같은 것을 볼 수 있습니다. “네 컴퓨터에서 재현해볼 수 있어?“는 이제 그만.

개별 트레이스, 스팬, 로그에도 컨텍스트 메뉴에 “Export JSON” 옵션이 있습니다. 특정 트레이스를 공유해야 할 때? 우클릭, JSON 복사, PR 설명에 붙여넣기. 끝.

텔레메트리 API가 진짜 게임 체인저

가장 기대되는 부분입니다. 대시보드가 이제 /api/telemetry 하위에 HTTP API를 제공하여 텔레메트리 데이터를 프로그래밍 방식으로 조회할 수 있습니다. 사용 가능한 엔드포인트:

GET /api/telemetry/resources — 텔레메트리가 있는 리소스 목록
GET /api/telemetry/spans — 필터를 사용한 스팬 조회
GET /api/telemetry/logs — 필터를 사용한 로그 조회
GET /api/telemetry/traces — 트레이스 목록
GET /api/telemetry/traces/{traceId} — 특정 트레이스의 모든 스팬 가져오기

모든 것이 OTLP JSON 형식으로 반환됩니다. 이것은 새로운 CLI 명령 aspire agent mcp와 aspire otel을 구동하지만, 진정한 의미는 더 큽니다: 이제 앱의 텔레메트리를 직접 조회하는 도구, 스크립트, AI 에이전트 통합을 구축할 수 있습니다.

디버깅 중에 실제 분산 트레이스를 볼 수 있는 AI 코딩 에이전트를 상상해보세요. 더 이상 가설이 아닙니다 — 이 API가 가능하게 하는 것입니다.

GenAI 텔레메트리가 실용적으로

Semantic Kernel이나 Microsoft.Extensions.AI로 AI 기반 앱을 구축하고 있다면, 개선된 GenAI 텔레메트리 시각화 도구를 좋아할 겁니다. Aspire 13.2 추가 기능:

AI 도구 설명을 Markdown으로 렌더링
트레이스 페이지에 전용 GenAI 버튼으로 빠른 접근
잘린 또는 비표준 GenAI JSON에 대한 더 나은 에러 처리
도구 정의 간 클릭-하이라이트 내비게이션

블로그 포스트에서 VS Code Copilot chat, Copilot CLI, OpenCode 모두 OTEL_EXPORTER_OTLP_ENDPOINT 설정을 지원한다고 언급합니다. Aspire 대시보드를 가리키면 텔레메트리를 통해 AI 에이전트가 실시간으로 생각하는 모습을 말 그대로 볼 수 있습니다. 다른 곳에서는 찾을 수 없는 디버깅 경험입니다.

마무리

Aspire 13.2는 대시보드를 “괜찮은 디버깅 UI"에서 “프로그래밍 가능한 관찰성 플랫폼"으로 변화시킵니다. 내보내기/가져오기 워크플로만으로도 분산 디버깅에서 실질적인 시간을 절약하고, 텔레메트리 API는 AI 지원 진단의 문을 엽니다.

이미 Aspire를 사용 중이라면 업그레이드하세요. 아직이라면 — aspire.dev를 확인해볼 좋은 이유입니다.

azd로 AI 에이전트를 로컬에서 실행하고 디버깅할 수 있게 됐다 — 2026년 3월 변경사항 정리

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

한 달에 7개 릴리스. Azure Developer CLI (azd) 팀이 2026년 3월에 발행한 것이며, 메인 기능은 제가 기다리던 것입니다: AI 에이전트를 위한 로컬 실행 및 디버그 루프.

PC Chan이 전체 요약을 게시했는데, 내용이 많지만 AI 기반 앱을 구축하는 .NET 개발자에게 실제로 중요한 것만 걸러보겠습니다.

배포 없이 AI 에이전트 실행 및 디버깅

이것이 핵심입니다. 새로운 azure.ai.agents 확장이 AI 에이전트를 위한 적절한 이너 루프 경험을 제공하는 명령을 추가합니다:

azd ai agent run — 에이전트를 로컬에서 시작
azd ai agent invoke — 메시지 전송 (로컬 또는 배포된 에이전트)
azd ai agent show — 컨테이너 상태 및 건강 표시
azd ai agent monitor — 컨테이너 로그를 실시간 스트리밍

이전에는 AI 에이전트 테스트가 변경할 때마다 Microsoft Foundry로 배포하는 것을 의미했습니다. 이제 로컬에서 반복하고, 에이전트 동작을 테스트하고, 준비가 되면 배포할 수 있습니다.

GitHub Copilot이 azd 프로젝트를 설정

azd init에 “Set up with GitHub Copilot (Preview)” 옵션이 추가됐습니다. 프로젝트 구조에 대한 프롬프트에 수동으로 답하는 대신, Copilot 에이전트가 구성을 생성합니다. 명령이 실패하면 azd가 AI 지원 문제 해결을 제공합니다.

Container App Jobs 및 배포 개선

Container App Jobs: azd가 기존 host: containerapp 설정으로 Microsoft.App/jobs 배포
설정 가능한 배포 타임아웃: azd deploy의 새 --timeout 플래그와 azure.yaml의 deployTimeout 필드
원격 빌드 폴백: ACR 빌드 실패 시 로컬 Docker/Podman 빌드로 자동 폴백
로컬 프리플라이트 검증: 배포 전 Bicep 매개변수를 로컬에서 검증

DX 개선

자동 pnpm/yarn 감지 — JS/TS 프로젝트용
pyproject.toml 지원 — Python 패키징용
로컬 템플릿 디렉토리 — azd init --template이 파일시스템 경로 허용
개선된 오류 메시지 — --no-prompt 모드
빌드 환경 변수 — 모든 프레임워크 빌드 서브프로세스에 주입 (.NET, Node.js, Java, Python)

마무리

로컬 AI 에이전트 디버그 루프가 이번 릴리스의 스타이지만, 배포 개선과 DX 폴리시의 축적으로 azd가 그 어느 때보다 성숙해졌습니다. Azure에 .NET 앱을 배포하고 있다면 — 특히 AI 에이전트라면 — 이번 업데이트는 가치가 있습니다.

전체 릴리스 노트에서 모든 세부사항을 확인하세요.

Visual Studio 3월 업데이트로 커스텀 Copilot 에이전트 제작 가능 — find_symbol이 큰 변화

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Visual Studio가 가장 중요한 Copilot 업데이트를 받았습니다. Mark Downie가 3월 릴리스를 발표했는데, 헤드라인은 커스텀 에이전트이지만 솔직히 find_symbol 도구가 워크플로를 가장 많이 바꿀 기능일 수 있습니다.

리포에 커스텀 Copilot 에이전트

Copilot이 팀의 코딩 표준을 따르게 하고 싶으세요? 커스텀 에이전트는 리포의 .github/agents/에 .agent.md 파일로 정의됩니다. 각 에이전트는 워크스페이스 인식, 코드 이해, 도구, 선호 모델, MCP 연결에 대한 전체 접근 권한을 가집니다.

에이전트 스킬: 재사용 가능한 인스트럭션 팩

스킬은 리포의 .github/skills/나 프로필의 ~/.copilot/skills/에서 자동 로드됩니다.

find_symbol: 언어 인식 내비게이션

새로운 find_symbol 도구는 Copilot의 에이전트 모드에 언어 서비스 기반 심볼 내비게이션을 제공합니다. 텍스트 검색 대신 심볼의 모든 참조를 찾고 타입 정보와 스코프에 접근할 수 있습니다.

.NET 개발자에게 이것은 엄청난 개선입니다 — 깊은 타입 계층 구조를 가진 C# 코드베이스가 크게 혜택을 받습니다.

Copilot으로 테스트 프로파일링

Test Explorer 컨텍스트 메뉴에 Profile with Copilot이 추가됐습니다. Profiling Agent가 테스트를 실행하고 자동으로 성능을 분석합니다.

라이브 디버깅 중 Perf Tips

성능 최적화가 이제 디버깅 중에 이루어집니다. Visual Studio가 인라인으로 실행 시간을 표시합니다. 느린 라인을 발견하면 Perf Tip을 클릭하고 Copilot에게 최적화 제안을 요청하세요.

Solution Explorer에서 NuGet 취약점 수정

NuGet 패키지 취약점이 감지되면 Solution Explorer에 직접 Fix with GitHub Copilot 링크가 표시됩니다.

마무리

커스텀 에이전트와 스킬이 헤드라인이지만, find_symbol이 숨겨진 보석입니다 — .NET 코드 리팩토링 시 Copilot의 정확도를 근본적으로 바꿉니다. Visual Studio 2026 Insiders를 다운로드해서 모든 기능을 체험해보세요.

KubeCon Europe 2026: .NET 개발자가 실제로 알아야 할 것

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

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

거대한 발표 글이 올라오고 스크롤하면서 “멋지긴 한데, 이게 실제로 나한테 뭘 바꿔주는 거지?“라고 생각하는 그 느낌 아시죠? 매 KubeCon 시즌마다 저한테 벌어지는 일입니다.

Microsoft가 방금 KubeCon Europe 2026 전체 요약을 발표했는데요 — Brendan Burns 본인이 직접 작성했습니다 — 솔직히? 진짜 내용이 있습니다. 기능 체크리스트가 아니라, 프로덕션에서 운영하는 방식을 바꿔주는 운영 개선 사항들입니다.

.NET 개발자로서 진짜 중요한 것만 정리해 보겠습니다.

서비스 메시 세금 없는 mTLS

서비스 메시의 문제점: 모두가 보안 보장을 원하지만, 운영 오버헤드는 아무도 원하지 않습니다. AKS가 드디어 이 격차를 메우고 있습니다.

Azure Kubernetes Application Network은 상호 TLS, 애플리케이션 인식 인가, 트래픽 텔레메트리를 제공합니다 — 사이드카가 무거운 풀 메시를 배포할 필요 없이요. Advanced Container Networking Services의 Cilium mTLS와 결합하면, X.509 인증서와 SPIRE 신원 관리를 사용한 암호화된 pod 간 통신을 얻을 수 있습니다.

실제로 의미하는 것: ASP.NET Core API가 백그라운드 워커와 통신하고, gRPC 서비스가 서로 호출하는 것 — 모두 네트워크 수준에서 암호화되고 신원 검증되며, 애플리케이션 코드 변경은 제로. 이건 큽니다.

ingress-nginx에서 마이그레이션하는 팀을 위해, Meshless Istio를 사용한 Application Routing도 있으며 Kubernetes Gateway API를 완전히 지원합니다. 사이드카 없음. 표준 기반. 점진적 마이그레이션을 위한 ingress2gateway 도구도 함께 출시되었습니다.

뒤늦은 생각이 아닌 GPU 관측성

.NET 서비스와 함께 AI 추론을 실행하고 있다면(솔직히, 누가 시작하지 않고 있겠어요?), GPU 모니터링 사각지대를 경험했을 겁니다. CPU/메모리 대시보드는 훌륭했는데, GPU는… 수동 익스포터 설정 없이는 아무것도 없었죠.

AKS가 이제 GPU 메트릭을 네이티브로 노출합니다 — 관리형 Prometheus와 Grafana에서. 같은 스택, 같은 대시보드, 같은 알림 파이프라인. 커스텀 익스포터도 서드파티 에이전트도 불필요.

네트워크 측에서는, HTTP, gRPC, Kafka 트래픽에 대한 플로우별 가시성이 원클릭 Azure Monitor 경험과 함께 추가되었습니다. IP, 포트, 워크로드, 플로우 방향, 정책 결정 — 모두 내장 대시보드에서.

그리고 두 번 쳐다보게 만든 것: agentic container networking이 자연어로 클러스터의 네트워크 상태에 대해 질문할 수 있는 웹 UI를 추가합니다. “Pod X가 서비스 Y에 도달하지 못하는 이유는?” → 라이브 텔레메트리에서 읽기 전용 진단. 새벽 2시에 진짜 유용합니다.

박사 학위 필요 없는 크로스 클러스터 네트워킹

멀티 클러스터 Kubernetes는 역사적으로 “자체 네트워크 접착제를 가져오세요” 경험이었습니다. Azure Kubernetes Fleet Manager가 이제 관리형 Cilium 클러스터 메시를 통한 크로스 클러스터 네트워킹을 제공합니다:

AKS 클러스터 간 통합 연결
크로스 클러스터 디스커버리를 위한 글로벌 서비스 레지스트리
클러스터마다 반복하지 않고 중앙에서 관리되는 설정

복원력이나 컴플라이언스를 위해 여러 리전에서 .NET 마이크로서비스를 실행하고 있다면, 많은 취약한 커스텀 접착제를 대체합니다. West Europe의 서비스 A가 메시를 통해 East US의 서비스 B를 발견하고 호출할 수 있으며, 일관된 라우팅과 보안 정책이 적용됩니다.

용기가 필요 없는 업그레이드

솔직히 — 프로덕션에서의 Kubernetes 업그레이드는 스트레스입니다. “업그레이드하고 기도하기"가 너무 많은 팀의 사실상 전략이었고, 클러스터가 버전에서 뒤처지는 주된 이유입니다.

두 가지 새로운 기능이 이것을 바꿉니다:

Blue-green 에이전트 풀 업그레이드는 새 설정으로 병렬 노드 풀을 생성합니다. 동작을 검증하고, 트래픽을 점진적으로 이동하고, 깨끗한 롤백 경로를 유지하세요. 프로덕션 노드에서의 인플레이스 변경은 이제 끝.

에이전트 풀 롤백은 업그레이드가 잘못된 후 클러스터를 재구축하지 않고 노드 풀을 이전 Kubernetes 버전과 노드 이미지로 되돌릴 수 있게 합니다.

함께 사용하면, 운영자에게 업그레이드 생명주기에 대한 진정한 통제력을 제공합니다. .NET 팀에게 중요한 이유는 플랫폼 속도가 새로운 런タ임, 보안 패치, 네트워크 기능을 얼마나 빨리 채택하는지를 직접 제어하기 때문입니다.

AI 워크로드가 Kubernetes의 일급 시민이 되다

업스트림 오픈소스 작업도 마찬가지로 중요합니다. Dynamic Resource Allocation (DRA)이 Kubernetes 1.36에서 GA가 되어, GPU 스케줄링이 우회 방법이 아닌 진정한 일급 기능이 되었습니다.

주목할 프로젝트들:

프로젝트	하는 일
AI Runway	추론을 위한 공통 Kubernetes API — K8s를 몰라도 모델 배포 가능, HuggingFace 검색과 비용 추정 포함
HolmesGPT	클라우드 네이티브를 위한 에이전트 문제 해결 — CNCF Sandbox 프로젝트로 합류
Dalec	SBOM 생성을 포함한 선언적 컨테이너 이미지 빌드 — 빌드 단계에서 CVE 감소

방향은 명확합니다: 여러분의 .NET API, Semantic Kernel 오케스트레이션 레이어, 추론 워크로드 모두 하나의 일관된 플랫폼 모델에서 실행되어야 합니다. 거기에 도달하고 있습니다.

이번 주부터 시작한다면

팀에서 이러한 변경 사항을 평가하고 있다면, 제 솔직한 우선순위 목록:

관측성 먼저 — 비프로덕션 클러스터에서 GPU 메트릭과 네트워크 플로우 로그를 활성화하세요. 놓치고 있던 것을 확인하세요.
Blue-green 업그레이드 테스트 — 다음 프로덕션 클러스터 업그레이드 전에 롤백 워크플로우를 테스트하세요. 프로세스에 대한 신뢰를 구축하세요.
신원 인식 네트워킹 파일럿 — 내부 서비스 경로 하나를 선택해서 Cilium으로 mTLS를 활성화하세요. 오버헤드를 측정하세요 (스포일러: 최소).
Fleet Manager 평가 — 두 개 이상의 클러스터를 운영한다면, 크로스 클러스터 네트워킹은 커스텀 접착제 감소만으로도 투자 대비 이득.

작은 실험, 빠른 피드백. 항상 정답인 방법입니다.

마무리

KubeCon 발표는 압도적일 수 있지만, 이번 배치는 AKS의 .NET 팀에게 진정으로 바늘을 움직입니다. 메시 오버헤드 없는 더 나은 네트워크 보안, 진짜 GPU 관측성, 더 안전한 업그레이드, 그리고 더 강력한 AI 인프라 기반.

이미 AKS를 사용하고 있다면, 운영 기준선을 강화할 좋은 시점입니다. .NET 워크로드를 Kubernetes로 이동할 계획이라면 — 플랫폼이 훨씬 더 프로덕션에 준비되었습니다.

SQL MCP Server, SSMS의 Copilot, AI 에이전트가 포함된 Database Hub: SQLCon 2026에서 실제로 중요한 것

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft가 애틀랜타에서 FabCon과 함께 SQLCon 2026을 시작했는데, 풀어봐야 할 내용이 정말 많습니다. 원래 발표는 비용 절감 플랜부터 엔터프라이즈 컴플라이언스 기능까지 전부 다룹니다. 저는 엔터프라이즈 가격 슬라이드는 건너뛰고 Azure SQL과 AI로 무언가를 만들고 있는 개발자에게 중요한 부분에 집중하겠습니다.

SQL MCP Server 퍼블릭 프리뷰 출시

이게 저에게는 헤드라인입니다. Azure SQL Database Hyperscale에 SQL MCP Server 퍼블릭 프리뷰가 추가되어 Model Context Protocol을 사용해 SQL 데이터를 AI 에이전트와 Copilot에 안전하게 연결할 수 있게 되었습니다.

MCP 물결을 따라오고 계셨다면 — 솔직히 지금은 안 보이는 게 더 어려운데 — 이건 큰 뉴스입니다. 데이터베이스에서 AI 에이전트에 컨텍스트를 제공하기 위해 커스텀 데이터 파이프라인을 구축하는 대신, SQL 데이터를 직접 노출하는 표준화된 프로토콜을 얻게 됩니다. 에이전트가 라이브 데이터베이스 정보를 쿼리하고, 추론하고, 행동할 수 있습니다.

Semantic Kernel이나 Microsoft Agent Framework로 AI 에이전트를 구축하는 우리에게 이건 깔끔한 통합 경로를 열어줍니다. 에이전트가 재고를 확인해야 하나요? 고객 레코드를 조회해야 하나요? 주문을 검증해야 하나요? MCP가 시나리오마다 맞춤형 데이터 가져오기 코드를 작성하지 않아도 되는 구조화된 방법을 제공합니다.

SSMS 22의 GitHub Copilot GA 출시

SQL Server Management Studio에서 시간을 보내신다면 — 솔직히 대부분이 아직 그렇죠 — GitHub Copilot이 SSMS 22에서 정식 출시되었습니다. VS Code와 Visual Studio에서 이미 사용하고 있는 것과 동일한 Copilot 경험을 T-SQL에서 사용할 수 있습니다.

실용적 가치는 명확합니다: 쿼리 작성, 저장 프로시저 리팩터링, 성능 문제 트러블슈팅, 관리 작업을 위한 채팅 기반 지원. 개념적으로 혁명적이진 않지만, SSMS 안에 바로 있다는 것은 데이터베이스 작업에서 AI 도움을 받기 위해 다른 에디터로 컨텍스트 스위치할 필요가 없다는 뜻입니다.

벡터 인덱스가 대폭 업그레이드

Azure SQL Database에 insert, update, delete를 완전히 지원하는 더 빠르고 강력한 벡터 인덱스가 추가되었습니다. 벡터 데이터가 실시간으로 최신 상태를 유지합니다 — 배치 재인덱싱이 필요 없습니다.

새로운 기능은 다음과 같습니다:

양자화로 정확도를 크게 잃지 않으면서 인덱스 크기 축소
반복 필터링으로 더 정밀한 결과
쿼리 옵티마이저와의 긴밀한 통합으로 예측 가능한 성능

Azure SQL을 벡터 스토어로 사용해서 Retrieval-Augmented Generation (RAG)을 하고 있다면, 이 개선 사항들은 직접적으로 유용합니다. 관계형 데이터와 동일한 데이터베이스에 벡터를 유지할 수 있어서, 별도의 벡터 데이터베이스를 운영하는 것에 비해 아키텍처가 크게 단순화됩니다.

동일한 벡터 개선 사항은 Fabric의 SQL Database에서도 사용할 수 있습니다. 둘 다 같은 SQL 엔진 위에서 동작하기 때문입니다.

Fabric의 Database Hub: 에이전트 기반 관리

이건 좀 더 미래지향적이지만 흥미롭습니다. Microsoft가 Microsoft Fabric의 Database Hub(얼리 액세스)를 발표했는데, Azure SQL, Cosmos DB, PostgreSQL, MySQL, SQL Server via Arc를 하나의 통합 뷰로 제공합니다.

흥미로운 점은 단순히 통합 뷰가 아니라 에이전트 기반 관리 접근 방식입니다. AI 에이전트가 데이터베이스 환경을 지속적으로 모니터링하고, 무엇이 변경되었는지 알려주고, 왜 중요한지 설명하고, 다음에 무엇을 해야 할지 제안합니다. 에이전트가 사전 작업을 하고 여러분이 결정을 내리는 human-in-the-loop 모델입니다.

여러 데이터베이스를 관리하는 팀에게 이건 운영 노이즈를 실질적으로 줄여줄 수 있습니다. 포털 사이를 오가며 수동으로 메트릭을 확인하는 대신, 에이전트가 신호를 가져다줍니다.

.NET 개발자에게 의미하는 것

이 모든 발표를 관통하는 흐름은 명확합니다: Microsoft는 데이터베이스 스택의 모든 레이어에 AI 에이전트를 내장하고 있습니다. 기믹이 아니라 실용적인 도구 레이어로서요.

Azure SQL 기반 .NET 앱을 구축하고 있다면, 제가 실제로 할 일은 이렇습니다:

SQL MCP Server를 사용해 보세요 — AI 에이전트를 구축하고 있다면. 커스텀 배관 없이 에이전트에 데이터베이스 접근을 제공하는 가장 깔끔한 방법입니다.
SSMS에서 Copilot을 활성화하세요 — 아직 안 했다면. 일상적인 SQL 작업에 무료 생산성 향상입니다.
벡터 인덱스를 살펴보세요 — RAG을 하고 있고 현재 별도의 벡터 스토어를 운영 중이라면. Azure SQL로 통합하면 관리할 서비스가 하나 줄어듭니다.

마무리

전체 발표에는 더 많은 내용이 있습니다 — 비용 절감 플랜, 마이그레이션 어시스턴트, 컴플라이언스 기능 — 하지만 개발자를 위한 스토리는 MCP Server, 벡터 개선, 에이전트 기반 관리 레이어에 있습니다. 이것들이 예산이 아니라 구축 방식을 바꾸는 부분입니다.

전체 그림은 Shireesh Thota의 전체 발표를 확인하시고, 새로운 관리 경험을 시도하고 싶다면 Database Hub 얼리 액세스에 등록하세요.

Azure DevOps MCP Server가 Microsoft Foundry에 등장: AI 에이전트에 어떤 의미인가

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

MCP(Model Context Protocol)가 주목받고 있습니다. AI 에이전트 생태계를 따라가고 있다면, MCP 서버가 곳곳에서 등장하고 있다는 것을 알아차렸을 것입니다 — 표준화된 프로토콜을 통해 에이전트가 외부 도구 및 서비스와 상호 작용할 수 있게 해줍니다.

이제 Azure DevOps MCP Server가 Microsoft Foundry에서 사용 가능하며, 이것은 실용적인 가능성에 대해 생각하게 만드는 통합 중 하나입니다.

실제로 무슨 일이 일어나고 있는가

Microsoft는 이미 Azure DevOps MCP Server를 퍼블릭 프리뷰로 출시했습니다 — 그것이 MCP 서버 자체입니다. 새로운 것은 Foundry 통합입니다. 이제 도구 카탈로그에서 직접 Azure DevOps MCP Server를 Foundry 에이전트에 추가할 수 있습니다.

아직 Foundry를 모르는 분들을 위해: 대규모로 AI 기반 애플리케이션과 에이전트를 구축하고 관리하기 위한 Microsoft의 통합 플랫폼입니다. 모델 접근, 오케스트레이션, 평가, 배포 — 모두 한 곳에서.

설정하기

설정은 놀라울 정도로 간단합니다:

Foundry 에이전트에서 Add Tools > Catalog으로 이동
“Azure DevOps” 검색
Azure DevOps MCP Server(preview)를 선택하고 Create 클릭
조직 이름을 입력하고 연결

그게 전부입니다. 이제 에이전트가 Azure DevOps 도구에 접근할 수 있습니다.

에이전트가 접근할 수 있는 것 제어하기

제가 높이 평가하는 부분입니다: 전부 아니면 전무 방식에 갇히지 않습니다. 에이전트에 사용 가능한 도구를 지정할 수 있습니다. 작업 항목만 읽고 파이프라인은 건드리지 않도록 하려면 그렇게 설정할 수 있습니다. 최소 권한 원칙을 AI 에이전트에 적용하는 것이죠.

이것은 누군가가 “릴리스를 도와줘"라고 요청했다고 해서 에이전트가 실수로 배포 파이프라인을 트리거하는 것을 원하지 않는 엔터프라이즈 시나리오에서 중요합니다.

.NET 팀에게 왜 흥미로운가

실제로 이것이 무엇을 가능하게 하는지 생각해 보세요:

스프린트 계획 어시스턴트 — 작업 항목을 가져오고, 속도 데이터를 분석하고, 스프린트 용량을 제안할 수 있는 에이전트
코드 리뷰 봇 — 실제로 저장소와 연결된 작업 항목을 읽을 수 있기 때문에 PR 컨텍스트를 이해하는 에이전트
인시던트 대응 — 작업 항목을 생성하고, 최근 배포를 조회하고, 버그와 최근 변경 사항을 상관시킬 수 있는 에이전트
개발자 온보딩 — “무엇을 해야 하나요?“가 실제 프로젝트 데이터에 기반한 진짜 답변을 받게 됩니다

CI/CD 파이프라인과 프로젝트 관리에 이미 Azure DevOps를 사용하는 .NET 팀에게, 이러한 시스템과 직접 상호 작용할 수 있는 AI 에이전트는 유용한 자동화를 향한 의미 있는 한 걸음입니다.

더 큰 MCP 그림

이것은 더 넓은 트렌드의 일부입니다: MCP 서버는 AI 에이전트가 외부 세계와 상호 작용하는 표준 방식이 되어가고 있습니다. GitHub, Azure DevOps, 데이터베이스, SaaS API에서 볼 수 있으며 — Foundry는 이 모든 연결이 모이는 허브가 되고 있습니다.

.NET 생태계에서 에이전트를 구축하고 있다면, MCP에 주목할 가치가 있습니다. 프로토콜은 표준화되고, 도구는 성숙해지고 있으며, Foundry 통합은 수동으로 서버 연결을 설정할 필요 없이 접근 가능하게 해줍니다.

마무리

Foundry의 Azure DevOps MCP Server는 프리뷰 상태이므로 발전을 기대하세요. 하지만 핵심 워크플로는 견고합니다: 연결하고, 도구 접근을 설정하고, 에이전트가 DevOps 데이터로 작업하게 하세요. 이미 Foundry 생태계에 있다면 몇 번의 클릭이면 됩니다. 시도해보고 어떤 워크플로를 구축할 수 있는지 확인해 보세요.

단계별 설정과 자세한 내용은 전체 공지를 확인하세요.

Foundry Agent Service GA: .NET 에이전트 개발자에게 정말 중요한 것

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

솔직히 말하면 — AI 에이전트 프로토타입을 만드는 건 쉬운 부분입니다. 어려운 건 그 이후의 모든 것: 적절한 네트워크 격리로 프로덕션에 올리기, 실제로 의미 있는 평가를 실행하기, 컴플라이언스 요구사항 처리하기, 새벽 2시에 아무것도 안 깨뜨리기.

Foundry Agent Service가 GA에 도달했습니다. 이 릴리스는 “그 이후의 모든 것” 간극에 레이저처럼 집중하고 있습니다.

Responses API 위에 구축

헤드라인: 차세대 Foundry Agent Service는 OpenAI Responses API 위에 구축되었습니다. 이미 그 와이어 프로토콜로 개발하고 있다면 Foundry로의 마이그레이션은 최소한의 코드 변경으로 가능합니다. 얻는 것: 엔터프라이즈 보안, 프라이빗 네트워킹, Entra RBAC, 완전한 트레이싱, 평가 — 기존 에이전트 로직 위에.

아키텍처는 의도적으로 열려 있습니다. 하나의 모델 제공자나 하나의 오케스트레이션 프레임워크에 종속되지 않습니다. 계획에 DeepSeek, 생성에 OpenAI, 오케스트레이션에 LangGraph — 런타임이 일관성 레이어를 처리합니다.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

프라이빗 네트워킹: 엔터프라이즈 블로커 제거

이것이 엔터프라이즈 채택의 잠금을 해제하는 기능입니다. Foundry는 이제 BYO VNet으로 완전한 엔드투엔드 프라이빗 네트워킹을 지원합니다:

퍼블릭 이그레스 없음 — 에이전트 트래픽이 공개 인터넷에 접촉하지 않음
컨테이너/서브넷 인젝션으로 로컬 통신을 위해 네트워크에 주입
도구 연결성 포함 — MCP 서버, Azure AI Search, Fabric 데이터 에이전트 모두 프라이빗 경로로 작동

마지막 포인트가 중요합니다. 프라이빗으로 유지되는 건 추론 호출만이 아닙니다 — 모든 도구 호출과 검색 콜도 네트워크 경계 내에 머무릅니다. 외부 라우팅을 금지하는 데이터 분류 정책 하에서 운영하는 팀에게 이것이 빠져있던 것입니다.

MCP 인증 제대로 하기

MCP 서버 연결은 이제 인증 패턴의 전체 스펙트럼을 지원합니다:

인증 방식	사용 시점
키 기반	조직 전체 내부 도구의 간단한 공유 액세스
Entra Agent Identity	서비스 간; 에이전트가 자기 자신으로 인증
Entra Managed Identity	프로젝트별 격리; 자격증명 관리 불필요
OAuth Identity Passthrough	사용자 위임 액세스; 에이전트가 사용자를 대신하여 행동

OAuth Identity Passthrough가 흥미로운 것입니다. 사용자가 에이전트에 개인 데이터 — OneDrive, Salesforce 조직, 사용자별 스코프 SaaS API — 에 대한 액세스를 부여해야 할 때, 에이전트는 표준 OAuth 플로우로 사용자를 대신하여 행동합니다. 모든 사람인 척하는 공유 시스템 ID는 없습니다.

Voice Live: 배관 없는 음성 대 음성

에이전트에 음성을 추가하는 것은 STT, LLM, TTS를 연결하는 것을 의미했습니다 — 세 개의 서비스, 세 번의 지연 홉, 세 개의 과금 표면, 모두 수동 동기화. Voice Live는 이것을 단일 관리 API로 압축합니다:

시맨틱 음성 활동 및 턴 종료 감지 (침묵이 아닌 의미를 이해)
서버 측 노이즈 억제 및 에코 캔슬레이션
끼어들기 지원 (사용자가 응답 중간에 끼어들 수 있음)

음성 상호작용은 텍스트와 같은 에이전트 런타임을 통과합니다. 같은 평가자, 같은 트레이스, 같은 비용 가시성. 고객 지원, 현장 서비스, 접근성 시나리오에서 이전에 커스텀 오디오 파이프라인이 필요했던 것을 대체합니다.

평가: 체크박스에서 지속적 모니터링으로

여기서 Foundry는 프로덕션 품질에 대해 진지해집니다. 평가 시스템에는 이제 세 개의 레이어가 있습니다:

기본 제공 평가자 — 일관성, 관련성, 근거성, 검색 품질, 안전성. 데이터셋이나 라이브 트래픽에 연결하여 점수를 받으세요.
커스텀 평가자 — 자체 비즈니스 로직, 톤 표준, 도메인별 컴플라이언스 규칙을 인코딩하세요.
지속적 평가 — Foundry가 라이브 프로덕션 트래픽을 샘플링하고, 평가자 스위트를 실행하고, 대시보드에 결과를 표시합니다. 근거성이 떨어지거나 안전 임계값이 초과되면 Azure Monitor 알림을 설정하세요.

모든 것이 Azure Monitor Application Insights에 게시됩니다. 에이전트 품질, 인프라 상태, 비용, 앱 텔레메트리 — 모두 한 곳에.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

호스티드 에이전트를 위한 6개 새 지역

호스티드 에이전트가 East US, North Central US, Sweden Central, Southeast Asia, Japan East 등에서 사용 가능합니다. 데이터 거주 요구사항과 에이전트가 데이터 소스 가까이에서 실행될 때 지연 시간을 압축하는 데 중요합니다.

.NET 개발자에게 왜 중요한가

GA 공지의 코드 샘플은 Python 우선이지만, 기반 인프라는 언어에 구애받지 않습니다 — 그리고 azure-ai-projects의 .NET SDK도 같은 패턴을 따릅니다. Responses API, 평가 프레임워크, 프라이빗 네트워킹, MCP 인증 — 이 모든 것이 .NET에서 사용 가능합니다.

AI 에이전트가 “멋진 데모"에서 “실제로 직장에서 출하할 수 있는 것"으로 바뀌기를 기다리고 있었다면, 이 GA 릴리스가 그 신호입니다. 프라이빗 네트워킹, 적절한 인증, 지속적 평가, 프로덕션 모니터링이 빠져있던 퍼즐 조각입니다.

마무리

Foundry Agent Service는 지금 사용할 수 있습니다. SDK를 설치하고, 포털을 열고, 빌드를 시작하세요. 빠른 시작 가이드가 몇 분 만에 제로에서 동작하는 에이전트까지 안내합니다.

모든 코드 샘플이 포함된 전체 기술 딥다이브는 GA 공지를 확인하세요.

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 참조와 더 많은 예제는 전체 문서를 확인하세요.

VS Code 1.112: .NET 개발자가 정말 주목해야 할 것들

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

VS Code 1.112가 도착했고, 솔직히? .NET 세계에서 매일을 보내고 있다면 이번 릴리스는 다르게 다가옵니다. 공식 릴리스 노트에 많은 내용이 있지만, 스크롤을 좀 줄여드리고 우리에게 정말 중요한 것에 집중하겠습니다.

Copilot CLI가 훨씬 유용해졌다

이번 릴리스의 큰 테마는 에이전트 자율성 — Copilot에게 더 많은 자유를 주어 당신이 매 단계를 감시하지 않아도 되게 하는 것입니다.

메시지 스티어링과 큐잉

Copilot CLI가 작업 중간에 있는데 뭔가 말하는 걸 깜빡했다는 걸 깨닫는 그 순간 알죠? 전에는 기다려야 했습니다. 이제 요청이 아직 실행 중일 때도 메시지를 보낼 수 있습니다 — 현재 응답을 방향 전환하거나 후속 지시를 큐에 넣거나.

dotnet 스캐폴딩의 긴 작업을 보면서 “아 잠깐, MassTransit도 필요한데"라고 생각하는 경우에 이것은 대단합니다.

권한 레벨

이것이 가장 흥분되는 것입니다. Copilot CLI 세션이 이제 세 가지 권한 레벨을 지원합니다:

기본 권한 — 도구가 실행 전에 확인을 요청하는 일반적인 흐름
승인 우회 — 모든 것을 자동 승인하고 오류 시 재시도
오토파일럿 — 완전 자율: 도구를 승인하고, 자체 질문에 답하고, 작업이 완료될 때까지 계속

Entity Framework, 마이그레이션, Docker 설정으로 새 ASP.NET Core API를 만드는 것 같은 작업을 한다면 — 오토파일럿 모드는 원하는 것을 설명하고 커피를 가지러 가면 됩니다. 알아서 할 겁니다.

chat.autopilot.enabled 설정으로 오토파일럿을 활성화할 수 있습니다.

위임 전 변경사항 미리보기

Copilot CLI에 작업을 위임하면 워크트리가 생성됩니다. 전에는 커밋하지 않은 변경사항이 있으면 소스 컨트롤을 확인해서 뭐가 영향받는지 봐야 했습니다. 이제 채팅 뷰에서 복사, 이동, 무시를 결정하기 전에 보류 중인 변경사항을 바로 보여줍니다.

작은 것이지만 “잠깐, 스테이징에 뭐가 있었지?” 하는 순간을 없애줍니다.

VS Code를 떠나지 않고 웹 앱 디버그

통합 브라우저가 이제 완전한 디버깅을 지원합니다. 브레이크포인트를 설정하고, 코드를 스텝스루하고, 변수를 검사할 수 있습니다 — 모두 VS Code 안에서. Edge DevTools로 전환할 필요 없습니다.

새로운 editor-browser 디버그 타입이 있고, 이미 msedge나 chrome 실행 구성이 있다면 launch.json의 type 필드만 바꾸면 됩니다:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Blazor 개발자에게 이것은 게임 체인저입니다. 이미 터미널에서 dotnet watch를 실행하고 있으니 — 이제 디버깅도 같은 창에 머무릅니다.

브라우저에 독립적인 줌 레벨(드디어), 적절한 우클릭 컨텍스트 메뉴, 웹사이트별 줌 기억 기능도 추가되었습니다.

MCP 서버 샌드박싱

이것은 생각보다 중요합니다. MCP 서버를 사용하고 있다면 — Azure 리소스나 데이터베이스 쿼리를 위한 커스텀 서버를 설정했을 수 있습니다 — VS Code 프로세스와 같은 권한으로 실행되고 있었습니다. 파일 시스템, 네트워크, 모든 것에 대한 전체 액세스를 의미합니다.

이제 샌드박스처리할 수 있습니다. mcp.json에서:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

샌드박스된 서버가 가지고 있지 않은 것에 대한 액세스가 필요하면 VS Code가 권한 부여를 요청합니다. “아무도 이상한 걸 안 하길 바라자” 접근방식보다 훨씬 낫습니다.

모노레포 커스터마이제이션 발견

모노레포에서 작업하고 있다면 (솔직히 많은 엔터프라이즈 .NET 솔루션이 모노레포가 됩니다), 이것은 진짜 페인 포인트를 해결합니다.

이전에는 레포의 하위 폴더를 열면 레포지토리 루트에 있는 copilot-instructions.md, AGENTS.md, 커스텀 스킬을 VS Code가 찾지 못했습니다. 이제 chat.useCustomizationsInParentRepositories 설정으로 .git 루트까지 올라가서 모든 것을 발견합니다.

팀이 모노레포의 모든 프로젝트에 걸쳐 에이전트 지시, 프롬프트 파일, 커스텀 도구를 공유할 수 있게 됩니다. 모두가 루트 폴더를 열 필요 없이.

에이전트 디버깅을 위한 /troubleshoot

커스텀 지시나 스킬을 설정한 후 왜 감지되지 않는지 궁금했던 적 있나요? 새로운 /troubleshoot 스킬이 에이전트 디버그 로그를 읽고 무슨 일이 있었는지 알려줍니다 — 어떤 도구가 사용되거나 건너뛰어졌는지, 왜 지시가 로드되지 않았는지, 무엇이 느린 응답을 유발하는지.

다음 설정으로 활성화하세요:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

그런 다음 채팅에서 /troubleshoot why is my custom skill not loading?을 입력하면 됩니다.

이 디버그 로그를 내보내기와 가져오기도 할 수 있어서, 뭔가 예상대로 작동하지 않을 때 팀과 공유하기 좋습니다.

이미지와 바이너리 파일 지원

에이전트가 이제 디스크에서 이미지 파일과 바이너리 파일을 네이티브로 읽을 수 있습니다. 바이너리 파일은 hexdump 형식으로 표시되고, 이미지 출력(통합 브라우저의 스크린샷 등)은 캐러셀 뷰로 나타납니다.

.NET 개발자의 경우: UI 버그의 스크린샷을 채팅에 붙여넣고 에이전트가 무엇이 잘못되었는지 이해하게 하거나, Blazor 컴포넌트 렌더링 출력을 분석하게 할 수 있습니다.

자동 심볼 참조

작은 삶의 질 개선: 심볼 이름(클래스, 메서드 등)을 복사해서 채팅에 붙여넣으면, VS Code가 자동으로 #sym:Name 참조로 변환합니다. 수동으로 추가하지 않아도 에이전트에 해당 심볼의 전체 컨텍스트를 제공합니다.

일반 텍스트를 원하면 Ctrl+Shift+V를 사용하세요.

플러그인 활성화/비활성화 가능

이전에는 MCP 서버나 플러그인을 비활성화하려면 제거해야 했습니다. 이제 켜고 끌 수 있습니다 — 전역적으로도 워크스페이스별로도. 확장 뷰나 커스터마이제이션 뷰에서 우클릭하면 됩니다.

npm과 pypi의 플러그인도 자동 업데이트가 가능하지만, 업데이트가 기기에서 새 코드를 실행하는 것을 의미하므로 먼저 승인을 요청합니다.

마무리

VS Code 1.112는 확실히 에이전트 경험을 강하게 밀어붙이고 있습니다 — 더 많은 자율성, 더 나은 디버깅, 더 단단한 보안. .NET 개발자에게 통합 브라우저 디버깅과 Copilot CLI 개선이 두드러진 기능입니다.

.NET 프로젝트를 위해 오토파일럿 모드에서 전체 Copilot CLI 세션을 아직 시도해보지 않았다면, 이번 릴리스가 시작하기 좋은 때입니다. 권한을 설정하고 맡기면 됩니다.

VS Code 1.112 다운로드 또는 VS Code 내에서 도움말 > 업데이트 확인으로 업데이트하세요.

노트북에서 프로덕션까지: 두 개의 명령으로 AI 에이전트를 Microsoft Foundry에 배포

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

“내 컴퓨터에서는 되는데"와 “배포되어 트래픽을 처리 중”—이 사이의 간극을 아시나요? AI 에이전트의 경우 이 간극은 고통스럽게 넓었습니다. 리소스 프로비저닝, 모델 배포, ID 설정, 모니터링 구축 — 이 모든 것이 누군가가 실제로 에이전트를 호출할 수 있기 전에 필요한 작업입니다.

Azure Developer CLI가 이것을 두 개의 명령으로 해결했습니다.

새로운 `azd ai agent` 워크플로

실제로 어떤 모습인지 보여드리겠습니다. AI 에이전트 프로젝트가 있다고 합시다 — 호텔 컨시어지 에이전트라고 하죠. 로컬에서 동작합니다. Microsoft Foundry에서 실행하고 싶습니다.

azd ai agent init
azd up

끝입니다. 두 개의 명령. azd ai agent init이 저장소에 Infrastructure as Code를 생성하고, azd up이 Azure에서 모든 것을 프로비저닝하고 에이전트를 퍼블리시합니다. Foundry 포털에서 에이전트로의 직접 링크를 받게 됩니다.

내부에서 일어나는 일

init 명령은 저장소에 실제 검사 가능한 Bicep 템플릿을 생성합니다:

Foundry Resource (최상위 컨테이너)
Foundry Project (에이전트가 존재하는 곳)
모델 배포 설정 (GPT-4o 등)
적절한 RBAC 역할 할당이 있는 관리 ID
서비스 맵용 azure.yaml
에이전트 메타데이터와 환경 변수가 있는 agent.yaml

핵심 포인트: 이 모든 것은 여러분 것입니다. 저장소에 버전 관리되는 Bicep입니다. 검사하고, 커스터마이즈하고, 에이전트 코드와 함께 커밋할 수 있습니다. 마법의 블랙박스는 없습니다.

개발 내부 루프

정말 마음에 드는 것은 로컬 개발 경험입니다. 에이전트 로직을 반복할 때, 프롬프트를 바꿀 때마다 재배포하고 싶지 않죠:

azd ai agent run

이것으로 에이전트를 로컬에서 시작합니다. azd ai agent invoke와 결합하여 테스트 프롬프트를 보내면 빠른 피드백 루프를 얻습니다. 코드 편집, 재시작, 호출, 반복.

invoke 명령은 라우팅도 똑똑합니다 — 로컬 에이전트가 실행 중이면 자동으로 그쪽을 타겟합니다. 실행 중이 아니면 원격 엔드포인트로 갑니다.

실시간 모니터링

이것이 저를 설득한 기능입니다. 에이전트가 배포되면:

azd ai agent monitor --follow

에이전트를 통과하는 모든 요청과 응답이 실시간으로 터미널에 스트리밍됩니다. 프로덕션 문제를 디버깅하는 데 이것은 값으로 매길 수 없습니다. Log Analytics를 뒤질 필요 없이, 메트릭이 집계되길 기다릴 필요 없이 — 지금 무슨 일이 일어나고 있는지 볼 수 있습니다.

전체 명령 세트

빠른 참조:

명령	기능
`azd ai agent init`	IaC로 Foundry 에이전트 프로젝트 스캐폴드
`azd up`	Azure 리소스 프로비저닝 및 에이전트 배포
`azd ai agent invoke`	원격 또는 로컬 에이전트에 프롬프트 전송
`azd ai agent run`	개발용으로 에이전트를 로컬에서 실행
`azd ai agent monitor`	퍼블리시된 에이전트의 실시간 로그 스트리밍
`azd ai agent show`	에이전트 상태 및 건강 확인
`azd down`	모든 Azure 리소스 정리

.NET 개발자에게 왜 중요한가

공지의 예제는 Python 기반이지만, 인프라 이야기는 언어에 구애받지 않습니다. .NET 에이전트도 동일한 Bicep 스캐폴딩, 동일한 관리 ID 설정, 동일한 모니터링 파이프라인을 받습니다. 그리고 이미 .NET Aspire 앱이나 Azure 배포에 azd를 사용하고 있다면, 기존 워크플로에 바로 통합됩니다.

AI 에이전트의 배포 간극은 생태계에서 가장 큰 마찰 포인트 중 하나였습니다. 작동하는 프로토타입에서 적절한 ID, 네트워킹, 모니터링을 갖춘 프로덕션 엔드포인트로 전환하는 데 일주일의 DevOps 작업이 필요해서는 안 됩니다. 이제 두 개의 명령과 몇 분이면 됩니다.

마무리

azd ai agent는 지금 사용할 수 있습니다. 인프라 설정이 너무 많은 작업처럼 보여서 AI 에이전트 배포를 미루고 있었다면 시도해 보세요. 프론트엔드 채팅 앱 통합을 포함한 완전한 단계별 가이드는 전체 워크스루를 확인하세요.

Ai | The .NET Blog

NL2SQL는 에이전트 시대의 SQL 인젝션이다

데모에서 아무도 이야기하지 않는 문제들

SQL MCP Server가 실제로 해결하는 것

올바른 질문

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를 사용한 배포 흐름

마무리

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

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

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

무엇을 얻나요

다섯 가지 산업 시나리오

결론

Foundry Local 1.1: 실시간 전사, Embeddings, Responses API

라이브 오디오 전사

텍스트 Embeddings

Responses API

패키지 크기 개선

왜 중요한가

Cosmos DB Shell이 공개 미리 보기 중 — 그리고 MCP 서버가 내장되어 있습니다

다른 데이터베이스 CLI와의 차별점

오픈 소스 기반이 중요합니다

더 쉬워지는 세 가지 시나리오

시작하기

Azure SQL이 이제 임베딩을 생성할 수 있습니다 — 순수 T-SQL로, 앱 레이어 없이

무엇을 하는가

전체 워크플로우

지원되는 API 형식과 옵션

.NET 애플리케이션에서 무엇이 가능해지는가

마무리

당신의 AI 에이전트에는 신원 문제가 있습니다 (그리고 이것이 그것을 해결하는 템플릿입니다)

핵심 문제: 인증 ≠ 인가

토큰 체인 작동 방식

템플릿이 배포하는 것

빌려올 가치 있는 설계 원칙

결론

Aspire 13.3: Kubernetes 지원, 브라우저 로그 및 Aspireify 스킬

Aspireify: 에이전트 지원 온보딩

퍼스트클래스 Kubernetes 및 AKS 배포

대시보드의 브라우저 로그

구조화된 명령 결과

결론

SDD Conference 2026

주제

발표자

티켓 및 정보

.NET의 Composable Stack으로 AI 기반 컨퍼런스 앱 만들기

ConferencePulse가 하는 일

Microsoft.Extensions.AI: 모든 것을 위한 하나의 추상화

DataIngestion 파이프라인

VectorData: 공급자에 독립적인 검색

MCP: 도구로서의 세션 콘텐츠

Agent Framework: 병렬 멀티 에이전트 요약

설계 원칙

Microsoft Agent Framework 3부: 도구에서 워크플로우까지 — 빌딩 블록이 딱 맞게 자리를 잡다

에이전트란 무엇인가 (vs. 챗봇)

`azd`를 사용한 배포 흐름