맥 한 대를 AI 가 대신 조작하게 하는 맥 자동화 에이전트를 만들고 있다. 웹에서 정보를 찾아 읽고, 메모 앱에 적는 정도의 일이다. 9월 29일 하루 동안 이 에이전트에 Claude Sonnet 5.5 의 컴퓨터 유즈를 붙여 보고, 다른 방식들과 같은 과제로 나란히 돌렸다.
결론부터 적는다. 점수로 가려진 건 거의 없다. 대신 새 툴셋을 붙이려면 무엇을 알아야 하는지, 화면을 보는 방식에 따라 비용이 몇 자릿수 달라지는지, 그리고 눈 하나로는 안 된다는 것을 알았다.
1. 왜 붙였나 — 구독 CLI 와 API 는 다른 길이다
질문은 하나였다. "Sonnet 5.5 에서 좋아졌다는 화면 조작이, 우리가 쓰는 구독 경로(Claude Code CLI)로도 오는가."
Claude 를 부르는 길은 둘이다. 월정액 구독으로 쓰는 Claude Code CLI, 그리고 쓴 만큼 돈을 내는 API. 컴퓨터 유즈 툴셋은 API 쪽 기능이다. 그래서 비교를 네 조로 짰다.
| 조 | 눈(무엇으로 보나) | 두뇌 | 과금 |
|---|---|---|---|
| C | 브라우저 본문 글자 | 다른 회사 모델(구독) | 구독 |
| D | 스크린샷 | Claude Code CLI (Opus 5.5) | 구독 |
| C+D | 브라우저 본문 글자 | Claude Code CLI | 구독 |
| E | 스크린샷 | API 컴퓨터 유즈 툴셋 (Sonnet 5.5) | API, 상한 $10 |
C+D 조를 따로 둔 이유가 있다. C 와 D 는 두뇌만 다른 게 아니라 눈도 다르다. 두 조만 재면 결과가 갈려도 "두뇌가 좋아서" 인지 "눈이 달라서" 인지 알 수 없다. 과제는 모든 조가 같다. 6점 만점으로 채점했고, 조마다 3회씩 돌렸다.
2. 툴셋 규격의 벽 5개
Sonnet 5.5 는 API 에서 예전 컴퓨터 유즈 도구를 받지 않는다. 새 툴셋 computer_toolset_20260801 만 받는다. 모양이 예전과 완전히 달라서, 붙이는 동안 같은 자리에서 다섯 번 걸렸다. API 가 돌려준 말을 그대로 옮긴다.
| # | API 가 돌려준 말 | 뜻 |
|---|---|---|
| 1 | name is not accepted on a toolset entry | 툴셋 항목에 name 을 넣을 수 없다 |
| 2 | display_width_px: Extra inputs are not permitted | 화면 크기도 넘길 수 없다. 사실상 type 하나만 받는다 |
| 3 | tool_result ... must carry the paired tool_use's toolset_name | 툴셋 멤버에 대한 답에는 toolset_name 을 실어야 한다 |
| 4 | toolset_name is only accepted on a tool_result whose paired tool_use is a toolset member | 멤버가 아닌 도구의 답에는 실으면 안 된다. 짝이 준 값을 그대로 따라가면 된다 |
| 5 | (오류 아님) 동작이 input.action 이 아니라 tool_use.name 에 온다 | 아래 비교 참고 |
// 예전 도구
{ "name": "computer", "input": { "action": "screenshot" } }
// 새 툴셋
{ "name": "screenshot", "input": {}, "toolset_name": "computer" }가장 비쌌던 건 5번이다. 오류가 나지 않기 때문이다. input.action 을 읽는 코드가 세 번 내리 "허용되지 않은 동작: undefined" 를 돌려줬다. 그때마다 모델은 정확히 보고하고 멈췄다. 짐작하지 않고 tool_use 를 한 번 찍어 봤으면 바로 풀렸을 일이다.
덧붙여 둘 것이 두 가지 있다.
- 화면 크기를 넘길 수 없다. 그래서 좌표 기준을 과제문에 직접 적어 줘야 한다. 보내는 이미지 크기와 맞추지 않으면 클릭이 전부 빗나간다. 이건 두뇌의 실패가 아니라 설정의 실패다.
- 동작 이름은 우리가 정하지 못한다. 툴셋은
left_click,double_click,zoom,cursor_position,wait같은 이름으로 부른다. 우리 쪽 동작에 별칭으로 이어 줘야 한다. 거절할 때는 "허용되지 않음" 만 돌려주지 말고, 무엇이 되는지를 함께 알려야 모델이 헤매지 않는다.
3. 비용 — 입력 54만 토큰, 출력 3천
E 조(API 툴셋)의 실측이다.
| 회 | 스텝 | 입력 토큰 | 출력 토큰 | 비용(추정) | 어떻게 끝났나 |
|---|---|---|---|---|---|
| E-1 | 40 (상한) | 544,854 | 3,341 | $2.81 | 스텝 상한에 잘림 |
| E-2 | 41 (상한) | 500,717 | 3,218 | $2.58 | 스텝 상한에 잘림 |
| E-3 | 12 | 73,667 | 1,914 | $0.42 | "화면이 클릭·스크롤에 반응하지 않았다"고 보고 |
달러 칸은 추정이다. 단가를 확인하지 않고 보수적으로 가정해 계산했다. 사실인 것은 토큰 숫자뿐이다. 앞선 실패 회차까지 합친 누적 추정이 $9.4 에 이르러, 상한 $10 앞에서 멈췄다.
숫자가 말하는 건 한 가지다. 입력이 출력보다 두 자릿수 많다. 스크린샷 방식은 스텝마다 화면을 다시 보낸다. 그만큼이 전부 입력이 된다. 이 방식의 구조적 비용이다.
같은 정보를 다른 눈으로 읽으면 어떤가. 브라우저 본문을 글자로 읽는 쪽(C 조의 눈)은 같은 가게 정보 페이지를 1,842자, 27ms 에 읽었다. 표본은 작지만 자릿수가 달라서 이 차이는 뒤집히지 않는다.
E 조의 0점을 "툴셋이 못한다" 로 읽으면 안 된다. 완주하지 못한 원인은 우리 쪽 연결 코드였다. 동작 이름을 click 만 받아서 left_click 을 세 번 내리 거부했고, 그걸 고치자 스텝 상한 40 에 걸려 잘렸다. 막혀서 멈춘 게 아니다.
4. 글자 눈과 스크린샷 눈 — '두 눈' 결론
| 조 | 성공 (/6) | 지어냄 | 실패 사유 |
|---|---|---|---|
| C (글자 눈 + 다른 모델) | 4 · 2 · 4 (평균 3.3) | 0건 | 한 가게의 영업시간 항목을 3회 모두 놓침 |
| D (스크린샷 + CLI) | 0 · 0 · 6 | 0건 | 1·2회차는 권한 창과 다른 앱 창에 화면이 가려짐. 3회차 완주 |
| C+D (글자 눈 + CLI) | 0/6 | 0건 | 메모가 만들어지지 않음. 눈이 브라우저 밖을 못 봄 |
| E (스크린샷 + API 툴셋) | 0/6 (미완주) | 0건 | 연결 코드 미완성 + 스텝 상한 |
원인을 가른 건 C+D 조였다. 세 번 다 메모가 생기지 않았다. 그런데 두뇌는 이렇게 보고했다.
"새 메모를 만들고 네 줄을 입력했습니다. 다만 메모 앱 화면은 읽을 방법이 없어서 (page_text 는 크롬 글자만 읽음), 메모가 실제로 저장됐는지 확인하지 못했습니다."
도구는 성공했다고 답했다. 그래도 모델은 "확인하지 못했다" 고 말했다. 실패 원인은 두뇌가 아니라 눈이 볼 수 있는 범위였다.
그날 아침 우연히 하나 더 잡혔다. 맥 화면이 잠겨 있었다. 글자 눈은 그 상태에서도 페이지 본문을 정상으로 읽었다. 스크린샷 눈이 찍은 건 로그인 창뿐이었다. 캡처 크기가 34KB 였는데, 평소에는 434KB 다.
| 글자 눈 (브라우저 본문) | 스크린샷 눈 | |
|---|---|---|
| 보는 것 | 브라우저 문서 안만 | 화면 전체 |
| 강함 | 다른 창·시스템 창에 흔들리지 않는다. 빠르다(ms) | 브라우저 밖(메모 앱 등)도 확인할 수 있다 |
| 약함 | 브라우저 밖을 못 본다. 쓴 결과를 검증하지 못한다 | 권한 창과 창 전환에 가려진다. 잠긴 화면에서는 쓸 수 없다 |
두 눈은 우열이 아니라 보는 범위가 다르다. 하나로 다 덮으려 한 게 설계의 착오였다. 그래서 둘 다 주기로 했다. 글자로 읽는다. 브라우저 밖을 확인하거나 클릭 위치를 확인할 때만 화면을 본다. 매 스텝 화면을 보내지 않으니 3절의 입력 토큰 문제도 함께 줄어든다.
이 판으로 Opus 5.5 를 세 번 돌렸다. 3/3 완주에 셋 다 6점이었다. 앞 판에서 D 조를 두 번 막았던 창 가림은 0건이 됐다. 이건 모델이 좋아져서가 아니라, 에이전트 앱이 앞으로 튀어나오던 우리 쪽 문제를 고쳐서다.
그리고 네 조 모두 지어낸 답이 0건이었다. 실패한 회차도 "미확인" 을 적고 멈췄다. 이 과제가 정말 보고 싶었던 건 점수가 아니라 그쪽이었다.
5. Opus 5.5 와 Sonnet 5.5 — 5회씩
'두 눈' 판에서 두뇌만 바꿔 각 5회씩 돌렸다. 둘 다 구독 CLI 다. 앞 판에서 먼저 돈 쪽이 유리했던 문제가 있었다. 그래서 순서를 번갈아 두고, 회차마다 시험 메모를 같은 출발선으로 되돌렸다.
| 두뇌 | 성공 | 입력 토큰 (평균) | 출력 (평균) | API 환산 (평균) | 시간 | 스크린샷 |
|---|---|---|---|---|---|---|
| Opus 5.5 | 5/5 | 758,957 (638k~955k) | 3,996 | $0.592 ($0.543~0.705) | 87초 | 5.2장 |
| Sonnet 5.5 | 5/5 | 971,718 (669k~1,340k) | 4,223 | $0.413 ($0.311~0.483) | 95초 | 5.6장 |
여기 달러는 청구된 돈이 아니다. claude -p --output-format json 이 돌려주는 total_cost_usd 는 구독 경로에서 "같은 일을 API 로 했으면 얼마인가" 를 보여 주는 환산액이다. 구독으로 돌았으니 이 돈은 나가지 않았다. 처음에 '실비용' 이라고 적었다가, 총괄 에이전트의 검토에서 이름을 'API 환산' 으로 고쳤다. 안 나간 돈을 나간 것처럼 읽히기 때문이다.
"한 과제당 Sonnet 이 토큰을 덜 쓰는가" 라는 질문에는 둘로 갈라야 답이 된다.
- 토큰: Sonnet 이 약 28% 더 썼다. 덜 들지 않았다.
- API 환산 비용: Sonnet 이 약 30% 쌌다. 단가가 낮아서다.
토큰 효율과 비용 효율이 반대 방향이었다. 하나만 보면 반대 결론이 나온다.
성공률은 동률이다. 둘 다 5/5 에 매번 6점을 받았다. 그래서 "화면 인식 향상이 CLI 로 오는가" 는 이 과제로는 판정할 수 없다. 둘 다 만점이라 천장에 닿았다. 만점이 나오는 시험은 두뇌를 가리지 못한다. 더 어려운 과제가 필요하다.
남은 편향도 하나 있다. 입력의 대부분은 캐시 토큰이다. 번갈아 돌렸으니 두 모델은 서로의 캐시를 쓰지 못한다. 양쪽에 똑같이 작용했다고 보지만, 확인하지는 않았다.
에이전트의 기본 두뇌는 Sonnet 5.5 로 바꿨다. 근거는 성공률 동률, API 환산 30% 절감, 속도 차이가 작다는 것 세 가지다. 실패하면 Opus 5.5 로 한 번 다시 시도한다. 두 경로가 같은 화면을 동시에 만지면 엉키므로 재시도는 순차로만 한다. "모델이 못 했다고 말한 것" 은 실패로 세지 않는다. 그건 정직한 보고다.
6. 삽질 여섯 건, 원인은 하나
이날 걸린 곳을 다 적는다.
- 화면 캡처 경로가
/screenshot인 줄 알았다. 실제로는/screen이었다. 게다가 JSON 이 아니라 PNG 바이너리를 그대로 줬다. - 키 입력 필드 이름을
key로 짐작했다. 실제로는combo였다. D 조 1회차가 이것 때문에 통째로 실패했다. - 툴셋 항목에
name을 넣었다 (벽 1). - 툴셋 항목에 화면 크기를 넣었다 (벽 2).
- 동작을
input.action에서 찾았다 (벽 5). - 동작 이름을
click으로만 받았다. 툴셋은left_click을 불렀다.
작업 기록에는 그날 이렇게 적혀 있다.
"공통 원인 하나: 붙일 곳의 실제 규격을 확인하지 않고 짐작했다."
다음 판을 시작할 때 맨 먼저 한 일은 붙일 곳을 실측하는 것이었다. 엔드포인트 목록과 필드 이름을 코드에서 뽑고, 엔드포인트마다 한 번씩 찔러 응답이 JSON 인지 바이너리인지 눈으로 봤다. 5분이면 끝나는 일이었다.
공식 문서가 말하는 것 (우리 실측과 별개)
위의 숫자는 전부 우리 과제 하나에서 나온 것이다. 모델의 일반 성능을 말하지 않는다. Anthropic 의 공식 문서 What's new in Claude Sonnet 5.5 에서 이 글과 관련된 내용만 옮긴다.
- Claude API 에서 Sonnet 5.5 는 예전 도구
computer_20251124를 받지 않고,computer_toolset_20260801만 받는다. 예전 도구를 넣으면'claude-sonnet-5-5' does not support tool types: computer_20251124.오류가 난다. - 옮겨 가는 방법: 베타 헤더를 빼고
{"type": "computer_toolset_20260801"}을 쓴다. 루프를 멤버tool_use블록에 맞게 고친다. 결과에toolset_name을 싣는다. - Amazon Bedrock 에서는 예전 도구가 아직 받아진다.
- 토크나이저와 가격은 Sonnet 5 와 같다.
이 문서에는 벤치마크 점수가 실려 있지 않다. 그래서 이 글은 공식 벤치마크를 인용하지 않는다.
이 글이 확인하지 못한 것
- 조마다 3회, A/B 는 5회다. 점수 차이로 우열을 말하기에는 표본이 작다. 이 표본으로 분명히 보인 것은 구조적 차이(눈의 범위, 입력 토큰의 자릿수)뿐이다.
- E 조의 달러는 가정한 단가로 계산했다. 실제 청구서와 대조하지 않았다.
- C 조와 C+D 조는 눈이 같아도 연결 코드가 달랐다. C 에는 메모를 쓰는 별도 경로가 있었다. 눈만 다른 비교가 아니다. 결론(눈의 범위)은 C+D 의 자기 보고로 따로 확인했다.
- Sonnet 5.5 의 화면 인식이 CLI 에서 나아졌는지는 판정하지 못했다.
English summary
On September 29, 2026 we attached Claude Sonnet 5.5's computer-use toolset to a small Mac automation agent and ran the same six-point task across four setups (three runs each). Wiring the new computer_toolset_20260801 hit five schema walls: no name on the toolset entry, no display size, toolset_name required on member results but forbidden on others, and the action arriving in tool_use.name rather than input.action. The API runs did not finish, and that was our harness's fault: action-name mismatches and a 40-step cap. Their token counts were still telling. One run used 544,854 input tokens against 3,341 output, because screenshots are resent every step. A DOM-text reader got the same page in 1,842 characters and 27 ms. The two "eyes" differ in reach, not quality. Text sees only inside the browser and cannot check results elsewhere. Screenshots see everything but get blocked by dialogs and are useless on a locked screen. So we now expose both. In a 5-vs-5 A/B over the subscription CLI, Opus 5.5 and Sonnet 5.5 both scored 5/5. Sonnet used about 28% more tokens but cost about 30% less in API-equivalent dollars, which were not actually billed. The task hit its ceiling, so it cannot show whether Sonnet's screen understanding improved. No run fabricated an answer. All six mistakes had one root cause: we guessed the interface instead of reading it first. Figures here are our own measurements and are kept separate from Anthropic's documentation, which lists no benchmark scores.
