GitHub Actions macOS Runner 대기가 길 때: 2026년 증설 판단
macOS job만 대기 중이고 다른 검사는 끝났는데, 빌드 단계는 시작되지 않나요?
먼저 job이 step에 들어갔는지 확인하세요. 실행 전 대기는 워크플로 동시 실행, Runner 라벨과 그룹, 호스팅 용량 문제로 나눠 점검해야 합니다. 원인을 구분하기 전에는 반복 재실행이나 즉시 증설을 피하고, macOS 작업이 계속 밀릴 때만 자체 호스팅 Mac Runner를 병행 대안으로 평가합니다. 이 방식도 GitHub 서비스 측 조정 문제를 고치지는 못합니다.
이 글은 iOS 빌드나 배포 job이 밀려 합치기와 출시 일정이 영향을 받는 독립 개발자와 소규모 팀을 위한 안내입니다. 자체 호스팅 Runner의 온라인 상태와 작업 수신 여부를 관리하는 개발자도 대상입니다.
마지막 업데이트: 2026년 11월 11일. GitHub 공식 제한, Runner 안내, 자체 호스팅 Runner 점검 문서와 GitHub Status를 기준으로 확인했습니다. 공식 제한 문서
대기와 실행 중 오류, 먼저 증거로 구분합니다
전체 실행 시간이 길다는 사실만으로 대기 원인을 확정할 수는 없습니다. job이 Runner에 배정되기 전 기다린 시간과, 배정된 뒤 Xcode 빌드나 테스트가 실행된 시간을 나눠 봐야 합니다.
GitHub Actions 화면에서 해당 job의 상태와 타임라인을 확인하고 로그를 엽니다. 아직 step이 하나도 나타나지 않았다면 컴파일 오류보다 Runner 배정이나 취소 이유를 먼저 조사합니다. 반대로 checkout이나 빌드 step이 시작된 뒤 실패했다면 그 시점의 로그와 workflow 명령을 확인합니다.
다음 표처럼 증거가 가리키는 분기부터 선택하면 불필요한 재실행을 줄일 수 있습니다.
| 관찰된 상태 | 우선 확인할 항목 | 다음 판단 |
|---|---|---|
| 어떤 step도 시작하지 않은 채 Queued | GitHub Status, Runner 할당 관련 로그, 동시 실행 설정 | 플랫폼 상태 또는 workflow 대기 규칙 확인 |
| 자체 호스팅 Runner가 대기열에 나타나지 않음 | 온라인 상태, 사용 중 여부, 라벨과 Runner 그룹 | Runner가 작업 조건에 맞는지 확인 |
| Runner가 연결된 뒤 초기화에 실패 | Runner 서비스 로그, 작업 디렉터리, 시작 과정 | 호스트의 실행 환경 문제인지 분리 |
| 빌드나 테스트 step이 시작된 뒤 실패 | 해당 step 로그, Xcode와 빌드 명령 | 빌드 오류로 따로 조사 |
GitHub의 호스팅 Runner 안내는 호스팅 Runner가 작업을 실행하는 방식을 설명합니다. job이 시작됐는지 모호하다면 워크플로 문제 해결 문서의 로그와 실행 기록 점검 방법을 참고하세요.
호스팅 Runner 대기와 자체 Runner 미수신은 원인이 다릅니다
GitHub-hosted macOS Runner를 선택한 job이 step 실행 전에 취소되거나 Runner를 얻지 못했다면, 먼저 GitHub Status에서 Actions 관련 공지를 확인합니다. 그다음 제한 문서의 배정 및 대기 관련 설명과 job 로그를 대조합니다. GitHub 문서는 macOS Runner가 제때 처리되지 못하면 작업이 버려질 수 있다고 안내합니다. 같은 문서에 있는 제한을 확인하되, 원인이 불분명한 상태에서 프로젝트 전체의 빌드 문제로 단정하지 않습니다.
2026년 11월 3일부터 9일까지 GitHub Community에는 macOS arm64 job에서 용량 안내를 보거나 step 실행 전에 실패했다는 사용자 보고가 올라왔습니다. 이는 해당 기간의 개별 보고이며, 모든 계정에 영향을 준 보편적 장애나 공식적으로 확인된 원인을 뜻하지 않습니다. 관련 커뮤니티 논의를 참고할 때도 현재 공식 상태와 구분해야 합니다.
자체 호스팅 Mac Runner가 작업을 받지 못했다면 점검 지점이 다릅니다. Runner 모니터링 안내에 따라 호스트의 온라인 상태와 서비스 로그를 확인하고, workflow가 요구하는 라벨 및 Runner 그룹이 실제 등록 정보와 일치하는지 비교합니다. 자체 호스팅 Runner 설정 안내도 함께 확인하면, 작업이 배정되지 않은 경우와 머신이 작업을 받은 뒤 초기화에 실패한 경우를 나누는 데 도움이 됩니다.
첫 번째 단계: 동시 실행과 반복 트리거를 확인합니다
대기가 커밋이나 작업 수가 늘어난 시점부터 시작됐다면, GitHub 서비스 용량을 의심하기 전에 workflow의 실행 규칙부터 살펴봅니다. 같은 변경으로 macOS 빌드가 여러 번 시작되는지, pull request와 배포 workflow가 중복으로 실행되는지 확인합니다. 테스트 행렬이 꼭 필요한 조합을 모두 포함하는지도 점검합니다.
특히 concurrency 설정은 대기 중 작업의 취소를 만들 수 있습니다. GitHub 문서는 같은 concurrency 그룹에 실행 중 작업 하나와 대기 중 작업 하나만 둘 수 있다고 설명합니다. 새 작업이 대기하면 앞서 대기 중이던 작업이 취소될 수 있습니다. 따라서 job이 “시작 전 취소”로 보일 때는 concurrency 동작 설명과 workflow의 그룹 이름을 함께 비교합니다.
concurrency:
group: ios-build-${{ github.ref }}
cancel-in-progress: true
예시처럼 cancel-in-progress: true가 설정되어 있다면 같은 그룹의 새 실행이 기존 실행을 취소할 수 있습니다. 이 동작이 의도된 것인지 먼저 확인합니다. 최신 커밋만 검증하면 되는 빌드와, 각각의 변경을 빠짐없이 확인해야 하는 검증은 취소 정책이 달라야 할 수 있습니다.
비용이 큰 macOS job 전에 소스 검사나 플랫폼에 종속되지 않는 검사를 진행하도록 workflow를 나누는 것도 선택지입니다. 중복 검증을 합치거나 불필요한 macOS job을 줄이면 프로젝트 내부 대기는 줄어들 수 있습니다. 하지만 이런 편집이 GitHub 호스팅 측 용량 부족을 해결한다고 보장할 수는 없습니다.
대기 원인별로 기다리기, 설정 조정, 실행 환경 추가를 고릅니다
| 원인 후보 | 근거로 볼 기록 | 권장 조치 | Mac Runner 추가의 역할 |
|---|---|---|---|
| GitHub Status에 관련 이슈가 표시됨 | 상태 공지와 job 시간대가 일치하는지 확인 | 공지와 로그를 저장하고 상태 갱신에 따라 재실행 판단 | 서비스 측 장애를 해결하지 못함 |
| 자체 workflow의 동시 실행 규칙 | 같은 그룹의 대기 job 취소가 반복되는지 확인 | 그룹과 취소 정책, 중복 트리거 조정 | 설정 문제를 대신 해결하지 못함 |
| 자체 호스팅 Runner가 오프라인이거나 조건 불일치 | Runner 상태, 서비스 로그, 라벨 및 그룹 비교 | Runner 복구 또는 workflow의 라우팅 조건 수정 | 정상 등록과 라우팅이 확인된 뒤에만 대안 |
| macOS 작업량이 계속 늘어남 | 반복되는 macOS 대기와 실제 병목 구간 확인 | 대표 프로젝트로 추가 실행 환경을 시험 | 팀 작업을 받을 Mac 환경을 병행할 수 있음 |
판단을 실행 순서로 옮기면 다음과 같습니다.
- 첫 번째 단계: job 타임라인에서 Runner 배정 여부와 첫 step 시작 여부를 기록합니다.
- 두 번째 단계: 대기와 취소가 발생한 시간에 GitHub Status와 공식 제한 안내를 확인합니다.
- 세 번째 단계: 자체 호스팅이라면 Runner 온라인 상태, 사용 중 여부, 라벨과 그룹을 대조합니다.
- 네 번째 단계: workflow의
concurrency, 반복 트리거, 행렬 작업과 중복 검증을 확인합니다. - 다섯 번째 단계: 원인이 프로젝트 설정이면 설정을 바꾸고, 플랫폼 측 문제라면 로그를 보관한 뒤 공식 상태를 보고 재실행 시점을 정합니다.
- 여섯 번째 단계: 대기가 반복되고 팀에 별도 Mac 실행 환경이 필요하다면 대표 프로젝트로 대체 Runner를 검증합니다.
자체 호스팅 Mac Runner는 팀이 관리하는 추가 실행 환경을 두는 선택지입니다. 그러나 호스트가 오프라인이거나 라벨 조건이 맞지 않으면 job은 여전히 배정되지 않습니다. GitHub 측 조정이나 서비스 장애에도 직접 개입하지 못합니다. 그러므로 “Runner 추가”와 “대기 원인 해결”을 같은 의미로 취급하지 않아야 합니다.
대표 iOS 작업으로 대체 Runner를 검증합니다
실제 도입 여부는 짧은 연결 확인만으로 결정하지 않습니다. 기존 workflow에서 중요도가 높은 iOS 작업을 골라 다음 항목을 확인합니다.
- workflow가 의도한 Runner 라벨과 그룹으로 job을 보내는지 확인합니다.
- Runner가 실제로 job을 수신하고, 실행 시작과 종료 기록이 남는지 확인합니다.
- 프로젝트가 요구하는 Xcode 환경이 선택되는지 확인합니다.
- 대표 빌드나 테스트 명령이 완료되고 필요한 산출물이 생성되는지 확인합니다.
- 실패한 경우 Runner 수신 문제인지, 도구 환경 문제인지, 프로젝트 빌드 오류인지 로그로 구분합니다.
성공 여부는 “대기 화면에서 사라졌다”가 아니라 작업 수신, 도구 선택, 목표 빌드 또는 테스트, 산출물 확인으로 기록합니다. 이 절차는 GitHub 서비스 측 문제를 없애는 방법이 아니라, 팀의 iOS 빌드에 별도 Mac 실행 환경을 추가해도 되는지 평가하는 과정입니다.
자주 묻는 내용
macOS job이 계속 대기 상태일 때는 무엇을 먼저 확인하나요?
step이 시작됐는지와 Runner가 할당됐는지를 먼저 나눕니다. 시작 전이라면 GitHub Status와 공식 제한 안내를 확인하고, 자체 호스팅 Runner라면 온라인 상태와 라벨 조건을 검사합니다. 빌드 로그가 없는 상태에서 컴파일 설정부터 바꾸면 원인과 무관한 수정이 될 수 있습니다.
step 실행 전에 취소된 job은 어디부터 살펴보나요?
타임라인과 로그에서 Runner 할당 전 취소인지, Runner 연결 뒤 초기화 실패인지 구분합니다. 그 뒤 workflow의 concurrency 그룹과 취소 설정을 확인합니다. 같은 그룹의 새 실행 때문에 기존 대기 작업이 취소될 수 있으므로, 취소 기록을 확인하지 않고 재실행만 반복하지 않는 것이 좋습니다.
동시 실행 설정이 대기 원인인지 어떻게 판단하나요?
workflow의 concurrency 설정과 job 실행 기록을 나란히 봅니다. GitHub 공식 문서에 따르면 같은 그룹에는 실행 중 작업과 대기 중 작업이 각각 하나씩 허용되며, 새 대기 작업이 기존 대기 작업을 취소할 수 있습니다. 취소 시점과 그룹이 맞아떨어지면 우선 프로젝트 설정을 조정합니다.
자체 호스팅 Mac Runner가 iOS 빌드 대기를 줄여 주나요?
프로젝트가 계속 Mac 실행 환경을 필요로 하고 Runner가 정상적으로 작업을 받을 수 있다면 병행 대안이 될 수 있습니다. 하지만 GitHub 서비스 측 조정 문제를 해결하지는 않습니다. 등록 상태, 라벨, Xcode 환경, 빌드와 산출물을 실제 workflow로 검증한 뒤 적용 여부를 결정해야 합니다.
팀에 지속적으로 쓸 Mac 환경이 필요한 경우
원인이 자체 workflow의 동시 실행 설정이라면 먼저 설정을 바로잡는 편이 낫습니다. 반대로 GitHub 호스팅 상태와 별개로 팀에 지속적으로 작업을 받을 Mac 환경이 부족하다면, 원격 Mac을 대체 실행 환경으로 검토할 수 있습니다. 자체 장비는 직접 관리할 수 있지만 구매와 유지가 필요하고, 단기 검증에는 과한 선택일 수 있습니다. 클라우드 실행 환경은 GitHub 서비스 측 장애를 해결하지 못하므로 그 한계도 고려해야 합니다.
원격 Mac 환경과 이용 방식을 먼저 비교하려면 SFTPMAC의 원격 Mac 안내를 살펴볼 수 있습니다. 필요한 기간에만 Mac 환경을 시험하려는 경우에는 SFTPMAC의 Mac mini 대여 안내도 확인할 수 있습니다. 실제 선택 전에는 자신의 workflow에서 Runner 연결, Xcode 선택, 빌드와 산출물 검수가 되는지 먼저 확인해야 합니다. 안정적인 장기 고부하 작업이나 물리 장치 연결이 핵심이라면 자체 Mac이 더 적합할 수 있습니다.