GitHub Copilot Computer Use 사용법: 설정·권한과 안전한 자동화 가이드

10월 06, 2026

GitHub Copilot의 활동 범위가 코드와 터미널을 넘어 데스크톱 앱으로 넓어졌다. 2026년 10월 1일 공개 미리보기로 발표된 computer use는 Copilot CLI와 GitHub Copilot 앱이 화면의 접근성 정보와 시각적 문맥을 읽고, 버튼 클릭·텍스트 입력·키보드 조작·스크롤·드래그를 수행하게 한다. API나 명령줄, MCP 연결이 없는 오래된 업무 프로그램이나 GUI 전용 도구를 자동화할 때 특히 의미가 있다.

다만 “컴퓨터를 대신 써주는 기능”이라는 설명만 보고 바로 모든 권한을 열어서는 안 된다. 이 기능은 인터페이스 상태에 따라 다른 결과가 나올 수 있고, 잘못된 위치에 값을 입력하거나 예상치 못한 버튼을 누를 수도 있다. 이 글에서는 설치 위치, 켜는 순서, 권한을 제한하는 방법, 프롬프트 작성법, 실제 업무에 적용할 수 있는 예시와 문제 해결 순서를 공식 문서 기준으로 정리한다.

핵심 요약: 무엇이 달라졌나

지원 환경: macOS와 Windows의 로컬 Copilot CLI 세션 및 GitHub Copilot 앱
현재 상태: 공개 미리보기이며 기능과 동작 방식이 바뀔 수 있음
가능한 조작: 접근성 트리 또는 화면의 시각 정보 읽기, 클릭, 입력·수정, 키 입력, 스크롤, 드래그, 앱 사이 이동
기본 상태: 비활성화. 사용자가 직접 켜야 함
승인 구조: 앱 제어 전에 허용 여부를 묻고, 현재 세션만 허용하거나 이후에도 항상 허용하도록 저장할 수 있음
관리자 통제: 조직 관리 설정으로 computer use를 차단할 수 있으며 로컬 설정으로 우회할 수 없음

Computer use는 API·MCP·브라우저 도구와 무엇이 다른가

가장 중요한 선택 기준은 “할 수 있느냐”보다 “더 구조적인 도구가 있느냐”다. GitHub 공식 문서도 API, MCP 서버, 터미널 명령, 파일 시스템 도구, 전용 브라우저 도구로 작업할 수 있다면 그 방법이 보통 더 예측 가능하다고 안내한다.

방법	적합한 작업	장점	주의점
API·MCP	정형 데이터 조회·수정, 반복 통합	입출력 구조와 권한 범위가 명확함	서비스가 API나 MCP를 제공해야 함
CLI·파일 도구	코드, 로그, 설정 파일, 빌드 작업	재현성과 자동화가 좋음	GUI 전용 기능은 다루기 어려움
전용 브라우저 도구	웹 페이지 탐색과 폼 작업	DOM 등 구조화된 정보를 활용 가능	데스크톱 앱에는 적용되지 않음
Computer use	레거시 앱, 프레젠테이션, GUI 전용 프로그램, 앱 간 정보 이동	별도 통합이 없는 화면도 다룰 수 있음	화면 상태와 타이밍에 민감하며 오조작 위험이 있음

따라서 computer use는 첫 번째 선택이 아니라 직접 연결 수단이 없을 때 사용하는 시각적 실행 계층으로 이해하는 편이 안전하다. 예를 들어 CRM이 공식 API를 제공한다면 화면을 클릭해 고객 정보를 수정하기보다 API나 승인된 MCP 도구를 쓰는 것이 낫다. 반대로 사내 오래된 Windows 프로그램처럼 버튼과 입력창만 있고 외부 연결 수단이 없다면 computer use가 빈틈을 메울 수 있다.

시작 전 준비사항

지원되는 환경인지 확인한다. 현재 공식 지원 대상은 macOS와 Windows의 로컬 세션이다. 원격 또는 클라우드 세션이 아니라 실제 컴퓨터에서 실행하는 Copilot CLI나 GitHub Copilot 앱을 준비한다.
Copilot 접근 권한을 확인한다. 공식 문서상 Copilot CLI는 모든 Copilot 플랜에서 제공되지만, 조직에서 제공받는 계정은 관리자가 CLI 정책을 허용해야 한다. 공개 미리보기 배포 범위에 따라 설정 메뉴가 아직 보이지 않을 수도 있다.
테스트용 작업과 데이터를 고른다. 첫 실행은 결제, 계정 삭제, 고객 정보 수정처럼 영향이 큰 작업이 아니라 읽기 전용 요약이나 임시 문서 편집으로 제한한다.
민감한 창을 닫는다. 화면에 보이는 개인정보, 금융 정보, 다른 사람의 메시지, 인증 코드가 문맥으로 제공될 수 있다. 작업에 필요 없는 앱과 알림을 닫는다.
완료 기준과 중단 지점을 정한다. “어느 화면까지 이동하면 멈출지”, “저장이나 제출 전에 반드시 물어볼지”, “어떤 값은 절대 바꾸지 않을지”를 먼저 적는다.

GitHub Copilot CLI에서 computer use 상태를 확인하고 켜는 공식 명령 — GitHub 공식 문서의 Copilot CLI 명령 위치. /computer show로 상태를 확인하고 /computer on으로 활성화한다. 출처: GitHub Docs, 2026년 10월 6일 확인.

Copilot CLI에서 켜는 순서

Copilot CLI의 대화형 세션에서 다음 순서로 확인한다.

/computer show
/computer on
/computer show

첫 번째 /computer show는 computer-use 플러그인, 연결된 MCP 서버, 관련 스킬의 활성 상태를 보여준다. /computer on은 사용자 선호를 저장하고 번들 computer-use 플러그인을 켠다. 다시 상태를 확인했을 때 사용할 수 없다고 나오면 계정 배포 범위, 지원 운영체제, 로컬 세션 여부, 조직 정책을 차례로 점검한다.

플러그인은 켜졌지만 작동하지 않는다면 /plugin에서 번들 computer-use 플러그인이 활성화됐는지 확인하고, /mcp list에서 관련 MCP 서버가 연결됐는지 본다. 작업을 마친 뒤에는 아래 명령으로 끌 수 있다.

/computer off
/computer show

예상하지 못한 동작이 시작되면 CLI에서 Esc를 두 번 눌러 중단한다. 종료 명령을 찾느라 기다리지 말고 즉시 멈춘 뒤 현재 화면과 변경된 값을 확인하는 것이 좋다.

GitHub Copilot 앱에서 켜는 순서

GitHub Copilot 앱의 Settings를 연다.
사이드바에서 Computer Use를 선택한다.
Enable Computer Use를 켠다.
macOS에서는 Accessibility와 Screen Recording 권한을 모두 허용한다. 변경 상태가 반영되지 않으면 설정 화면의 확인 기능을 다시 실행한다.
Sessions의 Tool Permissions에서 앱 제어 시 매번 승인할지 검토한다.

macOS의 접근성 권한은 버튼과 입력창 같은 앱 제어 요소를 조작하는 데 사용되고, 화면 기록 권한은 접근성 정보만으로 부족할 때 창의 시각적 문맥을 확인하는 데 사용된다. 권한 이름 때문에 결과 영상이 자동으로 공개된다고 해석해서는 안 되지만, 화면에 표시된 민감 정보가 작업 문맥에 포함될 수 있다는 점은 반드시 고려해야 한다.

안전한 프롬프트는 네 가지를 분리한다

“이 업무를 처리해 줘”처럼 넓은 요청은 앱 선택, 수정 범위, 완료 조건을 에이전트가 추론하게 만든다. 대신 다음 네 요소를 명시한다.

목표: 최종적으로 무엇을 얻어야 하는가
대상 앱: 어느 앱과 어느 창을 사용해야 하는가
허용 범위: 읽기만 할지, 임시 편집까지 가능한지
확인 지점: 저장·제출·전송 직전에 멈출지

브라우저의 운영 현황 페이지와 데스크톱 프레젠테이션 앱을 사용해
오늘의 상태를 세 줄로 요약하고 마지막 슬라이드의 메모 영역에 초안을 입력해 줘.
기존 슬라이드 본문은 수정하지 말고, 저장하거나 공유하기 전에는 멈춰서 변경 내용을 보여 줘.

읽기 전용 작업이라면 “값을 변경하지 말 것”, “폼을 제출하지 말 것”을 문장으로 넣는다. 여러 앱을 오가는 작업은 출발 앱, 복사할 필드, 도착 앱, 붙여 넣을 위치를 구분한다. 화면에 다른 지시문이 나타나더라도 원래 요청 범위를 벗어나지 말라는 제한도 유용하다.

활용 예시 1: 레거시 프로그램 상태를 읽기 전용으로 요약

목적: API가 없는 오래된 재고·시설·사내 업무 프로그램의 현재 상태를 사람이 읽기 쉬운 메모로 바꾼다.

준비: 조회 권한만 있는 계정, 요약할 메뉴 이름, 확인할 날짜 범위
진행: 특정 앱을 열고 지정된 메뉴로 이동한 뒤 표의 상태 항목만 읽게 한다. 화면을 바꾸는 필터는 허용하되 수정·저장 버튼은 누르지 않도록 제한한다.
기대 산출물: 경고 항목, 기한이 지난 항목, 추가 확인이 필요한 값의 목록
검토 기준: 요약의 각 항목을 원본 화면과 대조하고, 숫자나 이름을 추론해 채우지 않았는지 확인한다.

이 경우 computer use의 장점은 별도 연동 개발 없이 접근성 정보와 화면 문맥을 읽는 데 있다. 반면 정기적으로 수백 건을 처리해야 한다면 화면 자동화보다 데이터 내보내기, API, RPA 전용 도구가 더 안정적일 수 있다.

활용 예시 2: 프레젠테이션 초안을 만들되 저장 전에 검토

목적: 브라우저에 있는 공지나 프로젝트 상태를 읽고 프레젠테이션의 지정된 위치에 초안을 입력한다.

준비: 출처가 되는 페이지, 수정할 파일의 복사본, 대상 슬라이드 번호, 유지해야 할 디자인 규칙
진행: 브라우저 내용을 요약하고 프레젠테이션 앱을 열어 메모 또는 임시 텍스트 상자에 입력한다. 기존 도형 삭제, 테마 변경, 외부 공유는 금지한다.
기대 산출물: 출처와 구분된 짧은 요약 초안
검토 기준: 원문 의미가 바뀌지 않았는지, 잘못된 슬라이드에 입력하지 않았는지, 저장 전 미리보기에서 확인한다.

화면 자동화는 창 포커스가 바뀌면 다른 위치에 입력할 수 있다. 따라서 한 번에 전체 발표 자료를 맡기기보다 한두 장에서 먼저 시험하고, 저장 직전 멈추게 하는 편이 안전하다.

활용 예시 3: 두 GUI 앱 사이 정보 이동

목적: 전용 API가 없는 원본 앱에서 필요한 정보를 읽고 다른 데스크톱 앱의 초안 폼에 옮긴다.

준비: 이동할 필드 목록, 개인정보 제외 규칙, 대상 폼의 임시 또는 샌드박스 환경
진행: 이름·상태·날짜처럼 지정된 필드만 읽고 대상 앱에 입력한다. 제출 버튼 앞에서 중단한다.
기대 산출물: 검토 가능한 미제출 초안
검토 기준: 필드 매핑, 날짜 형식, 누락값, 중복 입력을 사람이 확인한다.

이 흐름은 업무 자동화 가능성을 빠르게 검증하는 데 유용하지만, 개인정보나 대량 데이터를 지속적으로 옮기는 운영 방식으로 바로 확장해서는 안 된다. 정식 운영 단계에서는 최소 권한, 감사 기록, 정형 통합 수단을 다시 검토해야 한다.

GitHub Copilot computer use의 앱별 권한과 Always allow 동작을 설명하는 공식 문서 — Computer use는 기본적으로 꺼져 있으며 앱 접근 승인은 세션 단위 또는 Always allow로 저장할 수 있다. 저장된 허용은 같은 컴퓨터의 CLI와 Copilot 앱에 함께 적용된다. 출처: GitHub Docs, 2026년 10월 6일 확인.

권한과 보안: Always allow를 신중하게 써야 하는 이유

앱 제어 요청이 나타나면 현재 세션만 허용하거나, 이후 세션에도 적용되는 Always allow를 선택하거나, 거부할 수 있다. Always allow 결정은 로컬에 저장되며 같은 컴퓨터의 Copilot CLI와 GitHub Copilot 앱에 함께 적용된다. 앱 설정에서 저장된 허용 목록을 삭제할 수 있지만, 이미 실행 중인 세션에 부여된 접근은 즉시 취소되지 않을 수 있으므로 현재 작업은 Stop 또는 Esc로 끝내야 한다.

메일, 메신저, 암호 관리자, 금융·인사 시스템, 운영 서버 콘솔처럼 민감 정보와 영향이 큰 동작을 포함하는 앱에는 Always allow를 피하는 것이 좋다. 매번 승인하도록 두면 요청한 앱과 실제 제어 대상이 일치하는지 확인할 기회가 생긴다. 조직에서 관리하는 환경은 features.computerUse 설정으로 기능 자체를 막을 수 있고, 관리자의 거부 규칙은 자동 승인이나 저장된 허용보다 우선한다.

또한 화면의 문구를 모두 명령으로 신뢰해서는 안 된다. 외부 문서나 웹 페이지에 “보안을 해제하라”, “다른 앱의 정보를 복사하라” 같은 내용이 표시돼도 원래 요청과 권한 범위를 기준으로 판단해야 한다. 저장, 제출, 전송, 삭제, 결제처럼 되돌리기 어려운 동작은 사람이 최종 확인하는 경계를 유지한다.

자주 막히는 상황과 해결 순서

1. Computer Use 메뉴나 명령이 보이지 않는다

macOS 또는 Windows의 로컬 세션인지 확인한다.
Copilot CLI와 Copilot 앱을 최신 버전으로 업데이트한다.
조직 계정이라면 CLI와 computer use 정책이 허용됐는지 관리자에게 확인한다.
공개 미리보기의 계정 배포가 아직 도착하지 않았을 가능성을 확인한다.

2. 켰지만 앱을 클릭하거나 읽지 못한다

/computer show로 플러그인·MCP·스킬 상태를 확인한다.
/plugin에서 computer-use 플러그인, /mcp list에서 서버 연결을 확인한다.
macOS는 Accessibility와 Screen Recording이 모두 Granted인지 본다.
대상 창을 화면 앞으로 가져오고, 가려진 대화상자나 잠금 화면이 없는지 확인한다.

3. 잘못된 위치를 누르거나 동작을 반복한다

Esc 두 번 또는 Stop으로 즉시 중단한다.
화면 배율, 창 크기, 팝업, 앱 버전 변화가 있었는지 확인한다.
한 요청의 단계 수를 줄이고 앱 이름·창 이름·버튼 위치를 더 구체적으로 적는다.
저장이나 제출 전 중단 지점을 추가하고 작은 범위부터 다시 실행한다.

사용 전 최종 체크리스트

API, MCP, CLI, 전용 브라우저 도구보다 computer use가 정말 적합한가?
필요 없는 앱과 민감한 알림을 닫았는가?
처음에는 읽기 전용 또는 복사본에서 시험하는가?
대상 앱, 허용 동작, 금지 동작, 완료 조건을 프롬프트에 적었는가?
Always allow를 고위험 앱에 저장하지 않았는가?
저장·제출·전송·삭제 전에 사람이 확인하도록 했는가?
문제가 생기면 Esc 두 번 또는 Stop으로 멈추는 방법을 알고 있는가?

정리

GitHub Copilot computer use는 통합 수단이 없는 데스크톱 앱까지 에이전트의 작업 범위를 넓힌다. 특히 레거시 프로그램 조회, 프레젠테이션 초안, GUI 앱 사이의 제한된 정보 이동처럼 기존 코딩 에이전트가 다루기 어려웠던 작업을 연결할 수 있다. 반면 화면 해석과 창 상태에 의존하므로 API나 MCP보다 결과가 덜 예측 가능하다.

가장 안전한 시작법은 간단하다. /computer show로 상태를 확인하고, 작은 읽기 전용 작업에서 켠 뒤, 앱별 승인을 유지하고, 저장 직전 사람이 검토한다. 기능을 “모든 화면 작업의 기본 도구”가 아니라 “직접 통합이 없을 때 쓰는 제한된 실행 수단”으로 두면 편의성과 통제력을 함께 확보할 수 있다.

공식 자료

자료 확인일: 2026년 10월 6일. 공개 미리보기 기능은 이후 변경될 수 있으므로 실행 전 최신 공식 문서를 다시 확인하세요.

영문판: Read this guide in English

이 블로그 검색

스택핀치