GeminiDesktop GeminiDesktop
가이드

Gemini 3 Computer Use 실전 테스트 2026: AI에게 호텔 예약 맡기기 전 8가지

게시일 · 작성자: GeminiDesktop Team

Gemini 3 Computer Use 실전 테스트 2026: AI에게 호텔 예약 맡기기 전 8가지

결론부터 말하면: Gemini 3 Computer Use는 Google이 2026년 선보인 “AI가 내 컴퓨터를 직접 조작한다”는 능력으로, 모델이 문장이 아니라 click_at(x, y) / type_text / key_combination 같은 조작 명령을 출력합니다. Claude Computer Use와 비교하면 좌표 정규화와 안전 경계 설계가 더 공격적이고, 그래서 네이티브 데스크톱 클라이언트가 반드시 있어야 합니다. 현재 macOS에서 가장 완성도 높은 구현이 GeminiDesktop으로, 내부적으로 scap 기반 화면 캡처 + enigo 기반 마우스·키보드 시뮬레이션 + AtomicBool + unblock channel 기반 emergency stop을 묶었습니다. 이 글은 AI에게 실제 계정을 맡기기 전에 반드시 이해해야 할 8가지를 정리합니다.

한 줄 경고: Computer Use는 실험실 장난감이 아니라 진짜 칼입니다. 켜기 전에 deny-list, per-step approval, emergency stop 세 개의 안전장치가 어디에 있는지 꼭 확인하세요.

1. Gemini 3 Computer Use vs Claude Computer Use: 세 가지 차이

이름은 같지만 내부 설계는 꽤 다릅니다.

항목 Gemini 3 Computer Use Claude Computer Use (Sonnet 4.5+)
좌표 정규화 모델이 0–1000 범위의 정규화 좌표를 출력, 클라이언트가 현재 화면 크기에 맞춰 스케일링 모델이 원시 픽셀 좌표 출력, 해상도 변화에 민감
화면 입력 스크린샷 + 옵셔널 접근성 트리 메타데이터 주로 스크린샷, 모델이 픽셀에서 UI 읽어냄
Action 단위 6종 원자 action (click_at / type_text / key_combination / scroll_at / wait / finish) 유사한 단위, 다른 명명
안전 경계 모델 측 + 클라이언트 측 deny-list 이중 레이어 주로 클라이언트 approval + 사용자 검토
Per-step approval 기본 ON, MVP는 trusted bypass 제공 안 함 구성 가능, 엔터프라이즈 샌드박스에서 비활성화 가능
가격 action 횟수 + 이미지 토큰 비슷, 이미지 토큰 소모는 약간 낮음

좌표 정규화가 이번 세대의 가장 실용적인 설계 결정입니다. 모델은 훈련할 때 화면 전체를 1000×1000 가상 그리드에 매핑해서, 출력하는 (x, y)가 항상 0–1000 정수입니다. 클라이언트를 MacBook Pro(2560×1600)에서 4K 외부 모니터(3840×2160)로 옮겨도 모델이 좌표계를 다시 배울 필요가 없고, 클라이언트가 선형 스케일링만 하면 됩니다. Claude의 픽셀 직출 방식은 고해상도 전환 시 드리프트가 눈에 띄게 많아져, 실측에서 가장 명확한 안정성 차이가 여기서 납니다.

2. 데스크톱 앱이 필수인 이유 (웹 버전으로는 불가)

“그냥 Chrome 확장으로 만들면 되지 않나?“라는 반응이 자주 나옵니다. 세 가지 이유로 안 됩니다.

  1. 화면 캡처 API가 브라우저에 없음: Chrome의 getDisplayMedia로 녹화는 가능하지만, 매초 전체 화면 JPEG를 모델에 안정적으로 공급할 수 없습니다(탭이 포커스 잃으면 멈춤). 다중 모니터나 시스템 메뉴는 말할 것도 없습니다
  2. 마우스·키보드 시뮬레이션도 브라우저 범위 밖: 브라우저 내 click과 type은 전부 DOM 샌드박스 안에서만 작동해서 브라우저 바깥 UI를 건드리지 못합니다. Spotlight 클릭, 창 전환, Cmd+Tab은 enigo나 robotjs 같은 OS 수준 라이브러리가 필요합니다
  3. 권한 모델이 다름: 브라우저의 권한 세분화는 “현재 탭” 단위지만, Computer Use는 시스템 전체 권한이 필요합니다 — macOS 접근성, Windows UI Automation 모두 네이티브 전용

결국 GeminiDesktop 같은 데스크톱 클라이언트는 “있으면 좋은” 수준이 아니라 macOS에서 Computer Use의 유일한 경로입니다. Google이 나중에 웹 버전을 열어도 브라우저 자체만 조작 가능하고, 크로스 앱 워크플로우는 영원히 범위 밖입니다.

3. 6가지 action의 실제 의미

Gemini 3 Computer Use는 모든 조작을 6개의 원자 action으로 압축했고, 이 의미를 이해하는 게 중요합니다.

  • click_at(x, y): 0–1000 정규화 좌표에서 좌클릭. 클라이언트가 스케일링 후 enigo의 MouseClick 호출
  • type_text(text): 포커스된 입력 필드에 문자 입력. 단축키는 해석 안 함 — Cmd+S는 key_combination으로 처리
  • key_combination(keys[]): 여러 키 동시 누르기. 예: ["cmd", "shift", "z"]로 redo. 시스템이 눌렀다 순서대로 뗌
  • scroll_at(x, y, direction, distance): 지정 좌표에서 스크롤. 방향 up/down/left/right, 거리는 notch 단위
  • wait(ms): 명시적 대기. 비동기 로딩보다 빠르게 스크린샷이 찍히는 걸 방지
  • finish(reason): “작업 끝”을 선언하는 유일한 정상 종료 경로

6개가 데스크톱 작업의 99%를 커버하지만, 동시에 연속 드래그, 호버 툴팁, 복잡한 제스처는 전혀 다룰 수 없습니다. “파일을 휴지통으로 드래그”는 한 번의 action으로 표현 불가능하고, “click_at으로 선택 → key_combination Cmd+Delete”로 분해해야 합니다.

4. 안전 deny-list: rm / sudo / git push –force를 자동 차단하는 원리

GeminiDesktop은 클라이언트에 하드코딩된 deny-list를 유지하고, 하나라도 일치하면 모델의 action이 실제로 실행되기 전에 건너뛸 수 없는 확인 다이얼로그를 띄웁니다.

  • rm / sudo / chmod 777 / chown (파괴적 셸 명령)
  • Cmd+Q / Alt+F4 (저장 안 된 상태를 잃는 강제 종료)
  • git push --force / git reset --hard (리포지토리 상태 파괴)
  • Cmd+Shift+Delete (휴지통 우회 삭제)

구현 골자: 클라이언트가 type_text 실행 전에 입력할 문자열을 deny-list와 정규식으로 대조하고, 일치하면 action을 suspend 후 메인 스레드에 모달 다이얼로그를 띄웁니다. 모델은 이 차단을 “보지 못하고” 다음 턴에 “rejected by user” 상태만 받아서, 전략을 재조정할지 멈추고 사용자에게 물을지 결정합니다.

철학: “모델이 알아서 피해줄 것”이라고 믿지 말 것. Gemini 3가 RLHF 데이터에서 rm -rf /를 피하도록 배웠더라도, 프로덕션에서는 클라이언트 측 최종 방어선이 책임 있는 선택입니다.

5. Per-step approval: MVP가 trusted bypass를 제공하지 않는 이유

기본 설정에서는 모든 action이 실행 전에 짧은 approval 프롬프트를 띄웁니다. “모델이 click_at(450, 230)을 수행하려 합니다 — 허용하시겠어요?” Enter로 허용, Escape로 거부.

“너무 귀찮으니 trust this session 토글 추가해달라”는 요청이 많지만, MVP는 명확히 거절합니다. 이유:

  1. 모델 편향은 여전히 실재: Gemini 3가 2.5보다 정확도가 크게 올라도 “잘못된 버튼을 클릭하는” 저확률 이벤트는 남습니다. 20단계 워크플로우에서 스텝당 0.5% 에러율이면 엔드투엔드 약 10% 실패율 — approval을 우회하면 사용자 손실이 큼
  2. UI는 예측 불가능: A/B 실험, 팝업 광고, 쿠키 배너가 좌표를 끊임없이 바꿉니다. Approval은 “내가 누르려던 바로 그 위치가 맞다”를 사용자가 확인하는 유일한 기회
  3. 감사 요구: 엔터프라이즈에서는 AI의 모든 조작이 추적 가능해야 합니다. Per-step approval이 그대로 운영 로그가 됨

미래 방향: action 유형 + 사용자 히스토리 기반 적응형 approval. “같은 호텔 예약”을 20번 반복했다면 신뢰 템플릿으로 표시해 스킵 허용하고, UI 레이아웃이 크게 바뀌면 즉시 엄격 모드로 돌아가는 식입니다.

6. 실전 데모: AI에게 폼 기입과 트윗 작성 시키기

제가 실제로 돌려본 완전한 데모 — Gemini 3에게 랜딩 페이지의 waitlist에 이메일 등록을 시킨 뒤 Twitter에 홍보 트윗을 올리게 하기.

프롬프트: “두 가지 부탁: 1) example.com/waitlist에 가서 alice@example.com으로 등록, 2) 그다음 Twitter로 가서 ‘X 웨이트리스트에 방금 등록, 흥미로워 보임’ 정도의 트윗 게시.”

Action 시퀀스(일부 wait 생략):

  1. click_at(500, 300) — 주소창 클릭
  2. type_text("example.com/waitlist")
  3. key_combination(["return"]) — 제출
  4. wait(800) — 페이지 로딩 대기
  5. click_at(420, 510) — 이메일 입력 필드 클릭
  6. type_text("alice@example.com")
  7. click_at(500, 580) — Join Waitlist 클릭
  8. wait(1200) — 등록 완료 대기
  9. key_combination(["cmd", "t"]) — 새 탭
  10. type_text("twitter.com/compose/post")
  11. …(계속)
  12. finish("이메일 등록과 트윗 게시 완료")

M2 MacBook에서 전체 약 90초 걸렸고, 그중 40초가 페이지 로딩과 approval 확인이었습니다. 수동으로 같은 작업을 3분에 하던 걸 생각하면 생산성 향상이 분명합니다. 하지만 더 중요한 관찰: 5단계에서 모델이 처음으로 위치를 오인(장식용 아이콘을 입력 필드로 착각)했고, 제가 reject한 직후 스스로 재계획해서 올바른 좌표를 찾아냈습니다. 바로 이것이 per-step approval의 실제 가치입니다.

7. Emergency stop: AtomicBool + unblock pending approval 원리

AI가 폭주하면? GeminiDesktop에는 글로벌 emergency stop(기본 단축키 Cmd+Shift+.)이 있습니다. 눌렀을 때 동작:

  1. 글로벌 AtomicBool을 true로 설정
  2. 실행 중인 enigo action은 다음 틱에서 플래그를 확인하고 즉시 abort
  3. approval을 기다리며 블록된 channel을 unblock, 수신 측에 “cancelled” 신호
  4. WebSocket 연결을 능동적으로 종료해 모델에 더 이상 프레임 전달 안 함

왜 AtomicBool과 channel 두 경로가 필요한가? AI action이 두 상태 중 하나에 있을 수 있기 때문입니다.

  • OS 호출 실행 중(enigo의 마우스 이동) → AtomicBool로 worker thread가 다음 루프에서 빠져나옴
  • 사용자 approval 대기 중(channel 블록) → channel을 능동적으로 unblock해야 함. 그렇지 않으면 AtomicBool이 무의미(worker가 recv에서 멈춘 채)

이 이중 경로 차단이 많은 “덜 만든” AI 자동화 도구의 함정입니다. AtomicBool만 설정하면 사용자가 emergency stop을 누르고도 앱이 몇 초간 멈춘 상태로 남습니다. GeminiDesktop은 두 신호를 병렬로 발사해 최악의 경우에도 200ms 안에 완전히 멈춥니다.

8. 알려진 제약: macOS 접근성 권한 + Windows 화면 캡처

실전에서 반드시 부딪히는 세 가지 제약:

  • macOS 접근성 권한: Computer Use는 enigo로 마우스·키보드를 시뮬레이션해서 “시스템 설정 → 개인 정보 보호 및 보안 → 손쉬운 사용”에서 GeminiDesktop을 허가해야 합니다. macOS는 이 권한에 민감해서 최초 허가 시 앱 재시작이 필요하고, 버전 업그레이드 시 권한이 조용히 해제되기도 합니다
  • Windows 화면 캡처: 현재 scap 라이브러리의 Windows 지원이 완성되지 않아, GeminiDesktop 공식 Windows 빌드에서는 Computer Use가 잠정 비활성화 상태입니다(텍스트 채팅과 Live는 작동). 로드맵 목표: 2026 Q3
  • 다중 모니터 일관성: 해상도가 다른 여러 모니터를 쓸 때 모델의 1000×1000 좌표계는 “활성 윈도우가 있는 모니터”에 적용됩니다. 모니터 간 드래그 워크플로우는 아직 불안정하니 당분간 단일 모니터 환경을 권장합니다

더 낮은 위험도로 Gemini 3의 실시간 능력을 먼저 맛보고 싶다면 자매 편인 Gemini Live Mac 데스크톱 가이드를 참고하세요 — 거기서는 “AI가 화면을 보며 조언”만 하고, 실제로 클릭하진 않습니다. Google의 공식 API 문서를 깊이 보고 싶다면 Google AI 개발자 사이트에 Computer Use의 전체 API 레퍼런스가 있습니다.

자주 묻는 질문

Q1: 내 Gemini API 키로 Computer Use를 돌릴 수 있나요?

A: 가능합니다. GeminiDesktop의 BYOK 방식은 키를 Google에 직송하고, 클라이언트가 로컬에서 computerUse: 도구 엔드포인트를 호출하는 형태입니다. Computer Use는 순수 텍스트 대비 3~5배 토큰을 소모하니(스크린샷이 무거움) BYOK 사용자는 청구서를 주시하세요.

Q2: AI가 민감한 창을 보면 어떡하죠?

A: Computer Use를 켜기 전에 민감한 창(비밀번호 관리자, 비공개 채팅)을 닫거나 다른 Space로 옮기세요. “윈도우 단위 캡처 화이트리스트” 기능은 로드맵에 있지만, MVP는 사용자 자율에 의존합니다.

Q3: 50단계짜리 긴 워크플로우를 완전 자동으로 돌릴 수 있나요?

A: 기술적으로는 가능하지만 실전에서는 비추천. 단계당 실패율이 기하급수적으로 쌓이고, per-step approval은 중간에 개입하라고 만든 것입니다. 권장: 긴 워크플로우를 3~8단계 소단위로 쪼개 개별 실행.

Q4: Zapier / n8n 같은 워크플로우 도구와 경쟁하나요?

A: 완전히는 아닙니다. Zapier는 “API가 있는 SaaS를 서로 연결”하고, Computer Use는 “API가 없는 데스크톱 UI도 자동화”합니다. 진짜 킬러 시나리오는 레거시 엔터프라이즈 소프트웨어 — API는 없지만 평범한 웹/네이티브 클라이언트처럼 생겼고, AI가 눈으로 보며 클릭해 갈 수 있는 경우입니다. 오히려 상보적입니다.

마무리

Gemini 3 Computer Use는 “AI가 자율적으로 컴퓨터를 조작한다”를 데모에서 프로덕션 입구까지 끌어올렸지만, “무엇이든 맡겨도 된다”는 아직 멀었습니다. deny-list, per-step approval, emergency stop — 이 세 안전장치의 작동 원리를 이해하는 게 실제 업무에 투입하기 전의 전제입니다. 호텔 예약처럼 저위험 단일 작업부터 시작해 모델 안정성에 대한 신뢰를 단계적으로 쌓는 것 — MVP가 trusted bypass를 제공하지 않는다는 사실이 곧 그 말을 하고 있습니다.