로그와 워크플로 요약은 빠지고, 빌드 단계만 성공합니다. 가장 빠른 확인은 방화벽이 호스트를 하나씩 허용하는지 보는 것입니다. 와일드카드로 관련 도메인을 허용했다면 새 호스트 규칙을 더하기 전에 적용 범위를 검증하세요. 개별 호스트만 등록했다면 공식 최신 목록과 대조해 갱신한 뒤 실제 워크플로로 확인해야 합니다.
이 글은 기업 방화벽·프록시·DNS 필터를 관리하며 GitHub Actions의 저장소 엔드포인트를 점검하는 담당자를 위한 절차입니다. 자체 호스팅 맥 러너의 네트워크를 운영하거나 배포 검증을 맡고 있다면, 아래 지표에 따라 규칙과 작업 결과를 확인하세요.
마지막 업데이트: 2026년 10월 27일. GitHub의 변경 공지, 메타 API 문서, 자체 호스팅 러너 네트워크 요구 사항을 대조했습니다. 2026년 10월 22일 공지는 GitHub.com Actions blob storage에 새 호스트 엔드포인트가 추가됐다고 밝힙니다. 공지에는 새 호스트 그룹이 두 개 제시되어 있습니다. 다만 모든 기업에 적용되는 강제 변경 기한은 공지에 없습니다.
엔드포인트 범위: 허용 목록이 관리하는 대상
이번 변경은 GitHub Actions blob storage 호스트에 관한 내용입니다. 러너 레이블이나 워크플로 파일을 수정하는 작업과는 다릅니다. 우선 방화벽 정책이 호스트 이름을 관리하는지, IP 주소를 관리하는지부터 확인하세요.
IP 주소만 허용하는 정책이라면 호스트 목록을 그대로 복사하는 것으로 끝나지 않습니다. 반대로 호스트를 하나씩 등록하는 정책과 특정 도메인 범위에 와일드카드를 적용한 정책도 판정이 달라집니다. 방화벽, 프록시, DNS 필터 중 실제 연결을 통제하는 장비의 적용 규칙을 기준으로 삼으세요.
GitHub 공지에 표시된 두 호스트 그룹은 원문에서 정확한 값을 확인해 대조해야 합니다. 이 글에 호스트 문자열을 추정해 옮기지 않는 이유는, 한 글자 차이도 잘못된 규칙이나 불필요한 허용으로 이어질 수 있기 때문입니다. 공식 공지의 호스트 목록을 변경 요청의 근거로 남기세요.
규칙 정밀도: 수정 여부를 가르는 조건
다음 조건으로 변경 범위를 결정하세요.
- 관련 도메인을 대상으로 한 와일드카드 규칙이 현재 적용 중이고, DNS·프록시 정책도 새 호스트 해석을 막지 않는다면: 이번 추가 호스트만을 위한 개별 규칙은 보통 만들지 않아도 됩니다. 실제 워크플로로 적용 여부를 확인하세요.
- 필요한 호스트를 이름별로 나열하는 규칙이라면: 공식 공지와 현재 메타 API 응답을 대조하고, 누락된 호스트만 변경 절차에 올리세요.
- 정책이 IP 주소에 묶여 있거나 프록시가 별도 도메인 검사를 한다면: 호스트 규칙만 보고 통과로 판정하지 마세요. 실제 경로와 적용 조건을 보안 담당자와 함께 확인하세요.
- 허용 범위를 넓혀야만 해결될 것 같다면: 모든 외부 출력을 허용하는 방식으로 우회하지 말고 차단 로그와 필요한 목적지를 먼저 확인하세요.
주의: GitHub.com Actions에 대한 이번 공지를 GitHub Enterprise Server 환경에도 자동으로 적용된다고 해석하지 마세요. 운영 제품과 네트워크 경로가 같은지 별도로 확인해야 합니다.
데이터 최신성: 공식 목록과 현재 응답 대조
오래된 티켓이나 문서 예시는 현재 허용 목록의 근거로 충분하지 않습니다. GitHub 메타 API 문서와 현재 메타 API 응답을 확인해 현재 제공되는 데이터를 기준으로 삼으세요. 메타 API 응답의 구조와 공지에 언급된 엔드포인트를 확인하고, 변경 전후의 조회 시각과 사용한 값을 보관하세요.
메타 API가 제공하는 목록은 정적인 방화벽 설정을 대신하지 않습니다. 응답을 읽었다고 해서 조직의 프록시나 DNS 필터가 해당 호스트를 허용한다는 뜻은 아닙니다. 방화벽 정책이 어떤 필드를 소비하고 어떤 호스트 패턴을 매칭하는지 확인해야 합니다. 문서의 예시 응답을 현재 목록처럼 붙여 넣지 말고, 조회 시점의 실제 응답을 사용하세요.
이번 공지의 날짜는 2026년 10월 22일이며, 기준 검토일은 2026년 10월 27일입니다. 두 날짜는 GitHub 변경 공지와 이 글의 검토 기준을 가리킵니다. 공지 밖의 일괄 마감일은 설정하지 말고, 내부 변경 관리 기준에 따라 재검토 시점을 정하세요.
기능 구분: 저장소 연결이 담당하는 전송 경로
저장소 호스트 차단은 Git 저장소 접근이나 GitHub API 인증 오류와 같은 문제라고 단정할 수 없습니다. 자체 호스팅 러너의 네트워크 요구 사항을 확인하고, 실패한 작업이 어떤 목적지로 연결하려 했는지 로그로 분리하세요.
특히 다음 전송 경로는 실제 사용 여부를 기준으로 검증합니다.
- 작업 로그와 워크플로 요약이 실행 화면에서 조회되는지 확인합니다.
- 팀이 쓰는 빌드 아티팩트의 업로드와 다운로드를 시험합니다. 아티팩트 동작은 공식 워크플로 아티팩트 문서를 참고하세요.
- 캐시를 사용하는 워크플로는 저장과 복원이 되는지 확인합니다. 캐시 설정과 동작은 의존성 캐시 문서와 대조하세요.
- 변수나 권한 설정에서 비롯된 실패라면 네트워크 변경으로 해결하려 하지 말고 워크플로 변수 참조도 확인하세요.
워크플로 검증: 로그부터 아티팩트까지 재현
변경 전후에 같은 네트워크 조건으로 대표 워크플로를 실행하세요. 네트워크 정책이 다른 별도 맥 CI 환경이 있다면 그 환경에서도 검증해야 합니다.
- 영향을 받는 방화벽·프록시 규칙과 기존 허용 목록을 내보내 변경 기록에 연결합니다.
- GitHub 공지와 메타 API의 현재 응답을 비교해 새 호스트가 빠졌는지 확인합니다.
- 적용 대상이 개별 호스트 규칙인지, 와일드카드인지, IP 기반 정책인지 판정합니다.
- 필요할 때만 최소 범위로 규칙을 갱신하고 변경 승인과 롤백 방법을 기록합니다.
- 대상 맥 러너에서 대표 빌드와 팀이 실제 사용하는 로그·요약·아티팩트·캐시 작업을 실행합니다.
- 작업 결과, 네트워크 로그, 규칙 매칭 기록을 함께 보관하고 DNS 실패·프록시 거부·방화벽 차단·권한 오류를 구분합니다.
변경 판정: 팀 정책에 맞춘 검토표
아래 표는 변경 여부를 정하기 위한 판정 기준입니다. ‘양호’는 확인된 정책과 실행 결과가 일치한다는 뜻이며, 실행 기록이 없으면 통과로 간주하지 마세요.
| 규칙 형태 또는 검증 항목 | 확인할 근거 | 판정 |
|---|---|---|
| 호스트별 허용 | 현재 공식 호스트 목록과 방화벽 규칙의 대조 | 빠진 항목이 있으면 갱신 |
| 관련 도메인 와일드카드 | 와일드카드 범위, DNS·프록시 적용, 실제 연결 기록 | 범위가 맞으면 새 규칙 추가 전 워크플로 검증 |
| IP 기반 제한 | 조직의 실제 IP 매칭 정책과 연결 로그 | 호스트 목록만으로 판정하지 않음 |
| 로그·요약·아티팩트·캐시 | 대표 워크플로의 조회·업로드·복원 결과 | 사용 중인 경로별로 확인 |
| 변경 이력 | 공식 공지, 메타 API 조회 결과, 승인 기록, 실행 결과 | 함께 보관하고 재검토 담당자 지정 |
자주 묻는 질문
와일드카드 규칙이 있으면 추가 확인은 필요 없나요? 개별 호스트 규칙을 새로 만들 필요가 없을 수는 있지만, 와일드카드의 실제 대상 범위와 DNS·프록시 정책은 따로 확인해야 합니다. 대표 맥 워크플로에서 로그, 요약, 필요한 아티팩트 전송까지 검증하세요.
메타 API 응답과 공지의 호스트가 다르면 무엇을 기준으로 하나요? 응답을 조회한 시각과 공지의 적용 범위를 기록한 뒤, 양쪽의 차이를 그대로 변경 근거로 삼지 마세요. GitHub 공식 문서를 다시 확인하고, 실제 방화벽 규칙이 참조하는 데이터와 필요한 호스트를 네트워크 담당자와 대조한 뒤 승인 절차를 진행하세요.
로그만 보이지 않고 빌드는 성공하면 방화벽 문제인가요? 가능한 원인 중 하나지만, 네트워크 차단으로 바로 결론 내리면 안 됩니다. 러너 연결 로그와 프록시·방화벽 판정 기록을 확인하고, 권한 오류와 작업 요약 처리도 구분하세요. 아티팩트와 캐시를 쓰는 경우 각각의 전송 결과도 따로 확인해야 합니다.
고정된 재검토 주기가 정해져 있나요? 이번 공지에 모든 조직을 위한 강제 재검토 주기나 일괄 마감일은 제시되지 않았습니다. 조직의 변경 관리 기준을 적용하되, GitHub의 엔드포인트 공지나 러너 네트워크 문서 변경, 사내 DNS·방화벽 정책 변경을 재검토 조건에 포함하세요.
규칙 검증을 마친 뒤에도 맥 빌드 환경의 네트워크 경계와 운영 책임을 분리해야 한다면, 먼저 MACGPU의 원격 맥 구성을 검토하고 현재 운영 방식과 비교하세요. 기존 사내 장비는 직접 통제할 수 있지만 하드웨어 조달·유지 관리와 환경별 설정을 계속 맡아야 합니다. 자체 호스팅도 네트워크와 보안 정책을 세밀하게 통제할 수 있는 대신 운영 부담이 남습니다. 임시 또는 별도 맥 CI 환경을 비교하려는 경우에는 MACGPU의 원격 맥 선택지를 살펴보고, 실제 접근 방식과 인수 검증 조건이 팀 정책에 맞는지 확인하세요. 서비스가 특정 네트워크 접근을 지원한다고 미리 가정하지 말고, 계약 전 필요한 연결 경로를 확인하는 것이 안전합니다.