마이크로소프트, 오픈클라우드 스크루트 출시

Microsoft가 Build에서 공개한 Scout는 OpenClaw의 에이전트 아키텍처를 Microsoft 365 생태계에 이식한 개인 비서로, 핵심은 LLM을 단순 대화 엔진이 아니라 '도구를 호출하는 실행 주체(agentic loop)'로 다루는 데 있다. OpenClaw 계열 설계의 특징은 모델이 사용자의 의도를 받아 계획을 세우고, 파일 검색·메일 조회·캘린더 수정 같은 외부 도구(tool)를 함수 호출 형태로 반복 실행하며, 그 결과를 컨텍스트에 다시 주입해 다음 행동을 결정하는 순환 구조다. Scout는 여기에 Microsoft Graph API를 권한 경계로 묶어, Outlook·Teams·SharePoint·OneDrive 등 조직 데이터에 접근하되 사용자의 기존 RBAC와 테넌트 정책을 그대로 상속받도록 했다. 즉 새로운 권한 모델을 만드는 대신 기존 엔터프라이즈 ID(Entra ID) 위에 에이전트의 행동 범위를 위임(delegated permission)하는 방식으로, 데이터 거버넌스 책임을 모델이 아니라 플랫폼 계층에서 통제한다는 점이 OpenClaw 원형과의 가장 큰 차이다.

개발자 관점에서 실질적인 영향은 '비서 앱'이 아니라 '확장 가능한 에이전트 런타임'이 표준화된다는 데 있다. Scout가 OpenClaw에서 빌려온 플러그인/커넥터 모델을 따른다면, 사내 API나 사내 시스템을 도구로 등록하는 순간 자연어만으로 그 기능이 호출 가능해진다. 이는 곧 사내 시스템의 OpenAPI 스펙, 명확한 함수 시그니처, 그리고 멱등성(idempotency) 보장이 새로운 'UI'가 된다는 의미다. 동시에 위험도 커진다. 에이전트가 메일을 보내거나 파일을 수정하는 등 부수효과(side effect)를 일으키는 행동을 자율적으로 수행하므로, 프롬프트 인젝션으로 도구 호출이 탈취되면 곧바로 데이터 유출이나 무단 작업으로 이어질 수 있다. 특히 외부에서 들어온 콘텐츠(수신 메일, 공유 문서)가 컨텍스트에 섞이는 RAG 구조에서는 '신뢰할 수 없는 입력이 도구 실행 권한을 얻는' 전형적인 confused deputy 문제가 발생한다.

따라서 엔지니어가 지금 점검해야 할 것은 세 가지다. 첫째, 자사 시스템을 Scout 도구로 노출할 계획이라면 읽기/쓰기 도구를 분리하고, 파괴적이거나 외부로 나가는 행동에는 반드시 사람 확인(human-in-the-loop) 단계를 두는 설계를 기본값으로 삼아야 한다. 둘째, Graph 권한을 위임할 때 최소 권한 원칙을 적용하고, 에이전트 행동에 대한 감사 로그(audit log)와 추적 가능성을 확보해 사후 검증이 가능하도록 해야 한다. 셋째, 프롬프트 인젝션 방어를 애플리케이션 책임으로 간주하고, 도구 호출 결과를 신뢰하기 전 검증 계층을 두며 외부 콘텐츠와 시스템 지시를 구조적으로 분리해야 한다. Scout가 OpenClaw 호환 인터페이스를 표방하는 만큼, 한 번 잘 설계한 도구·권한 모델은 다른 에이전트 플랫폼에도 재사용할 수 있으므로, 특정 벤더에 종속되지 않는 표준 기반(OpenAPI, 명시적 함수 계약, 위임형 인증)으로 투자해 두는 것이 장기적으로 가장 안전한 선택이다.