GitHub draft PR도 제한에 포함: 에이전트 작업을 쌓기 전에 정할 입구 정책
에이전트가 코드를 빨리 만들수록 검토 대기열도 빨리 늘어납니다. draft PR은 아직 검토 요청 전이라는 표시지만 저장소가 감당해야 하는 작업에서 사라지는 것은 아닙니다. 이번 GitHub 변경은 그 입구를 다시 설계할 계기입니다.
10월 8일 무엇이 바뀌었나
GitHub는 2026년 10월 8일 사용자별 pull request 제한에 draft PR도 포함하도록 설정할 수 있다고 발표했습니다. 이전에는 초안이 그 제한에 포함되지 않아 일반 PR 한도를 설정해도 draft를 계속 만들 수 있었습니다. 자동으로 모든 저장소 설정이 바뀐다고 해석해서는 안 됩니다.
공식 발표가 설명하는 목적은 낮은 품질의 기여와 스팸으로 생기는 혼잡·알림·CI 실행 부담을 줄이는 것입니다. 발표에는 일률적인 추천 한도나 모든 팀에 맞는 숫자가 없습니다. 운영자는 실제 저장소 설정과 적용 대상을 먼저 확인해야 합니다.
초안 상태와 작업 용량을 분리하기
draft는 내용이 미완성임을 알리는 협업 상태이고 제한은 저장소에 들어오는 작업량을 제어하는 정책입니다. 검토가 준비되지 않았다는 이유로 소비하는 용량까지 0이 되는 것은 아닙니다. 다만 모든 초안이 비싼 CI를 실행한다고 단정할 수도 없습니다. 실제 워크플로 트리거와 실행 이력을 확인하세요.
예를 들어 에이전트가 같은 이슈의 세 대안을 각기 draft로 열면 선택지를 보여주기에는 편하지만 유지할 브랜치와 diff도 세 개가 됩니다. 이는 기능 출시를 세 번 확정한 것이 아니라 실험을 세 개 유지하는 상황입니다. 가능한 경우 이슈나 작업 기록에서 대안을 비교하고 검토 가능한 단위만 PR로 올리는 편이 낫습니다.
먼저 관찰할 세 가지
설정을 바꾸기 전에 열린 draft와 일반 PR 수, 각 초안의 담당자·목표·마지막 의미 있는 갱신을 기록합니다. 이어 관련 CI 실행·검토 대기·중복 이슈를 봅니다. 알림 수가 많다는 인상만으로 한도를 정하면 정상 기여자의 작업까지 막을 수 있습니다.
에이전트 작업에는 저장소·이슈·기존 PR을 연결하는 기록을 남기세요. 생성 실패를 만났을 때 즉시 다른 이름의 PR을 여는 루프는 금물입니다. 기존 PR이 있는지 확인하고 같은 작업을 갱신하도록 설계합니다. 이 절차는 제품의 자동 기능이 아니라 팀이 구현할 운영 제안입니다.
막힌 작업에 대한 안내가 필요하다
한도에 닿았을 때 기여자가 볼 안내에는 기존 작업을 이어갈 방법, 검토 받을 준비 기준, 문의할 담당자가 있어야 합니다. draft를 일반 PR로 바꾸는 것만으로 제한을 피할 수 있다고 안내해서는 안 됩니다. 닫거나 보관하기 전에는 담당자와 내용의 가치도 확인합니다.
정상적으로 여러 의존 PR을 쓰는 팀이라면 초안 수만으로 품질을 판단하지 마세요. 작은 diff를 쌓는 작업과 같은 내용을 반복 제출하는 작업은 다릅니다. 제한은 입구의 보호 장치이며 검토 기준·테스트·배포 판단을 대신하지 않습니다.
작게 적용하고 운영 결과를 비교하기
먼저 한 저장소에서 정책과 예외 처리 방법을 명시하고 실제 설정을 확인합니다. 이후 새 draft 증가, 기존 PR 재사용, 검토 대기와 기여자 차단 사례를 같은 기간으로 비교하세요. 수치가 줄었다고 품질이 좋아졌다고 바로 결론 내리지 말고 유효한 기여가 지연됐는지도 봅니다.
오늘 할 일은 에이전트를 더 자주 실행하는 것이 아니라 같은 작업이 같은 PR로 돌아오는 경로를 만드는 것입니다. 공식 발표의 커뮤니티 피드백 경로는 설정 적용 경험을 공유하도록 마련돼 있습니다. 특정 이용자의 반응이나 개선 효과는 확인 없이 꾸며 넣지 않았습니다.
공식 출처
2026년 10월 9일 확인. 제품 변경 사실과 이 글의 운영 제안을 구분해 적용하세요.