GitHub Copilot 컴퓨터 유즈(computer use) 정리 — 데스크톱 앱 조작 켜는 법과 권한·보안 주의점
GitHub Copilot의 **컴퓨터 유즈(computer use)**는 Copilot이 사람 대신 데스크톱 앱 화면을 읽고, 버튼을 누르고, 글자를 입력하는 기능이다. GitHub는 10월 1일 체인지로그에서 이 기능을 Copilot CLI와 GitHub Copilot 앱에 공개 프리뷰로 넣었다고 밝혔다. 지원 운영체제는 macOS와 Windows, 그것도 로컬 세션에서만 돌아간다. 기본값은 꺼짐이다. 쓰려면 직접 켜야 한다.
지금까지 코딩 에이전트가 손댈 수 있는 범위는 API나 명령줄, MCP 서버가 있는 도구로 한정됐다. 사내에서 오래 쓴 업무 프로그램처럼 화면만 있고 연동 수단이 없는 소프트웨어는 사람이 마우스로 처리할 수밖에 없었다. GitHub가 이 기능의 쓰임새로 '레거시 앱'과 'GUI 전용 소프트웨어'를 맨 앞에 내세운 이유가 여기 있다.
화면을 어떻게 읽고 움직이나
공식 문서 설명을 보면 컴퓨터 유즈는 두 가지 재료로 화면을 이해한다. 하나는 운영체제의 접근성 트리다. 화면 낭독기가 "여기에 '저장' 버튼이 있다", "이 칸은 이메일 입력란이다"를 읽어 낼 수 있도록 앱이 운영체제에 넘겨주는 구조 정보를 말한다. 다른 하나는 스크린샷 같은 시각 정보다. 접근성 정보만으로 부족한 화면은 눈으로 보듯 이미지를 참고한다.
이렇게 파악한 화면 위에서 Copilot이 쓰는 동작은 클릭, 텍스트 입력·수정, 키 누르기, 스크롤, 드래그, 그리고 여러 앱을 오가는 이동이다. 어떤 동작을 쓸지는 요청을 처리하면서 그때그때 고른다. CLI 쪽에서는 이 기능이 별도 내장 플러그인과 MCP 서버, 관련 스킬 묶음으로 붙는다 — /computer show가 이 세 가지의 활성 상태를 보여 주는 것도 그래서다.
문서가 꼽는 대표 활용 예는 네 가지다.
- 레거시 데스크톱 앱에 떠 있는 내용을 훑어보고 요약하기
- 프레젠테이션 자료 고치기
- GUI로만 입력할 수 있는 소프트웨어에 정보 넣거나 바꾸기
- 여러 앱 사이로 정보를 옮기는 다단계 작업
체인지로그에는 브라우저 알림을 요약하는 예도 들어 있다.
켜는 법과 쓸 수 있는 조건
먼저 조건부터 보자. Copilot CLI는 설치 문서상 활성 Copilot 구독이 있으면 쓸 수 있고, Copilot 앱 문서는 "모든 Copilot 요금제에서 사용 가능"하다고 적고 있다. 다만 Copilot Business·Enterprise 사용자는 조직 관리자가 Copilot 앱 정책을 켜 둬야 하고, 관리자가 관리 설정으로 컴퓨터 유즈 자체를 막을 수도 있다. 이렇게 막힌 경우엔 개인이 로컬에서 켜도 조직 정책을 넘어서지 못한다. 프리뷰 기간에 별도 요금이 붙는지는 공식 문서에서 따로 찾지 못했다.
CLI로 쓰는 순서는 이렇다.
- CLI를 설치한다. npm(
npm install -g @github/copilot, Node.js 22 이상), Homebrew(brew install --cask copilot-cli), WinGet(winget install GitHub.Copilot), 설치 스크립트 중 하나를 고르면 된다. Windows는 PowerShell 6 이상이 필요하다. - 대화형 세션에서
/computer on을 입력한다. 설정이 저장되고 내장 컴퓨터 유즈 플러그인이 켜진다. - macOS라면 안내에 따라 **손쉬운 사용(Accessibility)**과 화면 기록(Screen Recording) 권한을 준다. 앞의 것은 컨트롤을 조작하는 데, 뒤의 것은 창 내용을 보는 데 쓰인다.
/computer show로 플러그인·MCP 서버·스킬이 모두 켜졌는지 본다. 끌 때는/computer off다.
Copilot 앱에서는 Settings → Computer Use → Enable Computer Use를 켜거나, 앱 안에서 똑같이 /computer on을 쓴다.
npm 레지스트리를 직접 조회해 보니(2026-10-05, macOS 26.4.1·Node.js 22.16.0에서 npm view @github/copilot) 최신 버전은 1.0.91이었다. 공개 프리뷰 발표일인 10월 1일에 올라온 버전이다. 우리는 이 기능을 실제로 켜서 돌려 보지는 못했다. 위 절차와 동작 설명은 전부 GitHub 공식 문서 기준이다.
켰는데 반응이 없다면 문서의 문제 해결 순서를 따르면 된다. 계정에 기능이 열려 있는지와 지원 OS인지 먼저 보고, /plugin으로 플러그인 상태를, /mcp list로 MCP 연결을 확인한다. macOS에서는 헬퍼 프로그램에 두 권한이 실제로 들어갔는지가 흔한 걸림돌이다.
프롬프트는 결과·앱·금지 사항까지
문서가 권하는 요청 방식은 원하는 결과, 관련된 앱, 지켜야 할 제약을 함께 말하는 것이다. 문서 예시는 이렇다.
Open APP_NAME and summarize the status information shown in the main window.
Do not change any values or submit any forms.
두 번째 줄이 핵심이다. "값을 바꾸지 말고 폼을 제출하지 마라"를 명시해 읽기 전용 작업으로 묶어 둔다. 처음 써 본다면 이런 조회·요약형 요청부터 시작하는 게 무난하다.
한계도 문서에 꽤 솔직하게 적혀 있다. 앱 버전이나 OS가 바뀌어 화면 구성이 달라지면 헤맬 수 있고, 엉뚱한 컨트롤을 누르거나 글자를 다른 칸에 넣을 수 있다. 표준이 아닌 컨트롤이나 동적으로 바뀌는 화면, 길게 이어지는 다단계 작업, 타이밍에 민감한 동작에서도 실수가 나기 쉽다고 한다. 타이밍 문제는 같은 동작을 두 번 하거나 중간에 끊기는 식으로 드러난다. 멈추고 싶으면 CLI에서는 Esc를 두 번, 앱에서는 Stop 버튼이나 Esc를 누른다.
권한은 어디까지 맡길까
컴퓨터 유즈는 Copilot 화면의 기존 도구 권한 체계를 그대로 따른다. 앱을 조작하기 전에 승인을 묻고, 사용자는 이번 세션만 허용(Allow), 앞으로도 계속 허용(Always allow), 거부 중에 고른다. CLI에서 지금 권한 상태는 /permissions show로 볼 수 있다.
개인적으로 가장 신경 쓰이는 건 Always allow다. 이 선택은 그 컴퓨터에 로컬로 저장되고, 같은 컴퓨터의 CLI와 앱 양쪽에 함께 적용된다. 한 번 허용한 앱은 다시 묻지 않고 반복해서 조작할 수 있다는 뜻이다. 문서도 민감한 정보가 있거나 영향이 큰 동작이 가능한 앱에는 Always allow를 고르지 말라고 따로 경고한다. 저장된 허용 목록은 Copilot 앱에서 검토하고 취소할 수 있는데, 이미 돌고 있는 세션에는 바로 반영되지 않는다.
놓치기 쉬운 설정이 하나 더 있다. Copilot CLI 공개 저장소의 변경 기록을 보면 1.0.64(6월 23일) 항목에 "전체 allow-all 세션에서는 컴퓨터 유즈 동의 프롬프트를 건너뛴다"는 줄이 있다. --yolo나 /allow-all로 모든 도구를 자동 승인해 둔 채 컴퓨터 유즈를 켜면, 앱 조작 전에 묻는 단계도 같이 사라진다는 얘기다. 셸 명령 자동 승인에 익숙한 사람이라면 이 조합만큼은 피하는 게 맞다.
프롬프트 인젝션도 문서가 명시한 위험이다. 화면에 뜬 예상 밖의 내용이 Copilot의 행동을 바꿀 수 있다는 것이다. 코드 저장소 안의 악성 주석만 조심하면 되던 때와 달리, 이제는 화면에 보이는 모든 글자가 입력이 된다. 메일 클라이언트, 메신저, 브라우저 알림처럼 남이 내용을 써 넣을 수 있는 앱이 특히 그렇다. 같은 이유로 창에 보이는 정보는 전부 Copilot의 맥락으로 넘어간다고 봐야 한다. 실무에 붙인다면 이렇게 정리할 수 있다.
- 작업에 필요한 앱만 열어 두고, 비밀번호 관리자나 금융·사내 관리 화면은 닫는다.
- Always allow는 조회만 하는 앱에 한정하고, 입력·제출이 일어나는 앱은 매번 승인한다.
- allow-all 모드와 컴퓨터 유즈를 동시에 켜지 않는다.
- 요청에 "제출하지 말 것", "저장 전 멈출 것" 같은 금지 조건을 넣는다.
문서의 표현대로 컴퓨터 유즈는 사람의 판단을 대신하지 않는다.
Copilot CLI 보안 이력
컴퓨터 유즈 기능 자체의 보안 사고 보고는 찾지 못했다. 다만 이 기능이 얹히는 Copilot CLI에는 올해 GitHub 보안 권고(Advisory Database)에 오른 취약점이 두 건 있었다.
- CVE-2026-29783(3월 6일 공개, CVSS 7.5) — 배시 매개변수 확장 문법을 악용하면 겉보기엔 무해한
echo명령 안에 다른 명령을 숨겨 실행할 수 있었다. '읽기 전용' 명령 판정을 우회하는 문제로, 프롬프트 인젝션이나 악성 MCP 서버를 통해 터질 수 있었다. 0.0.422 이하가 영향을 받았고 0.0.423에서 고쳐졌다. - CVE-2026-45033(5월 6일 공개, CVSS 8.5) — 프로젝트 안에 숨겨 둔 bare Git 저장소의
core.fsmonitor같은 설정을 통해, CLI가 Git 명령을 돌릴 때 임의 코드가 실행될 수 있었다. 1.0.42 이하가 대상이었고 1.0.43에서 수정됐다.
두 건 모두 10월 5일 조회 때 최신이던 1.0.91보다 한참 앞선 버전에서 고쳐졌다. 컴퓨터 유즈를 쓰려면 어차피 최근 버전이 필요하니 직접 영향은 없다. 그래도 공통점은 눈여겨볼 만하다. 둘 다 에이전트가 '믿고 읽은' 외부 입력에서 시작했다. 화면을 읽는 기능이 생긴 지금은 그 외부 입력의 범위가 저장소 밖 데스크톱 전체로 넓어진 셈이다.
이 글의 일부는 GitHub Docs(CC BY 4.0) 내용을 번역·요약했습니다.