PR을 받았는데 자동화가 멈춘다면? GitHub의 12월 2일 차단 전에 확인할 것

공개 저장소에서 pull_request_target을 사용하는 팀이라면, 12월까지 기다리지 말고 지금 실행 정책을 확인해야 합니다. GitHub는 이 이벤트의 기본 차단을 2026년 12월 2일부터 적용하고, 그 전에 두 차례 시험 차단을 진행한다고 발표했습니다. 모든 GitHub Actions가 멈추는 것은 아닙니다. 외부 PR에 반응하는 특정 자동화와 그 실행 권한을 점검해야 하는 변화입니다.

첫 점검일은 12월이 아니라 11월입니다

GitHub의 11월 2일 공지는 기존에 11월 2일로 예정했던 적용일을 12월 2일로 변경했다고 명시합니다. 현재 기본 정책은 평가 모드입니다. 실행을 바로 막는 대신 어떤 실행이 차단 대상이 되는지 미리 확인할 수 있습니다.

그 사이 시험 차단이 있습니다. 한국시간으로는 11월 10일과 11월 17일, 각각 오전 1시부터 3시까지입니다. 원문의 11월 9일·16일 UTC 16:00–18:00를 한국시간으로 환산한 일정입니다. 이 시간에는 기본 규칙에 걸린 실행이 오류 설명과 함께 실패로 생성되고, 워크플로 자체는 실행되지 않습니다. 시험 시간이 끝나면 다시 평가 모드로 돌아갑니다. GitHub 공식 일정 · 2026년 11월 2일 발표

대상은 GitHub Free·Team·Enterprise Cloud의 공개 저장소입니다. 비공개·내부 저장소와 GitHub Enterprise Server는 이번 변경 대상이 아닙니다. 이미 적용되는 이벤트 정책이 있다면 그 정책도 함께 확인해야 합니다. 모든 저장소에 같은 차단 결과가 생긴다고 볼 수는 없습니다.

위험한 것은 PR 자체보다 권한과 코드의 조합입니다

pull_request_target은 PR을 받은 원본 저장소의 문맥에서 실행됩니다. 라벨을 붙이거나 분류 작업을 하는 데 쓸 수 있지만, 저장소의 비밀값과 권한 있는 토큰에 접근할 수 있다는 점이 중요합니다.

기본 동작만으로 외부 기여자의 코드가 자동 실행되는 것은 아닙니다. 문제가 되는 경로는 별도로 외부 PR의 코드를 가져온 뒤 빌드·테스트·설치 명령 등으로 실행하는 경우입니다. 신뢰하지 않은 코드와 높은 권한이 같은 작업 안에서 만나는 셈입니다. GitHub 보안 문서

예를 들어 라벨만 붙이면 되는 자동화에 외부 PR 코드를 가져와 실행하는 단계까지 섞여 있다면, 먼저 역할을 나눌 수 있는지 살펴볼 필요가 있습니다. 자동화를 살리겠다고 모든 실행을 허용하는 것보다, 어떤 작업에 어떤 권한이 필요한지 좁히는 편이 이번 변경의 취지에 맞습니다.

먼저 찾고, 필요한 작업만 남기세요

첫째, 공개 저장소의 .github/workflows에서 pull_request_target 사용 여부를 확인합니다. 이어서 해당 워크플로가 외부 PR 코드를 내려받거나 실행하는지, 비밀값과 토큰 권한이 실제로 필요한지 검토합니다. 이벤트 이름만 찾아 바꾸고 끝낼 일은 아닙니다.

둘째, 관리자 권한으로 Actions 정책과 Policy insights를 확인합니다. GitHub는 이 화면에서 차단됐거나 평가 모드에서 차단될 실행을 살펴볼 수 있다고 안내합니다. 저장소·조직·기업 수준의 정책이 함께 적용될 수 있으므로, 한 화면의 허용만으로 전체 정책을 판단하지 않는 것이 좋습니다. 워크플로 실행 정책 안내

셋째, 필요 없는 경우에는 기본 차단을 유지하거나 작업 성격에 맞는 안전한 이벤트로 재설계합니다. 반드시 필요한 경우에만 적용 가능한 정책에서 특정 워크플로를 대상으로 허용하는 방식을 검토합니다. pull_request로 바꾸면 실행 문맥과 권한도 달라질 수 있으므로, 이름을 일괄 치환하기보다 테스트와 권한 검토를 함께 해야 합니다.

연장된 한 달을 예외 허용 기간으로 쓰지 않으려면

이번 소식의 핵심은 자동화가 곧 전부 중단된다는 경고가 아닙니다. 공개 저장소에서 외부 입력을 받는 작업을 찾아, 코드 실행과 권한을 구분할 점검 시간이 생겼다는 데 있습니다.

한국시간 11월 10일 첫 시험 차단 전에 사용 중인 워크플로, 필요한 권한, 적용 정책, 담당자를 짧게 정리해 두세요. 시험 시간의 실패 기록을 확인하고 필요한 변경만 검증하면, 12월 2일을 앞두고 급하게 예외를 넓히는 상황을 줄일 수 있습니다. 실제 영향은 각 저장소의 이벤트와 정책 구성에 따라 달라집니다.