GitHub Actions 로그가 안 보인다면: 새 저장소 호스트 120개가 알려주는 것
워크플로 파일은 그대로인데 로그나 작업 요약을 불러오는 데 문제가 생기면, 먼저 바꾼 코드를 의심하기 쉬워요. 그런데 실행에 필요한 연결과 결과를 보관하는 연결이 서로 다를 수 있어요. GitHub가 10월 22일 알린 Actions Blob 저장소 엔드포인트 추가는 바로 이 부분을 짚고 있어요.
추가된 이름에는 두 묶음의 숫자가 있어요
공식 발표의 새 호스트는 productionresultssa30.blob.core.windows.net부터 productionresultssa49.blob.core.windows.net까지, 그리고 productionresultssa100.blob.core.windows.net부터 productionresultssa199.blob.core.windows.net까지예요. 양 끝을 모두 포함하므로 각각 20개와 100개, 합계 120개예요. 중간 숫자 50~99까지 새 범위에 들어간다는 뜻은 아니에요.
여기서 영향을 받는 쪽은 Actions Blob 저장소에 접근할 때 네트워크 허용 목록을 쓰는 환경이에요. 기존에 productionresultssa*.blob.core.windows.net을 허용하고 있다면 이번 추가만을 위해 바꿀 것은 없다고 GitHub가 설명해요. 개별 이름을 나열한 환경에서는 새 호스트가 빠질 수 있고, 발표는 작업 요약과 로그의 중단을 피하도록 그 이름들을 추가하라고 안내해요.
이름을 120개 늘리는 일과 규칙을 넓히는 일
두 방식은 겉보기에는 비슷하지만 범위가 달라요. 별표가 있는 기존 규칙은 숫자가 늘어나는 경우를 이미 포괄할 수 있고, 개별 호스트 목록은 이름 하나하나가 허용 대상이에요. 그래서 이번 소식을 봤다고 모든 환경의 규칙을 넓힐 이유는 없어요. 현재 방식에서 빠진 정확한 이름이 무엇인지 먼저 대조하면 돼요.
두 범위를 이름 집합으로 만들면 빠진 주소를 찾기 쉬워져요. 이번 예제는 시작과 끝을 포함하는 숫자 배열을 만든 뒤, 각 숫자를 호스트 이름으로 바꾸어 Set에 넣었어요. 아래 첫 이미지에서 각 범위의 개수를, 다음 결과 이미지에서 경계값이 포함되는지 볼 수 있어요. 이 집합은 이번에 발표된 추가분만 담고 있으므로 기존에 허용한 주소에 이어서 대조하는 자료로 읽으면 돼요.
경계값을 넣어 보면 차이가 바로 보여요
직접 실행한 결과에서 30·49·100·199번 호스트는 집합에 있었고, 200번은 없었어요. 끝에 .example.org를 붙인 이름도 없었어요. 문자열 어딘가에 익숙한 주소가 들어 있다는 이유만으로 허용하면 다른 도메인까지 통과할 수 있지만, 정확한 이름 비교는 그 예제를 거절해요. 다만 이 결과는 집합 판별을 확인한 것이고 실제 방화벽 장비의 와일드카드 해석을 시험한 결과는 아니에요.
실제 환경에서는 공식 Meta API의 현재 값을 읽고, 장비가 FQDN·와일드카드·IP를 각각 어떻게 처리하는지 맞춰 봐야 해요. GitHub 문서는 문서에 든 응답이 예시이며 최신 값은 API를 직접 조회하라고 안내해요. 셀프호스트 러너 문서도 기능에 따라 필요한 도메인을 나눠 설명하고 CNAME을 따라 추가 규칙이 필요할 수 있다고 알려줘요. 이름 목록을 갖는 것과 그 이름으로 연결되는 경로가 열리는 것은 별개의 확인이에요.
초록 체크 옆에 남는 빈 공간
예를 들어 실행 결과 페이지는 열리는데 로그만 열리지 않는 상황이라면, 러너의 작업 시작과 로그를 읽는 요청을 나눠 살펴볼 수 있어요. 브라우저에 표시된 오류나 네트워크 장비에서 거절한 대상 이름을 보면 어느 연결이 빠졌는지 좁히는 데 도움이 돼요. 이때 새 범위에 없는 이름이 보인다면, 이번 추가분만 바라보기보다 해당 요청의 공식 통신 요구사항으로 돌아가 보는 편이 좋아요.
이번 변경의 흥미로운 점은 YAML 문법에 있지 않아요. 빌드 서비스가 커지면서 결과를 담는 주소도 늘어난다는 데 있어요. 개별 호스트를 엄격히 관리하는 환경이라면 발표된 두 구간을 현재 목록과 비교하고, 변경 뒤 로그와 작업 요약이 실제로 보이는지 확인하는 것까지가 하나의 자연스러운 흐름이에요. 아래 공식 발표와 러너 통신 문서에서 자기 환경에 해당하는 부분을 이어 읽어 보세요.
출처와 더 읽기
GitHub Docs · Self-hosted runners · Communication
기준일은 2026년 10월 24일이에요. 실제 네트워크 규칙은 사용하는 장비의 이름 해석 방식과 공식 최신 목록을 함께 확인해 적용해 주세요.