트렌드 · 4분 · 05.19

OSS 메인테이너의 주 절반을 잡아먹는 'AI slop' — Archestra가 git --author로 뚫은 방어선

loopy vibecoder

#draft #바이브코딩 #OSS #GitHub #AI-slop #git-author #Archestra #MCP #Ildar-Iskhakov #책임감

핵심 요약 (TL;DR)

Archestra CTO Ildar Iskhakov가 자사 OSS 레포에서 단일 피처 요청 1개에 테스트 안 된 PR 27개, 바운티 이슈 1개에 댓글 253개가 쏟아져 매주 반나절을 AI slop 청소에 쓴다고 공개했습니다. 해결책으로 git의 --author 플래그로 신규 기여자를 자동 화이트리스트에 올리는 3-step 온보딩 패턴을 제시했고, 첫 주에 봇 약 500개를 차단했다고 회사 블로그에 적었습니다. HN에 2026-05-19 KST 기준 370pts·177댓글로 1면.

누가 청소비를 내는가

"바이브코딩이 모두를 개발자로 만든다"는 문장은 가능성처럼 들립니다. 하지만 같은 흐름의 외부 비용이 OSS 메인테이너의 시간을 갉아먹기 시작했다는 게 이번 사례의 메시지입니다. Archestra CTO Ildar Iskhakov가 자기 OSS 레포에서 겪은 일을 회사 블로그(archestra.ai/blog/only-responsible-ai)에 풀었는데, 그 숫자가 구체적이라 무겁습니다.

구체적 숫자: PR 27개, 댓글 253개

Archestra는 MCP·에이전트 인프라 OSS를 만드는 회사이고, GitHub에 본인이 관리하는 레포가 있습니다. 그 레포에 어느 날부터 AI slop(AI가 적당히 만들어 던지는 저품질 PR과 이슈 코멘트)이 쌓이기 시작했죠.

"x.ai 프로바이더 추가" 단일 피처 요청 1개 → 테스트도 안 된 PR 27개.
바운티(상금) 이슈 1개 → 누적 댓글 253개. "AI accounts poisoning the conversation"이라는 본인 표현이 나옵니다.
본인 진술 — "매주 절반-하루(half a day every week)를 AI 쓰레기 청소에 쓴다."

여기서 무서운 건 PR과 댓글이 너무 많아서 노이즈인 게 아니라, PR이 진짜처럼 보이지만 테스트는 안 돌려본 상태라는 점입니다. 메인테이너가 PR을 닫으려면 한 번씩은 읽어야 하고, 그 시간이 누적되면 자기 코드 짜는 시간보다 남의 AI slop 청소하는 시간이 더 길어지는 거죠.

GitHub의 기본 방어가 왜 안 통하나

GitHub에는 'Limit to prior contributors'라는 기본 옵션이 있습니다. 이미 main 브랜치에 commit이 있는 기여자만 PR을 자유롭게 열 수 있게 하는 화이트리스트인 거죠. 그런데 이게 한 가지를 못 거릅니다 — 신규 정당 기여자도 main commit이 0이고, AI 봇도 main commit이 0입니다. 둘을 구분하지 못하는 거예요.

Iskhakov가 짚은 약점이 정확히 이 지점입니다. 정당한 신규 기여자를 안 막으려면 옵션을 풀어야 하고, 그러면 AI 봇이 들어오고. 옵션을 켜면 정당 기여자가 막히고.

우회 패턴: git --author로 가짜 첫 commit 박기

Iskhakov가 제시한 3-step 온보딩이 이렇습니다.

신규 기여자가 Archestra 웹사이트에서 ethical-AI 규칙에 동의 + CAPTCHA 통과.
GitHub Action이 git commit --author=신규유저<noreply email> 트릭으로 신규 유저 명의의 가짜 첫 commit을 main에 박음. git의 --author 플래그가 원래 과거 commit 작성자를 표기하는 용도였는데, 이걸 신규 기여자 등록 신호로 재해석한 겁니다.
GitHub가 그 commit을 보고 그 사용자를 "contributor"로 자동 인식 → Limit-to-prior-contributors 화이트리스트에 자동 등록.

회사 블로그에는 첫 주에 봇 약 500개를 차단했다는 수치가 한 줄 더 적혀 있습니다. CAPTCHA + ethical-AI 동의 단계에서 봇이 걸러진다는 신호죠.

# 의사 코드: GitHub Action에서 가짜 첫 commit을 만드는 흐름
- name: Register contributor
  run: |
    git commit --allow-empty \
      --author="${NEW_USER} <${NEW_USER}@users.noreply.github.com>" \
      -m "register: ${NEW_USER}"
    git push origin main

이 패턴이 한국 OSS 메인테이너에게 의미하는 것

HN에서 이 글이 370pts·177댓글로 1면에 오른 이유는 "트릭이 영리해서"만이 아닙니다. 댓글 흐름은 두 갈래로 갈렸습니다.

한쪽은 "이건 git의 메타데이터를 우회적으로 쓰는 거라 GitHub 정책 문제 소지가 있다." 가짜 commit 작성자를 박는다는 점에서 GitHub의 commit signature·noreply 이메일 정책 변경에 취약합니다. 현재 시점에서 명시적인 위반 보도는 없지만, GitHub이 noreply 정책을 조이면 이 패턴은 한 번에 막힐 수 있어요.

다른 한쪽은 "문제 자체가 곧 우리한테 온다." 한국 OSS 메인테이너도 같은 패턴을 곧 겪을 가능성이 높다는 거죠. 바이브코딩으로 생산성이 올라간 만큼 생산된 PR을 누가 검토하는가가 다음 분기 과제로 옮겨갑니다.

우리가 안 만드는 법

이 사례에서 가장 마음에 걸린 부분은 AI slop을 보내는 쪽이 누구인가입니다. 악의적인 봇만이 아닙니다. Claude Code로 PR을 짠 다음 테스트 한 번 안 돌리고 던지는 바이브코더도 그 비용을 보태고 있는 거죠. 가능성을 보여주는 사례가 늘어날수록, 그 가능성이 다른 누군가의 주 20시간을 빼앗을 때 책임은 누가 지나를 묻는 사례도 같이 늘어납니다.

자기 점검 한 줄 — PR을 열기 전에 테스트가 통과했는지를 확인했는가. AI에게 PR 본문을 써달라고 하는 건 자유지만, 테스트 결과를 첨부했는가는 본인 책임입니다. 메인테이너의 주 절반을 빼앗지 않는 가장 쉬운 방법인 거예요.

FAQ

Q. git --author 트릭이 GitHub 약관 위반인가요?
A. 2026-05-19 KST 기준 명시적 위반 보도는 없습니다. 다만 가짜 commit 작성자 표기에 의존하는 패턴이라 GitHub의 noreply 이메일 정책이나 commit signature 정책이 조여지면 한 번에 막힐 수 있다는 점은 도입 전 별도로 확인할 필요가 있습니다.

Q. CAPTCHA만 통과하면 똑같이 화이트리스트에 들어가는데, 진짜 봇 방어가 되나요?
A. Archestra는 첫 주에 봇 약 500개를 차단했다고 적었습니다. 다만 정교한 행위자가 CAPTCHA를 통과하면 같은 화이트리스트에 들어가는 건 맞습니다. 이 패턴은 완벽한 방어가 아니라 비용 곡선을 올리는 마찰에 가깝습니다.

Q. 우리 회사 OSS도 똑같이 깔까요?
A. 시간 회수율로 판단하세요. 주 절반을 AI slop 청소에 쓰고 있지 않다면 굳이 도입하지 않아도 됩니다. 트래픽이 있는 큰 OSS에서만 의미 있는 패턴입니다.

마무리

"바이브코딩의 외부 비용"이라는 개념이 처음으로 구체적 숫자로 잡힌 사례입니다. 27개 PR, 253개 댓글, 주 반나절, 첫 주에 봇 약 500개 차단. 다음 PR을 열기 전에 한 번 더 묻게 됩니다 — 이 PR이 메인테이너의 시간을 더하는가, 빼는가.