automationmodetool, Xcode UI 테스트의 Automation Mode 암호 프롬프트 정리

macOS에서 Xcode UI 테스트를 CI로 돌릴 때 가장 난감한 실패는 테스트 코드의 실패가 아니다. 테스트가 시작되기도 전에 시스템이 암호를 요구하는 경우다.

대표적인 로그는 Timed out while enabling automation mode다. 화면이 붙어 있는 Mac에서는 사람이 암호를 입력하면 지나간다. 하지만 self-hosted runner나 랩 장비에서는 그 순간부터 테스트가 아니라 운영 장애가 된다.

이 글은 macOS 26.5.1, Xcode 26.6 환경에서 man automationmodetool을 확인하고, 2026년 7월 1일 기준 공개 문서를 다시 본 뒤 정리했다. 범위는 automationmodetool 하나다. Accessibility, AppleEvents, keychain, signing, DevToolsSecurity는 관련은 있지만 이 글의 주제가 아니다.

이 도구가 해결하는 문제

automationmodetool은 UI 테스트용 Automation Mode 보안 설정을 관리하는 명령이다.

로컬 man page와 Xcode man page는 이 도구의 역할을 거의 같은 문장으로 설명한다. 장비를 설정해서 UI testing용 Automation Mode가 사용자 인증 없이 활성화될 수 있게 만든다. CI 장비나 관리자 권한이 없는 사용자가 쓰는 테스트 랩 장비를 준비할 때 쓰는 도구다.

핵심은 “앱이 Mac을 제어해도 되는가”가 아니다. “이 장비가 UI automation mode에 들어갈 때마다 사람의 암호를 물어야 하는가”다.

확인 명령은 인자 없이 실행한다.

automationmodetool

정상적으로 CI에 맞게 준비된 장비라면 이런 식의 상태를 볼 수 있다.

Automation Mode is disabled.
This device DOES NOT REQUIRE user authentication to enable Automation Mode.

첫 줄의 disabled만 보고 실패로 판단하면 안 된다. 여기서 더 중요한 줄은 두 번째다. DOES NOT REQUIRE user authentication이면 XCTest나 testmanagerd가 테스트 실행 중 Automation Mode를 켤 때 사람의 암호를 요구하지 않아도 되는 상태다.

설정 명령은 다음이다.

sudo automationmodetool enable-automationmode-without-authentication

되돌리는 명령도 있다.

sudo automationmodetool disable-automationmode-without-authentication

이 설정 자체는 관리자 인증이 필요하다. 그래서 아무 PR이나 실행할 수 있는 workflow 안에서 매번 실행할 성격의 명령이 아니다. CI 머신을 준비하는 부트스트랩 단계에서 한 번 처리해야 한다.

TCC 권한과 섞으면 진단이 틀어진다

macOS에서 UI 테스트가 멈추는 보안 프롬프트는 한 종류가 아니다.

Xcode Helper나 테스트 러너가 Accessibility, AppleEvents, Post Event 권한을 요구하는 경우가 있다. 이건 TCC 영역이다. Apple의 PPPC 문서는 Accessibility가 앱이 Accessibility API로 Mac을 제어하도록 허용하고, AppleEvents가 제한된 AppleEvent 전송을 허용하며, Post Event가 CoreGraphics 이벤트 전송을 허용한다고 설명한다.

반면 automationmodetool이 다루는 것은 Automation Mode의 사용자 인증 요구다. TCC 권한을 부여하지 않는다. PPPC 프로파일을 설치하지 않는다. Accessibility 권한을 대신 주지도 않는다.

그래서 아래 두 상황은 다르게 봐야 한다.

Xcode Helper does not have permission to use Accessibility.

이건 TCC/Accessibility 문제다. Privacy & Security 설정이나 MDM으로 배포한 PPPC 프로파일을 봐야 한다.

Timed out while enabling automation mode.

이건 Automation Mode 인증 게이트일 가능성이 높다. 먼저 automationmodetool 상태를 확인해야 한다.

두 문제가 동시에 있을 수도 있다. CI 장비에서 automationmodetool을 설정했는데도 테스트가 계속 멈춘다면, 그 다음에는 TCC 로그로 실제로 막는 프로세스를 확인해야 한다.

log stream --debug --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"'

Apple의 PPPC 문서도 이 로그를 책임 주체 확인용으로 제시한다. 추측으로 Xcode.app이나 앱 under test를 계속 추가하기보다, 실제 attribution chain에 잡히는 프로세스를 봐야 한다.

workflow에 넣을 명령이 아니라 장비 설정이다

automationmodetool의 사용 위치는 workflow 본문이 아니라 runner bootstrap이다.

좋은 위치는 이런 단계다.

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -license accept
sudo xcodebuild -runFirstLaunch
sudo automationmodetool enable-automationmode-without-authentication
automationmodetool

이 흐름은 “이 Mac은 Xcode UI 테스트를 unattended로 돌릴 장비”라고 정하는 단계다. 반대로 아래처럼 PR마다 실행되는 job에 넣으면 문제가 생긴다.

- name: Enable automation mode
  run: sudo automationmodetool enable-automationmode-without-authentication

hosted CI 서비스가 sudo 환경을 이미 제어하고 있고, 그 서비스 문서가 이 방식을 안내한다면 예외가 될 수 있다. Bitrise는 macOS 테스트에서 Timed out while enabling automation mode를 만났을 때 workflow의 Script Step에서 sudo automationmodetool enable-automationmode-without-authentication을 실행하라고 안내한다.

하지만 self-hosted runner라면 판단이 달라진다. workflow가 임의 코드 실행 경로라면 sudo를 열어두는 순간 테스트 안정성 문제가 권한 상승 문제가 된다. 이 경우에는 장비 소유자가 한 번 부트스트랩하고, workflow는 빌드와 테스트만 해야 한다.

GitHub Actions 사례에서 보이는 패턴

GitHub Actions macOS runner 이미지 이슈에서도 Timed out while enabling automation mode는 반복적으로 등장했다.

macOS 12 Monterey 시기의 보고에서는 headless runner에서 UI automation 동의가 필요하지만 상호작용할 사람이 없어서 timeout이 난다고 정리되어 있다. macOS 13과 Xcode 14.3.1 조합에서도 같은 계열의 오류가 보고되었다.

Flutter 인프라 이슈는 다른 관점에서 같은 문제를 보여준다. XCUITest 기반 integration test를 돌리려면 automationmodetool enable-automationmode-without-authentication이 필요하지만, 그 명령 자체가 암호 프롬프트를 요구한다는 점이 운영 문제로 남는다.

여기서 얻을 결론은 단순하다.

CI에서 매번 암호를 넣어 해결하는 구조는 불안정하다. “암호를 자동 입력하는 expect 스크립트”는 문제를 옮길 뿐이다. runner 계정과 장비 상태를 명시적으로 준비하고, 준비가 끝났는지 job 초반에 읽기 전용으로 확인하는 편이 낫다.

- name: Show UI automation state
  run: |
    automationmodetool || true
    xcodebuild -version
    xcode-select -p

이 단계는 설정을 바꾸지 않는다. 실패했을 때 원인을 빨리 좁히기 위한 관찰값만 남긴다.

운영 기준

self-hosted Mac에서 Xcode UI 테스트를 안정적으로 돌리려면 automationmodetool은 다음 기준으로 다룬다.

첫째, runner 이미지를 만들거나 Mac mini를 세팅하는 단계에서 실행한다.

sudo automationmodetool enable-automationmode-without-authentication

둘째, job에서는 상태만 출력한다.

automationmodetool

셋째, This device DOES NOT REQUIRE user authentication to enable Automation Mode.가 보이는지 확인한다.

넷째, 그래도 멈추면 automationmodetool을 다시 의심하기 전에 프롬프트의 성격을 분류한다. 암호를 요구하면 Automation Mode 쪽이다. 특정 앱이 컴퓨터를 제어해도 되는지 묻거나 Accessibility 권한을 요구하면 TCC/PPPC 쪽이다.

다섯째, 여러 Xcode 버전이나 여러 runner 계정을 운영한다면 설정 단위를 명확히 나눈다. automationmodetool은 장비 상태를 바꾸지만, TCC 권한과 keychain 접근은 사용자·프로세스·서명 요구사항의 영향을 받는다. 한 명령으로 전체 macOS UI 테스트 권한 문제가 끝난다고 보면 안 된다.

정리

automationmodetool은 Xcode UI 테스트에서 Automation Mode 암호 프롬프트를 제거하는 도구다.

하지만 이 도구는 TCC 권한을 주지 않는다. Accessibility, AppleEvents, Post Event, signing keychain, Developer Tools Access 문제는 별도로 봐야 한다. 그래서 실무 진단 순서는 “모든 권한을 한 번에 허용”이 아니라 “어떤 subsystem이 막고 있는지 분류”가 되어야 한다.

CI 장비에서는 sudo automationmodetool enable-automationmode-without-authentication을 runner 부트스트랩에서 실행한다. workflow에는 상태 확인만 남긴다. 그게 이 도구를 안전하게 쓰는 가장 단순한 기준이다.