# Godot, AI 작성 코드 기여를 더 이상 받지 않기로 함 > Clean Markdown view of GeekNews topic #31031. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31031](https://news.hada.io/topic?id=31031) - GeekNews Markdown: [https://news.hada.io/topic/31031.md](https://news.hada.io/topic/31031.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-02T10:13:42+09:00 - Updated: 2026-07-02T10:13:42+09:00 - Original source: [pcgamer.com](https://www.pcgamer.com/gaming-industry/open-source-game-engine-godot-will-no-longer-accept-ai-authored-code-contributions-we-cant-trust-heavy-users-of-ai-to-understand-their-code-enough-to-fix-it/) - Points: 2 - Comments: 1 ## Topic Body - 오픈소스 게임 엔진 **Godot**는 AI 생성 Pull Request가 리뷰 부담을 키우자, **AI 작성 코드와 AI 에이전트 제출**을 기여 정책에서 금지하기로 함 - 유지보수자들은 AI 생성 PR 검토가 이미 지루한 리뷰 작업을 더 소모적으로 만들고, 새 기여자를 **미래 유지보수자**로 키우는 효과도 약해진다고 봄 - 새 정책은 AI가 작성한 코드, AI 에이전트가 제출한 Pull Request, 사람 간 커뮤니케이션에 포함된 **AI 생성 텍스트**를 명시적으로 거부할 예정임 - 기여자는 AI를 “menial things”에만 보조적으로 사용할 수 있고 사용 사실을 공개해야 하며, 사람이 쓴 원문 기반 **기계 번역**은 허용됨 - Godot Foundation은 AI 도구가 빠르게 바뀌는 만큼 우선 보수적으로 운영하고, 상황 변화에 따라 정책을 다시 평가할 계획임 --- ### Godot의 기여 정책 변경 - Godot Foundation과 유지보수자들은 몇 달간 논의한 끝에 **기여자 가이드라인**을 개정해 AI 관련 제출을 제한하기로 함 - 제한 대상은 AI가 작성한 코드, AI 에이전트가 제출한 Pull Request, 사람 간 커뮤니케이션에 들어간 AI 생성 텍스트임 - Godot는 Slay the Spire 2와 The Case of the Golden Idol 같은 게임에 쓰이는 오픈소스 게임 엔진임 ### AI Pull Request가 만든 유지보수 부담 - 유지보수자들은 2월부터 늘어난 **AI slop Pull Request**에 어떻게 대응할지 논의해 왔음 - 이런 PR 흐름은 프로젝트 코드 리뷰어들에게 “increasingly draining and demoralizing”한 상태가 됨 - Godot Foundation은 문제가 일시적이지 않다고 보고, 유지보수자 부담을 줄이면서도 새 기여자를 미래 유지보수자로 키우는 경로는 유지하려 함 ### 리뷰가 멘토링으로 이어지지 않는 문제 - 검토 대기 중인 PR이 많아진 상황 자체는 Godot 사용과 기여에 대한 관심 증가로 볼 수 있음 - 그러나 AI가 작성하거나 제출한 기여가 늘면서, 유지보수자들이 PR 리뷰에 시간을 쓰려는 의지가 약해지고 있음 - PR 피드백이 잠재적인 미래 유지보수자를 멘토링하지 못하고 “기계에 흡수”된다면, 자유 시간을 리뷰에 쓰는 일을 정당화하기 어려워짐 ### 새 정책의 구체적 제한 - Godot의 기여 정책은 곧 **AI-authored code**를 명시적으로 거부하는 내용을 포함할 예정임 - 기여자는 AI 보조를 “menial things”에만 사용해야 하며, 사용 사실을 공개해야 함 - Foundation은 “AI는 책임을 질 수 없고, AI를 많이 쓰는 사람이 자기 코드를 고칠 만큼 충분히 이해한다고 신뢰할 수 없다”고 밝힘 - 사람 간 커뮤니케이션에서도 **AI 생성 텍스트**는 거부됨 - Foundation은 이를 “a basic principle of respect”라고 표현함 - 사람이 작성한 원문을 바탕으로 한 **기계 번역**은 계속 허용됨 ### 정책의 운영 방향 - Godot Foundation은 낮은 노력의 “slop” 기여에 장벽을 추가하는 데 초점을 맞춤 - 유지보수자가 코드 리뷰를 계속할 수 있게 하고, 새 기여자를 미래 유지보수자로 성장시키는 것도 정책 목표에 포함됨 - 모든 기여는 자기 코드에 책임을 지고, 실패할 경우 직접 고칠 수 있는 **사람**에게서 와야 함 - Foundation은 현재 AI 도구가 매일 바뀌고 있어 보수적인 정책을 유지하되, 변화에 따라 다시 평가하겠다고 밝힘 ## Comments ### Comment 61022 - Author: neo - Created: 2026-07-02T10:13:43+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48743472) - 이 정책은 공정함. 장황한 **AI 작성 텍스트 벽**을 철저히 검토하라고 받는 건 정말 짜증 나고, 인간 정신에 대한 서비스 거부 공격 같음 다만 AI 기반 코딩 자체를 막지는 못할 듯함. 부정적으로는 제출자가 사람처럼 보이게 문체 표식을 덧붙여, 핵심 내용과 기여 규모는 그대로인데 스타일만 괴상해질 수 있음 긍정적으로는 “이게 코드고, 바꾼 이유고, 영향은 이렇다”처럼 군더더기 없는 커밋과 코멘트를 내게 될 수 있음. AI가 만들었더라도 이런 작은 기여는 검증하기 훨씬 쉬워지고, 적절한 기여 크기나 더 엄격한 리뷰가 필요한 변경에 대한 표준도 생길 수 있음 개인적으로는 내용이 후자에 맞는다면 AI 생성 여부는 크게 상관하지 않음 - 리뷰해 본 경험상 대부분의 기여자는 정책을 읽지 않고, 특히 **빠른 AI PR**을 만드는 사람들은 더 그렇다. 새 정책이 이걸 크게 바꾸지는 못할 듯함 “군더더기 없는 커밋과 코멘트”가 실제로 오면 꿈같은 일임 - 문제는 많은 **AI 기여**가 제대로 검토되지 않은 채 게으르게 만들어진다는 데 있음. 정확성 확인, 실제 동작 테스트, 부작용 점검, 가독성 조정, 프로젝트 지침 준수까지 거친 기여라면 사람만 만든 기여와 구분하기 어렵겠지만, 그런 노력을 하지 않는 사람이 많아서 대다수는 그 수준에 못 미침 - “인간 정신에 대한 서비스 거부 공격”이라는 표현은 의도적인 **적대적 설계**의 예일 수도 있음. 방대한 출력을 요약하려면 결국 사용자가 LLM 기반 도구를 쓰도록 강제하는 방식임 이런 맥락에서는 AI 기여를 밀어내는 게 타당하고, Godot처럼 이미 큰 가치를 입증한 소프트웨어라면 더욱 그렇다 - Linux 커널에도 원래 비슷한 규칙이 있었고, 패치당 **200줄 이하**였음. git 커밋과 풀 리퀘스트 설명에도 커밋당 400자/10줄, 초기 풀 리퀘스트 3커밋 이하, 풀 리퀘스트 설명 20줄, 동시에 열린 풀 리퀘스트 3개 이하 같은 제한을 도입할 수 있음 - AI가 쓴 커밋이라도 사람이 작성한 것처럼 읽힌다면 개발자가 할 일을 한 것이고, 표시될 것도 없음 AI가 쓴 커밋이 본질적으로 다르지 않다면 거절할 이유도 없으니, AI 기반 코딩을 막는 게 목표는 아니라고 봄 - 한쪽에서는 AI 업체의 기업가치가 가까운 미래에 모든 코드와 디지털 산출물이 **AI로 작성될 것**이라는 가정에 기대고 있는데, 다른 한쪽에서는 거의 모든 인기 오픈소스 프로젝트가 AI 기여를 막으려 한다는 점이 흥미로움. 양립시키기 어렵다 개인적으로도 내 오픈소스 프로젝트에서 많이 써 본 뒤 **AI 숙취** 같은 걸 겪고 있음. 쓰는 순간에는 몇 주 걸릴 기능을 몇 시간 만에 만들며 대단한 힘을 얻은 느낌인데, 시간이 지나 코드를 보면 도구가 남긴 미묘한 균열과 불일치가 보여서 난감해짐 이제는 큰 기능 개발보다 계획, 디버깅, 좁은 범위의 리팩터링처럼 엄격한 가드레일을 둘 수 있는 곳에 덜 쓰려 함. 그래도 작업은 빨라지지만 10배가 아니라 1.5~3배 정도에 가까움 코딩에 필요한 정신적 집중은 줄지만, 기계와 계속 채팅하면서 자연어 지시가 어떻게 해석될지 모르는 새로운 피로가 생김. 내부 배선이 계속 바뀌는 기계를 버튼 조합으로 조작하는 느낌이라 만족스럽지 않다 - 전통적으로 오픈소스 기여는 **자기 선택적**이었음. PR을 만들려면 프로젝트에 어느 정도 관심이 있어야 했고, 가치 있는 기여를 하려면 코드베이스와 관례를 이해하고 프로젝트와 조금은 상호작용해야 했음 AI가 가능하게 한 건 프로젝트에 전혀 관여하지 않은 사람들의 기여임. 이제 PR을 만들었다는 사실만으로 “이 사람이 프로젝트 성공에 어느 정도 관심이 있다”는 문턱을 넘었다고 볼 수 없게 됨 AI는 제대로 쓰면 증폭기지만, 오픈소스 관리자 입장에서는 프로젝트에 관심 없는 사람들이 쏟아내는 다량의 낮은 가치 “기여”에 쉽게 파묻힘 - 마약 비유가 꽤 적절함. 처음에는 “초인적 능력을 얻었다”는 느낌이 오고, 그 뒤에는 “아, 내가 난장판을 만들었네”라는 숙취가 옴 특히 AI의 **아첨 성향** 때문에 계속 “좋은 아이디어네요!”라고 하는데, 내 아이디어 대부분이 대단하지 않다는 건 잘 알고 있음 아이들과 함께 있으면서 휴대폰으로 바이브 코딩을 한다는 식의 얘기를 보면 거의 강박처럼 들리기도 함 - 오랫동안 빠르게 움직이는 것이 큰 **해자**였지만, 이제 빠르게 움직이는 건 쉬워졌음. 새 해자는 품질일 수 있음 애초에 오픈소스에서 빠르다는 건 큰 의미가 없었고, 그럴 만한 이유가 있었음 - 나도 이 관점으로 많이 돌아섰음. 현재 세대의 AI 도구는 산출물을 실제로 쓰려 하면 아직 한참 부족해 보임 일을 하거나 새 프로젝트를 시작할 때 너무 쉽게 AI에 손이 가는 **도파민 구조**도 문제임 지금은 Claude부터 찾기보다 대부분의 코드를 손으로 쓰는 쪽을 다시 선호하도록 뇌를 재훈련하려고 함. 이게 일시적 단계인지, 아니면 LLM 익명 모임 같은 게 필요해질지는 시간이 말해줄 듯함 - 모든 코드와 디지털 산출물이 곧 AI로 작성될 거라는 가정은 AI 업체들이 삽을 팔기 위해 믿게 만들고 싶었던 얘기임. 그 가정이 망상이라는 걸 깨닫고 나면 양립이 어려운 것도 아님 - **AI 없는 소프트웨어**를 모아 둔 목록들이 있음. 시간이 지나며 어떻게 바뀌는지 색인이나 그래프로 보면 좋겠음 [https://codeberg.org/brib/slopfree-software-index]() [https://noai.starlightnet.work/list.html]() - Hacker News에 올라온 GitHub 저장소 중 **AI 작성 흔적**이 없는 것만 보여주는 필터를 만들었음 [https://hcker.news/?ai=exclude&include_domains=github.com]() - 흥미로운 시도임. 이런 목록의 기준이 되는 이유가 궁금함 기능적 이유로는 no-AI 정책이 잘 떠오르지 않음. 누가 만들었든 무엇이 만들었든 실행되면 실행되는 것임 AI 생성 쓰레기를 피하더라도 필터를 통과하는 사람 생성 또는 사람+AI 생성 쓰레기까지 피할 수는 없음 그래도 출처, 책임성, 작업 증명, 사람들이 직접 코드를 쓰도록 장려하는 것, 인간이 코드베이스를 발전시키는 방식을 실증적으로 추적하는 것 같은 **비기능적 이유**는 충분히 떠올릴 수 있음 - “PR에 대한 피드백이 미래의 관리자가 될 수도 있는 사람을 멘토링하는 데 쓰이지 않고 기계에 흡수될 뿐이라면, 자유 시간을 PR 리뷰에 쓰는 걸 정당화하기 훨씬 어려워진다”는 Foundation의 말이 핵심을 찌름 - Zig의 **contributor poker**가 점점 더 선견지명처럼 들림 - 더 나쁜 건 그 피드백이 아마 다음 LLM 학습에 들어간다는 점임. 결국 AI 회사들을 위한 또 다른 **무료 노동**이 됨 - 이해가 안 된다면 이것들을 보면 됨 [https://github.com/godotengine/godot/pull/115280]() [https://github.com/godotengine/godot/pull/116410]() AI 시대 전에도 리뷰할 PR이 너무 많아 힘들던 프로젝트에서 이런 것까지 계속 처리하라고 하는 건 관리자에게 공정하지 않음 그래서 정책의 진짜 큰 변화는 **신규 기여자**가 큰 기능이나 리팩터링을 맡을 수 없게 한 부분임 - 첫 번째 예시는 AI 주도였다는 점뿐 아니라 그 사람이 어리다는 점도 있음 저장소에 남은 정보만으로 별칭과 소셜 계정을 찾을 수 있었고, 아직 10대 초반도 안 된 아이였음. 문제나 관련된 사회적 구조를 이해하기 위한 기초 지식이 아직 없는 상태로 보임 - “이 기여는 실제 오픈소스 기여를 해야 하는 대학 수업 프로젝트의 일부입니다”라니, 그 대학은 정말 어리석음. 어떤 대학이 학생들에게 오픈소스 프로젝트를 스팸하게 만드는지 알 방법이 있을까 - 정말 이상함. 그 기여자의 실제 동기가 뭘까 - **Brandolini의 법칙**이 그대로 작동하는 사례임 헛소리를 반박하는 데는 만들어내는 것보다 10배 더 많은 노력이 듦. 코드 리뷰는 반박이고, 명제의 정확성을 검증하는 것도 마찬가지임 명제를 생성하는 건 쉽지만, 반박하려면 참거짓을 증명하거나 모순을 찾아야 함. 시간이 부족한 오픈소스 관리자들의 에너지가 불필요하게 낭비되니, 에너지를 아껴 생산적으로 쓰자는 데 전적으로 동의함 - AI가 업계에서 가장 비싼 자원 중 하나를 우연히 찾아냈음. 바로 본업을 마친 뒤 저녁에 오픈소스를 관리하는 사람들의 **자유 시간**임 - Foundation은 늘 사실이었지만 AI가 전면에 드러낸 점을 짚었음. AI를 포함한 어떤 기여자든 앞으로 그 패치를 유지보수할 수 없을 가능성이 있음 핵심은 AI 사용 자체가 아니라, 제출자가 자신이 무엇을 내는지 이해하지 못한다는 냄새 중 하나라는 점임. 변수명 관례를 깨거나, 건드리면 안 되는 API를 바꾸거나, 미숙한 언어 실수를 하는 것 모두 패치가 동작하더라도 거절할 이유가 될 수 있음 우회 방법으로는 AI 때문에 PR을 거절한다고 표시한 뒤, 작성자에게 특히 자랑스러운 부분을 하나 짚고 AI 텍스트 벽이 아니라 자기 말로 무엇을 하고 왜 좋은지 설명하게 할 수 있음. 작성자가 AI에는 없는 취향과 의견을 보여줘야 함 - 2026년의 AI는 의견처럼 보이는 텍스트를 충분히 지어낼 수 있음. 이 방식으로는 **AI와 사람 작성자**를 구분하는 데 도움이 되지 않음 - 여기서 많은 사람이 실제 정책을 읽기보다 제목에 반응하는 느낌임. 정책에는 PR 리뷰를 **신규 기여자 훈련**과 잠재적 미래 관리자 발굴에 쓴다는 점이 중요한 이유라고 되어 있음 AI 기여의 품질과 무관하게, 이 부분은 반박하기 어려워 보임 AI가 오픈소스 기여나 유지보수 개념 전체를 불필요하게 만들 거라고 믿는다면 예외겠지만, 그렇다면 Godot에 PR을 보내기보다 엔진을 포크해서 에이전트들이 작업하게 하는 편이 더 맞을 듯함 - AI 기여자들은 정말 자신들이 도움을 준다고 생각하는 걸까. 그런 “작업”으로 프로젝트를 망치고 있다는 걸 모르는 걸까 아무도 원하지 않고 거절당할 것에 왜 돈을 쓰는지 이해가 안 됨. 취미가 없는 건가, 아니면 만든 사람이 잊어버려서 자유롭게 돌아다니는 **OpenClaw 인스턴스**들이 자기 멋대로 움직이는 건가 - FOSS 기여가 순전히 자기 문제 해결, 이타심, 호기심으로만 움직이던 시대는 지났음. 회사들이 채용 때 지원자의 GitHub 페이지를 보기 시작한 지 10년도 넘었음 이런 사람들은 주요 FOSS 프로젝트 기여를 **이력서 부풀리기**로 수확하고 있음. 취약점 보고에서도 같은 일이 벌어짐 대량 생성자들이 진심으로 돕고 있다고 생각할 수도 있고, 자기 “기여”가 프로젝트에 순손해라는 걸 알 수도 있음. 하지만 직접적인 경제적 동기가 있고 처지가 불안정하면 외부효과는 우선순위에서 밀림 - “AI 기여자”에도 정도가 있음. 최근 Rust로 작성된 오픈소스 도구에서 드문 경계 사례를 발견했는데, 내가 익숙하지 않은 언어라 깔끔하고 Rust다운 작은 변경을 하려면 일주일 이상 걸렸을 것임 Claude는 1시간 만에 해냈고, 나는 3~4번 다듬으며 텍스트 벽을 줄이고 원 프로젝트 스타일에 맞췄음. 대안은 그냥 덮어두거나 이슈만 열어 관리자에게 부담을 넘기는 것이었음 그래서 나는 도움을 줬다고 생각함. 이 경계 사례도 내 취미인 홈랩을 만지다가 발견했음 - AI를 써서 기여해 봤음. Brew와 far2는 내 작업을 받아들였고, KDE spectacle 관리자는 답하지 않았음 두 PR 모두 작았고 사람 PR과 다르지 않았음. 여전히 가치 있는 추가였다고 믿고, 일부 관리자도 그렇게 본 것이 분명함 - 예술에서의 AI 사용과 어느 정도 비슷함. 사람들은 쓰고 싶어 하는 게 아니라 “썼다”는 상태와 거기서 온다고 생각하는 **사회적 지위**를 얻고 싶어 함 코딩하거나 제품을 더 좋게 만들고 싶은 게 아니라, 세부를 이해하지 않아도 “코드 줄 수”, “커밋”, 예쁜 GitHub 녹색 프로필을 원함