GitHub이 6월 17일에 쓰기 권한 없는 사용자의 동시 열린 PR 수를 제한하는 기능을 냈습니다. AI가 쏟아내는 저품질 PR에 메인테이너가 시달린다는 얘기 끝에 나온 기능이고, 2016년부터 요청되던 것이기도 합니다.
그래서 실제 저장소 큐에서 이게 얼마나 걸러지는지 재봤습니다. 봇을 빼고, 쓰기 권한 없는 작성자가 연 PR만 세서, 한도를 3으로 뒀을 때 몇 건이 미뤄졌을지 계산했습니다.
- huggingface/transformers — 열린 PR 55건 / 작성자 49명 / 한도3이 미뤘을 PR 1건
- typescript-eslint — 28건 / 24명 / 1건
- DIYgod/RSSHub — 26건 / 23명 / 1건
- django/django — 79건 / 59명 / 7건
- caddyserver/caddy — 58건 / 43명 / 7건
- coollabsio/coolify — 86건 / 68명 / 11건
2~13%입니다.
이유는 큐의 모양이었습니다. transformers는 PR 55건이 작성자 49명에게서 옵니다. coolify는 86건에 68명. 한 사람이 서른 개를 여는 스팸 패턴이 아니라, 서른 명이 하나씩 연 것입니다. 한도는 전자를 겨냥해 만들어졌는데 실제 큐는 후자입니다.
기능이 쓸모없다는 얘기는 아닙니다. 한 계정이 큐를 도배하는 저장소는 실재하고, 그런 곳은 전에는 방어할 수단이 없었습니다. 다만 리뷰어에게 도달하는 양은 거의 그대로라는 것이고, 무엇을 먼저 읽을지 정하는 일은 남습니다.
같이 재본 것 하나 더. 자동으로 저품질 PR을 닫아주는 액션을 설치한 저장소 167곳을 찾아봤더니, 큐가 살아 있는 30곳 전부 pull_request_creation_policy가 all이었습니다. 기본값이라 "아무도 안 바꿨다"는 뜻이긴 한데, 제한 동기가 가장 강한 집단이 문은 안 닫고 필터만 달았다는 것이기도 합니다.
그리고 그 167곳 중 126곳(75%)은 열린 PR이 4건 미만이었습니다. "N곳이 슬롭 필터를 깔았다"를 "N곳이 홍수를 겪는다"로 읽으면 안 된다는 뜻입니다. 저도 그렇게 읽다가 재보고 고쳤습니다.
측정 방법과 한계는 링크한 문서에 있습니다. 한도 3은 제 가정이고(저장소마다 다르게 설정합니다), 열린 큐 스냅샷이라 한도에 막혀 아예 안 열린 PR은 안 보입니다 — 그게 기능의 요점 중 하나이기도 하고요. 공개 PR 목록만 있으면 누구나 재현할 수 있습니다.
(공개: 이 측정은 제가 만든 PR 트리아지 체커에서 나왔습니다. 이해관계가 있다는 뜻이니 감안해서 읽어주시고, 수치는 저장소별 공개 PR 목록에서 그대로 재현됩니다.)