증상 → 빠른 해결: macOS 26에서 일반적인 Apple Silicon 대상 빌드를 시작한다면 arm64 러너를 먼저 시험하세요.
Intel 동작·의존성·배포 대상을 확인해야 할 때만 Intel 러너를 추가하고, 양쪽 지원이 요구되면 빌드와 테스트를 아키텍처별 행렬로 분리하세요.
이 글은 iOS·macOS 프로젝트의 CI 러너를 고르는 독립 개발자, Apple 플랫폼 팀, CI·개발 플랫폼 담당자를 위한 안내입니다.
2026년 11월 2일 기준 GitHub와 Apple의 공식 문서를 확인했습니다. 러너 태그와 이미지 상태는 바뀔 수 있으므로 배포 전 공식 자료를 다시 확인해야 합니다. macOS 26 러너 GA 안내와 Xcode 27 이미지 GA 안내를 기준으로 정리했습니다.
SECTION 01GitHub Actions macOS 26 러너 선택은 무엇을 기준으로 하나요?
macos-26과 macos-26-intel은 같은 이름의 실행 환경이 아닙니다. GitHub 문서에서 제공하는 태그와 아키텍처 대응을 확인한 뒤, 프로젝트가 실제로 빌드·테스트·배포해야 하는 대상을 기준으로 선택하세요. 러너 호스트의 CPU 아키텍처와 앱이 지원하는 대상 아키텍처는 별개의 조건입니다. 작업에 사용할 러너를 선택하는 GitHub 문서에서 태그와 적용 범위를 확인할 수 있습니다.
특히 빌드가 성공했다는 사실만으로 다른 아키텍처에서의 실행 가능성까지 검증됐다고 볼 수는 없습니다. 빌드 산출물의 아키텍처와 실제 테스트 범위를 따로 기록해야 합니다. Apple은 여러 아키텍처를 포함하는 macOS 바이너리 구성을 안내하고 있습니다.
SECTION 02독립 개발자는 주된 빌드 목표에 맞춰 선택합니다
개인 프로젝트라면 모든 작업을 처음부터 두 아키텍처에서 실행하기보다, 현재 배포하거나 테스트할 대상을 먼저 좁히세요. iOS 프로젝트에서 일상적인 빌드와 테스트가 주 업무라면 arm64 태그로 제한된 시험 실행을 하고, Intel 사용자를 지원하거나 Intel 환경의 오류를 재현해야 할 때 Intel 작업을 추가하는 편이 관리하기 쉽습니다.
iOS 프로젝트에는 어떤 태그를 먼저 적용하나요?
일반적인 iOS 빌드의 기본 후보는 macos-26입니다. 다만 이것을 모든 의존성이나 스크립트가 arm64에서 동작한다는 보증으로 해석해서는 안 됩니다. 프로젝트의 실제 빌드·테스트 작업을 실행하고, 실패한 명령과 의존성 정보를 확인하세요. GitHub의 호스팅 러너 사용 안내에서 사용 가능한 실행 환경과 적용 조건도 함께 확인해야 합니다.
작은 시험 실행은 기존 워크플로 전체를 교체하지 않고도 빠진 조건을 찾는 방법입니다. 빌드, 유닛 테스트, 시뮬레이터 테스트, 서명과 배포를 한 덩어리로 판단하지 말고, 어떤 작업이 어느 태그에서 통과했는지 구분해 남기세요.
SECTION 03Apple Silicon 중심 팀은 의존성까지 함께 검증합니다
Apple Silicon을 기본 개발 대상으로 삼는 팀은 arm64 워크플로가 코드만이 아니라 도구와 의존성까지 포함해 완결되는지 확인해야 합니다. 사전 빌드된 바이너리, 셸 스크립트, 캐시, 서드파티 Action이 특정 아키텍처를 전제로 하면 앱 코드가 정상이어도 작업이 중단될 수 있습니다.
Xcode 27을 사용하는 작업이라면 러너 태그만 보고 이미지에 필요한 도구가 있다고 단정하지 마세요. GitHub의 Xcode 27 이미지 안내와 Apple의 Xcode 27 릴리스 노트를 확인하고, 프로젝트가 쓰는 SDK와 명령을 실제 작업에서 실행해 보세요. Xcode의 요구 환경은 Apple 시스템 요구 사항에서도 확인할 수 있습니다.
SECTION 04Intel 지원 앱 팀은 빌드와 호환성 검증을 나눕니다
macos-26-intel은 Intel 환경에서 동작하는 빌드나 동작을 확인해야 할 때 가치가 있습니다. Intel용 산출물을 계속 제공하는지, Intel에서만 재현되는 문제가 있는지, 사용자 지원 범위에 해당 아키텍처가 남아 있는지 먼저 판단하세요.
macOS 26 Intel 러너는 어떤 검증에 맞나요?
Intel 지원 앱의 실제 빌드·테스트, 아키텍처별 동작 차이 확인, Intel에서만 나타나는 오류 재현처럼 이유가 분명한 작업에 배정하세요. arm64에서 빌드가 통과한 것만으로 Intel 호환성이 확인됐다고 결론 내리면 안 됩니다. 필요한 경우 Intel 러너에서 산출물과 테스트를 별도로 확인하고, 그 결과를 지원 기준과 연결해야 합니다.
Apple의 Apple Silicon 빌드 오류 해결 안내는 아키텍처 관련 문제를 진단할 때 참고할 수 있습니다. 특정 오류가 Intel에서만 재현된다면 그 작업만 Intel 태그로 분리하고, 관련 없는 워크플로까지 Intel로 바꾸지는 마세요.
SECTION 05레거시 의존성 팀은 실패 근거가 있을 때 예외를 둡니다
오래된 바이너리 의존성이나 아키텍처를 가정한 빌드 스크립트가 있다면 러너를 바꾸기 전에 목록을 만드세요. 의존성 설치 단계, 컴파일 단계, 테스트 단계 중 어디서 실패하는지 기록하면 문제의 범위를 좁힐 수 있습니다. 오류 로그와 함께 아키텍처별 차이를 확인하되, 문서만으로 프로젝트의 호환성을 추정하지 말고 실제 작업으로 검증하세요.
Intel에서만 오류가 재현되는 경우에는 그 작업에 한해 Intel 러너를 지정할 수 있습니다. 다만 예외에는 담당자, 적용 이유, 재검토 조건을 적으세요. 의존성 갱신으로 arm64에서도 통과하게 되면 오래된 예외를 그대로 남기지 않도록 합니다.
SECTION 06서명·배포 팀은 서로 다른 제약을 따로 확인합니다
코드 서명, 테스트 기기 등록, 러너 아키텍처는 서로 바꿔 쓸 수 있는 조건이 아닙니다. 서명 자격 증명과 프로비저닝 설정은 배포 흐름에서 점검하고, 테스트 기기 요건은 해당 테스트 절차에서 확인하세요. 호스트 아키텍처는 빌드와 실행 작업에서 검증해야 합니다.
배포 과정이 특정 기기 식별 정보나 호스트 동작에 의존한다면, 실제로 사용하는 태그와 워크플로에서 재현해 보세요. 특정 제한을 모든 호스팅 러너에 일반화하지 말고, 해당 조건이 적용되는 러너 유형인지 GitHub의 큰 사양 러너 문서에서 확인하세요.
SECTION 07CI 플랫폼 책임자는 기본값과 예외를 문서화합니다
플랫폼 담당자는 팀의 지원 약속에 맞춰 기본 태그, 아키텍처 행렬, 예외 작업을 정해야 합니다. 같은 저장소 안에서도 일반 빌드는 arm64로, Intel 검증은 별도 작업으로 둘 수 있습니다. 두 아키텍처를 모두 지원하는 프로젝트라면 두 작업의 산출물과 테스트 결과를 각각 보관하세요.
Xcode 27 작업은 어느 러너에서 시작하나요?
먼저 프로젝트에서 요구하는 Xcode 이미지가 실제 러너 환경에서 사용 가능한지 GitHub의 이미지 공지와 현재 문서로 확인하세요. 그다음 arm64에서 빌드와 테스트를 시험하고, Intel 지원을 검증해야 하는 프로젝트에만 Intel 작업을 더합니다. Xcode 버전이 같다는 이유만으로 두 러너의 결과가 서로 대체 가능하다고 가정하지 마세요.
다음 조건 분기로 기본 구성을 정할 수 있습니다.
- Apple Silicon 대상 빌드가 주된 목표라면 arm64 태그로 시작합니다.
- Intel용 빌드나 Intel에서의 실제 동작 확인이 지원 요구에 포함되면 Intel 작업을 추가합니다.
- 양쪽 아키텍처를 배포하거나 검증해야 한다면 각각의 빌드와 테스트를 행렬로 분리합니다.
- 특정 레거시 의존성이 Intel에서만 동작한다면 그 의존성을 쓰는 작업에만 Intel 태그를 지정합니다.
- 지속적으로 유지되는 환경이나 호스트 제어가 필수일 때만 호스팅 러너 외의 전용 맥 운영 방식을 비교합니다.
실행 전에는 아래 순서로 확인하세요.
- 앱의 지원 아키텍처와 실제 배포 산출물을 문서로 정리합니다.
- 빌드 도구, 바이너리 의존성, 스크립트, 서드파티 Action의 아키텍처 요구를 확인합니다.
- 현재 워크플로를 복사해 시험 작업을 만들고, 우선 후보 태그에서 실제 프로젝트를 실행합니다.
- 빌드 성공 여부와 테스트 범위를 분리해 기록하고, 산출물의 아키텍처를 확인합니다.
- Intel 지원이나 오류 재현이 필요하면 해당 작업만 Intel 태그에서 실행합니다.
- 기본 태그, 행렬 구성, 예외 사유와 재검토 책임자를 CI 문서에 남깁니다.
아래 두 표는 시험 결과를 팀 설정으로 옮길 때 활용할 수 있습니다. 러너의 현재 태그와 이미지 제공 상태는 변경될 수 있으므로, 적용 전 GitHub 문서에서 다시 확인하세요.
| 팀의 요구 | 기본 선택 | 시험에서 확인할 내용 |
|---|---|---|
| Apple Silicon 대상의 일상 빌드 | arm64 태그 | 의존성 설치, 빌드, 테스트가 모두 통과하는지 |
| Intel 사용자 대상의 빌드 또는 검증 | Intel 태그 작업 추가 | Intel용 산출물과 실제 테스트 결과 |
| 양쪽 아키텍처 지원 | 아키텍처별 행렬 | 각 작업의 산출물과 테스트가 독립적으로 확인되는지 |
| Intel에서만 재현되는 레거시 오류 | 해당 작업에만 Intel 태그 | 재현 로그와 예외가 필요한 범위 |
| 지속적인 호스트 제어가 필요한 작업 | 전용 맥 환경도 비교 | 유지 관리 책임과 필요한 운영 방식 |
| 검증 결과 | CI 구성에 반영할 결정 |
|---|---|
| arm64에서 필요한 빌드와 테스트가 통과하고 Intel 지원 요구가 없음 | arm64를 기본 태그로 유지 |
| Intel 배포 또는 호환성 확인이 제품 지원 범위에 포함됨 | Intel 빌드·테스트를 별도 작업으로 추가 |
| 두 아키텍처를 모두 제공해야 함 | 아키텍처별 빌드와 테스트를 행렬로 실행 |
| 특정 작업만 호스트 제어 또는 지속 환경을 요구함 | 그 작업에 한해 원격 맥 운영을 검토하고 시험 결과로 판단 |
호스팅 러너는 작업마다 정해진 실행 환경을 쓰기 편하지만, 팀이 직접 관리하는 호스트 상태나 지속적인 작업 환경이 필요하면 별도의 운영 부담을 따져야 합니다. 반대로 모든 CI 작업을 전용 맥으로 옮기면 호스트 유지와 접근 관리가 늘어날 수 있습니다. 현재 구성이 일반 호스팅 작업만으로 충분하다면 먼저 러너 태그와 행렬을 정리하세요. 장기간 유지할 통제된 맥 환경이 실제로 필요한 경우에만 MACNOX의 맥 환경 안내를 확인하고, 필요한 조건이 맞는지 요금 및 이용 조건과 비교해 보세요.