macOS에서 computer-use 에이전트가 '성공'을 반환해도 아무 일도 일어나지 않는 이유

Claude Code나 Cursor, Codex에 computer-use 관련 MCP 서버를 연결하고 "이 버튼을 눌러라"고 요청합니다. 툴 호출은 "ok"로 돌아오지만 화면은 아무것도 움직이지 않습니다. 혹은 모델이 보는 스크린샷이 그저 배경화면일 뿐입니다.

경험상, 원인의 대부분은 모델이나 MCP 서버가 아니라 macOS의 개인 정보 권한(TCC)에 있습니다. 게다가 실패하는 경우 대부분이 오류를 내지 않고 조용히 발생합니다. 가장 먼저 알아야 할 체크리스트를 정리했습니다.

두 가지 권한, 두 종류의 실패

화면을 조작하는 에이전트에는 "시스템 설정 > 개인 정보 보호 및 보안"에서 별개의 두 가지 허가가 필요합니다.

접근성(Accessibility): 다른 앱의 UI 트리(버튼, 입력란, 레이블)를 읽고 합성된 마우스/키보드 이벤트를 전송하기 위한 권한입니다.

• 이것이 없으면 Accessibility API 호출은 kAXErrorAPIDisabled (-25211)로 실패합니다. 많은 툴들이 이를 무시하고 빈 요소 리스트를 반환합니다. - CGEventPost로 보낸 이벤트는 오류 없이 버려집니다. 클릭은 "성공"하지만 아무 일도 일어나지 않습니다.

스크린 기록(Screen Recording): 다른 앱의 픽셀을 캡처하기 위한 권한입니다.

• 이것이 없으면, 캡처에는 데스크톱과 메뉴바는 찍히지만, 다른 앱의 창 내용은 찍히지 않는 것이 일반적입니다. 비전 모델은 빈 데스크톱을 자신만만하게 설명합니다. - 놓치기 쉬운 점: 타 앱의 창 제목(CGWindowListCopyWindowInfo의 kCGWindowName)도 가져올 수 없게 됩니다. 스크린샷을 한 번도 찍지 않아도 "Invoice라는 창을 찾는다"가 실패합니다.

요소는 가져올 수 있는데 스크린샷이 비어 있다면 스크린 기록 권한이 부족한 것이고, 모든 것이 보이지만 클릭이 작동하지 않는다면 접근성 권한이 부족하다고 구분할 수 있습니다.

허가가 필요한 것은 대부분 에이전트를 실행하는 앱

여기서 반나절을 낭비하는 사람이 많습니다. macOS는 권한 요청을 "책임 있는(responsible)" 앱에 귀속시킵니다. 커맨드라인 툴의 경우, 그것은 바이너리 자체라기보다는 실행시킨 GUI 앱인 경우가 대부분입니다.

• Terminal이나 iTerm 상에서 Claude Code가 MCP 서버를 시작했을 경우: Terminal (또는 iTerm)의 허가가 적용됩니다.
• Cursor, VS Code, 데스크톱 채팅 클라이언트가 시작된 경우: 해당 앱의 허가가 적용됩니다.
• launchd (LaunchAgent)에서 시작한 경우: 프로세스 자체가 책임 주체이므로, ProgramArguments에 적은 바이너리 자체에 허가가 필요합니다.

즉, "node에 접근성을 부여했는데 작동하지 않는다"는 흔한 이야기이며, node는 애초에 책임 주체가 아닙니다. 호스트 측 앱에 허가를 주고, 창을 닫을 뿐만 아니라 완전히 종료한 후 다시 열어야 합니다. 실행 중인 프로세스는 권한 변경을 감지하지 못합니다.

반대편도 적어두겠습니다. Terminal에 접근성을 부여하면, Terminal에서 실행하는 모든 것이 Mac을 조작할 수 있게 됩니다. 신경 쓰인다면, 에이전트 전용 터미널 앱을 하나 준비해서 거기서 실행하는 것이 안전합니다.

에이전트가 실제로 가지고 있는 권한 확인하기

에이전트를 시작하는 것과 같은 앱에서 실행하십시오 (동일한 responsible 프로세스를 상속받기 위함).

cat > /tmp/tcc-check.swift <<'SWIFT'
import ApplicationServices
import CoreGraphics
...

두 함수 모두 확인만 할 뿐 대화 상자를 띄우지 않습니다. 둘 중 하나라도 false라면 "아무 일도 일어나지 않는다"는 보고의 대부분은 이것으로 설명이 됩니다 (swift에는 Xcode Command Line Tools가 필요합니다).

에이전트가 조작하려고 하는 도중에 macOS가 어떻게 판단했는지 실시간으로 보려면:

log stream --debug --predicate 'subsystem == "com.apple.TCC"'

TCC가 어떤 프로세스를 평가하고 허용했는지 로그에 나오기 때문에, '책임 주체는 무엇인지'를 추측할 필요 없이 확정할 수 있습니다.

토글은 켜져 있는데도 실패하는 경우

자주 발생하는 원인은 세 가지입니다.

• 바이너리가 변경되었다. 허용은 코드 서명에 연결됩니다. 애드호크(ad-hoc) 서명의 바이너리라면 정확한 해시와 연결되므로, 재빌드나 패키지 매니저의 업그레이드로 바이너리가 대체될 때마다 설정 화면의 스위치는 '켜짐' 상태를 유지하지만 허용만 무효화됩니다. 대처 방법: 마이너스 버튼으로 항목을 삭제했다가 다시 추가하거나, 직접 만든 도구를 고정된 ID로 서명합니다(무료 Apple Development 인증서로 충분합니다). - 오래된 항목이 남아있다. 하나의 앱의 하나의 서비스만 리셋하고 다시 확인하도록 요청합니다. tccutil reset Accessibility com.apple.Terminal tccutil reset ScreenCapture com.apple.Terminal

에이전트를 호스팅하는 앱의 번들 ID로 교체해 주세요.

• 시스템 다이얼로그가 대기 중이다. 최근 macOS는 일부 앱에 대해 화면 접근 재확인을 주기적으로 요청합니다. 무인 에이전트는 이 다이얼로그에 응답할 수 없습니다. 몇 주 동안 작동했는데 갑자기 캡처가 새하얗게 되었다면, 먼저 화면에 확인 다이얼로그가 떠 있는지 확인해 보세요.

모델을 의심하기 전의 짧은 사전 점검(Pre-flight)

• 에이전트를 시작하는 앱은 무엇인가? 그 앱에 두 가지 허용 모두가 필요함
• 허용한 후, 그 앱을 완전히 종료했다가 다시 실행한다
• 해당 앱에서 Swift 체크를 실행: 둘 다
  true

할 수 있는가? - 스크린샷이 비어있음 → 화면 기록. 클릭이 무시됨 → 접근성

• 업데이트 후 토글은 켜져 있는데 실패함 → 항목을 삭제했다가 다시 추가한다

이것을 작성한 이유

우리는 Auten을 만들고 있습니다. Claude Code, Codex, Cursor 등 임의의 MCP 클라이언트에 실제 화면을 조작하는 '손'을 제공하는 MCP 서버입니다. 대상은 사용자의 컴퓨터(Mac/Windows/Linux)와 Android 스마트폰(베타)입니다. macOS에서는 설치 프로그램이 권한 설정 절차를 수행하고, auten status로 무엇이 연결되었고 무엇이 부족한지 표시합니다. 사소한 권한 오류는 저희 스스로가 처음 부딪혔던 지점이었기 때문입니다 (UI는 현재 영어만 지원합니다).

여기에 실리지 않은 TCC 케이스에 해당한다면, 댓글로 알려주세요. 모으고 있습니다.

토론(Discussion)