▲

Git의 --author 플래그로 GitHub 저장소의 AI 봇 스팸을 막은 방법

 (archestra.ai)
2P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • Archestra 저장소는 AI 기반 기여가 늘어나면서 무의미한 댓글·PR이 몰리며 실제 논의가 묻히고 유지관리 부담이 커짐
  • $900 바운티 이슈는 실제 기여자 논의 공간이었지만 AI 봇 댓글로 253개 댓글까지 불어났고, 공격적 태도도 나타남
  • x.ai provider 지원 이슈에는 닫히고 병합되지 않은 27개 PR이 들어왔으며, 대부분 기여자가 테스트하지 않았음
  • GitHub의 prior contributor 제한은 신규 실제 개발자와 AI 봇을 구분하지 못해, Git --author로 승인 사용자를 main 커밋 author에 추가함
  • 온보딩은 윤리적 AI 규칙과 CAPTCHA 뒤 GitHub Action으로 화이트리스트 커밋을 만들며, 부풀려진 활동 지표보다 품질을 우선함

AI 봇 스팸이 오픈소스 저장소를 잠식한 방식

  • Archestra 저장소는 GitHub의 AI 기반 기여 지표 성장과 달리, 실제 현장에서는 기여 품질 저하와 유지관리 부담이 커짐
  • $900 바운티를 건 이슈는 실제 기여자들이 계획을 제안하고 질문하며 작업을 시도하던 공간이었지만, AI 봇이 몰려들며 총 253개 댓글로 불어남
  • AI 계정들은 무의미한 구현 계획을 남기고 유지관리자에게 공격적인 태도까지 보이며 논의를 오염시킴
  • 저장소를 지켜보던 팀원들은 AI 댓글마다 알림을 받았고, @ethanwater, @developerfred, @Geetk172 같은 실제 기여자들의 대화가 묻힘
  • x.ai provider 지원 이슈에는 닫히고 병합되지 않은 27개 pull request가 들어왔고, 대부분은 기여자가 테스트조차 하지 않았음
  • 팀원 한 명이 매주 반나절을 들여 테스트되지 않은 PR과 환각성 이슈를 정리해야 했고, 정리를 놓치면 저장소가 실제 기여자에게 불친절한 공간으로 빠르게 바뀜

GitHub 제한을 우회한 화이트리스트 방식

  • 초기 대응의 한계

    • Archestra는 먼저 기여자의 평판을 계산하기 위해 London-Cat이라는 작은 봇을 만듦
    • London-Cat은 병합된 PR과 몇 가지 신호를 바탕으로 기여자 평판을 계산했으며, 예시처럼 기여자 식별에는 도움이 됨
    • 이 방식은 스팸 차단 자체에는 실패함
    • 다음 단계로 만든 AI sheriff는 예시처럼 실제 PR도 일부 닫아버림

  • 온보딩 없는 활동 차단

    • 무의미한 AI 댓글과 제안이 계속되며 실제 기여자들이 떠났고, 바운티로 기여를 유도하는 방식과 채용 후보자에게 테스트 과제를 주는 방식까지 재검토하게 됨
    • Archestra는 실제 기여자, 책임 있는 AI 사용자, 초보자, 숙련 엔지니어 모두에게 편안하고 안전한 저장소를 만들기 위해 대응을 강화함
    • 온보딩을 거치지 않은 사용자는 이제 이슈 생성, PR 열기, 댓글 작성을 할 수 없도록 막힘
    • VC 투자를 받은 스타트업에게 GitHub 활동 지표는 민감하지만, Archestra는 AI slop으로 부풀린 지표보다 품질을 더 중요하게 봄

  • GitHub 설정의 한계

    • GitHub에는 오픈소스 저장소에서 댓글 작성자나 PR 생성자를 직접 화이트리스트로 관리하는 간단한 방법이 없음
    • “Limit to prior contributors” 설정은 main에 이전에 커밋한 적이 없는 사용자의 이슈·PR 댓글 작성을 막음
    • 이 설정은 AI 봇과 바운티 작업을 위해 새로 온 실제 개발자를 구분하지 못하며, 둘 다 기존 기여자가 아닌 사용자로 처리함

  • --author 플래그를 이용한 화이트리스트

    • GitHub는 main 브랜치 커밋의 author로 연결된 GitHub 계정을 prior contributor로 판단함
    • Git 커밋에는 author와 committer라는 두 신원 필드가 있고, 두 값은 서로 다를 수 있음
    • Git의 --author 플래그를 사용하면 다른 사람에게 귀속된 커밋을 만들 수 있으며, 이메일이 해당 GitHub 계정과 일치하면 GitHub가 커밋을 그 프로필에 연결하고 기여자 상태를 부여함
    • 모든 GitHub 계정에는 <id>+<username>@users.noreply.github.com 형식의 noreply 이메일이 있음
    • 사용자 ID를 API로 조회한 뒤 해당 이메일 형식으로 커밋 author를 지정함
    gh api users/their-username --jq '.id'  
git commit \  
--author="their-username <ID+their-username@users.noreply.github.com>" \  
-m "chore: add their-username to external contributors"
    • 이 커밋을 main에 푸시하면 외부 사용자는 author, Archestra 계정은 committer로 표시되고, GitHub는 해당 사용자를 prior contributor로 간주해 즉시 댓글 권한을 부여함

  • 실제 온보딩 흐름

    • https://archestra.ai/contributor-onboard - 웹사이트에서 윤리적 AI 규칙과 CAPTCHA를 포함한 온보딩을 진행함
    • GitHub Action - 제출 시 사용자의 GitHub ID를 조회하고, EXTERNAL_CONTRIBUTORS.md 파일에 핸들을 추가한 뒤 해당 사용자 계정이 author인 커밋을 main에 푸시함
    • 사용자 - 화이트리스트에 올라 저장소 접근 권한을 얻음
    • GitHub가 AI 생성 활동을 포함한 대규모 지표 성장을 보고하는 동안, 오픈소스 프로젝트 팀은 저장소의 AI slop을 직접 치우고 실제 참여자 수준을 유지하기 위한 우회책까지 만들어야 함
    • AI slop은 좋은 기여를 하려는 사람을 소음 속으로 밀어 넣어 동기를 떨어뜨릴 뿐 아니라, LiteLLM repo에서처럼 공격자가 AI 봇으로 대화를 유도하려 한 보안 위험도 가져옴

함께 보면 좋은 글 β

▲
GN⁺ 11시간전  [-]
Hacker News 의견들

  • 저장소 기여자는 fork PR 실행의 승인 요구를 우회하는 등 더 높은 권한을 갖게 되므로, 이 방식에는 간과된 보안 영향이 있음
    GitHub 문서도 “첫 기여자에게만 승인을 요구”하는 설정에서는, 저장소에 커밋이나 PR이 한 번이라도 병합된 사용자는 승인이 필요 없어지며, 악의적 사용자가 단순 오타 수정 같은 무해한 변경을 받아들여 이 조건을 충족할 수 있다고 경고함

    • 맞는 말임. 조직 구성원이 아닌 사람은 신뢰할 수 없으니 모든 외부 기여자 승인 요구가 기본값이어야 한다고 봄
    • 그건 보안 영향이 아님
      누군가의 완전히 무해한 PR 하나가 저장소에 병합됐다는 이유로 불안정해진다면, 이미 그 저장소는 불안정한 상태라고 봐야 함

  • GitHub가 이런 일이 가능하게 둔 게 문제임. 댓글 작성과 PR 생성에 아주 기본적인 요구사항만 넣었어도 여기까지 오지 않았을 것임
    그리고 이슈를 삭제할 수 있는 것처럼 PR도 삭제할 수 있게 해줬으면 함

    • 현재 관리자가 PR을 보관 처리할 수 있는 기능을 작업 중임
      목표는 유지보수자가 저장소 기여를 관리하는 방식을 더 잘 통제하게 하는 것임. 보관된 PR은 관리자에게만 보이고, 감사나 조직·컴플라이언스 요구를 위해 기여자 기록은 유지보수자가 계속 접근할 수 있게 하려 함. 이런 기능이 도움이 될지 궁금함
    • 이 판단이 맞음. 스팸 이메일을 받지 않는 방법을 개인이 “알아서 해결”할 일이 아니듯, 이건 오픈소스 커뮤니티나 개별 프로젝트가 알아서 해결할 문제가 아님
    • PR을 닫는 대신 삭제할 때 얻는 이점이 무엇인지 모르겠음. 닫아두면 어떤 PR이 받아들여지지 않는지 신호를 줄 수 있는데, 삭제하면 그 장점이 사라짐

  • PR 스팸은 현상금을 운영하는 저장소에 큰 문제임. PR의 95% 이상이 거절되는 계정은 GitHub가 일시적으로 PR 생성을 막아야 할지도 모름

    • GitHub에 예를 들어 PR 1개짜리 토큰을 발급하는 시스템이 있으면 좋겠음
      누군가 의미 있는 논의에 참여하고 이슈나 기능을 해결할 좋은 아이디어를 보이면 처음에는 PR 토큰 하나를 주고, PR 품질이 좋으면 몇 개 더 주다가, 결국 자유롭게 PR을 만들 수 있는 기여자로 승격하는 식임. 이슈에도 비슷한 시스템이 있으면 좋겠지만, 이슈가 PR 기여의 출발점일 때는 어떤 모습이어야 할지 잘 모르겠음. 다만 GitHub/MS는 Copilot 구독과 토큰을 팔고 싶어 하고, LLM 생성 PR도 그 사업 모델의 일부라서 실제로 생길 가능성은 낮아 보임
    • GitHub가 AI 차단을 할 유인은 없음. 광고 회사에 자기 브라우저에 광고 차단기를 넣으라고 요구하는 것과 비슷함
    • 문제는 봇이 GitHub 계정을 얼마든지 새로 만들어 계속 스팸을 보낼 수 있다는 점임. 그래도 시작점으로는 괜찮은 단순 방어가 될 수 있음
    • GitHub와 Microsoft가 이 문제에 적극적으로 기여하고 있는데, 왜 자기 잘못을 인정하겠음?

  • 이런 문제를 줄이는 데 Elo 기반 점수 시스템이 통할지 궁금함
    특정 프로젝트에 성공적으로 PR을 병합한 사람, 실제 이슈를 인정받은 사람, 다른 사용자 반응으로 응답 품질이 측정된 사람 등을 평가하고, 그 활동이 있었던 프로젝트의 중요도까지 곱하는 식임. 인간 대 AI가 아니라 실제로 도움이 되는 효과적인 기여와 저노력·스팸성 기여를 가르는 기준이 될 수 있음. 이슈와 PR은 Elo 점수로 정렬하거나 필터링할 수 있음. 여기서 Elo는 맥락 기반 점수의 비유일 뿐, 실제 Elo 시스템을 1:1로 옮기자는 뜻은 아님
    부정 점수는 스팸성 콘텐츠나 인정받지 못한 이슈에 대한 다른 사용자의 신고에서 나오고, 선의가 분명하지만 병합된 PR까지 이어지지 못했거나 올바른 저장소가 아니었던 이슈, 선행 구현이 필요했던 좋은 PR 같은 경우에는 중립 또는 약한 양수 점수를 주는 중간 지대가 필요해 보임

    • Elo는 조작하기 놀랄 만큼 쉬움
      예를 들어 실제로 감옥 안에 꽤 괜찮은 체스 플레이어가 있었고, 그는 자신을 이겨 높은 Elo를 얻은 플레이어 풀을 만든 뒤 그들을 이용해 자기 점수를 더 끌어올렸음. 이 과정을 반복하면 됨
      조작 가능한 어떤 제도든 AI는 조작 방법을 찾아낼 것임. 원문의 방식에서도 AI 하나가 기여자 자격을 얻으면 다른 AI들을 기여자로 끌어올릴 수 있고, 다시 같은 문제가 시작됨. 여기에 목적이 없어도 됨. 트롤은 트롤링을 하고, AI 봇을 가진 트롤은 끝없는 에너지를 쏟을 수 있음. 막으려고 애쓸수록 그들에게는 더 재미있어짐. 이 문제의 답이 있으면 좋겠지만 모르겠음
    • Elo가 궁금한 사람을 위해 덧붙이면, Elo는 약자가 아니라 사람의 성임. 자세한 내용은 여기 있음: https://en.wikipedia.org/wiki/Elo_rating_system
    • ELO가 아니라 Elo임. Elo는 약자가 아님
      https://en.wikipedia.org/wiki/Elo_rating_system
    • 비슷한 걸 만들어서 현재 데이터를 수집 중임
      Frontier users: 527,865
      Light indexed: 527,865
      Ready to queue: 9,083
      Fast scores ready: 0
      Activity events 24h: 30,266
      Fast scores completed 24h: 19,123
      Deep jobs completed 24h: 3,043
      Fast-score ETA: n/a
      Deep-hydrate ETA: 69h
      Stale running jobs: 0
      GitHub backpressure jobs: 19,113
      High automation signals: 4,608
      Medium automation signals: 1,327
      Completed jobs: 74,714
      가장 큰 난관은 GitHub 속도 제한임. 이 속도라면 98% 커버리지까지 두 달이 더 걸리겠지만, 그 이후 유지보수는 꽤 단순할 것으로 보임
    • Mitchell Hashimoto의 Vouch와 좀 비슷하게 들림: https://github.com/mitchellh/vouch

  • AI가 코드를 얼마나 잘 쓰는지 모두에게 떠들어댄 결과가 이거임
    AI를 파는 사람들이 시작했고, 이상하게도 독립 개발자들, 그중 업계에서 꽤 존경받는 사람들까지 대거 거기에 올라탔음. Facebook이 이제 사람들을 해고하면서 AI가 너무 뛰어나서 그렇다고 말하는 것도 불에 기름을 붓고 있음. 이제 AI 친구가 엄청난 코드를 찍어낸다고 확신하는 사람들이 있고, 완전히 감당 불가능해진 프로젝트들에 그 코드를 제출하고 있음

    • 카우보이 코더들이 가상 카우걸 코더를 얻고 모두에게 팔아댄 셈일지도 모름
      존경받는지와 별개로, 1인 개발자가 항상 카우보이가 되지 않을 만큼의 필수 역량을 갖추는 건 아님. 경험 부족이든 타고난 역량 부족이든 그럴 수 있음. 다만 이 서사를 완전히 믿지는 않음. “초기”부터 강한 하향식 추진이 있었기 때문임

  • .ai 도메인이라는 점이 아이러니함

    • 딱히 아이러니하다고 보진 않음. AI가 나쁘다고 말하는 게 아니라, 오용될 수 있다고 말하는 것이기 때문임
    • 웹사이트가 스크롤 코드를 좀 고쳐줬으면 함. 짜증 나서 글을 읽을 수가 없음
    • “AI가 내 프로젝트를 쓰레기화할 줄은 몰랐어!”라고 AI 쓰레기에 기반한 회사가 말하는 셈임
    • 도메인뿐만이 아님. 이건 에이전트형 스택임. 다시 말해, 이 회사 제품을 써서 자기들이 여기서 한탄하는 바로 그런 PR을 만들 수 있음

  • 모든 것의 해법은 결국 더 많은 catgirl인가? [1] 작업 증명은 원래 이메일 스팸에 대응하려는 것이었고, PR 스팸은 그 긴 전통의 최신 사례일 뿐임
    1- https://anubis.techaro.lol

    • 작업 증명은 이메일에서 안 통했던 것처럼 여기서도 안 통함
      유효한 작업 증명을 만드는 노력은 어떤 구현이든 항상 정상 사용자에게 불리하게 작용함. 스팸을 보낼 유인이 있는 사람은 언제나 더 빠르고 효율적으로 할 수 있음
      노트북이 너무 느려서 PR을 제출할 수 없다면? 누군가에게 해시 파워를 빌리면 되고, 그러면 GitHub 저장소에 오타 수정을 올리기 위해 봇넷 소유자에게 돈을 내는 시스템을 만든 셈이 됨. HashCash가 현실에서 쓰이지 않은 데는 이유가 있음. 귀엽게 들리지만, 모두가 속이지 않는 진공 상태를 가정해야만 작동할 정도로 유인이 말도 안 됨
    • Anubis는 사실 고양이가 아님. 원래 이집트 신화의 Anubis는 죽음의 신이고 개과 동물 머리를 가졌음. 애니메이션 catgirl과 dog girl은 처음 보면 비슷해 보일 수 있음
    • Anubis는 PR을 만드는 에이전트가 아니라 크롤러를 막기 위한 것으로 봄. 여기서는 작업 증명이 통하지 않음. 에이전트가 그냥 계산을 해버릴 테니까

  • 온보딩 문서의 문체에는 흔한 AI 티가 있음. 인용문에서도 em dash와 “A가 아니라 B다” 식 문장이 보임
    불로 불을 끄려는 것이거나, 이미 말했듯 시간이 없어서 그럴 수도 있다는 건 이해함. 그래도 전체적으로는 부족한 반쪽짜리 대응처럼 느껴짐

    • 전체 글이 명백히 LLM 생성으로 보임
      사람이 생각을 정리해 넣은 건 알겠지만, LLM에 “이걸 블로그 글로 바꿔줘”라고 시키는 건 HN에 어울리지 않는 저노력 콘텐츠라고 생각했음. 그래도 기본 방식인 “기여자로 제한”이 보안 측면에서 나쁜 생각일 수 있다는 논의를 낳은 점은 있음
    • 자기 프로젝트에 AI를 쓰는 것과, 다른 사람이나 봇이 보내는 AI 기여에 압도되는 것은 다른 문제임

  • “이메일이 GitHub 계정과 일치하면 GitHub가 커밋을 프로필에 연결하고 기여자 상태를 부여한다”는 부분을 보고, 기여자의 이메일 주소가 바뀌면 깨지지 않을까 걱정했음
    수년 동안 더 이상 존재하지 않는 이메일 주소로 여러 프로젝트에 기여한 적이 있기 때문임
    하지만 실제로는 작성자의 원래 git 커밋에 기록된 이메일 주소를 쓰는 게 아니라, GitHub 사용자 ID와 사용자명이 고유 부분으로 들어간 GitHub 생성 주소를 쓰는 것 같음. 그러면 작성자가 이메일 주소를 바꿔도 유지될 수 있음. 다만 기여자가 계정 접근권을 잃고 새 계정을 만들어야 하는 경우에는 깨질 수 있지만, 그건 아마 덜 흔할 것임

  • “지원자에게 재미있는 테스트 과제를 주는 걸 멈춰야 할까?”에 대한 답은 그렇다임

    • 이 회사는 그 과제를 완료하면 비용을 지급하는 것 같아서, 그렇게 나쁘지는 않을 수도 있음
    • 개발자들: 화이트보드 면접은 실제 업무와 관련된 걸 측정하지 못하니 그만하라
      또한 개발자들: 실제 문제를 풀게 하지 말라
    • 애초에 누구에게 재미있다는 건지 모르겠음
답변달기