Copilot이 데스크톱 앱을 누른다면, API 없는 업무도 새로 개발하지 않아도 될까요?

핵심 요약 (TL;DR)

GitHub가 10월 1일 현지 시각에 Copilot의 computer use 공개 프리뷰를 발표했습니다. macOS와 Windows의 Copilot CLI·앱에서 데스크톱 화면을 읽고, 클릭하고, 글을 입력하는 기능입니다. API나 MCP 연결이 없는 오래된 업무 프로그램도 자동화의 대상이 될 수 있습니다. 다만 ‘새 앱을 만들 필요가 없어졌다’는 결론은 이릅니다. 화면을 움직이는 기능과 안정적인 업무 연결은 다르기 때문입니다. 이번 글은 공식 문서에 근거한 안내이며, 특정 업무 프로그램에서 실행한 후기는 아닙니다.

새 업무 앱을 만들기 전에 무엇을 살펴볼까요?

코딩을 몰라도 앱을 만들 수 있다는 말은 매력적입니다. 그러나 이미 사용하는 프로그램에서 정보를 옮기는 일이 문제라면, 그 프로그램을 통째로 다시 만들 필요는 없을 수 있습니다. Copilot의 새 기능은 운영체제의 접근성 정보나 필요한 경우 스크린샷을 읽어 기존 화면을 조작하는 접근입니다.

그렇다고 화면 클릭을 첫 선택으로 삼을 이유도 없습니다. GitHub 문서는 API, MCP, 터미널, 파일 도구나 전용 브라우저 도구로 직접 처리할 수 있다면 그쪽이 대체로 더 구조화된 정보와 예측 가능한 결과를 제공한다고 설명합니다. 먼저 기존 프로그램에 내보내기나 공식 연결 기능이 있는지 확인하고, 없을 때 화면 조작을 검토하는 순서가 합리적입니다.

첫 요청은 어느 정도로 좁혀야 할까요?

처음부터 “매달 정산을 끝내 주세요”라고 맡기기보다, 한 화면에서 확인할 결과를 정해 보세요. “이 샘플 문서의 항목을 읽어 별도 초안으로 정리해 주세요. 원본 수정과 외부 전송은 하지 말고, 읽지 못한 항목은 표시해 주세요”처럼 대상 앱·결과·금지 행동을 함께 적는 방식입니다.

이는 공식 데모를 재현했다는 설명이 아니라, 첫 실험을 위한 제안입니다. 화면의 위치나 문구가 바뀌면 잘못된 곳을 누르거나 입력할 수 있으므로, 테스트 자료로 시작해 결과를 원문과 나란히 확인하는 편이 좋습니다. 잘못 읽힌 항목이 있다면 요청을 더 길게 만드는 것보다 화면 상태와 대상 범위를 먼저 단순하게 줄여 보세요.

‘항상 허용’을 지우면 지금 작업도 멈출까요?

공식 문서에서 특히 눈여겨볼 부분입니다. 앱에 대한 ‘Always allow’ 결정은 로컬에 저장되며, 같은 컴퓨터의 Copilot CLI와 앱에 함께 적용됩니다. 저장된 승인을 삭제하면 앞으로의 세션에 적용되지만, 실행 중인 세션에 이미 부여한 접근까지 취소되지는 않습니다.

따라서 잘못 움직이는 작업은 활성 작업부터 중단해야 합니다. 중요한 자료를 다루는 앱에는 처음부터 상시 허용을 신중하게 선택하세요. macOS의 접근성·화면 기록 권한도 별도로 필요하며, 회사의 관리 정책이 기능을 막고 있다면 로컬에서 켜는 것만으로 그 정책을 넘을 수 없습니다.

FAQ: 화면을 읽기만 해도 주의할 것이 있나요?

있습니다. 창에 보이는 고객 정보나 개인 메모도 AI의 작업 맥락이 될 수 있습니다. 읽기 전용 요청이라도 대상 자료를 샘플로 바꾸고, 불필요한 민감정보가 화면에 남지 않도록 확인하세요.

FAQ: 이 기능으로 앱 검증까지 끝낼 수 있나요?

화면 동작을 확인하는 데 도움은 될 수 있지만, 저장 데이터·접근 권한·실제 전송 결과까지 자동으로 증명하지는 않습니다. 클릭이 끝났다는 보고와 업무가 정확하게 끝났다는 확인을 나눠 두는 것이 좋습니다.

출처: https://github.blog/changelog/2026-10-01-github-copilot-can-now-interact-with-desktop-apps/
공식 문서: https://docs.github.com/copilot/concepts/agents/computer-use
관찰 시점: 2026-10-03 KST