AI 코드 에이전트 시대의 오픈소스 스팸 문제
최근 AI 코딩 에이전트의 발달로 오픈소스 프로젝트에 대량의 저품질 스팸 PR(Pull Request)이 쏟아지고 있습니다. 이는 2000년대 초 이메일 스팸과 유사한 양상을 띠며, 시스템 과부하를 막기 위해 기여자 신뢰도 평가와 같은 근본적인 필터링 시스템이 필요해졌습니다. 또한 다수가 동일한 AI를 사용하면서 코드의 다양성이 사라지고, 기존 코드베이스에 대한 깊은 이해를 바탕으로 한 리팩토링보다 단순 기능 추가 코드의 반려율이 크게 높아지는 현상이 발생하고 있습니다.
안녕하세요, 저는 Greptile에서 풀 리퀘스트(PR)를 검토하는 AI 에이전트를 개발하는 Rahul입니다. Greptile은 거의 하루아침에 GitHub 역사상 가장 빠르게 성장하는 저장소(repo)가 된 OpenClaw의 PR을 검토합니다. 덕분에 우리는 매우 기이한 현상을 가까이서 목격할 수 있었습니다. 작년 12월만 해도 OpenClaw에는 일주일에 두 개의 PR이 들어왔습니다. 하지만 2월이 되자 그 수가 주당 3,400개로 급증했습니다. 급증 이전에는 약 48%의 PR이 병합(merge)되었지만, 이후에는 9.3% 미만의 PR만이 병합되었습니다. 이 PR들 중 상당수는 흔히 사람들의 AI 코딩 에이전트가 생성한 저노력 쓰레기 코드(slop)였습니다. 예를 들어, 한 기여자는 하루에 106개의 PR을 제출했는데, 제출 간격의 중앙값은 단 3초습니다. 여러 모로 openclaw/openclaw는 오픈소스 기여의 미래가 어떤 모습일지 보여주는 미리보기라 할 수 있습니다. 여기 세 가지 관찰 결과가 있습니다.
PR은 발신자의 신뢰도를 요구하게 될 것입니다. 오늘날의 PR 스팸은 2000년대 초반의 이메일 스팸과 같습니다. OpenClaw 데이터를 처음 보았을 때, 그 패턴이 이메일을 떠올리게 했습니다. 2000년, ILOVEYOU 웜은 이메일 발송 비용이 0에 가까워졌고 사람들이 플랫폼을 신뢰했기 때문에 24시간 만에 4,500만 대의 컴퓨터를 감염시켰습니다. 결과적으로 사람들은 훨씬 더 많은 양의 이메일을 받았고, 그중 일부는 악성이었습니다. 오늘날 PR에도 똑같은 매개변수가 적용됩니다. 첫 번째 해결책은 과거와 비슷합니다. 물량을 관리하기 위한 차단 목록(blocklist), 그리고 악성 사용자를 잡기 위한 신뢰도 기반 필터 및 평판 인프라입니다. 오늘날 귀하의 이메일이 수신자의 받은편지함에 도달하는지 여부는 두 가지로 결정됩니다. 바로 귀하가 누구인지, 그리고 귀하의 발송 이력입니다. OpenClaw의 기여자들 역시 이미 그들의 평판에 따라 필터링되고 있습니다. 첫 기여자의 병합률은 8.2%, 2~5개의 PR을 가진 기여자는 10.3%, 5개 이상인 경우 18.6%입니다. 미첼 하시모토(Mitchell Hashimoto)는 가장 인기 있는 오픈소스 터미널 에뮬레이터 중 하나인 Ghostty를 만들고 유지 관리하고 있습니다. 이 프로젝트가 탄력을 받으면서 사람들이 AI가 생성한 쓰레기 PR을 너무 많이 제출했기 때문에, 그는 AI 생성 기여물을 제한해야 했습니다. 일주일 뒤, 그는 해결책을 발표했습니다. 바로 오픈소스 기여자를 위한 신뢰 관리 시스템인 Vouch입니다. 인증되지 않은 사용자는 기여할 수 없으며, 악의적인 사용자는 명시적으로 표시됩니다. Vouch는 현재 프로젝트별로만 적용되지만, 미첼의 비전은 궁극적으로 유사한 가치를 공유하는 프로젝트 전반으로 신뢰 결정이 파급되는 것입니다. Vouch는 발신자 평판 점수의 오픈소스 버전이라 할 수 있습니다. (참고로: Vouch가 Ghostty에서는 잘 작동했음에도 불구하고, 미첼은 Ghostty를 GitHub에서 없애기로 결정했습니다.)
모두가 같은 방식으로 생각한다면 기여자가 더 많아도 도움이 되지 않습니다. 리누스 토르발스(Linus Torvalds)의 유명한 말이 있습니다. "충분한 수의 눈이 있다면, 모든 버그는 얕다(Given enough eyeballs, all bugs are shallow)." 더 많은 사람이 같은 문제를 본다는 것은 다양한 관점을 가져다줍니다. 사람마다 소프트웨어를 사용하는 방식이 다르고, 마주치는 버그도 다르며, 해결책을 접근하는 방식도 독창적입니다. 하지만 모두가 Claude, Codex, Cursor, Devin 등에 집중하게 될 때는 이 법칙이 통하지 않을 수 있습니다. OpenClaw에서는 다음과 같은 일들이 일어났습니다. 4명의 기여자가 정확히 "feat(web-search): add SearXNG as a search provider"라는 동일한 제목으로 PR을 제출했습니다. 이들은 독립적으로 동일한 기능을 추가하려 했던 10명 이상의 사람 중 4명이었습니다. 6명이 독립적으로 동일한 Brave Search 로케일 버그를 수정했습니다. 2명이 94분 차이로 동일한 제목의 PR을 제출했습니다. 5명이 독립적으로 에이전트 러너(agent runner)에서 동일한 시간 초과 교착 상태(deadlock)를 발견했습니다. OpenClaw를 살피는 눈은 그 어느 때보다 많아졌지만, 그들의 관점 역시 AI 코딩 에이전트에 의해 필터링되고 있습니다. 대부분의 기여자가 동일한 프롬프트를 사용하여 동일한 AI 코딩 에이전트를 사용한다면, 그들의 기여물 역시 서로 비슷해질 것입니다. 오픈소스의 약속과 이점은 사고의 다양성에 있었습니다. 리누스의 법칙은 근본적인 사고 방식도 다양하게 유지될 때만 성립합니다. 코드베이스를 진정으로 깊이 공부하는 기여자는 그렇지 않은 기여자와 다르게 프롬프트를 입력할 것입니다.
실제로 병합되는 것은 무엇인가요? OpenClaw PR 데이터에서 새로운 기능(features)은 9%의 병합률을 보인 반면, 리팩토링(refactors)은 35%가 병합되었습니다. 기존 코드베이스에 대한 깊은 이해가 필요한 기여물은 새로운 기능 기여보다 거의 4배 높은 성과를 내고 있습니다. 이는 흔한 현상입니다.