
오늘날의 PR 스팸은 2000년대 초반의 이메일 스팸과 닮아 있습니다
요약
AI 코딩 에이전트의 급증으로 인해 오픈 소스 프로젝트에 저품질의 PR(Pull Request) 스팸이 몰리는 현상을 분석합니다. 이메일 스팸 사례처럼 발신자 평판 시스템과 신뢰 기반 필터링의 필요성을 강조합니다.
핵심 포인트
- AI 에이전트 생성 PR 급증으로 인한 오픈 소스 프로젝트의 관리 부담 증가
- 저품질 AI 생성 코드(slop)로 인해 PR 머지율이 급격히 하락하는 현상 발생
- 이메일 스팸과 유사한 '발신자 평판(sender reputation)' 시스템 도입 필요성
- Vouch와 같은 신뢰 관리 시스템을 통한 기여자 인증 및 필터링의 중요성
- AI 도구의 획일화가 오픈 소스 생태계의 다양성을 해칠 수 있다는 우려
저는 Rahul이며, Pull Request (PR)를 리뷰하는 AI 에이전트를 구축하는 Greptile에서 일하고 있습니다. Greptile은 거의 하룻밤 사이에 GitHub 역사상 가장 빠르게 성장한 리포지토리(repo)가 된 OpenClaw의 PR을 리뷰합니다. 덕분에 저희는 기이한 현상을 가장 가까이서 지켜볼 수 있었습니다.
지난 12월, OpenClaw는 일주일에 2개의 PR을 받고 있었습니다. 하지만 2월이 되자 그 숫자는 주당 3,400개로 급증했습니다. 급증하기 전에는 PR의 약 48%가 머지(merge)되었으나, 급증 이후에는 머지되는 비율이 9.3% 미만으로 떨어졌습니다.
이러한 PR 중 상당수는 사람들의 AI 코딩 에이전트에 의해 생성된 저품질의 슬롭(slop)이었습니다. 예를 들어, 한 기여자는 단 하루 만에 106개의 PR을 제출했으며, 제출 사이의 중앙값(median) 시간은 단 3초였습니다.
여러 면에서 openclaw/openclaw는 오픈 소스 기여의 미래가 어떤 모습일지에 대한 예고편을 제공합니다. 여기 세 가지 관찰 결과가 있습니다:
PR에는 발신자 평판(sender reputation)이 필요할 것입니다
오늘날의 PR 스팸은 2000년대 초반의 이메일 스팸과 닮아 있습니다.
제가 처음 OpenClaw 데이터를 보았을 때, 그 패턴은 이메일을 연상시켰습니다. 2000년, ILOVEYOU 웜은 24시간 만에 4,500만 대의 컴퓨터를 감염시켰는데, 이는 이메일 발송 비용이 거의 제로에 가까워졌고 사람들이 해당 플랫폼을 신뢰했기 때문입니다. 그 결과 사람들은 훨씬 더 많은 양의 이메일을 받게 되었고, 그중 일부는 악의적이었습니다. 오늘날의 PR에도 동일한 매개변수가 적용됩니다.
첫 번째 해결책은 유사합니다. 볼륨을 관리하기 위한 차단 목록(blocklists), 그리고 악성 행위자를 잡아내기 위한 신뢰 기반 필터 및 평판 인프라입니다. 오늘날 당신의 이메일이 수신자의 편지함에 도달할지 여부는 당신이 누구인지, 그리고 당신의 발송 이력이 어떠한지라는 두 가지 요소에 달려 있습니다.
OpenClaw의 기여자들은 이미 그들의 평판에 따라 필터링되고 있습니다: 첫 참여자의 머지율은 8.2%, 2~5개의 PR을 제출한 기여자는 10.3%, 5개 이상은 18.6%입니다.
Mitchell Hashimoto는 가장 인기 있는 오픈 소스 터미널 에뮬레이터 중 하나인 Ghostty를 만들고 유지 관리하고 있습니다. 프로젝트가 탄력을 받으면서, 사람들은 너무 많은 양의 AI 생성 PR 슬롭을 제출했고, 결국 그는 AI가 생성한 기여를 제한해야만 했습니다.
일주일 후, 그는 해결책을 발표했습니다: 오픈 소스 기여자들을 위한 신뢰 관리 시스템인 Vouch입니다. 인증(Vouch)되지 않은 사용자는 기여할 수 없으며, 악의적인 행위자는 명시적으로 플래그(flag)가 지정됩니다. 현재 Vouch는 프로젝트별로 적용되지만, Mitchell의 비전은 신뢰 결정이 궁극적으로 유사한 가치를 공유하는 프로젝트들 사이로 파급되는 것입니다. Vouch는 오픈 소스 버전의 발신자 평판 점수(sender reputation score)와 같습니다. (참고: Vouch가 Ghostty에 잘 작동하고 있었음에도 불구하고, Mitchell은 Ghostty를 GitHub에서 내리기로 결정했습니다.)
모두가 똑같이 생각한다면 기여자가 늘어나는 것은 도움이 되지 않습니다
Linus Torvalds는 다음과 같은 유명한 말을 남겼습니다: "충분한 눈(eyeballs)이 있다면, 모든 버그는 얕다(shallow)."
동일한 문제에 더 많은 눈이 집중되면 다양한 관점이 생겨납니다. 서로 다른 사람들이 소프트웨어를 다르게 사용하고, 서로 다른 버그를 마주하며, 새로운 방식으로 해결책에 접근하기 때문입니다.
하지만 모두가 Claude / Codex / Cursor / Devin 등을 사용하게 된다면 이 규칙은 유효하지 않을 수 있습니다. OpenClaw의 사례를 보면 다음과 같습니다:
- 4명의 기여자가 "feat(web-search): add SearXNG as a search provider."라는 정확히 동일한 제목의 PR을 제출했습니다. 이들은 독립적으로 동일한 기능을 추가하려고 시도한 10명 이상의 사람들 중 4명이었습니다.
- 6명이 독립적으로 동일한 Brave Search 로케일(locale) 버그를 수정했습니다. 그중 2명은 94분 간격으로 동일한 제목의 PR을 제출했습니다.
- 5명이 에이전트 러너(agent runner)에서 동일한 타임아웃 데드락(timeout deadlock)을 독립적으로 발견했습니다.
OpenClaw에는 그 어느 때보다 많은 눈이 집중되어 있지만, 그들의 관점 또한 AI 코딩 에이전트(AI coding agents)에 의해 필터링되고 있습니다. 만약 대부분의 기여자가 동일한 프롬프트(prompt)로 동일한 AI 코딩 에이전트를 사용한다면, 그들의 기여 또한 서로 닮아갈 것입니다.
오픈 소스의 약속이자 장점은 사고의 다양성이었습니다. Linus의 법칙은 근본적인 사고 방식 또한 다양하게 유지될 때만 유효합니다. 코드베이스를 정말로 연구하는 기여자는 그렇지 않은 기여자보다 다르게 프롬프트를 작성할 것입니다.
실제로 머지(merge)되고 있는 것들
OpenClaw PR 데이터에 따르면, 기능(feature)의 머지율은 9%인 반면, 리팩터링(refactor)의 머지율은 35%입니다.
기존 코드베이스에 대한 깊은 이해를 요구하는 기여(contribution)는 새로운 기능(feature) 기여보다 거의 4배 더 높은 성과를 냅니다. 이는 요즘 흔히 쓰이는 격언이기도 합니다. 즉, 타이핑(typing)보다 사고(thinking)가 훨씬 더 중요하다는 것입니다. 데이터가 이를 뒷받침합니다.
예를 들어, claude-mem이 Claude Code의 훅(hook)으로 캡처된 도구 스트림(tool stream)을 자체적인 재개 가능한 에이전트 SDK 옵저버 세션(Agent SDK observer session)으로 매핑하는 방식은 두 시스템 모두에 대한 깊은 이해를 요구하는, 명확하지 않은(non-obvious) 아키텍처적 선택입니다. 이 결정을 이해하는 소프트웨어 개발자라면 이를 체크리스트로 추출할 수 있을 것이며, 이는 에이전트의 출력을 현저히 개선하는 프롬프트(prompt)가 될 것입니다. 단순히 "메모리 시스템을 구축하라"는 프롬프트를 받은 에이전트는 스스로 이를 달성할 수 없을 것입니다.
200년 전까지만 해도 건물을 설계하는 사람들이 직접 건설하기도 했습니다. 이들은 마스터 빌더(master builder)로 알려져 있었습니다. 건설 기술이 발전함에 따라 그 역할은 건축(architecture)과 시공(construction)이라는 두 가지 기술로 분리되었습니다. 소프트웨어에 대한 비유가 완벽하게 들어맞지는 않습니다. 건축가는 여전히 건물이 어떻게 서 있는지를 알아야 합니다. 하지만 이 비유는 실질적인 무언가를 시사합니다. 리뷰(review)를 통과하여 살아남는 기여들은 점점 더 에이전트가 혼자서는 할 수 없는 것들, 즉 새로운 구축(novel construction)이 아니라 기존 시스템에 대한 깊은 이해를 요구하는 호출(call)들이 되어가고 있다는 점입니다.
그래서, 다음은 무엇인가요?
OpenClaw는 불과 몇 달 만에 아무것도 없는 상태에서 실제 세계의 Jarvis와 같은 존재가 되었습니다. 한 명의 개인과 강력한 커뮤니티가 결합하여 1년 전에는 불가능했던 속도로 구축할 수 있었습니다. 이는 매우 특별한 일입니다.
오픈 소스(open source) 커뮤니티는 그 어느 때보다 빠르게 구축할 수 있습니다. 이러한 속도로 인해 발생하는 문제들은 신원(identity), 평판(reputation), 그리고 기여를 검증하는 방식에 있어 더 나은 프리미티브(primitives)를 필요로 할 것이며, 이 모든 것들이 구축될 것입니다. 오픈 소스는 이전에도 더 어려운 문제들을 해결해 온 바 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 HN AI Posts의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기