Hacker News 2026.06.25 24

AI가 쏟아내는 'PR 폭탄', 깃허브가 마침내 제동을 걸기 시작했어요

오픈소스 메인테이너들의 새로운 골칫거리

오픈소스 프로젝트를 운영하고 관리하는 사람을 메인테이너(maintainer)라고 해요. 전 세계 누구나 코드를 고쳐서 '이거 좀 반영해주세요' 하고 제안하는 게 PR(Pull Request, 풀 리퀘스트)인데, 원래 이건 오픈소스의 꽃이거든요. 모르는 사람이 보내준 작은 수정 하나가 프로젝트를 더 좋게 만드는 게 오픈소스의 낭만이니까요.

그런데 요즘 이 PR이 거꾸로 메인테이너를 괴롭히는 골칫거리가 됐어요. AI 코딩 도구가 흔해지면서, 본인이 제대로 들여다보지도 않은 채 AI한테 시켜 만든 저품질 PR이 우수수 쏟아지거든요. 의미 없는 오타 수정이나 줄바꿈 정리 같은 걸 무더기로 올리거나, 이력서에 '오픈소스 기여' 한 줄 넣으려고 영혼 없이 던지는 PR도 많고요. 이런 걸 'AI 슬롭(slop, 영혼 없이 양산된 쓰레기)'이라고 부르기도 해요.

깃허브의 처방: PR에 제한을 걸다

메인테이너 입장에선 PR이 하나 올라올 때마다 코드를 읽고, 동작을 확인하고, 정중하게 답을 달아야 해요. 그런데 쏟아지는 게 죄다 쓸모없는 PR이면, 진짜 가치 있는 기여 한 건이 그 소음에 파묻혀 버려요. 시간과 에너지가 엉뚱한 데로 다 새어 나가는 거죠.

그래서 GitHub가 메인테이너에게 'PR을 통제할 권한'을 주기 시작했어요. 한 번에 받아들이는 PR 수에 한도를 두거나, 일정 조건(예: 먼저 이슈로 논의를 거친 사람, 일정 기준을 충족한 기여자)을 만족한 경우에만 PR을 열 수 있게 막는 식이에요. 신호 대 잡음비(signal-to-noise, 진짜 중요한 정보 대 쓸데없는 소음의 비율)를 끌어올려서, 메인테이너가 정말 검토할 가치가 있는 것에 집중하게 해주자는 취지예요.

왜 이게 미묘하고 민감한 문제일까

오픈소스의 정신은 '개방'이잖아요. 그런데 무한정 열어두니 메인테이너가 번아웃에 빠지는 역설이 생긴 거예요. 너무 닫으면 신규 기여자의 진입 문턱이 높아지고, 너무 열면 소음에 짓눌려요. 결국 이건 '개방'과 '지속 가능성' 사이에서 균형점을 찾는 일이고, 깃허브의 이번 변화는 추를 '지속 가능성' 쪽으로 살짝 옮긴 거라고 볼 수 있어요.

업계 맥락

이 흐름은 갑자기 튀어나온 게 아니에요. 해마다 10월이면 열리는 기여 이벤트 Hacktoberfest에선 티셔츠를 노린 스팸 PR이 쏟아져 한바탕 홍역을 치르곤 했어요. 또 curl 같은 핵심 프로젝트의 메인테이너 Daniel Stenberg는 'AI가 그럴듯하게 지어낸 가짜 보안 취약점 제보 때문에 시간을 낭비하고 있다'고 공개적으로 토로하기도 했고요. 즉 '사람이 만든 소음'에 더해 'AI가 양산하는 소음'까지 겹치면서, 플랫폼 차원의 방어 장치가 필요해진 거예요.

한국 개발자에게 주는 시사점

오픈소스에 기여하고 싶은 분들께 드리는 진심 어린 조언이에요. PR을 보내기 전에 먼저 이슈로 '이런 걸 고치려는데 받아주실 의향 있나요?' 하고 물어보세요. AI로 코드를 짰다면 그걸 그대로 던지지 말고, 본인이 직접 돌려보고 이해한 다음 보내야 해요. 양보다 질이에요. 잘 정리된 PR 하나가 영혼 없는 열 개보다 훨씬 환영받거든요.

반대로 직접 프로젝트를 운영하는 분이라면, 깃허브의 이런 기능을 '문을 닫는 도구'가 아니라 '진짜 기여자를 보호하는 도구'로 활용하면 좋아요. 기여 가이드(CONTRIBUTING.md)를 명확히 적어두는 것만으로도 소음이 꽤 줄어들어요.