Enterprise Cloud self-hosted runner 버전 강제 적용 시작, 2.329.0 미만 등록 불가와 30일 규칙 (9월 29일 기준)

2.329.0 미만 self-hosted runner는 GitHub Enterprise Cloud에서 2026년 9월 29일부터 등록할 수 없다. 이미 등록한 러너도 실행 하한을 못 넘으면 작업을 받지 못한다. 2.329.0 이상이라고 안전한 것은 아니다. 실행 하한은 등록 하한보다 높고, 새 러너 릴리스를 30일 안에 반영해야 한다는 규칙과 맞물려 있다. 9월 25일로 예고됐던 적용일이 9월 28일 공지로 29일로 바뀛을 뿐, 요구사항은 그대로다.

세 줄로 먼저 읽기

• 대상은 GitHub Enterprise Cloud다. Enterprise Server는 영향이 없다.
• 등록 기준은 2.329.0 이상이다. 작업 실행 기준은 이보다 높고 시간이 지나며 올라간다.
• 자동 업데이트를 끈 러너와 오래된 이미지로 띄우는 임시 러너가 위험하다는 것은 필자의 추론이다.

이 글은 GitHub 9월 28일 changelog, 6월 12일 일정 공지, 러너 업데이트 정책 문서를 읽고 썼다. 러너를 일부러 낡게 만들어 멈추는 것을 재현해 보지는 않았다. 아래 확인 방법과 복구 순서는 공식 규칙에서 끌어낸 실무 절차다.

적용일은 나흘 늦춰졌고 요구사항은 그대로다

6월 12일 공지의 일정은 이랬다. Data Residency가 적용된 Enterprise Cloud는 7월 31일, 일반 Enterprise Cloud는 9월 25일이었다. 9월 28일 공지가 일반 Enterprise Cloud의 전면 적용일을 9월 29일 화요일로 바꿨다.

6월 공지는 적용 약 4주 전부터 단계별 브라운아웃을 하겠다고 했다. 시간대는 미국 동부 기준 오전 11시부터 오후 3시다. 서머타임 기간이라면 한국 시간으로 자정부터 새벽 4시쯤이 된다(직접 계산한 값이다). 브라운아웃 날짜별 일정은 이번에 확인하지 못했다. 그 사이 밤 배치가 이유 없이 실패한 적이 있다면 러너 버전부터 의심해 볼 만하다.

우리 조직이 대상인지부터 본다

공지가 밝힌 범위는 세 가지다. GitHub Enterprise Cloud는 9월 29일에 적용된다. Enterprise Server는 영향이 없다. Data Residency 버전은 7월 31일에 이미 적용이 시작됐다.

Free나 Team 같은 다른 플랜이 이번 날짜 변경에 어떻게 걸리는지는 공지에 없다. 이 글도 판단하지 않는다. 조직의 플랜은 계약서나 청구 화면으로 먼저 확인하자.

기준선이 둘이라 2.329.0만 맞추면 부족하다

등록과 재등록의 하한이 2.329.0이다. 이 숫자는 고정돼 있다.

작업 실행의 하한은 다르다. 공지는 이 값이 등록 하한보다 높다고만 적었고 구체 숫자는 밝히지 않았다. 6월 공지는 실행 하한이 새 러너가 나올 때마다 앞으로 올라간다고 설명한다. GitHub Docs는 30일 규칙을 이렇게 쓴다. 업데이트가 나온 뒤 30일 안에 러너를 올리지 않으면 Actions 서비스가 그 러너에 작업을 큐잉하지 않는다.

GitHub API로 조회한 최신 릴리스는 v2.337.0이고 2026년 8월 26일에 나왔다. 30일 규칙을 문자 그대로 읽으면 9월 25일이 지난 지금은 2.337.0보다 낮은 러너가 뒤처진 상태일 수 있다. 이는 추론이다. 실행 하한이 정확히 어느 버전인지는 확인하지 못했다. 2.329.0을 겨우 넘긴 러너라면 최신으로 올리는 편이 안전하다.

내 러너 버전을 확인하는 순서

먼저 조직이나 엔터프라이즈의 러너 목록 화면을 열어 버전이 보이는지 본다. 보이지 않거나 러너가 수십 대라면 API로 뽑는 쪽이 낫다.

# 조직 단위 러너 목록. 응답에 version 필드가 오는지 한 건으로 먼저 확인한다
gh api /orgs/ORG/actions/runners --paginate --jq '.runners[] | {name, status, version}'

필드가 비어 있으면 러너 호스트에서 직접 버전을 본다. 이 명령은 REST API 문서의 응답 예시와 대조해 만든 것이 아니다. 실제 응답을 한 번 확인하고 쓰자.

감사 로그로도 버전을 추적할 수 있다. 6월 공지는 org.register_self_hosted_runner, repo.register_self_hosted_runner, enterprise.register_self_hosted_runner 이벤트를 알려 준다. 등록 시점의 버전이라 지금 버전과는 다를 수 있다.

9월 3일에는 폐기 일정 조회 API가 추가됐다. 9월 3일 changelog에 따르면 저장소, 조직, 엔터프라이즈 수준에서 GET /actions/runners/deprecations/{version}을 호출한다. 응답에는 runner_version, runtime_deprecates_at, registration_deprecates_at이 들어 있다. 앞에 붙는 경로는 수준마다 다르니 REST 문서에서 확인하자. 버전을 하나씩 넣어 보면 각 버전의 실행 종료일이 나온다. 이 값으로 알림을 만들면 다음 강제 적용 때 놀라지 않는다.

자동 업데이트를 켠 러너와 고정 러너는 사정이 다르다

러너는 기본적으로 스스로 업데이트한다. 작업이 배정될 때, 또는 놀고 있으면 릴리스 뒤 일주일 안에 올라간다고 Docs가 설명한다. 이 설정을 그대로 둔 러너는 대체로 문제가 없다. 6월 공지도 자동 업데이트 러너는 기준을 자동으로 맞춘다고 했다.

문제는 --disableupdate로 등록한 러너다. 컨테이너나 임시 러너에서 업데이트 시점을 이미지 재빌드로 직접 통제하려고 쓰는 옵션이다. 이미지를 넉 달 전에 구웠다면 새 러너가 뜰 때마다 낡은 버전으로 등록을 시도하게 된다.

GTM 서버 컨테이너 배포나 BigQuery 적재 스크립트를 사내 러너에서 돌리는 마케팅 데이터 팀을 가정해 보자. 러너 이미지를 6월에 만들어 두고 그대로 쓰는 중이다. 이번 적용일 이후 새 러너가 등록되지 않으면 밤 적재 작업이 큐에서 기다리고, 아침 대시보드는 어제 값을 보여 준다. 실제 사고 사례가 아니라 구조를 보여 주려는 가정이다. 적재된 GA4 데이터에서 사내 접속을 거르는 방법은 GA4 내부 트래픽이 BigQuery에 남는 이유와 쿼리로 거르는 법에 정리해 두었다.

이미 멈췄다면 이 순서로 복구한다

1. 대기 중인 작업이 어느 러너 풀에 몰려 있는지 본다. 러너가 offline이거나 작업이 계속 queued로 남아 있으면 후보다.
2. 해당 러너 호스트의 버전을 확인한다. 위 목록이나 API가 가장 빠르다.
3. 최신 러너로 교체한다. 자동 업데이트를 켠 상태로 다시 시작하거나 최신 패키지를 새로 설치한다.
4. 등록이 풀렸다면 새 등록 토큰으로 config.sh를 다시 실행해 재등록한다.
5. 이미지와 배포 스크립트에 버전이 고정돼 있으면 고치고 이미지를 다시 빌드한다.
6. 큐에 남은 작업을 다시 실행하고, 성공 여부와 소요 시간을 기록한다.

이 여섯 단계는 공식 규칙에서 도출한 실무 순서다. 재등록과 설치 명령은 GitHub 러너 문서의 최신 절차를 따르자.

확정된 사실과 추론을 나누면

확정된 사실은 다음과 같다. 일반 Enterprise Cloud의 전면 적용일이 9월 29일로 바뀌었다. 2.329.0 미만은 등록과 재등록이 안 된다. 실행 하한 미만의 기존 러너는 작업을 멈춘다. Enterprise Server는 영향이 없고, Data Residency는 7월 31일에 시작됐다. 새 폐기 일정 API가 있다.

추론은 다음이다. 2.337.0보다 낮은 러너가 30일 규칙에 이미 걸렸을 수 있다. 낡은 이미지를 쓰는 임시 러너가 가장 먼저 영향을 받을 것이다. 확인하지 못한 것도 있다. 실행 하한의 정확한 버전, 브라운아웃 날짜별 일정, Enterprise Cloud 외 플랜의 적용 여부다.

자주 묻는 질문

Enterprise Server를 쓰는데 해당되나?
해당되지 않는다. 공지가 영향이 없다고 밝혔다.

2.329.0 이상이면 안전한가?
그렇지 않다. 2.329.0은 등록 하한이다. 작업을 받으려면 실행 하한도 넘어야 하고, 이 값은 새 릴리스와 30일 규칙에 따라 올라간다.

9월 25일에 벌써 막힌 러너가 있었나?
변경 공지는 전면 적용이 9월 29일에 시작된다고 했다. 그 전의 브라운아웃이나 개별 실패가 있었는지는 각자의 Actions 실행 기록을 열어 봐야 안다.

그대로 옮겨 쓸 점검표

러너 풀 이름, 소유 조직, 운영 방식(상시 또는 임시), 자동 업데이트 여부, 현재 버전, 이미지 빌드일, 담당자를 한 줄씩 적는다. 자동 업데이트를 껐다면 이미지 재빌드 주기를 릴리스 뒤 30일보다 짧게 잡는다. 폐기 일정 API로 각 버전의 runtime_deprecates_at을 조회해 남은 일수가 14일 아래로 내려가면 알림이 오게 만든다. 14일은 임의로 정한 여유 기준이다.

공식 자료

• Self-hosted runner version enforcement date has moved (2026-09-28)
• Minimum version enforcement timeline for self-hosted runners (2026-06-12)
• GitHub Actions: Early September 2026 updates (2026-09-03)
• Self-hosted runners 문서
• Self-hosted runners REST API 문서

공식 문서 확인일: 2026년 9월 29일. 이미지는 개념을 설명하는 생성 도해이며 실제 GitHub 화면이 아니다.