Git author 플래그까지 꺼낸 오픈소스 AI 스팸

Archestra가 공개한 글 Let's talk about AI slop은 오픈소스 프로젝트가 AI 생성 기여를 어떻게 다루는지 보여주는 흥미로운 사례다. Archestra는 MCP 앱 지원 이슈에 900달러 바운티를 걸었고, 합법적인 기여자들이 논의하던 공간에 AI 봇 계정들이 몰려들었다고 설명한다. 한 이슈는 253개 댓글까지 불어났고, x.ai provider 지원 이슈에는 27개 PR이 들어왔지만 상당수는 테스트조차 하지 않았다고 한다.

문제는 단순히 댓글이 많다는 것이 아니다. 유지보수자에게는 알림, 검토, 닫기, 설명이라는 비용이 생긴다. 진짜 기여자는 소음 속에 묻히고, 저장소는 초보자와 숙련자 모두에게 불친절한 공간이 된다. AI 사용률 KPI가 만들 수 있는 가짜 생산성처럼, 숫자는 늘었지만 실질 품질은 떨어지는 현상이 오픈소스에서도 나타난다.

prior contributor를 우회적으로 화이트리스트로 쓰다

Archestra가 선택한 방법은 꽤 독특하다. GitHub에는 공개 저장소에서 “이 사람만 댓글과 PR을 남길 수 있다”는 단순한 화이트리스트가 부족하다. 대신 GitHub의 상호작용 제한 기능은 prior contributor, 즉 과거에 main 브랜치에 커밋 저자로 기록된 사람을 기준으로 제한할 수 있다.

Archestra는 여기에 git commit의 --author 옵션을 조합했다. 사용자가 온보딩 페이지에서 윤리적 AI 사용 규칙과 CAPTCHA를 통과하면, GitHub Action이 GitHub REST API로 사용자 ID를 조회하고 EXTERNAL_CONTRIBUTORS.md에 핸들을 추가한 뒤, 해당 사용자를 author로 한 커밋을 main에 넣는다. 그러면 GitHub는 그 사람을 prior contributor로 보고 댓글과 PR 권한을 연다.

오픈소스는 이제 커뮤니티 운영 문제다

이 사례는 AI 코딩의 어두운 면을 잘 보여준다. AI가 코드를 더 빨리 만들면 좋은 PR도 늘 수 있다. 하지만 “그럴듯한 계획”, “테스트 없는 수정”, “환각 이슈”도 함께 늘어난다. Archestra는 이를 AI slop이라고 부르며, VC-backed 스타트업이라 GitHub 활동 지표가 중요함에도 품질을 위해 핵 옵션을 선택했다고 말한다.

한국 스타트업과 오픈소스 팀도 같은 문제를 겪을 가능성이 크다. MCP, 에이전트, 플러그인처럼 뜨거운 키워드를 가진 저장소일수록 바운티와 채용 과제가 스팸 유입 장치가 될 수 있다. Tailwind를 떠나는 글이 AI 코딩에 중요한 이유는 코드 구조의 유지보수성을 다뤘고, Semble의 에이전트 코드 검색은 탐색 비용을 줄이는 도구를 다뤘다. 그러나 커뮤니티 대화 품질은 도구만으로 해결되지 않는다.

보안 리스크도 있다

Archestra는 LiteLLM 저장소에서 공격자가 AI 봇으로 대화를 조작하려 한 사례를 언급한다. 오픈소스 PR은 단순 기여가 아니라 공급망의 입구다. 유지보수자가 피로해질수록 악성 수정, 의존성 변경, 권한 상승 코드가 섞일 가능성이 커진다. GitHub Actions 문서는 자동화를 쉽게 만들지만, 자동화된 승인 흐름은 그만큼 더 엄격한 검증을 요구한다.

따라서 좋은 대응은 “AI 금지”가 아니라 책임 있는 사용 규칙, 테스트 요구, 작은 PR, 재현 가능한 설명, 기여자 온보딩을 묶는 것이다. AI로 작성한 PR이라도 테스트와 설명이 좋으면 받아들일 수 있다. 반대로 사람이 썼더라도 근거 없는 대량 변경은 거절해야 한다.

결론

Archestra의 Git author 플래그 해법은 우아하지 않지만 현실적이다. 오픈소스의 기본값이 완전 개방에서 신뢰 기반 개방으로 조금씩 이동하고 있음을 보여준다. AI 코딩 시대의 유지보수자는 코드 리뷰어이면서 커뮤니티 방화벽 관리자다. 한국 팀이 공개 저장소를 운영한다면 지금부터 기여 규칙, 테스트 기준, 자동화 권한, 봇 대응 정책을 문서화해야 한다.

FAQ

AI slop은 무엇인가?

AI가 만든 그럴듯하지만 검증되지 않은 댓글, 이슈, PR처럼 유지보수 비용만 늘리는 저품질 산출물을 뜻한다.

Archestra는 어떤 방법을 썼나?

GitHub prior contributor 제한과 git --author 커밋을 조합해 온보딩을 통과한 사람만 참여할 수 있게 했다.

이 방식은 공식 화이트리스트인가?

아니다. GitHub의 기존 기능을 우회적으로 조합한 운영 해법에 가깝다.

AI PR은 모두 막아야 하나?

아니다. 테스트, 설명, 범위가 명확한 PR은 도구 사용 여부와 별개로 평가할 수 있다.

한국 오픈소스 팀의 첫 조치는?

기여 가이드, 테스트 필수 조건, 바운티 운영 규칙, 자동화 권한 범위를 명확히 하는 것이다.