마지막 업데이트: 2026년 10월 21일. 런타임 상태는 GitHub 공식 변경 공지와 공식 문서를 기준으로 확인했습니다.
Action 초기화에서 Mac CI가 멈추거나, Node 런타임 경고 뒤 빌드가 실패하고 있나요?
이번 주에는 프로젝트의 Node.js 버전을 바꾸기 전에 실패한 대상이 JavaScript Action 런타임인지 확인하세요. 해당 Action을 Node 24 지원 버전으로 갱신해 격리 검증하고, 자체 호스팅 Mac Runner가 macOS 13.4 이하라면 운영체제 호환성도 별도로 점검해야 합니다. GitHub는 2026년 9월 23일 Runner에서 Node 20 Action 런타임을 제거했다고 밝혔습니다. 공식 공지
기업 IT 책임자라면 영향받는 CI 작업과 복구 순서를 확인할 수 있습니다.
플랫폼 엔지니어라면 자체 호스팅 Runner와 공용 Action을 점검할 수 있습니다.
iOS/macOS 릴리스 책임자라면 실제 빌드와 테스트 결과로 배포 재개 여부를 결정할 수 있습니다.
먼저 구분할 지표: Action 런타임인가, 프로젝트 Node.js인가
GitHub Actions Node 20 Mac CI 문제를 진단할 때 핵심은 Node.js가 쓰이는 위치입니다. JavaScript Action은 Runner 안에서 Action 코드를 실행하기 위한 런타임을 선언합니다. 프로젝트 Node.js는 네가 워크플로에서 설치하거나 호출해 애플리케이션을 빌드하는 별도 환경입니다. GitHub도 Node.js 프로젝트를 위한 워크플로 설정과 JavaScript Action 실행을 별도 문서로 설명합니다. Node.js 빌드 안내
따라서 Action 런타임 변경만으로 프로젝트 의존성이나 package.json에 지정한 Node.js 버전이 자동 변경되지는 않습니다. 프로젝트 설정부터 바꾸면 원인을 흐리거나 새로운 호환성 문제를 만들 수 있습니다.
로그의 실패 단계와 Action 메타데이터를 함께 보세요. 초기화 단계에서 실패하면 Action 런타임과 Action 버전을 먼저 살핍니다. 의존성 설치나 테스트 명령에서 실패한다면 프로젝트 Node.js, 패키지, 빌드 설정을 별도로 조사합니다.
| 확인 지표 | 살펴볼 증거 | 우선 조치 |
|---|---|---|
| Action 초기화 | 실패 로그의 단계, 워크플로의 uses 참조 |
실제 Action 버전과 런타임 선언 확인 |
| 프로젝트 명령 | 설치·빌드·테스트 명령과 Node.js 선택 설정 | 프로젝트 실행 환경과 의존성 확인 |
| Runner 환경 | macOS 버전과 프로세서 아키텍처 | Node 24 지원 경계와 대조 |
Action 버전과 런타임 선언을 따라가기
워크플로 파일에 직접 적힌 Action만 찾고 끝내면 안 됩니다. 재사용 워크플로, 조직 공용 템플릿, composite Action 안에서 호출하는 JavaScript Action도 점검 대상입니다. 워크플로 문법 문서를 참고해 실제 호출 관계와 버전 참조를 추적하세요.
Action의 action.yml 또는 action.yaml에서 runs.using 값을 확인합니다. 이 필드는 JavaScript Action의 실행 환경을 선언하는 메타데이터입니다. GitHub 문서는 이 필드와 Action 메타데이터 구성을 설명합니다. Action 메타데이터 문서
직접 만든 Action이라면 소스 코드만 수정하지 말고 메타데이터와 패키지 의존성도 함께 검토해야 합니다. JavaScript Action 제작 안내를 기준으로 런타임 선언을 점검하고, 새 버전에서 입력·출력과 오류 처리가 유지되는지 확인하세요. 오래된 버전을 고정해 쓰는 워크플로는 새 릴리스가 자동 적용되지 않을 수 있으므로 호출 참조도 직접 확인해야 합니다.
03Node 20으로 되돌리는 임시 우회책이 계속 유효하다고 가정하지 마세요. GitHub는 Node 20 런타임 제거와 함께 임시 제외 설정을 사용할 수 없다고 공지했습니다. 현재 정책은 공식 변경 공지에서 다시 확인하세요.
Runner 호환성은 운영체제와 아키텍처로 판정하기
GitHub는 Node 24가 macOS 13.4 이하와 ARM32에서 공식 지원되지 않는다고 명시합니다. 이는 모든 Mac Runner, 특히 모든 Apple Silicon 장비가 영향을 받는다는 뜻이 아닙니다. 네 Runner의 실제 macOS 버전과 프로세서 아키텍처가 지원 경계에 들어가는지 확인해야 합니다. 공식 런타임 변경 안내
Runner 선택 안내에서 작업이 어떤 Runner에 배정되는지 살펴보고, 자체 호스팅 Runner 문서와 대조해 등록 환경을 점검하세요. Runner가 온라인으로 보이는지만으로 Node 24 호환성을 판정할 수는 없습니다.
macOS 13.4 Runner 호환성 여부를 확인할 때는 세 가지를 분리합니다. 첫째, 운영체제 버전이 공식 제한에 걸리는지 확인합니다. 둘째, 프로세서 아키텍처가 ARM32인지 판별합니다. 셋째, 같은 Action 버전과 워크플로를 지원되는 별도 환경에서 실행해 Action 자체 문제인지 비교합니다. 환경을 바꾸기 전에 원인을 분리해야 불필요한 Mac 교체를 피할 수 있습니다.
04격리 검증은 실제 배포 작업까지 이어가기
다음 순서로 확인하면 Action 업데이트와 Runner 변경의 영향을 분리하기 쉽습니다.
- 실패한 워크플로의 로그와 실행 시각을 보존합니다. 실패 단계가 Action 초기화, 의존성 설치, Xcode 빌드, 테스트 중 어디인지 기록합니다.
- 워크플로, 재사용 워크플로, 조직 템플릿에서 실제 호출되는 Action과 버전을 목록화합니다. Action이 다른 Action을 호출하는지도 추적합니다.
- 각 JavaScript Action의 메타데이터에서
runs.using을 확인하고, 업데이트 후보가 Node 24를 지원하는지 유지 관리자의 문서와 릴리스 정보로 확인합니다. - 격리된 브랜치나 테스트 워크플로에서 후보 버전을 적용합니다. 입력값, 출력값, 실패 처리뿐 아니라 이후 단계가 기대한 값을 받는지 검증합니다.
- Runner의 macOS 버전과 아키텍처를 기록하고 공식 호환 경계와 대조합니다. 서로 다른 환경에서 비교할 때는 Action 버전과 워크플로 입력을 동일하게 유지합니다.
- 실제 키 빌드와 테스트를 재실행합니다. Action 초기화 통과만으로 승인하지 말고, Xcode 빌드·테스트와 배포에 필요한 후속 작업까지 확인합니다.
- 재현 로그, Action 참조, Runner 정보를 남기고 릴리스 담당자와 재개 여부를 결정합니다.
판단 조건에 따른 복구 경로
- 실패가 Action 초기화에 있고 해당 Action이 Node 24 지원 버전을 제공한다면, 업데이트한 뒤 격리 검증을 진행합니다.
- 직접 관리하는 Action이 구 런타임을 선언한다면, 유지 관리 책임자가 메타데이터와 의존성을 갱신하고 새 버전을 배포해야 합니다.
- macOS 버전 또는 아키텍처가 공식 지원 경계에 걸리고, 같은 Action이 지원 환경에서 정상 동작한다면 Runner 환경 조정을 검토합니다.
- 실패가 프로젝트 명령이나 의존성 설치 단계에 국한된다면, Action 런타임 변경으로 단정하지 말고 프로젝트 Node.js와 패키지 설정을 조사합니다.
- 원인이 아직 분리되지 않았거나 핵심 작업 검증이 끝나지 않았다면 릴리스를 보류하고 격리 검증을 유지합니다.
복구 여부는 같은 작업의 증거로 결정하기
아래 세 표를 이용해 원인, 조치, 승인 근거를 남기세요. 한 단계가 통과했거나 Runner 상태가 온라인이라는 사실만으로 전체 복구를 승인하지 않습니다.
| 관찰 결과 | 가능한 원인 | 필요한 추가 증거 |
|---|---|---|
| Action 시작 단계에서 실패 | Action 런타임 선언 또는 Action 버전 문제 | Action 메타데이터와 갱신 버전의 격리 실행 |
| 프로젝트 명령에서 실패 | 프로젝트 Node.js, 의존성, 빌드 스크립트 문제 | 설치·빌드·테스트 로그와 프로젝트 런타임 설정 |
| 특정 Runner에서만 실패 | macOS 또는 아키텍처 차이 가능성 | 동일 Action·워크플로를 다른 지원 환경에서 실행한 결과 |
| Runner는 온라인이나 작업이 실패 | 작업 실행 조건 또는 런타임 문제 | 실제 Action 초기화부터 빌드·테스트까지의 기록 |
| 확인 지표 | 통과 조건 | 미통과 시 처리 |
|---|---|---|
| Action 참조 | 변경 대상과 적용 버전이 기록되어 있음 | 영향받는 워크플로를 다시 검색 |
| Action 초기화 | 갱신 버전이 격리 환경에서 시작됨 | 오류와 메타데이터를 유지 관리자가 조사 |
| macOS·아키텍처 | 실제 값이 공식 지원 경계와 대조됨 | 환경 변경 전 원인 재현 |
| 핵심 빌드·테스트 | 릴리스에 필요한 작업이 실제로 완료됨 | 배포 보류, 실패 단계 추가 분석 |
| 운영 기록 | 변경 책임과 재검토 조건이 남아 있음 | 담당자 지정 전 확대 적용 보류 |
| 선택지 | 장점 | 주의할 점 |
|---|---|---|
| Action 버전 갱신 | 원인이 런타임 선언이라면 Runner 교체 없이 수정 가능 | 입력·출력·오류 처리의 회귀 검증 필요 |
| 자체 Action 수정 | 유지 관리 중인 코드와 실행 메타데이터를 함께 통제 가능 | 새 버전 배포와 소비 워크플로 갱신 책임이 생김 |
| Runner 환경 조정 | 확인된 OS·아키텍처 제한을 직접 해소할 수 있음 | 원인 확인 없이 바꾸면 비용과 운영 범위만 커질 수 있음 |
| 격리 검증 유지 | 릴리스 위험을 통제하며 증거를 모을 수 있음 | 승인 기준과 담당자를 분명히 해야 함 |
운영 기록에는 Runner의 시스템과 아키텍처, Action 참조, 오류 로그, 재검토를 시작할 조건을 포함하세요. 자체 호스팅 Runner와 원격 Mac 환경을 비교한다면 작업 데이터와 계정 정보의 처리 기준도 살펴보세요. 원격 Mac 개인정보 보호 방침에서 관련 안내를 확인할 수 있습니다. GitHub의 런타임 정책이나 지원 범위가 바뀌면 기록과 테스트 기준도 다시 확인해야 합니다.
06자주 묻는 질문
Node 20 중단이 Mac CI 실패의 직접 원인인가요?
Action 초기화 실패와 Node 런타임 관련 로그가 확인될 때 가능한 원인입니다. 프로젝트 Node.js를 사용하는 명령이 실패했다면 별도 조사해야 합니다. 변경 공지의 적용 범위와 Runner 환경을 대조하세요.
프로젝트에서 Node.js 버전을 낮추거나 올려야 하나요?
Action 런타임 문제라는 증거만으로 프로젝트 Node.js를 변경하지 마세요. 프로젝트의 설치·빌드 단계에서 실패가 재현될 때 프로젝트 설정과 의존성을 조사합니다. 두 런타임은 설정 위치와 역할이 다릅니다.
오래된 JavaScript Action을 어떻게 갱신하나요?
호출 버전과 메타데이터를 확인한 뒤 Node 24 지원 버전이 있는지 살펴보세요. 격리 워크플로에서 입력, 출력, 실패 처리와 후속 작업까지 확인한 다음 핵심 빌드에 적용합니다. 직접 만든 Action은 유지 관리자가 새 버전을 배포해야 합니다.
자체 호스팅 Mac Runner의 macOS 버전도 영향을 주나요?
공식 안내는 Node 24가 macOS 13.4 이하와 ARM32를 지원하지 않는다고 밝힙니다. 네 Runner가 해당 경계에 들어가는지 확인하고, Action 자체 문제와 구분하세요. 모든 Apple Silicon 장비가 영향받는다고 가정해서는 안 됩니다.
수동으로 유지하는 Mac CI는 Action 버전 추적, macOS 호환성 점검, 테스트 책임을 네 팀이 함께 맡아야 합니다. 범용 클라우드 실행 환경도 실제 macOS와 Xcode 작업 요구에 맞는지 먼저 검증해야 하며, 물리적 Mac이 필요한 작업을 자동으로 대신하지는 않습니다. 지원되는 Mac 환경을 지속적으로 관리해야 한다면, 업무량과 호환성 기준을 정한 뒤 원격 Mac 제공 환경과 전달 조건을 확인할 수 있습니다. 이 변경만 해결하려고 하드웨어를 바로 늘리기보다, 실제 작업 검증에서 Runner 환경의 한계가 확인됐을 때 대체 환경을 비교하는 편이 합리적입니다.