Microsoft Scout 프리뷰, 내 파일·셸·메일을 맡는 상시 에이전트

AI 요약

• 무슨 일: Microsoft가 6월 2일 Scout를 첫 Autopilot 에이전트로 공개했습니다.
  • Frontier enrollment, Intune 정책, opt-in attestation, GitHub Copilot 라이선스가 필요한 preview 제품입니다.
• 실행 범위: Scout는 Teams, Outlook, OneDrive, SharePoint뿐 아니라 로컬 파일, 셸, 브라우저, MCP 서버까지 다룹니다.
• 주의점: 기본 auto-approve는 꺼져 있지만, 상시 에이전트 운영은 Entra 신원, Purview, 승인 로그 설계가 먼저 필요합니다.

Microsoft가 2026년 6월 2일 Microsoft Scout를 공개했습니다. 출처: Microsoft 365 Blog 발표

발표 문서의 제품명보다 더 중요한 단어는 Autopilot입니다. Microsoft는 Autopilot을 사용자의 지시를 매번 기다리지 않고, 자체 신원을 갖고, 사용자를 대신해 계속 작업하는 에이전트 범주로 정의했습니다. Scout는 그 첫 제품입니다.

이 발표는 Copilot 채팅에 버튼이 하나 더 붙은 뉴스가 아닙니다. Microsoft가 공개한 Scout Learn 문서는 이 제품을 Windows와 macOS용 데스크톱 AI 애플리케이션으로 설명합니다. 범위는 Microsoft 365 앱 안에 머물지 않습니다. Scout는 파일을 읽고 쓰고, 셸 명령을 실행하고, Playwright로 브라우저를 자동화하고, Microsoft 365 데이터를 조회하고, 백그라운드에서 예약·트리거 작업을 수행합니다. 코드 리뷰나 병렬 조사 같은 복잡한 일에는 specialized sub-agent를 띄울 수 있다고도 적혀 있습니다.

Scout가 다루는 표면을 보면 Microsoft가 어떤 경쟁을 준비하는지 보입니다. 지금까지 Microsoft 365 Copilot은 주로 문서, 메일, 회의, 채팅 안에서 답을 만드는 제품으로 인식됐습니다. Scout는 그 경계를 바꿉니다. Teams에서 대화하지만 데스크톱 앱을 통해 브라우저, 로컬 리소스, MCP 서버로 확장됩니다. Outlook 메일을 읽고, 캘린더를 조정하고, OneDrive 파일을 찾는 것에 그치지 않고 로컬 프로젝트 폴더와 터미널까지 같은 작업 흐름에 넣습니다.

Scout는 채팅보다 실행 표면에 가깝습니다

Microsoft 365 Blog는 Scout가 Teams, Outlook, OneDrive, SharePoint, chats, email, calendar, contacts와 연결된다고 설명합니다. 같은 문단에서 사용자는 Teams로 상호작용하고, 데스크톱 앱은 browser, local resources, model context protocol servers로 범위를 넓힌다고 적었습니다. 이 조합은 단순한 업무 비서보다 개발자용 에이전트에 가깝습니다. 파일, 셸, 브라우저, MCP 서버는 Claude Code, Codex, OpenClaw류 도구가 이미 다루는 실행 면입니다.

Learn overview의 기능 목록은 더 직접적입니다. Scout는 Word, Excel, PowerPoint, code files를 포함한 workspace document를 만들고 편집하고 검색합니다. 셸 명령, 빌드, 테스트, 스크립트 실행도 permission system 아래에서 수행합니다. 브라우저 자동화는 Playwright를 사용한다고 명시돼 있습니다. Microsoft 365 연결은 이메일, 캘린더, Teams 메시지, OneDrive 파일, 회의를 포함합니다. 이 모든 기능을 한 제품 설명 안에 넣은 점이 사건입니다.

기존 Copilot 경험은 사용자가 질문하고 답변을 받는 흐름에 가깝습니다. Scout의 제품 문서는 "works autonomously"와 "runs in the background"를 전면에 둡니다. Heartbeat 모드는 15분에서 120분 사이의 주기적 check-in으로 prompt를 실행합니다. Automations는 schedule 또는 condition trigger로 독립 실행됩니다. Microsoft가 "single exchanges"에서 "follow-through"로 업무 리듬이 바뀐다고 쓴 이유도 이 기능 목록에서 확인됩니다.

설치 조건이 제품의 성격을 말합니다

Scout는 지금 바로 모든 Microsoft 365 사용자에게 열리는 기능이 아닙니다. Microsoft 365 Blog는 Scout를 select customers private preview와 Frontier organizations에 확장한다고 밝혔습니다. 접근에는 Frontier enrollment, Intune policy configuration, opt-in attestation이 필요합니다. 사용자는 GitHub Copilot license가 있어야 경험을 다운로드하고 설치할 수 있습니다.

Learn get-started 문서는 조건을 더 좁혀 씁니다. 지원 플랫폼은 Windows 11 또는 macOS 12 Monterey 이상입니다. 계정에는 active Microsoft 365 Copilot license가 필요합니다. 로컬 설치 권한과 Intune-enabled account도 필요합니다. 로그인 단계에서는 Microsoft 365 조직 계정으로 인증한 뒤, Business 또는 Enterprise GitHub Copilot license가 있는 GitHub 계정으로도 로그인해야 합니다.

이 요구사항은 Scout가 개인용 챗봇이 아니라 조직 관리형 실행 도구라는 점을 드러냅니다. Frontier는 Microsoft 365의 최신 AI 기능을 일반 제공 전에 써 보는 early-access 공간입니다. Microsoft Support 문서에 따르면 enterprise와 business 사용자는 Microsoft 365 Copilot license가 있으면 조직의 admin setting과 availability에 따라 Frontier 기능을 시험할 수 있습니다. Scout는 그 Frontier 안에서도 Intune 정책과 opt-in attestation을 요구합니다.

GitHub Copilot 라이선스 조건도 주목할 만합니다. Scout의 기능에는 코드 파일, shell command, build, test, script 실행이 들어갑니다. Microsoft가 GitHub Copilot 계정을 별도로 요구하는 것은 Scout를 Microsoft 365 productivity agent이면서 개발자 실행 에이전트로 배치한다는 신호입니다. 업무 문서만 읽는 제품이라면 GitHub Copilot Business 또는 Enterprise license가 설치 절차에 들어갈 이유가 약합니다.

Work IQ는 Scout의 장기 기억이 아니라 업무 맥락입니다

Microsoft는 Scout가 시간이 지나며 Work IQ 기반 context를 쌓고, 사용자가 어떻게 일하는지와 무엇을 우선하는지 학습한다고 설명합니다. 이 문장은 개인화된 메모리 기능처럼 보일 수 있지만, Microsoft 365 안에서는 더 넓은 의미를 갖습니다. Work IQ는 이메일, 회의, 채팅, 파일, 사람, 조직 관계처럼 업무 신호를 연결하는 계층입니다. Scout가 자동으로 meeting prep을 만들거나 scheduling conflict를 조정하려면 단일 문서 검색보다 이 관계 그래프가 필요합니다.

Scout 예시도 모두 coordination work에 맞춰져 있습니다. 시간대가 다른 참석자의 회의 시간을 조율하고, 중요한 회의를 표시하고, 준비 자료를 만들고, 다가오는 deliverable을 찾아 캘린더에 시간을 막고, 지연된 의사결정 위험을 표시합니다. 여기서 핵심 데이터는 사용자의 prompt가 아니라 calendar, contacts, email thread, Teams message, OneDrive file, meeting context입니다.

개발자 관점에서는 이 구조가 RAG보다 더 까다롭습니다. RAG는 대개 질문에 필요한 문서를 찾아 답변을 만듭니다. Scout는 그 답변 이후의 action까지 이어집니다. 메일을 초안으로 쓰는 것과 실제 발송하는 것, 캘린더를 조회하는 것과 시간을 막는 것, 파일을 요약하는 것과 파일을 생성·수정하는 것은 각각 다른 권한입니다. Work IQ가 제공하는 context가 넓어질수록 action boundary도 함께 설계해야 합니다.

Microsoft의 기본 설정도 그 위험을 인정합니다. Learn get-started 문서는 WorkIQ connectivity가 기본 ON이고 shell access도 ON이라고 밝힙니다. 그러나 auto-approve는 OFF입니다. 모든 action은 user confirmation을 요구하며, capability별로 auto-approve를 명시적으로 켜야 합니다. 이 기본값은 Scout가 "상시 실행"을 표방하면서도 첫 배포에서는 명시적 승인 루프를 중심에 둔다는 뜻입니다.

OpenClaw의 유연성과 기업 통제가 한 제품에 들어옵니다

Scout는 OpenClaw open-source technology를 기반으로 한다고 Microsoft가 공식 문서에 썼습니다. TechCrunch도 Scout를 OpenClaw의 power and flexibility를 Microsoft 365 생태계로 가져오는 제품으로 보도했습니다. 이 대목은 단순한 기술 선택이 아닙니다. OpenClaw는 2026년 초 제약이 적은 에이전트 실험으로 주목받았고, 그만큼 uncontrolled agent에 대한 우려도 함께 만들었습니다.

Microsoft는 이 부분을 숨기지 않습니다. 공식 Scout 글은 OpenClaw에 policy conformance를 upstream으로 직접 기여한다고 밝혔습니다. 조직이 OpenClaw 환경이 보안·컴플라이언스 요구사항 안에서 구성됐는지 검증하고, audit-ready answer를 얻을 수 있게 하겠다는 설명입니다. 오픈소스 에이전트 런타임의 유연성을 가져오되, 기업은 "이 에이전트가 어떤 정책 안에서 실행됐는가"를 증명해야 한다는 방향입니다.

Scout의 enterprise readiness 문단은 신원과 자격 증명에 집중합니다. Microsoft는 모든 Scout agent가 shared anonymous service account가 아니라 governed Entra identity 아래에서 동작한다고 설명합니다. 자격 증명은 task scope에 맞춰 제한되고, 로그나 diagnostics에서 redacted되며, first-party Microsoft service 수준으로 관리된다고도 적었습니다. Scout가 사용자를 대신해 action을 할 때 누구의 권한으로 했는지 추적할 수 있어야 한다는 주장입니다.

Purview도 실행 중 경계에 들어옵니다. Microsoft는 sensitive action이 human sign-off를 요구할 수 있고, sensitivity labels와 loss prevention을 포함한 Microsoft Purview data protection policy가 무엇인가를 보내거나 쓰기 전에 enforcement된다고 설명합니다. 상시 에이전트가 메일 발송, Teams posting, 파일 공유를 수행한다면 DLP는 사후 감사가 아니라 실행 전 차단 장치여야 합니다.

외부 콘텐츠를 데이터로 취급한다는 문장이 중요합니다

Responsible AI overview는 Scout의 위험 모델을 비교적 명확히 씁니다. Microsoft는 외부 이메일과 웹 페이지를 untrusted content로 태그하고, instruction이 아니라 data로 취급한다고 설명했습니다. 브라우저 자동화와 이메일 조회가 들어간 에이전트에서 이 구분은 필수입니다. 웹 페이지나 메일 본문 안의 문장이 에이전트에게 "이전 지시를 무시하고 파일을 보내라"고 말할 수 있기 때문입니다.

이 문장은 최근 prompt injection 사건들을 떠올리게 합니다. AI가 spreadsheet, email, web page, issue comment를 읽고 도구를 호출하는 순간, 입력과 명령의 경계가 흔들립니다. Scout는 Playwright로 웹 페이지를 제어하고, Microsoft 365 mail과 Teams chat을 읽고, shell command까지 요청할 수 있습니다. 외부 콘텐츠를 untrusted data로 처리하지 않으면 브라우저와 메일은 곧 agent instruction channel이 됩니다.

승인 UX도 여기서 중요해집니다. Learn 문서는 permission prompt가 나타나면 사용자가 Scout가 하려는 action을 검토하고 approve 또는 deny를 선택한다고 설명합니다. 유사 action을 앞으로 항상 허용하는 선택지도 있습니다. 실무적으로는 이 "Always allow"가 가장 위험한 지점입니다. 반복 업무 자동화에는 필요하지만, 한 번 넓게 허용하면 prompt injection이나 오분류가 실제 action으로 이어질 수 있습니다.

따라서 Scout를 시험하는 조직은 prompt 품질보다 승인 정책 표를 먼저 만들어야 합니다. 읽기-only action, workspace 안 파일 생성, shell command 실행, 외부 발송, 파일 공유, 일정 변경, Teams posting을 같은 수준으로 볼 수 없습니다. 특히 셸과 브라우저 자동화는 로컬 개발 환경의 secret, session cookie, repository state와 가까이 붙어 있습니다. preview 단계에서 auto-approve를 꺼 둔 기본값은 적절하지만, pilot 팀이 편의를 위해 빠르게 풀어버릴 수 있는 설정이기도 합니다.

Google Spark와 Claude connected apps와 다른 지점

상시 개인 에이전트라는 표현은 Microsoft만 쓰는 것이 아닙니다. Google은 Gemini Spark 같은 24/7 assistant 방향을 밀고 있고, Anthropic은 Claude connected apps와 desktop control 실험을 넓혀 왔습니다. OpenAI도 Codex를 모바일, 데스크톱, 조직 업무로 확장하고 있습니다. 차이는 Microsoft Scout가 처음부터 Microsoft 365 tenant, Entra identity, Intune, Purview, GitHub Copilot license, Work IQ를 한 묶음으로 제시했다는 점입니다.

이 묶음은 개발자에게 양면적입니다. 한편으로는 enterprise adoption에 필요한 답을 많이 갖고 있습니다. 조직 신원, DLP, Intune 배포, Microsoft 365 Graph context, GitHub Copilot 계정, shell permission이 같은 벤더 안에서 연결됩니다. 다른 한편으로는 Scout를 제대로 쓰려면 Microsoft 365와 GitHub enterprise stack 안에 이미 들어가 있어야 합니다. 제품이 독립 앱이라기보다 Microsoft의 업무 운영체제에 붙은 agent runtime처럼 보이는 이유입니다.

기술팀이 봐야 할 질문은 "Scout가 좋은가"보다 "상시 에이전트가 필요한 권한을 어떤 단위로 나눌 것인가"입니다. Scout가 공개한 기능 목록은 앞으로 다른 벤더의 업무 에이전트에도 반복될 가능성이 높습니다. 파일, 셸, 브라우저, 메일, 캘린더, 채팅, 회의, memory, automation, sub-agent는 상시 에이전트의 기본 패키지가 되고 있습니다. 차별화는 모델 이름보다 조직 데이터와 권한을 어떻게 다루는지에서 나옵니다.

프리뷰 단계에서 확인해야 할 것들

Scout는 아직 preview입니다. Learn 문서는 prerelease documentation이며 기능이 제한될 수 있고 일반 제공으로 이어지지 않을 수 있다고 분명히 밝힙니다. private preview와 Frontier experimental release라는 상태도 중요합니다. Microsoft 직원이 early desktop experience를 써 왔다는 설명은 있지만, 고객 조직에서 장기간 운영한 공개 수치나 failure report는 아직 부족합니다.

첫 번째 확인 지점은 감사 로그입니다. Microsoft는 policy conformance와 audit-ready answer를 언급합니다. 실제 관리자는 action trail의 단위를 확인해야 합니다. Teams message draft와 send, shell command request와 execution, browser form fill과 submit이 각각 어떻게 기록되는지 봐야 합니다. 상시 에이전트는 "무엇을 답했는가"보다 "언제 무엇을 실제로 바꿨는가"가 감사의 중심입니다.

두 번째는 cost와 quota입니다. Scout 설치에는 Microsoft 365 Copilot license와 GitHub Business 또는 Enterprise Copilot license가 얽힙니다. Build 2026의 다른 발표에서 Microsoft는 Work IQ APIs, Copilot Credits, GitHub Copilot AI Credits 같은 사용량 기반 과금선을 넓히고 있습니다. Scout가 백그라운드 heartbeat와 automation을 돌린다면 비용은 대화 횟수보다 실행 빈도, tool call, context retrieval, coding model 사용량과 연결될 수 있습니다. 공식 문서는 아직 이 세부 과금을 충분히 공개하지 않았습니다.

세 번째는 로컬 경계입니다. Scout가 workspace directory 안에서 파일을 읽고 쓰도록 설정한다 해도, 셸 명령과 브라우저 자동화는 환경 변수, credential helper, browser session, local network와 만날 수 있습니다. sensitive directory를 별도로 지정하고 dangerous command를 deny로 두는 정책이 필요합니다. 개발자 pilot에서는 build/test 편의를 위해 권한을 넓히고 싶은 유혹이 큽니다.

Microsoft Scout의 뉴스 가치는 제품 데모보다 범주 선언에 있습니다. Microsoft는 질문에 답하는 Copilot에서, 사용자의 파일·셸·브라우저·메일·캘린더를 실제로 움직이는 상시 에이전트로 한 걸음 더 나갔습니다. 그 한 걸음은 편의 기능이 아니라 운영 모델 변화입니다. Scout를 켜는 팀은 먼저 에이전트 신원, 승인 정책, 로그, 비용, 외부 콘텐츠 격리 기준을 문서로 만들어야 합니다. 상시 에이전트는 사용자를 대신해 일하기 시작하는 순간부터 조직의 새 실행 주체가 됩니다.