화면을 직접 누르는 코파일럿, 깃허브는 왜 '다른 방법부터 쓰라'고 말했을까

사람이 쓰던 화면을 그대로 클릭하는 코파일럿의 등장과 깃허브의 기묘한 경고

인공지능이 코드를 대신 짜주는 단계를 넘어, 모니터 화면을 보면서 직접 마우스를 움직이고 키보드를 두드리는 시대가 열렸다. 깃허브가 코파일럿 명령줄 도구(CLI)와 리서치팀톱 앱에 ‘컴퓨터 유즈(Computer Use)’ 기능을 시험판으로 공개했다. 이 기능은 사람이 모니터 앞에서 일하는 방식 그대로 작동한다. 화면에 뜬 창을 훑어보고, 버튼을 찾아 누르고, 글자를 입력하고, 스크롤을 내리거나 창을 끌어다 놓는다. 데이터 통로(API)나 별도의 명령어 인터페이스가 전혀 없는 10년 넘은 낡은 사내 프로그램도 인공지능이 손쉽게 다룰 수 있게 된 셈이다.

깃허브가 선보인 시연에서는 코파일럿이 사파리 브라우저를 열어 지출 결재 보고서를 직접 작성하는 모습이 공개됐다. 오래된 구형 프로그램에 적힌 정보를 요약하거나, 발표 자료 슬라이드를 수정하고, 이 프로그램에서 저 프로그램으로 데이터를 복사해 옮겨 적는 일까지 가능하다. 앤트로픽의 클로드와 오픈AI의 코덱스가 먼저 선보였던 컴퓨터 제어 시장에 깃허브도 본격적으로 참전한 것이다.

그러나 이번 발표에서 가장 눈길을 끈 대목은 신기능의 위력이 아니라 깃허브가 함께 내놓은 공식 안내문이었다. 깃허브는 새 기능을 소개하자마자 이용자들에게 “가능하면 이 기능을 쓰지 말고 다른 도구부터 먼저 써라”고 권고했다. 연결 통로(API)나 전용 연동 서버(MCP), 터미널 명령어, 파일 시스템 제어기처럼 컴퓨터와 곧바로 대화할 수 있는 직접 통로가 있다면 화면 제어는 최후의 수단으로 남겨두라는 뜻이다.

인간이 쓰던 화면을 인공지능이 그대로 쓰면 전용 연결 다리를 일일이 만들 필요가 없다고 주장하는 오픈AI와 달리, 깃허브는 화면을 보면서 마우스를 클릭하는 방식이 가진 치명적인 불안정성을 정면으로 짚었다. 화면 그래픽을 눈으로 읽고 손으로 누르는 작업은 예측하기 어렵고 돌발 변수에 취약하기 때문이다.

분당 성공률 80% vs 99.9%: 화면 직접 조작과 전용 규격의 정밀 비교

화면 제어 기능은 겉보기에 마법처럼 편리해 보이지만, 실제 업무 현장에 올려놓고 숫자를 따져보면 비용과 안정성에서 큰 차이가 난다. 코파일럿이 마우스로 화면을 제어하려면 운영체제의 접근성 트리(Accessibility Tree)를 읽고, 화면 변화를 파악하기 위해 실시간으로 고화질 스크린샷을 찍어 언어 모델에 전달해야 한다.

글자 몇 줄만 주고받으면 끝나는 일반 데이터 통로와 달리, 한 번 클릭할 때마다 방대한 시각 정보가 오가면서 시간과 요금이 눈덩이처럼 불어난다.

실제로 기업 전산망에서 지출 결의서 100건을 입력한다고 가정해 보자. 정형화된 데이터 통로를 거치면 30초 안에 단 한 번의 오류도 없이 끝난다. 반면 마우스 제어 방식을 쓰면 창이 뜨는 시간차나 예기치 않은 팝업 광고, 브라우저 스크롤 위치에 따라 15–20건에서 마우스가 빗나가거나 엉뚱한 입력창을 누르는 현상이 벌어진다. 깃허브가 직접 연결 통로를 고집하라고 강조한 이유는 바로 이 불안정한 실패율 때문이다.

마우스가 빗나갈 때 생기는 일: 기업 현장과 업무 파이프라인에 미치는 3대 위험

컴퓨터 유즈 기능이 개발자 개인의 실험실을 벗어나 기업 현장에 들어설 때, 관리자와 실무진은 세 가지 구체적인 위험 장벽에 부딪히게 된다.

작업 반복과 멈춤 현상이 일으키는 운영 시간 손실

화면 제어 인공지능은 시간 감각이 사람과 다르다. 웹페이지나 소프트웨어가 로딩되는 데 0.5초가 더 걸리면, 에이전트는 버튼이 아직 나타나지 않았다고 판단해 당황하거나 이전 행동을 헛돌며 반복한다.

깃허브 역시 타이밍이 어긋나거나 프로그램 창의 크기나 순서가 조금만 바뀌어도 코파일럿이 같은 동작을 도돌이표처럼 되풀이하거나 아예 멈춰 설 수 있다고 경고했다. 사람이 곁에서 계속 지켜보지 않으면, 10분이면 끝날 작업이 밤새 멈춤 상태로 방치되어 다음 날 전체 업무 일정이 줄줄이 밀리는 사태가 일어난다.

화면 캡처 과정에서 발생하는 민감 데이터 유출 위험

코파일럿 리서치팀톱 앱이 화면을 인식하려면 맥OS 기준으로 ‘화면 기록(Screen Recording)‘과 ‘손쉬운 사용(Accessibility)’ 권한을 반드시 넘겨받아야 한다. 이는 인공지능이 화면 전체를 들여다볼 수 있는 눈을 갖는다는 뜻이다.

문제는 직원이 브라우저 창에서 작업을 지시하는 동안, 옆에 띄워둔 메신저 창에 고객의 개인정보나 비밀 유지 문서, 내부 회계 숫자가 떠 있을 때 발생한다. 코파일럿은 맥락을 파악하기 위해 화면 전체를 캡처하므로, 개발자가 의도하지 않았던 민감한 사내 기밀 정보까지 고스란히 인공지능 분석 서버로 흘러 들어가게 된다.

비상 정지와 중앙 통제 정책의 현장 괴리

코파일럿이 잘못된 입력창에 엉뚱한 숫자를 쳐 넣거나 삭제 버튼 쪽으로 마우스를 가져갈 때, 사용자가 이를 급히 멈추려면 CLI에서는 ‘Esc 키를 두 번’ 누르거나 리서치팀톱 창에서 ‘Stop’ 버튼을 클릭해야 한다.

하지만 마우스 조작 속도가 빨라지면 사람이 화면을 인지하고 물리적으로 키보드를 누르기 전에 이미 돌이킬 수 없는 데이터 덮어쓰기나 삭제가 일어날 수 있다. 다행히 깃허브는 관리자 설정 파일(managed-settings.json)을 통해 전사 차원에서 이 기능을 강제로 끄거나, 매 작업마다 직원이 일일이 승인 버튼을 누르도록 강제할 수 있는 안전장치를 마련해 두었다. 그러나 승인 창이 뜰 때마다 직원이 무심코 ‘항상 허용’을 눌러버리면 중앙 통제망은 순식간에 무력화된다.

낡은 프로그램의 늪에서 벗어나는 법: 화면 클릭 대신 선택할 수 있는 3가지 완충재

깃허브가 조언한 대로 화면 클릭이라는 극단적인 우회로를 타기 전에, 기업이 시스템 안정성을 지키면서 자동화를 달성할 수 있는 완충 대안은 분명히 존재한다.

화면 대신 전용 통로를 뚫어주는 경량 MCP 서버 구축

모든 기능을 다 갖춘 거대한 통신 규격을 새로 개발할 필요는 없다. 오픈소스 모델 컨텍스트 프로토콜(MCP)을 활용하면, 특정 낡은 데이터베이스나 사내 파일 저장소에서 데이터만 쏙 뽑아오는 작은 연결 프로그램을 반나절 만에 만들 수 있다. 화면을 띄워 마우스로 긁어오는 대신, 파이썬이나 노드 스크립트로 작성된 가벼운 MCP 서버를 컴퓨터에 붙여두면 코파일럿이 화면을 보지 않고도 오차 없이 필요한 자료만 주고받는다.

터미널 스크립트와 로컬 파일 시스템 직접 제어

대다수 업무 자동화의 본질은 결국 ‘텍스트를 읽어서 다른 파일로 옮기는 일’이다. 굳이 그래픽 화면을 띄워 복사 붙여넣기를 반복할 필요가 없다. 깃허브 코파일럿 CLI 본연의 기능인 터미널 명령어와 로컬 파일 편집 도구를 활용하면 훨씬 빠르고 안전하다. 파워셸이나 배시 스크립트로 사내 파일 폴더를 직접 제어하게 만들면, 마우스가 빗나갈 염려 자체가 원천 차단된다.

브라우저 전용 헤드리스 자동화 도구 병행

만약 웹 브라우저 안에서 일어나는 반복 작업이라면, 모니터에 화면을 직접 띄우지 않고 백그라운드에서 코드 형태로 웹 문서를 조작하는 헤드리스(Headless) 방식을 택해야 한다. 플레이라이트(Playwright)나 퍼피티어(Puppeteer) 같은 검증된 웹 조작 도구를 코파일럿과 연동하면, 화면 해상도나 창 겹침에 방해받지 않고 버튼의 고유 코드 이름을 찾아 정확하게 누를 수 있다.

우리 회사 PC에 마우스 권한을 넘겨도 될까: 도입 적합 기업과 보류 기업 판정

깃허브 코파일럿의 컴퓨터 유즈 기능은 분명 기술적으로 놀라운 진전이지만, 모든 기업이 당장 켜고 써야 할 만능 도구는 아니다. 각 기업의 전산 환경과 취급 데이터의 성격에 따라 도입 여부를 냉정하게 가려내야 한다.

지금 즉시 도입해 볼 만한 기업 (Fit 조건 3가지)

• API 개방이 불가능한 폐쇄형 레거시 프로그램을 매일 쓰는 기업: 소스코드가 유실되었거나 개발사가 사라져 데이터 통로를 도저히 뚫을 수 없는 오래된 사내 전산망을 쓰는 경우다. 직원이 하루 3–4시간씩 모니터를 보며 수기 입력하던 단순 전기 작업을 화면 제어 에이전트에게 맡기면 업무 피로도를 크게 줄일 수 있다.
• 실수를 즉시 되돌릴 수 있는 읽기·요약 위주의 작업을 하는 팀: 여러 응용프로그램 창을 번갈아 띄워놓고 숫자를 비교해 엑셀 표 하나로 취합하거나, 발표 슬라이드의 문구를 다듬는 등 원본 데이터 파괴 위험이 없는 부서라면 지금 당장 시험판을 켜서 생산성을 높일 수 있다.
• 전사 중앙 통제 정책(managed-settings.json)이 정비된 조직: 개발자 개개인이 무분별하게 권한을 열어두지 못하도록, 중앙 전산 부서에서 허용 프로그램 목록을 통제하고 승인 절차를 강제할 수 있는 체계가 갖춰진 기업이라면 안전하게 시범 운영을 통제할 수 있다.

도입을 보류하고 지켜봐야 할 기업 (Non-Fit 리스크 3가지)

• 화면에 환자 정보, 금융 계좌, 고객 개인정보가 상시 노출되는 기업: 병원 전산망, 금융 창구, 법률 사무소처럼 모니터 화면 한구석에 주민등록번호나 민감 계약서가 떠 있을 가능성이 높은 환경에서는 도입을 전면 보류해야 한다. 화면 녹화 기반의 에이전트는 사용자가 가리고 싶어 하는 민감 영역까지 전부 눈으로 읽어 들이기 때문이다.
• 단 한 번의 입력 오류도 치명적인 손실로 이어지는 부서: 회계 전표 발행, 서버 인프라 설정 변경, 대외 결제 송금 등 마우스 클릭 실수 한 번이 막대한 금전적·법적 피해로 이어지는 핵심 업무에는 화면 제어 방식을 투입해서는 안 된다. 깃허브 경고대로 이 영역은 규격화된 직접 API 통로만 써야 한다.
• 충분한 모니터링 인력이 없는 무인 자동화를 꿈꾸는 팀: 밤새 컴퓨터를 켜두고 인공지능 혼자 마우스를 움직여 아침까지 일을 끝내두기를 기대한다면 실망할 확률이 높다. 로딩 지연이나 알 수 없는 시스템 알림창 하나로 새벽 1시에 멈춰 설 가능성이 매우 높으며, 이를 실시간으로 지켜보고 풀어줄 사람이 없다면 도입하지 않는 편이 낫다.