Zig이 LLM 기여를 막는 이유: “PR이 아니라 사람에 베팅한다”

• Zig 프로젝트는 주요 오픈소스 중에서도 꽤 빡센 반(反)LLM 기여 정책을 갖고 있음

  • 이슈 작성에 LLM 사용 금지
  • 풀 리퀘스트(PR)에 LLM 사용 금지
  • 버그 트래커 댓글도 금지, 심지어 번역용 LLM 사용도 허용하지 않음
  • 영어가 권장되긴 하지만 필수는 아니고, 각자 원하는 번역 도구로 읽으라는 쪽에 가까움

• 이 정책이 다시 주목받은 건 Bun 때문임

  • Bun은 Zig로 작성된 대표적인 JavaScript 런타임이고, 2025년 12월 Anthropic에 인수됨
  • Bun 쪽은 Zig 자체 포크를 운영 중이고, 최근 LLVM 백엔드에 “병렬 의미 분석(parallel semantic analysis)”과 “여러 코드 생성 유닛(multiple codegen units)”을 넣어 Bun 컴파일 성능을 4배 개선했다고 밝힘
  • 그런데 Bun은 이 변경을 Zig 본류에 올릴 계획이 없다고 했음. 이유는 Zig가 LLM이 작성한 기여를 엄격히 금지하기 때문
  • 다만 Zig 코어 기여자 쪽에서는 이 특정 패치가 LLM 문제와 별개로도 바로 받아들이기 어렵다고 설명함. 병렬 의미 분석은 오래전부터 계획된 기능이지만 Zig 언어 자체에 영향을 줄 수 있는 사안이라는 것

• Zig Software Foundation 커뮤니티 부대표 Loris Cro의 설명은 꽤 선명함

  • 성공한 오픈소스 프로젝트는 어느 순간 처리 가능한 양보다 더 많은 PR을 받게 됨
  • 그럼 유지보수자 입장에서는 완성도 낮은 PR을 거절하고 효율만 챙기는 게 합리적으로 보일 수 있음
  • 그런데 Zig는 그렇게 하지 않고, 새 기여자가 부족한 부분을 채워서 기여를 넣을 수 있도록 돕는 쪽을 택함
  • 이유는 착해서가 아니라 장기적으로 더 똑똑한 선택이라고 보기 때문임

• Zig의 관점은 “기여물보다 기여자”임

  • PR 리뷰의 목적은 새 코드를 하나 더 넣는 데서 끝나지 않음
  • 핵심은 시간이 지나면서 믿을 수 있고, 자신감 있고, 꾸준히 기여할 사람을 만드는 것
  • 첫 PR이 좀 거칠어도 리뷰 과정에서 그 사람이 프로젝트의 사고방식과 품질 기준을 배우면, 나중에는 훨씬 큰 자산이 됨

• LLM 도움을 받은 PR은 이 구조를 깨뜨린다는 게 Zig 쪽 주장임

  • 설령 LLM이 완벽한 PR을 만들어 줬다고 해도, 리뷰어가 그 PR을 검토하는 시간은 새 기여자의 역량 성장으로 이어지지 않음
  • 유지보수자는 코드를 리뷰하는 동시에 사람을 평가하고 키우는데, LLM이 중간에 끼면 그 신호가 흐려짐
  • 결국 “이 사람을 앞으로 믿고 더 큰 일을 맡길 수 있나?”라는 질문에 답하기 어려워짐

• Loris Cro는 이걸 “contributor poker”라고 부름

  • 포커에서 “카드가 아니라 사람을 보고 플레이한다”는 말처럼, 오픈소스에서도 첫 PR의 내용만 보는 게 아니라 그 사람에게 베팅한다는 뜻
  • 코드 한 덩어리보다 장기적으로 프로젝트를 이해하고 책임질 기여자가 더 중요하다는 철학임

• Simon Willison도 이 논리에 꽤 설득됐다는 반응임

  • 만약 PR 대부분이 LLM이 쓴 거라면, 유지보수자가 그 PR을 리뷰하고 토론해야 할 이유가 약해짐
  • 차라리 유지보수자가 자기 LLM을 켜서 같은 문제를 직접 풀어보는 게 낫지 않냐는 질문이 자연스럽게 나옴
  • 이건 오픈소스뿐 아니라 회사 코드 리뷰에도 그대로 들어오는 문제임. “이 사람이 이해한 코드인가, 아니면 생성된 결과물만 들고 온 건가?”라는 질문이 남음

---

기술 맥락

• Zig가 고른 선택은 LLM 작성 기여를 부분 제한하는 게 아니라, 이슈와 PR, 버그 트래커 댓글까지 넓게 막는 방식이에요. 왜냐하면 문제를 코드 생성 품질이 아니라 유지보수 프로세스의 신뢰 신호로 보고 있기 때문이에요.

• 일반적인 프로젝트라면 LLM이 만든 패치를 테스트와 리뷰로 걸러내면 된다고 생각할 수 있어요. 그런데 Zig는 리뷰를 “코드 검수”가 아니라 “기여자가 프로젝트 기준을 배우는 과정”으로 보기 때문에, 누가 실제로 문제를 이해했는지가 중요해져요.

• Bun 사례가 흥미로운 이유는 실제 성능 개선 수치가 꽤 크기 때문이에요. Zig 포크에서 Bun 컴파일이 4배 빨라졌다면 기술적으로는 탐나는 변경인데, Zig 본류 입장에서는 그 변경을 받아들이는 순간 기여 정책과 언어 설계 리스크를 같이 떠안게 돼요.

• 그래서 이 논쟁은 AI 도구 찬반보다 오픈소스 운영 모델에 가까워요. 유지보수자가 부족한 프로젝트일수록 “좋은 패치 하나”보다 “앞으로 계속 믿고 맡길 사람 하나”가 더 큰 자산이 될 수 있거든요.