Devlery
Blog/AI

API 없는 앱까지 누른다, Copilot Studio GA의 자동화 경계

Microsoft Copilot Studio computer use GA는 UI 자동화 에이전트를 실험에서 기업 배포와 감사 로그의 문제로 옮깁니다.

API 없는 앱까지 누른다, Copilot Studio GA의 자동화 경계
AI 요약
  • 무슨 일: Microsoft가 Copilot Studio computer use를 GA로 올렸습니다.
    • 에이전트가 API 없는 웹/데스크톱 앱을 화면, 마우스, 키보드, 비전 모델로 직접 조작하는 기능입니다.
  • 의미: UI 자동화 경쟁이 RPA 스크립트에서 감사 가능한 실행 에이전트로 이동합니다.
  • 실무 영향: Key Vault, Purview, Dataverse, Cloud PC pool이 모델보다 중요한 구매 조건이 됩니다.
    • "사람처럼 클릭한다"는 기능보다 credential scope, human checkpoint, session replay가 운영 리스크를 좌우합니다.

Microsoft가 Copilot Studio의 computer-using agents를 일반 제공으로 올렸습니다. 발표만 보면 또 하나의 에이전트 기능처럼 보일 수 있습니다. 하지만 이 뉴스의 핵심은 "Copilot이 더 똑똑해졌다"가 아닙니다. 기업 업무에서 가장 오래 남아 있던 자동화 사각지대, 즉 API가 없거나 부족한 웹/데스크톱 앱을 에이전트가 직접 화면으로 다루는 기능이 실험 단계에서 배포 단계로 넘어갔다는 점입니다.

Microsoft의 공식 GA 발표는 2026년 5월 13일 올라왔습니다. 글은 computer use가 Microsoft Copilot Studio에서 일반 제공되고, Microsoft Power Platform의 모든 commercial geographies로 확장된다고 설명합니다. 이어 2026년 5월 26일 Copilot Studio 월간 업데이트는 computer-using agents, 새로운 workflows experience, Work IQ extensibility, real-time voice experiences를 한 묶음으로 다시 정리했습니다.

여기서 중요한 단어는 GA입니다. Preview나 demo에서는 에이전트가 브라우저를 열고 버튼을 누르는 장면만으로도 충분히 인상적입니다. 그러나 기업 자동화에서는 그다음 질문이 더 중요합니다. 누가 credential을 보관하는가. 실패한 실행을 누가 재생해 볼 수 있는가. 사람이 승인해야 하는 지점은 어디인가. 어떤 앱에는 접근하지 못하게 막을 수 있는가. 에이전트가 클릭한 화면과 로그는 감사 대상으로 남는가. Microsoft는 이번 GA를 이런 운영 질문에 대한 제품 답으로 포장하고 있습니다.

Microsoft Learn의 release plan은 computer use를 GUI가 있는 시스템과 상호작용하는 Copilot Studio 기능으로 설명합니다. 웹사이트나 데스크톱 애플리케이션에서 버튼을 누르고, 메뉴를 고르고, 필드에 입력하는 식입니다. 사용자는 자연어로 작업을 설명하고, 에이전트는 구성된 컴퓨터에서 virtual mouse와 keyboard로 실행합니다. API가 없을 때도 data entry, invoice processing, data extraction 같은 반복 업무를 처리할 수 있다는 설명입니다.

이 정의는 RPA와 닮았습니다. 그러나 Microsoft가 강조하는 차이는 selector가 아니라 vision과 reasoning입니다. 기존 RPA는 안정적인 DOM selector, 좌표, workflow rule에 강합니다. 반대로 화면이 바뀌거나 조건 분기가 늘어나면 유지보수 비용이 커집니다. Computer-Using Agents는 화면을 보고 다음 행동을 고르는 방식으로 이 문제를 줄이려 합니다. Microsoft는 이것을 "legacy system에 API가 나올 때까지 기다리지 않아도 되는 자동화"로 제시합니다.

물론 이 말은 곧바로 "RPA가 끝났다"는 뜻이 아닙니다. 오히려 Microsoft의 메시지는 더 현실적입니다. 안정적인 절차와 문서화된 API가 있는 작업은 기존 workflow, connector, Power Automate, RPA가 더 낫습니다. Computer use는 UI가 자주 바뀌거나, API가 없거나, 사람이 매번 판단을 섞어 처리하던 긴 꼬리 업무에 맞습니다. 다시 말해 이것은 모든 자동화의 대체재가 아니라 자동화할 수 없다고 여겨졌던 영역을 밀어붙이는 보조 실행층입니다.

Microsoft가 2026년 2월에 공개한 computer-using agents 업데이트를 같이 보면 GA의 방향이 더 선명합니다. 해당 글은 OpenAI Computer-Using Agent와 Anthropic Claude Sonnet 4.5를 포함한 model choice, built-in credentials, Azure Key Vault, session replay, action logs, Purview integration, Dataverse logging, Windows 365 Cloud PC pool을 소개했습니다. 모델 이름보다 눈에 띄는 것은 보안과 운영 기능입니다.

이 조합은 Microsoft가 어디를 겨냥하는지 보여줍니다. 개인 사용자가 자신의 브라우저에서 한 번 쓰는 에이전트가 아닙니다. 관리자가 agent fleet을 통제하고, security team이 로그를 보고, compliance team이 실행 증거를 보관하고, 운영팀이 Cloud PC capacity를 조절하는 형태입니다. Copilot Studio computer use의 경쟁자는 단순히 Anthropic Computer Use API나 Google의 브라우저 조작 데모가 아닙니다. UiPath, Automation Anywhere, Power Automate Desktop, ServiceNow, Salesforce, SAP처럼 기업 업무 자동화 예산을 두고 경쟁하는 플랫폼입니다.

Graebel Service Order Agent 아키텍처

Microsoft가 5월 업데이트에서 강조한 Graebel 사례는 이 포지션을 잘 보여줍니다. Graebel은 약 1,500명 규모의 global talent mobility 기업으로, 다국적 기업 직원의 relocation service order를 처리합니다. Microsoft 설명에 따르면 상당수 요청은 자유형 이메일, 첨부파일, 예외 조건이 섞인 상태로 들어옵니다. 사람이 읽고, 해석하고, proprietary Global Connect platform에 입력해야 했습니다. 문제는 Global Connect가 API 기반 통합을 지원하지 않았고, 기존 RPA 시도도 사람의 이메일 변동성을 따라가기 어려웠다는 점입니다.

Graebel의 Service Order Agent는 이 지점에서 computer use를 씁니다. 앞단에서는 Azure Content Understanding으로 이메일과 첨부 문서에서 key data를 구조화합니다. 그다음 요청을 business rule과 compliance requirement에 맞춰 검증합니다. 그리고 Global Connect 화면을 직접 조작해 데이터를 입력하고 transaction을 완료합니다. Microsoft는 이 agent가 live today이며, 30개 이상 relocation service categories로 확장되도록 설계됐다고 설명합니다.

이 사례는 과장 없이 중요합니다. 실제 기업 시스템에는 "중요하지만 API가 없는" 화면이 많습니다. 공급업체 포털, 오래된 ERP 화면, 사내 승인 도구, 보험/물류/재무 처리 시스템, 지역별 규제 포털이 여기에 들어갑니다. 이런 시스템을 모두 새 API로 재개발하는 것은 비용이 크고, 공급업체가 움직이지 않으면 불가능합니다. Computer use는 이 낡은 표면을 에이전트의 작업 표면으로 바꾸려는 시도입니다.

하지만 여기에는 위험도 있습니다. API는 구조화된 계약입니다. 어떤 endpoint에 어떤 schema로 요청하고, 어떤 권한으로 어떤 값을 바꾸는지 비교적 명확합니다. UI 조작은 그렇지 않습니다. 버튼 라벨이 바뀌거나, 팝업이 뜨거나, 화면 순서가 달라지거나, 같은 단어가 다른 의미로 쓰이면 에이전트는 오판할 수 있습니다. 따라서 computer use의 핵심 리스크는 모델이 똑똑한가보다 "실패했을 때 시스템이 얼마나 빨리 멈추고, 기록하고, 사람에게 넘기는가"입니다.

검토 항목Microsoft가 앞세운 기능운영팀 질문
CredentialBuilt-in credentials, Azure Key Vault에이전트별 최소 권한과 회전 정책이 있는가
감사Session replay, action logs, Purview, Dataverse클릭, 좌표, 화면, 예외가 재현 가능한가
통제Allow lists, DLP, environment isolation허용 앱과 금지 앱의 경계가 명확한가
실행 표면Browser, desktop apps, Windows 365 Cloud PC pool장기 실행과 capacity spike를 어떻게 감당하는가

특히 session replay와 action log는 computer use를 단순 데모에서 기업 기능으로 바꾸는 핵심입니다. Microsoft는 action type, coordinates, timestamps, context, run summary, duration, action counts, human escalation counts 같은 항목을 언급합니다. 에이전트가 어느 화면을 봤고, 어느 버튼을 눌렀고, 어떤 credential을 사용했는지 남기는 방향입니다. 금융, 헬스케어, 제조, 공공 업무에서는 이 기록 없이는 자동화가 production으로 들어가기 어렵습니다.

Human-in-the-loop checkpoint도 같은 맥락입니다. 에이전트가 낮은 confidence 상태에 있거나, 예외를 만나거나, 업무상 사람이 승인해야 하는 결정을 만났을 때 멈춰야 합니다. 여기서 설계가 허술하면 AI 자동화는 "빠른 처리"가 아니라 "빠른 사고"가 됩니다. 반대로 적절한 checkpoint가 있으면 사람은 모든 클릭을 직접 하지 않고도 중요한 판단 지점에만 개입할 수 있습니다. 자동화의 절약 효과는 이 경계 설정에서 나옵니다.

Windows 365 Cloud PC pool은 덜 화려하지만 중요한 조각입니다. UI automation은 실제 실행 표면이 필요합니다. 브라우저와 데스크톱 앱을 띄울 컴퓨터가 있어야 하고, 그 컴퓨터는 패치되고, 격리되고, 인증되고, scale out될 수 있어야 합니다. Microsoft는 Cloud PC pool을 computer use runs에 맞춘 관리형 cloud-hosted machine으로 설명합니다. 이는 에이전트 모델보다 더 낮은 층의 인프라 문제입니다. 그러나 기업 자동화에서는 이 층이 자주 병목이 됩니다.

개발자에게 흥미로운 지점은 Copilot Studio가 low-code 도구라는 점입니다. 이 기능은 전통적인 API-first 개발자 플랫폼이 아니라 Power Platform과 Copilot Studio의 maker 경험 안에 들어갑니다. 즉 조직 안의 automation team, business analyst, operations team이 에이전트 실행을 만들 수 있는 경로입니다. 동시에 developer team은 더 복잡한 system integration, Dataverse, workflow, governance, custom connector, monitoring 쪽을 맡게 됩니다. AI agent가 개발자를 없애는 것이 아니라 자동화 표면을 넓히고, 개발자가 책임져야 할 운영 경계를 바꾸는 쪽에 가깝습니다.

Microsoft Learn의 What's new in Copilot Studio 페이지도 같은 방향을 보여줍니다. 최근 항목에는 agent evaluation, REST API 기반 평가 자동화 preview, custom metrics, A2A protocol, Work IQ tools, model selection, prompt builder 개선, Visual Studio Code extension 같은 기능이 나열됩니다. Computer use만 따로 떨어진 기능이 아니라 agent lifecycle, evaluation, orchestration, governance, developer workflow의 일부로 배치되고 있습니다.

이 흐름은 최근 에이전트 플랫폼 경쟁과도 맞물립니다. Google은 Gemini API Managed Agents로 실행 환경을 API 제품 안으로 끌어오고 있습니다. Anthropic은 Claude Code, MCP, Stainless 인수, enterprise connector를 통해 에이전트가 닿는 시스템을 넓히고 있습니다. OpenAI는 Codex와 Agents SDK, sandbox, remote task 흐름을 밀고 있습니다. Microsoft는 이들과 달리 Microsoft 365, Power Platform, Windows 365, Purview, Entra, Dataverse라는 기업 운영 계층을 전면에 둡니다. 모델 경쟁보다 "이미 기업이 쓰는 통제면 위에서 에이전트를 굴릴 수 있는가"를 묻는 전략입니다.

보조 분석들은 Microsoft의 GA를 Anthropic과 Google의 computer-use 계열 기능과 비교하며 production readiness를 강조합니다. 다만 이런 비교는 조심해서 읽어야 합니다. Microsoft가 모든 computer-use 문제를 먼저 해결했다는 뜻은 아닙니다. Copilot Studio라는 제품 경계, Power Platform 상용 지역, sovereign cloud 제외 여부, 라이선스와 credit 비용, generative orchestration 요구, 지원되는 앱 표면, external model 사용 시 데이터 처리 위치 같은 조건이 붙습니다. "GA"는 실무 검토가 끝났다는 말이 아니라 procurement와 운영 검토를 시작할 수 있는 기준선에 가깝습니다.

커뮤니티 반응에서도 이 점이 보입니다. r/copilotstudio 같은 사용자 공간에서는 computer use 자체보다 agent status, premium feature 표시, Agent Builder 통제, 기존 agent의 동작 안정성 같은 이야기가 이어집니다. 이는 냉소가 아니라 현실적인 신호입니다. 엔터프라이즈 에이전트에서 사용자가 막히는 지점은 모델 데모가 아니라 라이선스, admin policy, tenant 설정, migration, support boundary입니다. Microsoft가 강한 영역이기도 하지만 동시에 복잡도가 커지는 영역이기도 합니다.

한국 기업과 개발팀 관점에서도 이 뉴스는 꽤 실용적입니다. 많은 조직이 이미 Microsoft 365, Power Platform, Azure AD/Entra, Purview, Teams를 쓰고 있습니다. 이런 환경에서는 완전히 새로운 agent runtime을 도입하는 것보다 Copilot Studio 안에서 작은 업무 자동화를 시작하는 경로가 더 빠를 수 있습니다. 예를 들어 공급업체 포털에서 상태를 확인하고 ERP에 입력하는 작업, 메일로 들어온 요청을 사내 시스템에 등록하는 작업, 규제 사이트에서 데이터를 가져와 내부 양식에 옮기는 작업이 후보가 됩니다.

그러나 첫 프로젝트를 고를 때는 욕심을 줄여야 합니다. 돈이 직접 움직이거나, 고객 데이터가 대량 변경되거나, 취소하기 어려운 업무는 첫 대상이 아닙니다. 화면이 비교적 안정적이고, 사람의 검토 지점이 분명하며, 실패해도 되돌릴 수 있고, 기존 처리 기록이 충분한 업무가 낫습니다. 에이전트가 화면을 조작한다는 것은 테스트도 화면 단위로 해야 한다는 뜻입니다. happy path만 녹화해서는 부족합니다. 팝업, 오류 메시지, 세션 만료, 느린 로딩, 권한 부족, 중복 입력까지 봐야 합니다.

또 하나의 질문은 API와 computer use의 우선순위입니다. API가 있다면 API를 쓰는 것이 대체로 낫습니다. 구조화된 계약, 안정적인 오류 처리, 낮은 비용, 테스트 용이성, 권한 분리가 더 좋기 때문입니다. Computer use는 API가 없거나 불완전한 영역을 위한 선택지입니다. 따라서 좋은 아키텍처는 "모든 것을 화면으로 클릭하게 하자"가 아니라 "API와 workflow로 가능한 부분은 구조화하고, 마지막 UI-only 구간만 computer use로 넘기자"에 가깝습니다. Graebel 사례도 이메일 구조화, business rule validation, Dataverse 같은 계층과 computer use를 결합합니다.

이 뉴스의 가장 큰 의미는 에이전트의 정의가 다시 넓어지고 있다는 점입니다. 챗봇은 답변합니다. Tool-calling agent는 API를 호출합니다. Coding agent는 파일과 터미널을 다룹니다. Computer-using agent는 사람이 보던 화면을 직접 작업 표면으로 삼습니다. 이 단계에 오면 에이전트는 단순한 모델 호출이 아니라 조직의 권한, 업무 규칙, 실행 환경, 감사 로그를 함께 다루는 운영 단위가 됩니다.

그래서 Copilot Studio computer use GA는 화려한 모델 발표보다 덜 눈에 띄지만, 기업 AI 시장에서는 더 오래 남을 수 있는 뉴스입니다. API 없는 앱까지 에이전트가 누를 수 있게 되면 자동화 후보는 크게 늘어납니다. 동시에 잘못 누른 클릭의 책임도 더 커집니다. Microsoft가 이번에 내놓은 답은 "더 똑똑한 모델"보다 "credential, audit, governance, Cloud PC를 묶은 실행층"입니다. 에이전트 시대의 승부가 점점 답변 품질에서 작업 증거와 통제권으로 내려오고 있다는 신호입니다.