본문으로 건너뛰기

컴퓨터 사용 에이전트 비교

고급

모든 주요 랩이 이제 화면을 보고 클릭할 수 있는 모델을 내놓습니다. Anthropic의 computer use 도구, OpenAI의 computer 도구, Google의 computer_use 도구는 모두 같은 형태의 문제를 풉니다 — 스크린샷을 찍고, 액션을 정하고, 실행하고, 다시 스크린샷 — 그리고 셋 모두 클릭이 40픽셀씩 빗나가기 시작하기 전까지는 눈에 띄지 않는 방식으로 서로 와이어 호환이 되지 않습니다.

이 페이지는 리더보드가 아니라 하네스 수준의 가이드입니다. 리더보드는 매달 바뀌지만, 아래의 실패 모드는 첫 프리뷰가 나온 이래 그대로입니다.

What you'll learn
  • 세 제공자가 공유하는 에이전트 루프 — 그리고 그들이 갈라지는 세 지점 이해하기
  • 첫 시도 대부분을 조용히 망가뜨리는 좌표 버그 고치기 (Retina, 다운스케일링, 이미지 크기 제한)
  • 각 제공자의 안전 게이트 알기 — 그것은 선택적 부가물이 아니라 프로토콜의 일부입니다
  • OSWorld를 정직하게 읽기: 인간 기준선이 실제로 뜻하는 것
  • 추론 노력(effort)을 올바르게 고르기 — 가장 싼 설정은 여러분이 짐작하는 그것이 아닙니다

모두가 공유하는 루프​

브랜딩을 걷어내면 셋 다 같은 상태 기계입니다.

Guided walkthrough1 of 5
  1. 모델은 여러분의 지시와 현재 화면의 이미지를 받습니다. 일부 제공자는 현재 URL이나 최근 액션의 짧은 이력도 원합니다.

사람들이 놓치는 귀결: 세상에 대한 모델의 유일한 지각은 여러분이 보낸 이미지입니다. 아래의 모든 실패는 사실 그 이미지의 실패이거나, 그것이 함의하는 좌표 공간의 실패입니다.

셋이 갈라지는 곳​

갈라짐은 "누가 더 똑똑한가"가 아닙니다. 계약입니다.

Anthropic (Claude)OpenAI (GPT)Google (Gemini)
액션 공간원시 데스크톱 프리미티브: screenshot, left_click, type, key, scroll, drag, hold_key, wait, 그리고 최신 도구 버전의 zoom구조화된 UI 액션: click, double_click, scroll, type, keypress, drag, move, wait, screenshot의미론적 액션: click/type뿐 아니라 navigate, go_back, go_forward, open_app, long_press — 브라우저와 모바일 개념이 일급 시민
좌표픽셀 크기를 보내면 모델이 그 공간의 원시 픽셀 좌표를 반환같은 픽셀 계약, 권장 데스크톱 크기 제공동일. 각 액션의 이유를 설명하는 intent 필드 추가
루프 배관이미지를 담은 도구 결과 블록computer_call → call_id로 연결된 computer_call_output. previous_response_id가 이력을 실어 나르므로 재전송 불필요함수 호출 → 새 스크린샷과 함께 function_result
안전 게이트스크린샷에 인젝션 분류기가 자동 실행명시적으로 확인해야 하는 pending_safety_checks정책 범주가 붙은 safety_decision
강점 영역범용 데스크톱 / OS 수준 제어데스크톱과 브라우저, 그리고 코드 실행 경로브라우저 우선. 모바일에 강함. 데스크톱 OS 제어에는 명시적으로 최적화되지 않음

마지막의 Anthropic/Google 행이 아키텍처를 결정합니다. Google의 액션 공간은 의미론적입니다 — go_back은 모델이 이름 부를 수 있는 개념입니다. Anthropic의 것은 기계적입니다 — 뒤로 가려면 모델이 뒤로 가기 버튼을 찾아 클릭하거나 올바른 키 조합을 눌러야 합니다. 의미론적 액션은 브라우저 안에서 더 믿을 만하고 바깥에서는 쓸모없습니다. 기계적 프리미티브는 어디서나 동작하고 더 자주 실패합니다.

그러니 computer-use 에이전트를 제공자 간에 이식하는 것은 모델 교체가 아닙니다. 하네스의 액션 실행기를 다시 쓰는 일입니다. 그에 맞게 예산을 잡으세요. (코딩 에이전트 CLI 비교와 같은 교훈: 여러분이 실제로 결혼한 상대는 모델이 아니라 하네스입니다.)

첫 주를 잡아먹는 좌표 버그​

이 페이지에서 가장 값어치 있는 항목입니다. 거의 모두가 부딪히고, 증상이 "모델이 클릭을 못 한다"처럼 보이기 때문입니다.

클릭을 못 하는 게 아닙니다. 여러분의 이미지와 좌표 공간이 서로 어긋난 것입니다.

독립적인 세 가지 원인이 있고, 겹칩니다.

1. Retina / HiDPI가 이미지를 두 배로 만든다​

macOS Retina 디스플레이는 디바이스 픽셀 비율 2로 스크린샷을 캡처합니다 — 이미지가 논리적 화면 좌표의 두 배 해상도입니다. 그것을 그대로 보내면 모델은 2880 너비 이미지 위에서 추론하는데 여러분의 클릭 실행기는 1440 너비 논리 포인트로 생각합니다. 모든 클릭이 의도한 위치의 대략 절반 지점에, 일관되게, 한 방향으로 떨어집니다.

해법: 보내기 전에 2로 다운스케일하거나, 또는 모델이 반환한 좌표를 절반으로 나누세요. 둘 다 하지는 마세요.

2. API가 큰 이미지를 조용히 다운스케일한다​

모델에는 이미지 크기 제한이 있고 — 같은 랩의 모델들 사이에서도 다릅니다. Claude Sonnet 5, Opus 4.8, Opus 4.7은 긴 변 기준 2576 픽셀까지 받습니다. 이전 Claude 모델들은 1568 픽셀과 총 약 1.15 메가픽셀까지 받습니다.

여기에 함정이 있습니다. 더 큰 것을 보내면 API가 에러를 내는 대신 알아서 다운스케일합니다. 그러면 모델은 자신이 본 이미지의 공간에서 좌표를 반환하는데, 리사이즈가 서버 측에서 일어났으므로 여러분은 스케일 팩터를 결코 알지 못합니다. 정말로 거대한 이미지(한 변이 약 8,000 px 초과)만 검증 에러로 곧바로 거부됩니다.

그러니 "친절한" 동작이 곧 버그입니다. 항상 클라이언트 측에서 리사이즈하고, display_width_px/display_height_px를 실제로 보낸 크기로 설정하고, 반환된 좌표를 직접 되돌려 스케일하세요.

3. detail 설정과 종횡비​

OpenAI 도구에서는 스크린샷에 detail: "original"을 써야 합니다 — 이 작업에 한해서는 "high"와 "low" 둘 다 클릭 정확도를 떨어뜨립니다. 그리고 종횡비를 보존하지 않고 리사이즈하면 클릭이 맞는 영역에 떨어지고 대상은 빗나갑니다.

좌표 스케일링 — 해법의 형태

# Before sending: shrink to fit the model's image limit, remember the factor.
LONG_EDGE_LIMIT = 2576   # check YOUR model's limit; older Claude models: 1568

scale = min(1.0, LONG_EDGE_LIMIT / max(width, height))
sent_w, sent_h = round(width * scale), round(height * scale)
# -> send the resized image, and declare display_width_px=sent_w, display_height_px=sent_h

# After the model replies: map its coordinates back to the real screen.
real_x, real_y = model_x / scale, model_y / scale
# On a Retina capture you did NOT pre-downscale, divide by the device pixel ratio too.

증상 → 원인 요약표​

증상거의 확실히
클릭이 한 방향으로 일관되게 어긋남선언한 display_width_px/display_height_px가 실제로 보낸 이미지와 맞지 않음
클릭이 맞는 영역에 떨어지지만 작은 대상은 빗나감다운스케일로 디테일 손실, 또는 리사이즈에서 종횡비 왜곡
어디서나 정확도가 나쁨해상도가 너무 낮음 — 1280x720을 하한으로 시도해 보세요
모델이 작은 텍스트(탭 제목, 파일명, 줄 번호)를 잘못 읽음확대가 필요한데 활성화하지 않음

벤더 자신들이 제시한 해상도 가이드: Anthropic은 일반 데스크톱에 1024x768 또는 1280x720을, 웹 앱에 1280x800 또는 1366x768을 권하며 1920x1080을 넘기지 말라고 명시합니다. OpenAI는 1440x900 또는 1600x900을 권합니다. 크다고 더 좋은 게 아닙니다 — 픽셀에 토큰을 지불하고는 다운스케일에서 그 디테일을 버리게 됩니다.

확대라는 탈출구​

Claude의 최신 computer 도구 버전(computer_20251124)은 zoom 액션을 추가하는데, 기본은 꺼짐입니다 — enable_zoom: true를 설정해야 합니다. 켜면 Claude는 스크린샷의 기본 해상도에서 읽기 힘든 작은 텍스트가 필요할 때 영역을 확대합니다. 사이드바 파일명, 탭 제목, 상태 표시줄 텍스트, 줄 번호, 버튼 레이블 같은 것들입니다.

눈에 잘 안 띄는 운영 노트: Claude가 기대하는 때에 확대를 하지 않고 있다면, 해법은 대개 화면 전체가 아니라 특정 영역이나 요소에 대해 묻는 것입니다.

안전 게이트는 프로토콜의 일부다​

이것을 덧붙이는 물건으로 여기지 마세요. 세 API 모두에서 안전 메커니즘이 루프의 형태를 바꿉니다.

Anthropic은 모델이 프롬프트 인젝션에 저항하도록 훈련했고 동시에 computer-use 도구가 쓰이면 여러분의 프롬프트에 분류기를 자동으로 돌립니다. 분류기가 스크린샷 안에서 인젝션으로 보이는 것을 포착하면, 다음 액션 전에 사용자에게 확인을 구하도록 모델을 유도합니다. 사람이 있을 때는 훌륭하고 무인 파이프라인에는 명백히 틀린 동작입니다 — 그래서 지원팀 문의로 열리는 옵트아웃이 있습니다.

OpenAI는 루프가 진행되기 전에 여러분의 코드가 명시적으로 확인해야 하는(acknowledged_safety_checks) pending_safety_checks를 노출합니다. 게이트가 여러분 손에 있고, 건너뛰는 것은 코드에서 내리는 결정입니다.

Google은 safety_decision을 반환합니다 — allowed, require_confirmation, blocked — 그리고 FINANCIAL_TRANSACTIONS, COMMUNICATION_TOOL, ACCOUNT_CREATION, SENSITIVE_DATA_MODIFICATION, LEGAL_TERMS_AND_AGREEMENTS를 포함한 정책 범주가 이를 구동합니다. 스크린샷의 프롬프트 인젝션 스크리닝은 옵트인으로 제공됩니다.

위협은 실재하고 구체적입니다. 스크린샷은 신뢰할 수 없는 입력입니다. 웹페이지에, 이미지에, 에이전트가 연 PDF에 렌더링된 텍스트 — 그 전부가 여러분의 지시와 같은 채널로 모델에 도달합니다. Anthropic 자신의 문서는 Claude가 어떤 상황에서는 여러분의 지시와 충돌하더라도 콘텐츠에서 발견한 지시를 따를 것이라고 지적합니다. 모든 제공자의 완화책은 같은 세 규칙으로 수렴합니다: 환경을 격리하고, 영향이 큰 액션에는 사람을 두고, 화면 위의 모든 것을 적대적이라고 취급하라.

에이전트가 로그인해야 한다면 그 위험은 급격히 올라갑니다 — 자격 증명 더하기 주입 가능한 콘텐츠는 이 분야 최악의 조합입니다. 방어 플레이북은 로컬 및 하이브리드 에이전트 보안과 프롬프트 인젝션을 보세요.

OSWorld를 정직하게 읽기​

OSWorld는 공유 잣대이고, 속이기 어렵기 때문에 좋은 잣대입니다. 에이전트를 실제 애플리케이션이 있는 실제 OS에 떨어뜨리고 실행 기반 검증으로 채점합니다 — 에이전트가 그렇게 주장했는지가 아니라 파일이 실제로 저장되었는지 스크립트가 확인합니다. 벤치마크는 369개 작업에 걸쳐 있고(표준 평가 세트에서는 361개, 일부 Google Drive 작업은 수동 설정이 필요하므로) 134개의 실행 기반 평가 함수를 제공합니다. OSWorld-Verified는 커뮤니티가 보고한 깨진 예제를 고치고 평가 시간을 AWS에서 약 한 시간으로 줄인 정제판입니다.

함께 붙들 가치가 있는 두 숫자.

  • 인간 기준선은 약 72.4%입니다. 100%가 아닙니다. 이 작업들은 정말로 까다롭고 사람도 헤맵니다.
  • OSWorld가 출시됐을 때 최고 모델은 12.24%를 기록했습니다.

프런티어 에이전트들은 이제 70%대 이상을 보고합니다 — 즉 "에이전트가 컴퓨터 사용에서 인간 수준에 도달했다"는 헤드라인은 산술적으로는 방어 가능하지만 실무적으로는 오도합니다. 벤치마크 점수는 코딩 벤치마크와 똑같이 모델 + 하네스 + 스캐폴드 결과입니다(능력–신뢰성 격차 참고). 여러분의 하네스는 그들의 하네스가 아닙니다. 그리고 단일 작업 75% 성공률은 잔혹하게 복리로 줄어듭니다. 각 단계가 95% 신뢰성인 여덟 단계 워크플로는 약 66%만 성공합니다.

OSWorld는 능력이 존재한다는 증거로 다루고, 여러분의 제품이 동작한다는 유일한 증거는 자체 평가 세트로 삼으세요.

아무도 예상 못 하는 추론 노력 결과​

Claude computer use에 한해, Anthropic의 내부 벤치마킹은 통상적인 직관을 뒤집는 가이드를 줍니다.

  • Opus 4.7: 기본은 high 노력. 처리량이 많거나 비용에 민감한 워크로드에서는 low로 내리세요.
  • Sonnet 4.6과 Opus 4.6: medium이 정확도 대비 비용 비율이 가장 좋습니다. max는 피하세요 — UI 작업에서는 정확도 향상 없이 토큰 비용만 더합니다.
  • 반직관적인 것: 그 모델들에서 low 노력은 사고를 아예 끄는 것보다 출력 토큰을 더 적게 씁니다. 약간의 사고가 실수를 막고, 실수는 재시도를 부르고, 재시도는 사고보다 훨씬 많은 토큰을 씁니다.

그러니 "돈 아끼려 사고를 끄자"는 computer use에서는 흔히 틀립니다. 가장 싼 것은 약간의 사고입니다.

모델 선택의 또 다른 주름: 기계적 클릭 정밀도는 지능과 같은 축이 아닙니다. Sonnet 4.6은 클릭에서 Opus 4.6보다 기계적으로 더 정밀하고, 스크린샷이 심하게 다운스케일됐을 때 더 견고합니다. Opus 4.7은 그 격차를 좁히고 픽셀 제한을 올려서 애초에 다운스케일이 덜 필요합니다.

Enter 또는 스페이스 키를 눌러 카드를 뒤집습니다. 좌우 화살표 키로 카드를 이동할 수 있습니다.용어가 표시되었습니다.
1 / 7

접촉을 견디는 하네스​

Guided walkthrough1 of 6
  1. 가치 있는 것이 하나도 없는 컨테이너나 VM. 모든 제공자가 이렇게 말하고 진심입니다: 에이전트는 언젠가 여러분이 의도하지 않은 것을 클릭합니다.

마지막 단계가 전략적인 것입니다. Computer use는 API가 없는 소프트웨어를 위한 만능 어댑터입니다 — 레거시 데스크톱 앱, 벤더 포털, 통합 스토리 없이 로그인 뒤에 있는 모든 것. 훌륭한 해킹이고, 여전히 해킹입니다. 먼저 MCP와 진짜 도구에 손을 뻗으세요.

Check yourself

0/5
  1. 여러분의 computer-use 에이전트 클릭이 한 방향으로 일관되게 어긋납니다. 가장 유력한 원인은?
  2. 큰 스크린샷에 대한 API의 자동 다운스케일링에 의존하는 것이 왜 편의가 아니라 버그인가요?
  3. Sonnet 4.6에서 Claude computer use를 할 때, 보통 출력 토큰이 가장 적게 드는 추론 노력 설정은?
  4. OSWorld 인간 기준선이 대략 72%입니다. 75%를 기록한 에이전트에 대해 이것이 함의하는 바는?
  5. 스크린샷이 왜 신뢰할 수 없는 입력으로 간주되나요?

출처 및 더 읽을거리​