GitHub PR 보관 권한 확대: 댓글 자동화부터 멈추는 정리 절차
관리자에게 부탁하던 PR 정리를 triage 담당자가 직접 할 수 있게 됐습니다. 하지만 버튼을 누를 사람이 늘었다는 소식보다, 보관된 PR에 자동화가 계속 댓글을 쓰려는 상황을 먼저 점검할 필요가 있습니다. 리뷰 요청, 빌드 결과 요약, 에이전트의 진행 보고가 모두 PR 대화에 의존하는 팀이라면 보관을 단순한 목록 정리로 취급하기 어렵습니다.
공식 변경에서 확인할 경계
GitHub는 2026년 10월 8일 triage 이상 역할의 사용자가 PR을 보관하고 보관 해제할 수 있다고 발표했습니다. 보관하면 PR은 자동으로 닫히고 대화는 읽기 전용이 됩니다. 댓글·반응·자동 댓글도 차단됩니다. 10월 9일 보충 설명에 따르면 보관된 PR은 공개 보기에서 숨겨지며 triage·write·maintain·admin 역할에는 보입니다. 보관 해제는 댓글과 반응을 다시 허용하지만 PR을 다시 열지는 않습니다.
자동 댓글은 제출 전에 상태를 읽기
자동화가 실패할 때 무조건 전송을 반복하면 읽기 전용 대화에서 같은 오류만 쌓일 수 있습니다. 팀 운영 규칙으로 PR의 현재 상태를 확인하고, 보관된 대상으로 확인된 작업은 댓글 전송 대신 내부 작업 기록에 종료 이유를 남기는 방법을 권합니다. 이는 새 API 필드나 모든 봇의 자동 대응을 약속하는 설명이 아닙니다. 실제 연동이 제공하는 상태와 오류를 확인하고, 권한 부족·보관·네트워크 실패를 서로 다른 원인으로 기록해야 합니다.
정리 전에 검토 근거를 옮기기
스팸이나 중복 PR을 치우는 일과 아직 판단이 남은 구현을 보관하는 일은 구분하세요. 변경 이유, 마지막 검증 결과, 연결된 이슈, 중복이라면 기준 PR을 먼저 정리하는 편이 좋습니다. 공개 검토 근거가 필요한 프로젝트에서는 보관 뒤 외부 독자가 PR을 보지 못할 수 있다는 점도 고려해야 합니다. 필요한 근거를 적절한 공개 이슈나 릴리스 기록에 남기되, 비공개 내용을 공개하는 근거로 이 절차를 사용해서는 안 됩니다.
triage 위임은 코드 변경 권한과 별개
일상적인 정리를 위해 모든 담당자에게 write 권한을 주는 대신 필요한 역할로 운영할 여지가 커졌습니다. 그래도 보관 대상 선정 기준과 예외는 합의가 필요합니다. 리뷰 중인 PR, 연결된 작업의 마지막 증거, 외부 기여자의 문의가 남은 PR은 사람이 판단할 대상으로 두세요. 보관 해제 후에도 닫힌 상태가 유지되므로 재개 의도라면 담당자가 별도로 다시 열지 확인해야 합니다.
오늘 할 일은 실제 저장소 역할을 확인하고, 보관 대상 한 건에서 댓글 자동화의 종료 처리를 시험하는 것입니다. 실패 응답만 보고 새로운 PR을 만들거나 기존 PR을 다시 제출하지 마세요. 공식 변경은 확인된 사실이며 상태별 기록·검토 기준은 이 글의 운영 제안입니다. 커뮤니티 논의는 의견 수렴 창구로 연결하며 참여 규모나 효과를 추정하지 않습니다.
공식 출처와 논의
새 권한을 적용하기 전에 팀의 PR 보관 기준과 자동 댓글 종료 규칙을 함께 검토해 보세요.