Zig의 반 AI 기여 정책, HN이 문화전쟁보다 유지보수 시간표로 읽은 이유

Zig의 반 AI 기여 정책을 HN은 이념 선언보다 유지보수 시간표로 읽었다. 이 글이 크게 퍼진 이유도 거기에 있다. 이 정책은 코드 품질 일반론을 늘어놓지 않는다. 부족한 자원이 무엇인지부터 딱 잘라 말한다. 부족한 건 코드가 아니라 리뷰어의 시간이고, 그 시간은 새 사람을 믿을 수 있는 기여자로 키우는 데 써야 한다는 판단이다.

정책 자체는 매우 엄격하다. LLM이 만든 이슈, PR, 버그 트래커 댓글, 번역 댓글까지 받지 않는다. Simon Willison이 정리한 내용을 보면 Zig Software Foundation의 커뮤니티 담당 Loris Cro는 리뷰를 장기 투자로 설명한다. Zig가 PR을 읽는 이유는 당장 패치 하나를 더 먹기 위해서가 아니다. 프로젝트가 어떻게 돌아가는지 가르치고, 맥락을 공유하고, 시간이 갈수록 더 믿을 수 있는 사람을 늘리기 위해서다. 겉보기에는 완성도가 높아 보이는 LLM 보조 PR도 이 순환을 끊는다. 유지보수자는 시간을 쓰지만, 다음 달에도 독립적으로 코드를 다룰 사람을 얻지 못할 수 있다.

HN이 붙잡은 것도 바로 이 대목이다. 상위 댓글 다수는 AI를 둘러싼 도덕 논쟁으로 흐르지 않았다. 오히려 자원 배분 문제에 가까웠다. 패치가 대부분 기계 산출물이라면, 유지보수자가 왜 제출자의 산출물을 길게 리뷰해야 하느냐는 질문이 나왔다. 차라리 필요하면 유지보수자가 직접 도구를 돌려 초안을 만드는 편이 낫지 않느냐는 식이다. 동시에 Bun 쪽 업스트림 갈등을 전부 AI 금지 탓으로만 보면 안 된다는 지적도 붙었다. 어떤 변경은 작성 방식과 별개로 언어 설계와 아키텍처 부담이 크다는 반론이다.

이 논의가 길게 간 이유는 더 큰 역설을 건드렸기 때문이다. AI 보조를 폭넓게 허용하는 정책과 새 기여자를 환영하는 정책이 이제 서로 다른 방향으로 당길 수 있다. 기계 보조 제출물이 밀려들수록, 유지보수자는 오히려 초보 기여자에게 더 차갑게 굴 가능성이 커진다. 긴 리뷰가 미래의 유지보수자를 만들지 못하기 때문이다. Zig는 반대쪽을 택했다. 당장의 처리량은 줄더라도, 인간의 신뢰와 맥락 축적, 프로젝트 기억을 남기는 리뷰 문화를 고르겠다는 선택이다.

그래서 HN은 이 이야기를 Zig만의 특수 사례로 보지 않았다. 많은 유지보수자가 이미 몸으로 느끼고 있는 문제를 Zig가 문장으로 못 박았다고 봤다. 논쟁의 핵심은 코드 품질만이 아니다. PR이 애초에 무엇을 위한 절차인가라는 질문이다.