같은 GitHub Actions인데, 오늘은 AWS에서 실행될 수 있어요
어제까지 잘 돌던 GitHub Actions가 오늘은 외부 서비스 로그인에서 막힌다면 YAML만 비교해서는 단서가 안 나올 수 있어요. GitHub가 10월 28일 Linux 러너의 실행 기반을 Azure에 더해 AWS로 넓힌다고 발표했거든요. 작업을 적을 때 쓰는 라벨은 같아도, 작업이 외부로 나갈 때의 주소는 달라질 수 있어요.
달라지는 것은 실행할 컴퓨터를 고르는 풀(pool)이에요
공식 발표의 대상은 표준 2코어·4코어 Linux 러너와 특수 구성이 없는 호환 2코어·4코어 larger runner예요. Windows나 사설 네트워킹 등 특수 구성 러너는 이번 변경 대상이 아니에요. Free·Pro·Team의 해당 러너에는 자동 적용되고, Enterprise Cloud는 기업 설정의 Actions > Hosted compute cloud providers에서 AWS compute를 켜는 선택 방식이에요.
GitHub는 기존 러너 라벨과 워크플로 문법을 유지한 채 가용한 클라우드에 작업을 배치해요. 목표는 공급 여력이 부족해 생기는 대기시간을 줄이고 복원력을 높이는 거예요. 특정 작업이 반드시 빨라진다는 수치나 두 클라우드에 동시에 복제 실행한다는 약속은 이 발표에 없어요. 그래서 실행 위치 변화와 우리 작업의 성능 측정은 따로 읽는 편이 정확해요.
성공과 실패가 번갈아 보일 수 있는 이유
가상의 예로, 배포 API가 Azure 주소에서 온 요청만 허용한다고 해 볼게요. 같은 워크플로가 Azure에서 실행되면 통과하고 새 풀에서 다른 출구 주소를 받으면 차단될 수 있어요. Microsoft Entra Conditional Access처럼 로그인 과정의 네트워크 조건도 영향을 받을 수 있다는 게 GitHub의 설명이에요. 실제 장애를 겪었다는 이야기는 아니며, 변경이 어떻게 간헐적 실패로 보일 수 있는지 설명하는 예시예요.
여기서 토큰을 무조건 재발급하거나 워크플로를 AWS 전용으로 갈아엎기 전에 볼 정보가 있어요. 실패한 연결의 시간, 목적지, 출발 IP, 그리고 그 목적지가 적용한 정책이에요. 작업이 대기열에서 늦게 시작한 것과 시작한 뒤 인증이 거부된 것은 다른 단계예요. 원인을 분리하면 실행 용량 확대를 인증 문제로 오해하거나, 반대로 네트워크 거부를 토큰 만료로 오해하는 일을 줄일 수 있어요.
IP 목록은 문자열 목록보다 주소 범위에 가까워요
공식 출발점은 GET https://api.github.com/meta 응답의 actions 배열이에요. REST 문서는 예시 응답을 복사하지 말고 현재 API를 조회하라고 안내해요. CIDR은 주소 하나가 아니라 범위를 뜻하므로 단순 문자열 일치로 검사하면 안 돼요. 아래 자료는 문서용 주소 192.0.2.0/24에 대해 Python ipaddress로 직접 실행한 예제예요. 192.0.2.10과 192.0.2.200은 포함되고 198.51.100.10은 제외돼요. GitHub의 실제 러너 IP나 우리 서비스 접속 기록은 아니에요.
다만 actions 전체를 방화벽에 넣는 것이 모든 환경의 정답은 아니에요. GitHub 러너 문서는 표준 러너의 범위가 많아 내부 자원 허용 목록으로 쓰는 방식을 권하지 않고, 정적 IP가 있는 larger runner나 자체 러너를 대안으로 제시해요. 네트워크 출처만으로 접근 주체를 식별할 수도 없어요. 기존 인증과 최소 권한을 유지하면서, 넓어진 실행 풀을 수용할지 고정된 출구가 필요한지 서비스 특성에 맞춰 고를 문제예요.
라벨은 그대로여도 연결의 전제는 바뀔 수 있어요
이번 발표가 흥미로운 지점은 개발자가 코드를 고치지 않아도 CI의 기반이 바뀐다는 데 있어요. 먼저 실패가 실행 전 대기인지 실행 후 연결인지 구분하고, 네트워크 제한이 있다면 현재 actions 범위와 실제 정책을 대조해 보세요. 엄격하게 고정된 출구가 필요한 환경이라면 그 요구에 맞는 러너를 선택하는 것이 자연스러워요. 배포판 라벨 하나에 클라우드 제공자까지 묶어 생각하던 전제를 풀어 주는 변화예요.