Mac UI 자동화 테스트는 공유 Mac과 전용 Mac 중 무엇을 써야 할까? 2026

UI 테스트가 다른 작업과 섞이거나 실패 원인을 되짚기 어렵습니까?

저빈도이며 신뢰할 수 있는 코드만 실행하고 작업을 직렬화할 수 있다면 관리되는 공유 Mac에서 먼저 시험합니다. 동시 실행, 안정적인 재현, 다른 작업과의 분리가 필요해지면 전용 Mac 테스트 노드로 옮깁니다. Runner 그룹과 작업 라우팅만으로 호스트 격리가 입증되지는 않으므로, 최종 결정은 팀의 실행 기록으로 확인해야 합니다.

이 글은 macOS 앱 품질을 맡은 QA 책임자, CI 플랫폼 엔지니어, Mac 자원과 보안 경계를 관리하는 IT 책임자를 위한 선택 안내입니다.

착수 전: UI 테스트와 빌드 작업의 실행 조건을 구분합니다

단위 테스트, 앱 빌드, UI 자동화 테스트를 같은 종류의 작업으로 취급하면 안 됩니다. 단위 테스트와 빌드는 프로젝트의 도구 체인과 의존성에 따라 실행 환경을 정합니다. UI 테스트는 앱 화면에 실제로 접근해 동작을 확인하는 절차가 포함됩니다.

Apple은 XCUIAutomation 문서에서 UI 자동화가 앱의 UI와 상호작용하고 상태를 확인하는 방식을 설명합니다. 따라서 macOS UI 테스트를 설계할 때는 단순히 빌드가 성공하는지보다 테스트 대상 앱이 실행되고, 필요한 UI 동작을 수행하며, 결과를 남기는지 확인해야 합니다.

다만 UI 테스트가 특정 Mac 호스트에서만 실행되어야 한다고 일반화할 수는 없습니다. 실제 프로젝트의 테스트 방식, 도구 체인, 접근 권한과 워크플로를 검토한 뒤 테스트를 맡길 환경을 정합니다. Xcode 테스트 안내를 기준으로 테스트 종류와 프로젝트의 실행 조건을 먼저 확인합니다.

시험 운영: 공유 Mac과 전용 Mac을 조건에 따라 선택합니다

공유 Mac은 제한된 범위의 시험 운영에 적합할 수 있습니다. 단, 코드와 작업을 신뢰할 수 있고 실행을 직렬화할 수 있어야 합니다. 공유 호스트에서 작업을 다른 Runner로 보냈다는 사실만으로 프로세스, 파일, 키체인이나 네트워크 접근이 분리됐다고 판단해서는 안 됩니다.

macOS UI 테스트를 공유 Mac에서 실행해도 됩니까?

신뢰할 수 있는 코드만 사용하고, 동시에 여러 작업이 상태를 바꾸지 않도록 통제할 수 있다면 제한된 시험 운영은 가능합니다. 실행 전후에 남는 파일과 자격 증명, 다른 작업의 동시 실행 여부를 기록해야 합니다. 이런 조건을 관리하기 어렵거나 실패 원인을 호스트 간섭과 구분할 수 없다면 전용 노드로 전환하는 편이 낫습니다.

첫 실행: Runner 상태가 아니라 테스트 완료 증거를 확인합니다

Runner가 온라인이거나 일반 빌드가 성공했다는 사실은 UI 테스트가 실제로 완료됐다는 증거가 아닙니다. 대표 테스트를 선택해 팀이 정한 Mac 환경에서 실행하고, 다음 정보를 함께 보존합니다.

• 커밋 식별 정보와 테스트에 사용한 대상
• 실제 UI 테스트 실행 결과와 실패 진단 자료
• 테스트가 남긴 보고서와 첨부 파일
• 실행 환경, 실행 시점, 작업을 맡은 노드

Apple의 테스트 실행 및 결과 해석 안내는 Xcode에서 테스트 결과를 확인하는 방법을 다룹니다. 결과 보고서와 첨부 자료를 남기고, 해당 결과가 대상 커밋과 실행에 연결되는지 검수합니다.

최초 검증은 팀에서 반복적으로 사용하는 대표 테스트로 진행합니다. 실행 명령은 프로젝트의 스킴과 테스트 대상을 반영해 조정합니다.

xcodebuild test \
  -scheme AppUITests \
  -destination 'platform=macOS' \
  -resultBundlePath Artifacts/UI.xcresult

위 명령은 구성 예시입니다. 실제 스킴, 실행 목적지와 결과 경로는 프로젝트에 맞춰야 합니다. 시험이 끝나면 결과 번들이 생성됐는지, 실패한 테스트의 진단 자료가 확인되는지, 같은 커밋과 환경 정보로 실행 내역을 추적할 수 있는지 확인합니다. 성공 여부를 Runner의 상태 화면만으로 판정하지 않습니다.

CI 연결: 작업 라우팅과 호스트 격리를 따로 검증합니다

GitHub Actions를 사용하는 경우 작업 정의의 runs-on 설정에서 Runner group과 labels를 확인합니다. GitHub의 자체 관리 Runner 워크플로 안내는 워크플로가 조건에 맞는 Runner를 선택하도록 설정하는 방법을 설명합니다. 그룹과 레이블은 작업을 어느 Runner로 보낼지 정하는 조건입니다. 호스트의 데이터나 자격 증명이 작업 사이에 격리된다는 증명은 아닙니다.

예를 들어 다음처럼 작업 대상 조건을 선언할 수 있습니다.

runs-on:
  group: macos-ui-tests
  labels: mac-ui

이 설정을 적용한 뒤에는 워크플로 로그에서 의도한 Runner가 선택됐는지 확인합니다. 그룹과 접근 범위를 검토할 때는 Runner 그룹 설명과 Runner 접근 관리 안내를 함께 살펴봅니다.

라우팅 확인과 별도로 호스트 경계를 점검합니다.

• 작업이 끝난 뒤 소스, 빌드 산출물과 임시 파일이 남는지 확인합니다.
• 서명 키와 토큰이 어디에 저장되고 누가 읽을 수 있는지 확인합니다.
• 작업 코드가 접근할 수 있는 네트워크와 내부 서비스 범위를 검토합니다.
• 신뢰할 수 없는 코드가 같은 호스트에서 실행되는 경로가 있는지 확인합니다.

GitHub는 자체 관리 Runner가 매번 임시로 생성된 깨끗한 가상 머신에서 실행된다고 보장하지 않는다고 안내합니다. 따라서 자체 관리 Runner 보안 문서를 검토하고, 풀 리퀘스트를 처리하는 흐름에는 보안 사용 지침도 적용 가능한지 따로 판단합니다. Runner 그룹을 분리해도 호스트에 남는 자료나 접근 권한이 자동으로 정리되는 것은 아닙니다.

실행 확대: 동시성, 재현과 대기 기록으로 운영 방식을 다시 정합니다

시험 운영을 확대할 때는 기억이나 추정 대신 CI 기록을 비교합니다. 작업이 겹칠 때만 나타나는 실패가 있는지, 앞선 실행의 상태가 다음 테스트에 영향을 주는지, 같은 커밋의 재실행 결과가 달라지는지 살펴봅니다. 대기와 실행 시간, 실패율에 대한 보편적인 전환 기준은 두지 않습니다. 실제 프로젝트 기록이 기준입니다.

테스트를 묶는 방식도 살펴볼 수 있습니다. Apple의 테스트 구성 안내는 피드백을 개선하기 위한 테스트 구성 방법을 설명합니다. 테스트 구성을 바꾸더라도 호스트 간섭이 해소됐다고 가정하지 말고, 변경 전후의 결과와 실행 조건을 남깁니다.

다음 조건 분기로 결정을 내리면 됩니다.

• 신뢰할 수 있는 코드만 실행하고, 실행을 직렬화할 수 있으며, 다른 작업의 영향을 결과에서 구분할 수 있다면 공유 Mac을 유지합니다.
• 동시 UI 실행이 필요하지만 작업끼리 영향을 주는 정황이 있다면 우선 직렬 실행으로 되돌리고, 기록을 모아 원인을 확인합니다.
• 안정적인 재현이 필요하거나 다른 작업과의 분리가 요구되는데 공유 호스트에서 이를 확인할 수 없다면 전용 Mac 테스트 노드로 전환합니다.
• Runner 라우팅은 맞지만 호스트의 잔여 데이터, 자격 증명이나 네트워크 접근을 통제할 수 없다면 노드 증설보다 먼저 보안 경계를 재설계합니다.

승인 단계: 결과, 환경과 운영 책임을 함께 검수합니다

공유 환경을 유지하든 전용 환경으로 나누든, 결정 기록에는 실제 테스트 결과와 환경 정보가 있어야 합니다. 실패 진단 자료의 보존 위치, 호스트 접근 권한, 작업 후 정리 책임도 명시합니다. 이런 증거가 빠지면 CI에 표시된 성공이나 온라인 상태만으로 UI 테스트 환경을 승인하지 않습니다.

공유 Mac은 가벼운 시험 운영에는 쓸 수 있지만, 작업 간 영향과 정리 책임이 누적되면 재현과 보안 검토가 어려워집니다. 반대로 테스트가 저빈도이고 직렬 실행이 가능하며 공유 환경의 경계를 관리할 수 있다면, 처음부터 전용 자원을 고정할 필요는 없습니다. 팀의 기록으로 조건을 검증한 뒤 필요한 범위만 분리하는 것이 합리적입니다.

현재 공유 환경에서 문제가 반복된다면 전용 Mac 노드를 검토할 수 있습니다. 공유 작업의 잔여 데이터, 다른 테스트와의 간섭, 접근 권한을 함께 관리해야 하는 부담을 줄이는 방향입니다. 원격 Mac이 후보라면 먼저 SFTPMAC의 원격 Mac 서비스 안내와 Mac 미니 렌탈 요금 안내를 확인하고, 실제 UI 테스트 대상과 필요한 접근 조건이 맞는지 시험해야 합니다. 원격 환경의 제공 형태만으로 그래픽 UI 자동화 호환성을 단정할 수는 없습니다. 전용 노드가 필요한 경우에만 조건과 운영 책임을 대조해 도입 여부를 결정합니다.