--- title: "고도·Zig 등 오픈소스 프로젝트, AI 생성 코드 PR 전면 차단 흐름" published: 2026-07-03T02:05:03.284Z canonical: https://jeff.news/article/4551 --- # 고도·Zig 등 오픈소스 프로젝트, AI 생성 코드 PR 전면 차단 흐름 고도 재단을 비롯한 여러 오픈소스 프로젝트가 AI가 만든 ‘바이브 코딩’ 풀 리퀘스트를 받지 않겠다고 선을 긋고 있어. 이유는 코드 품질만이 아니라 리뷰어의 시간, 신규 기여자 멘토링, 유지보수자 양성이라는 코드 리뷰의 본래 기능이 무너진다는 데 있어. ## 오픈소스 프로젝트들이 AI 생성 코드 PR에 선을 긋기 시작함 - 오픈소스 게임 엔진 ‘고도(Godot)’ 재단이 AI가 만든 바이브 코딩 풀 리퀘스트(PR)를 더 이상 받지 않겠다는 방향을 명확히 함 - 수개월간 내부 논의를 거친 결과로 알려짐 - 유지보수자들이 AI가 작성한 코드를 포함해 급증하는 PR을 더 이상 감당하기 어렵다고 호소한 게 배경임 - 이 흐름은 고도만의 이야기가 아님 - PlayStation 에뮬레이터 프로젝트 - 휴대용 게임 콘솔 Playdate 개발업체 - Zig 커뮤니티 - Ghostty, curl 같은 프로젝트들도 AI 기반 기여나 기여 파이프라인 일부를 제한하는 움직임을 보이고 있음 > [!IMPORTANT] > 이 논쟁의 핵심은 “AI 코드가 쓸 만하냐”를 넘어, 리뷰어의 시간이 누구에게 투자되는가라는 오픈소스 유지보수의 구조 문제임. ## 고도가 말한 진짜 이유는 ‘리뷰의 의미가 사라진다’는 것 - 고도 재단은 AI 코드가 형편없어서만 막는다고 말하지 않음 - 물론 품질, 정확도, 보안 측면의 문제가 크고, AI가 대량 생성한 코드가 리뷰어를 태우고 있다는 문제의식은 있음 - 하지만 더 본질적인 이유는 코드 리뷰가 미래 유지보수자를 키우는 과정이라는 점임 - 사람 기여자의 PR을 리뷰하면, 피드백이 그 사람에게 남음 - 리뷰어가 왜 이 설계가 안 좋은지, 왜 이 API가 프로젝트 스타일에 맞지 않는지 설명함 - 기여자는 그 피드백을 배워 다음 PR을 더 잘 만들 수 있음 - 그래서 지루한 리뷰 작업도 ‘새 기여자를 키운다’는 보람이 생김 - AI 생성 코드에서는 이 구조가 깨짐 - 리뷰어가 남긴 피드백이 모델의 다음 행동에 의미 있게 반영된다고 보기 어려움 - AI를 많이 쓰는 제출자가 자기 코드의 의도와 책임을 충분히 이해하는지도 불확실함 - 결국 리뷰어는 누군가를 멘토링하는 게 아니라, 기계가 뱉은 결과물을 대신 치우는 사람이 됨. 이건 사기 떨어질 만함 ## 정책은 ‘AI 전면 금지’라기보다, 실질적 코드 생성 PR 금지에 가까움 - 고도 저장소에서는 자율 AI 에이전트와 바이브 코딩된 PR이 이미 자동 차단되고 있음 - 다만 기존 공식 가이드라인에는 이 기준이 명시돼 있지 않았음 - 현재 개발 중인 업데이트는 AI가 실질적인 코드 조각을 생성하는 것을 금지해 이 공백을 메우려는 방향임 - 금지 대상은 봇이 PR을 만들었는지, 사람이 AI 출력을 붙여넣었는지와 무관함 - 사람이 검토 후 공개했더라도 AI가 실질적인 코드를 생성했다면 제한 대상이 됨 - 핵심은 “최종 제출 버튼을 누른 주체”가 아니라 “코드를 실제로 만든 주체와 책임 소재”임 - 다만 낮은 위험도의 AI 사용은 허용함 - 코드 완성 - 정규 표현식 작성 - 찾기 및 바꾸기 - 사람이 작성한 텍스트의 기계 번역 - 이런 작업에 AI를 쓴 경우에는 PR에서 AI 사용 사실을 명시해야 함 > [!TIP] > 오픈소스에 AI 도움을 받은 코드를 내고 싶다면, 해당 프로젝트의 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를 썼는지가 핵심이 아니라, 코드를 낸 사람이 동작 원리와 장애 책임을 질 수 있는지가 핵심이에요. ## 핵심 포인트 - 고도 재단이 AI가 실질적인 코드 조각을 생성한 풀 리퀘스트를 금지하는 방향으로 가이드라인을 업데이트 중 - 자율 AI 에이전트와 바이브 코딩 PR은 이미 고도 깃허브 저장소에서 자동 차단됨 - 코드 완성, 정규 표현식, 찾기·바꾸기 같은 낮은 위험 작업에는 AI 사용을 허용 - 병합된 풀 리퀘스트가 3개 이하인 신규 작성자는 큰 기능이나 리팩토링 전 명시적 승인을 받아야 함 - Zig, Ghostty, curl 등도 AI 기반 기여나 허위 버그 보고로 인한 리뷰 부담을 제한하는 흐름에 있음 ## 인사이트 오픈소스에서 코드 리뷰는 단순 품질검사가 아니라 사람에게 투자하는 과정이야. AI가 만든 코드를 사람이 대신 책임지는 구조가 되면, 리뷰어는 코드를 고치는 동시에 아무도 성장하지 않는 노동을 떠안게 돼.