AI 에이전트가 데스크톱 앱을 직접 만질 때: computer use 도입 기준

결론부터: desktop computer use는 “먼저 켤 기능”이 아니라 “API가 막힌 업무의 마지막 실행 경로”다

2026년 10월 3일 기준으로 GitHub는 Copilot CLI와 macOS·Windows용 GitHub Copilot 앱에서 computer use 공개 프리뷰를 제공한다고 밝혔다. Copilot은 접근 가능한 앱 내용과 시각 정보를 읽고, 클릭·텍스트 입력·키 입력·스크롤·드래그처럼 데스크톱 앱을 직접 조작할 수 있다.GitHub 공식

이 글의 답은 단순하다. API, MCP 서버, 브라우저 자동화로 안정적으로 처리할 수 있는 일은 그쪽이 먼저다. Computer use는 레거시 데스크톱 앱, GUI 전용 승인 화면, 파일 업로드·편집처럼 기계가 화면을 실제로 봐야 하는 경우에만 좁게 켜는 편이 안전하다. 켜야 한다면 앱별 승인, OS 권한, 조직 관리 설정, 민감정보 차단, 실패 시 사람에게 멈추는 지점을 먼저 정해야 한다.

최근 seonoh.dev 글들은 브라우저 에이전트의 로그인 세션, 작은 decision model 라우팅, 프런티어 모델 경쟁을 다뤘다. 오늘의 새 기여는 모델 성능 소개가 아니라 에이전트 실행 경로 선택표다. “AI가 데스크톱을 만질 수 있다”는 사실보다 중요한 것은 어느 업무에 그 권한을 주지 말아야 하는지다.

무엇이 달라졌나: 에이전트가 웹페이지 밖의 앱까지 조작한다

GitHub의 10월 1일 changelog는 computer use가 Copilot CLI와 GitHub Copilot 앱에서 공개 프리뷰로 제공된다고 설명한다. 예시는 앱 내용과 시각적 컨텍스트 읽기, 컨트롤 클릭, 텍스트 입력과 편집, 키 입력, 스크롤, 드래그, 앱 사이 워크플로 이동이다.GitHub 공식

관측은 이렇다. 지금까지 에이전트 자동화의 안전한 순서는 대체로 “API → CLI → MCP → 브라우저”였다. 그런데 실제 회사 업무에는 API가 없거나, API가 있어도 마지막 승인·첨부·형식 확인이 데스크톱 앱 안에 묶인 경우가 많다. 경비 정산 앱, 오래된 ERP 클라이언트, 내부 보안 툴, 프레젠테이션 편집, 로컬 파일 기반 업무가 그렇다.

GitHub는 computer use가 API, 커맨드라인, MCP 통합을 제공하지 않는 레거시·GUI 전용 소프트웨어의 워크플로까지 자동화 범위를 넓힌다고 적었다.GitHub 공식 즉 핵심 변화는 “더 똑똑한 대답”이 아니라 에이전트의 손이 닿는 표면적이 넓어진 것이다.

API·MCP·브라우저·데스크톱 computer use 선택표

작은 팀이 바로 써먹을 기준은 다음 네 줄이다.

• API: 입력·출력 스키마가 있고 권한·로그가 남을 때 먼저 고른다. 실제 업무 규칙이 UI에만 숨어 있으면 보조 확인이 필요하다.
• MCP·도구: 파일·이슈·문서·DB처럼 도구 경계가 명확할 때 적합하다. 비공식 서버이거나 권한 범위가 과하면 제외한다.
• 브라우저 에이전트: 로그인된 웹 UI, 반복 확인, 공개 웹 수집이 핵심이면 우선 검토한다. 결제·관리자 삭제·고객정보 쓰기 작업은 사람 승인이 먼저다.
• Desktop computer use: API·MCP·브라우저로 안 되는 GUI 전용 앱을 다룰 때만 후보가 된다. 화면이 자주 바뀌거나 승인 없이 클릭하면 손해가 큰 일에는 맞지 않는다.

이 선택표의 핵심은 “가능한가”가 아니라 “재현 가능한가”다. API 호출은 같은 입력이면 같은 결과를 기대할 수 있다. MCP도 도구 호출 단위가 남는다. 브라우저 자동화는 DOM과 세션 상태를 다룰 수 있다. 반면 데스크톱 computer use는 창 위치, 포커스, OS 권한, 팝업, 알림, 화면 배율의 영향을 크게 받는다. 그래서 더 강력하지만 더 쉽게 흔들린다.

켜기 전에 정해야 할 네 가지: 승인, 앱 범위, 권한, 중단 조건

GitHub는 사용자가 여전히 통제권을 가진다고 설명한다. Copilot은 앱을 제어하기 전에 승인을 요청하고, 사용자가 항상 허용한 앱을 검토하거나 초기화할 수 있다. macOS에서는 Accessibility와 Screen Recording 권한 설정도 안내하며, 조직 관리 설정으로 기능을 비활성화할 수 있다고 밝혔다.GitHub 공식

따라서 도입 전 체크리스트는 기능 켜기보다 먼저다.

1. 앱 범위: 어떤 앱만 허용할지 정한다. “내 데스크톱 전체”가 아니라 “정산 앱과 브라우저 한 창”처럼 좁힌다.
2. 작업 범위: 읽기, 초안 작성, 입력 준비, 제출 전 멈춤을 구분한다. 처음부터 최종 제출을 자동화하지 않는다.
3. 민감정보: 고객정보, 결제수단, 비밀번호, 개인 메일, 관리자 콘솔은 별도 금지 목록으로 둔다.
4. 중단 조건: 알 수 없는 팝업, 다른 앱 포커스, 금액·수량·수신자 변경, 삭제 버튼, 외부 전송 버튼을 만나면 멈추게 한다.

데스크톱 computer use에서도 같은 원칙이 필요하다. 화면을 조작할 수 있다는 것은 링크 열기, 파일 첨부, 외부 전송까지 이어질 수 있다는 뜻이다. 그래서 링크·파일·전송이 등장하는 순간에는 “사용자 확인 없이 외부로 나가는 동작은 하지 않는다”는 운영 규칙을 별도로 둬야 한다.

가장 현실적인 쓰임새: API 없는 레거시 앱과 문서 편집

GitHub는 computer use를 켠 뒤 사용자가 원하는 결과, 관련 앱, 중요한 제약을 설명하는 방식이 좋다고 안내한다. 예시로 브라우저 알림 요약, 프레젠테이션 내용 업데이트, 데스크톱 앱의 워크플로를 통한 정보 이동을 들었다.GitHub 공식

작은 팀에서 먼저 시험할 만한 업무는 다음 정도다.

• 회의 메모를 열어 프레젠테이션 초안에 옮기고, 제출 전 멈추기
• 로컬 CSV를 데스크톱 정산 앱에 입력하되, 결재 버튼 앞에서 멈추기
• 오래된 사내 클라이언트에서 조회 화면을 열고 값만 복사하기
• 브라우저와 문서 앱 사이에서 형식이 깨진 표를 정리하기
• 반복되는 QA 체크리스트를 화면 기준으로 확인하고 누락 항목만 보고하기

반대로 자동 결제, 고객 대량 메일 발송, 관리자 권한 삭제, 인사·급여 변경, 법적 제출 같은 일은 첫 적용처가 아니다. 기술적으로 가능해도 실패 비용이 너무 크다.

왜 지금 봐야 하나: 에이전트가 “앱 안의 일”을 요구하기 시작했다

GitHub의 같은 날 VS Code changelog도 에이전트 흐름이 구현에서 PR 병합까지 길어지고 있음을 보여준다. 자동화는 반복 작업을 스케줄로 돌리고, agent merge는 리뷰 피드백·실패한 체크·머지 충돌·워크플로 재실행을 처리하며, 세션 관리는 여러 에이전트 작업을 정리한다.GitHub VS Code changelog

추론은 여기서 나온다. 코딩 에이전트 제품은 점점 “한 번 답하는 도구”에서 “여러 앱과 세션을 오가며 작업을 이어가는 실행자”로 이동하고 있다. 그러면 팀의 질문도 바뀐다. 어떤 모델이 가장 똑똑한가보다 어떤 실행 표면에 어떤 권한을 줄 것인가가 더 중요한 운영 문제가 된다.

실패 조건: 화면 자동화는 보이는 것보다 쉽게 어긋난다

Computer use의 위험은 “AI가 나쁜 의도를 가진다”보다 더 평범하다. 창이 겹친다. 팝업이 늦게 뜬다. 입력 포커스가 다른 칸에 있다. 화면 배율이 바뀐다. 같은 버튼이지만 오늘은 삭제 버튼 옆에 붙어 있다. 알림이 가린다. 사람은 눈치채고 멈추지만, 에이전트는 목표를 달성하려고 계속 다음 동작을 시도할 수 있다.

그래서 첫 설계는 자동화가 아니라 멈춤 설계여야 한다.

• 화면에 예상하지 못한 대화상자가 뜨면 멈춘다.
• 파일명, 금액, 수신자, 고객명, 권한 변경처럼 의미 있는 값은 사람에게 요약 후 확인받는다.
• “제출”, “삭제”, “전송”, “구매”, “초대”, “권한 부여” 버튼은 기본적으로 자동 클릭 금지다.
• 결과 확인은 화면 캡처만이 아니라 가능한 경우 파일·API·로그 read-back으로 다시 확인한다.
• 같은 작업을 반복할수록 전용 프로필, 테스트 계정, 샌드박스 데이터를 쓴다.

이 기준을 적용하면 desktop computer use는 무서운 기능이 아니라 좁은 범위의 실무 도구가 된다. 사람이 귀찮아서 미루는 GUI 반복 업무를 대신하되, 책임이 큰 순간에는 멈추는 도구다.

작은 팀 도입 순서

1. 읽기 전용 업무를 고른다. 예를 들어 알림 요약, 문서 비교, 화면 체크리스트 확인부터 시작한다.
2. 앱을 하나로 제한한다. 첫날부터 브라우저, 메일, 문서, 메신저를 모두 열지 않는다.
3. 전용 계정 또는 전용 프로필을 만든다. 권한이 낮은 환경에서 시작한다.
4. 제출 전 멈춤을 프롬프트와 운영 규칙에 넣는다. “마지막 버튼은 누르지 말고 요약해줘”가 기본이다.
5. 성공·실패 로그를 남긴다. 왜 멈췄는지, 어떤 화면에서 흔들렸는지 기록해야 다음 자동화가 안전해진다.
6. 반복 성공한 단계만 API·MCP로 승격한다. 화면 조작으로 검증한 업무라도 장기적으로는 더 안정적인 도구 경계로 옮기는 편이 좋다.

FAQ

Computer use가 있으면 API나 MCP는 덜 중요해지나?

아니다. 오히려 더 중요해진다. Desktop computer use는 화면을 보고 조작하는 강력한 우회로지만, 장기 운영에서는 API와 MCP처럼 입력·출력·권한이 명확한 경로가 더 안정적이다.

브라우저 에이전트와 무엇이 다른가?

브라우저 에이전트는 웹페이지, 세션, DOM, 네트워크 상태를 중심으로 움직인다. Desktop computer use는 브라우저 밖의 로컬 앱, 문서 편집기, 레거시 클라이언트, OS 창 조작까지 포함한다. 범위가 넓은 만큼 권한도 더 조심해야 한다.

개인 업무에도 쓸 만한가?

읽기, 정리, 초안 만들기, 반복 입력 준비에는 쓸 만하다. 다만 결제, 메일 발송, 계정 권한 변경, 민감 파일 업로드처럼 되돌리기 어려운 일은 사람 승인 지점을 둬야 한다.

macOS에서 특히 봐야 할 권한은?

GitHub는 macOS에서 Accessibility와 Screen Recording 권한 안내를 제공한다고 설명한다.GitHub 공식 이 권한은 화면 읽기와 앱 조작에 직접 연결되므로, 어떤 앱에 허용했는지 주기적으로 확인해야 한다.

첫 자동화 후보를 하나만 고른다면?

“읽고 요약한 뒤 제출 전 멈추는” 업무가 좋다. 예를 들어 정산 앱 화면에서 누락 항목을 확인하거나, 발표 자료 초안을 열어 수정 제안을 만든 뒤 저장 전 확인받는 방식이다. 첫 목표는 완전 자동화가 아니라 안전한 반복 패턴을 찾는 것이다.

출처 확인일

이 글의 공개 출처 확인일은 2026년 10월 3일 06:31 KST다. GitHub Copilot computer use와 GitHub Copilot in VS Code changelog를 중심으로 작성했다. 공개 프리뷰 기능은 지역, 계정, 플랜, 조직 관리 정책에 따라 달라질 수 있다.