Zig는 왜 AI 생성 코드 기여를 거부할까 — 오픈소스 거버넌스의 새 논쟁

"AI가 짠 코드는 받지 않습니다"

시스템 프로그래밍 언어 Zig가 최근 공식적으로 "AI가 생성한 코드 기여는 받지 않는다"는 정책을 명문화했어요. 그리고 이게 왜 그저 보수적인 정책이 아니라 합리적인 결정인지를 메인테이너인 Andrew Kelley가 직접 설명했고, Simon Willison(파이썬 Django 공동 창시자이자 LLM 분야의 영향력 있는 블로거)이 이걸 정리해 옮겨 적은 글이 이번 화제예요.

요즘 GitHub에 가보면 Copilot이나 Cursor로 만든 PR이 정말 많이 들어와요. 그중엔 진짜 좋은 것도 있지만, 메인테이너 입장에서 "이걸 검토하느니 차라리 내가 다시 짜는 게 빠르겠다" 싶은 것도 적지 않거든요. Zig는 그 피로도가 임계점을 넘었다고 판단한 거예요.

왜 받지 않는다고 못 박았을까

Kelley의 핵심 논리는 "기여는 단순히 코드를 받는 게 아니라, 그 코드를 평생 책임질 사람을 받는 일"이라는 거예요. 오픈소스 프로젝트에서 PR 하나가 머지되면, 그건 영원히 코드베이스에 남아서 누군가 유지보수해야 하는 자산이 돼요. 그런데 AI로 만든 PR은 보내는 사람조차 코드를 깊이 이해하지 못한 채 보내는 경우가 많아요. 리뷰어가 "왜 이렇게 짰어요?"라고 물었을 때 답을 못 하면, 결국 그 부담은 메인테이너가 떠안게 되는 구조예요.

게다가 Zig는 컴파일러 언어 프로젝트라 한 줄의 의미가 무거워요. 메모리 모델, undefined behavior, 컴파일 타임 평가 같은 미묘한 영역이 가득해서 LLM이 "그럴듯하지만 틀린" 코드를 만들기 딱 좋은 환경이거든요. 정상 컴파일되고 테스트도 통과하지만 사실은 잘못된 추론에 기반한 변경, 이런 게 머지되면 몇 달 뒤에 미궁 같은 버그로 돌아와요. Kelley는 이걸 "지능적인 노이즈"라고 표현했는데, 정말 적절한 비유 같아요.

또 하나 짚는 게 학습/모방의 차이예요. AI를 "공부 도구"로 쓰는 건 환영하지만, AI 출력물을 그대로 PR에 붙여 보내는 건 다른 문제라는 거죠. 전자는 사람이 이해의 주체이고, 후자는 사람이 단순 전달자가 되는 거니까요.

다른 프로젝트들은 어떨까

비슷한 흐름이 다른 곳에서도 보여요. NetBSD는 "AI 생성 코드는 오염된 것으로 간주한다"는 정책을 명시했고, Gentoo는 AI 도구 사용에 보수적인 입장을 밝혔어요. 반대로 cURL의 메인테이너 Daniel Stenberg는 AI 보안 보고서가 너무 많이 들어와서 "가짜 보고가 진짜 보고보다 더 많아졌다"고 공개적으로 불평했고요.

반대편엔 Linux 커널이나 Rust처럼 "도구는 도구일 뿐, 결과물의 품질로 판단한다"는 입장도 있어요. 결국 정책의 차이는 프로젝트의 규모, 메인테이너의 여력, 코드의 위험도에 따라 달라지는 거예요. Zig는 코어 메인테이너 수가 적고 언어 자체가 안전성에 민감하니까 강경한 입장이 자연스러운 선택인 거죠.

한국 개발자에게 주는 시사점

사내 코드베이스나 사이드 프로젝트 운영하시는 분들에게 시사하는 바가 커요. "AI 사용을 어떻게 정책화할 것인가"는 더 이상 추상적인 윤리 토론이 아니라 당장 결정해야 하는 운영 이슈가 됐거든요. PR 템플릿에 "이 PR에 AI 생성 코드가 포함되어 있나요?"를 넣을지, 포함된다면 사람이 어떻게 검토했다는 걸 명시할지, 이런 가이드라인이 필요해진 거예요.

오픈소스에 기여하는 분들도 이걸 읽어볼 가치가 있어요. AI에게 코드를 받아서 그대로 PR을 만드는 게 점점 더 환영받지 못하는 행위가 될 수 있거든요. 적어도 내가 그 코드 한 줄 한 줄을 설명할 수 있는 수준은 되어야 한다는 거예요. 이건 결국 "AI를 어떻게 잘 활용할 것인가"라는 본질로 돌아오는 질문이고요.