2026년 9월 29일부터 GitHub Enterprise Cloud에서 자체 호스팅 Runner 버전 강제 적용이 시작됐습니다. GitHub 공식 공지에 따르면 2.329.0보다 낮은 Runner는 등록하거나 다시 등록할 수 없습니다. 따라서 등록 기준만 맞추지 말고 실행 지원 상태도 따로 확인한 뒤, 노드를 나눠 업데이트하고 실제 Mac CI 작업으로 검증해야 합니다.
적합: GitHub Actions macOS Runner를 운영하며 노드 버전과 작업 접수 상태를 함께 관리해야 하는 조직에 적합합니다.
부적합: 자체 호스팅 Runner를 사용하지 않거나 GitHub Enterprise Server만 운영해 해당 공지의 적용 대상이 아닌 경우에는 이 강제 적용을 기준으로 긴급 업데이트할 필요가 없습니다.
이 안내는 Runner 기기를 점검하고 올려야 하는 기업 IT 관리자, iOS/macOS CI 플랫폼을 맡은 플랫폼 엔지니어, 버전 감시와 유지보수 절차를 정하려는 기술 책임자를 위한 내용입니다.
마지막 확인: 2026년 10월 8일. 적용 범위와 시행일은 GitHub 공식 공지, 버전별 지원 상태는 Runner 버전 퇴역 API 문서에서 확인했습니다.
00먼저 적용 대상과 기준을 분리합니다
이번 변경은 모든 GitHub 배포 형태에 똑같이 적용되지 않습니다. GitHub Enterprise Cloud는 공지된 시행일을 기준으로 확인하고, 데이터 레지던시가 적용된 Enterprise Cloud는 2026년 7월 31일부터 강제 적용 대상입니다. GitHub Enterprise Server는 해당 공지의 적용 대상이 아닙니다. 제품과 배포 형태를 잘못 분류하면 불필요한 작업을 하거나, 필요한 노드 점검을 놓칠 수 있습니다. 공식 시행 공지에서 적용 범위를 먼저 대조하세요.
2.329.0이 등록과 워크플로 실행의 공통 하한인가요?
아닙니다. 2.329.0은 위 공지에 명시된 등록 및 재등록 기준입니다. 기존에 등록된 Runner가 워크플로를 실행할 수 있는 버전 기준은 새 Runner 버전이 배포되면서 달라지는 동적 조건입니다. 따라서 2.329.0을 장기 운영에 필요한 실행 최소 버전으로 고정해서는 안 됩니다. 현재 실행 지원 상태는 버전 퇴역 REST API에서 대상 버전을 조회해 확인합니다.
| 확인 항목 | 기준과 의미 | 운영 판단 |
|---|---|---|
| 신규 등록 또는 재등록 | GitHub Enterprise Cloud 공지상 2.329.0 미만은 등록할 수 없습니다. | 해당 기준을 충족해도 실행 지원까지 보장되지는 않습니다. |
| 워크플로 실행 | 지원 하한은 고정값이 아니라 버전 퇴역 정보에 따라 바뀝니다. | API에서 해당 버전의 실행 지원 종료 상태를 확인합니다. |
| 온라인 표시 | Runner와 GitHub 사이의 연결 상태를 보여줍니다. | 온라인만으로 작업 접수와 실제 빌드 성공을 판정하지 않습니다. |
01다음으로 Mac Runner 자산과 갱신 경로를 기록합니다
저장소, 조직, 엔터프라이즈 범위에 있는 macOS Runner를 한 목록으로 모읍니다. 버전과 온라인 여부뿐 아니라 유휴 또는 작업 중 상태, 등록 범위, 실행하는 워크플로, 설치 방식도 적습니다. 자산 목록이 없으면 어떤 노드가 등록 차단 대상인지, 어떤 빌드가 특정 구형 노드에 의존하는지 찾아내기 어렵습니다.
버전이 오래된 Runner는 바로 실행을 멈추나요?
등록이 차단되는 상태와 이미 등록된 Runner의 실행 지원 종료는 서로 다른 조건입니다. 구버전이어도 온라인으로 표시될 수 있지만, 그 표시만으로 현재 워크플로를 받을 수 있다고 결론 내릴 수는 없습니다. 작업이 대기열에 남거나 실제 실행이 실패한다면, 버전 지원 상태와 함께 모니터링 신호, Runner 로그, 워크플로 결과를 확인합니다. GitHub 모니터링 및 문제 해결 안내를 운영 점검에 활용하세요.
자산 목록에는 갱신 방식도 표시합니다. 기본 자동 업데이트를 사용하는 노드와 자동 업데이트를 끈 노드를 구분하고, 이미지나 컨테이너, 배포 자동화로 새 노드를 만드는 경우에는 그 원본도 함께 기록합니다. 오래된 설치 스크립트가 남아 있으면 갱신된 노드를 교체하는 순간 예전 Runner 버전이 다시 등록될 수 있습니다.
02퇴역 예정 버전을 찾아 업데이트 순서를 정합니다
각 버전의 등록 가능 여부와 워크플로 실행 지원 종료 상태를 공식 API로 확인한 다음, 결과를 자산 목록의 노드에 연결합니다. 실행 지원이 종료됐거나 종료가 예정된 노드부터 우선순위를 정하되, 빌드 영향도와 대체 노드 유무도 함께 고려합니다. 버전 확인 방법과 관리 범위는 GitHub 자체 호스팅 Runner 문서 및 Runner 관리 안내와 대조할 수 있습니다.
주의: 온라인 상태는 접속 여부를 나타낼 뿐입니다. 등록 기준 통과, 실행 지원 상태, 목표 워크플로의 성공 여부를 각각 확인해야 합니다.
자동 업데이트를 사용하는 노드는 업데이트 서비스에 접근할 수 있는지 살핍니다. 네트워크 제한이나 운영 정책으로 자동 갱신이 되지 않는다면 수동 업데이트 담당자와 정기 점검 절차를 지정합니다. 자동 업데이트를 끈 노드는 지원 종료 전에 올릴 일정과 문제가 생겼을 때 되돌릴 조건을 함께 정해야 합니다.
03비핵심 노드부터 올리고 실제 Mac CI로 승인합니다
한꺼번에 모든 노드를 교체하지 말고, 영향이 제한된 노드에서 먼저 업데이트 결과를 확인합니다. 업데이트가 통과해도 Runner 서비스가 정상적으로 작업을 받는지, 도구 체인이 기대한 상태인지 확인하기 전에는 전체 빌드 풀에 적용하지 않습니다.
- [ ] 노드의 등록 범위와 버전을 자산 목록에 연결합니다.
- [ ] API에서 등록 기준과 실행 지원 종료 상태를 각각 확인합니다.
- [ ] 자동 업데이트 여부와 업데이트 서비스 접근 가능성을 점검합니다.
- [ ] 설치 스크립트, 기본 이미지, 캐시 템플릿과 컨테이너 원본을 확인합니다.
- [ ] 영향이 제한된 노드에서 업데이트한 뒤 실제 iOS CI/CD 워크플로를 실행합니다.
- [ ] 빌드, 테스트, 아카이브 결과와 Runner 로그를 기록합니다.
- [ ] 서명이나 배포가 포함된 작업은 권한과 전체 작업 결과까지 별도로 확인합니다.
- [ ] 검증에 실패하면 해당 노드를 빌드 풀에서 분리하고, 정해 둔 복구 조건에 따라 이전 상태로 되돌립니다.
운영 메모: 새 노드가 정상 등록됐다는 사실만으로 이전 노드의 이미지와 설치 절차까지 고쳐졌다고 볼 수 없습니다. 원본 자동화도 함께 점검해야 같은 구버전이 다시 배포되는 일을 막을 수 있습니다.
04버전 감시를 정기 운영 절차에 포함합니다
Runner 퇴역 API 조회와 자산 목록 대조를 반복 가능한 운영 작업으로 만듭니다. 지원 종료가 가까워지는 버전을 담당자에게 알리고, 업데이트 결과와 실패 로그, 실제 워크플로 검증 기록을 함께 남깁니다. 자동 업데이트 실패, 업데이트 서비스 연결 불가, 작업 대기 증가, 빌드 실패가 발생했을 때 누가 조사하고 어느 조건에서 노드를 격리하거나 복구할지도 미리 정합니다.
기업 Mac CI Runner를 직접 운영하면 장비와 이미지, 업데이트 작업을 통제할 수 있습니다. 반면 노드 교체와 유지보수를 자체 인력으로 맡아야 하고, 사용량이 적은 시기에도 용량을 보유하며, 버전과 작업 결과를 계속 확인해야 합니다. 업그레이드 기간에만 macOS 빌드 용량을 보태려는 팀이라면 자체 장비 증설 전에 NUKCLOUD 원격 Mac 서비스를 대안으로 비교할 수 있습니다. 실제 Runner 등록과 iOS CI/CD 검증은 팀이 직접 수행해야 하므로, NUKCLOUD 이용 안내를 확인하고 기존 파이프라인에 맞는 과도기 또는 탄력 용량인지 판단하세요.