오픈소스 저장소에 몰려든 AI 봇 스팸, Git author 플래그로 막은 팀 이야기

AI 봇 스팸이 오픈소스 저장소를 실제로 망가뜨린 사례

• Archestra 팀은 GitHub 저장소에서 AI 봇 스팸이 “불편한 정도”를 넘어 운영 문제로 커지는 걸 겪음

  • 몇 달 전 GitHub가 AI 기여 증가를 제품 지표로 자랑했지만, 이 팀 입장에선 기여 품질 저하가 더 먼저 보였다고 함
  • 특히 오픈소스 프로젝트에서 숫자만 보면 활동이 늘어난 것처럼 보이지만, 유지보수자 입장에선 검토할 쓰레기가 늘어난 셈임

• 첫 번째 큰 경고는 900달러 바운티를 건 이슈에서 터짐

  • 원래는 “MCP Apps” 지원을 추가할 기여자를 찾으려던 이슈였음
  • 실제 기여자들이 구현 계획을 제안하고 질문하고 작업을 시작했는데, 곧 AI 계정들이 몰려듦
  • 이슈 댓글은 총 253개까지 불어났고, 의미 없는 구현 계획과 유지보수자를 향한 공격성 댓글까지 섞였다고 함

• 문제는 한 이슈에서 끝나지 않았음

  • AI 계정들이 저장소 전체에 댓글과 이슈, PR을 뿌리기 시작함
  • 저장소를 watching 중인 팀원들은 의미 없는 알림을 계속 받게 됨
  • 실제로 바운티 작업을 하던 기여자들의 대화가 소음에 묻히는 상황까지 갔음

테스트 안 한 PR 27개, 유지보수자 반나절 청소

• x.ai provider 지원 이슈 하나에도 PR이 27개나 들어옴

  • 대부분은 작성자가 직접 테스트조차 하지 않은 PR이었다고 함
  • 겉으로는 오픈소스 활동이 활발해 보이지만, 실제로는 유지보수자가 하나씩 확인하고 닫아야 하는 비용임

• 팀원 한 명이 매주 반나절을 AI 쓰레기 청소에 써야 하는 상태가 됨

  • 테스트 안 한 PR을 닫고, 환각으로 만든 이슈를 정리하는 작업이 반복됨
  • 이걸 놓치면 저장소가 실제 기여자에게 불친절한 공간으로 변함
  • 결국 좋은 기여자는 소음 속에서 떠나고, 저품질 자동화만 남는 역선택이 생김

• 처음엔 부드러운 대응도 시도함

  • London-Cat이라는 작은 봇을 만들어 merged PR 같은 신호로 기여자 평판을 계산함
  • 누가 누군지 파악하는 데는 도움이 됐지만 스팸 자체를 막진 못함
  • 다음으로 만든 “AI sheriff”는 일부 PR을 자동으로 닫았지만, 당연히 정상 PR도 잘못 닫는 문제가 생김

결국 선택한 건 GitHub 접근 제한이라는 핵옵션

• Archestra는 신규 사용자가 바로 이슈, PR, 댓글을 남기지 못하게 막기로 결정함

  • 팀 표현대로 핵옵션임
  • VC 투자를 받은 스타트업 입장에선 GitHub 활동량이 외부 지표로 보이기 때문에 더 민감한 선택임
  • 그래도 팀은 AI slop으로 부풀린 지표보다 품질이 중요하다고 판단함

• 문제는 GitHub에 “화이트리스트 사용자만 댓글/PR 허용” 같은 기능이 딱 맞게 없다는 점임

  • 대신 GitHub에는 “Limit to prior contributors” 설정이 있음
  • main 브랜치에 예전에 커밋한 계정만 이슈나 PR에 댓글을 달 수 있게 제한하는 기능임
  • 단점은 AI 봇과 진짜 신규 기여자를 똑같이 막아버린다는 것임

• 여기서 팀이 발견한 우회로가 Git의 --author 플래그임

  • Git 커밋에는 author와 committer가 따로 있음
  • GitHub는 main 브랜치 커밋의 author가 해당 GitHub 계정과 매칭되면 prior contributor로 봄
  • 즉, 실제 커밋을 푸시한 사람은 팀 계정이어도 author를 외부 기여자로 설정하면 GitHub가 그 사람을 기여자로 인정함

sequenceDiagram
    participant 기여자
    participant 온보딩페이지
    participant 깃허브액션
    participant 저장소
    participant 깃허브권한

    기여자->>온보딩페이지: 윤리적 AI 규칙 확인 + CAPTCHA 통과
    온보딩페이지->>깃허브액션: GitHub 사용자명 제출
    깃허브액션->>깃허브액션: 사용자 ID와 noreply 이메일 조회
    깃허브액션->>저장소: --author로 외부 기여자 커밋 생성
    저장소->>깃허브권한: main 브랜치 author 기록 반영
    깃허브권한->>기여자: prior contributor로 댓글/PR 허용

구현 방식은 꽤 기묘하지만 효과는 명확함

• GitHub 계정마다 noreply 이메일이 있다는 점을 이용함

  • 형식은 <id>+<username>@users.noreply.github.com임
  • GitHub API로 사용자 ID를 조회한 뒤, 그 이메일을 author로 넣어 커밋을 만듦
  • 그러면 GitHub가 해당 커밋을 외부 사용자의 기여로 연결함

• 실제 흐름은 온보딩과 GitHub Actions로 자동화됨

  • 사용자는 Archestra 웹사이트에서 윤리적 AI 사용 규칙과 CAPTCHA를 통과함
  • 제출되면 GitHub Action이 사용자 ID를 조회함
  • EXTERNAL_CONTRIBUTORS.md 파일에 핸들을 추가하고, 해당 사용자를 author로 하는 커밋을 main에 푸시함
  • 푸시가 끝나면 사용자는 저장소에서 댓글과 PR을 남길 수 있음

• 팀이 강조하는 건 책임 있는 AI 사용자를 막자는 게 아님
  • 합법적인 신규 기여자, 책임 있는 AI 사용자, 초보 개발자, 숙련된 엔지니어 모두가 편하게 기여하는 공간을 만들고 싶다는 입장임
  • 문제는 AI 봇이 만든 저품질 참여가 그 공간을 먼저 망가뜨린다는 점임
  • 그래서 진입 장벽을 올려서 최소한의 신호를 보겠다는 선택을 한 것임

오픈소스 지표가 부풀수록 유지보수자는 더 힘들어질 수 있음

• GitHub 입장에선 AI 생성 기여가 엄청난 활동 증가로 보일 수 있음

  • 하지만 프로젝트 팀은 그 활동 중 상당수를 청소해야 하는 비용으로 떠안음
  • 댓글 수, PR 수, 이슈 수가 늘어도 실제 소프트웨어 품질이 좋아지는 건 아님

• 보안 리스크도 같이 커짐

  • 기사에서는 LiteLLM 저장소에서 공격자들이 AI 봇으로 대화를 유도하려 했던 사례를 언급함
  • 저품질 PR만 문제가 아니라, 공격자가 여론이나 리뷰 흐름을 조작하는 벡터가 될 수도 있다는 얘기임
  • 오픈소스 유지보수가 이제 코드 검토뿐 아니라 참여자 신뢰 관리까지 포함하게 된 셈임

• 결론은 꽤 씁쓸함

  • AI는 오픈소스 기여 장벽을 낮출 수 있지만, 동시에 스팸 생성 비용도 거의 0에 가깝게 낮춤
  • 유지보수자는 “더 많은 기여”와 “더 많은 쓰레기”를 구분하기 위한 장치를 직접 만들어야 함
  • 이 팀의 Git author 우회는 땜질이지만, 지금 당장 저장소를 지키기 위한 실전적인 선택임

기술 맥락

• Archestra가 고른 핵심 선택은 GitHub의 prior contributor 제한을 켜고, 온보딩을 통과한 사람만 인위적으로 prior contributor로 만들어주는 방식이에요. 왜냐하면 GitHub에는 오픈소스 저장소에서 댓글과 PR 권한을 세밀하게 화이트리스트로 관리하는 기능이 딱 맞게 없거든요.

• --author 플래그가 여기서 중요한 이유는 Git 커밋의 author와 committer가 분리돼 있기 때문이에요. 팀 계정이 커밋을 푸시하더라도 author를 외부 사용자의 GitHub noreply 이메일로 지정하면, GitHub는 그 사용자를 main 브랜치 기여자로 연결해요.

• 이 방식의 트레이드오프는 분명해요. 장점은 AI 봇 스팸을 저장소 입구에서 크게 줄일 수 있다는 점이고, 단점은 진짜 신규 기여자도 온보딩을 거쳐야 해서 마찰이 생긴다는 점이에요. 그래도 이 팀은 실제 기여자 대화가 묻히는 비용이 더 크다고 본 거예요.

• GitHub Actions를 붙인 이유는 운영자가 매번 수동으로 사용자를 등록하면 유지보수 비용이 또 생기기 때문이에요. 온보딩 제출, 사용자 ID 조회, EXTERNAL_CONTRIBUTORS.md 수정, author 커밋 푸시까지 자동화해야 이 제한 정책이 실제 운영 가능한 수준이 돼요.

• 보안 관점에서도 이건 단순 스팸 필터가 아니에요. AI 봇이 PR과 댓글 흐름을 장악하면 리뷰어가 피로해지고, 악성 변경이나 잘못된 방향의 논의가 끼어들 여지가 커져요. 그래서 저장소 접근 제어가 코드 품질 관리의 일부가 되는 상황이에요.