AI가 짠 코드가 기술 심사를 통과했는데 거부당했다 — Node.js AI 코드 금지 청원의 경고
AI 코딩 도우미 Claude Code로 작성된 Node.js 핵심 코드가 9명의 리뷰어 승인과 93% 테스트 커버리지를 달성했지만, 47명의 개발자가 AI 코드 금지 청원에 서명했습니다. 품질이 아니라 원칙의 문제입니다.
AI 코딩 도우미로 작성한 코드가 기술 심사에서 9명의 핵심 개발자 승인을 받았습니다. 테스트 커버리지(코드가 제대로 작동하는지 확인하는 비율)는 93%입니다. 그런데 47명의 개발자가 이 코드를 '받아들이면 안 된다'는 청원에 서명했습니다. 코드의 품질이 아니라, AI가 짠 코드를 핵심 인프라에 넣는 것 자체가 문제라는 겁니다.
Claude Code로 짠 가상 파일 시스템, 무엇이 문제였나
Node.js는 전 세계 웹사이트와 서버 수억 개를 구동하는 핵심 프로그램입니다. 넷플릭스, 우버, 링크드인 등이 Node.js 위에서 돌아갑니다. 이 프로그램의 핵심 코드에 변경을 가하려면 여러 전문가의 검토를 통과해야 합니다.
올해 1월, Node.js의 핵심 기여자이자 인기 웹 프레임워크 Fastify의 창시자인 Matteo Collina가 PR(코드 변경 요청) #61478을 제출했습니다. 가상 파일 시스템(node:vfs)을 Node.js에 추가하는 작업으로, 16개 파일에 걸쳐 약 9,100줄의 새로운 코드가 포함됐습니다. 총 125개의 커밋(코드 변경 기록)이 쌓였고, 청원 측은 전체 변경 규모를 1만 9천 줄로 추산합니다.
문제는 코드의 품질이 아니었습니다. PR 설명에 달린 한 줄의 고백이 논쟁을 촉발했습니다:
"저는 이 PR을 만드는 데 상당한 양의 Claude Code 토큰을 사용했습니다. 모든 변경 사항은 직접 검토했습니다."
— Matteo Collina, PR #61478 설명 중
Collina는 Node.js 생태계에서 존경받는 인물입니다. Fastify(Node.js에서 가장 빠른 웹 서버 프레임워크 중 하나)를 만들었고, Node.js 핵심 코드에 수년간 기여해왔습니다. 그런 전문가가 AI 도구를 활용하고, 결과물을 직접 검토했다고 밝힌 것입니다.
"인프라 코드는 사람이 한 줄씩 이해해야 한다" — 청원의 세 가지 논점
3월 18일, Fedor Indutny가 "no-ai-in-nodejs-core"라는 이름의 깃허브 저장소를 열었습니다. Indutny는 Node.js의 기술 운영 위원회(TSC) 명예 멤버로, Node.js 초창기부터 핵심 코드를 작성해온 인물입니다. TLS(암호화 통신) 모듈 등 보안에 민감한 코드를 직접 만든 장본인이기도 합니다.
청원의 핵심 주장은 세 가지입니다:
1. 재현 가능성의 문제 — AI가 생성한 코드는 같은 질문을 넣어도 매번 다른 결과가 나옵니다. 다른 개발자가 코드를 검증하려면 유료 AI 구독이 필요한데, 이는 오픈소스의 '누구나 참여할 수 있다'는 원칙에 어긋납니다.
2. 인프라의 무게 — Node.js는 수백만 대의 서버에서 돌아갑니다. 한 줄의 버그가 인터넷 전체에 영향을 줄 수 있습니다. '수작업으로 한 줄씩 작성되고, 사람이 완전히 이해한 코드'만이 이 무게를 견딜 수 있다는 주장입니다.
3. 커뮤니티 신뢰 — Node.js의 명성은 수천 명의 개발자가 자발적으로 기여한 고품질 코드 위에 세워졌습니다. AI 코드를 허용하면 이 신뢰가 흔들릴 수 있다는 우려입니다.
청원에는 프로그래밍 언어 Zig의 창시자 Andrew Kelley, 데이터베이스 프로젝트 Apache CouchDB의 의장 Jan Lehnardt, Node.js 핵심 기여자 Bryan English, 자바스크립트 표준화 위원회 전문가 Jamie Kyle 등 47명 이상이 이름을 올렸습니다.
9명은 승인했고, 47명은 서명했다
이 논쟁이 흥미로운 이유는 코드 자체는 기술적으로 높은 평가를 받았다는 점입니다.
✅ 코드를 승인한 쪽
• 9명의 핵심 리뷰어가 코드를 승인
• 테스트 커버리지 93% 달성
• 63개의 👍 반응, 35개의 🎉 반응
• "정말 인상적인 작업입니다. 훌륭합니다!" — Ethan Arrowood (Node.js 핵심 기여자)
❌ 코드를 거부하는 쪽
• 47명이 AI 코드 금지 청원에 서명
• 12개의 👎 반응
• "기계가 만든 코드는 인프라의 가치를 희석한다"
• OpenJS 재단은 '규정 위반 아님'이라 판단했지만, 청원 측은 '그게 핵심이 아니다'라고 반박
PR 토론은 한때 과열되어 관리자가 댓글을 일시적으로 잠그기도 했습니다. 기술적 리뷰와 AI 정책 논쟁이 뒤섞이면서, 관리자는 "기술적 내용에 집중해달라"고 요청했습니다.
이 갈등의 본질은 'AI가 짠 코드의 품질'이 아니라 'AI 코드를 허용하는 원칙'입니다. 코드가 아무리 좋아도, AI가 만들었다는 이유만으로 거부해야 하는가? 아니면 결과물이 좋으면 과정은 중요하지 않은가?
AI 코드를 둘러싼 오픈소스 전쟁, 어디까지 왔나
이 논쟁은 Node.js만의 이야기가 아닙니다. 최근 몇 주 동안 여러 대형 오픈소스 프로젝트에서 비슷한 갈등이 터져 나왔습니다:
Django(파이썬 웹 프레임워크) — 핵심 기여자가 'AI가 만든 코드가 오픈소스를 병들게 하고 있다'고 경고했습니다. AI 기여물의 품질이 낮아 검토 시간만 낭비된다는 지적입니다.
GitHub 봇 트랩 — 일부 프로젝트 관리자가 기여 안내 파일에 함정 문구를 넣었더니, 코드 기여의 절반이 AI 봇이었다는 사실이 드러났습니다.
하지만 Node.js의 사례는 한 단계 더 나아갑니다. Django와 GitHub 봇 트랩은 'AI 코드의 품질이 낮다'는 문제 제기였습니다. 반면 Node.js 청원은 '품질이 좋아도 AI 코드를 받으면 안 된다'는 원칙적 입장입니다. 코드의 '내용'이 아니라 '출처'를 문제 삼는 것이죠.
AI 코딩 도구를 쓰는 모든 사람에게 던지는 질문
이 논쟁은 AI 코딩 도구를 사용하는 모든 사람에게 실질적인 시사점이 있습니다:
• AI가 짠 코드를 팀에 제출할 때 — '직접 검토했다'는 말만으로는 충분하지 않을 수 있습니다. 코드의 모든 줄을 왜 이렇게 짰는지 설명할 수 있어야 합니다.
• 오픈소스에 기여할 때 — 프로젝트마다 AI 코드 정책이 다릅니다. 기여 전에 해당 프로젝트의 방침을 확인하는 것이 좋습니다.
• AI 도구의 '생산성'을 믿을 때 — 빠르게 코드를 만들 수 있지만, 그 코드의 책임은 온전히 제출자의 몫입니다. Matteo Collina처럼 검증을 거쳐도, 원칙의 벽에 부딪힐 수 있습니다.
PR #61478은 현재 초안(Draft) 상태로, 최종 결정은 아직 내려지지 않았습니다. 하지만 이 논쟁은 이미 오픈소스 세계에 피할 수 없는 질문을 던졌습니다 — AI가 만든 코드의 기준은 '무엇을 만들었느냐'인가, '어떻게 만들었느냐'인가?
관련 콘텐츠 — Easy클코로 AI 시작하기 | 무료 학습 가이드 | AI 뉴스 더보기