안녕하세요, Build를 너무 열심히 쫓아가느라 수면 부족 기미가 보이는 아키텍트 야마판(やまぱん！)입니다.

보충 코멘트나 질문, 좋아요, 확산(공유) 꼭 부탁드립니다 🥺!

틀린 부분이 있다면 부드럽게 알려주세요!

이번에는 Microsoft Build 2026의 keynote를 기점으로 X, Microsoft Learn, 공식 blog, GitHub Changelog까지 쫓아갔습니다. 전부를 망라하기보다는, 제 안에서 "이것들은 같은 선상에 있구나"라고 느껴진 발표에 집중해서 쓰겠습니다.

2026/06/03 시점의 정리입니다.

이 기사에서는 Microsoft의 공식 blog / Learn / GitHub / GitHub Changelog를 중심으로, 필요한 부분에만 X 게시물이나 보도를 보조선으로 사용하고 있습니다. Preview / Early Access / GA의 차이가 남아 있는 것은 그 변동성까지 포함하여 작성하고 있습니다.

Build 직후에는 rollout이나 docs 업데이트로 인해 표기가 바뀌기 쉬우므로, 실제로 시도하기 전이나 설명에 사용하기 전에는 링크된 1차 정보도 확인해 주세요.

• Build 2026에서는 Scout, OpenClaw, Agent 365, Windows 365 for Agents, Foundry, GitHub까지, Agent 시대의 부품들이 같은 선상에 나열되었습니다.
• 핵심 축이 된 것은,
  Scout / MXC / OpenClaw on Windows / Work IQ APIs / Agent 365 / Windows 365 for Agents가 하나로 연결되어 있었다는 점입니다.
• Microsoft Scout는 현재 공개된 정보 기준으로 Windows / macOS용 desktop AI application입니다. M365 Copilot의 화면 그 자체가 아닙니다. Microsoft 365와 GitHub Copilot의 전제 조건을 가진 별개의 앱으로 구분합니다.
• Foundry와 GitHub는 agent를 만들고 구동하는 계층을 한 단계 앞으로 밀어냈습니다. prototype에서 끝내지 않고, runtime, sandbox, memory, evaluation, SDK, CLI, backend / data까지 갖추러 왔습니다.
• 후반부에서는 Discovery, MAI models, Frontier Tuning, Cobalt 200, Project Solara까지 등장했습니다. agent를 강력하게 만드는 model / tuning과, agent를 배치하는 compute / device를 다루고 있습니다.

이 기사는 Build 2026을 전부 쫓지 못한 분들을 위한 초입문서가 아닙니다. keynote나 live blog에서 단편적으로 보였던 것들을, 어느 계층(layer)의 이야기였는지를 통해 다시 연결하기 위한 메모입니다.

제목에 넣은 나만의 Book of News도 그런 의도로 붙였습니다. Microsoft의 공식적인 Book of News를 대체하는 기사가 아닙니다. Microsoft Build Live와 개별 blog / Learn / GitHub Changelog를 자신만의 순서로 다시 나열한 메모입니다.

Build 2026의 keynote를 그대로 시계열로 쫓다 보면 저는 중간에 머리가 포화 상태가 되었습니다. 그래서 일단 4개 계층으로 나누었습니다.

keynote에서는 Scout나 OpenClaw의 실행 환경, Microsoft IQ의 문맥 레이어(context layer), Foundry / GitHub의 개발 도구, MAI models, Cobalt 200, Surface RTX Spark Dev Box까지 같은 자리에서 등장했습니다.

가장 먼저 선으로 연결된 것은, agent를 로컬 PC나 Cloud PC에서 상시 구동하며 실제로 작업을 수행하게 한다는 전제가 명확히 드러난 부분이었습니다.

Windows blog에는 Coreutils for Windows와 같은 개발자 경험(developer experience)의 업데이트도 있습니다. 여기서 주로 보고 싶은 것은 agent runtime 측면입니다.

Autopilots 소개 슬라이드. Build 2026에서는 우선 「always-on」, 「long-running」, 「autonomous agents (자율 에이전트)」라는 카테고리명을 그대로 내걸고 있었습니다.

2026년 6월 2일 자 Microsoft 365 blog의 Scout 발표에서는, Scout를 first Autopilot으로 정식 출시했습니다.

Scout는 Microsoft Scout overview와 Admin access overview를 살펴보면, **Windows / macOS에서 동작하는 desktop app (데스크톱 앱)**입니다. M365 Copilot의 새로운 화면에 그대로 탑재된 형태가 아닙니다. Frontier preview 단계로, Microsoft 365 측의 활성화, Intune policy (인튠 정책), 관리자 attestation (증명), GitHub Copilot Business / Enterprise 라이선스까지 갖추어 도입되는 설계입니다. 발표의 중점은 UI 추가보다는, enterprise (엔터프라이즈)를 위한 local agent (로컬 에이전트)를 어떻게 공개하고 관리할 것인가에 있었습니다.

GitHub Copilot 측의 전제 조건 또한 주의해야 할 부분입니다. Admin access overview에서는 Frontier access만으로도, 혹은 GitHub Copilot 라이선스만으로도 부족하다는 식으로 기술되어 있습니다. 적어도 현재의 docs (문서) 상으로는, Microsoft 365 측의 Frontier 활성화와 GitHub Copilot Business / Enterprise 측의 전제 조건을 모두 확인해야 합니다.

Microsoft Scout (Frontier) overview에서는 Scout가 다룰 수 있는 범위로 다음 사항들을 확인할 수 있습니다.

• 파일 읽기 및 쓰기
• shell command (셸 명령) 실행
• Playwright를 이용한 browser automation (브라우저 자동화)
• Microsoft 365로의 접속
• heartbeat / automations을 통한 background (백그라운드) 실행
• sub-agent delegation (서브 에이전트 위임)

공개된 docs에서 눈에 띄는 점은, Scout가 desktop app (데스크톱 앱)과 local resources (로컬 리소스)까지 reach (접근 권한)를 가지고 있다는 점입니다. 이러한 성격이 OpenClaw on Windows나 MXC에 관한 이야기로 이어집니다.

이름도 다소 복잡합니다. Admin Intune setup에서는 설정명이 AllowScoutFrontierAccess인데,

UI 라벨에는 Allow Clawpilot Frontier access가

남아 있습니다. pre-release (사전 출시) policy templates (정책 템플릿)나 screenshots (스크린샷)에는 internal product name (내부 제품명)이 남을 수 있다고 명시되어 있습니다. Build Live의 Scout 유도 경로에도 ProjectLobster의 단축 URL이 남아 있었습니다. 저는 **Scout를 public brand (공식 브랜드)로, ClawPilot / Project Lobster를 전환기의 internal naming / alias (내부 명칭/별칭)**로 해석하고 있습니다.

OpenClaw on Windows 데모. Node Sandbox, Security level, Permissions가 나열되어 있으며, containment (격리) 및 permission (권한) 설계까지 product surface (제품 표면)에 드러나 있었습니다.

Windows Developer Blog는 Build 2026에서 **Microsoft Execution Containers (MXC)**를 early preview (조기 프리뷰)로 출시하며, 그 위에서 **OpenClaw now runs natively on Windows leveraging MXC (OpenClaw가 이제 MXC를 활용하여 Windows에서 네이티브로 실행됨)**라고 명시했습니다.

OpenClaw 측의 입구는 우선 openclaw/openclaw입니다. OpenClaw 본체는 사용자의 device (장치)에서 실행되는 personal AI assistant (개인용 AI 어시스턴트)이며, gateway (게이트웨이)를 control plane (제어 평면)으로 사용합니다. Windows에서 사용하는 경우, Windows companion suite인 openclaw/openclaw-windows-node가 실제 입구가 됩니다.

Windows 측 README에서는 OpenClaw Windows Hub로서 system tray app, shared client library, CLI validator가 하나로 묶여 있습니다. Quick Start에는 "end-user installer는 docs/SETUP.md를 참조할 것"이라고 명시되어 있어, 빌드가 필요 없는 경로도 마련되어 있습니다. 개발자로서 빌드할 경우의 전제 조건은 공개된 README 상에서 다음과 같습니다.

• Windows 10 20H2 이후 또는 Windows 11
• .NET 10.0 SDK
• Windows 10 SDK (WinUI 빌드용)
• WebView2 Runtime

OpenClaw 본체 측은 README에 Node 24 권장 또는 Node 22.19 이후라고 기재되어 있습니다. 셋업은 npm install -g openclaw@latest로 시작하여, openclaw onboard --install-daemon을 통해 gateway, workspace, channels, skills의 초기 설정으로 진행하는 흐름입니다. Windows에서는 WSL2를 경유하는 것이 strongly recommended(강력히 권장)됩니다.

OpenClaw on Windows의 핵심은 Windows PC를 OpenClaw agent가 다룰 수 있는 node로 만드는 것입니다. Windows Hub의 Node Mode를 활성화하면 gateway에 device pairing request(장치 페어링 요청)가 나타나며, openclaw devices approve <id>로 승인합니다. 그 후 gateway 측의 allowlist(허용 목록)에 system.run, canvas.present, screen.snapshot, camera.snap, tts.speak 등 허용하고자 하는 command(명령)를 명시적으로 입력합니다.

독자가 직접 테스트해 본다면 다음과 같은 순서가 적절합니다.

• openclaw/openclaw에서 gateway / assistant 본체를 셋업한다
• openclaw/openclaw-windows-node에서 Windows Hub를 설치하거나 빌드한다
• Windows Hub의 Node Mode를 활성화하여 gateway와 페어링한다
• gateway 측에서 command allowlist와 exec approval policy(실행 승인 정책)를 제한한다
• openclaw nodes invoke 등으로 Windows node에 대해 알림, Canvas, 스크린샷, command 실행을 시도한다

이 데모에서 저는 OpenClaw를 enterprise(기업용) 환경에서 구동할 때 필요한 containment(격리) / permission(권한) / policy(정책)를 Windows 측이 담당하기 시작했다는 점에 주목했습니다. Windows에서 native(네이티브)하게 동작하는 것과 실행 시의 containment를 동일한 발표 내에서 다루고 있습니다.

microsoft/mxc의 README에서는 현 시점이 early preview(초기 프리뷰) 단계이므로, 현재의 profile을 security boundary(보안 경계)로 취급해서는 안 된다고 명시하고 있습니다. 적어도 현재의 공개 정보로 볼 때, 이는 완성된 형태의 폐쇄적인 제품이 아닙니다. OS 레벨의 containment foundation(격리 기반)을 public(공개)으로 내놓고, 그 위에 OpenClaw 등을 얹기 시작한 단계입니다.

특히 system.run이나 screen.record, camera / microphone / location 관련 기능은 편리한 만큼 경계 설계가 중요합니다. OpenClaw Windows Hub 측에서도 gateway-side allowlist와 node-local exec approval policy는 별개의 것으로 취급됩니다. Build 데모 화면에 permissions(권한)나 security level(보안 수준)이 나타났던 이유는, 이것이 단순한 편의 기능이 아니라 agent가 Windows를 조작할 수 있도록 하기 위한 권한 설계이기 때문입니다.

Windows 365 for Agents in Agent 365는 Agent 365가 reasoning / orchestration(추론/오케스트레이션)에 집중하고, Windows 365 for Agents가 **execution layer(실행 계층)**를 담당한다고 정리하고 있습니다.

What’s new in Windows 365 for Agents에서는 2026년 6월 1일 주(Week of June 1, 2026)에 **GA(General Availability, 정식 출시)**라고 명시되어 있습니다. 반면, What is Windows 365 for Agents?나 Pricing for Windows 365 for Agents에는 preview(미리보기) 표기가 남아 있으며, public preview(공개 미리보기)는 미국(United States)에서만 가능하다고도 적혀 있습니다. 서비스(surface)마다 가용성 관련 문구(availability wording)가 흔들리고 있습니다.

Agent가 Cloud PC를 check-out / check-in 하면서 UI를 실행합니다. 문서(docs)는 그 전제를 명확히 기술하고 있습니다. API만으로 완결되지 않는 작업을 제대로 된 enterprise execution environment(엔터프라이즈 실행 환경)에서 구동하는 것까지 포함되어 있습니다.

Agent 365는 조직 내에 늘어가는 agent를 observe / govern / secure(관찰/거버넌스/보안)하기 위한 control plane(제어 평면)입니다.

Agent 365 overview에서는 2026년 5월 1일 시점에 commercial segment(상업용 부문)에서 user-per-user 방식의 GA라고 적혀 있습니다. Build 당일에 갑자기 생겨난 신조어라기보다는, control plane 측의 공개 정보는 5월 시점에 이미 나와 있었습니다.

저는 이를 Microsoft 365 admin center의 Agent registry, Microsoft Entra, Microsoft Purview, Microsoft Defender 측의 통합을 가로질러 사용하는 control plane이라고 읽고 있습니다. Agent 365 자체는 활성화를 위해 특정 제품 전제 조건을 요구하지 않는 반면, 문서(docs)에서는 적어도 1명에게 qualifying Microsoft Agent 365 license(자격 요건을 갖춘 Microsoft Agent 365 라이선스)를 할당해야 하며, Entra P1 / P2 또는 Entra Suite, Purview DLP와의 병용이 권장됩니다.

Agent 365 overview에 따르면, 적어도 공개 문서(docs)상으로는 다음의 세 가지 기둥으로 구성됩니다.

• Observe: agent registry와 activity(활동)를 가로질러 가시화한다
• Govern: 라이프사이클, 액세스 제어, 리뷰를 일원 관리한다
• Secure: Entra, Purview, Defender와 연결하여 runtime protection(런타임 보호)을 적용한다

Scout, MXC, Windows 365 for Agents만을 쫓다 보면 "어디서 구동되는가"에 대한 이야기가 중심이 됩니다. Agent 365는 해당 agent를 기업으로서 어떻게 바라보고 어떻게 관리할 것인가를 담당합니다.

여기에 **Microsoft Defender for Endpoint의 local AI agent discovery(로컬 AI 에이전트 탐지)**가 들어옵니다. Public Preview로 등장한 Build 2026의 보안(security) 측면에서 저는 조금 흥미를 느꼈습니다. local AI agent를 Defender의 inventory(인벤토리)에 올린다는 방식으로 제시되었기 때문입니다.

The next frontier in endpoint security: Securing local AI agents with Microsoft Defender에서는 Microsoft Defender가 local AI agents를 **first-class asset(1급 자산)**으로 취급하며, 전용 inventory, exposure map(노출 맵), Advanced Hunting, 나아가 일부 agent에 대해서는 runtime protection까지 제공합니다.

Docs의 Local AI agent discovery with Microsoft Defender for Endpoint (Preview)를 보면, 적어도 preview의 공개된 측면에서는 다음 사항이 명시되어 있습니다.

• 온보딩된(onboarded) 장치 상의 local AI agents 및 MCP server configurations를 자동 discovery하여 - Defender portal 상에서 inventory / exposure map / Advanced Hunting에 출력 - 지원되는 local agents로서 GitHub Copilot CLI, Codex CLI, Gemini CLI, Cursor, Windsurf, GitHub Copilot extension, OpenClaw, Clawpilot, Ollama Desktop 등을 언급하고 있습니다.

적용 대상은 Microsoft Defender for Endpoint Plan 2이며, 문서(docs)상으로는 Windows endpoints 상의 supported local AI agents가 대상입니다. 이는 만능 인벤토리 기능이 아니라, 지원 대상인 local agent와 MCP server configuration을 user / device / agent type의 조합으로서 Defender portal에 노출하는 기능으로 구분해야 합니다.

Build 2026에서는 에이전트(agent)를 만드는 이야기에서 그치지 않습니다. 엔드포인트(endpoint) 상에서 누가 어떤 에이전트를 구동하고 있으며, 그 에이전트가 어디까지 도달하는지를 Defender를 통해 모니터링하는 단계까지 포함되어 있습니다.

'Protect AI assets from emerging threats and vulnerabilities using Microsoft Defender'에서는 Defender가 Agent 365-managed agents와 통합되어, local AI agents discovery 및 runtime protection을 그 일부로서 다룬다고 명시되어 있습니다. 저는 이를 Agent 365의 Secure 영역을 MDE가 엔드포인트에서 담당한다는 발표로 해석하고 있습니다.

IQ

슬라이드에서는 Work IQ / Fabric IQ / Foundry IQ / Web IQ의 4가지가 Context → Decisions → Actions를 연결하는 공통 지능 계층(common intelligence layer)으로서 나열되어 있었습니다.

Build 2026의 전반부에서 Microsoft는 에이전트의 가치를 '모델의 똑똑함'보다 컨텍스트(context)의 질에 더 가깝게 배치했습니다. 그 상위 개념으로 등장한 것이 바로 Microsoft IQ입니다.

Build Live에서는 Microsoft IQ를 shared intelligence foundation으로 취급하며, 그 안에 다음 4가지가 나열되었습니다.

• Work IQ: 사람, 회의, 이메일, 채팅, 일정 등 Microsoft 365의 업무 컨텍스트(work context)
• Fabric IQ: 비즈니스 데이터(business data) 및 시맨틱 레이어(semantic layer) 측면의 컨텍스트
• Foundry IQ: 에이전트로부터 엔터프라이즈 지식(enterprise knowledge)을 가져오는 검색(retrieval) 측면
• Web IQ: 웹(web) / 뉴스(news) / 이미지(image) / 비디오(video) 그라운딩(grounding)

'What’s new in Microsoft Foundry | Build Edition'에서는 Foundry IQ를 Work IQ, Fabric IQ, Azure SQL, File Search, MCP sources를 통합하여 다루는 **지식 계층(knowledge layer)**으로 설명합니다. 매번 RAG를 구축하기보다, 우선 이곳으로 데이터를 모으는 방식입니다.

동시에 'Announcing the new Work IQ APIs'에서는 Work IQ API를 Chat / Context / Tools / Workspaces의 4개 도메인으로 제공합니다. Work IQ 또한 에이전트가 추론(reasoning)하면서 도구(tool)를 호출하고, 중간 결과물을 워크스페이스(workspace)에 배치하기 위한 context + tools layer를 전제로 하고 있습니다.

Work IQ API 개요 (overview)에서는 Work IQ API가 preview 상태로 정리되어 있습니다. A2A와 local MCP는 이용 가능하며, REST와 remote MCP는 coming soon(출시 예정) 상태입니다. 요청은 로그인된 사용자(signed-in user)의 컨텍스트(context)로 실행되며, Microsoft 365의 권한(permissions), 민감도 레이블(sensitivity labels), 준수 정책(compliance policies)을 계승합니다. Work IQ API는 Microsoft 365의 업무 문맥을 권한이 제한된(permission-trimmed) 형태로 에이전트(agent)에게 전달하는 입구입니다.

Web IQ는 외부 세계(outside world)에 대한 그라운딩 (grounding), Fabric IQ는 업무 데이터, Work IQ는 사람과 절차라는 순서로 설명되었습니다. Foundry routines와 결합하면, 단발성 응답(one-time response)을 스케줄(schedule)이 포함된 지속 실행으로 전환할 수 있습니다. IQ는 단순히 검색 API를 추가하는 것이 아닙니다. Work IQ, Fabric IQ, Foundry IQ, Web IQ를 에이전트가 중간에 참조하는 문맥의 입구로서 나란히 배치하고 있습니다.

Scout의 Work IQ powered 역시 이 흐름에 포함됩니다. Scout는 로컬 런타임(local runtime)만으로 완결되지 않고, M365 측의 인텔리전스 레이어(intelligence layer)를 데스크톱 측으로 끌어오고 있습니다. Foundry 측에서는 동일한 개념을 엔터프라이즈 검색(enterprise retrieval)이나 웹 그라운딩(web grounding)까지 확장했습니다. Build 2026의 IQ 관련 발표는 M365와 Foundry를 가로질러 에이전트에게 문맥을 전달하는 입구를 통일한 발표로 보고 있습니다.

Build 2026에서는 Foundry와 GitHub가 정확히 중간 계층을 채우러 왔습니다. 에이전트를 "만들고", "육성하고", "병행하여 실행하고", "평가하고", "배포(publish)하는" 영역입니다.

Foundry 측 데모 화면. 평가 요약(evaluation summary), 실행 상세(run details), 샘포 데이터(sample data)까지 나열되어 있으며, 평가와 개선 기능도 제품 인터페이스(product surface)에 포함되어 있었습니다.

'What’s new in Microsoft Foundry | Build Edition'과 'What’s New in Hosted Agents in Foundry Agent Service'를 종합하면, Foundry는 프로덕션 런타임(production runtime) 측으로 기울어 있습니다.

이 발표 그룹은 다음 4가지 항목으로 보면 파악하기 쉽습니다.

• hosted agents: 세션 샌드박스(session sandbox)와 지속적 상태(persistent state)를 갖춘 코드 우선(code-first) 에이전트 실행 런타임
• Toolboxes: MCP / OpenAPI / IQ / 검색 계열의 툴 표면(tool surface)을 통합하는 관리형 엔드포인트(managed endpoint)
• Memory: 세션(session) / 사용자(user) / 절차적 메모리(procedural memory)
• Agent Optimizer / Rubric: 프로덕션 트레이스(production trace)와 평가를 바탕으로 프롬프트(prompt) / 스킬(skill) / 툴 설명(tool description)을 정교화하는 기능

Hosted agents 문서에서도 샌드박스(sandbox), 지속적 파일 시스템(persistent filesystem), 에이전트 ID(agent identity), Toolbox MCP 엔드포인트(endpoint), OpenTelemetry 트레이스(trace)가 갖춰져 있습니다. Foundry는 샌드박스, 지속적 파일 시스템, 에이전트 ID, 트레이스까지 포함하여 에이전트를 프로덕션에 올리는 장소로 거듭나고 있습니다.

Hosted agents의 제공 상태는 Build Edition 블로그에서 2026년 7월 초까지 GA(General Availability) 도달 전망이라고 안내되었으며, Hosted Agents 전용 블로그에서는 2026년 6월 말에 GA로 진행될 예정이라고 안내되어 있습니다. Learn 본문에는 preview 표기가 남아 있으나, Build 블로그의 문맥상으로는 **GA를 향해 가는 프로덕션 에이전트 호스팅(production agent hosting)**입니다.

구성으로는, 자신의 agent code를 container image로 Azure Container Registry에 배치하고, Foundry Agent Service가 이를 pull 하여 세션(session)별 VM-isolated sandbox, persistent filesystem, 전용 Microsoft Entra ID, 전용 endpoint를 준비합니다. Toolbox 또한 자동으로 주입되는 방식이 아니라, Foundry project 측의 Toolbox MCP endpoint에 agent code가 접속하는 방식입니다. third-party model / tool / server와 조합하여 사용할 경우의 데이터 경계나 비용은 사용하는 측에서 확인할 필요가 있습니다.

Build의 Foundry는 runtime만을 강조한 것이 아니었습니다. Build Edition blog와 Hosted Agents blog에서는 source-code deployment, built-in guardrails, Voice Live / WebSocket, Managed Compute까지 나열되어 있습니다. 나아가 ASSERT나 Agent Control Specification도 등장하여, agent를 구동하는 runtime과 평가·안전·규격화를 동일한 발표군에서 다루고 있습니다.