fastlane scan은 iOS 테스트 절차를 호출하지만 실행 환경이나 테스트 결과를 대신하지 않습니다. 원격 맥의 도구 체인 확인부터 테스트 설정, 첫 실행, 결과 보관, CI 연결 판단까지 시간순으로 설명합니다. 시뮬레이터 테스트와 실제 기기 검증의 차이도 함께 정리합니다.
fastlane scan은 iOS 테스트 절차를 호출하지만 실행 환경이나 테스트 결과를 대신하지 않습니다. 원격 맥의 도구 체인 확인부터 테스트 설정, 첫 실행, 결과 보관, CI 연결 판단까지 시간순으로 설명합니다. 시뮬레이터 테스트와 실제 기기 검증의 차이도 함께 정리합니다.
fastlane scan은 iOS 테스트 절차를 호출하지만 Mac 실행 환경이나 테스트 결과를 대신하지 않습니다. 원격 맥에서 scheme과 시뮬레이터 대상을 먼저 확인하고, 결과 파일까지 검수한 뒤 CI에 연결하세요. 실제 기기 동작이 필요한 항목은 별도로 기기 검증을 진행해야 합니다.
이 글은 fastlane scan으로 원격 맥에서 iOS 자동화 테스트를 운영하려는 개발자와 CI 엔지니어를 위한 안내입니다.
테스트 노드를 유지하거나 임시 원격 환경을 검토하는 독립 개발자와 소규모 팀에도 적합합니다.
먼저 테스트를 실행할 원격 맥에 프로젝트의 작업 복사본을 준비합니다. Xcode 프로젝트 또는 작업 공간, 공유된 scheme, 테스트 대상이 저장소에 포함되어 있는지 확인합니다. 개인 로컬 환경에만 있는 설정에 의존하면 원격 실행 결과를 재현하기 어렵습니다.
그다음 원격 맥에서 실제로 선택된 Xcode 환경을 확인합니다. fastlane 문서는 scan을 통해 iOS 테스트를 실행하는 방법을 안내하며, run_tests의 설정 항목도 제공합니다. 어떤 Xcode가 선택되어 있는지와 테스트 실행에 전달할 조건을 함께 점검하세요. fastlane의 iOS 테스트 실행 안내와 run_tests 설정 문서를 기준으로 삼되, 프로젝트가 요구하는 설정은 저장소의 구성과 대조해야 합니다.
Ruby와 fastlane의 버전을 임의로 맞추기보다 프로젝트의 의존성 관리 방식을 따릅니다. Gemfile과 잠금 파일을 사용하는 프로젝트라면 원격 맥에서도 해당 파일을 기준으로 의존성을 설치하고, 실행 명령도 프로젝트에서 쓰는 방식과 일치시킵니다. 공식 문서가 프로젝트별 호환성을 보장하는 것은 아니므로, 특정 버전 조합을 일반적인 성공 조건으로 간주하지 마세요.
Xcode 명령줄 도구는 선택된 개발자 도구 환경과 연결됩니다. 필요한 도구가 준비됐는지와 프로젝트가 의도한 Xcode를 사용하는지는 Apple의 Xcode 명령줄 도구 참고 문서에서 확인할 수 있습니다.
반복 실행할 테스트는 Fastfile의 lane에 넣어 호출 조건을 프로젝트 안에 남기는 편이 관리하기 쉽습니다. 아래는 구조를 보여 주는 예시입니다. 프로젝트 이름과 scheme, 테스트 계획, 기기 이름, 경로는 실제 저장소와 원격 맥의 구성으로 바꿔야 합니다.
lane :test_remote do
scan(
project: "프로젝트 경로",
scheme: "공유된 scheme 이름",
testplan: "테스트 계획 이름",
devices: ["원격 맥에서 사용 가능한 시뮬레이터 이름"],
result_bundle_path: "결과 저장 경로"
)
end
project와 workspace 중 무엇을 사용할지는 프로젝트 구조에 맞춰 선택합니다. 테스트 계획을 쓰지 않는 프로젝트라면 해당 설정을 생략할 수 있습니다. Apple은 테스트 계획을 통해 테스트 구성을 정리하고 실행 방식을 구성하는 방법을 설명합니다. 계획을 추가하거나 이름을 바꾼 뒤에는 원격 맥에 체크아웃된 프로젝트에서도 같은 구성이 발견되는지 확인하세요. Apple의 테스트 계획 구성 안내를 참고할 수 있습니다.
시뮬레이터 이름은 예시 문자열을 그대로 복사하지 않습니다. 원격 환경에 설치된 런타임과 사용 가능한 기기 목록을 확인한 다음, 그중 실제 대상과 일치하는 값을 설정합니다. 이름이나 런타임이 맞지 않으면 테스트 코드가 실행되기 전 단계에서 멈출 수 있습니다.
첫 실행에서 곧바로 전체 테스트를 돌리기보다, 핵심 테스트 대상 하나를 선택해 실행 흐름을 확인합니다. 프로젝트가 잠금 파일을 쓰는 경우에는 의존성 설치와 fastlane 호출을 같은 프로젝트 방식으로 수행합니다.
bundle exec fastlane test_remote
이 명령은 Bundler를 사용하는 프로젝트의 예시입니다. 프로젝트가 다른 방식으로 fastlane을 실행한다면 기존 실행 절차를 유지합니다. 필요할 때는 fastlane run_tests로 action을 직접 호출할 수 있지만, 팀에서 반복하는 작업은 lane에 조건을 모아 두는 편이 실행 기록을 비교하기 쉽습니다. run_tests의 인자와 동작은 공식 action 문서에서 확인하세요.
실패 원인은 한 덩어리로 처리하지 말고 단계별로 구분합니다.
이 구분은 fastlane scan 명령 자체의 문제와 프로젝트 설정, 시뮬레이터 대상, 테스트 코드의 실패를 혼동하지 않도록 돕습니다.
아래 평가는 비용이나 속도 수치가 아니라 테스트 운영 목적에 따른 적합성 판단입니다. 각 환경에서 실제로 얻을 수 있는 결과와 팀이 직접 확인해야 할 항목을 기준으로 선택하세요.
| 실행 환경 | 잘 맞는 경우 | 확인할 점 | 평가 |
|---|---|---|---|
| 개발자 로컬 맥 | 설정을 빠르게 바꾸며 테스트를 확인할 때 | 로컬 Xcode와 의존성이 CI 환경과 같은지 | 개발 반복에 적합 |
| 원격 맥 | 팀 공용 실행 환경이나 원격 테스트 노드가 필요할 때 | 접근 방식, 도구 체인, 결과 파일 회수 절차 | 조건부 적합 |
| Linux 기반 CI | 맥 실행 환경이 필요하지 않은 작업을 처리할 때 | iOS 시뮬레이터와 Xcode 테스트 실행에 필요한 환경인지 | 해당 테스트에는 부적합 |
원격 맥에서 테스트를 실행한다면 접속 편의성만 보지 말고, 프로젝트 작업 복사본을 준비하는 방법과 실패 결과를 가져오는 경로를 함께 검토해야 합니다. Xcode 테스트 실행의 명령과 결과 해석은 Apple의 테스트 실행 및 결과 해석 문서에서 확인할 수 있습니다.
CI에서 테스트가 실패한 뒤에도 원인을 확인할 수 있도록 결과 경로와 수집 절차를 먼저 정합니다. Xcode 테스트 실행은 결과 번들을 생성할 수 있으므로, 원격 실행에서는 이 파일을 작업 결과로 보관할 위치를 lane과 파이프라인 설정에 반영합니다. 결과 번들은 테스트 상태를 다시 살펴보는 데 도움이 되지만, 저장이나 업로드가 자동으로 보장되는 것은 아닙니다. 실제 보관 위치와 접근 권한은 팀의 CI 설정에서 확인해야 합니다.
다음 항목을 순서대로 점검합니다.
fastlane은 CI에서 테스트를 호출하는 구성도 문서화하고 있습니다. 기존 파이프라인에 lane을 연결하기 전, fastlane의 CI 통합 안내를 참고해 실행 환경과 결과 수집 단계를 검토하세요. 특정 CI 제품의 설정을 그대로 복사하기보다는 팀의 작업 정의와 아티팩트 보관 정책에 맞춰 적용해야 합니다.
원격 맥에서 선택한 Xcode와 설치된 시뮬레이터 런타임을 먼저 확인합니다. 이어서 사용할 수 있는 기기 이름과 lane의 devices 설정이 정확히 일치하는지 비교하세요. 로컬 맥에서 보이는 이름이 원격 환경에도 있다는 보장은 없습니다. 프로젝트의 scheme과 테스트 계획까지 확인한 뒤에도 대상이 없으면, 해당 맥에서 그 런타임을 사용할 수 있는지부터 판단합니다.
테스트 결과의 저장 경로를 명시하고, 파이프라인이 실패한 작업에서도 그 경로를 수집하도록 설정합니다. 실행 로그와 결과 번들이 함께 남는지 실제 실패를 포함한 테스트 작업으로 확인하세요. 성공한 작업에서만 파일을 보관하도록 구성하면 실패 원인을 검토할 수 없습니다. 팀의 보관 정책에 따라 다운로드 권한과 파일 보존 위치도 따로 검수해야 합니다.
그렇지 않습니다. 시뮬레이터 테스트는 선택한 시뮬레이터 환경에서 앱과 테스트가 실행됐다는 근거입니다. 실제 기기의 하드웨어와 동작을 확인했다는 근거는 아닙니다. Apple의 시뮬레이터 및 실제 기기 실행 안내처럼 실행 대상의 차이를 고려하고, 프로젝트가 기기별 기능을 검증해야 하는 경우에는 별도 기기 테스트를 계획하세요.
첫 실행이 끝나면 같은 커밋을 기준으로 원격 재실행, 실패 피드백, 결과 다운로드, 노드 복구를 확인합니다. 이 흐름에서 결과를 다시 열 수 있고 실패 위치를 구분할 수 있으면 CI 연결을 검토할 수 있습니다. 결과가 남지 않거나 로컬과 원격의 환경 차이를 설명할 수 없다면, 정식 적용 전에 설정을 조정하고 재시험합니다.
시뮬레이터만으로 충분한 프로젝트는 그 범위에 맞춰 자동화를 운영할 수 있습니다. 실제 기기 동작이 제품 검수 조건이라면 별도 기기 검증을 추가해야 합니다. 이 차이를 명시해야 테스트 통과 결과를 배포 승인으로 과대 해석하지 않습니다.
현재의 로컬 실행은 장비를 계속 켜 두어야 하고, 개발자마다 도구 체인이나 의존성 상태가 달라질 수 있으며, 원격 팀원이 같은 환경을 쓰기 어렵다는 단점이 있습니다. 반면 원격 맥은 접속 안정성, 결과 회수 절차, 필요한 Xcode 환경을 실제 프로젝트로 먼저 검증해야 하며, 장기간 계속 사용하는 팀이라면 구매가 더 적합할 수도 있습니다. 프로젝트 scheme 하나를 원격 맥에서 먼저 실행해 요구 조건을 확인한 뒤, 임시 테스트나 구축 전 검증이 목적이라면 VNCMac의 서비스 안내에서 이용 방식을 살펴보고, 원격 맥 이용 안내에서 도구 체인과 사용 기간이 맞는지 판단하세요.