GitHub Actions, 12월 8일까지 ARM32 실행 지원 종료…배포 작업에서 확인할 것은

AI 생성 이미지

GitHub Actions로 배포하고 있다면 모든 ARM 작업을 바꿔야 할까요? 이번 대상은 GitHub가 제공하는 Windows·Linux 러너에서의 ARM32 작업 실행입니다. GitHub는 11월 12일, 이 지원을 2026년 12월 8일까지 종료한다고 공지했습니다. ARM64 전체가 종료되는 것은 아닙니다. 공식 종료 공지

러너는 빌드와 테스트 같은 자동화 작업을 실행하는 컴퓨터입니다. 웹사이트 코드가 그대로여도 그 컴퓨터에서 실행하는 도구가 지원 범위를 벗어나면 배포 과정에 영향을 줄 수 있습니다. 따라서 이번 공지는 모든 배포 설정을 바꾸라는 뜻보다, 현재 작업이 실제로 어떤 프로그램을 실행하는지 확인할 기한으로 읽는 편이 맞습니다.

ARM32와 ARM64, 실행 환경부터 구분합니다

종료 범위에는 hosted 러너의 native AArch32 user-space 실행도 포함됩니다. 쉽게 말해 ARM의 32비트 프로그램을 해당 환경에서 직접 실행하는 경우까지 점검해야 한다는 의미입니다. 적용 범위

반면 현재 공식 러너 문서는 Linux와 Windows의 ARM64 환경을 계속 안내합니다. 이름에 ARM이 들어간다는 이유만으로 같은 대상으로 묶으면 안 됩니다. 지원 러너 목록

예를 들어 ARM64 러너를 쓰는 작업과, 그 작업 중 내려받아 실행하는 도구는 따로 살펴볼 필요가 있습니다. 작업 설정에 적힌 환경 이름만 확인하고 끝내면 내부 단계의 의존성을 놓칠 수 있기 때문입니다. 자체 스크립트뿐 아니라 외부 액션이 호출하는 도구도 확인 대상에 넣어 보세요.

ARM32 실행 종료 대상과 ARM64 전체 종료가 아님을 구분한 도식 — ARM32 실행과 ARM64를 구분합니다 · 설명용 도식

GitHub 공식 ARM32 종료 공지의 제목과 날짜 실제 캡처 — ARM32 지원 종료 공지 실제 캡처 · GitHub

Node 24 전환과 연결되지만, 앱의 Node 버전과는 다릅니다

GitHub는 이번 종료를 Node 20 지원 종료의 후속 변화로 설명합니다. 앞선 9월 23일 공지에서는 JavaScript 액션의 실행 환경이 Node 24로 바뀌었고, Node 20을 계속 쓰던 임시 예외도 종료됐다고 안내했습니다. Node 20 종료 안내

여기서 확인할 대상은 액션 자체를 실행하는 환경입니다. 애플리케이션 빌드에 사용할 Node 버전만 바꿨다고 외부 액션과 러너의 호환성까지 확인한 것은 아닙니다. 배포 작업을 읽을 때 ‘우리 앱을 빌드하는 도구’와 ‘그 도구를 호출하는 액션’을 나눠 보는 이유입니다.

예를 들어 팀이 앱의 Node 버전을 이미 올렸더라도 오래된 외부 액션을 계속 사용하고 있을 수 있습니다. 이 경우 앱 설정만 다시 수정하기보다, 사용 중인 액션의 지원 버전과 실행 조건을 확인하는 편이 원인을 좁히는 데 도움이 됩니다. 지원이 끝난 예외 설정을 되살리는 방향으로 해결하려 해서는 안 됩니다.

앱 빌드용 Node와 JavaScript 액션 런타임, 러너 아키텍처 세 층 — 앱·액션·러너를 따로 봅니다 · 설명용 도식

ARM32 파일을 만드는 일과 실행하는 일을 나눠 점검합니다

ARM32용 파일의 생성과 작업 도중 실제 실행의 차이를 구분한 설명용 도식 — 산출물과 실제 실행은 다릅니다 · 설명용 도식

ARM32용 산출물을 만든다는 사실만으로 이번 종료의 영향을 확정할 수는 없습니다. 빌드 결과를 저장하기만 하는지, 작업 도중 그 결과를 직접 실행해 시험하는지에 따라 확인할 부분이 달라집니다. 공식 공지는 특정 크로스컴파일이나 에뮬레이션 구성이 계속 작동한다고 보장하지도 않습니다.

가정해 보겠습니다. 한 작업은 기기용 파일을 만들어 보관하고, 다른 작업은 같은 파일을 실행해 결과를 검사합니다. 두 작업을 ‘ARM32 빌드’라는 이름 하나로 관리하면 실제 실행이 필요한 단계를 놓치기 쉽습니다. 우선 단계별 목적과 실행 파일을 적어 영향 여부를 분리하는 것이 좋습니다.

최근 작업 로그에서 러너 환경을 확인하고, 내려받는 도구와 테스트 단계의 아키텍처를 함께 살펴보세요. 영향이 예상되는 작업은 지원되는 환경에서 같은 검사를 수행할 수 있는지 비교해야 합니다. 성공 여부뿐 아니라 기존에 확인하던 오류와 호환성 문제를 여전히 잡아내는지가 판단 기준입니다.

이번 발표는 자체 호스팅 러너 전체의 종료 공지가 아닙니다. 이를 이유로 테스트를 삭제하거나 자체 호스팅 러너로 무조건 옮길 필요는 없습니다. 실행 환경을 바꿀 때도 무엇을 검증하던 작업인지 보존해야 합니다. 12월 8일이라는 기한보다 먼저 정리할 것은 ‘어떤 단계가 ARM32 실행에 의존하는가’입니다.

ARM32 산출물 생성과 실제 실행 테스트를 분리하여 점검하는 절차 — 산출물과 실행 단계를 구분합니다 · 설명용 도식

이어볼 뉴스

액션 코드를 고정하는 잠금 파일도 러너 환경까지 고정해 주지는 않습니다. 배포 자동화에서 무엇을 별도로 관리해야 하는지 함께 살펴보세요.

GitHub Actions 잠금 파일의 적용 범위를 설명하는 VECTORLOG 썸네일

배포 코드는 그대로인데 실행 내용이 바뀐다면? GitHub Actions에 잠금 파일이 생겼습니다

#GitHubActions #ARM32 #배포자동화 #CI #개발운영