Microsoft Scout Autopilot의 Entra ID 기반 M365 자율 에이전트 설계
Microsoft Scout Autopilot이 Entra ID 독립 신원과 M365 권한·감사 체계 안에서 자율 워크플로우를 실행하는 구조와 도입·롤백 원칙을 정리한다.
2026-08-14 · 최초 발행 2026-08-02
사용자의 보조 도구에서 독립된 업무 주체로
Microsoft Build 2026에서 공개된 Scout는 Outlook·Teams·OneDrive·SharePoint에 걸친 복잡한 멀티스텝 워크플로우를 인간 개입 없이 수행하는 새로운 에이전트 카테고리인 Autopilot을 제시했다. 기존 코파일럿이 사용자의 요청을 받아 초안을 만들거나 데이터를 요약했다면, Scout는 이벤트·일정·조건을 감지해 먼저 움직인다.
차이는 실행 방식에만 있지 않다. Scout는 자체 Entra ID 신원을 가진다. 일반 직원과 마찬가지로 인증, 권한 위임, 감사의 대상이 되며 에이전트가 수행한 작업은 독립된 책임 단위로 추적된다.
| 구분 | M365 Copilot (기존) | Scout Autopilot (신규) |
|---|---|---|
| 실행 트리거 | 사용자 명령 | 이벤트·일정·조건 기반 자율 트리거 |
| 작업 범위 | 단일 앱 내 단일 작업 | 크로스 앱 멀티스텝 워크플로우 |
| ID 체계 | 사용자 위임 토큰 | 독립 Entra ID (에이전트 서비스 주체) |
| 인간 개입 | 매 작업 승인 필요 | 비동기·선택적 감독 |
| 감사 로그 | 사용자 행위 로그 | 에이전트 행위 독립 감사 로그 |
| 책임 귀속 | 사용자 | 에이전트 ID + 위임 정책 |
이 구조의 자율성은 **에이전트 자율도(Agentic Autonomy Level, AAL)**로 제어한다. 마이크로소프트는 AAL 0(완전 수동)부터 AAL 4(완전 자율)까지 5단계를 정의한다. Scout Autopilot은 기본적으로 AAL 3, 즉 비정상 상황에서만 인간에게 개입을 요청하는 조건부 자율 방식으로 운영된다. 관리자는 조직 단위와 워크플로우 유형에 따라 AAL을 따로 조정할 수 있다.
에이전트 신원을 Entra ID에 편입하는 방식
Scout 에이전트는 사용자 자격증명을 빌려 동작하지 않는다. Azure Active Directory 서비스 주체에 해당하는 독자적인 Entra ID를 발급받고 조직 디렉터리 안에 별도의 행위 주체로 등록된다.
첫 번째 통제 지점은 최소 권한 범위다. Scout를 만들 때 필요한 Graph API 권한만 명시적으로 부여한다. 계약서 검토 에이전트라면 Files.ReadWrite.All을 열어 주는 대신 지정된 SharePoint 라이브러리에만 접근하는 Sites.Selected 권한을 허용할 수 있다. OAuth 2.0 범위를 조직 구조와 연결해 권한을 좁히는 방식이다.
자격증명은 정적 클라이언트 시크릿 대신 Azure Managed Identity로 관리한다. 코드나 구성 파일에 자격증명을 넣지 않고 Azure 플랫폼이 토큰 발급과 순환을 담당하므로 비밀 유출 위험을 구조적으로 제거한다.
Entra ID Conditional Access도 에이전트 ID에 연결된다. 비정상 시간대의 접근이나 지리적 이상을 탐지하고, 고위험 작업에는 추가 인증을 요구하는 정책을 적용할 수 있다.
계획하고 실행한 뒤 결과를 검증한다
Scout의 자율 워크플로우는 계획, 실행, 검증이 반복되는 순환 구조다. 이벤트가 들어오면 목표를 작업 단위로 나누고 실행 계획을 만든다. 이후 각 Graph API 호출 결과를 평가하면서 다음 행동을 결정한다.
작업 계획기는 ReAct(Reasoning + Acting)를 확장한 M-ReAct(Multi-step ReAct) 아키텍처를 사용한다. 각 추론 단계에서 호출할 수 있는 Graph API 도구를 동적으로 평가하고 현재 상태와 목표 상태의 차이를 줄이는 행동 순서를 만든다. 실행 직전에는 안전성 분류기(Safety Classifier)가 행동을 검사한다. 삭제나 외부 발송처럼 되돌릴 수 없는 작업은 별도의 확인 단계를 통과해야 한다.
이벤트 수집에는 Microsoft Graph Change Notifications가 사용된다. Scout는 여러 M365 서비스의 변경을 구독하고 한 앱에서 발생한 사건을 다른 앱의 작업으로 연결한다.
| 이벤트 소스 | 구독 이벤트 유형 | Scout 자율 처리 예시 |
|---|---|---|
| Outlook | 메일 수신, 캘린더 초대 | 계약서 분류 → SharePoint 업로드 → 담당자 알림 |
| Teams | 채널 메시지, 미팅 종료 | 회의록 생성 → OneNote 저장 → Planner 작업 생성 |
| SharePoint | 파일 업로드, 버전 변경 | 문서 분석 → 태그 자동 부여 → 승인 워크플로우 트리거 |
| OneDrive | 공유 링크 생성 | DLP 정책 검사 → 외부 공유 허용/차단 판단 |
| Power Automate | 흐름 완료 이벤트 | 다음 단계 에이전트 체인 활성화 |
자율도는 신뢰가 쌓인 범위에서 넓힌다
Scout를 처음부터 전사 자율 실행에 투입하면 권한과 예외 상황을 검증하기 어렵다. 파일럿에서 행동을 관찰하고, 저위험 작업부터 실행 권한을 넘긴 뒤, 롤백과 보안 모니터링이 작동하는 범위에서 자율도를 높이는 접근이 필요하다.
Phase 0은 1-2주의 파일럿 준비 기간이다. 반복적이고 규칙 기반이며 위험이 낮은 업무를 먼저 고른다. 필요한 Graph API 권한을 목록화해 에이전트 권한 매트릭스를 만들고, 샌드박스 테넌트에서 기능을 검증한다. 법무·컴플라이언스·보안팀의 검토도 이 단계에서 끝내야 한다.
Phase 1은 1개월 동안 AAL 1로 운영한다. 모든 작업을 기록하되 실제 실행에는 인간의 최종 승인을 둔다. 이 기간에 에이전트 행동 패턴을 확인하고 예외 상황 목록(Exception Catalog)을 수집한다.
Phase 2에서는 2-3개월에 걸쳐 AAL 2-3으로 범위를 넓힌다. 저위험 작업은 에이전트가 자율 실행하고 고위험 작업에만 사람이 개입한다. 자동 롤백을 활성화하고 SOC(보안운영센터) 모니터링과 연결한다.
Phase 3은 6개월+의 완전 자율 단계다. AAL 3-4로 전사 배포를 진행하면서 에이전트 거버넌스 프레임워크를 운영하고 성과 KPI를 정기적으로 검토한다.
실패를 멈추고 되돌릴 수 있어야 한다
자율 실행의 안전성은 사전 검사에서 끝나지 않는다. Scout는 실행 전, 실행 중, 실행 후의 방어 체계를 함께 사용한다.
사전 실행 단계에서는 의도 분류기가 요청한 작업이 허용된 정책 범위에 속하는지 판단한다. 메일 발송, 파일 삭제, 외부 공유처럼 되돌리기 어려운 작업을 식별해 추가 확인을 요구하고, 기밀 데이터가 포함돼 있다면 데이터 분류 레이블에 따라 처리를 제한한다.
실행 중에는 각 Graph API 호출 결과를 이상 탐지 모델로 평가한다. 예를 들어 API 오류가 3회 연속 발생해 실패 임계치를 넘으면 에이전트를 자동으로 일시 정지하고 Teams 메시지로 인간 감독자에게 알린다.
사후 복구는 작업 대상의 특성에 맞춰 설계한다. SharePoint 파일이나 OneNote 페이지처럼 버전 관리가 가능한 대상은 이전 버전으로 자동 복원한다. 메일은 지연 발송(Delay Send) 정책으로 취소할 수 있는 시간을 확보하며, Planner 작업의 생성·변경은 24시간 내 감사 기록을 바탕으로 취소할 수 있다.
롤백 런북(Runbook)은 에이전트 Playbook과 분리해 관리한다. 보안 사고가 발생했을 때 에이전트 ID를 즉시 비활성화할 수 있는 단일 명령 절차도 런북에 포함해야 한다.
권한이 다른 에이전트를 하나의 업무로 묶는다
엔터프라이즈 업무에서는 단일 Scout가 모든 권한을 가지기보다 역할별 에이전트가 협업하는 구조를 사용할 수 있다. 계약 처리 워크플로우라면 문서 분류, 법률 조항 분석, 일정 조율, 이해관계자 알림을 서로 다른 에이전트에 맡기는 방식이다.
여기서 중심 원칙은 **에이전트 책임 분리(Agent Responsibility Segregation)**다. 하위 에이전트에는 담당 도메인에 필요한 최소 권한만 부여한다. 오케스트레이터는 의사결정과 작업 위임을 맡지만 데이터를 직접 수정하지 않는다. 전통적인 직무 분리(Separation of Duties)를 에이전트 계층에 적용한 구조다.
엔터프라이즈 에이전트 플랫폼과의 차이
| 평가 항목 | Microsoft Scout Autopilot | Google Gemini Spark | Anthropic Claude Agent SDK |
|---|---|---|---|
| 에이전트 신원 | Entra ID 서비스 주체 (독립 ID) | Google Workspace 서비스 계정 | API 키 기반 (신원 체계 없음) |
| 접근 권한 모델 | Graph API Least-Privilege + Managed Identity | OAuth 2.0 도메인 위임 | 애플리케이션 정의 권한 |
| 감사 로그 | Microsoft Purview 통합 (에이전트 행위 독립 기록) | Cloud Audit Logs (Workspace 통합) | 애플리케이션 레이어 자체 구현 필요 |
| 자율 실행 범위 | M365 전 앱 크로스 연동 | Google Workspace 내 크로스 앱 | 도구 정의 기반 무제한 연동 |
| 멀티에이전트 | Scout 오케스트레이터 패턴 (기본 제공) | Gemini Agent Garden (베타) | MCP + Tool Use (개발자 구현) |
| 롤백 메커니즘 | SharePoint 버전 관리 연동 (자동) | Drive 버전 기록 활용 | 애플리케이션 레이어 구현 필요 |
| 컴플라이언스 | Microsoft 365 DLP·Purview 직접 연동 | Workspace DLP 연동 | 별도 컴플라이언스 레이어 필요 |
| 온프레미스 연동 | Azure AD Connect + M365 하이브리드 | Google Cloud Identity 연동 | 제한적 (SaaS 전용) |
| 도입 난이도 | 중간 (M365 기존 인프라 활용) | 중간 (Google Workspace 종속) | 높음 (자체 구현 부담) |
| 주요 강점 | M365 생태계 완결성, Entra ID 거버넌스 | AI 추론 품질, 멀티모달 | 유연성, 오픈 표준 지향 |
| 주요 약점 | Microsoft 종속성 | Workspace 외 연동 한계 | 엔터프라이즈 거버넌스 미비 |
Scout가 내세우는 경쟁력은 기존 엔터프라이즈 거버넌스 인프라와의 통합이다. Entra ID Conditional Access, Microsoft Purview DLP, Microsoft Sentinel SIEM이 추가 구성 없이 에이전트 활동을 포괄한다. Anthropic Claude Agent SDK는 높은 개발 유연성을 제공하지만, 엔터프라이즈 거버넌스 계층은 개발팀이 직접 구축해야 한다.
기존 관리 체계에 에이전트를 연결하는 관점
Scout의 독립 신원은 접근 통제 원칙을 AI 에이전트에 적용할 수 있게 한다. 최소 권한 원칙에 따라 Graph API 권한을 워크플로우 단위로 제한하고, 직무 분리 원칙에 따라 오케스트레이터와 실행 에이전트의 권한을 나눈다. 모든 행동은 Purview 감사 로그에 남겨 책임 추적(Accountability)의 근거로 사용한다.
업무 연속성 관리에서는 롤백과 인간 개입 경로를 BCP에 포함해야 한다. RTO(Recovery Time Objective)는 에이전트 장애 이후 자동 일시 정지, 관리자 알림, 수동 전환까지의 목표 시간으로 다룬다. RPO(Recovery Point Objective)는 SharePoint 버전 관리 정책을 기준으로 데이터 손실을 최소화할 지점을 정한다. 에이전트가 비활성화되면 Power Automate 폴백 워크플로우를 자동으로 작동시키는 페일오버 시나리오도 설계할 수 있다.
IT 서비스 관리에서는 AI 에이전트가 ITIL 4의 가치 공동 창출(Value Co-creation) 모델 안에서 서비스 공급자(Service Provider) 역할을 맡는다. 에이전트가 수행하는 변경은 변경 관리(Change Management)의 RFC(Request for Change) 프로세스와 연결해야 한다.
개인정보가 포함된 문서를 자율 처리한다면 GDPR·개인정보보호법 준수도 운영 정책에 반영해야 한다. 데이터 접근 목적은 정책 문서에 명시하고 Managed Identity 범위를 최소화해 접근 가능한 개인정보를 제한한다. Purview 감사 로그는 처리 기록(Records of Processing Activities), 즉 ROPA의 증빙으로 활용한다.
2026년 하반기에 예상되는 확장 방향
Microsoft Scout Autopilot이 지향하는 것은 단순한 자동화가 아니라 **에이전트 민주화(Agent Democratization)**다. 개발자가 아닌 비즈니스 사용자도 자연어로 에이전트를 정의하고 기존 기업 거버넌스 안에서 운영할 수 있는 환경을 목표로 한다.
2026년 하반기에는 SAP·Salesforce 같은 ERP/CRM을 연결하는 외부 데이터 커넥터 확대가 예상된다. 산업별로 미리 구성한 Scout 에이전트 템플릿을 제공하는 에이전트 마켓플레이스, B2B 환경에서 파트너사 에이전트가 데이터를 안전하게 교환하는 크로스 테넌트 협업도 확장 방향에 포함된다.
워크플로우별 처리 시간·오류율·비용 효율성을 실시간으로 추적하는 성능 분석 대시보드와 GDPR·HIPAA·금융 규제에 맞춰 사전 검증된 컴플라이언스 에이전트 팩도 예상되는 영역이다.
Scout의 성패는 에이전트가 수행할 수 있는 작업의 수보다 조직이 그 작업을 얼마나 통제하고 추적할 수 있는지에 달려 있다. Entra ID 기반 독립 신원, Purview 감사 로그, 단계적으로 조정하는 AAL은 에이전트를 기존 책임 체계에 편입하는 장치다. 실제 도입에서는 IT 보안팀·법무팀·현업 부서가 권한 정책과 감사 체계를 함께 설계해야 한다. 기술 배포에 앞서 신뢰의 경계를 정하는 작업이 필요하다.
Sources
- Microsoft Build 2026 Keynote: Scout Autopilot 발표 세션 공식 영상 (2026.05)
- Microsoft Tech Community: "Introducing Scout: The Next Generation of M365 Agents" (2026.05)
- Microsoft Entra ID 공식 문서: "Workload Identity and Managed Identity for AI Agents" (2026)
- Microsoft Graph API 공식 문서: "Sites.Selected Permission for SharePoint Agent Scoping" (2026)
- Microsoft Purview 공식 문서: "Audit logging for AI agent activities in Microsoft 365" (2026)
- Google Cloud Blog: "Gemini Spark for Google Workspace: Enterprise Agentic Workflows" (2026.04)
- Anthropic Documentation: "Claude Agent SDK — Enterprise Deployment Guide" (2026.03)
- NIST AI Risk Management Framework 1.0: Agentic System Trustworthiness Considerations
- ITIL 4 Foundation: AI-Enhanced Service Management Patterns (Axelos, 2025)
- 개인정보보호위원회: "AI 에이전트 개인정보 처리 가이드라인(안)" (2026.02)