Xcode UI 테스트와 automationmodetool의 범위
CI에서 Xcode UI 테스트를 돌리면 실행 전에 인증 대화상자가 떠서 멈출 때가 있어요. 사람이 앞에 있는 Mac이라면 암호를 넣으면 돼요. self-hosted runner나 테스트 랩의 Mac에는 입력할 사람이 없어서 테스트가 진행되지 않아요.
automationmodetool은 이 인증 요구를 설정하는 도구예요. 다만 UI 테스트의 권한 문제를 전부 풀어 주지는 않아요. 이 도구가 맡는 범위와 TCC 권한처럼 따로 다뤄야 하는 것을 구분하고, 장비를 준비하는 순서를 정리해요. 상태 조회는 2026년 10월 4일에 macOS 27.0.1과 Xcode 27.0에서 직접 실행했어요. 설정을 바꾸는 명령과 UI 테스트는 실행하지 않았어요.
인자 없이 실행하면 상태를 알려 줘요
man page에 따르면 이 도구는 UI 테스트용 Automation Mode를 사용자 인증 없이 켤 수 있게 장비를 설정해요. CI 장비와, 사용자에게 관리자 권한이 없는 랩 장비를 준비할 때 쓰라고 적혀 있어요. 인자를 주지 않으면 Automation Mode가 켜져 있는지와 인증이 필요한지를 출력하고 끝나요. 설치된 man page의 내용도 같았어요.
automationmodetool
제 Mac에서 실행한 출력이에요.
Automation Mode is disabled.
This device DOES NOT REQUIRE user authentication to enable Automation Mode.
두 줄은 서로 다른 것을 말해요. 첫 줄의 disabled는 지금 Automation Mode가 꺼져 있다는 상태예요. 둘째 줄은 모드를 켤 때 인증이 필요한지에 대한 설정이에요. DOES NOT REQUIRE라고 나오면 XCTest와 testmanagerd가 실행 중에 모드를 전환할 때 암호를 넣지 않아도 돼요.
인증 없이 켤 수 있게 하는 명령은 이것이에요.
sudo automationmodetool enable-automationmode-without-authentication
다시 인증을 요구하게 되돌리는 명령은 이것이에요.
sudo automationmodetool disable-automationmode-without-authentication
설정을 바꾸는 일 자체에는 관리자 인증이 필요해요. 그래서 PR마다 실행하기보다 장비를 처음 준비할 때 넣기를 권해요.
인증 설정과 TCC 권한은 다른 문제예요
Xcode Helper나 러너가 Accessibility, AppleEvents, Post Event를 요청하는 것은 TCC의 문제예요. Apple의 PPPC 설정 안내에서 이 셋은 각각 Accessibility API로 Mac을 제어하는 것, 제한된 AppleEvent를 다른 프로세스에 보내는 것, CoreGraphics API로 이벤트를 보내는 것에 대응해요. automationmodetool로는 TCC 허가, PPPC 설치, Accessibility 허가를 대신할 수 없어요.
로그의 문구로 둘을 나눠 봐요. Xcode Helper does not have permission to use Accessibility. 같은 거부 메시지가 나오면 Privacy & Security 설정이나 MDM의 PPPC 설정을 조사해요. Timed out while enabling automation mode.가 나오면 인증 단계의 문제일 가능성이 있으므로 상태부터 조회해요. timeout만으로 인증 문제라고 확정할 수는 없고, 두 장애가 함께 날 수도 있어요. 화면에 뜨는 창으로도 가늠해 볼 수 있어요. 암호를 묻는 창은 모드 인증 쪽의 후보이고, 앱 제어 동의나 Accessibility를 묻는 창은 TCC와 PPPC 쪽의 후보예요.
어느 프로세스가 권한을 요청하는지는 TCC의 로그에서 볼 수 있어요. 같은 PPPC 안내에 실린 명령이에요.
log stream --debug --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"'
Xcode.app이나 테스트 대상 앱을 짐작으로 허용 목록에 계속 추가하지 말고, 이 로그에서 책임 프로세스를 확인한 뒤에 허용하기를 권해요.
장비를 준비할 때 설정하고 job에서는 조회해요
무인 UI 테스트용 Mac을 준비하는 순서의 예예요. Xcode의 개발 경로를 고르고, 라이선스를 수락하고, 첫 실행 작업을 한 뒤, 인증 설정을 바꾸고 상태를 조회해요.
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -license accept
sudo xcodebuild -runFirstLaunch
sudo automationmodetool enable-automationmode-without-authentication
automationmodetool
self-hosted runner에서 이 변경을 workflow에 넣는 것은 조심해야 해요. 아래 같은 단계가 그 예예요.
- name: Enable automation mode
run: sudo automationmodetool enable-automationmode-without-authentication
임의의 코드가 실행되는 workflow에 sudo를 허용하면 권한 상승의 위험이 생겨요. 장비의 소유자가 준비를 맡고, job은 빌드와 테스트만 하게 나누기를 권해요. job의 시작에는 설정을 바꾸지 않고 상태만 기록해 둬요.
- name: Show UI automation state
run: |
automationmodetool || true
xcodebuild -version
xcode-select -p
|| true는 조회가 실패해도 job을 멈추지 않고 기록만 남기려는 것이에요. 이 운영 방식은 man page가 정한 것이 아니고 제 해석이에요.
예외도 있어요. sudo를 서비스가 관리하는 hosted CI에서는 사정이 달라요. Bitrise의 안내는 이 timeout이 나면 Script Step에서 변경 명령을 실행하라고 적어요.
이 문제는 여러 번 보고됐어요. GitHub Actions의 macOS 12 Monterey 러너에서 UI 테스트가 timeout으로 실패한다는 이슈 5410이 있고, macOS 13과 Xcode 14.3.1에서 같은 오류를 다룬 이슈 7778이 있어요. Flutter의 이슈 166011은 XCUITest 통합 테스트를 위해 이 설정이 필요한데 설정 명령이 암호를 요구하는 것이 문제라고 적어요. 그 이슈에는 expect로 암호를 넣는 방식이 인용돼 있는데, 불안정하므로 러너의 계정과 장비를 미리 준비하는 쪽을 권해요. UI 자동화의 녹화와 재생은 WWDC25 세션 344의 주제예요.
장비 단위의 모드 설정과 사용자·프로세스·서명 조건에 따른 TCC, keychain 권한은 별개예요. signing keychain, Developer Tools Access, DevToolsSecurity도 따로 조사할 영역이에요. Xcode를 여러 버전으로 두거나 러너 계정을 여럿 운영한다면, 어느 설정이 어느 범위에 걸리는지 나눠서 봐야 해요. 이 글의 이전 판은 macOS 26.5.1과 Xcode 26.6을 기준으로 적었고, 이번에는 상태 조회만 다시 확인했어요. 설정이 재부팅이나 업데이트, 이미지 교체 뒤에도 유지되는지와 설정한 뒤에 UI 테스트가 실제로 통과하는지는 확인하지 않았어요.