iOS 자동화 테스트 서버는 어떻게 구축할까? 2026 원격 Mac 튜토리얼

테스트를 실행할 때마다 Mac을 빌리거나 개발자에게 수동 실행을 부탁해야 한다면, 실패 재현과 야간 회귀 테스트가 막힙니다.
가장 빠른 해법은 로컬에서 코딩하고 원격 Mac에서 자동 테스트를 실행하는 이중 환경입니다. 먼저 하나의 Scheme과 하나의 시뮬레이터로 통과시킨 뒤 Test Plan, xcresult, 예약 실행을 붙이세요.

SECTION 01 이 글이 필요한 개발자

Windows 또는 Linux에서 크로스 플랫폼 코드를 작성하지만 iOS 테스트는 macOS에서 실행해야 하는 독립 개발자를 위한 글입니다.

무거운 XCTest 또는 UI 테스트를 일상적인 개발 장비에서 분리하려는 1인 개발자, 복구 가능한 테스트 환경을 만들고 싶지만 복잡한 CI 플랫폼은 아직 필요하지 않은 소규모 팀에도 맞습니다.

SECTION 02 시작 전: 로컬과 원격의 경계

소스 편집과 빠른 코드 수정은 익숙한 로컬 장비에 남겨도 됩니다. 원격 Mac은 의존성 복원, 테스트용 빌드, iOS Simulator 실행, 결과 패키지 보관을 담당하게 하세요.

이 구조는 모든 개발 작업을 원격으로 옮기지 않고도 테스트 환경만 안정화합니다. Apple은 Simulator와 실제 기기에서 앱을 실행하는 방법을 별도로 안내하므로, 프로젝트가 실제 기기를 요구하는지 먼저 확인해야 합니다. Apple의 실행 대상 안내를 기준으로 테스트 유형을 나누세요.

처음부터 여러 기기를 병렬 실행하면 실패 원인을 분리하기 어려워집니다. 다음 조건을 먼저 문서로 고정하세요.

빠른 단위 테스트인지, 화면 조작을 포함한 UI 테스트인지
실행을 수동으로 할지, 커밋이나 예약 작업마다 할지
확인할 운영체제와 기기 조합이 무엇인지
성공을 판단할 기준이 종료 상태인지, 특정 테스트 결과인지
기존 Scheme과 Test Plan에서 이미 요구하는 설정이 무엇인지

원격 Mac의 macOS와 Xcode 조합은 프로젝트가 요구하는 기준으로 정해야 합니다. 최신 조합이라고 자동으로 호환되는 것은 아니므로 Apple의 Xcode 시스템 요구 사항 표에서 지원 관계를 확인하세요.

선택 조건

로컬 Mac이 없지만 테스트를 가끔 실행한다면, 필요할 때 켜는 원격 Mac을 먼저 선택합니다.
매일 회귀 테스트나 야간 작업이 필요하다면, 상시 실행 환경을 검토합니다.
여러 Simulator를 동시에 돌려야 한다면, 먼저 단일 테스트의 자원 사용과 상태 격리를 확인한 뒤 병렬화를 결정합니다.
물리적인 기기 연결, 특수한 USB 장비, 장시간의 고정 부하가 필수라면 원격 임대보다 직접 보유가 더 적합할 수 있습니다.

운영 방식	적합한 경우	먼저 확인할 항목
필요할 때 원격 실행	가끔 회귀하거나 릴리스 직전에 검증하는 경우	Xcode 설치 상태, Simulator Runtime, 결과 내려받기
상시 테스트 머신	매일 회귀, 야간 실행, 팀 공용 테스트가 필요한 경우	재부팅 후 자동 접속, 디스크 정리, 실패 알림
로컬 Mac 직접 운영	물리 기기나 전용 장비가 필요한 경우	장비 유지 관리, 전원과 네트워크, 접근 권한

SECTION 03 첫 작업: 원격 Mac의 기준선 고정

원격 접속을 열었다면 곧바로 전체 프로젝트를 실행하지 마세요. 먼저 테스트 전용 계정과 디렉터리를 만드세요. 계정에는 필요한 권한만 주고, 소스와 임시 산출물을 분리해야 실패 후 정리가 쉬워집니다.

mkdir -p "$HOME/work/<PROJECT_PLACEHOLDER>"
mkdir -p "$HOME/test-output/<PROJECT_PLACEHOLDER>"
xcode-select --print-path
xcodebuild -version

프로젝트 이름, 사용자 이름, 저장소 주소와 경로는 실제 값으로 바꾸되, 운영 문서에는 비밀 값이 남지 않게 하세요. xcode-select가 예상한 개발 도구를 가리키는지 확인하고, Command Line Tools가 별도 경로를 가리키면 팀의 기준을 다시 맞춰야 합니다.

Simulator Runtime이 없으면 테스트 대상이 표시되지 않을 수 있습니다. 필요한 런타임은 Apple의 Simulator 추가 문서에서 설치 방법과 지원 범위를 확인하세요. 설치가 끝난 뒤 프로젝트의 destination에 실제로 선택 가능한지 점검합니다.

SSH는 명령 실행과 로그 수집에 편리합니다. 반면 권한 대화 상자, 키보드 입력, 화면 상태를 확인해야 하는 작업은 그래픽 로그인 세션이 필요할 수 있습니다. iOS Simulator 테스트 서버가 항상 그래픽 화면을 띄워야 한다고 단정하지 말고, 명령 실행은 SSH에서 검증한 뒤 UI 테스트에 필요한 권한과 세션 동작을 별도로 확인하세요. Apple의 원격 명령줄 테스트 안내도 함께 참조합니다.

SECTION 04 첫 실행: 하나의 테스트 입구 만들기

공유 Scheme과 확실한 destination 하나를 정한 뒤 xcodebuild test를 실행하세요. 이 단계의 목표는 속도가 아닙니다. 프로젝트가 빌드되고, 테스트 프로세스가 시작되며, 스크립트가 성공과 실패를 구분하는지 확인하는 것입니다.

xcodebuild \
  -workspace "<WORKSPACE_PLACEHOLDER>.xcworkspace" \
  -scheme "<SCHEME_PLACEHOLDER>" \
  -destination 'platform=iOS Simulator,name=<DEVICE_PLACEHOLDER>,OS=<RUNTIME_PLACEHOLDER>' \
  -resultBundlePath "$HOME/test-output/<PROJECT_PLACEHOLDER>/first-run.xcresult" \
  test

실제 프로젝트가 프로젝트 파일을 사용한다면 -workspace 대신 -project를 사용합니다. destination 이름과 운영체제 값은 설치된 Simulator 목록에서 확인하고, 임의의 기기 이름을 문서에 고정하지 마세요.

전체 테스트가 실패하면 -only-testing으로 범위를 줄입니다.

xcodebuild \
  -scheme "<SCHEME_PLACEHOLDER>" \
  -destination 'platform=iOS Simulator,name=<DEVICE_PLACEHOLDER>,OS=<RUNTIME_PLACEHOLDER>' \
  -only-testing:"<TEST_TARGET_PLACEHOLDER>/<TEST_CASE_PLACEHOLDER>" \
  test

이 방식으로 특정 XCTest 묶음만 실행하면 빌드 오류, 테스트 코드 오류, Simulator 상태 오류를 분리하기 쉽습니다. Apple의 명령줄 빌드와 테스트 기술 문서에서 xcodebuild의 명령 구조와 테스트 방식을 확인하세요.

빠른 피드백과 전체 회귀를 하나의 실행 설정에 섞지 마세요. Test Plan을 다음처럼 나누면 실패 범위가 명확해집니다.

코드 수정 직후 실행하는 빠른 단위 테스트
예약 작업에서 실행하는 전체 회귀 테스트
배포 전 별도로 확인하는 UI 및 통합 테스트

Test Plan은 테스트 묶음과 실행 설정을 관리하는 기준이므로, Apple의 테스트 구성 안내에 맞춰 공유 Scheme에 연결하세요.

SECTION 05 UI 테스트: Simulator 상태를 고정하는 법

XCTest 단위 테스트는 데이터 격리만으로도 재현성이 좋아질 수 있지만, UI 테스트는 화면 상태와 권한에 더 민감합니다. 기기 유형, 운영체제 런타임, 언어, 권한 요청 처리, 테스트 계정과 초기 데이터를 고정하세요.

실패를 다음 네 범주로 나누면 불필요한 서버 교체를 줄일 수 있습니다.

앱 코드의 실제 동작 오류
대기 조건이 부족한 테스트 코드
이전 실행이 남긴 Simulator 상태
원격 세션이나 접근 권한 문제

앱 삭제, 콘텐츠와 설정 초기화, Simulator 재생성은 영향 범위가 서로 다릅니다. 초기화 전에 콘솔 로그와 실패 화면을 보관하세요. 원인을 지운 뒤 다시 실행하면 같은 실패를 재현하지 못할 수 있습니다.

주의: 테스트가 우연히 통과하도록 매번 전체 환경을 파괴하면 진단 정보도 함께 사라집니다. 먼저 결과와 로그를 보존하고, 격리된 재실행에서 초기화 효과를 비교하세요.

처음부터 병렬 실행을 기본값으로 두지 마세요. 공유 파일, 포트, 테스트 계정, 네트워크 목 데이터가 겹치면 병렬화가 테스트 속도가 아니라 실패 수만 늘릴 수 있습니다. 단일 실행이 안정화된 뒤 독립성이 확인된 묶음만 분리합니다.

SECTION 06 결과 보관: xcresult와 실패 증거

원격 테스트는 화면을 계속 지켜보는 방식이 아니라, 종료 상태와 산출물로 판단해야 합니다. -resultBundlePath로 xcresult를 지정하고 표준 출력도 별도 로그로 저장하세요.

set -o pipefail
xcodebuild \
  -scheme "<SCHEME_PLACEHOLDER>" \
  -destination 'platform=iOS Simulator,name=<DEVICE_PLACEHOLDER>,OS=<RUNTIME_PLACEHOLDER>' \
  -resultBundlePath "$HOME/test-output/<PROJECT_PLACEHOLDER>/run.xcresult" \
  test 2>&1 | tee "$HOME/test-output/<PROJECT_PLACEHOLDER>/run.log"
exit "${PIPESTATUS[0]}"

셸 환경에 따라 종료 상태 전달 방식이 다를 수 있으므로, 실제 원격 환경에서 성공과 실패를 각각 만들어 확인하세요. 결과 패키지에는 테스트 결과와 관련 로그가 포함될 수 있고, 설정에 따라 커버리지 정보도 확인할 수 있습니다. 다만 모든 UI 실패가 결과 패키지만으로 해결되는 것은 아닙니다. 화면 캡처, 동영상, Simulator 로그가 추가로 필요할 수 있습니다.

Apple의 테스트 결과 해석 문서와 결과 패키지 도구 설명을 기준으로 결과를 열고 필요한 파일을 추출하세요. 테스트 반복 기능은 Apple의 반복 테스트 안내처럼 우연한 실패를 찾는 용도로 사용하되, 반복 통과를 코드 결함이 없다는 증거로 해석하지 마세요.

실패 후 자동 흐름은 다음처럼 단순하게 설계하는 편이 좋습니다.

실패하면 종료 상태를 실패로 남깁니다.
xcresult, 콘솔 로그, 캡처와 Simulator 로그를 보관합니다.
알림에는 Scheme, destination, 실패한 테스트 이름과 결과 위치를 포함합니다.
전체 재실행과 특정 테스트만 다시 실행하는 입구를 분리합니다.
보관 기간과 용량 제한을 정하고, 삭제 전에 최근 실패 자료를 보호합니다.

SECTION 07 첫 주 운영: 임대 방식을 결정하는 시점

단일 테스트가 성공했다고 서버가 완성된 것은 아닙니다. 실제 저장소를 새로 내려받고, 의존성을 복원하고, 테스트를 실행하고, 결과를 내보낸 뒤 실패한 테스트를 다시 실행하세요. 재부팅 후에도 접속 가능한지, 이전 Simulator가 남아 있는지, DerivedData와 결과 패키지가 계속 쌓이는지도 확인합니다.

테스트 반복에서 같은 실패가 재현되는지 관찰하고, 재현되지 않는 실패만 별도 분류하세요. 서버 성능으로 모든 실패를 설명하면 테스트 코드의 대기 문제나 공유 상태를 놓치게 됩니다.

운영 선택은 다음 조건으로 정리할 수 있습니다.

테스트가 가끔 필요함 → 필요할 때 원격 Mac을 시작하고 결과를 내려받습니다.
매일 같은 회귀를 실행함 → 상시 테스트 머신을 두고 재부팅과 실패 알림을 검증합니다.
야간 작업과 팀 공유가 필요함 → 상시 환경과 보관 정책을 함께 구성합니다.
여러 Simulator가 필요하지만 단일 실행이 불안정함 → 병렬화를 미루고 상태 격리부터 해결합니다.
물리 기기나 특수 장비가 필요함 → 원격 환경만으로 대체하지 말고 직접 장비 운영을 비교합니다.

원격 Mac을 선택할 때는 Xcode 호환성, 필요한 Simulator Runtime, SSH와 그래픽 세션의 접근 방식, 재부팅 뒤 복구 방법을 계약 전에 확인하세요. VPSNIX의 Mac 원격 이용 안내와 이용 요금 및 기간 정보를 검토할 때도 이 네 가지를 먼저 대조하는 것이 좋습니다.

SECTION 08 현재 방식과 Mac 테스트 환경의 차이

로컬 Mac을 새로 사는 방식은 물리 기기와 주변 장비를 직접 통제할 수 있지만, 테스트 전용 장비의 구매 비용과 유지 관리가 발생합니다. 반대로 현재 Windows 또는 Linux 장비만으로 버티면 iOS Simulator 실행 지점이 없고, 수동 원격 접속에 의존하며, 야간 테스트와 실패 결과 보관이 끊기기 쉽습니다.

이런 제약 때문에 가끔 검증하는 개발자는 필요할 때만 Mac을 임대하고, 매일 XCTest와 UI 테스트를 돌리는 팀은 상시 임대 환경을 비교하는 편이 현실적입니다. 최소 테스트 체인을 직접 통과시킨 뒤 Xcode, Simulator, 결과 보관과 재부팅 복구가 모두 맞는지 확인하면, VPSNIX의 원격 Mac 이용 시작이 자신의 실행 빈도에 맞는지 판단할 수 있습니다.