macOS 14 실행기 태그는 2026년 11월 2일 퇴역했으므로, 그대로 유지하지 말고 현재 지원되는 태그를 프로젝트의 macOS·Xcode·아키텍처 요구 사항에 맞춰 고른 뒤 격리 실행으로 검증해야 합니다. 해당 환경으로 바로 바꾸기보다 빌드, 테스트, 서명 결과가 기준선과 일치하는지 확인한 다음 전환하세요. GitHub의 퇴역 공지
이 글은 macos-14, macos-14-large, macos-14-xlarge를 사용하는 Apple 플랫폼 개발팀과 CI 엔지니어를 위한 안내입니다.
서명·테스트·배포를 맡은 담당자는 새 실행기에서 실제 워크플로를 확인하세요.
플랫폼 운영 담당자는 검증 기준과 되돌림 조건을 정하는 데 활용할 수 있습니다.
마지막 확인: 2026년 11월 8일. GitHub 퇴역 공지와 현재 호스팅 실행기 문서, 이미지 저장소 및 Apple의 Xcode 자료를 기준으로 확인했습니다. 태그와 이미지 내용은 바뀔 수 있으므로 실제 전환 직전에 다시 대조해야 합니다. 현재 실행기 문서
이전할 실행기 태그와 작업 범위부터 확인합니다
GitHub는 macos-14, macos-14-large, macos-14-xlarge 태그를 2026년 11월 2일 퇴역 대상으로 공지했습니다. 그러므로 이 세 태그를 쓰는 작업은 새 실행기 환경으로 옮겨야 합니다. 공지에서 제시한 이전 방향과 현재 제공되는 모든 태그·이미지 구성을 같은 정보로 취급해서는 안 됩니다. 지원 여부는 전환 시점의 호스팅 실행기 문서와 실행기 이미지 저장소에서 각각 확인하세요.
먼저 저장소 전체에서 runs-on 값을 검색해 영향을 받는 워크플로를 찾습니다. 재사용 워크플로와 행렬 구성에 태그가 들어간 경우도 확인해야 합니다. 설정 파일만 살펴보지 말고 과거 실행 기록과 배포 작업도 대조하세요. 분기나 수동 실행에서만 호출되는 작업은 일상적인 빌드 검색에서 빠질 수 있습니다.
각 작업에 대해 다음 내용을 기록해 두면 후보 태그를 좁히기 쉽습니다.
- 현재 지정한 실행기 태그와 실행기 크기
- 빌드와 테스트에 필요한 macOS, Xcode, SDK 버전
- 실행 중인 네이티브 의존성, 바이너리와 설치 스크립트
- 시뮬레이터 대상, 서명, 아카이브 및 배포 작업
- 사설 저장소 접근, 캐시, 비밀 값 등 실행에 필요한 조건
주의: 공지에 제시된 이전 방향이 곧 모든 프로젝트의 권장 태그라는 뜻은 아닙니다. 현재 지원 여부와 이미지별 소프트웨어 구성을 확인한 뒤 프로젝트 조건에 맞는 후보만 남기세요.
Xcode와 macOS 도구 체인의 호환성을 대조합니다
실행기 태그의 macOS 버전만 확인해서는 Xcode CI 환경이 호환되는지 알 수 없습니다. 새 이미지에 설치된 Xcode, SDK, 명령행 도구가 프로젝트의 요구 조건을 충족하는지 별도로 확인해야 합니다. 특히 도구 체인이 바뀌면 기존 코드나 의존성이 경고를 오류로 처리하거나, 빌드 설정과 테스트 동작이 달라질 수 있습니다.
프로젝트가 요구하는 Xcode 버전과 macOS 조합은 Apple의 Xcode 시스템 요구 사항에서 확인합니다. 릴리스별 변경과 지원 정보를 확인할 때는 Apple의 Xcode 26 릴리스 노트를 함께 살펴보세요. 정식 버전과 베타 버전은 구분하고, 문서에 있는 요구 조건을 현재 실행기에서 실제로 확인한 결과와 혼동하지 않아야 합니다.
새 환경에 임시 워크플로를 만들어 다음 항목을 로그로 남기세요.
- 실행기 태그와 실행 시점에 보고되는 macOS 버전
xcodebuild -version결과와 선택된 Xcode 경로- 프로젝트가 사용하는 SDK와 실제 빌드 대상
- 패키지 관리자와 네이티브 의존성 설치 결과
같은 태그라도 이미지의 소프트웨어 구성이 달라질 수 있습니다. 워크플로가 특정 설치 경로나 사전 설치된 도구에 기대고 있다면, 이미지 저장소의 소프트웨어 목록과 실제 실행 로그를 함께 비교하세요. 확인되지 않은 Xcode 버전을 태그 이름만 보고 가정하지 않는 것이 안전합니다.
아키텍처와 네이티브 의존성을 따로 검증합니다
macOS 14 이전에서 놓치기 쉬운 조건은 CPU 아키텍처입니다. 실행기 태그를 교체한 뒤에도 빌드가 시작될 수 있지만, 그 사실만으로 바이너리 패키지와 스크립트가 새 아키텍처에 맞게 준비됐다고 볼 수 없습니다. 아키텍처가 중요한 프로젝트는 현재 제공되는 실행기 정보와 이미지별 설치 목록을 확인해 후보 환경을 검토하세요.
의존성 설치, 컴파일, 테스트를 하나의 성공·실패 결과로 뭉뚱그리지 마세요. 각 단계의 로그를 따로 확인하면 어떤 바이너리나 스크립트에서 문제가 생겼는지 추적하기 쉽습니다. Intel 아키텍처에 의존하는 작업은 실제로 필요한 의존성을 먼저 확인하고, 지원 문서가 해당 아키텍처와 후보 실행기를 뒷받침하는지 검토해야 합니다. Intel이 반드시 필요하다면, 이를 제공하는 지원 환경이 확인되기 전까지 해당 작업을 새 기본 태그로 옮기지 말고 분리해 유지하세요.
행렬 워크플로를 사용하면 후보 실행기를 별도 항목으로 추가해 같은 작업을 비교할 수 있습니다. 구성 방법은 GitHub의 행렬 워크플로 문서를 참고하세요. 여러 후보를 한 번에 운영 기본값으로 바꾸기보다, 검증용 분기나 별도 워크플로에서 결과를 확인한 뒤 기본 실행기를 변경하는 편이 안전합니다.
조건별로 이전 여부를 결정합니다
다음 결정 조건을 순서대로 확인하세요. 각 항목은 새 태그를 선택하거나 전환을 보류하는 기준입니다.
- [ ] 프로젝트가 요구하는 macOS와 Xcode 조합이 Apple의 요구 사항에 맞고, 후보 실행기에서 실제로 확인됐다면 해당 태그를 격리 실행에 추가합니다.
- [ ] 필요한 CPU 아키텍처와 네이티브 의존성이 후보 실행기에서 확인됐다면 의존성 설치, 컴파일, 테스트를 각각 실행합니다. Intel 의존성을 충족하지 못하면 해당 작업은 분리해 유지합니다.
- [ ] 클린 빌드와 프로젝트 테스트가 통과하고 시뮬레이터 대상도 정상이라면 서명과 아카이브 검증으로 진행합니다. 하나라도 실패하면 기본 태그를 변경하지 않습니다.
- [ ] 서명, 아카이브, 배포 산출물이 기존 기준선과 일치하고 비밀 값 및 사설 의존성 접근도 확인됐다면 전환을 승인합니다.
- [ ] 실행 로그나 결과를 비교할 수 없거나 실패 시 되돌릴 경로가 없다면 전환을 보류하고 검증용 워크플로를 유지합니다.
이 기준은 “새 태그에서 한 번 실행됐다”는 사실을 완료 조건으로 오인하지 않게 해줍니다. macos-14 이전 과정의 기준은 태그 변경이 아니라 프로젝트가 필요로 하는 결과의 재현입니다.
자주 나오는 이전 질문을 검증 기준으로 바꿉니다
퇴역한 macOS 14 태그 대신 어떤 실행기를 선택해야 하나요?
현재 실행기 문서에서 지원 상태와 아키텍처를 확인한 뒤, 이미지 저장소에서 필요한 도구가 설치되는지 확인합니다. macos-15나 macos-26 같은 후보는 현재 지원 여부와 프로젝트의 Xcode 요구 조건이 모두 맞을 때만 시험하세요. 공지의 이전 안내만으로 모든 태그가 사용 가능하다고 판단하지 마세요.
macos-15 또는 macos-26으로 바꾸기 전에 무엇을 확인해야 하나요?
프로젝트의 macOS·Xcode·SDK 조합과 네이티브 의존성을 먼저 정리합니다. Apple의 시스템 요구 사항과 릴리스 노트를 대조하고, 새 실행기에서 실제 Xcode 버전과 설치된 도구를 기록하세요. 이후 같은 커밋으로 빌드와 테스트를 실행해야 태그 교체와 도구 체인 변경의 영향을 구분할 수 있습니다.
태그 변경 후 Xcode와 시뮬레이터 테스트가 정상인지 어떻게 확인하나요?
실제 Xcode 버전과 선택된 SDK를 기록하고, 프로젝트에서 사용하는 시뮬레이터 대상의 테스트를 실행합니다. 빌드 성공뿐 아니라 테스트 로그, 서명, 아카이브와 배포 산출물까지 기존 기준선과 대조하세요. 사용하는 시뮬레이터와 의존성이 새 이미지에서 확인됐는지도 별도로 살펴야 합니다.
Intel 빌드 작업은 어떻게 처리해야 하나요?
Intel 전용 바이너리나 스크립트가 정말 필요한 작업인지부터 확인합니다. 그런 의존성이 남아 있다면 후보 실행기의 아키텍처를 현재 GitHub 문서와 이미지 정보로 확인하고, 충족하지 못하는 작업은 분리해 유지하세요. 새 실행기에서 작업이 시작됐다는 사실만으로 네이티브 의존성이 호환된다고 판단해서는 안 됩니다.
빌드부터 서명까지 같은 기준으로 검수합니다
후보 실행기에서 대표 워크플로를 실행할 때는 같은 커밋과 같은 입력을 사용해 결과를 비교하세요. 새 환경에서 프로젝트를 깨끗하게 체크아웃한 뒤 의존성 설치, 빌드, 테스트, 서명과 아카이브를 차례로 확인합니다. 검증 로그에는 실행기 태그, Xcode 정보와 산출물 식별 정보를 남겨야 나중에 차이를 추적할 수 있습니다.
확인할 항목은 다음과 같습니다.
- 캐시를 사용하지 않는 클린 빌드와 의존성 복원
- 프로젝트가 실제로 사용하는 테스트 대상과 시뮬레이터
- 인증서와 프로비저닝 설정을 포함한 서명 과정
- 아카이브와 후속 배포 단계의 입력 및 산출물
- 실패 시 원인을 찾을 수 있는 빌드·테스트 로그
특정 시뮬레이터, 사설 패키지 또는 배포 자격 증명을 쓰는 프로젝트라면 해당 항목을 따로 검증해야 합니다. 한 번의 빌드 성공은 전체 전달 경로가 정상이라는 증거가 아닙니다. 캐시를 쓰는 워크플로는 캐시 키 변경이나 복원 결과도 살피세요. GitHub는 의존성 캐시의 동작과 설정을 별도로 안내합니다.
네트워크와 운영 책임을 전환 전에 확인합니다
관리형 실행기와 자체 호스팅 실행기는 운영 책임이 다릅니다. 자체 실행기를 검토한다면 사설 의존성에 접근할 수 있는지, 네트워크 정책과 비밀 값이 적절히 통제되는지 확인해야 합니다. 등록, 업데이트, 접근 권한과 네트워크 구성도 팀의 운영 범위에 포함됩니다. 관련 요구 사항은 자체 호스팅 실행기 운영 문서에서 확인하세요.
캐시가 있는 프로젝트는 캐시 적중 여부만 보고 결과를 승인하지 마세요. 이미지 변경과 도구 체인 변경이 캐시된 의존성에 어떤 영향을 주는지 확인하고, 클린 빌드와 캐시 사용 빌드를 구분해 기록합니다. 실행 대기 시간이나 가용성은 이전 이미지에서의 경험만으로 새 환경에서도 같다고 추정할 수 없습니다. 서비스 수준이나 대기 결과가 전환 기준이라면 팀의 실제 실행 기록을 기준으로 별도 판단해야 합니다.
전환 전에는 실패 시 되돌릴 태그와 워크플로 변경 지점을 정해 두세요. 새 실행기에서 테스트와 전달 검증이 끝나지 않았거나 사설 네트워크 접근이 불안정하면 기본 경로를 바꾸지 않는 편이 낫습니다. 원격 Mac 환경을 검증 후보로 살펴보려는 팀은 RUVCLOUD의 요금 정보를 확인하고, 실제 프로젝트의 접근 방식과 운영 조건에 맞는지 별도로 평가할 수 있습니다.
마이그레이션이 끝난 뒤에도 같은 프로젝트와 도구 체인으로 목표 환경을 다시 검수하는 과정은 필요합니다. 관리형 실행기에서 이미지와 운영 조건을 직접 통제하기 어렵거나, 장시간 접근 가능한 실제 Mac 개발 환경이 필요하다면 원격 Mac을 보완 경로로 검토할 수 있습니다. 다만 자체 Mac은 운영·업데이트 책임이 있고, 원격 환경은 네트워크와 접근 경로를 고려해야 하므로 모든 CI에 적합한 대안은 아닙니다. 일시적인 검증 환경이나 지속적으로 접속할 개발용 Mac이 필요할 때는 RUVCLOUD의 이용 환경을 확인해 해당 프로젝트의 요구와 맞는지 판단하세요.