에이전트에게도 PC가 필요하다, Windows 365의 격리 조건

AI 요약

• 무슨 일: Microsoft가 Windows 365 for Agents 공개 프리뷰 확장을 다시 전면에 세웠습니다.
  • 2026년 5월 21일 보안 업데이트에서 Agent 365는 권한, Windows 365 for Agents는 실행 위치를 맡는 구조로 설명됐습니다.
• 핵심 구조: 에이전트는 관리형 Cloud PC를 체크아웃해 작업하고 세션 뒤 초기화됩니다.
• 개발자 의미: 에이전트 운영의 병목이 모델 호출에서 identity, 샌드박스, 감사 로그로 이동합니다.
• 주의점: 현재 공개 프리뷰는 미국 한정이며, 실제 비용과 운영 복잡도는 아직 검증 구간입니다.

Microsoft가 에이전트에게 “자기 PC”를 주는 방향으로 움직이고 있습니다. 여기서 PC는 사람이 로그인해 쓰는 노트북이 아니라, Microsoft Entra ID와 Intune 정책, Defender 신호, Purview 감사 범위 안에 들어온 Cloud PC입니다. 2026년 5월 21일 Microsoft Security의 월간 업데이트는 Windows 365 for Agents가 공개 프리뷰에서 확장 중이며, Microsoft Agent 365와 함께 “에이전트를 실행하고 통제하는” 짝을 이룬다고 설명했습니다.

이 뉴스가 흥미로운 이유는 상품명이 Windows 365라는 점보다 역할 분담에 있습니다. Agent 365는 에이전트가 무엇을 할 수 있는지 정하는 거버넌스 평면입니다. Windows 365 for Agents는 그 에이전트가 어디에서 실제 작업을 수행하는지 정하는 실행 평면입니다. Microsoft는 이를 “일관되고 안전한 환경에서 에이전트를 실행하고 거버넌스한다”는 문장으로 요약합니다. 더 직설적으로 말하면, 기업 에이전트가 사람의 PC, 개발자 노트북, 임시 컨테이너, 관리되지 않는 브라우저 세션을 돌아다니며 권한을 빌리는 구조를 Microsoft 365 관리 모델 안으로 끌어오겠다는 뜻입니다.

최근 AI 에이전트 논의는 대부분 모델 성능, 툴 호출, 코딩 능력, 브라우저 조작 능력에 몰려 있었습니다. 그러나 실제 기업 배포에서는 더 건조한 질문이 먼저 나옵니다. 에이전트가 어떤 ID로 로그인합니까? 파일을 다운로드하면 누가 책임집니까? 세션이 끝난 뒤 쿠키와 임시 파일은 남습니까? 보안팀은 어떤 로그를 봅니까? 특정 에이전트가 SaaS나 클라우드 리소스에 연결될 때, 그 권한 경로를 한 장의 그래프로 볼 수 있습니까? Windows 365 for Agents는 바로 이 질문을 겨냥합니다.

Agent 365는 권한, Windows 365는 실행 위치

Microsoft의 5월 1일 발표를 보면 Agent 365의 관심사는 명확합니다. 조직 안팎의 에이전트를 발견하고, 레지스트리에 올리고, 어떤 사용자를 대신하는지 또는 자체 권한으로 움직이는지 구분하고, 정책을 적용하는 것입니다. 발표문은 사용자가 기기에 설치하는 로컬 에이전트와 개발자가 SaaS나 클라우드 플랫폼 위에 올리는 에이전트가 전통적인 관리 바깥에서 움직이며 “shadow AI”를 만든다고 봅니다.

이 문맥에서 Windows 365 for Agents는 Agent 365의 또 다른 기능이 아니라, 에이전트가 일을 수행하는 격리된 작업장입니다. Microsoft는 5월 1일 글에서 Agent 365가 관찰, 거버넌스, 보안의 제어 평면을 제공하는 반면 Windows 365 for Agents는 에이전트가 작업을 수행할 수 있는 보안 관리 환경을 제공한다고 설명했습니다. 에이전트는 정책 통제 환경에서 애플리케이션과 상호작용하고, 직원에게 적용되는 ID, 보안, 관리 통제를 공유합니다.

이 분리는 중요합니다. 많은 에이전트 플랫폼은 “에이전트가 무엇을 할 수 있는지”를 프롬프트, 툴 권한, API 토큰 목록으로 표현합니다. 그러나 실제 업무는 브라우저, 데스크톱 앱, 문서, 사내 웹앱, SSO, 다운로드 폴더, 임시 캐시, 네트워크 목적지 위에서 일어납니다. 권한 정책만 있고 실행 표면이 관리되지 않으면 감사와 차단은 뒤늦게 따라옵니다. 반대로 격리 실행 환경만 있고 조직 ID와 정책이 약하면 에이전트는 안전한 빈 상자 안에서만 움직입니다. Microsoft가 두 제품을 나누어 설명하는 이유도 여기에 있습니다.

체크아웃하고 초기화되는 Cloud PC

Microsoft Learn 문서는 Windows 365 for Agents를 에이전트 사용을 위한 새로운 Cloud PC 클래스라고 설명합니다. 기업은 에이전트용 Cloud PC 프로비저닝 정책을 만들고, 팀이나 워크로드에 맞춰 Cloud PC 풀을 구성합니다. 에이전트가 작업해야 할 때는 풀에서 Cloud PC를 체크아웃합니다. 작업이 끝나면 체크인하고, 그 자원은 다시 풀로 돌아갑니다.

여기서 “Cloud PC”라는 단어가 조금 낡게 들릴 수 있습니다. 하지만 에이전트 입장에서는 상당히 구체적인 의미가 있습니다. 브라우저 자동화만 필요한 작업도 있고, 레거시 Windows 데스크톱 앱을 조작해야 하는 작업도 있으며, 사내 포털과 Office 문서를 동시에 다루는 작업도 있습니다. 컨테이너나 헤드리스 브라우저만으로는 기업 업무 표면 전체를 다루기 어렵습니다. Windows 365 for Agents는 Windows 데스크톱, Linux 기반 컴퓨터 사용 흐름, Microsoft 365 앱, Intune 관리, Entra 인증을 하나의 실행 단위로 묶으려 합니다.

보안 설계 문서는 이 Cloud PC를 세 단어로 정리합니다. pooled, stateless, programmatic입니다. 공유 풀에서 작업마다 동적으로 배정되고, 세션 뒤 상태가 남지 않으며, 사람의 대화형 사용이 아니라 프로그램형 에이전트 워크로드가 접근합니다. 이 조합은 에이전트 운영에서 특히 중요합니다. 에이전트는 같은 작업을 빠르게 반복하고, 여러 SaaS와 파일을 넘나들며, 실수하면 사람보다 훨씬 빠르게 피해 범위를 넓힐 수 있기 때문입니다.

ID가 장치보다 앞서는 모델

Windows 365 for Agents의 더 중요한 특징은 “장치에 붙은 권한”보다 “세션과 에이전트 ID에 붙은 권한”을 앞세운다는 점입니다. Microsoft Learn은 각 에이전트가 사람 사용자와 분리된 전용 Microsoft Entra agent user identity를 사용한다고 설명합니다. 이 ID는 Agent 365에서 수명주기와 감사가 관리되고, Cloud PC 세션으로 들어갈 때 토큰 기반 흐름으로 인증됩니다. 에이전트는 사람의 자격 증명을 재사용하거나 가장하지 않는다는 점도 강조됩니다.

이 구조는 에이전트가 실무에 들어갈 때 자주 생기는 애매함을 줄입니다. 예를 들어 영업 자료를 정리하는 에이전트가 CRM, SharePoint, 이메일, 브라우저를 오가며 작업한다고 합시다. 기존 자동화라면 서비스 계정, 위임 권한, 사용자 세션, RPA 봇 계정이 뒤섞일 수 있습니다. 나중에 감사 로그를 보면 “누가 요청했고, 어떤 에이전트가 어떤 ID로 무엇을 했는지”를 재구성해야 합니다. Microsoft의 목표는 이 체인을 Agent 365, Entra sign-in logs, Defender, Purview에서 이어서 보는 것입니다.

이는 개발자에게도 직접적인 요구사항을 남깁니다. 앞으로 기업용 에이전트는 단순히 API 키를 잘 숨기고 툴 목록을 줄이는 것만으로는 부족해질 가능성이 큽니다. 에이전트마다 고유 ID가 있어야 하고, 세션마다 인증이 다시 수립되어야 하며, 작업 뒤 환경이 초기화되어야 합니다. 또 어떤 사용자의 요청으로 어떤 에이전트가 어떤 리소스에 접근했는지 설명할 수 있어야 합니다. “좋은 에이전트 UX”와 “좋은 보안 운영 모델”이 점점 같은 설계 문제가 되는 셈입니다.

로컬 코딩 에이전트까지 들어오는 감사 범위

Agent 365 발표에서 특히 눈에 띄는 대목은 로컬 에이전트 탐지입니다. Microsoft는 Defender와 Intune을 통해 Windows 기기에서 실행되는 로컬 AI 에이전트를 발견하고 관리하는 기능을 예고했습니다. 시작점은 OpenClaw이며, 이후 GitHub Copilot CLI와 Claude Code 같은 널리 쓰이는 에이전트로 확장하겠다고 밝혔습니다.

이 대목은 코딩 에이전트 시장에 꽤 큰 신호입니다. 지금까지 많은 코딩 에이전트는 개발자의 로컬 권한 위에서 움직였습니다. 저장소를 읽고, 파일을 수정하고, 테스트를 실행하고, 터미널 명령을 날립니다. 개발자에게는 자연스러운 워크플로지만 보안팀에게는 어려운 표면입니다. 에이전트가 어떤 MCP 서버를 붙였는지, 어떤 클라우드 자격 증명에 닿을 수 있는지, 어떤 네트워크 목적지로 나갔는지, 민감 파일을 읽었는지 파악하기 어렵기 때문입니다.

Microsoft는 2026년 6월부터 Defender가 각 에이전트에 대해 실행 장치, 구성된 MCP 서버, 연결된 ID, 도달 가능한 클라우드 리소스의 관계 맵을 제공할 것이라고 설명했습니다. 이 기능이 실제로 충분한 정확도와 낮은 오탐으로 작동한다면, 코딩 에이전트 도입 논의는 “개발자가 좋아하느냐”에서 “조직이 에이전트 행동 그래프를 볼 수 있느냐”로 이동합니다. 이는 Anthropic, OpenAI, GitHub, Cursor 같은 개발자 도구 회사에도 압력으로 작용할 수 있습니다.

미국 한정 프리뷰라는 현실적인 제약

다만 Windows 365 for Agents를 곧바로 보편적 실행 표준처럼 읽으면 과합니다. Microsoft Learn 문서는 공개 프리뷰가 미국에서만 제공된다고 밝힙니다. 프리뷰 기능은 일반 공급 전까지 바뀔 수 있습니다. 비용 모델, 풀 크기 설계, 세션 시작 지연, 앱 호환성, 브라우저 자동화 안정성, 로그 보존 정책, 파트너 에이전트와의 통합 품질은 실제 고객 환경에서 검증되어야 합니다.

또 하나의 변수는 복잡도입니다. 기업이 이미 Entra, Intune, Defender, Purview, Microsoft 365 관리 체계를 깊게 쓰고 있다면 Windows 365 for Agents는 자연스러운 확장으로 보일 수 있습니다. 반대로 멀티클라우드와 오픈소스 에이전트 프레임워크 중심 조직에는 무거운 조달 및 관리 계층으로 느껴질 수 있습니다. 에이전트 샌드박스가 필요한 것은 분명하지만, 그 샌드박스가 꼭 Cloud PC여야 하는지는 워크로드별로 다릅니다.

예를 들어 코드 실행, 패키지 설치, 테스트, 웹 검색이 주된 에이전트라면 컨테이너형 샌드박스가 더 가볍고 빠를 수 있습니다. 브라우저와 데스크톱 앱, 사내 SSO, Office 문서, 레거시 업무 앱을 동시에 다루는 에이전트라면 Cloud PC의 장점이 커집니다. Microsoft가 노리는 지점은 후자입니다. 즉 “AI 에이전트용 컴퓨트”가 GPU 추론이나 서버리스 함수만 뜻하지 않고, 기업 업무 표면을 안전하게 조작하는 관리형 데스크톱까지 포함한다는 주장입니다.

에이전트 인프라의 다음 경쟁축

Windows 365 for Agents는 화려한 모델 발표가 아닙니다. 새 추론 성능 수치도 없고, 일반 사용자가 당장 체감할 챗봇 기능도 아닙니다. 하지만 에이전트가 실제 업무를 맡는 순간 필요한 층을 잘 보여줍니다. 실행 환경은 격리되어야 하고, ID는 사람과 분리되어야 하며, 작업은 감사 가능해야 하고, 세션은 초기화되어야 합니다. 동시에 에이전트는 여전히 현실의 앱과 웹페이지, 문서, 클라우드 리소스를 조작해야 합니다.

이 조건을 만족하는 플랫폼은 앞으로 에이전트 시장의 조달 기준이 될 가능성이 큽니다. AI 모델 회사가 더 똑똑한 에이전트를 만들수록 기업은 더 강한 실행 통제를 요구합니다. 개발자가 로컬 에이전트와 MCP 서버를 빠르게 붙일수록 보안팀은 어떤 도구가 어떤 권한으로 움직이는지 묻습니다. Microsoft는 이 질문에 Windows 365와 Agent 365라는 기존 엔터프라이즈 자산으로 답하려 합니다.

그래서 이번 뉴스의 핵심은 “에이전트가 Cloud PC에서 돈다”가 아닙니다. 더 큰 변화는 에이전트 실행 위치가 독립 제품이 되고 있다는 점입니다. 모델, 프롬프트, 툴 목록만으로 에이전트를 설명하던 시기는 짧았습니다. 이제는 에이전트가 체크아웃한 작업장, 그 작업장의 ID, 정책, 네트워크, 로그, 초기화 절차까지 함께 봐야 합니다. 에이전트에게도 PC가 필요하다는 말은 결국 에이전트에게도 조직 안에서 책임질 수 있는 자리가 필요하다는 뜻입니다.