요약: Gemini API의 Computer Use는 모델이 스크린샷을 보고 클릭, 입력, 스크롤 같은 UI 액션을 제안하게 만드는 기능입니다. 문서상 gemini-3-flash-preview와 컴퓨터 사용 전용 모델에서 지원되며, 개발자는 액션을 실제로 실행하는 클라이언트 코드를 직접 작성해야 합니다. 따라서 핵심은 “모델이 브라우저를 조작한다”가 아니라 “안전한 agent loop를 어떻게 설계하느냐”입니다.
Google 문서에 따르면 Computer Use는 브라우저 제어 에이전트를 만들기 위한 기능입니다. 모델은 화면 스크린샷을 보고 필요한 UI 액션을 function call 형태로 제안합니다. 예를 들어 버튼 클릭, 텍스트 입력, 스크롤, 키보드 입력 같은 행동입니다. 개발자는 이 응답을 받아 Playwright 같은 자동화 도구로 실제 브라우저에 적용하고, 새 스크린샷과 결과를 다시 모델에 전달합니다.
이 구조는 일반 function calling과 비슷하지만 차이가 큽니다. 일반 function calling은 보통 API나 내부 함수를 호출합니다. Computer Use는 실제 UI 상태를 바꿉니다. DOM이 바뀌고, 폼이 제출되고, 외부 사이트에서 버튼이 눌릴 수 있습니다. 그래서 구현 난이도는 모델 호출보다 실행 환경 제어에 있습니다.
최소 루프는 네 단계입니다. 첫째, 사용자 목표와 현재 화면 스크린샷을 모델에 보냅니다. 둘째, 모델이 제안한 UI action을 받습니다. 셋째, 클라이언트가 액션을 실행하고 결과를 기록합니다. 넷째, 변경된 화면을 다시 캡처해 다음 요청에 넣습니다. 목표가 끝났거나 제한에 걸리면 루프를 종료합니다.
운영에서는 루프 제한을 반드시 둬야 합니다. 예를 들어 최대 15 step, 최대 2분, 동일 액션 3회 반복 시 중단, 같은 URL에서 5회 이상 실패 시 중단 같은 규칙입니다. 브라우저 자동화는 실패가 조용히 반복되기 쉽습니다. 버튼을 눌렀지만 로딩이 끝나지 않았거나, 팝업이 떠서 클릭이 먹히지 않거나, 쿠키 배너가 화면을 가리는 경우가 많습니다. 제한이 없으면 비용과 시간이 계속 늘어납니다.
Computer Use를 제품에 붙일 때 가장 위험한 설계는 “모든 사이트에서 모든 클릭 허용”입니다. 실제 서비스에서는 allowlist와 denylist가 필요합니다. 읽기 전용 리서치, 내부 QA, 데이터 입력 보조처럼 낮은 위험 작업부터 시작해야 합니다. 결제, 계정 삭제, 개인정보 제출, 외부 메시지 발송, 약관 동의는 기본적으로 금지하거나 사용자 승인을 요구해야 합니다.
액션 단위 권한도 나눌 수 있습니다. 스크롤과 페이지 이동은 낮은 위험입니다. 텍스트 입력은 중간 위험입니다. 제출 버튼 클릭, 파일 업로드, 다운로드, 새 창 열기, 외부 도메인 이동은 높은 위험입니다. 모델 응답을 그대로 실행하지 말고 액션 필터를 거쳐야 합니다. 예를 들어 click action이 제출 버튼 근처라면 실행 전 사용자 확인을 요구합니다.
Computer Use가 가장 먼저 유용한 영역은 웹 애플리케이션 테스트입니다. 기존 E2E 테스트는 selector가 바뀌면 자주 깨집니다. Computer Use 기반 테스트는 화면을 보고 행동하기 때문에 “사용자 관점 플로우 점검”에 적합합니다. 단, 이것이 deterministic test를 대체한다는 뜻은 아닙니다.
추천 구조는 두 겹입니다. 핵심 결제, 로그인, 권한 같은 플로우는 Playwright selector 기반 테스트로 고정합니다. 그 위에 Computer Use를 붙여 “새 사용자가 대시보드에서 리포트를 만들 수 있는가”, “설정 화면에서 API 키 위치를 찾을 수 있는가” 같은 탐색형 테스트를 돌립니다. 실패하면 스크린샷, 액션 목록, 마지막 URL, 모델 판단 이유를 저장합니다.
Google 문서는 모델이 정규화된 좌표를 출력하며, 클라이언트가 이를 실제 픽셀 좌표로 변환해야 한다고 설명합니다. 이때 브라우저 viewport, device pixel ratio, 스크롤 위치를 정확히 다뤄야 합니다. 좌표 변환이 틀리면 모델은 맞게 봤는데 엉뚱한 위치를 클릭하는 일이 생깁니다.
또한 화면 캡처 시점도 중요합니다. 클릭 직후 바로 캡처하면 로딩 중 화면이 들어갈 수 있습니다. 네트워크 idle, 특정 element visible, timeout fallback을 조합하는 것이 좋습니다. 페이지가 완전히 안정될 때까지 기다리되 무한 대기는 막아야 합니다. 각 step마다 before screenshot, action, after screenshot, wait condition을 저장하면 디버깅이 쉬워집니다.
브라우저 에이전트 로그는 일반 API 로그보다 자세해야 합니다. 최소한 task id, step index, URL, screenshot hash, action type, normalized coordinate, converted coordinate, execution result, elapsed time, blocked reason을 남깁니다. 사용자 데이터가 포함된 스크린샷은 보관 정책을 따로 둬야 합니다. 민감한 화면은 마스킹하거나 저장하지 않는 편이 안전합니다.
프롬프트에는 “민감정보를 입력하지 말 것”, “결제나 삭제 버튼을 누르기 전에 중단할 것”, “목표와 관계없는 사이트로 이동하지 말 것” 같은 정책을 넣습니다. 하지만 프롬프트만으로는 부족합니다. 같은 정책을 코드 레벨 액션 필터에도 넣어야 합니다. 모델이 실수해도 실행기가 막아야 합니다.
출처: Google AI for Developers Computer Use 문서, Gemini API release notes.
