Hacker News 2026.05.19 67

GitHub 저장소를 도배하는 AI 봇 스팸, git --author 플래그 하나로 막은 이야기

요즘 오픈소스 메인테이너들이 겪는 새로운 골칫거리

GitHub에서 오픈소스를 운영해본 분들이라면 최근 묘한 변화를 느끼셨을 거예요. 어디서 듣도 보도 못한 계정이 갑자기 PR(Pull Request)을 잔뜩 올리는데, 내용을 열어보면 어색한 코드 변경이거나 의미 없는 리팩토링, 혹은 README의 오타 하나 고치는 것 같은 자잘한 작업들이에요. 작성자 프로필을 봐도 아무 활동 이력이 없고요. 이게 바로 요즘 늘어나고 있는 AI 봇 스팸 PR 현상이에요.

왜 이런 일이 벌어지냐면, 일부 사람들이 AI 에이전트(자동으로 코드 작성과 PR 생성을 해주는 AI)를 이용해서 "GitHub 컨트리뷰션 이력"을 인위적으로 쌓고 있기 때문이에요. 어떤 경우는 취업 시장에서 이력을 부풀리려는 목적이고, 어떤 경우는 봇 자체를 학습시키거나 평가하려는 실험이기도 해요. 문제는 메인테이너 입장에서는 이걸 일일이 검토하느라 진짜 기여자에게 쓸 시간이 빨려나간다는 거예요.

Archestra 팀의 해결책 - 의외로 단순한 발상

Archestra라는 팀이 자기들 저장소에서 이 문제를 어떻게 해결했는지 공유했어요. 그런데 해결 방법이 놀랍게도 "git의 오래된 기능 하나"를 활용한 거였어요. 바로 --author 플래그예요.

이게 뭐냐면, git에서 커밋을 만들 때 "커밋한 사람(committer)"과 "코드를 짠 사람(author)"을 따로 지정할 수 있는 기능이에요. 평소엔 둘 다 동일한 사람이지만, 누군가의 패치를 대신 적용할 때 "코드 작성자"는 원작자로 남기고 자기는 "적용한 사람"으로 기록하는 용도로 쓰여왔어요. 1970년대부터 있던 메일링 리스트 기반 패치 문화에서 유래한 기능이죠.

Archestra 팀이 한 일은 이래요. 기여 가이드라인에 "AI를 써서 코드를 작성했다면, --author 플래그로 AI를 작성자로 명시해주세요"라고 못 박아둔 거예요. 예를 들면 git commit --author="Claude <noreply@anthropic.com>" 같은 식으로요. 그리고 PR이 올라오면 커밋 메타데이터를 확인해서, AI가 작성자인 PR은 별도 라벨을 붙이거나 다르게 처리해요.

왜 이게 효과가 있을까

처음 들으면 "그게 무슨 차단이야? 봇이 그냥 자기 이름으로 커밋하면 되잖아"라고 생각하실 수 있어요. 맞아요, 기술적으로는 누구나 우회할 수 있어요. 그런데 여기서 핵심은 "규칙을 명시했다"는 사실 그 자체예요.

규칙이 명시되어 있는데 어겼다는 건, 그 PR을 올린 사람이 의도적으로 정책을 위반했다는 뜻이 돼요. 그러면 메인테이너는 양심의 가책 없이 즉시 닫아버릴 명분이 생기죠. 또 "AI 코드인 걸 숨기려고 했다"는 행위 자체가 신뢰를 깎아먹어요. 반대로 정직하게 --author를 표기한 사람의 PR은, 코드 품질만 괜찮다면 정상적으로 검토받을 수 있고요.

즉, 이건 기술적 방어막이라기보다 사회적 계약을 명문화한 도구에 가까워요. "우리는 AI 기여를 거부하진 않지만, 숨기는 건 받지 않는다"는 입장을 git이라는 도구에 새겨놓은 거죠. 흥미로운 건 git의 author 필드는 위변조가 가능하지만, 한번 기록되면 그 커밋의 히스토리에 영구적으로 남는다는 점이에요. 나중에 라이선스 분쟁이나 코드 출처 추적이 필요할 때도 의미 있는 흔적이 되거든요.

다른 접근법들과 비교해보면

비슷한 문제를 다르게 푸는 시도들도 있어요. 예를 들어 어떤 프로젝트는 CLA(Contributor License Agreement)를 강화해서 AI 코드의 라이선스 책임을 기여자에게 명시적으로 지우고요. 또 Hacktoberfest 같은 이벤트는 봇 PR을 막기 위해 메인테이너가 직접 "hacktoberfest-accepted" 라벨을 붙이도록 했어요. GitHub 자체에서도 PR 작성자의 활동 이력을 보여주는 기능을 강화하고 있고요.

Archestra 방식의 장점은 추가 인프라가 필요 없다는 거예요. CLA 봇을 돌릴 필요도, 라벨 시스템을 구축할 필요도 없어요. git에 이미 있던 기능을 활용했을 뿐이거든요. 단점이라면 결국 "정직한 기여자"를 전제로 한다는 점인데, 앞서 말한 것처럼 정직하지 않은 사람의 PR을 거를 명분이 되어주니까 어느 정도 보완이 돼요.

한국 개발자에게 주는 시사점

오픈소스를 운영하는 분이라면 이 방식을 그대로 가져와도 좋아요. CONTRIBUTING.md에 한 줄 추가하면 끝이거든요. 한국에서도 점점 글로벌 오픈소스 프로젝트가 늘고 있는데, AI 봇 스팸은 시간 문제로 닥쳐올 이슈예요. 미리 정책을 명시해두는 게 나중에 문제가 터졌을 때 "왜 거절했냐"는 분쟁을 줄여줘요.

사내 개발팀에서도 응용 가능해요. "Claude Code나 Cursor로 생성한 커밋은 --author에 표기하자"라는 컨벤션을 두면, 나중에 어떤 코드가 AI로 작성되었는지 추적이 쉬워져요. 코드 리뷰 강도를 다르게 적용하거나, 버그가 났을 때 원인 분석에도 유용하고요.