Microsoft Scout의 M365 자율 실행 구조와 에이전트 거버넌스
Microsoft Scout가 M365 업무를 계획·실행하는 방식과 Entra Agent ID 기반 권한 관리, 감사, 안전한 도입 전략을 분석한다.
2026-08-14 · 최초 발행 2026-08-02
프롬프트에 답하는 도구에서 목표를 수행하는 주체로
Microsoft는 2026년 6월 2일 Build 2026에서 M365 생태계용 자율 에이전트 Scout를 발표했다. 기존 Copilot이 사용자의 명시적인 요청에 응답하고 결과를 제안했다면, Scout는 전달받은 목표를 세부 작업으로 나누고 실행 순서를 정한 뒤 여러 애플리케이션을 넘나들며 처리한다.
Microsoft는 이 작동 방식을 Autopilot이라는 카테고리로 명명했다. Scout는 Outlook의 메일, Teams의 협업 작업, OneDrive와 SharePoint의 문서를 하나의 워크플로우 안에서 다룬다. 승인 게이트가 필요한 지점을 제외하면 멀티스텝 작업도 독립적으로 이어 간다.
더 중요한 변화는 실행 주체의 신원이다. Scout는 사람의 계정이나 공유 서비스 계정에 기대지 않고 자체 Entra ID를 보유한다. 비인간 신원(non-human identity, NHI)이 디렉터리의 독립된 보안 주체(security principal)가 되면서 권한 부여, 감사, 책임 추적도 별도의 관리 대상으로 올라온다.
Autopilot은 위임받은 목표를 작업으로 바꾼다
Microsoft가 구분한 에이전트 성숙도에서 Scout는 가장 높은 자율성 단계에 놓인다.
| 단계 | 명칭 | 작동 방식 | 인간 개입 | 대표 사례 |
|---|---|---|---|---|
| L0 | Assistant | 단일 프롬프트 응답 | 매 요청마다 | 기존 Copilot Chat |
| L1 | Co-pilot | 제안·초안 작성 | 검토·확정 필요 | Copilot in Word/Excel |
| L2 | Agent | 정의된 작업 자동 수행 | 트리거·승인 | Copilot Studio 에이전트 |
| L3 | Autopilot | 목표 기반 자율 계획·실행 | 예외 시에만 | Microsoft Scout |
이 구분의 핵심은 자동화 범위보다 위임(delegation)에 있다. 사용자가 “다음 주 분기 검토 회의를 준비하라”는 목표를 맡기면 Scout는 관련 메일 스레드를 분석하고 SharePoint에서 문서를 모은다. 이어 Teams 일정을 조율하고 요약 자료를 만드는 식으로 작업을 연결한다.
각 실행 단계에서는 에이전트 권한을 검증하며, 수행한 작업의 책임은 Scout의 Entra ID에 귀속된다. 사용자의 요청을 받아 움직이더라도 실제 행위 주체를 사용자와 분리해 기록하는 구조다.
계획과 실행은 검증 루프 안에서 반복된다
Scout의 처리 구조는 목표 수신, 계획 수립, 도구 호출, 결과 검증으로 이어진다. 목표가 달성되지 않았다면 작업을 다시 분해하고 실행하며, 권한 검증에 실패하면 승인 게이트나 거부 절차로 이동한다. Outlook·Teams·SharePoint·OneDrive는 이벤트를 제공하는 소스이면서 에이전트가 작업을 수행하는 대상이다.
이벤트 기반 실행에는 Microsoft Graph의 변경 알림(change notification)과 웹훅이 쓰인다. 새 메일이 도착하거나 파일이 업로드되고 회의가 생성되면 해당 이벤트가 자율 작업의 트리거가 된다. 실행 결과와 에이전트의 결정은 감사 파이프라인으로 전달된다.
Scout는 사용자의 토큰을 그대로 빌려 실행하지 않는다. 자신의 신원을 이용해 스코프가 제한된 토큰을 발급받는다. 덕분에 에이전트가 어떤 목표에 따라 어떤 액션을 수행했는지 사용자 행위와 구분해 추적할 수 있다.
Entra Agent ID가 권한과 책임의 경계를 만든다
Scout를 기존 업무 자동화와 구분하는 지점은 Microsoft Entra Agent ID다. 에이전트를 디렉터리에 등록된 독립 보안 주체로 취급하므로 사람 계정이나 공유 서비스 계정과 신원이 섞이지 않는다.
에이전트에는 조건부 액세스 정책과 위험 기반 평가를 적용할 수 있다. 생성부터 권한 부여, 회수, 폐기까지의 과정도 ID 거버넌스 도구로 관리한다. 비밀(secret)과 인증서는 자동 순환하도록 구성해 정적 자격 증명이 노출될 가능성을 줄인다.
권한 범위는 맡은 작업에 맞춰 제한한다. SharePoint의 특정 사이트를 읽는 일만 필요하다면 테넌트 전체 권한 대신 해당 사이트에 한정된 위임 스코프를 제공한다. 에이전트의 행위가 Microsoft Purview 감사 로그에 모이면 실행 주체와 작업 내역을 연결해 책임 추적성(accountability)을 확보할 수 있다.
M365 워크로드를 하나의 업무 체인으로 묶는다
Scout는 애플리케이션마다 고립된 자동화를 실행하는 대신 각 워크로드의 이벤트와 작업을 이어 붙인다.
| 워크로드 | 자율 작업 예시 | 트리거 | 권한 범위 |
|---|---|---|---|
| Outlook | 메일 분류·우선순위화·초안 회신·일정 조율 | 새 메일 수신 | Mail.ReadWrite 위임 |
| Teams | 회의 요약·액션 아이템 추출·채널 알림 | 회의 종료 | Chat.ReadWrite, OnlineMeetings |
| SharePoint | 문서 수집·태깅·버전 정리·승인 라우팅 | 파일 업로드 | Sites.Selected |
| OneDrive | 개인 파일 정리·관련 자료 취합 | 사용자 위임 | Files.ReadWrite |
여러 앱을 거치는 작업에는 멀티스텝 추론이 필요하다. 판단이 불확실하거나 위험도가 높은 경우에는 예외 에스컬레이션을 통해 사람의 승인을 요청한다. 테넌트 데이터와 과거 상호작용을 의사결정의 컨텍스트로 활용하며, 각 행위에는 사후 검토를 위한 근거(reasoning trace)를 남긴다.
자율성보다 먼저 설계해야 할 운영 통제
Scout 도입의 난점은 기능 연결보다 거버넌스에 있다. 처음부터 넓은 권한을 부여하기보다 저위험 업무에서 실행 계획과 감사 기록을 확인하고, 검증 결과에 따라 범위를 늘려야 한다.
새 워크플로우는 실제 작업을 수행하지 않고 계획만 기록하는 섀도우 모드에서 먼저 검증한다. 실행 단계로 전환한 뒤에도 작업 중단용 킬 스위치(kill switch)와 권한 회수 절차가 필요하다. 에이전트가 수행한 변경은 되돌릴 수 있도록 설계해야 한다.
위임 스코프는 작업별로 분리하고 시간 제한 권한인 JIT(Just-In-Time)를 적용한다. 여러 Scout 에이전트가 함께 움직이는 환경에서는 오케스트레이터가 중복 작업과 충돌을 조정하되, 각 에이전트의 책임 경계는 분명하게 유지해야 한다.
감사 로그에는 목표, 계획, 실행, 결과가 이어지는 전체 과정을 남긴다. 자율성이 커질수록 책임 소재를 설명하기 어려워지므로 사후 추적과 컴플라이언스 대응이 가능한 기록 체계가 실제 운영의 전제가 된다.
엔터프라이즈 에이전트 접근법의 차이
Microsoft Scout, Google Gemini Spark, Anthropic Claude Agent SDK는 자율 에이전트를 서로 다른 기반 위에서 제공한다.
| 비교 항목 | Microsoft Scout | Google Gemini Spark | Anthropic Claude Agent SDK |
|---|---|---|---|
| 통합 범위 | M365 전반 네이티브 | Google Workspace 중심 | 플랫폼 비종속(빌드형) |
| 에이전트 신원 | Entra Agent ID | Google Cloud IAM | 구현자 정의 |
| 거버넌스 | Purview·조건부 액세스 내장 | Cloud 감사·IAM | 자체 구축 필요 |
| 확장성 | Copilot Studio | Vertex AI | MCP·툴 정의 |
| 적합 대상 | 기존 M365 기업 | Google 생태계 기업 | 커스텀 에이전트 개발팀 |
Scout는 기존 M365 환경의 통합과 거버넌스 체계를 그대로 활용할 수 있다는 데 강점이 있다. Gemini Spark는 Google Workspace 연계와 멀티모달 처리에 무게를 두며, Claude Agent SDK는 플랫폼에 종속되지 않는 커스텀 에이전트 구축 방식으로 구분된다.
운영 아키텍처에서 읽어야 할 쟁점
Scout의 목표-계획-실행-검증 루프는 이벤트 기반 아키텍처(EDA)와 오케스트레이션 패턴이 자율 에이전트에 적용된 사례다. Microsoft Graph 변경 알림 구독은 발행-구독(Pub/Sub) 통합 패턴으로 볼 수 있으며, Outlook·Teams·SharePoint를 연결하는 구조는 엔터프라이즈 애플리케이션 통합과 API 오케스트레이션 문제로 이어진다.
보안 관점에서는 비인간 신원의 라이프사이클, 최소 권한, JIT 권한이 접근통제와 ID 거버넌스의 중심에 놓인다. 안전성 검증, 롤백, 킬 스위치는 신뢰할 수 있는 AI(Trustworthy AI)와 위험 관리 체계를 실제 업무 실행 계층에 연결한다.
2026년 엔터프라이즈 자율 에이전트 경쟁에서 모델 성능만으로는 운영 적합성을 판단하기 어렵다. Scout가 제시하는 핵심은 M365 자동화 자체보다 에이전트의 신원, 권한, 감사 기록을 기존 기업 통제 체계 안에 넣는 방식이다. 도입 조직도 기능 확장에 앞서 최소 권한 위임과 섀도우 검증, 가역적인 실행 구조를 갖춰야 한다.
Sources
- https://news.microsoft.com/build-2026/
- https://learn.microsoft.com/en-us/entra/identity/agent-id/
- https://learn.microsoft.com/en-us/microsoft-365-copilot/
- https://learn.microsoft.com/en-us/graph/webhooks
- https://learn.microsoft.com/en-us/purview/audit-solutions-overview
- https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/
- https://blog.google/technology/google-deepmind/gemini-spark/
- https://docs.anthropic.com/en/docs/agents-and-tools/agent-sdk
- https://learn.microsoft.com/en-us/entra/identity/conditional-access/