Agents | 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?

당신의 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

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

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

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 네이티브 설계는 이미 구축 중인 도구와 함께 작동한다는 것을 의미한다. 공식 발표를 확인해 시작해보자.

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 — 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 저장소에서 작동하는 예제를 확인하세요.

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에서 실제 에이전트형 워크플로우를 구축하는 실제 팀을 위해 준비되었다는 의미입니다. “엔터프라이즈 준비 완료"라는 신호를 기다리고 있었다면, 이것이 바로 그 신호입니다.

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를 통한 오픈 모델 추론 — 플랫폼이 본격적인 워크로드를 위해 준비되었습니다.

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

VS Code 1.116 — Agents 앱에 키보드 내비게이션과 파일 컨텍스트 자동완성 추가

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

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

VS Code 1.116은 2026년 4월 릴리스입니다. 최근 몇몇 업데이트보다 가벼운 편이지만, 변경 사항은 집중적이고 의미 있습니다 — 특히 Agents 앱을 매일 사용하고 있다면요.

공식 릴리스 노트를 바탕으로 무엇이 추가되었는지 살펴보겠습니다.

Agents 앱 개선 사항

Agents 앱은 일상 워크플로에 진정한 차이를 만드는 사용성 개선으로 계속 성숙해지고 있습니다:

전용 키바인딩 — 이제 변경 사항 뷰, 변경 사항 내의 파일 트리, 그리고 채팅 커스터마이제이션 뷰에 전용 명령과 키보드 단축키로 포커스를 맞출 수 있습니다. Agents 앱에서 여기저기 클릭하며 탐색하고 있었다면, 이제 완전한 키보드 기반 워크플로가 가능합니다.

접근성 도움말 대화상자 — 채팅 입력 상자에서 Alt+F1을 누르면 사용 가능한 명령과 키바인딩을 보여주는 접근성 도움말 대화상자가 열립니다. 스크린 리더 사용자는 안내 방송의 상세도도 제어할 수 있습니다. 좋은 접근성은 모든 사람에게 도움이 됩니다.

파일 컨텍스트 자동완성 — Agents 앱 채팅에서 #을 입력하면 현재 워크스페이스 범위의 파일 컨텍스트 자동완성이 트리거됩니다. 모든 상호작용을 빠르게 해주는 작은 편의성 개선 중 하나입니다 — 코드를 참조할 때 전체 파일 경로를 입력할 필요가 없어집니다.

CSS `@import` 링크 해석

프론트엔드 개발자에게 좋은 소식: VS Code가 이제 node_modules 경로를 사용하는 CSS @import 참조를 해석합니다. 번들러를 사용할 때 @import "some-module/style.css" 같은 임포트를 Ctrl+클릭으로 따라갈 수 있습니다. 작지만 CSS 워크플로의 마찰점을 제거합니다.

마무리

VS Code 1.116은 세련됨에 관한 것입니다 — Agents 앱을 더 탐색하기 쉽고, 더 접근 가능하며, 더 키보드 친화적으로 만드는 것. Agents 앱에서 상당한 시간을 보내고 있다면 (그리고 많은 분들이 그럴 것으로 생각합니다), 이러한 변경 사항들은 쌓여갑니다.

전체 목록은 전체 릴리스 노트를 확인하세요.

에이전틱 플랫폼 엔지니어링이 현실이 되고 있다 — Git-APE가 방법을 보여준다

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

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

플랫폼 엔지니어링은 컨퍼런스에서는 멋지게 들리지만 보통 “내부 포털과 Terraform 래퍼를 만들었습니다"를 의미하는 용어 중 하나였습니다. 진정한 약속 — 실제로 안전하고, 거버넌스가 적용되고, 빠른 셀프 서비스 인프라 — 는 항상 몇 발짝 떨어져 있었습니다.

Azure 팀이 에이전틱 플랫폼 엔지니어링 시리즈의 파트 2를 발표했는데, 이번에는 실전 구현에 대한 내용입니다. Git-APE라고 부릅니다 (네, 약어는 의도적입니다). 이것은 GitHub Copilot 에이전트와 Azure MCP 서버를 사용하여 자연어 요청을 검증되고 배포된 인프라로 전환하는 오픈소스 프로젝트입니다.

Git-APE가 실제로 하는 것

핵심 아이디어: 개발자가 Terraform 모듈을 배우거나, 포털 UI를 탐색하거나, 플랫폼 팀에 티켓을 올리는 대신, Copilot 에이전트와 대화합니다. 에이전트가 의도를 해석하고, Infrastructure-as-Code를 생성하고, 정책에 대해 검증하고, 배포합니다 — 모두 VS Code 안에서.

설정은 이렇습니다:

git clone https://github.com/Azure/git-ape
cd git-ape

VS Code에서 워크스페이스를 열면 에이전트 설정 파일이 GitHub Copilot에 의해 자동 검색됩니다. 에이전트와 직접 상호작용합니다:

@git-ape deploy a function app with storage in West Europe

에이전트는 내부적으로 Azure MCP Server를 사용하여 Azure 서비스와 상호작용합니다. VS Code 설정의 MCP 구성이 특정 기능을 활성화합니다:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

왜 이게 중요한가

Azure에서 개발하는 우리에게 이것은 플랫폼 엔지니어링 대화를 “포털을 어떻게 만들까"에서 “가드레일을 API로 어떻게 기술할까"로 전환시킵니다. 플랫폼의 인터페이스가 AI 에이전트가 되면, 제약 조건과 정책의 품질이 곧 제품이 됩니다.

파트 1 블로그는 이론을 제시했습니다: 잘 기술된 API, 제어 스키마, 그리고 명시적인 가드레일이 플랫폼을 에이전트 대응(agent-ready)으로 만듭니다. 파트 2는 실제 도구를 제공하여 이것이 작동한다는 것을 증명합니다. 에이전트는 리소스를 무작정 생성하지 않습니다 — 모범 사례에 대해 검증하고, 명명 규칙을 존중하며, 조직의 정책을 적용합니다.

정리도 마찬가지로 간단합니다:

@git-ape destroy my-resource-group

내 생각

솔직히 — 이건 특정 도구보다는 패턴에 대한 이야기입니다. Git-APE 자체는 데모/참조 아키텍처입니다. 하지만 근본적인 아이디어 — 플랫폼의 인터페이스로서의 에이전트, 프로토콜로서의 MCP, 호스트로서의 GitHub Copilot — 이것이 엔터프라이즈 개발자 경험이 향하는 방향입니다.

내부 도구를 에이전트 친화적으로 만드는 방법을 찾는 플랫폼 팀이라면, 이보다 나은 출발점은 없습니다. 그리고 .NET 개발자로서 이것이 자신의 세계와 어떻게 연결되는지 궁금하다면: Azure MCP Server와 GitHub Copilot 에이전트는 모든 Azure 워크로드에서 작동합니다. ASP.NET Core API, .NET Aspire 스택, 컨테이너화된 마이크로서비스 — 모두가 에이전틱 배포 플로우의 대상이 될 수 있습니다.

마무리

Git-APE는 에이전틱 플랫폼 엔지니어링 실전의 초기이지만 구체적인 모습입니다. 저장소를 클론하고, 데모를 시도하고, 에이전트가 안전하게 사용할 수 있도록 플랫폼의 API와 정책이 어떤 모습이어야 하는지 생각해 보세요.

자세한 워크스루와 데모 비디오는 전체 포스트를 읽어보세요.

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 에이전트라면 — 이번 업데이트는 가치가 있습니다.

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

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)

azure-ai-agents 패키지에서 오는 경우, 에이전트는 이제 azure-ai-projects의 AIProjectClient에서 퍼스트 클래스 작업입니다. 독립 의존성을 제거하고 get_openai_client()를 사용하여 응답을 구동하세요.

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

이것이 엔터프라이즈 채택의 잠금을 해제하는 기능입니다. 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 공지를 확인하세요.

Agents | The .NET Blog

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

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

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

올바른 질문

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

핵심 문제: 인증 ≠ 인가

토큰 체인 작동 방식

템플릿이 배포하는 것

빌려올 가치 있는 설계 원칙

결론

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

CodeAct란?

보안: Hyperlight 마이크로 VM

최소 설정

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

지금 시도해보세요

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

두 가지 기본 패턴

Agent Framework의 추상화 방식

공급자 빠른 참조

선택 방법

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

Toolbox란

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

실제 예시

Foundry Agents에 종속되지 않는다

지금 왜 중요한가

마무리

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

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

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

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

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

macOS Agents 앱 자동 업데이트

알아둘 만한 작은 것들

핵심 정리

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

6가지 옵션 한눈에 보기

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

배포가 진짜 간단합니다

내장 대화 관리

나의 결정 프레임워크

마무리

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

Azure MCP Server란?

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

보안 강화

어디서 사용할 수 있나요?

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

시작하기

마치며

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

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

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

SDK가 드디어 안정화

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

기타 하이라이트

마무리

VS Code 1.116 — Agents 앱에 키보드 내비게이션과 파일 컨텍스트 자동완성 추가

Agents 앱 개선 사항

CSS @import 링크 해석

마무리

에이전틱 플랫폼 엔지니어링이 현실이 되고 있다 — Git-APE가 방법을 보여준다

Git-APE가 실제로 하는 것

왜 이게 중요한가

내 생각

마무리

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

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

GitHub Copilot이 azd 프로젝트를 설정

Container App Jobs 및 배포 개선

DX 개선

마무리

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

Responses API 위에 구축

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

MCP 인증 제대로 하기

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

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

CSS `@import` 링크 해석