제가 3년 전부터 계속해 온 평소의 Update 속보입니다. Microsoft Foundry에서의 Microsoft Build 2026 업데이트는 단순한 신기능 추가가 아니라, 에이전트 개발을 '시제품(Prototype)' 단계에서 '본격적인 운영(Production)' 단계로 옮기기 위한 기반 정리로 볼 수 있습니다. 이번에 Microsoft는 Foundry를 모델, 에이전트, 도구(Tool), 지식(Knowledge), 메모리(Memory), 평가(Evaluation), 가드레일(Guardrails), 모니터링(Monitoring), 배포(Deployment)를 일체로 다루는 플랫폼으로 재정의하고 있습니다.

이번 핵심 메시지는 다음의 3가지입니다.

Build: Microsoft Agent Framework, Foundry Toolkit for VS Code, Toolboxes, Foundry IQ, Voice Live, Content Understanding을 통해, 개발자가 사용하는 프레임워크나 도구의 선택권을 유지하면서도 에이전트를 만들기 쉽게 한다.

Deploy: Hosted Agents, 소스 코드 배포, Teams / Microsoft 365 Copilot 공개, Agent 365, A2A를 통해, 에이전트를 이용자의 업무 화면으로 쉽게 전달한다.

Operate: 트레이스(Trace), 평가(Evaluation), ASSERT, Agent Control Specification, 가드레일(Guardrails), Rubric, Agent Optimizer, Purview 연동을 통해, 운영 환경에서 발생한 실패를 관측하고, 평가하여, 개선으로 되돌리는 루프를 만든다.

Build 2026에서는 Microsoft Agent Framework (MAF)가 Foundry 기반의 코드 퍼스트 (Code-first) 에이전트 개발의 중심으로 자리매김했습니다. MAF는 2026년 4월 2일에 1.0 GA에 도달했으며, AutoGen과 Semantic Kernel을 통합한 단일 플랫폼입니다.

새로운 기능이 대량으로 추가되어, 서둘러 워크숍도 업데이트해야겠네요...

Agent Harness는 모델 추론과 실행을 연결하는 레이어로 추가되었습니다. 다음과 같은 빌딩 블록 (Building Blocks)이 내장되어 제공됩니다.

컨텍스트 관리 (Context Management):

• 자동 컨텍스트 압축 (Automatic Context Compression): 토큰 사용량을 모니터링하고, 긴 도구 호출 체인 중에 대화 이력을 압축하여 컨텍스트 윈도우 (Context Window) 오버플로를 방지
• 기본 시스템 지침 및 지침 병합 (Default System Instructions and Instruction Merging): 작업 분해, 도구 사용, 추론 패턴을 위한 의견이 포함된 시스템 지침을 포함

내장 프로바이더 및 도구 (Built-in Providers and Tools):

• FileMemoryProvider: 세션 범위의 파일 기반 메모리 (agent-file-memory/{session}/에 저장)
• FileAccessProvider: 에이전트가 파일에 접근 및 변경하기 위한 범용 파일 액세스
• TodoProvider: 멀티 스텝 작업 관리를 위한 작업 항목 추적
• AgentModeProvider: "plan" vs "execute" 모드 전환
• AgentSkillsProvider: 파일 시스템으로부터의 스킬 발견 및 실행
• BackgroundAgentsProvider: 하위 에이전트에게 서브태스크 위임 (병렬 팬아웃 (Parallel Fan-out))
• Web Search: 내장 웹 검색 도구 (DisableWebSearch로 비활성화 가능)
• Shell Execution (.NET 전용): 샌드박스화된 ShellExecutor를 통한 쉘 명령 실행

미들웨어 및 커스터마이징 (Middleware and Customization):

• ToolApprovalAgent: 민감한 도구 호출에 대한 "앞으로 확인하지 않음" 승인 규칙
• OpenTelemetryAgent

: OpenTelemetry Semantic Conventions를 통한 자동 트레이스(Automatic Tracing) - 플러그형 스토리지 백엔드:
FileMemoryStore 및 FileAccessStore를 임의의 AgentFileStore 구현체(파일 시스템, Blob Storage 등)로 교체 가능합니다.

많은 에이전트의 병목 현상은 모델 품질이 아니라 오케스트레이션 오버헤드(Orchestration Overhead)에서 발생합니다. CodeAct는 모델이 개별 도구 호출을 순차적으로 선택하는 대신, call_tool(...)을 호출하는 짧은 Python 프로그램을 한 번 생성하고, 이를 샌드박스(Sandbox) 내에서 실행하여 결과를 한꺼번에 반환합니다.

CodeAct는 agent-framework-hyperlight (알파) 패키지로 제공되며, 생성된 코드는 Hyperlight micro-VM 내에서 실행되므로 호출마다 강력한 격리(Isolation)를 사실상 비용 없이 얻을 수 있습니다. 블로그에서는 대표적인 멀티 스텝 워크로드(다수의 사용자에 걸친 주문 합계 계산, 수십 개의 도구 호출 등)에서 유의미한 차이가 확인되었다고 보고했습니다.

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider
@tool
...

로컬 MAF 에이전트를 Hosted Agent로 전환하는 것은 몇 줄이면 충분합니다.

Python:

server = ResponsesHostServer(agent)
server.run()

.NET:

builder.Services.AddFoundryResponses(agent);
app.MapFoundryResponses();

Hosted Agent로 배포하면 스케일 투 제로(Scale-to-Zero, 유휴 시 비용 제로, 다음 요청 시 스케일 업), 파일 시스템 및 디스크 상태를 포함한 재개(Resumption), 세션별 VM 격리 샌드박스, OpenTelemetry 트레이스의 Application Insights 자동 연동을 얻을 수 있습니다.

MAF는 GitHub Copilot SDK를 백엔드로 지원하며, Copilot의 코딩용 기능(셸 실행, 파일 조작, URL 페치, MCP 서버 통합)을 표준 MAF 프로그래밍 모델로 가져올 수 있습니다. Copilot 에이전트는 표준 MAF 에이전트이므로 도구, 지시(Instruction), 스트리밍, 세션, MCP 서버, 내장된 OpenTelemetry 관측성(Observability)을 지원합니다.

Foundry Toolkit for VS Code는 일반 제공(GA)되며, 템플릿 또는 GitHub Copilot을 통한 에이전트 생성, 로컬 실행 및 디버깅, 트레이스 시각화, Toolboxes 연결, Foundry Agent Service로의 배포까지 VS Code 내에서 처리할 수 있습니다.

Toolboxes는 Web Search, Azure AI Search, Code Interpreter, File Search, MCP Server, OpenAPI 도구 등을 하나로 묶은 관리형 도구 번들(Tool Bundle)입니다. Toolboxes는 MCP 호환 엔드포인트를 공개하므로 Microsoft Agent Framework, LangGraph, GitHub Copilot SDK, 커스텀 코드 등 MCP를 지원하는 실행 환경에서 이용할 수 있습니다.

이번 업데이트는 도구의 스케일링 문제에 대한 대응에 중점을 두었습니다. 5개의 도구로 시작한 Toolbox가 50개 또는 200개로 성장하면 비용(모든 정의를 매 턴 전송함에 따른 토큰 소비), 컨텍스트 혼잡, 모델의 혼란이라는 세 가지 문제가 발생합니다.

Build 2026 업데이트에서는 Toolboxes에 다음 기능이 추가되었습니다.

• 도구 설정을 한 번 생성하여 여러 에이전트에서 재사용.
• Toolbox 버전을 생성하고, 검증 후 기본 버전으로 승격.
• 인증, 자격 증명 주입(Credential Injection), 토큰 갱신, 정책 적용을 중앙에서 처리.
• **스킬(Skill)**을 Toolbox 버전으로 연결하고 MCP Resources로 탐지.

Tool Search가 활성화된 Toolbox에서는 모든 도구 정의를 모델의 컨텍스트에 일괄 전송하는 대신, 두 가지 메타 도구(Meta-tool)만 공개됩니다.

tool_search

— 의도를 기술하여 가장 관련성이 높은 도구를 획득

call_tool

— 발견한 도구를 이름으로 호출

또한, 도구 서피싱(Tool Surfacing) 제어를 위해 다음과 같은 기능이 제공됩니다.

Pin: 특정 도구를 tool_search 이전에 항상 공개
추가 컨텍스트 (Additional Context): 팀의 이용 패턴에 맞게 도구 설명을 보완
Auto-pin: 빈번하게 사용되는 도구를 자동으로 항상 공개

Browser Automation은 Playwright 워크스페이스를 사용한 MCP 네이티브 웹 자동화입니다. Hosted Agents에 웹 브라우저 조작 기능을 도입하며, 에지 케이스(Edge case)에서는 실시간 가시성과 제어 기능을 제공합니다. 이를 통해 에이전트가 복잡한 웹 태스크를 자율적으로 자동화할 수 있습니다.

Foundry Tools Catalog에는 SaaS 및 비즈니스 애플리케이션에 대한 사전 구축된 통합(Integration)이 포함되어 있습니다. 커넥터를 추가하면 Foundry가 Managed MCP server를 프로비저닝하여, Jira, Confluence, LinkedIn, Box 등의 시스템에서 커스텀 통합 없이도 액션을 실행할 수 있습니다.

Work IQ는 에이전트에게 Microsoft 365 전반의 조직 데이터와 컨텍스트에 대한 액세스 권한을 제공합니다. 기존 권한 및 정책을 기반으로 지속적으로 업데이트되는 이해도를 구축하며, 로우 데이터(Raw data)를 노출하지 않고도 복잡한 멀티 스텝(Multi-step) 태스크를 처리합니다.

Fabric IQ는 에이전트를 비즈니스 운영 및 분석 상태에 연결합니다. 온톨로지(Ontology), Fabric Data Agents, Power BI Semantic Models을 통해 자연어로 비즈니스 데이터를 쿼리할 수 있습니다.

도구와 Toolbox의 사용 규모가 커짐에 따라, 관리자는 에이전트의 행동을 명확하게 거버넌스(Governance)해야 합니다. Foundry Control Plane의 Guardrails를 통해 도구 입력과 도구 출력 모두에 정책을 적용할 수 있으며, 컴플라이언스 위반, 민감 데이터 유출, 안전하지 않은 콘텐츠, 의도치 않은 태스크 이탈을 차단할 수 있습니다.

주의 사항으로, Toolboxes는 퍼블릭 프리뷰(Public Preview) 상태이며 일부 API는 실험적입니다. 또한, 스킬(Skill)은 동일한 Foundry 프로젝트 내에 있어야 하며, 프로젝트 간 스킬 참조는 지원되지 않습니다.

Build 2026에서는 Foundry IQ가 Foundry 에이전트의 백엔드 지식 레이어(Knowledge layer)로서 강조되었습니다. Foundry IQ는 Work IQ, Fabric IQ, Azure SQL, File Search, MCP Source 등을 하나의 SLA가 보장되는 Retrieval 엔드포인트로 통합하여, 에이전트가 기업 내외부의 지식을 안전하게 취득할 수 있도록 합니다. Serverless tier는 퍼블릭 프리뷰 상태입니다.

특히 중요한 점은 RAG(Retrieval-Augmented Generation)의 구현 책임이 애플리케이션 측에서 Foundry IQ / Azure AI Search 측으로 이동하고 있다는 것입니다. 기존에는 청킹(Chunking), 인덱싱(Indexing), 권한 동기화, 리랭킹(Re-ranking), 인용(Citation), 다중 데이터 소스 통합을 개별적으로 구축해야 했습니다. Build 2026의 Foundry IQ 업데이트에서는 이를 지식 베이스(Knowledge base), 지식 소스(Knowledge source), Agentic Retrieval, MCP 엔드포인트로서 관리할 수 있습니다.

Foundry IQ에 대한 모든 업데이트 정보는 다음을 참조하십시오.

Memory는 에이전트가 세션을 넘어 유지할 수 있는 장기 기억을 구현할 수 있습니다.

엔터프라이즈 배포에서 빈번하게 발생하는 실패 패턴으로, "올바른 사실을 알고 있음에도 올바른 절차를 실행하지 않는" 문제가 지적되고 있습니다. Procedural Memory는 이 격차를 메우기 위해 설계되었으며, 2단계로 동작합니다.

• 수집 및 감사 (Ingestion & Auditing): 에이전트의 궤적 (trajectories)을 수집하여 성공 패턴, 비효율적인 경로, 누락된 단계를 식별합니다. 이를 구조화된 절차적 메모리 (Procedural Memory) 항목으로 추출하여, "언제 사용할 것인가" (태스크 컨텍스트, 전제 조건, 시그널)와 "무엇을 할 것인가" (순서가 지정된 액션, 필요한 체크리스트, 도구 사용 방법)를 기록합니다. -
  검색 및 주입 (Retrieval & Injection): 유사한 태스크에 직면했을 때 관련 절차를 검색하여 에이전트의 컨텍스트에 주입합니다. 필요한 검증 (validation), 올바른 도구 파라미터, 정책 강제와 같은 명시적인 스텝 레벨 제약 사항을 포함하여, 에이전트가 검증된 경로를 따르도록 가이드합니다.

Agent Optimizer와 결합함으로써, 설계 시의 프롬프트 및 도구 최적화와 런타임에서의 실제 태스크 실행으로부터의 학습을 통합한 자기 개선 (self-improving) 에이전트를 구축할 수 있습니다.

그러고 보니 작년에 저는 「AutoGen의 실험적 기능 Task-Centric Memory를 통한 AI 에이전트의 기억 저장」이라는 글을 썼는데, 그것과의 공통점은 다음과 같습니다.

AutoGen 시대의 Task-Centric Memory가 "일반적인 가르침의 기억과 재사용"이라면, Foundry의 Procedural Memory는 "실행 절차서의 자동 생성·검색·주입"에 초점을 맞춘, 더욱 구조화된 프로덕션 버전이라고 할 수 있을 것 같습니다. MAF가 AutoGen을 통합한 경위를 고려하면, Task-Centric Memory 연구가 그대로 Procedural Memory의 설계 기반이 되지 않았을까 생각합니다.

다음 기능들이 추가되었습니다.

• 포털 UI에서의 메모리 관리: Foundry 포털에서 저장된 메모리를 직접 열람하고, 개별 메모리 항목을 CRUD 작업으로 관리할 수 있는 새로운 UX/UI입니다. 메모리를 블랙박스가 아닌, 검사 및 조정 가능한 대상으로 다룰 수 있습니다. -
  Memory TTL (Time-to-Live): 메모리 스토어 생성 시 기본 TTL을 설정하여, 오래되거나 가치가 낮은 메모리를 자동으로 폐기합니다. 검색 품질 향상과 스토리지 비용 제어에 유효합니다. -
  Multimodal Memory: 이미지로부터 정보를 이해하고 기억하는 기능입니다. 특히 EC(전자 상거래)나 고객 지원 시나리오에서 유용합니다. -
  Direct Memory Commands: 사용자가 에이전트에게 "이것을 기억해", "이것을 잊어"라고 명시적으로 지시할 수 있어, 투명성과 사용자 제어력을 향상시킵니다. # 메모리 스토어 옵션 지정 예시 options = MemoryStoreDefaultOptions( chat_summary_enabled=True, user_profile_enabled=True, procedural_memory_enabled=True, default_ttl_seconds=30 * 24 * 60 * 60, user_profile_details=( "연령이나 재무 정보 등, 본론과 관계없는 정보나 기밀성이 높은 정보는 피해주세요" "혹은, 향후 대화의 개인화에 도움이 되지 않는 정보는 모두 피해주세요." ), )

Microsoft Agent Framework에 파일 기반 메모리 지원이 추가되었다는 소식도 발표되었습니다. 로컬의 Markdown (.md) 파일로 시작하여, 개발 모델을 변경하지 않고도 확장할 수 있습니다.

from agent_framework import Agent, MemoryContextProvider, MemoryFileStore
store = MemoryFileStore(
base_path=Path("./memory"),
...

하지만 메모리는 편의성과 동시에 리스크도 수반합니다. 프롬프트 인젝션 (Prompt Injection)이나 메모리 오염을 방지하기 위해, Azure AI Content Safety를 통한 프롬프트 검증과 통제된 환경에서의 적대적 테스트 (Adversarial Testing) 실시가 권장됩니다. 또한, 메모리 관리 기능으로서 스토어 레벨의 기본 TTL (Time To Live) 설정, 항목 레벨의 CRUD (생성·읽기·수정·삭제), 스코프(Scope)에 따른 사용자 단위의 데이터 분리, 다이렉트 메모리 커맨드 (즉각적인 기억 및 망각)가 제공됩니다. 메모리를 사용할 경우에는 지식 베이스 (Knowledge Base)와는 별개로, 사용자 단위 및 에이전트 단위의 데이터 경계 (Data Boundary)를 설계해야 합니다.

참고로 며칠 전, 저는 다음과 같은 글을 막 작성한 참이었는데요... 뭐, 기억의 망각에 대한 개념은 당연한 것이겠지요.

Voice Live는 음성 인식, 텍스트 읽어주기 (TTS), 턴 감지 (Turn Detection), 인터럽트 처리 (Interrupt Handling), 아바타, 실시간 대화 기능을 하나의 API로 통합한 것입니다. Prompt Agent를 위한 Voice Live는 일반 제공 (GA) 상태이며, Hosted Agents와 Voice Live의 조합은 퍼블릭 프리뷰 (Public Preview) 상태가 되었습니다.

Hosted Agents의 실시간 음성 워크로드(Workload)는 invocations_ws가 WebSocket 프로토콜을 사용한다고 설명되어 있습니다. 다만, 2026-06-03 시점 기준으로 invocations_ws는 퍼블릭 프리뷰 단계이며, North Central US 지역에서만 이용 가능합니다. WebRTC를 사용한 실시간 음성 시나리오도 지원되며, Invocations (WebSocket) 프로토콜과 Voice Live, Pipecat, LiveKit 등의 프레임워크를 컨테이너 내에서 조합함으로써 마이크 입력부터 음성 출력까지의 완전한 실시간 음성 에이전트를 구축할 수 있습니다.

Content Understanding (CU)에 대해서는 송장, 문서, 이미지, 음성, 영상 등으로부터 구조화된 정보를 추출하며, RAG, 지능형 문서 처리, 에이전트 플로우 (Agent Flow)의 도구로 사용할 수 있습니다.

GPT 5.2를 통한 추출 품질 향상:

CU의 분석기 (Analyzer)는 Foundry에 배포된 LLM (Large Language Model)에 의해 구동됩니다. Build 2026에서는 GPT 5.2 지원이 추가되어 커스텀 필드 추출 기능이 강화되었습니다. 혼합 레이아웃, 도메인 특화 언어 (Domain-Specific Language), 다국어 문서에서도 프롬프트 엔지니어링 (Prompt Engineering)의 별도 노력 없이도 정확한 추출이 가능합니다. 기존의 GPT 4.1 기반 분석기는 변경 없이 계속 동작합니다.

Foundry 포털에서의 통합: