GitHub Actions Linux ARM64 러너, private 저장소에서도 쓸 수 있을까?

ARM64 기반 CI 실행 환경을 표현한 AI 생성 이미지. 실제 GitHub 러너나 하드웨어를 촬영한 사진은 아니다.

GitHub Actions에서 Linux ARM64 빌드가 필요하면 먼저 확인할 것은 저장소 공개 여부와 러너 라벨이다. GitHub.com에서는 private 저장소도 표준 Linux ARM64 호스팅 러너를 사용할 수 있다. 예전 글에서 본 “private는 larger runner가 필요하다”는 설명을 현재 기준으로 그대로 적용하면 안 된다.

이 글은 2026년 10월 27일 확인한 공식 문서를 기준으로 지원 범위와 선택 기준을 정리한다. 실제 저장소 설정을 바꾸거나 유료 워크플로를 실행한 후기가 아니라, 공식 화면 확인과 최소 설정 예제를 함께 담은 가이드다.

private 저장소 지원은 2026년 1월에 바뀌었다

GitHub는 2026년 1월 29일 공지에서 Linux·Windows ARM64 표준 러너를 private 저장소에도 제공한다고 발표했다. Linux 예제로 안내한 라벨에는 ubuntu-24.04-arm과 ubuntu-22.04-arm이 포함된다.

GitHub 공식 변경 공지의 실제 화면. 2026년 1월 29일 private 저장소 지원 발표를 확인했다.

따라서 “Enterprise를 사용하는데 Linux ARM64는 안 되는가?”라는 질문만으로 지원 여부를 판단하기는 어렵다. GitHub.com의 표준 러너 지원, 조직의 Actions 허용 정책, 비용 제한을 나누어 확인해야 한다. 이 글의 범위는 GitHub.com의 GitHub-hosted runner이며, 자체 설치형 GitHub Enterprise Server 환경까지 같은 조건이라고 가정하지 않는다.

ubuntu-latest가 ARM64를 자동으로 고르지는 않는다

현재 공식 표에서 ubuntu-latest는 x64 항목에 있다. ARM64 실행이 목적이라면 다음처럼 아키텍처가 드러나는 라벨을 지정한다.

운영체제 버전과 CPU 아키텍처는 별개다. “최신 Ubuntu”를 골랐다는 이유만으로 배포 대상과 같은 아키텍처가 되는 것은 아니다. 버전과 아키텍처가 중요한 빌드에서는 둘을 명시적으로 확인하는 편이 낫다.

GitHub-hosted runners 공식 표에서 이 라벨의 사양은 다음과 같다.

저장소	CPU	메모리	SSD
public	4 vCPU	16 GB	14 GB
private	2 vCPU	8 GB	14 GB

공식 문서의 private 저장소용 표준 러너 표를 직접 캡처했다. Linux arm64 행에서 CPU·메모리·라벨을 함께 확인할 수 있다.

같은 라벨이라도 public과 private의 자원 크기가 다르다. public 저장소에서 측정한 빌드 시간을 private에서도 그대로 기대하기보다는 실제 작업의 메모리 사용량과 소요 시간을 다시 확인하는 것이 좋다.

먼저 아키텍처만 확인하는 최소 워크플로

아래 예제는 체크아웃이나 빌드 없이 러너의 아키텍처만 출력한다. .github/workflows/check-arm64.yml에 넣어 사용할 수 있는 수동 실행 예제다. 저장소에 반영하거나 실행하기 전에는 조직 정책과 과금 조건을 먼저 확인한다.

runner.arch는 GitHub가 제공하는 runner context의 값이다. 위 예제는 값이 ARM64인지 검사한다. uname -m은 실행 환경의 머신 아키텍처를 별도로 확인하기 위해 넣었다.

예제의 YAML 구조는 검증했지만 GitHub Actions에서 직접 실행한 결과는 아니다. 실제 도입 시에는 워크플로 실행 기록에서 사용된 러너와 출력값을 확인해야 한다.

ARM64 러너를 선택한 뒤에도 남는 확인 사항

러너를 바꾸는 것은 시작 단계다. 기존 빌드 스크립트가 x64 실행 파일을 내려받거나, 사용하는 컨테이너 이미지에 ARM64 변형이 없다면 다른 부분에서 실패할 수 있다. 다음 항목을 함께 살펴보는 것이 좋다.

다운로드 스크립트에 x86_64나 amd64 파일명이 고정되어 있지 않은가?

의존하는 네이티브 라이브러리와 도구가 ARM64 빌드를 제공하는가?

Docker 이미지나 외부 Action의 지원 아키텍처를 확인했는가?

배포할 산출물이 실제 목표 환경에서 실행되는지 테스트하는가?

이는 특정 프로젝트에서 확인한 장애 목록이 아니라, 아키텍처 전환 시 점검할 일반적인 항목이다. 컴파일에 성공한 것과 배포 환경에서 정상 실행되는 것을 구분해서 검증해야 한다.

비용과 러너 종류를 혼동하지 않는다

표준 러너의 private 사용량은 계정 플랜의 포함 실행 시간을 사용하며, 이후에는 분당 요금이 적용된다. private ARM64 지원을 무료·무제한 제공으로 해석하면 안 된다. 정확한 비용은 실행 전에 현재 러너 요금표와 계정의 사용량·예산 설정을 확인한다.

Larger runner는 더 큰 자원이나 특정 네트워크 요구가 있을 때 검토할 별도 선택지다. 단순히 private 저장소에서 Linux ARM64를 쓰기 위해 항상 필요한 것은 아니다. 자체 환경을 유지해야 한다면 self-hosted runner도 선택지가 되지만, 유지보수와 보안 책임까지 함께 고려해야 한다.

처음에는 ubuntu-24.04-arm으로 최소 작업을 확인하고, 실제 빌드의 의존성·자원 요구·비용을 차례로 검토하는 접근이 단순하다. 오래된 지원 공지 한 편보다 현재 러너 목록과 실제 실행 기록을 기준으로 판단하는 것이 중요하다.