Xcode 27 러너 정식 제공: GitHub Actions 전환 가이드

GitHub는 2026년 10월 15일 공지에서 Xcode 27 러너 이미지의 정식 제공을 알렸습니다. 공식 피드 게시 시각은 16일 UTC이며, 이번 글은 최근 48시간의 미중복 소재가 부족해 7일 범위에서 선정했습니다. 이미지에는 macOS 27, Xcode 27 도구 체인과 Apple SDK가 포함됩니다. Apple Silicon인 arm64 전용이며 Intel 러너용 이미지가 아닙니다.

버전 선택의 변화

기존처럼 운영체제 이름만 보고 도구 체인을 추정하기보다, 필요한 Xcode 주 버전을 직접 지정하는 방식입니다. 공지에 나온 라벨은 xcode-27과 xcode-27-xlarge입니다. 각 이미지는 하나의 Xcode 주 버전을 지원합니다. 이미 이 라벨을 쓰는 공개 미리보기 사용자는 정식 전환을 위해 워크플로를 바꿀 필요가 없습니다.

다만 정식 제공이 프로젝트 호환성을 보장하지는 않습니다. 네이티브 의존성, 시뮬레이터 런타임, 코드 서명, 기존 빌드 캐시를 따로 확인해야 합니다. 특히 Intel에서만 동작하는 바이너리 도구를 사용한다면 arm64 환경에서 실행할 수 있는지 먼저 조사하세요.

실행 전 준비

GitHub Actions가 허용된 저장소와 워크플로를 수정할 권한이 필요합니다. 조직의 러너 정책에서 해당 라벨을 사용할 수 있는지도 확인합니다. 로컬 Mac에 Xcode 27을 설치하는 과정이 아니라 GitHub 호스티드 환경을 선택하는 것이므로, 로컬 운영체제를 업그레이드할 필요는 없습니다.

다음 YAML은 공식 러너 라벨과 GitHub Actions 문법에 따른 예이며 실제 CI를 실행하지는 않았습니다. 저장소의 .github/workflows/xcode27-check.yml로 저장하고 기본 브랜치에 반영한 뒤 Actions에서 Run workflow를 선택합니다. 비용과 권한 검토가 끝난 시험 저장소에서 먼저 실행하세요.

name: Inspect Xcode 27
on:
  workflow_dispatch:
permissions:
  contents: read
jobs:
  inspect:
    runs-on: xcode-27
    timeout-minutes: 10
    steps:
      - name: Check toolchain
        run: |
          uname -m
          sw_vers
          xcodebuild -version
          xcrun simctl list devices available

최소 예제는 저장소 코드를 내려받지 않고 도구 체인만 확인합니다. 로그에서 uname의 arm64, macOS 버전, Xcode의 주 버전 27을 대조하고 사용 가능한 시뮬레이터 목록을 보존합니다. 정확한 세부 버전과 디바이스 목록은 이미지 갱신에 따라 달라질 수 있으므로 특정 모델이 항상 있다고 가정하지 않습니다.

앱 테스트 예제

실제 프로젝트에서는 위 steps의 버전 확인 단계 앞에 다음 체크아웃 단계를 추가한 뒤 아래 명령을 새 run 단계에서 실행합니다. 체크아웃 액션 버전은 공식 README에서 확인한 v7 기준이며 조직의 고정 SHA 정책이 있으면 검증한 커밋으로 고정합니다.

      - uses: actions/checkout@v7
        with:
          persist-credentials: false

App.xcodeproj와 App은 각각 자신의 프로젝트 파일명과 공유 scheme으로 바꾸세요. 외부 패키지를 쓰는 프로젝트는 네트워크 접근과 잠금 파일도 확인해야 합니다. 워크스페이스 기반 프로젝트라면 project 대신 workspace 옵션을 선택합니다.

xcodebuild -list -project App.xcodeproj
xcodebuild -showdestinations -project App.xcodeproj -scheme App
xcodebuild test \
  -project App.xcodeproj \
  -scheme App \
  -destination 'platform=iOS Simulator,id=REPLACE_WITH_AVAILABLE_UDID' \
  -resultBundlePath TestResults.xcresult

REPLACE_WITH_AVAILABLE_UDID는 첫 확인 단계와 showdestinations가 제시한 실행 가능한 대상 식별자로 바꿉니다. scheme은 CI가 볼 수 있도록 공유되어 있어야 합니다. 테스트가 통과하면 xcodebuild의 종료 코드 0과 테스트 성공 로그, xcresult 산출물을 함께 확인합니다. 테스트를 하나도 찾지 못한 빌드 성공을 테스트 통과로 해석하지 마세요.

주요 설정 선택

처음에는 xcode-27로 기준을 잡고 병목이 확인된 뒤 xlarge 필요성을 판단하는 것이 합리적입니다. 큰 러너가 모든 테스트를 빠르게 만드는 것은 아니며 직렬 테스트나 외부 네트워크 대기는 별도 병목입니다. timeout-minutes는 무한 대기를 제한하고 workflow_dispatch는 전환 실험이 매 push마다 실행되는 일을 막습니다.

이전 도구 체인으로 만든 빌드 캐시는 그대로 재사용하지 않는 편이 안전합니다. 기존 캐시 키에 Xcode 주 버전과 아키텍처를 포함해 분리하고, 새 캐시 도입 전 한 번은 깨끗한 빌드를 비교하세요. 이는 권장 운영 설계이며 이미지가 특정 캐시 정책을 강제한다는 뜻은 아닙니다.

권한과 비용

첫 시험에는 읽기 권한만 부여하고 배포 토큰이나 서명 인증서를 넣지 않습니다. 시뮬레이터 테스트와 실제 기기·스토어 배포의 서명 요구는 다릅니다. 서명이 필요한 프로젝트는 별도의 제한된 배포 절차에서 검증하세요. PR의 신뢰할 수 없는 코드에 운영 비밀을 노출하는 방식으로 전환 문제를 해결하면 안 됩니다.

호스티드 macOS 사용량과 큰 러너 비용은 계정, 저장소 공개 범위, 플랜, 러너 종류에 따라 확인해야 합니다. 정식 출시 공지는 이 작업의 실제 청구 금액을 보장하지 않습니다. 조직의 Actions 예산과 러너 사용 권한을 먼저 검토하고 시험 실행의 사용량을 확인한 후 전체 CI로 확대하세요.

오류와 되돌리기

작업이 queued 상태에서 진행되지 않으면 라벨 오타와 조직 정책, 사용 자격과 용량을 확인합니다. 실행은 되지만 명령이 실패한다면 Xcode 버전 로그, scheme 목록, 실행 대상 목록, arm64 호환 의존성 순서로 범위를 좁힙니다. 존재하지 않는 시뮬레이터 이름을 임의로 여러 번 바꾸는 것보다 실제 목록을 근거로 대상을 선택하는 편이 빠릅니다.

되돌릴 때는 전환 전 워크플로 커밋을 기준으로 runs-on과 관련 캐시 키를 복원합니다. 새 시험 워크플로만 추가했다면 해당 파일을 제거하는 PR로 되돌릴 수 있습니다. 이전 라벨의 제공 종료 여부는 별도로 확인해야 하며, 이미 실행한 작업 비용은 롤백으로 없어지지 않습니다. 새 러너 하나로 기존 배포 파이프라인 전체를 동시에 교체하지 않는 것이 핵심입니다.

출처