GitHub의 pull_request_target 기본 차단은 2026년 12월 2일 시행 예고와 11월의 시험 차단 구간을 나누어 읽어야 합니다. 11월 2일 공지는 이전에 잡았던 시행 날짜를 변경한 안내입니다. 제목만 보고 지금 모든 저장소의 워크플로가 막혔다고 판단하지 마세요.
이번 글은 2026년 11월 3일 확인한 공식 자료를 기준으로 현재 평가 상태, 시험 구간, 향후 예고를 구분합니다. 실제 저장소의 정책이나 실패 기록을 조회하고 변경한 작업은 없으며, 자신의 계정에 무엇이 적용됐는지는 별도 확인이 필요합니다.
11월 2일 공지에서 어떤 날짜가 바뀌었나요?
GitHub는 기본 보호의 강제 적용 예고를 이전 11월 2일에서 12월 2일로 옮겼다고 안내합니다. 대상은 github.com의 Free·Team·Enterprise Cloud 공개 저장소이며 비공개·내부 저장소와 Enterprise Server는 제외됩니다. 적용 가능한 Actions 이벤트 정책에서 해당 이벤트를 명시적으로 허용하는 경우도 구분해야 합니다.
공식 원문은 pull_request_target 기본 차단 일정 변경 공지입니다. 공지에 적힌 날짜를 현재의 시행 완료나 앞으로 절대 바뀌지 않을 약속으로 바꾸어 읽지 않는 것이 좋겠습니다.
11월의 시험 차단 시간은 한국에서 언제인가요?
공지는 11월 9일과 16일, 각각 UTC 16:00~18:00에 기본 보호를 일시적으로 강제하는 brownout을 예고합니다. brownout은 여기서 예정된 시험 차단 구간을 뜻합니다. 한국시간으로는 다음 날 새벽이므로 날짜를 함께 바꾸어 적어야 합니다.
| 공식 공지의 UTC 구간 | 한국시간으로 환산한 구간 |
| 2026년 11월 9일 16:00~18:00 | 2026년 11월 10일 01:00~03:00 |
| 2026년 11월 16일 16:00~18:00 | 2026년 11월 17일 01:00~03:00 |
해당 구간에서 기본 규칙에 막힌 시도는 오류 주석이 있는 실패 실행을 만들고 워크플로는 실행되지 않는다고 설명합니다. 구간 뒤에는 기본 규칙이 경고와 함께 실행을 허용하는 평가 모드로 돌아간다는 안내입니다. 시간표를 실제 장애나 시험 완료 기록으로 쓰면 안 됩니다.
12월 2일이라는 최종 적용 예고에는 이 공지에서 정확한 시각이 제시되지 않았습니다. 위 두 시험 구간처럼 임의의 UTC 시각을 붙여 한국 날짜를 확정하지 마세요. 자신의 운영 일정에는 출처와 확인 날짜, 원문에 있는 시간 범위를 함께 남기는 방식을 제안합니다.
현재 평가 모드와 강제 차단은 무엇이 다른가요?
보안 문서는 적용 가능한 이벤트 정책이 없는 공개 저장소에 기본 정책을 더하며, 이미 구성한 적용 가능한 정책을 대체하지 않는다고 설명합니다. 현재 기본 정책은 evaluate 모드여서 실행이 계속되고 policy insights에서 강제 적용 시 막힐 실행을 살펴볼 수 있다고 안내합니다.
이 조건은 pull_request_target의 안전한 사용과 기본 정책 문서에서 확인했습니다. 개별 저장소가 어떤 정책의 대상인지 읽지 않은 상태에서 ‘공개니까 모두 같은 상태’라고 결론 내리지는 말아야 해요.
일반적인 정책 관리 문서는 사용자 정의 정책의 Evaluate 선택을 Enterprise Cloud에 한정해 안내합니다. 내장 기본 규칙의 현재 평가 상태와 모든 계정에서 같은 설정을 선택할 수 있다는 말은 구분해야 합니다. 관련 범위는 워크플로 실행 정책 관리 문서를 참고했습니다.
같은 문서는 기업·조직·저장소의 보호가 함께 겹쳐 적용된다고 설명합니다. 보호 대상을 조직이나 저장소, 특정 워크플로 경로로 나누고 누가 실행할지도 검토하도록 안내해요. 저장소 한 곳의 화면만 읽었다면 상위 조직이나 기업의 정책까지 모두 확인했다고 쓰지 않는 것이 좋겠습니다.
이 이벤트가 별도로 보호되는 이유는 무엇인가요?
공식 보안 문서상 pull_request_target은 기본 저장소의 신뢰 맥락에서 동작하며 토큰과 시크릿에 접근할 수 있습니다. 기본 브랜치의 신뢰된 흐름을 바꾸어 포크에서 온 코드를 받아 실행하면 위험이 생깁니다. 코드를 가져오는 행위와 그것을 빌드·테스트 등으로 실행하는 단계도 구분해 살펴봐야 합니다.
이 글에는 위험한 워크플로 코드나 허용 정책을 복사해 넣는 예시를 제공하지 않습니다. 문서에 나오는 이름을 알아봤다는 사실과 자신의 워크플로의 신뢰 경계를 검토했다는 사실은 다릅니다. 아래에서는 설정 변경 전에 남겨 볼 질문과 메모를 직접 구성했습니다.
내 저장소의 영향 범위는 어떤 순서로 읽을까요?
우선 저장소에 현재 표시된 공개 범위와 사용하는 GitHub 서비스 종류를 적어 보세요. 저장소 이름만 보며 추측하기보다 실제로 확인한 값과 확인하지 못한 값을 구분하는 겁니다. 조직에서 여러 저장소를 관리한다면 한 곳의 상태를 다른 곳에도 복사하지 않는 방식이 좋겠습니다.
| 자체 점검 질문 | 남길 수 있는 기록 |
| 어느 저장소를 보았나요? | 서비스 종류, 저장소 식별 정보, 공개 범위, 확인한 시각. |
| 어떤 자동화가 관련되나요? | 워크플로 파일과 담당자, 목적, 확인한 이벤트 이름. |
| 어떤 정책을 확인했나요? | 적용 범위와 상태, 읽은 근거, 아직 확인하지 못한 상위 정책. |
| 어느 자료에 근거하나요? | 공식 안내 날짜와 실제 실행·정책 화면에서 각각 읽은 내용. |
이 표는 GitHub의 공식 검사 결과나 보안 승인 양식이 아닙니다. 담당자가 질문을 빠뜨리지 않도록 만든 자체 메모예요. 확인할 권한이 없는 항목은 권한을 넓혀 보려고 하기보다 적절한 관리 담당자에게 문의할 내용으로 남겨 주세요.
워크플로에서는 이름과 목적도 함께 읽는 방식을 제안합니다. ‘테스트’라고 이름 붙어 있다고 실제로 무엇을 실행하는지까지 확인한 것은 아니에요. 파일을 읽어 본 단계라면 그 범위까지만 기록하고, 운영에서 어떻게 사용되는지 모른다면 담당자의 추가 확인이 필요하다고 표시하세요.
시크릿과 외부 코드의 경계는 어떻게 질문할까요?
검토 메모에는 ‘외부 기여자의 입력이 들어오는 곳’, ‘코드를 실행하는 곳’, ‘민감한 자원에 접근하는 곳’을 따로 적어 볼 수 있습니다. 이 셋이 어떤 흐름으로 연결되는지 담당자가 설명하도록 하는 제안입니다. 항목을 적었다고 검증이 완료되는 것은 아닙니다.
가령 가상의 자동화가 외부 요청을 받아 분류하는 일과 코드 검사를 함께 한다고 합시다. 검토자는 두 작업이 정말 같은 신뢰 수준을 필요로 하는지, 어떤 입력을 데이터로만 읽는지, 어떤 내용을 실행에 사용하는지 질문할 수 있어요. 실제 저장소를 분석해 그런 위험을 발견했다는 사례는 아닙니다.
문서에 제시된 더 안전한 이벤트 선택이나 역할 분리도 자신의 목적과 조건에 맞는지 검토할 일입니다. 이 글은 이벤트 이름만 기계적으로 바꾸면 같은 기능과 안전성이 유지된다고 권하지 않습니다. 변경이 필요한 경우에는 코드와 권한, 운영 영향을 이해하는 담당자의 검토로 연결해야 합니다.
특히 ‘기존 기능을 계속 쓰기’와 ‘필요한 범위의 보호를 유지하기’를 함께 질문해 보세요. 편의를 위해 모든 워크플로를 넓게 허용하는 방식을 기본 해결책으로 삼지 않는 것이 좋겠습니다. 허용 여부 자체를 이 글의 표나 예시가 대신 승인하지는 않습니다.
시험 구간을 준비한다면 어떤 기록을 나눌까요?
일정 메모에는 공지의 시간표, 팀에서 확인할 담당자, 관련 자동화의 목적을 나눠 적어 보세요. 한국시간을 적더라도 원문의 UTC 구간을 함께 남겨 두면 어떤 값을 옮겼는지 대조할 수 있습니다. 날짜를 적었다는 사실을 영향 검토 완료로 표시할 필요는 없습니다.
시험 전에 남길 기록과 시험 뒤 실제로 읽은 기록도 분리하는 방식을 제안합니다. 이전에는 어떤 실행이 영향을 받을 것으로 보였는지 적고, 이후에는 실제 관찰한 주석과 결과가 무엇인지 별도로 적는 겁니다. 이 글은 해당 구간에 워크플로를 실행하거나 결과를 확인하지 않았습니다.
실패를 관찰하게 된다면 오류 주석, 발생 시각, 대상 워크플로와 정책 상태를 먼저 확인할 항목으로 남길 수 있어요. 예고 시간과 겹쳤다는 이유만으로 모든 실패의 원인을 하나로 정하지 마세요. 기록에서 원인을 확인하지 못했다면 ‘미확인’이라고 남기고 담당자에게 연결하는 것이 좋겠습니다.
반대로 실행이 성공했다고 해서 모든 경로가 검토됐다고 적지 않는 방식도 필요합니다. 무엇을 시도했고 어떤 경로는 시도하지 않았는지 구분해 보세요. 그 기록은 제품 전체의 시행 상태나 다른 저장소의 안전성을 보증하는 자료가 아닙니다.
팀에 전달할 변경 검토안에는 무엇을 넣을까요?
가상의 인계 문장을 만들어 볼게요. ‘공식 예고와 관련 이벤트를 사용하는 파일은 확인했습니다. 조직의 적용 정책과 외부 코드 실행 여부는 담당자 검토가 남아 있습니다’라고 쓸 수 있습니다. 지금 아는 범위와 남은 질문을 함께 보여 주려는 예시예요.
기능을 유지하기 위해 어떤 작업이 필요한지도 검토 대상에 남겨 보세요. 단순히 실행을 다시 허용하는 데 목적을 두기보다, 실제로 필요한 자동화의 역할과 다루는 자원을 설명하는 겁니다. 현재 정책을 이해하기 전에 변경안을 확정하거나 넓은 권한을 먼저 주는 순서를 제안하지 않습니다.
변경을 검토한다면 담당자와 적용 여부를 판단할 근거도 적어 보세요. 기존 파일과 정책을 어디에서 확인할 수 있는지, 어떤 운영 경로를 다시 볼지 함께 남길 수 있습니다. 이 글은 보안 정책을 해제하거나 실제 저장소를 변경한 실행 보고가 아닙니다.
자주 묻는 질문은 어떻게 이해하면 될까요?
11월 3일에 실패한 실행은 이번 기본 차단 때문인가요? 실제 기록을 보지 않고 원인을 정할 수는 없습니다. 공지의 예고와 자신의 실행에서 관찰한 내용을 나눠 확인하세요. 이 글은 개별 계정의 실패를 재현하거나 정책 상태를 진단하지 않았습니다.
경고가 보이지 않으면 영향이 없는 건가요? 확인한 화면과 조회 범위를 먼저 적어 보세요. 보지 못한 기록을 없다고 단정하거나 다른 저장소의 결과를 가져와 적용 여부를 채우지 않는 방식이 좋겠습니다. 접근할 수 없는 정보는 담당자 확인이 필요한 상태로 두세요.
시간표대로 모든 것을 확정해 운영해도 되나요? 확인한 시점의 공식 계획으로 기록하고 실제 준비가 필요한 때에는 현재 공식 안내와 관리 담당자의 계획을 다시 대조할 일입니다. 이 글은 12월의 시행 완료나 변경 없는 일정을 보장하지 않습니다.
이번 글의 사실 기준일은 언제인가요?
사실 기준일은 2026년 11월 3일입니다. 같은 실행에서 보존한 공식 공지와 현재 공식 보안·정책 문서를 대조했습니다. 원문 일정의 한국시간 환산은 계산으로 확인했으며, 계정 조회·정책 변경·코드 실행·실제 차단 시험은 하지 않았습니다.
먼저 자신의 대상 범위와 관련 자동화, 현재 확인한 정책, 실제로 읽은 기록을 나눠 적어 보세요. 일정의 예고와 운영 관찰을 구분하고, 남은 보안 판단은 담당자의 검토로 연결하는 것이 이번 글에서 제안하는 준비 방식입니다.
'소프트웨어개발' 카테고리의 다른 글
| Edge 실행 가속 발표, 내 Windows도 지원되나요? 버전과 실행 조건 확인 (0) | 2026.11.04 |
|---|---|
| Copilot code review Max 발표: 더 깊은 검토와 승인 권한은 어떻게 고를까요? (0) | 2026.11.04 |
| GitHub public monitoring 정식 제공: 공개 유출 탐지는 어디까지 포함될까요? (0) | 2026.11.04 |
