GitHub Actions, 멀티 클라우드 컴퓨팅 추가: Linux 작업이 AWS에서 실행될 수 있어 IP 허용 목록 갱신 필요

GitHub는 2026년 10월 28일 GitHub Actions가 대상 작업을 더 넓은 멀티 클라우드 컴퓨팅 풀에 나눠 배정한다고 밝혔다. 대상 Linux 작업은 Microsoft Azure뿐 아니라 Amazon Web Services에서도 실행될 수 있다. GitHub가 내세운 목표는 용량 확대, 용량 부족으로 인한 대기 시간 단축, 수요 정점에서의 복원력 향상이다. 변경은 단계적으로 적용되며 경고가 붙는다. Azure나 마이크로소프트 대역만 허용하는 네트워크 허용 목록은 새 러너를 막을 수 있다.

범위는 좁다. 멀티 클라우드 컴퓨팅은 표준 2코어와 4코어 Linux 러너, 그리고 특수 구성이 없는 호환 2코어와 4코어 대형 러너에 적용된다. Windows 러너와 사설 네트워크나 다른 특수 구성을 쓰는 러너에는 적용되지 않는다. GitHub는 옮겨 갈 작업의 비율, 계정별 시작일, 측정된 대기 시간 개선을 밝히지 않았으므로 이점은 결과가 아니라 목표다.

누가 쓰는지는 요금제에 달려 있다. GitHub Free, Pro, Team 고객은 대상 러너에서 멀티 클라우드 컴퓨팅이 자동으로 쓰인다. GitHub Enterprise Cloud 고객은 직접 켜야 한다. 관리자가 Enterprise 설정의 Actions 아래 Hosted compute cloud providers에서 AWS 컴퓨팅을 활성화한다. GitHub는 대상 작업을 사용 가능한 제공자에 자동으로 배정하며 러너 레이블과 워크플로 문법은 그대로라고 말한다. 따라서 팀이 작업마다 클라우드를 고르지는 않는다. Enterprise Cloud에서 고를 수 있는 것은 AWS 컴퓨팅을 허용할지 여부뿐이다.

권장 조치는 파이프라인을 깨뜨릴 수 있는 부분이다. 확장된 풀의 러너는 추가 외부 발신 IP 주소를 쓴다. Azure나 마이크로소프트 소유 대역만 허용하는 정책, Microsoft Entra 조건부 액세스 정책도 포함해, 이 러너의 연결이나 인증을 막을 수 있다. 방화벽으로 보호된 데이터베이스, 사설 패키지 레지스트리, 호출자 주소를 확인하는 클라우드 API에 접근하는 작업이 영향을 받기 쉽다. 적용이 단계적이므로 이런 실패는 한꺼번에가 아니라 일부 작업에서 간헐적으로 나타날 수 있어 진단이 더 어렵다.

GitHub의 해법은 클라우드별 목록을 직접 관리하지 않는 것이다. 새로 추가된 것을 포함한 GitHub Actions 러너의 모든 IP 대역은 GET https://api.github.com/meta 응답의 actions 배열에 공개된다. GitHub는 한 클라우드 제공자의 대역에 기대지 말고 이 엔드포인트와 허용 목록을 동기화하라고 권하며, 워크플로가 확장된 풀에서 돌기 전인 지금 하라고 한다. 공개 목록은 바뀔 수 있으므로 동기화를 스크립트로 만들어 정기적으로 돌릴 수 있다. 켜지 않은 Enterprise Cloud 고객은 새 주소를 피할 수 있지만, 이 선택이 얼마나 유지되는지는 변경 기록에 없다.

GitHub는 이 변경을 호스팅 러너 뒤의 인프라를 넓혀 수요 정점에서도 워크플로가 더 빨리 시작되고 안정적으로 돌게 하는 일이라고 설명한다. 변경 기록은 대상 Linux 작업이 AWS에서 실행될 수 있다고 쓰므로 모든 대상 작업이 AWS로 가는 것은 아니다. 러너 레이블과 워크플로 문법이 그대로라서 워크플로 파일은 고칠 필요가 없지만 네트워크 정책은 고쳐야 한다. GitHub는 Microsoft Entra 조건부 액세스처럼 발신 주소로 허용 여부를 정하는 신원 정책도 영향을 받는다고 짚었으므로, 방화벽 팀만이 아니라 신원·접근 관리 팀도 점검에 참여해야 한다. 이 점검 순서는 본 사이트의 제안이며 GitHub의 표현이 아니다. 변경 기록이 요구하는 것은 허용 목록을 meta 엔드포인트와 맞추는 일이고, 새 주소를 포함한 모든 러너 대역이 그곳에 공개된다고 밝힌다. 적용이 단계적이므로 워크플로가 확장된 풀에서 돌기 전에 갱신하라는 권고가 붙는다.

대부분의 팀에게 할 일은 작고 구체적이다. GitHub 호스팅 러너를 허용하는 방화벽 규칙, 조건부 액세스 정책, 클라우드 보안 그룹을 모두 찾고, 고정 대역을 meta 엔드포인트의 목록으로 바꾸고, 적용이 시작된 뒤 로그에서 차단된 연결을 확인한다. Windows 러너, 특수 목적 대형 러너, 사설 네트워크를 쓰는 팀은 이들이 이번 발표 범위 밖이라는 점을 알아 두면 된다.