증상 → GitHub Actions의 Xcode 27 Runner에서 xcodebuild가 Simulator 목적지를 찾지 못한다면, 먼저 실행된 Runner 이미지와 활성 Xcode를 확인한 다음 Runtime과 scheme 목적지를 대조합니다.
가장 빠른 조치 → 프로젝트나 Xcode를 먼저 바꾸지 말고, 실패한 작업의 로그와 해당 실행기의 기기·Runtime 목록을 수집합니다.

이 안내는 GitHub Actions Xcode 27 Runner에서 iOS Simulator 테스트를 처음 설정하거나, 목적지 불일치 오류를 조사하는 CI 엔지니어를 위한 것입니다.
테스트가 시작되기 전에 실패하는 개발자와, 관리형 실행기에서 해결할지 원격 맥으로 옮길지 판단해야 하는 DevOps 엔지니어도 따라 할 수 있습니다.

목적지 오류가 난 단계를 먼저 분리합니다

xcodebuild의 “목적지와 일치하는 대상을 찾을 수 없음” 계열 오류가 나와도, 원인이 모두 Simulator 자체에 있는 것은 아닙니다. 빌드가 실패했는지, 테스트 실행 전에 destination 선택이 실패했는지, Simulator 시작 뒤 테스트가 실패했는지 구분해야 합니다.

GitHub Actions Xcode 27 Runner가 iOS Simulator를 찾지 못하는 이유는 무엇인가요?
Runner 이미지에 요청한 Runtime이나 기기가 없을 수 있습니다. 활성 개발자 디렉터리가 다른 Xcode를 가리키거나, scheme·테스트 target·destination 조건이 서로 맞지 않는 경우도 있습니다. 우선 GitHub Actions 작업 로그에서 실제 실행된 Runner 라벨, 이미지 정보, 실패 단계와 명령을 확인합니다. workflow 파일에 적힌 라벨만으로 작업에 사용된 이미지의 세부 구성을 단정하지 마세요. GitHub 작업 로그 문서는 실행 단계별 로그를 확인하는 방법을 안내합니다.

GitHub는 2026년 10월 15일 Xcode 27 Runner 이미지의 정식 사용 가능 상태를 알렸습니다. 공지에 따르면 해당 이미지는 macOS 27에서 실행되고 Apple Silicon Runner만 제공하며, xcode-27과 xcode-27-xlarge 라벨을 지원합니다. 이 정보는 공지에서 확인할 수 있지만, 특정 작업에 설치된 Runtime이나 기기 목록까지 영구적으로 보장하지는 않습니다. GitHub의 Xcode 27 Runner 공식 공지를 기준으로 상태를 확인하고, 실제 실행 이미지의 구성은 Xcode 27 Runner 이미지 안내에서 다시 확인하세요.

xcodebuild가 목적지를 찾지 못하면 무엇부터 확인해야 하나요?
요청한 scheme과 destination 문자열부터 확인합니다. 기기 이름이나 시스템 버전 조건이 실제 제공 목록과 다른지, 테스트 target이 해당 플랫폼을 대상으로 하는지 살펴봅니다. scheme을 지정한 상태로 xcodebuild -showdestinations를 실행해 선택 가능한 목적지를 출력하고, workflow에서 요청한 값과 비교합니다. Apple의 자동화 테스트 안내를 참고해 테스트 실행 명령과 목적지 설정을 함께 점검하세요.

Runtime과 기기 목록을 실제 실행기에서 확인합니다

이미지 이름이 맞아도 필요한 iOS Simulator Runtime이 설치되어 있다는 뜻은 아닙니다. 요청한 시스템 버전이 이미지에 없거나, Runtime은 있지만 원하는 기기 유형이 제공되지 않을 수 있습니다. xcode-27에서 사용 가능한 항목은 현재 실행된 이미지의 목록으로 판별해야 합니다.

현재 Runner에 어떤 iOS Simulator Runtime이 있는지 어떻게 확인하나요?
실패한 작업 안에서 xcrun simctl list runtimes를 실행해 Runtime 목록을 저장합니다. 이어 xcrun simctl list devices available로 사용 가능한 기기 목록을 확인합니다. 두 명령의 결과를 workflow가 요청한 시스템 버전과 기기 이름에 대조하면, Runtime 누락과 기기 선택 오류를 분리하기 쉽습니다. GitHub의 현재 macOS Xcode 27 이미지 목록은 이미지 구성 확인에 도움을 주지만, 이미지가 갱신될 수 있으므로 실행 당일 결과를 보관해야 합니다.

기록할 증거와 구분 기준

  • Runtime 목록에 요청한 시스템 버전이 없으면, 이미지에 해당 Runtime이 빠진 경우인지 확인합니다.
  • Runtime이 있지만 요청한 기기 이름이 없다면, 해당 기기 유형이 실제 목록에 있는지 살핍니다.
  • 기기가 목록에 존재하는데 시작 단계에서 실패하면, destination을 찾지 못한 문제와 Simulator 시작 문제를 별도로 기록합니다.
  • 기기가 시작되고 테스트가 진행된 뒤 실패하면, 오류를 destination 불일치로 분류하지 말고 테스트 결과와 실패 로그를 조사합니다.

Runner 이미지의 기기와 Runtime 구성은 업데이트에 따라 달라질 수 있습니다. 따라서 과거에 성공한 목록을 현재 실행의 보증으로 사용하지 말고, 실패한 작업에서 수집한 결과를 기준으로 판단합니다. 누락된 구성 요소를 설치해야 한다면 Apple이 안내하는 방법만 사용하고, 일회성 관리형 Runner에서 설치·유지하는 방식이 작업마다 재현 가능한지 먼저 검토하세요. Apple의 추가 Xcode 구성 요소 설치 안내에 설치 절차가 정리되어 있습니다.

활성 Xcode와 요청 조건이 서로 맞는지 대조합니다

이미지 목록에 Xcode가 있어도 작업이 그 Xcode를 사용한다고 바로 결론 내릴 수 없습니다. xcode-select -p로 활성 개발자 디렉터리를 확인하고, xcodebuild -version 출력과 작업 로그의 Xcode 경로를 함께 봅니다. Apple은 명령줄 도구가 사용할 Xcode를 개발자 디렉터리 설정으로 선택하는 방법을 설명합니다. 설정 확인은 Apple의 명령줄 도구 설정 안내를 참고하세요.

증거를 다음처럼 나누면 불필요한 재설치를 피할 수 있습니다.

  • 이미지와 활성 Xcode가 다름: Runner에 여러 Xcode가 있더라도 선택된 개발자 디렉터리가 기대한 버전을 가리키지 않을 수 있습니다. 실제 경로와 xcodebuild 출력을 나란히 기록합니다.
  • 활성 Xcode는 맞지만 Runtime이 없음: Runner 라벨만 바꾸기 전에 현재 이미지의 Runtime 목록을 확인합니다.
  • scheme 또는 target 조건이 맞지 않음: 앱 빌드 대상과 테스트 대상 플랫폼, destination 조건을 함께 대조합니다.
  • 이름은 맞지만 테스트 단계에서 실패: 기기 목록에 대상이 존재하는지 확인한 뒤, 부팅 오류와 테스트 실패를 destination 선택 오류에서 분리합니다.

예를 들어 workflow에서 시스템 버전이 포함된 기기 목적지를 지정했지만 실행기의 실제 목록에 그 조합이 없다면, 이름을 임의로 바꾸기보다 -showdestinations 출력과 Runtime 목록을 먼저 비교해야 합니다. 이 방식은 프로젝트 설정 변경이 원인인지, 이미지 구성이 원인인지 구분할 단서를 남깁니다.

로그와 재현 결과를 기준으로 복구를 결정합니다

다음 점검 목록을 실패한 작업에서 하나씩 수행합니다. 결과를 남기면 재시도 후 상태가 달라졌을 때 비교 기준을 잃지 않습니다.

  • [ ] 작업 로그에서 실제 Runner 라벨, 이미지 정보, 실패한 단계와 실행 명령을 기록합니다.
  • [ ] xcode-select -p와 xcodebuild -version 출력을 저장하고 기대한 Xcode 경로와 비교합니다.
  • [ ] xcrun simctl list runtimes 결과에서 요청한 iOS Simulator Runtime이 있는지 확인합니다.
  • [ ] xcrun simctl list devices available 결과와 workflow의 기기 이름·시스템 버전·UDID 조건을 대조합니다.
  • [ ] 같은 scheme으로 xcodebuild -showdestinations를 실행해 실제 선택 가능한 목적지를 확인합니다.
  • [ ] 같은 커밋과 같은 조건으로 다시 실행하고, 빌드·Simulator 시작·테스트 결과를 각각 기록합니다.

재현 실행에서는 한 번에 여러 설정을 바꾸지 마세요. Runner 라벨, 활성 Xcode, destination 조건을 동시에 바꾸면 어느 조치가 문제를 해결했는지 판별하기 어렵습니다. 수정 전후의 실행 로그와 테스트 결과를 함께 보관하면, 이후 이미지 변경으로 다시 실패했을 때 원인을 좁히는 데 도움이 됩니다.

어느 시점에 원격 맥에서 테스트해야 하나요?
실행기 이미지와 활성 Xcode, Runtime, 목적지 조건을 확인했는데도 필요한 구성이나 통제 가능한 환경을 관리형 Runner에서 확보할 수 없다면, 해당 테스트 작업만 별도 macOS 환경에서 재현하는 방안을 평가합니다. 동일한 커밋과 scheme으로 확인해야 원인 비교가 가능합니다. 원격 맥으로 옮긴다고 해서 Simulator 결과가 실제 iPhone이나 iPad에서의 검증을 대신하지는 않습니다. 기기별 동작이 중요하다면 실제 기기 검수도 별도로 유지하세요.

원격 환경을 검토한다면 먼저 원격 Mac CI 작업용 맥 미니 환경에서 프로젝트의 실행 방식과 필요한 접속 조건을 살펴보세요. 특정 지역에서 장기간 사용할 계획이라면 서울 맥 미니 환경 안내도 비교할 수 있습니다.

관리형 Runner는 workflow에 통합하기 편하지만, 이미지 구성은 갱신될 수 있고 필요한 Runtime을 지속적으로 통제하기 어렵습니다. 반대로 자체 Mac을 구매하면 장비와 유지 관리를 맡아야 하며, 일시적인 테스트 수요에도 유휴 장비가 생길 수 있습니다. 필요한 작업만 분리해 원격 Mac에서 실행하면 고정된 macOS 환경을 검증하는 선택지가 되지만, 장기간 무거운 작업이나 물리 기기 연결이 필수라면 직접 보유한 장비나 별도 기기 테스트가 더 알맞을 수 있습니다. MACCOME의 원격 Mac 환경은 이런 조건을 따져 본 뒤 특정 CI 작업의 재현 환경이 필요할 때 검토하세요.

마지막 업데이트: 2026년 10월 17일. Xcode 27 Runner 상태는 GitHub 공식 공지, 이미지 구성은 Runner 이미지 안내, 도구 체인 설정과 구성 요소 확인 방법은 Apple 개발자 문서를 기준으로 확인했습니다.