---
title: "Zig이 LLM 기여를 막는 이유: “PR이 아니라 사람에 베팅한다”"
published: 2026-04-30T02:15:47.000Z
canonical: https://jeff.news/article/1984
---
# Zig이 LLM 기여를 막는 이유: “PR이 아니라 사람에 베팅한다”

Zig 프로젝트는 이슈, PR, 버그 트래커 댓글까지 LLM 사용을 금지하는 강한 정책을 유지하고 있다. 핵심 논리는 코드 품질 문제가 아니라, 오픈소스 리뷰가 새 기여자를 키우는 투자라는 점이다. 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 언어 자체에 영향을 줄 수 있는 사안이라는 것

> [!IMPORTANT]
> 여기서 핵심은 “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 도구 찬반보다 오픈소스 운영 모델에 가까워요. 유지보수자가 부족한 프로젝트일수록 “좋은 패치 하나”보다 “앞으로 계속 믿고 맡길 사람 하나”가 더 큰 자산이 될 수 있거든요.

## 핵심 포인트

- Zig은 이슈, PR, 버그 트래커 댓글에서 LLM 사용을 금지한다
- Bun은 Zig 포크에서 컴파일 성능을 4배 개선했지만 LLM 작성 기여 금지 때문에 업스트림 계획이 없다고 밝혔다
- Zig 쪽 논리는 “기여물보다 기여자”를 중시하는 오픈소스 운영 철학에 가깝다
- LLM이 만든 PR은 리뷰어의 시간이 새 기여자 육성으로 이어지지 않는다는 게 핵심 문제다

## 인사이트

이 논쟁은 “AI가 코드를 잘 짜냐”보다 “오픈소스 유지보수자의 시간을 어디에 써야 하냐”에 더 가깝다. 한국 개발자 입장에서도 회사 코드 리뷰와 오픈소스 기여 문화에 바로 연결되는 꽤 현실적인 질문이다.