Gemini 컴퓨터 사용 공개, 브라우저 에이전트에 안전판 추가
Google이 Gemini 3.5 Flash에 화면 조작형 Computer Use 공개 프리뷰를 추가했습니다. 개발팀이 봐야 할 실행 루프와 안전 경계를 정리합니다.
- 무슨 일: Google이 2026년 6월 24일 Gemini API에
computer_use공개 프리뷰를 추가했습니다.- 대상 모델은
gemini-3.5-flash이고, 브라우저·모바일·데스크톱 화면 조작을 스크린샷 기반 루프로 처리합니다.
- 대상 모델은
- 의미: 모델이 클릭을 “제안”하고, 클라이언트가 Playwright 같은 실행기로 실제 행동을 수행하는 API 계약이 선명해졌습니다.
- 주의점: Google은 이 기능을 미리보기로 표시하며, 민감 데이터와 되돌리기 어려운 행동에는 감독과 샌드박스를 요구합니다.
Google이 Gemini API에 컴퓨터 사용(Computer Use) 도구 공개 프리뷰를 추가했습니다. 2026년 6월 24일 릴리스 노트는 gemini-3.5-flash에서 브라우저, 모바일, 데스크톱 환경을 대상으로 화면 조작 에이전트를 만들 수 있다고 설명합니다. 새로 들어간 요소는 간소화된 행동, 행동별 intent, 구성 가능한 안전 정책, 프롬프트 인젝션 감지입니다. 모델 성능 점수보다 더 직접적인 변화는 API의 책임 분리입니다. Gemini는 화면을 보고 다음 행동을 제안하지만, 실제 클릭과 입력은 개발자가 만든 실행 환경이 처리합니다.
이 발표는 Google A2UI나 MCP Apps처럼 에이전트 결과를 어떤 UI로 보여줄지 묻는 뉴스와 다릅니다. 이번 기능은 사람이 쓰던 화면을 에이전트가 어떻게 다룰지 묻습니다. Computer Use 문서는 스크린샷을 모델에 보내고, 모델이 function_call로 클릭·입력·스크롤·탐색 같은 행동을 반환한다고 설명합니다. 클라이언트는 그 행동을 수행한 뒤 새 스크린샷을 다시 보내며 반복 루프를 이어갑니다. 챗봇이 답을 말하는 구조가 아니라, 모델과 실행기가 같은 화면 상태를 주고받으며 한 단계씩 전진하는 구조입니다.

Google 문서의 최소 예시는 짧습니다. 개발자는 tools: [{ type: "computer_use", environment: "browser" }]를 붙이고 gemini-3.5-flash에 요청을 보냅니다. 그러면 모델은 예컨대 검색창을 누르기 위한 click 호출과 좌표, 그리고 왜 그 행동을 택했는지 설명하는 intent를 돌려줍니다. 여기서 중요한 점은 Gemini가 브라우저를 직접 점유하는 것이 아니라는 점입니다. 문서는 클라이언트가 Playwright 같은 도구로 좌표를 실제 화면 크기에 맞게 변환하고, 행동을 실행하고, 새 화면을 캡처해 function_result로 되돌려 보내야 한다고 적습니다.
| 단계 | Gemini API가 맡는 일 | 개발팀이 맡는 일 |
|---|---|---|
| 화면 입력 | 스크린샷과 사용자 목표를 해석합니다. | 민감 정보가 섞이지 않도록 실행 환경과 캡처 범위를 제한합니다. |
| 행동 제안 | click, type, scroll 같은 호출과 intent를 반환합니다. | 좌표 변환, 입력 실행, 실패 처리, 재시도를 구현합니다. |
| 안전 판단 | 행동을 허용, 확인 필요, 차단으로 분류할 수 있습니다. | 확인 UI, 감사 로그, 중단 조건, 사람 승인 기준을 정합니다. |
| 상태 갱신 | 새 스크린샷을 보고 다음 행동을 산출합니다. | 각 단계 뒤의 URL, 오류, 화면 이미지를 기록해 루프를 이어갑니다. |
이 구조는 브라우저 자동화 개발자에게 낯설지 않습니다. Playwright, Selenium, Browserbase, Stagehand를 써 본 팀이라면 "화면을 보고 클릭한다"는 말이 마법이 아니라는 것도 압니다. 다만 기존 자동화는 사람이 셀렉터, 조건, 예외 처리를 미리 써야 했습니다. Gemini의 컴퓨터 사용 도구는 그 일부를 모델 호출로 바꿉니다. 모델은 현재 스크린샷에서 버튼과 입력창의 위치를 추정하고, 다음 행동을 JSON 형태로 제안합니다. 사람이 만든 스크립트는 더 짧아질 수 있지만, 잘못 누른 버튼을 되돌리는 책임은 사라지지 않습니다.
Google이 이번 문서에서 intent를 강조한 이유도 여기에 있습니다. Gemini 3.5 Flash 응답은 좌표만 주지 않고 "목적지를 입력하기 위해 검색창을 클릭한다" 같은 행동 의도를 함께 반환합니다. 이 필드는 사용자에게 보여주는 승인 문구, 실행 로그, 실패 분석에 쓸 수 있습니다. 좌표만 남으면 감사 로그는 "450, 120 클릭"으로 끝납니다. intent가 있으면 "검색창 클릭"이라는 사람이 읽을 수 있는 단서가 붙습니다. 화면 조작형 에이전트를 업무 도구에 넣을 때 이 차이는 작지 않습니다.
안전 정책은 이번 발표의 더 큰 메시지입니다. 릴리스 노트는 구성 가능한 안전 정책과 고급 프롬프트 인젝션 감지를 새 기능으로 적었습니다. Computer Use 문서는 응답에 safety_decision이 포함될 수 있고, 내부 안전 시스템이 행동을 일반 허용, 사용자 확인 필요, 차단으로 나눌 수 있다고 설명합니다. 즉, 개발자는 모든 모델 출력을 즉시 실행하는 구조로 만들 필요가 없습니다. 결제, 계정 삭제, 권한 변경, 데이터 내보내기처럼 되돌리기 어려운 행동은 확인 단계를 끼워 넣어야 합니다.
사용자 목표와 현재 스크린샷
Gemini 3.5 Flash의 행동 호출과 intent
안전 판단: 허용, 확인 필요, 차단
클라이언트 실행, 새 스크린샷, 다음 단계
프롬프트 인젝션 감지는 특히 브라우저 에이전트에서 중요합니다. 화면 안에는 사용자가 쓴 명령뿐 아니라 웹사이트가 숨겨 둔 지시, 악성 텍스트, 광고, 댓글, 문서 내용도 함께 들어옵니다. 모델이 화면을 "읽는다"는 것은 그 모든 텍스트를 입력으로 받는다는 뜻입니다. Google 문서는 enable_prompt_injection_detection: true 설정 예시를 보여주며, 숨은 적대적 지시를 탐지하기 위한 스크린샷 스캔으로 설명합니다. 이 기능이 모든 공격을 막는다는 뜻은 아닙니다. 하지만 플랫폼이 프롬프트 인젝션을 브라우저 에이전트의 기본 위험으로 인정했다는 점은 제품 설계의 기준선을 바꿉니다.
환경 지원 범위도 넓습니다. 브라우저 환경은 클릭, 입력, 스크롤, 뒤로 가기, 앞으로 가기, URL 탐색, 스크린샷 같은 행동을 제공합니다. 모바일 환경은 Android에 맞춰 앱 열기, 앱 목록 조회, 길게 누르기, 드래그 앤드 드롭, 키 입력을 포함합니다. 릴리스 노트는 데스크톱 환경도 언급합니다. 개발자 입장에서는 "웹 자동화 API" 하나가 아니라 화면을 가진 여러 환경의 행동 어휘가 API로 표준화되는 과정으로 읽어야 합니다. 같은 모델이 브라우저 탭, 모바일 앱, 데스크톱 앱을 넘나들 수 있다면 권한 모델도 환경별로 달라져야 합니다.
Google은 google-gemini/computer-use-preview 참조 구현도 공개했습니다. 저장소 README는 로컬 Playwright와 Browserbase 환경을 지원하고, 기본 모델을 gemini-3.5-flash로 둡니다. main.py --query ... --env playwright 같은 실행 경로, Browserbase API 키, Vertex AI 설정, 이전 gemini-2.5-computer-use-preview-10-2025 선택지가 함께 문서화되어 있습니다. 이것은 SDK 예제 이상의 의미가 있습니다. Google은 모델 호출만 제공하고 나머지는 알아서 하라는 식으로 끝내지 않고, 브라우저 실행기와 샌드박스 시작점을 같이 제시했습니다.
그래도 개발팀의 작업량은 작지 않습니다. 문서는 "보안 실행 환경"을 준비하라고 명시합니다. 에이전트를 호스트 시스템과 격리된 가상 머신이나 컨테이너에서 실행해 잠재적 영향을 줄이라는 권고입니다. 이 요구는 기능 소개에서 자주 지나치기 쉽지만, 실제 배포에서는 가장 먼저 결정해야 할 항목입니다. 에이전트가 사내 콘솔, 결제 관리자, 고객 데이터 화면을 볼 수 있다면 스크린샷 한 장도 민감 데이터가 됩니다. 실행 환경 격리, 네트워크 제한, 세션 수명, 로그 보관, 화면 마스킹은 모델 선택보다 먼저 설계되어야 합니다.
커뮤니티 반응은 아직 큰 단독 논쟁으로 번지지는 않았습니다. 이번 실행에서 Hacker News 첫 화면을 확인했을 때 상단에는 GLM 5.2 보안 벤치마크, Codex 민감 파일 제외 이슈, Claude Code 사용 경험 같은 AI 개발 도구 논의가 더 크게 보였습니다. GeekNews 첫 화면에서도 Gemini 컴퓨터 사용 릴리스 단독 반응은 확인하지 못했습니다. 그래서 지금 이 주제는 "모두가 떠드는 새 모델"보다 "문서를 먼저 읽은 팀이 운영 경계를 잡아야 하는 프리뷰"에 가깝습니다.
기존 브라우저 에이전트와 비교하면 이번 발표의 위치가 보입니다. Browserbase, Stagehand, Playwright 기반 에이전트는 이미 웹 자동화 시장에서 빠르게 퍼졌습니다. OpenAI와 Anthropic도 화면 조작형 에이전트를 제품에 넣고 있습니다. Google의 차별점은 Gemini API 안에서 모델, 행동 호출, 안전 정책, 프롬프트 인젝션 감지를 하나의 개발자 문서로 묶었다는 점입니다. 개발자는 별도 연구 데모가 아니라 Gemini API의 도구 하나로 이 기능을 붙일 수 있습니다. 반대로 이 쉬운 진입점 때문에 잘못된 실험도 늘 수 있습니다.
실무에서 가장 먼저 확인할 질문은 세 가지입니다. 첫째, 에이전트가 볼 수 있는 화면을 어디까지 제한할 것인가. 둘째, 모델이 제안한 행동 중 어떤 범주를 사람 확인 없이 실행할 것인가. 셋째, 웹페이지 안의 지시와 사용자의 지시가 충돌할 때 어느 쪽을 신뢰할 것인가. Google 문서는 미리보기 기능에 오류와 보안 취약점이 있을 수 있고, 중요한 작업·민감 데이터·심각한 오류를 되돌릴 수 없는 행동에는 가까운 감독을 권고합니다. 이 경고는 면책 문구가 아니라 제품 요구사항입니다.
테스트 전략도 달라집니다. 일반 API 통합은 요청과 응답 JSON을 고정하면 상당 부분을 회귀 테스트로 묶을 수 있습니다. 컴퓨터 사용 루프는 화면, 좌표, 로딩 시간, 팝업, 로그인 상태, 언어 설정에 따라 결과가 흔들립니다. 그래서 개발팀은 성공 여부만 기록하면 부족합니다. 각 단계의 스크린샷, 모델이 반환한 intent, 실제 실행된 함수, 안전 판단, 최종 URL을 함께 남겨야 합니다. 실패 로그가 없으면 "모델이 틀렸다"와 "페이지가 바뀌었다"와 "실행기가 좌표를 잘못 변환했다"를 구분하기 어렵습니다.
비용 구조도 단순한 토큰 단가로 끝나지 않습니다. 화면 조작형 에이전트는 한 번의 질문으로 답을 끝내지 않고, 스크린샷을 보내고 행동을 받고 다시 스크린샷을 보내는 루프를 반복합니다. 쇼핑몰 가격 비교나 관리자 콘솔 입력처럼 10단계가 필요한 작업은 모델 호출도 10회 가까이 늘어날 수 있습니다. gemini-3.5-flash가 빠른 모델이라는 사실은 지연 시간을 줄이는 데 도움이 되지만, 화면 캡처 크기, 재시도 횟수, 확인 단계, 브라우저 실행 환경 비용까지 합치면 작업당 비용은 별도 측정이 필요합니다. 이 지표는 기존 챗봇의 "응답당 비용"과 다릅니다. 단계별 중단률도 함께 봐야 합니다.
제품 UX에서는 사람의 개입 위치를 정해야 합니다. 모든 클릭 전에 확인을 요구하면 에이전트의 장점이 사라지고, 모든 클릭을 자동 실행하면 사고 범위가 커집니다. 실무적으로는 읽기 전용 탐색, 양식 초안 작성, 필터 변경, 내부 검색처럼 되돌릴 수 있는 행동은 자동화하고, 제출, 구매, 삭제, 권한 부여, 외부 전송은 확인 단계로 묶는 식의 계층화가 필요합니다. Google 문서의 safety_decision은 이 계층화를 구현할 수 있는 신호 중 하나입니다. 하지만 최종 정책은 각 제품의 데이터 민감도와 업무 책임에 맞춰 애플리케이션이 정해야 합니다.
이번 발표를 개발자 관점에서 요약하면, 브라우저 에이전트가 "프롬프트를 잘 쓰면 되는 기능"에서 "실행기, 샌드박스, 안전 판단, 감사 로그를 갖춘 시스템"으로 내려왔다는 뜻입니다. Gemini 3.5 Flash는 화면을 해석하고 다음 행동을 말합니다. 하지만 클릭을 수행하는 손, 스크린샷을 고르는 눈, 위험 행동을 멈추는 규칙은 여전히 애플리케이션 쪽에 남습니다. Google이 컴퓨터 사용을 공개 프리뷰로 열었다는 뉴스의 핵심은 모델이 화면을 클릭할 수 있다는 사실보다, 그 클릭을 운영 가능한 API 계약으로 포장하기 시작했다는 점입니다.