Xcode 27 러너 GA: 빌드 성공과 Apple Silicon 호환성을 따로 검증하기
러너 이름을 바꾸고 녹색 체크를 받았는데 배포 직전에 네이티브 라이브러리 오류가 난다면, 이행에서 무엇을 확인한 것일까. GitHub가 2026년 10월 15일 Xcode 27 러너 이미지의 정식 제공을 발표했다. Apple 앱을 만드는 작은 팀에 필요한 판단은 새 이미지 사용 여부만이 아니다. 툴체인 선택, 실행 아키텍처, 실제 배포 결과를 각각 증명해야 한다.
정식 제공 범위부터 좁혀 읽기
공식 발표에 따르면 이미지는 macOS 27에서 실행되며 Xcode 27 툴체인과 Apple SDK를 포함한다. runs-on에는 xcode-27 또는 xcode-27-xlarge를 지정한다. 이미 이 레이블을 쓴 워크플로는 변경할 필요가 없다. 단, 제공 대상은 Apple Silicon arm64 러너이며 Intel 러너에는 제공되지 않는다. 각 이미지는 특정 OS보다 Xcode 주 버전을 선택하는 구조다. GA라는 표현을 모든 기존 의존성의 호환성 보증으로 넓혀 읽지 말자.
첫 번째 증거: 실제로 선택된 도구
이하 절차는 공식 추가 기능이 아니라 팀 운영 제안이다. 우선 배포용 워크플로를 덮어쓰지 말고 같은 커밋으로 비교용 실행을 만든다. 러너 레이블, uname -m 결과, xcodebuild -version, 선택된 개발자 디렉터리, SDK 목록을 로그에 남긴다. 비밀값이나 서명 자산은 출력하지 않는다. 이름만 기록하면 사전 설치된 도구와 실제 선택된 도구가 다른 상황을 놓칠 수 있다. 실패 로그에는 커밋과 실행 식별자를 함께 남겨 재현 출발점을 고정한다.
두 번째 증거: 네이티브 의존성의 실행 경로
질문을 두 개로 나누자. 러너에서 실행되는 코드 생성기·패키지 설치 스크립트·사전 빌드 도구가 arm64에서 동작하는가. 그리고 최종 앱의 각 대상에 필요한 바이너리가 포함되는가. 이 둘은 같은 검사가 아니다. 패키지 캐시는 툴체인과 아키텍처 경계를 반영하도록 검토하고, 첫 비교 실행은 캐시 없는 결과도 확보한다. 장애가 사라질 때까지 캐시만 반복 삭제하면 어떤 조건이 원인이었는지 증거가 사라진다. 시뮬레이터 테스트 하나로 실제 기기용 아카이브 검증을 대신하지 않는다.
세 번째 증거: 릴리스 후보와 복귀 경로
컴파일·테스트·아카이브·내보내기를 별도 결과로 남긴다. 비교용 실행에서 서명을 다루려면 기존의 승인된 비밀 관리 경로를 사용하고, 자격증명을 로그에 추가하지 않는다. 내부 배포에서 설치와 앱 시작까지 확인한 후보에 대해 전환을 결정한다. 이전 워크플로와 재실행 가능한 커밋을 남겨 두면 문제가 나타났을 때 되돌릴 기준이 생긴다. 이 글은 실행 시간 단축이나 비용 절감을 보장하지 않는다. 성능 판단에는 같은 커밋·캐시 조건·테스트 범위로 측정한 자체 결과가 필요하다.
개발자 커뮤니티의 반응을 수치화한 자료는 이번 조사에서 사용하지 않았다. 대신 이행 때 자주 뒤섞이는 질문을 점검표로 정리했다. 최신 툴체인이 필요한 프로젝트라도 모든 저장소를 동시에 전환할 이유는 없다. 네이티브 의존성이 많은 앱과 단순 앱을 구분하고, 실패했을 때 담당자가 읽을 로그 위치를 정한다. GA 도입을 미루는 비용도 있으므로 무조건 보류하는 대신 제한된 후보 하나에서 확인 범위를 합의하는 편이 실용적이다.
이번 주 실행할 일은 작게 잡을 수 있다. 대표 앱 하나와 비교 커밋 하나를 고르고, 기존 실행과 xcode-27 실행의 도구·테스트·아카이브 결과를 연결한다. runner-images 저장소에서 설치 소프트웨어를 확인하고 문제는 재현 조건과 함께 기록한다. 팀의 완료 조건을 ‘녹색 체크’에서 ‘동일 커밋의 설치 가능한 후보와 복귀 증거’로 바꾸는 것이 이행의 핵심이다.
공식 출처
GitHub Changelog · Xcode 27 GA
현재 쓰는 Apple 앱 워크플로 한 개에서 이 세 가지 증거를 먼저 연결해 보자.