1편은 radarlog.kr에서 볼 수 있다. 더 많은 글은 radarlog.kr에서.
Claude Computer Use는 AI가 스크린샷으로 화면을 보고 마우스와 키보드를 조작하는 도구다. 1편에서 에이전트 루프, 좌표 스케일링, 토큰 비용 구조를 이론적으로 정리했다. 깔끔하게 정리해놓고 마지막에 이렇게 썼다.
"다음 글에서는 직접 해본다."
해봤다. 텔레그램으로 "안녕" 한마디 보내는 데 $3이 나갔다.
명령 하나, 삽질은 Claude 몫
Claude Code에서 Computer Use 기능을 켜고, "텔레그램으로 안녕 보내줘"라고 명령했다. Computer Use는 MCP가 아니라 Claude Code에 내장된 기능이다. 설정에서 토글을 켜면 바로 쓸 수 있다. claude mcp add로 추가하는 게 아니다.
여기서부터 나는 지켜보기만 한다. 명령 한 줄 뒤로는 키보드에 손을 댄 적이 없다.
Claude가 제일 먼저 한 건 Telegram 접근 권한 요청이었다. macOS가 접근성 권한 대화상자를 띄우고, 허용을 누르면 끝이라고 생각했다. 아니었다. 클릭할 때마다 권한 경고가 뜨고, 경고가 뜨면 Telegram이 포커스를 잃고, 포커스를 잃으면 다음 클릭도 실패한다. Claude가 무한루프에 빠졌다. 결국 Claude가 나한테 "접근성 권한을 수동으로 추가해달라"고 요청했고, 그게 이 글에서 내가 직접 손을 댄 유일한 순간이다. macOS 접근성 권한은 앱 단위가 아니라 프로세스 단위라서 이런 일이 생긴다.
권한을 해결하고 나서도 진짜 문제가 시작됐다. Claude가 Telegram 입력란을 클릭하려는데 좌표가 계속 밀렸다. 1편에서 다뤘던 좌표 스케일링 문제가 여기서 터진 거다. 입력란이 화면 하단에 있고 바로 아래가 Dock이라, 몇 픽셀만 밀려도 Dock을 클릭한다. Claude가 좌표를 바꿔가며 15번 클릭했고, zoom으로 확대도 해봤고, type 도구로 직접 타이핑도 시도했다. 전부 실패.
20번째쯤 실패한 뒤, Claude가 스스로 접근을 바꿨다. **"클릭 대신 Bash에서 AppleScript를 쓰겠다"**는 판단을 내가 힌트를 준 게 아니라 Claude가 자기 혼자 내렸다. AppleScript는 macOS 네이티브 자동화 도구로, 포커스 상태와 무관하게 프로세스에 직접 키 이벤트를 보낼 수 있다. Claude가 작성하고 실행한 코드는 이거다.
tell application "Telegram" to activate
delay 1
set the clipboard to "안녕"
tell application "System Events"
tell process "Telegram"
keystroke "v" using command down
delay 0.5
key code 36
end tell
end tell한 방에 됐다. 다만 한글을 keystroke로 직접 보내면 "aa"가 입력되는 문제가 있었는데, Claude가 이것도 스스로 진단하고 클립보드 경유 방식으로 전환했다. 한글 조합 중간에 키코드가 끊기기 때문이고, 클립보드에 완성된 문자열을 넣고 Cmd+V로 붙여넣으면 문제가 없다.
두 번째 시도에서는 딥링크로 채팅방을 여는데 radarbot이라는 도메인이 스페인 레이더 봇에 점유돼 있어서 엉뚱한 봇이 열렸다. Claude가 BotFather에서 정확한 username(@YRadar_bot)을 찾아낸 뒤에야 올바른 봇으로 연결됐다.
내가 한 건 "텔레그램으로 안녕 보내줘"뿐이다. 접근성 권한 무한루프, 좌표 오차 15번 재시도, AppleScript 우회 발견, 한글 입력 깨짐 진단, 클립보드 경유 해결, 딥링크 잘못 열림까지 — 전부 Claude가 자율적으로 수행했다.
스크린샷이 지나가는데 잘 되고 있는 건가
Computer Use가 동작하는 동안 화면에는 스크린샷이 계속 찍힌다. Claude가 매 턴마다 스크린샷을 캡처하고 분석하니까, 내 화면에서 Telegram 창이 열리고, 뭔가 클릭되고, 또 스크린샷이 찍히는 게 실시간으로 보인다.
근데 이게 잘 되고 있는 건지 아닌지 알 수가 없다.
스크린샷이 찍히면 "아 뭔가 하고 있구나"는 알겠는데, 클릭이 성공한 건지 실패한 건지는 다음 스크린샷이 올 때까지 모른다. 화면이 바뀌지 않았으면 실패한 거고, 바뀌었으면 성공한 건데 — 그걸 판단하는 것도 Claude가 하는 거지 내가 하는 게 아니다. 나는 그냥 스크린샷이 줄줄이 지나가는 걸 쳐다보고 있을 뿐이다.
게임으로 치면 리플레이를 보는 느낌이다. 내가 조작하는 게 아니라 다른 사람(AI)이 플레이하는 걸 구경하는 거다. 근데 리플레이는 결과를 아니까 편하게 보는데, 이건 결과를 모르니까 묘하게 불안하다. "지금 Dock 클릭한 거 아냐?" 싶은 순간에도 개입할 수 없다. Claude가 알아서 다음 시도를 한다.
중간에 스크린샷이 10초 넘게 안 올 때도 있다. Claude가 thinking 중인 건지, API 레이턴시인 건지, 아니면 뭔가 잘못된 건지 알 수 없다. 진행 표시기 같은 게 없으니까 그냥 기다린다. "명령하고 기다리기"가 Computer Use의 실제 사용 경험이다. 컨트롤이 내 손에 없다는 게 편하기도 하고 불안하기도 하다.
해상도를 바꿨으면 달랐을까
1편에서 좌표 스케일링을 다룰 때 빠뜨린 게 있다. Anthropic이 추천하는 해상도가 있다.
일반 데스크톱: 1024x768 또는 1280x720
웹 앱: 1280x800 또는 1366x768
1920x1080 초과는 성능 저하 우려가 있고, API가 이미지를 최대 1568px로 리사이즈하니까 그 이상은 의미가 없다. 내 맥 해상도가 얼마였는지 정확히 확인하지 않았지만, Retina 디스플레이라면 논리 해상도가 아니라 물리 해상도 기준으로 리사이즈가 일어날 수 있다.
이번에 Telegram 입력란 클릭이 실패한 핵심 원인이 좌표 스케일링 오차였으니, 해상도를 1024x768로 낮췄으면 리사이즈 자체가 안 일어나고 좌표 정확도가 올라갔을 가능성이 높다. 리사이즈 없이 원본 이미지를 그대로 분석하면 좌표가 밀릴 이유가 없다. 15번이나 클릭을 반복하는 대신 한두 번 만에 성공했을 수 있다.
게임에서 렌더 해상도를 낮추면 프레임이 올라가는 것처럼, Computer Use도 해상도를 낮추면 정확도가 올라간다. 토큰 비용도 줄어든다. 1편에서 스크린샷당 ~1,600토큰이라고 했는데, 이건 1024x768 기준이다. 해상도가 높으면 리사이즈 전에 이미지가 더 크고 처리도 느려진다.
다음에 Computer Use를 쓸 때는 가상 디스플레이 해상도를 1024x768로 세팅하고 시작할 거다. 이번 삽질의 가장 큰 교훈이 "좌표 정확도가 모든 걸 결정한다"였으니까, 해상도 세팅이 첫 번째로 할 일이다.
$3짜리 "안녕" — 비용 해부
첫 번째 시도에서 Claude가 "안녕" 두 글자를 보내는 데 발생한 도구 호출은 총 ~63회다. 스크린샷 약 20회, 클릭 시도 약 15회, 키보드 입력 시도 약 8회, AppleScript 실행 약 5회, 나머지 wait/zoom 등이 약 12회.
$100 Max 플랜에서 사용량이 **29%에서 32%**로 올라갔다. 3%다. $100의 3%는 $3.
두 번째 시도에서 Claude는 처음부터 딥링크 + AppleScript로 갔다. 1차에서 학습한 거다. 핵심 도구 호출만 치면 3~4회면 끝났을 건데, 딥링크 잘못 열림 + 입력란 클릭 재시도로 결국 또 20회 넘게 쌓였다.
효율적으로 했으면 $0.30. 실제로는 $3. 10배 차이.
1편에서 계산한 이론적 비용은 8회차 루프 기준 $0.375~0.625였다. 실전에서는 실패한 시도가 비용을 지배한다. 성공하는 액션은 싸다. 실패하고 재시도하는 루프가 비싸다. 특히 스크린샷이 비싸다 — 매번 이미지를 비전 모델에 넣으니까 토큰이 대량으로 들어간다. 해상도를 낮췄으면 클릭 실패가 줄었을 거고, 그러면 재시도 스크린샷도 줄었을 거고, 비용도 $0.30에 가까워졌을 거다.
교훈 — 이론과 실전 사이
1편에서 정리한 에이전트 루프는 이론적으로 맞다. 스크린샷 찍고, 분석하고, 액션하고, 다시 스크린샷 찍는다. 깔끔하다.
실전은 깔끔하지 않다.
macOS 접근성 권한이 프로세스 단위로 걸린다는 건 문서에 안 나와 있다. Telegram 입력란이 Dock과 몇 픽셀 차이라는 건 해봐야 안다. 한글 keystroke가 "aa"로 변한다는 건 삽질해봐야 안다. 추천 해상도를 미리 세팅했으면 좌표 문제의 절반은 안 생겼을 거다. 이 네 가지는 전부 Anthropic의 공식 문서만 읽어서는 알 수 없는 실전 지식이다.
1편에서 "Computer Use는 QA 어시스턴트지, QA 대체제가 아니다"라고 썼다. 실전에서 느낀 건 조금 다르다. Computer Use는 UI 조작 도구지, UI 조작만으로는 부족하다. 진짜 힘은 Bash, AppleScript, 딥링크 같은 OS 네이티브 도구와 결합할 때 나온다.
1편을 쓸 때 나는 에이전트 루프가 깔끔하게 돌아가는 세상을 상상했다. 그 세상은 아직 안 왔다. 좌표는 밀리고, 클릭은 Dock에 가고, 포커스는 날아간다. 그래도 이번 실험에서 인상적이었던 건 Claude의 자율적 문제 해결 과정이다. 나는 "텔레그램으로 안녕 보내줘" 한 마디만 했다. 클릭이 안 먹으면 좌표를 바꿔보고, 그래도 안 되면 zoom으로 확대해보고, 그것마저 안 되면 Bash에서 AppleScript를 꺼내는 — 이 전체 디버깅을 Claude가 혼자 수행했다. 실패할 때마다 추론하고 대안을 찾는 모습이, 마치 주니어 개발자가 삽질하면서 성장하는 과정을 압축해서 보는 것 같았다.
그리고 그 과정을 지켜보는 동안 내 화면에는 스크린샷만 줄줄이 지나갔다. 잘 되고 있는 건지 아닌 건지도 모르면서.
"AI한테 눈(스크린샷)을 주는 것보다, 손(OS 네이티브 API)을 주는 게 더 강하다."