오픈소스에 'AI가 만든 쓰레기 PR'이 쏟아진다 — 2000년대 초 이메일 스팸의 데자뷔

메인테이너들의 새로운 골칫거리

오픈소스 프로젝트를 운영해본 분이라면 공감하실 거예요. 요즘 깃허브 저장소에 AI로 대충 만들어낸 저품질 PR(풀 리퀘스트, 코드 수정 제안)과 버그 리포트가 부쩍 늘었거든요. 코드 리뷰 AI를 만드는 회사 그렙타일(Greptile)이 이 현상을 두고 흥미로운 비유를 했어요. 지금의 'PR 스팸'이 마치 2000년대 초반 우리 메일함을 가득 채웠던 '이메일 스팸'과 똑 닮았다는 거예요. 그 시절을 떠올려보면, 어느 날 갑자기 광고 메일이 진짜 메일보다 많아졌잖아요. 지금 오픈소스에서 비슷한 일이 벌어지고 있는 거죠.

왜 이런 일이 벌어질까요

핵심은 '만드는 비용과 검토하는 비용의 불균형'이에요. 이게 뭐냐면, 예전엔 PR 하나를 보내려면 코드를 직접 이해하고 짜야 해서 시간이 꽤 들었어요. 그런데 지금은 LLM(거대 언어 모델)에게 '이 프로젝트에 기여할 만한 수정 좀 만들어줘'라고 시키면 1분 만에 그럴듯해 보이는 PR이 뚝딱 나와요. 생성은 1분, 검토는 30분. 보내는 쪽은 거의 공짜인데 받는 쪽은 매번 진땀을 빼야 하는 비대칭이 생긴 거죠. 스팸 메일이 보내는 데 거의 돈이 안 들어서 폭증했던 것과 똑같은 구조예요.

동기도 분명해요. 어떤 사람들은 깃허브 기여 이력을 화려하게 꾸며 이력서에 쓰려고 하고, 어떤 이들은 버그를 찾으면 돈을 주는 '버그 바운티(포상금)'를 노리고 AI에게 가짜 보안 취약점을 양산시켜요. 실제로 유명한 curl 프로젝트의 메인테이너 다니엘 스텐베리는 'AI가 만든 그럴듯하지만 전부 틀린 보안 리포트' 때문에 진짜 검토 시간을 빼앗긴다고 공개적으로 토로하기도 했죠. 문제는 이게 그럴듯해 보인다는 거예요. 딱 봐서 스팸인 게 아니라, 일단 열어서 코드를 따라가 봐야 '아, 이거 말이 안 되네' 하고 알게 되니까 더 지치는 거예요.

이메일 스팸의 역사가 힌트를 줘요

그렇다면 답도 그 역사에서 찾을 수 있어요. 이메일 스팸도 처음엔 무방비였지만, 결국 자동 스팸 필터가 등장하면서 정리됐잖아요. 마찬가지로 오픈소스에도 'AI 슬롭(slop, 영양가 없는 AI 결과물)'을 1차로 걸러주는 자동 필터가 필요해진 거예요. 그렙타일 같은 AI 코드 리뷰 도구가 사람 메인테이너 앞단에서 '이 PR은 테스트도 안 통과하고 맥락도 안 맞으니 자동 반려' 하는 식으로요. 결국 AI가 만든 스팸을 AI로 막는 구도가 되는 거죠. 여기에 기여하려면 먼저 이슈에서 합의를 거치게 하거나, 신뢰도 낮은 계정의 PR은 자동 검토를 강화하는 정책적 장치도 함께 가야 해요.

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

오픈소스 메인테이너분들께는 '리뷰 자동화 장치를 미리 깔아두자'는 실용적인 조언이 돼요. 그런데 회사 안에서도 남 일이 아니에요. 사내에서 AI로 코드를 짜는 게 일상이 되면서, 검토 없이 던지는 대량의 PR이 팀 동료를 지치게 하는 일이 충분히 생길 수 있거든요. 'AI로 짠 코드라도 보내기 전에 내가 먼저 끝까지 이해하고 책임진다'는 최소한의 에티켓이 점점 더 중요해질 거예요.

마무리

핵심은 '생성이 공짜가 되면 검토가 새로운 비용이 된다'는 거예요. AI가 무언가를 쉽게 만들어줄수록, 그걸 받는 사람의 시간을 존중하는 문화가 더 절실해지는 거죠. 여러분 주변에서도 'AI가 만들었지만 검토 안 된 결과물'에 시간을 빼앗긴 경험이 있으신가요? 이걸 막을 가장 현실적인 방법은 뭐라고 생각하세요?