Microsoft Scout 공개, OpenClaw를 회사 계정으로 묶은 자동 에이전트

AI 요약

• 무슨 일: Microsoft가 Build 2026에서 첫 Autopilot agent인 Microsoft Scout를 공개했습니다.
  • Scout는 OpenClaw 기반으로 Teams, Outlook, OneDrive, SharePoint, desktop, browser, shell, MCP server를 연결합니다.
• 권한 조건: Frontier preview, Intune 설정, opt-in attestation, GitHub Copilot Business 또는 Enterprise license가 필요합니다.
• 개발자 영향: desktop agent가 file, command, browser, M365 data를 함께 만지며 permission과 audit가 제품 기능이 됩니다.
• 주의점: auto-approve는 기본 OFF입니다. WorkIQ memory, shell access, MCP scope, Purview DLP 경계는 pilot에서 검증해야 합니다.
  • Microsoft는 Scout를 experimental release로 제공하며 preview 기능은 GA 전에 바뀔 수 있다고 문서화했습니다.

Microsoft가 2026년 6월 2일 Build 2026과 Microsoft 365 Blog에서 Microsoft Scout를 공개했습니다. Microsoft 365 Blog의 Omar Shahine 글은 Scout를 Microsoft의 첫 Autopilot agent라고 부릅니다. Autopilot은 prompt를 기다리는 assistant가 아니라 자기 identity를 갖고 background에서 계속 일하는 agent로 정의됩니다. Scout는 Teams에서 대화하고, desktop app을 통해 browser, local resources, Model Context Protocol server까지 닿습니다.

이번 발표는 Copilot에 일정 정리 기능이 하나 더 붙었다는 이야기보다 큽니다. Microsoft Learn overview는 Scout가 files를 읽고 쓰고, shell command를 실행하고, Playwright로 browser를 조작하고, Microsoft 365 data를 조회하며, schedule이나 trigger로 background automation을 돌릴 수 있다고 설명합니다. 이 조합은 OpenClaw, Claude Code, Codex 같은 agentic harness가 하던 일을 Microsoft 365 tenant와 desktop permission model 안으로 가져옵니다.

Command Line의 Scout 인터뷰는 제품의 출발점을 더 노골적으로 보여줍니다. Shahine은 개인 OpenClaw assistant인 Lobster를 만들었고, 이 assistant는 자체 Apple ID와 email address를 갖고 travel logistics와 family reminders를 처리했습니다. 같은 시기에 Microsoft의 Jakob Werner는 desktop app 기반 OpenClaw-inspired agent를 만들었고, 내부 이름은 Clawpilot이었습니다. Command Line은 이 내부 경험이 몇 주 만에 Microsoft 직원 수천 명에게 다운로드됐다고 적었습니다.

Scout가 흥미로운 이유는 OpenClaw식 개인 실험을 Microsoft가 그대로 배포하지 않았기 때문입니다. Command Line은 Scout가 OpenClaw code와 enterprise identity, governance, security를 결합한다고 설명합니다. 모든 package는 Microsoft가 선별하고 서명한 supply chain을 거치며, tool call, model request, network hop은 zero-trust runtime이 중재합니다. agent container는 신뢰하지 않고, identity와 token과 policy는 Microsoft가 control하는 바깥쪽에 둔다는 설명입니다.

Microsoft 365 Blog의 product framing도 같은 방향입니다. Scout는 cloud, desktop, web에 걸쳐 Teams, Outlook, OneDrive, SharePoint, email, calendar, contacts를 연결합니다. 사용 사례는 meeting time coordination, time zone 조정, 중요한 meeting flagging, prepare material generation, deliverable 확인, calendar time blocking, stalled decision 탐지입니다. 개발자 관점에서 이 목록은 productivity demo가 아니라 authority list입니다. agent가 회의를 잡고, 파일을 만들고, shell을 실행한다면 누가 어떤 권한으로 행동했는지 남아야 합니다.

access 조건은 Scout가 아직 일반 release가 아니라는 점을 분명히 합니다. Microsoft Learn의 get started 문서는 Frontier preview program 참여와 terms of participation 수락을 prerequisites로 적었습니다. 같은 문서는 Windows 11 또는 macOS 12 이상, Microsoft 365 license, local administrator permission, Intune-enabled account, GitHub Copilot Business 또는 Enterprise license도 요구합니다. Build live blog도 Frontier enrollment, Intune policy configuration, opt-in attestation, GitHub Copilot account/license를 요구한다고 설명했습니다.

기본 permission 설정도 기사에서 다룰 만한 숫자입니다. Microsoft Learn은 Scout의 default로 WorkIQ connectivity ON, shell access ON, auto-approve OFF를 적었습니다. actions는 auto-approve, prompt, deny 세 단계로 나뉩니다. send, share, reply, forward, update처럼 다른 사람에게 보이는 정보를 바꾸는 작업은 confirmation이 필요합니다. shell access가 기본 ON이라는 점은 개발자에게 편하지만, auto-approve OFF라는 기본값은 Microsoft가 위험을 알고 있다는 신호입니다.

Work IQ는 Scout가 단발성 assistant와 갈라지는 지점입니다. Microsoft 365 Blog는 Work IQ가 시간이 지날수록 how you work, what you care about, what needs to happen next를 학습한다고 설명합니다. Official Microsoft Blog는 Work IQ APIs가 2026년 6월 16일 GA되어 agents가 organization context에 접근할 수 있게 한다고 적었습니다. Scout가 meeting prep을 자동화하려면 사람, file, meeting, email, decision pattern을 장기적으로 묶어야 합니다.

이 memory는 생산성 기능이면서 개인정보와 governance 문제입니다. Command Line 인터뷰에서 Shahine은 OpenClaw, Claude Code, GitHub Copilot CLI 같은 agentic coding harness가 diary처럼 기억을 적는다고 말했습니다. 이어 agent는 기억해야 하지만 잊어야 할 것도 있다고 설명했습니다. Werner도 반복 사용되면 memory가 붙고, 사용되지 않으면 사라지는 layer를 설계했다고 말했습니다. Scout pilot에서 memory retention과 forgetting policy를 확인해야 하는 이유가 여기에 있습니다.

보안 발표와 연결하면 Scout는 Agent 365 전략의 데모이기도 합니다. Microsoft Security Blog는 Agent 365 Agent Registry가 unmanaged local agents를 Microsoft Defender, Entra, Intune과 함께 surface한다고 설명했습니다. registry는 coding agents, AI desktop applications, local/remote MCP servers를 포함해 20개 이상 local agent type을 지원한다고 적었습니다. Purview는 Claude Code, GitHub Copilot, OpenAI Codex, OpenClaw 같은 coding agents의 sensitive data access와 unsafe behavior를 signal로 다룹니다.

이 대목은 Scout의 경쟁 상대를 바꿉니다. 일반 사용자는 Scout와 ChatGPT Tasks, Google Gemini, Claude desktop workflow를 비교할 수 있습니다. enterprise 개발팀은 Agent 365, Entra identity, Intune policy, Purview DLP, GitHub Copilot license, local shell permission이 한 묶음인지 봅니다. Microsoft가 팔려는 것은 개인 agent UI가 아니라 "agent가 회사 asset으로 행동할 때 누가 accountable한가"라는 control plane입니다.

Agent Control Specification도 배경에 있습니다. Microsoft는 Build 2026에서 ACS를 공개하며 runtime governance를 framework와 policy engine에서 분리하려 했습니다. ACS article은 agent lifecycle에 여덟 개 interception point를 둔다고 설명합니다. 목록은 agent_startup, Input, pre_model_call, post_model_call, pre_tool_call, post_tool_call, output, agent_shutdown입니다. Scout 자체 문서가 ACS 구현 세부를 모두 공개하지는 않지만, Microsoft가 말하는 signed package, zero-trust runtime, Purview enforcement는 같은 문제를 겨냥합니다.

커뮤니티 반응은 아직 공식 발표만큼 크지 않습니다. Hacker News에서 Scout 자체의 큰 토론은 확인하지 못했습니다. Reddit의 r/technology thread는 Scout를 persistent agent로 설명하면서도, 일부 사용자가 Appium이나 Selenium workflow와 AI coding으로 이미 비슷한 자동화를 만들 수 있다고 반응했습니다. r/copilotstudio에서는 Copilot Studio workflow가 100 step 이상으로 커지는 고객에게 Scout가 맞을 수 있다는 평가와, Microsoft가 OpenClaw를 다시 포장했다는 비판이 함께 나왔습니다.

이 비판은 완전히 빗나가지 않습니다. browser automation, file edit, shell execution, scheduled prompt는 이미 여러 agent tool이 해 온 일입니다. Scout의 차이는 기능 목록보다 tenant boundary에 있습니다. OpenClaw를 개인이 직접 돌릴 때는 email token, local file, browser session, payment account를 개인이 감당합니다. Scout는 그 risk를 Entra identity, Intune policy, Purview DLP, Agent 365 registry로 enterprise admin이 볼 수 있는 대상으로 바꾸려 합니다.

developer team이 pilot을 설계한다면 첫 업무는 "무엇을 자동화할까"가 아니라 "어떤 action을 절대 자동 승인하지 않을까"입니다. Microsoft Learn의 permission model은 auto-approve, prompt, deny를 제공합니다. repo build와 local file search는 auto-approve 후보가 될 수 있습니다. destructive shell command, external email, calendar cancellation, shared drive write, MCP server registration은 prompt나 deny가 더 맞습니다. Scout가 편리할수록 default deny list가 먼저 필요합니다.

두 번째 체크는 workspace boundary입니다. Learn 문서는 Scout가 workspace directory를 정하고 그 안에서 file을 읽고 쓴다고 설명합니다. 그러나 active project directory 안에는 .env, customer export, meeting transcript, key material, unpublished contract가 섞일 수 있습니다. sensitive directory가 항상 explicit approval을 요구하는지, generated document가 어디에 저장되는지, inline image나 artifact가 cloud sync에 올라가는지 확인해야 합니다.

세 번째 체크는 shell과 browser의 연결입니다. Scout가 Playwright로 web app을 조작하고 shell로 build를 실행한다면, web page의 untrusted instruction과 local command 사이에 거리가 짧아집니다. prompt injection은 email, shared document, issue page, web page 안에 들어갈 수 있습니다. browser에서 읽은 내용이 shell command나 file write로 이어질 때 Scout가 어떤 intervention point에서 user confirmation을 요구하는지 pilot에서 로그로 확인해야 합니다.

네 번째 체크는 MCP server입니다. Microsoft 365 Blog는 Scout desktop app이 MCP servers로 reach를 확장한다고 적었습니다. MCP server는 agent에게 강력한 tool을 노출합니다. 사내 Jira, GitHub, Snowflake, Workday, Slack connector가 붙으면 Scout는 개인 비서가 아니라 cross-system operator가 됩니다. server provenance, tool description, authentication scope, audit log, revocation path가 없으면 편리한 통합이 shadow automation이 됩니다.

다섯 번째 체크는 GitHub Copilot license와 비용입니다. Scout access에는 GitHub Copilot Business 또는 Enterprise license가 요구됩니다. Build live blog는 사용자가 GitHub Copilot account/license로 experience를 다운로드하고 설치할 수 있다고 적었습니다. 이 조건은 Microsoft가 Scout를 M365 Copilot만의 extension으로 두지 않고 developer agent와 consumption path를 묶고 있음을 보여줍니다. 실제 비용은 Frontier preview 이후 licensing과 token metering 문서를 봐야 합니다.

경쟁 구도에서 Microsoft는 독특한 위치를 잡았습니다. OpenAI Codex와 Claude Code는 developer workflow의 repository, terminal, PR review를 장악하려 합니다. Google Antigravity는 CLI와 IDE migration을 밀고 있습니다. Salesforce Agentforce와 ServiceNow AI는 business workflow와 data graph를 앞세웁니다. Scout는 개인 업무의 M365 graph와 desktop local action을 같이 잡는 쪽입니다. Teams와 Outlook이 agent의 conversation surface가 되고, desktop이 file과 browser와 shell을 맡습니다.

이 전략에는 약점도 있습니다. Scout가 유용하려면 많은 권한을 받아야 하고, 많은 권한을 받을수록 admin approval과 DLP friction이 늘어납니다. Frontier preview, Intune configuration, opt-in attestation, Copilot Business/Enterprise license는 도입 속도를 늦춥니다. 반대로 이 friction이 없으면 enterprise는 OpenClaw식 상시 실행 agent를 표준 업무 PC에 쉽게 열 수 없습니다. Microsoft는 속도보다 통제 가능한 배포를 먼저 택한 셈입니다.

본문에서 Scout를 "Copilot 채팅의 다음 기능"으로만 읽으면 실무 변화가 흐려집니다. Scout는 Teams message에 답을 쓰는 assistant가 아니라, background에서 meeting risk를 찾고, calendar block을 만들고, local file을 편집하고, build를 돌리고, browser를 조작할 수 있는 desktop agent입니다. 그 행동이 회사 계정과 compliance boundary 안에서 이뤄져야 하므로 제품의 핵심 UI는 chat box보다 permission prompt, audit trail, admin registry, DLP signal에 있습니다.

지금 개발 조직이 얻을 교훈은 명확합니다. agent pilot의 KPI를 "몇 개 업무를 자동화했는가"로만 두면 안 됩니다. tool allowlist 수, prompt된 approval 수, deny된 action 수, sensitive file 접근 횟수, MCP server별 permission, Purview DLP hit, rollback time을 같이 기록해야 합니다. Scout가 실제로 시간을 줄였는지는 자동화 성공률뿐 아니라 사람이 검토한 권한 변경의 양으로도 봐야 합니다.

Microsoft가 Scout를 GA로 넓힌다면 enterprise agent 경쟁의 기준은 모델 성능표에서 운영 표면으로 이동합니다. 어떤 모델이 더 긴 계획을 세우는지보다, 어떤 agent가 회사 identity로 행동하고, 어떤 tool call이 policy로 막히고, 어떤 memory가 만료되고, 어떤 audit log가 남는지가 중요해집니다. Scout 발표는 OpenClaw식 개인 agent가 기업 안으로 들어올 때 필요한 조건을 Microsoft 방식으로 적어 낸 첫 공개 사례입니다.