GitHub Actions ARM32 지원 종료: 빌드 대상과 실행 환경을 분리해 점검하기

CI 실행 환경의 세대 전환을 표현한 생성형 개념 이미지. 실제 제품 화면이 아니다.

ARM32 제품을 계속 배포해야 하는데 CI 실행 환경의 지원이 끝난다면, 먼저 빌드를 수행하는 머신과 산출물이 실행될 대상을 분리해야 한다. 러너를 ARM64로 옮기는 것과 제품의 ARM32 지원을 포기하는 것은 같은 결정이 아니다.

GitHub는 2026년 11월 12일, 호스팅 러너의 Windows·Linux ARM32 작업 실행 지원을 12월 8일까지 종료한다고 발표했다. 네이티브 AArch32 사용자 공간 실행도 포함한다. ARM64 장비에서 32비트 프로그램을 직접 실행하던 테스트 역시 점검 대상이다. GitHub 공식 발표

이번 변경에서 구분할 세 가지

첫째는 러너 프로세스와 운영체제의 아키텍처다. 둘째는 JavaScript 액션을 실행하는 Node 런타임이다. 셋째는 빌드한 제품 바이너리의 대상 아키텍처다. 이 셋을 하나의 ‘ARM 지원’으로 묶으면 영향 범위를 잘못 판단하기 쉽다.

GitHub는 이미 9월 23일 JavaScript 액션의 Node 20 사용 종료를 공지했다. 현재 액션은 Node 24를 사용하며, 임시 우회 변수인 ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION도 더 이상 사용할 수 없다. 해당 공지는 ARM32 자체 호스팅 러너도 지원 대상에서 제외한다고 설명한다. 따라서 이번 호스팅 러너 공지를 보고 “ARM32 자체 호스팅으로 옮기면 해결된다”고 결론 내리면 안 된다. Node 20 종료 공지

반면 현재 러너 선택 문서에는 ubuntu-24.04-arm 등의 ARM64 라벨이 남아 있다. 이름에 arm이 들어 있다고 ARM32인 것은 아니다. 이번 공지는 ARM64 러너 전체의 종료 공지가 아니다. 러너 선택 공식 문서

저장소에서 먼저 찾을 것

다음 명령은 Linux 셸에서 실행하는 정적 점검 예시다. 이 글에서는 실제 사용자 저장소나 GitHub 작업에 실행하지 않았다.

검색 결과가 없다고 안전하다는 뜻은 아니다. 재사용 워크플로, 외부 액션, 호출되는 셸 스크립트와 Dockerfile에도 아키텍처 의존성이 들어갈 수 있다. linux/arm64 같은 정상 항목도 검색에 잡히므로 문자열 일치 자체를 오류로 취급하지 않는다.

각 작업에 대해 다음 질문에 답하면 된다.

• 러너의 실제 OS와 CPU 아키텍처는 무엇인가?

• 32비트 실행 파일을 빌드만 하는가, 같은 러너에서 직접 실행하는가?

• 제품의 ARM32 지원은 계약·장비 수명 때문에 계속 필요한가?

• 사내 액션과 외부 액션은 Node 24 대응 버전을 사용하는가?

머신과 프로세스 정보를 로그에 남긴다

Linux 작업에는 아래와 같은 진단 단계를 추가할 수 있다. RUNNER_ARCH는 러너 정보이고, getconf LONG_BIT는 해당 환경의 정수 비트 폭 확인이다. 서로 같은 대상을 설명한다고 가정하지 않는다.

이 예시는 진단 단계일 뿐 마이그레이션 완성본이 아니다. 빌드 산출물도 file 경로/실행파일 등으로 별도 확인하고, 실제 대상 장치의 테스트 결과와 함께 보관한다.

프로젝트에서 setup-node로 설치한 Node 버전만 확인해서 JavaScript 액션 런타임까지 검증했다고 생각해서는 안 된다. 액션 작성자는 액션 메타데이터의 runs.using과 배포 버전을 확인해야 한다. 액션 사용자는 해당 액션의 Node 24 대응 릴리스를 검토한다.

이전 경로는 테스트 목적에 따라 나눈다

ARM32 산출물만 필요하다면 지원되는 x64 또는 ARM64 환경에서 교차 컴파일할 수 있는지 검토한다. 이것은 설계 선택지이며 모든 언어·라이브러리에 자동 적용되는 해결책은 아니다. 네이티브 확장, C/C++ 의존성, 타깃 시스템 라이브러리와 링커 설정은 따로 확인해야 한다.

ARM32 실행 동작까지 보장해야 한다면 빌드 작업과 대상 장치 검증을 분리한다. 에뮬레이션을 검토할 수 있지만, 에뮬레이터에서 통과한 테스트를 실제 장치의 성능·드라이버·CPU 명령 지원 검증으로 대체해서는 안 된다. 11월 12일 공지는 에뮬레이션 지원을 보장하는 문서도 아니다.

ARM64로 제품 자체를 전환할 수 있다면 배포 대상의 OS, 패키지와 네이티브 모듈 호환성까지 확인한 뒤 결정한다. runs-on 한 줄만 바꾸고 기존 ARM32 검증이 유지된다고 간주하면 테스트 범위가 조용히 줄어든다.

완료 기준은 초록색 체크보다 구체적이어야 한다

이전 후에는 러너 아키텍처, 액션 버전, 산출물 아키텍처, 실행 테스트 위치를 한 묶음으로 남긴다. 릴리스 작업뿐 아니라 PR 검사와 정기 작업도 확인한다. 테스트 일부를 제외했다면 제외 이유와 보완 방법을 명시한다.

핵심은 12월 8일 전에 “어느 머신에서 무엇을 실행하는가”를 명확히 하는 것이다. 공식 종료 범위는 발표문으로 확인하고, 제품의 ARM32 지원 유지 여부는 빌드와 검증 경로를 나누어 판단해야 한다. 이 글은 공식 문서와 마이그레이션 설계 검토이며, 실제 CI 전환이나 성능 측정을 수행한 결과는 아니다.