고도·Zig 등 오픈소스 프로젝트, AI 생성 코드 PR 전면 차단 흐름

오픈소스 프로젝트들이 AI 생성 코드 PR에 선을 긋기 시작함

• 오픈소스 게임 엔진 ‘고도(Godot)’ 재단이 AI가 만든 바이브 코딩 풀 리퀘스트(PR)를 더 이상 받지 않겠다는 방향을 명확히 함

  • 수개월간 내부 논의를 거친 결과로 알려짐
  • 유지보수자들이 AI가 작성한 코드를 포함해 급증하는 PR을 더 이상 감당하기 어렵다고 호소한 게 배경임

• 이 흐름은 고도만의 이야기가 아님

  • PlayStation 에뮬레이터 프로젝트
  • 휴대용 게임 콘솔 Playdate 개발업체
  • Zig 커뮤니티
  • Ghostty, curl 같은 프로젝트들도 AI 기반 기여나 기여 파이프라인 일부를 제한하는 움직임을 보이고 있음

고도가 말한 진짜 이유는 ‘리뷰의 의미가 사라진다’는 것

• 고도 재단은 AI 코드가 형편없어서만 막는다고 말하지 않음

  • 물론 품질, 정확도, 보안 측면의 문제가 크고, AI가 대량 생성한 코드가 리뷰어를 태우고 있다는 문제의식은 있음
  • 하지만 더 본질적인 이유는 코드 리뷰가 미래 유지보수자를 키우는 과정이라는 점임

• 사람 기여자의 PR을 리뷰하면, 피드백이 그 사람에게 남음

  • 리뷰어가 왜 이 설계가 안 좋은지, 왜 이 API가 프로젝트 스타일에 맞지 않는지 설명함
  • 기여자는 그 피드백을 배워 다음 PR을 더 잘 만들 수 있음
  • 그래서 지루한 리뷰 작업도 ‘새 기여자를 키운다’는 보람이 생김

• AI 생성 코드에서는 이 구조가 깨짐

  • 리뷰어가 남긴 피드백이 모델의 다음 행동에 의미 있게 반영된다고 보기 어려움
  • AI를 많이 쓰는 제출자가 자기 코드의 의도와 책임을 충분히 이해하는지도 불확실함
  • 결국 리뷰어는 누군가를 멘토링하는 게 아니라, 기계가 뱉은 결과물을 대신 치우는 사람이 됨. 이건 사기 떨어질 만함

정책은 ‘AI 전면 금지’라기보다, 실질적 코드 생성 PR 금지에 가까움

• 고도 저장소에서는 자율 AI 에이전트와 바이브 코딩된 PR이 이미 자동 차단되고 있음

  • 다만 기존 공식 가이드라인에는 이 기준이 명시돼 있지 않았음
  • 현재 개발 중인 업데이트는 AI가 실질적인 코드 조각을 생성하는 것을 금지해 이 공백을 메우려는 방향임

• 금지 대상은 봇이 PR을 만들었는지, 사람이 AI 출력을 붙여넣었는지와 무관함

  • 사람이 검토 후 공개했더라도 AI가 실질적인 코드를 생성했다면 제한 대상이 됨
  • 핵심은 “최종 제출 버튼을 누른 주체”가 아니라 “코드를 실제로 만든 주체와 책임 소재”임

• 다만 낮은 위험도의 AI 사용은 허용함

  • 코드 완성
  • 정규 표현식 작성
  • 찾기 및 바꾸기
  • 사람이 작성한 텍스트의 기계 번역
  • 이런 작업에 AI를 쓴 경우에는 PR에서 AI 사용 사실을 명시해야 함

• 신규 기여자에 대한 제한도 들어감
  • 병합된 PR이 3개 이하인 신규 작성자는 새로운 기능이나 대규모 리팩토링을 제출하기 전에 명시적인 승인을 받아야 함
  • 대량 AI 코드가 신규 계정이나 낮은 신뢰도의 기여 경로로 밀려오는 상황을 의식한 조치로 볼 수 있음

Zig도 비슷한 논리로 ‘기여자에게 베팅한다’고 봄

• Zig 소프트웨어 재단 커뮤니티도 지난 4월 AI 기반 기여에 대해 무관용 정책을 채택함

  • 이들이 강조한 문장은 꽤 인상적임. PR 검토의 핵심은 코드 자체가 아니라 제출자에게 투자하는 것이라는 주장임
  • 첫 번째 PR의 내용보다 그 사람이라는 기여자에게 베팅한다는 식으로 설명함

• AI 생성 PR은 이 계산을 무너뜨림

  • 리뷰어의 시간과 노력이 미래의 유지보수자나 더 나은 기여자를 키우는 데 쓰이지 않음
  • 코드만 남고 사람의 학습은 빠짐
  • 오픈소스 프로젝트 입장에서는 이게 장기적으로 유지보수 생태계를 갉아먹는다고 보는 것임

개발자에게 남는 질문은 꽤 현실적임

• 바이브 코딩으로 뭔가를 만드는 게 무조건 나쁘다는 얘기는 아님

  • 혼자 쓰는 작은 도구
  • 버려도 되는 실험 코드
  • 정규식이나 반복 수정 같은 낮은 위험 작업
  • 이런 영역에서는 AI가 꽤 유용할 수 있음

• 문제는 이해하고 책임져야 하는 서비스나 오픈소스 기여에 AI 코드를 그대로 밀어 넣는 경우임

  • 리뷰어는 결과물의 품질과 유지보수성을 봐야 함
  • 제출자는 코드가 왜 그렇게 동작하는지 설명할 수 있어야 함
  • 보안, 성능, 프로젝트 스타일, 장기 유지보수까지 책임져야 하는데 “AI가 이렇게 짜줬다”는 답은 통하지 않음

• 결국 오픈소스 커뮤니티의 기준은 한쪽으로 수렴하는 중임

  • AI를 도구로 쓰는 건 허용할 수 있음
  • 하지만 AI가 실질적인 기여자가 되고, 사람은 제출 버튼만 누르는 구조는 거부하겠다는 것
  • 개발자 입장에선 AI 코드의 소유권이 아니라 책임권을 먼저 생각해야 할 시점임

---

기술 맥락

• 오픈소스 코드 리뷰는 단순한 품질 게이트가 아니에요. 리뷰어가 피드백을 주면 기여자가 프로젝트 구조와 스타일을 배우고, 다음에는 더 나은 유지보수자가 될 가능성이 생기거든요.

• AI 생성 PR이 문제 되는 이유는 이 학습 루프가 끊기기 때문이에요. 리뷰어가 긴 피드백을 남겨도 그게 제출자의 실력 향상으로 이어지는지 불확실하고, 모델 자체가 프로젝트 맥락을 지속적으로 학습한다고 보기도 어려워요.

• 고도가 낮은 위험도의 AI 사용은 허용하는 것도 현실적인 선택이에요. 코드 완성이나 정규식, 찾기·바꾸기처럼 사람이 의도를 알고 통제하는 작업은 생산성을 올릴 수 있거든요. 반대로 기능 구현이나 리팩토링처럼 설계 책임이 큰 작업은 제출자가 코드를 이해하고 설명할 수 있어야 해요.

• 신규 기여자에게 별도 승인을 요구하는 기준도 유지보수 비용을 줄이기 위한 장치예요. 병합된 PR이 3개 이하라면 프로젝트 신뢰가 아직 쌓이지 않은 상태라서, 대규모 AI 코드가 들어왔을 때 리뷰 부담이 폭증할 수 있거든요.

• 개발팀에서도 같은 기준을 적용해볼 만해요. AI를 썼는지가 핵심이 아니라, 코드를 낸 사람이 동작 원리와 장애 책임을 질 수 있는지가 핵심이에요.