Godot, AI 작성 코드 기여를 더 이상 받지 않기로 함

 (pcgamer.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 오픈소스 게임 엔진 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 도구가 매일 바뀌고 있어 보수적인 정책을 유지하되, 변화에 따라 다시 평가하겠다고 밝힘

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 정책은 공정함. 장황한 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 녹색 프로필을 원함
답변달기