더 많은 글은 radarlog.kr에서.
어제(3월 23일) Anthropic이 Claude Computer Use를 리서치 프리뷰로 풀었다. macOS 전용, Pro/Max 구독자 한정. Claude가 내 맥에서 앱을 열고, 브라우저를 조작하고, 스프레드시트를 채운다.
솔직히 처음 데모 영상을 봤을 때 든 생각은 하나였다. "이거 오픈클로 아닌가?"
맞다. 비슷하다. 근데 결정적으로 다르다.
AI가 컴퓨터를 "쓴다"는 게 뭔 소리인가
Computer Use Tool의 핵심은 단순하다. Claude가 스크린샷을 찍어서 화면을 보고, 마우스와 키보드를 조작해서 작업을 수행한다. API로 직접 연동할 수 없는 앱이 있으면, 사람이 하듯이 화면을 보고 클릭한다.
게임 개발자라면 바로 와닿을 거다. QA 자동화 테스트에서 스크린캡처 → 이미지 매칭 → 입력 시뮬레이션 하는 그 흐름이랑 똑같다. Appium이나 Sikuli 같은 UI 테스트 프레임워크의 구조를 LLM이 대체한 셈이다. 다만 이미지 매칭 대신 비전 모델이 화면을 "이해"하고, 하드코딩된 시나리오 대신 자연어 명령으로 동작한다는 점이 다르다.
구체적으로 어떤 액션이 가능한지 보면, 기본적으로 screenshot, left_click, type, key, mouse_move가 있다. 여기에 Claude 4.x 모델부터는 scroll, right_click, double_click, triple_click, left_click_drag, hold_key, wait 같은 세밀한 조작이 추가됐다. Opus 4.6에서는 zoom까지 된다. 화면의 특정 영역을 풀 해상도로 확대해서 보는 기능인데, 작은 UI 요소를 정확히 인식하기 위한 장치다.
UE5에서 Slate 위젯 디버깅할 때 특정 픽셀 영역을 확대해서 보는 것처럼, AI도 "여기 뭐라고 써있지?" 싶으면 줌인해서 확인한다는 거다.
에이전트 루프 — 핵심 구조
Computer Use의 진짜 핵심은 개별 액션이 아니라 에이전트 루프다. 이 구조를 이해해야 한다.
흐름은 이렇다. 사용자가 "고양이 사진을 바탕화면에 저장해줘"라고 요청한다. Claude가 "screenshot 찍겠다"고 응답한다. 개발자의 애플리케이션이 실제로 스크린샷을 찍어서 결과를 돌려준다. Claude가 화면을 분석하고 "브라우저를 클릭하겠다"고 응답한다. 다시 애플리케이션이 실행하고 결과를 돌려준다.
이걸 Claude가 "작업 끝났다"고 판단할 때까지 반복한다.
# 에이전트 루프의 골격
while iterations < max_iterations:
response = client.beta.messages.create(
model=model,
tools=tools,
messages=messages,
)
tool_results = []
for block in response.content:
if block.type == "tool_use":
result = run_tool(block.name, block.input)
tool_results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": result
})
if not tool_results:
break # 도구 호출 없음 = 작업 완료
messages.append({"role": "user", "content": tool_results})게임 서버의 틱 루프랑 구조가 닮았다. 매 틱마다 상태를 확인하고, 판단하고, 액션을 실행하고, 다시 상태를 확인한다. 다만 게임 루프는 16ms마다 도는데, 이건 스크린샷 캡처 + API 호출 + 비전 분석이 매 턴마다 들어가니까 체감 레이턴시가 꽤 크다. Anthropic도 공식 문서에서 "속도가 중요하지 않은 유스케이스에 집중하라"고 권장한다.
중요한 건, Claude가 직접 컴퓨터에 접속하는 게 아니라는 점이다. 개발자가 중간에서 Claude의 요청을 받아서 실제 환경에 실행하고, 결과를 다시 Claude에 돌려주는 구조다. Claude는 "left_click at (512, 384)"라고 말할 뿐, 실제 클릭은 개발자의 코드가 한다.
이 구조 덕분에 샌드박스 안에서 안전하게 돌릴 수 있다. Docker 컨테이너 안에 가상 디스플레이(Xvfb)를 띄우고, 그 위에서 Claude가 작업하게 하면 호스트 시스템은 건드리지 않는다.
좌표 스케일링 — 은근히 까다로운 문제
실제로 구현할 때 가장 먼저 부딪히는 문제가 좌표 스케일링이다. API가 이미지를 최대 1568px(긴 변 기준)로 리사이즈한다. 1512x982 화면을 보내면 대략 1330x864로 줄어든다. Claude는 줄어든 이미지를 보고 좌표를 반환하는데, 실제 클릭은 원본 해상도에서 해야 한다.
import math
def get_scale_factor(width, height):
long_edge = max(width, height)
total_pixels = width * height
long_edge_scale = 1568 / long_edge
total_pixels_scale = math.sqrt(1_150_000 / total_pixels)
return min(1.0, long_edge_scale, total_pixels_scale)
scale = get_scale_factor(screen_width, screen_height)
# Claude가 반환한 좌표를 원본 해상도로 역변환
def execute_click(x, y):
screen_x = x / scale
screen_y = y / scale
perform_click(screen_x, screen_y)UE5에서 UI 좌표를 다룰 때 DPI 스케일링 때문에 논리 좌표와 물리 좌표가 다른 것과 같은 문제다. Retina 디스플레이에서 Slate 위젯 위치를 잘못 계산해서 클릭이 엉뚱한 곳에 가는 버그, 한 번씩은 겪어봤을 거다. 똑같은 일이 AI한테도 일어난다.
이걸 안 처리하면 Claude가 버튼을 클릭한다고 했는데 실제로는 옆에 있는 다른 버튼이 눌린다. 스케일 팩터를 직접 계산해서 역변환을 해줘야 정확하게 동작한다.
오픈클로 vs Claude Computer Use — 뭐가 다른가
둘 다 "AI가 컴퓨터를 조작한다"는 건 같다. 근데 설계 철학이 완전히 다르다.
오픈클로는 범용 에이전트 플랫폼이다. 오스트리아 개발자 Peter Steinberger가 2025년 11월에 만든 오픈소스 프로젝트로, 처음엔 "Clawdbot"이라는 이름이었다가 Anthropic 상표 문제로 Moltbot → OpenClaw로 두 번 이름을 바꿨다. GitHub 스타 20만 개를 넘기면서 역대급 속도로 성장했다. LLM을 자체 내장한 게 아니라 Claude, GPT, Gemini, 로컬 LLM 등 아무 모델이나 갖다 붙일 수 있는 모델 비종속적 구조다. WhatsApp, Telegram, Discord 같은 메신저로 명령을 내리면 컴퓨터에서 알아서 작업한다.
Claude Computer Use는 API 도구다. Claude 모델 전용이고, Anthropic의 Messages API 안에서 동작한다. 도구 정의를 넣으면 Claude가 "이 액션을 실행해달라"고 요청하는 구조다. 개발자가 에이전트 루프를 직접 구현해야 한다.
가장 큰 차이는 누가 환경을 제어하느냐다. 오픈클로는 사용자의 로컬 머신에 직접 설치돼서 파일을 읽고 쓰고, 셸 커맨드를 실행한다. 편하지만 그만큼 위험하다. API 키를 평문으로 저장하다가 보안 취약점(CVE-2026-25253)이 터졌고, 인포스틸러가 오픈클로 설정을 통째로 탈취하는 사례도 나왔다. 네이버, 카카오, 배달의민족이 사내 사용을 금지한 이유가 여기 있다. 네덜란드 데이터 보호 당국은 민감한 데이터를 다루는 시스템에 오픈클로 같은 실험적 에이전트를 배포하지 말라고 경고까지 했다.
Claude Computer Use는 Docker 컨테이너나 VM 안에서 격리된 환경을 전제로 설계됐다. Claude가 직접 호스트에 접근하는 게 아니라, 개발자가 중간에서 모든 액션을 중계한다. 프롬프트 인젝션 탐지 분류기가 스크린샷마다 자동으로 돌아가서, 의심스러운 지시가 감지되면 사용자 확인을 먼저 요청한다.
쉽게 비유하면 이렇다. 오픈클로는 친구한테 내 컴퓨터 비번을 알려주고 알아서 하라고 맡기는 것이고, Claude Computer Use는 격리된 방에서 CCTV로 화면만 보여주고 "여기 클릭해줘"라고 지시하는 것이다. 자유도는 오픈클로가 높지만, 보안은 비교가 안 된다.
그리고 하나 더. 오픈클로가 메신저 연동, 자율 스케줄링, Skills 마켓플레이스(ClawHub) 같은 "생활 밀착형" 기능에 집중한다면, Claude Computer Use는 개발자가 자기 제품에 데스크톱 자동화를 내장하는 빌딩 블록에 가깝다. 오픈클로는 완제품, Computer Use는 부품이다.
macOS 전용 — 윈도우는 아직이다
Cowork와 Claude Code에서 제공되는 Computer Use 리서치 프리뷰는 macOS에서만 된다. 윈도우도 안 되고 리눅스도 안 된다. macOS 데스크톱 앱이 실행 중이어야 하고, 모바일에서 Dispatch로 작업을 지시할 수는 있지만 실제 컴퓨터 제어는 맥에서 일어난다.
Anthropic이 왜 맥부터 시작했는지는 공식적으로 밝히지 않았지만 추측은 어렵지 않다. macOS는 접근성 API가 잘 정리돼 있고, Apple Silicon의 통합 메모리 아키텍처가 비전 처리에 유리하다. 그리고 솔직히 말하면, 오픈클로가 이미 증명했듯이 맥 유저가 이런 도구에 대한 수요가 가장 높다. 오픈클로 커뮤니티에서도 "맥미니 M4에 설치해서 24시간 돌린다"는 후기가 주류였다. 애플 실리콘의 전력 효율과 소음 때문에 항시 구동 머신으로 맥 외에는 현실적 대안이 없다는 분석도 많았다.
게임 개발자 입장에서는 좀 아쉽다. UE5 개발 환경은 대부분 윈도우고, 자동화 테스트나 빌드 파이프라인도 윈도우 서버에서 돌아간다. Claude Computer Use를 빌드 자동화에 붙이고 싶어도 당장은 못 쓴다. API 레벨의 Computer Use Tool은 플랫폼 제약이 없다. Docker 안에 리눅스 환경을 올리고 거기서 돌리면 되니까. 제약이 있는 건 Cowork/Claude Code의 "내 컴퓨터를 직접 제어" 기능 한정이다.
Anthropic은 "초기 사용 피드백을 모은 뒤 플랫폼 지원을 확대할 계획"이라고 했으니, 윈도우 지원은 시간 문제일 거다.
그래서 토큰이 얼마나 나가는가
Computer Use가 비싼 이유는 개별 액션이 아니라 누적 구조 때문이다. 에이전트 루프가 돌 때마다 이전 대화 전체가 context로 다시 들어간다. 루프 1회차에는 스크린샷 1장이지만, 8회차에는 스크린샷 8장 + 이전 응답 7개가 전부 입력 토큰에 쌓인다.
먼저 고정 비용을 보자. 매 API 호출마다 시스템 프롬프트 오버헤드 ~499토큰, 도구 정의(computer 735토큰 + bash/editor 각 ~200토큰)가 깔린다. 여기에 스크린샷이 장당 ~1,600토큰이다. 1024x768 해상도 기준으로, 비전 문서에서 공식적으로 약 1,600토큰이라고 명시하고 있다.
이걸 구체적으로 계산해보면 이렇다.
루프 1회차 입력:
시스템 프롬프트 499 토큰
도구 정의 (3개) 1,135 토큰
사용자 메시지 ~100 토큰
스크린샷 1장 1,600 토큰
────────────────────────
합계 ~3,334 토큰
루프 1회차 출력:
thinking 1,024 토큰 (최소값)
액션 응답 ~150 토큰
────────────────────────
합계 ~1,174 토큰
여기까지는 별거 아닌 것 같다. 근데 문제는 루프가 쌓이면서 생긴다.
루프 8회차 입력:
시스템 프롬프트 499 토큰
도구 정의 (3개) 1,135 토큰
사용자 메시지 ~100 토큰
스크린샷 8장 12,800 토큰 ← 여기가 핵심
이전 응답 7개 ~1,400 토큰
tool_result 7개 ~350 토큰
────────────────────────
합계 ~16,284 토큰
8회차 한 턴의 입력만 16K 토큰이다. 1회차부터 8회차까지 누적하면 총 입력 토큰은 약 78,000, 출력은 약 9,400이 된다.
Sonnet 4.6 기준으로 돈을 계산하면, 입력 $3/MTok × 78K = $0.234, 출력 $15/MTok × 9.4K = $0.141. 작업 한 번에 $0.375. "고양이 사진 바탕화면에 저장해줘"가 400원짜리 작업이다.
Opus 4.6으로 바꾸면 입력 $5/MTok, 출력 $25/MTok이라 같은 작업이 $0.625까지 올라간다. 하루 100번 돌리면 월 $1,875. 연간 2,700만원이다.
하지만 최적화할 수 있다. 프롬프트 캐싱을 쓰면 시스템 프롬프트 + 도구 정의 부분(~1,634토큰)이 캐시 히트 시 **기본 가격의 10%**로 떨어진다. 매 턴마다 반복되는 이 고정 비용이 90% 할인되니 효과가 크다. Batch API를 쓸 수 있는 비동기 작업이면 50% 할인까지 적용된다.
게임 개발에서 렌더링 최적화할 때 "매 프레임 반복되는 연산을 캐싱하라"는 원칙이 있다. 똑같은 원칙이 여기서도 적용된다. 매 턴 반복되는 시스템 프롬프트와 도구 정의를 캐싱하고, 가능하면 스크린샷 해상도를 낮춰서 토큰을 아끼는 거다. 1024x768을 800x600으로 줄이면 스크린샷당 토큰이 꽤 줄어든다. 물론 해상도를 낮추면 비전 정확도도 떨어지니까 트레이드오프다. 렌더 해상도 vs 프레임레이트 트레이드오프랑 정확히 같은 구조다.
게임 QA에 쓸 수 있는가 — 되는 것과 안 되는 것
지금 당장 UE5 프로젝트에 Claude Computer Use를 쓸 수 있느냐고 물으면, "API 레벨에서는 가능하다"가 답이다. Docker에 리눅스 + Xvfb + 브라우저를 올리고, Claude한테 "Jira 티켓에서 이번 스프린트 버그 목록을 뽑아서 스프레드시트로 정리해줘" 같은 작업을 시킬 수 있다.
근데 진짜 흥미로운 건 QA 자동화다. 그리고 여기에 명확한 선이 있다.
확실히 되는 것: 기능 QA
기존 UI 자동화 테스트를 생각해보자. XPath나 위젯 ID 기반이라 UI가 바뀌면 테스트 스크립트도 전부 고쳐야 했다. 버튼 하나 옮기면 테스트 10개가 깨진다. Computer Use는 화면을 시각적으로 이해하니까 UI 레이아웃이 바뀌어도 "설정 버튼"을 찾아서 클릭할 수 있다.
구체적으로 이런 시나리오가 가능하다.
시나리오: 메인 메뉴 → 설정 → 그래픽 → 해상도 변경 → 적용
기존 방식 (Selenium/Appium 스타일):
driver.find_element(By.ID, "btn_settings").click()
driver.find_element(By.XPATH, "//div[@class='graphics-tab']").click()
→ UI 리팩터링하면 전부 깨짐
Computer Use 방식:
"메인 메뉴에서 설정 버튼을 찾아 클릭해.
그래픽 탭으로 이동해서 해상도를 1920x1080으로 변경하고 적용해."
→ Claude가 스크린샷을 보고 알아서 찾음
이런 기능 QA는 Computer Use가 잘한다. 메뉴 네비게이션, 설정 변경 후 실제 반영 확인, 로그인/로그아웃 플로우, 상점에서 아이템 구매 후 인벤토리 확인. 핵심은 "A를 하면 B가 되어야 한다"는 명확한 기대값이 있는 테스트다.
여기에 비주얼 리그레션 테스트도 붙일 수 있다. 패치 전후로 같은 씬의 스크린샷을 찍어서 Claude한테 "이 두 스크린샷에서 달라진 점을 찾아줘"라고 시키는 거다. 텍스처가 깨졌다거나, UI 요소가 잘렸다거나, 폰트 렌더링이 바뀐 것 같은 시각적 차이를 잡아낼 수 있다. 기존 픽셀 diff 도구보다 나은 점은, Claude가 "의도적 변경"과 "버그"를 맥락으로 구분할 수 있다는 거다. "배경색이 바뀐 건 디자인 업데이트고, 체력바가 잘린 건 버그 같다"는 식으로.
로컬라이제이션 QA도 좋은 케이스다. 10개 언어 빌드를 각각 띄워서 "모든 메뉴를 순회하면서 텍스트가 잘리거나 깨진 곳을 찾아줘"라고 시키면 된다. 사람이 하면 언어당 2~3시간인데, Claude한테 병렬로 돌리면 시간을 크게 줄일 수 있다.
애매한 영역: 성능 QA
FPS가 30 이하로 떨어지는 구간을 찾는 건 가능할까? 반만 맞다.
Claude가 스크린샷으로 FPS 카운터를 읽을 수는 있다. 디버그 오버레이에 FPS 숫자가 찍혀 있으면 "지금 28fps다"라고 인식한다. 근데 Computer Use의 에이전트 루프는 스크린샷 → 분석 → 액션 → 스크린샷 사이클이 턴당 수 초가 걸린다. 실시간 프레임 드롭을 잡는 건 불가능하다. 0.5초짜리 프레임 스터터링이 스크린샷 사이에 일어나면 놓친다.
대신 이런 식으로는 쓸 수 있다. "맵의 각 구역을 돌아다니면서 FPS 카운터를 읽고, 30fps 이하인 구역을 기록해줘." 느리지만 넓은 영역을 커버하는 탐색형 성능 프로파일링이다. 정밀한 벤치마크는 아니지만, QA팀이 "어디가 느린지 대략적인 히트맵"을 뽑는 용도로는 충분하다.
메모리 누수 같은 장기 테스트도 비슷하다. "게임을 2시간 플레이하면서 30분마다 태스크 매니저의 메모리 사용량을 읽어줘." 사람이 2시간 동안 앉아서 하기 싫은 단순 반복 모니터링을 AI한테 맡기는 거다.
못 하는 것: 게임의 "느낌"
여기서부터가 핵심이다. 게임의 재미를 판단할 수 있는가?
결론부터 말하면, 못 한다. 적어도 지금은.
게임 QA에서 가장 중요하면서도 자동화가 안 되는 영역이 "손맛"이다. 공격 버튼을 눌렀을 때 0.1초 뒤에 히트가 발생하는 것과 0.15초 뒤에 히트가 발생하는 것의 차이. 숫자로 보면 50ms인데, 플레이어는 "뭔가 찝찝하다"고 느낌. 이걸 **게임 필(game feel)**이라고 한다.
Computer Use는 이 미묘한 차이를 판단할 수 없다. 구조적으로 불가능한 이유가 세 가지다.
첫째, 시간 해상도가 부족하다. Computer Use는 스크린샷 기반이다. 턴당 수 초의 사이클 타임에서 50ms의 입력 지연 차이를 감지할 방법이 없다. 60fps 게임에서 3프레임 차이인데, 스크린샷 한 장으로는 절대 포착이 안 된다.
둘째, 체감의 주관성이다. 카메라 쉐이크가 "적당히 박진감 있다"와 "과해서 어지럽다"의 경계는 사람마다 다르다. 히트스탑(히트 시 프레임을 잠깐 멈추는 연출)이 0.05초일 때와 0.08초일 때의 타격감 차이를 Claude한테 물어봤자, Claude는 두 스크린샷이 "거의 같다"고 대답할 수밖에 없다. 실제 플레이어의 손가락 끝에서 느껴지는 피드백 루프를 스크린샷으로 재현할 수 없다.
셋째, 맥락 누적의 한계다. 게임의 재미는 한 순간이 아니라 흐름에서 나온다. 쉬운 구간 → 어려운 구간 → 보상의 리듬. 난이도 커브가 적절한지 판단하려면 30분~1시간을 연속으로 플레이하면서 감정의 변화를 추적해야 한다. Computer Use의 에이전트 루프로 1시간을 돌리면 토큰 비용이 어마어마할 뿐 아니라, Claude가 "지금 지루한지 긴장되는지" 같은 감정 상태를 가지지 않는다.
하지만 완전히 불가능이냐 하면, 우회로가 있다.
Claude가 "재미있다/없다"를 직접 판단하는 건 안 되지만, 재미와 상관관계가 있는 프록시 지표를 수집하는 건 가능하다.
프록시 지표 수집 예시:
"10분 동안 플레이하면서 다음을 기록해줘:
- 같은 구간에서 죽은 횟수
- 죽은 뒤 재시작까지 걸린 시간 (UI 플로우)
- 상점 UI에서 아이템 설명을 읽는 데 걸린 시간
- 스킬 트리에서 되돌아간 횟수"
플레이어가 같은 구간에서 5번 죽으면 난이도 스파이크일 수 있다. 상점에서 아이템 설명을 10초 이상 읽고 있으면 설명이 불친절한 거다. 스킬 트리에서 자꾸 되돌아가면 선택지가 직관적이지 않다는 신호다. Claude가 이런 행동 패턴을 수집하고, "이 구간은 죽는 횟수가 평균 대비 3배다"같은 리포트를 뽑아주면, 판단은 디자이너가 하되 데이터 수집은 AI가 한다.
애니메이션 블렌딩이 매끄러운지도 비슷한 우회로로 접근할 수 있다. Claude한테 "달리다가 멈추는 동작을 반복해서 스크린샷을 5프레임 간격으로 찍고, 캐릭터 포즈가 부자연스럽게 끊기는 순간이 있는지 봐줘"라고 시키면 시각적 아티팩트는 잡을 수 있다. 팔이 몸을 관통한다거나, 발이 바닥에 묻힌다거나. 근데 "이 블렌딩이 느낌이 좋은지"는 여전히 사람이 판단해야 한다.
정리하면 이렇다.
확실히 가능:
기능 QA (메뉴 네비게이션, 설정, 구매 플로우)
비주얼 리그레션 (패치 전후 시각적 차이)
로컬라이제이션 QA (텍스트 잘림, 깨짐)
자동 스크린샷 수집 + 리포트 생성
조건부 가능:
성능 모니터링 (FPS 카운터 읽기 — 실시간은 불가)
프록시 지표 수집 (죽는 횟수, UI 체류시간 등)
시각적 아티팩트 탐지 (관통, 클리핑)
불가능:
게임 필 / 손맛 판단
난이도 밸런스의 "적절함" 판단
연출의 감정적 임팩트 평가
실시간 프레임 드롭 탐지
결국 Computer Use는 QA 어시스턴트지, QA 대체제가 아니다. 사람 QA가 하기 싫은 반복 작업을 빨아들이고, 사람은 "이거 재밌어?"라는 질문에 집중할 수 있게 해주는 도구다. 게임 업계에서 오래된 격언이 있다. "재미는 스프레드시트에 없다." AI가 스프레드시트를 채워주면, 사람은 재미를 찾는 데 시간을 쓸 수 있다.
"AI가 버그를 찾는 시대는 왔다. AI가 재미를 찾는 시대는 아직이다."
다음 글에서는 직접 해본다. 텔레그램으로 Claude Computer Use에 작업을 던져보고, 실제로 토큰이 얼마나 찍히는지, 셋업은 얼마나 걸리는지, 어디서 막히는지를 기록한다. 이론은 여기까지고, 다음은 삽질 로그다.