AI 보조 개발이 이미 현실이 된 지금, 오픈 소스 커뮤니티는 책임, 투명성, 그리고 DCO 같은 기존 기여 규칙이 AI 시대에도 어떻게 적용되는지 합의점을 찾아가고 있다.
AI 보조 개발은 이미 현실이며, 오픈 소스 커뮤니티는 이를 어떻게 관리할지 함께 해답을 찾아가고 있습니다.
이제 많은 주요 프로젝트와 조직이 몇 가지 핵심 아이디어에 동의합니다. 사람은 끝까지 책임을 져야 하고, 공개적으로 투명하게 하는 것이 신뢰를 쌓으며, Developer Certificate of Origin(DCO) 같은 기존 기여 규칙은 여전히 중요하다는 것입니다. Linux 커널 커뮤니티, Red Hat 법무팀, OpenJS Foundation 모두 비슷한 결론에 도달했습니다. AI는 개발을 도울 수 있지만, 제출하는 것에 대한 책임은 여전히 사람에게 있습니다.
이것이 오늘날 소프트웨어 개발을 실제로 형성하고 있는 현실입니다. 이제 질문은 AI를 써야 하느냐가 아니라, 어떻게 책임 있게 사용할 것이냐로 바뀌었습니다.
그런 배경에서, 최근 Node.js 프로젝트에서 진행된 한 논의는 이러한 원칙이 실제로 어떻게 적용되는지 살펴보았습니다.
PR #61478는 Node.js 코어에 Virtual File System을 추가하는 내용으로, 약 80개 파일에 걸쳐 거의 19,000줄에 달합니다. 저는 2025년 크리스마스 기간에 Claude Code로 이를 만들었고, 처음부터 그 사실을 공개했습니다. AI는 모든 fs 메서드를 구현하는 일, 테스트 커버리지 구성, 문서 생성 같은 반복 작업을 처리했습니다. 저는 아키텍처와 API 설계에 집중했고, 모든 줄을 직접 확인했습니다. AI가 없었다면, 창업자이자 부모로서의 본업을 병행하면서 이것을 휴일 사이드 프로젝트로 해내는 것은 불가능했을 겁니다. 애초에 일어나지 않았을 일이었고, 이전에도 늘 그랬습니다.
리뷰 과정에서 한 Node.js collaborator가 코드 품질이나 아키텍처가 아니라, AI 보조 기여가 Node.js 기여자가 PR을 열 때마다 서명하는 법적 인증인 DCO 1.1의 요구 사항을 충족할 수 있는지에 대해 우려를 제기했습니다. 그는 또한 Node.js TSC가 코어 프로젝트에서 AI 보조 개발을 허용하는 데 반대하도록 투표해 달라는 개인 청원도 시작했습니다.
그 collaborator의 주장은 단순했습니다. DCO는 기여자가 코드를 제출할 권리가 있음을 주장하도록 요구하는데, AI가 생성한 코드에서는 그 출처(provenance)가 불분명할 수 있다는 것입니다.
구체적으로, Claude 같은 AI 시스템이 라이선스가 없거나 호환되지 않는 라이선스의 소스 코드를 섞어 학습했을 수 있어, 기여자가 규정 준수를 확신하며 주장하기 어렵다는 우려였습니다. 대규모 언어 모델이 때때로 학습 데이터의 일부를 재현할 수 있다는 연구는 의도치 않은 복제에 대한 우려에 힘을 실어주었습니다.
그의 주장은 여기서 더 나아갔습니다. 어떤 것을 “보조 도구(assistive tool)”라고 부른다고 해서 그 결과물이 자동으로 라이선스상 깨끗해지는 것은 아닙니다. 제시된 비유는 cp -rf였습니다. cp -rf를 사용해 GPL 라이선스 코드를 기여물에 복사하는 것이 DCO에 부합한다고 주장할 사람은 없을 텐데, 복사라는 행위가 기술적으로는 또 다른 “도구”일 뿐이라는 것입니다. 그의 주장에 따르면, 입증 책임은 제출자에게 있습니다. 그것이 DCO의 핵심이라는 것이죠.
이는 업계가 여전히 해결 중인 더 큰 질문을 반영하는 중요한 우려들입니다.
이 논의가 PR에서 진행되는 동안, 여러 주요 조직은 이미 이 질문들에 답하고 있었습니다.
DCO를 만든 Linux 커널 커뮤니티는 AI 보조 기여에 대한 명확한 정책 문서를 갖고 있습니다. 그들의 coding-assistants.rst는 엄격한 human-in-the-loop 프로세스를 요구합니다. AI 에이전트는 Signed-off-by 태그를 추가할 수 없습니다. DCO를 법적으로 인증할 수 있는 것은 사람뿐입니다. 코드를 제출하는 사람은 모든 AI 생성 코드를 검토하고, 라이선스 준수를 확인하며, 자신의 sign-off를 추가해야 합니다. 또한 AI 사용은 Assisted-by 태그로 공개해야 합니다. DCO의 창시자들 스스로도 이것이 여전히 적용된다고 말합니다. 사람이 서명하고 전적인 책임을 진다는 것입니다.
Red Hat의 CTO Chris Wright와 법률 자문 Richard Fontana는 DCO 질문을 직접 다룬 상세 분석을 발표했습니다. 그들은 DCO가 기여의 모든 줄이 기여자의 개인적인 창작 표현이어야 한다고 해석된 적이 없다고 설명했습니다. 많은 기여는 일상적이고 저작권 대상이 아닌 자료를 포함하며, 개발자들은 여전히 그에 대해 sign off를 합니다. DCO의 진짜 요점은 책임입니다. 공개와 사람의 감독이 있다면, AI 보조 기여는 DCO의 정신과 완전히 양립할 수 있습니다.
Red Hat은 또한 제가 설득력 있게 느낀 역사적 지점도 제시했습니다. 수년 동안, 오픈 소스를 신중하게 사용하는 상업 사용자들은 “세탁된(laundered)” 코드—불명확하거나 문제가 있는 조건 아래 저작권 자료를 숨길 수 있는 기여—를 걱정해 왔습니다. 시간이 지나며 그런 두려움은 대부분 근거가 약하다는 것이 드러났습니다. AI 보조 기여도 숨겨진 저작권 자료를 포함할 수 있지만, 이는 관리 가능한 위험이며 오픈 소스가 이미 마주했고 해결해 온 도전과 크게 다르지 않습니다.
OpenJS Foundation( Node.js의 법적 주체)도 PR에 직접 의견을 냈습니다. Executive Director Robin Ginn은 재단이 법률 자문과 확인했으며 AI 보조 기여에 대한 DCO 적용에 문제가 없다는 점을 확인했습니다. 또한 이 입장을 공식 문서로 남기겠다고 약속했습니다.
서로 독립적인 세 조직—DCO의 창시자들, 세계 최대급 오픈 소스 법무팀 중 하나, 그리고 Node.js 재단—이 모두 같은 답에 동의합니다. AI는 DCO를 깨지 않습니다. 중요한 것은 책임입니다.
DCO는 코드가 어떻게 작성되었는지에 초점을 맞춘 적이 없습니다. 기여자가 그 코드를 제출할 권리가 있는지에 관한 것입니다.
AI가 생성한 코드에 잘못된 라이선스의 자료가 포함되어 있다면, 손으로 코드를 복사했을 때와 마찬가지로 sign off한 기여자에게 책임이 있습니다. 이런 의미에서 AI는 특별한 예외가 아니라, 그저 또 하나의 도구일 뿐입니다. 컴파일러는 개발자가 항상 추적하지 못하는 방식으로 코드를 바꿉니다. 템플릿 생성기는 자체 로직으로 결과물을 만듭니다. Stack Overflow 답변은 라이선스를 깊게 생각하지 않은 채 코드베이스에 자주 복사됩니다.
우리는 늘 DCO에 의존해 왔습니다. 코드를 제출하는 사람이 책임을 집니다.
더 큰 맥락도 있습니다. 다른 많은 OSS 메인테이너와 마찬가지로, 저는 최근 OpenAI와 Anthropic 양쪽에서 무료 구독 형태로 오픈 소스 후원을 받았습니다(앞서 언급한 PR은 제가 직접 비용을 낸 구독을 사용해 만들었습니다). 이 회사들은 오픈 소스가 마주한 과제를 알고 있으며, 생태계를 강하게 유지하는 데 도움을 주고자 합니다. 또한 그들은 우리의 코드—Node.js, Fastify, Undici, 그리고 수천 명 오픈 소스 기여자의 작업물—로 모델을 학습했습니다. 그들의 모델이 배운 프로젝트에 다시 환원하는 것은 중요하고 적절한 कदम입니다. AI 회사들이 오픈 소스에서 이익을 얻고 다시 투자하는 이런 관계는 생태계를 건강하게 유지하는 데 도움이 됩니다. 법적 질문을 해결해 주지는 않지만, 주요 AI 연구소들이 오픈 소스를 단지 학습 데이터의 원천이 아니라 파트너로 본다는 점을 보여줍니다.
AI가 가져오는 진짜 변화는 법적 변화가 아니라 운영상의 변화입니다. AI는 병목을 코드 작성에서 코드 리뷰로 옮깁니다.
저는 몇 달 동안 이렇게 말해 왔습니다. human in the loop은 결함이 아니라 기능입니다. AI는 병목을 판단과 리뷰로 이동시킵니다. 코드를 리뷰하고, 이해하고, 책임지는 사람이 가장 중요한 일을 하고 있습니다.
이 논쟁은 그 주장을 구체적인 현실로 만들어 줍니다.
한 가지를 분명히 하고 싶습니다. 저는 그 VFS 구현을 만들었습니다. Claude Code의 도움을 받았다는 이유로 제가 만들지 않았다고 말하는 것은 정확하지 않습니다. 제 할머니는 모든 이탈리아 가정의 주방에 있던 파스타 메이커 “Nonna Papera”로 수제 파스타를 만들곤 했습니다. 누구도 그것이 할머니의 파스타가 아니라고 말하지 않았을 겁니다. 할머니는 밀가루를 고르고, 달걀을 고르고, 두께와 모양을 선택했습니다. 도구는 손을 도와줬을 뿐입니다. 파스타는 할머니의 것이었습니다.
저는 아키텍처를 선택했습니다. PR에 코멘트한 모든 리뷰어의 피드백을 바탕으로 API를 다듬었습니다. 설계 결정을 내렸고, AI가 도입한 문제를 찾아 고쳤으며, 코드의 모든 부분이 무엇을 하고 왜 그렇게 하는지 이해합니다. 저는 DCO에 서명했습니다. 제 이름이 거기에 있습니다. 버그가 있다면 제 책임입니다. 라이선스 문제가 있다면, 준수를 인증한 사람은 저입니다.
여기서 한 가지 질문을 던져봅시다. 리뷰어들은 어떨까요? PR을 리뷰하고 변경을 제안하며 엣지 케이스를 잡아내고 최종 구현을 함께 만들어 간 collaborator들은 이 작업의 공동 저자가 아닌가요? 그들은 언제나 그랬습니다. Node.js 역사상 모든 PR에서요. 누구도 리뷰어가 첫 버전을 쓰지 않았다는 이유로, PR에 대한 리뷰어의 기여가 “진짜”인지 의심한 적이 없습니다. 리뷰 과정은 오픈 소스가 품질을 만드는 방식입니다. 첫 초안이 새로운 종류의 도구에서 나왔다는 이유로 그 사실이 바뀌지는 않습니다.
그것이 human in the loop입니다. 단지 아이디어로서가 아니라, 우리가 실제로 하는 일로서 말이죠.
해결책은 이미 세 가지 방식으로 윤곽을 드러내고 있습니다.
OpenJS Foundation은 사람이 책임을 지는 한 AI 보조 기여가 DCO와 양립 가능하다는 입장을 공식화하고 있습니다. 이는 Node.js 기여자들에게 명확한 법적 근거를 제공합니다.
Node.js TSC는 어떤 공개(disclosure) 및 귀속(attribution) 관행을 채택할지 논의할 것입니다. 이의 제기가 있었던 만큼, 투표로 넘어갈 것입니다. 이것이 Node.js 커뮤니티를 지탱하는 의사결정 프로세스입니다. Linux 커널이 제안한 human-in-the-loop 모델은 탄탄합니다. Assisted-by 태그를 요구하는 것도 좋은 모델입니다. 도구 사용의 투명성은 리뷰어가 검토 강도를 조절하는 데 도움이 되고, 시간이 지나며 신뢰를 쌓습니다.
커뮤니티는 또한 AI 보조 기여에서 “사람이 리뷰한다”는 것이 실제로 무엇을 의미하는지에 합의해야 합니다. 단지 “리뷰했다”라고 말하는 것으로는 충분하지 않습니다. 예를 들어 이런 질문에 답할 수 있어야 합니다. 이 코드가 무엇을 하는지 이해하고 있나요? 설계 선택을 설명할 수 있나요? AI에게 다시 묻지 않고도 피드백에 대응할 수 있나요? 1년 뒤에도 이 코드를 유지보수할 수 있나요? 이것들은 우리가 늘 기여자에게 물어오던 같은 질문입니다. 도구는 바뀔 수 있지만, 사람에 대한 기대는 바뀌지 않습니다.
AI 보조 개발은 단지 미래의 아이디어가 아닙니다. 오늘날 점점 더 많은 전문 소프트웨어가 작성되는 방식의 현실입니다. 공개성, 사람의 리뷰, 명확한 책임이라는 원칙 아래 책임 있게 AI 보조 기여를 받아들이는 법을 배우는 프로젝트는 더 많은 기여자를 끌어들이고, 더 빠르게 움직이며, 계속 관련성을 유지할 것입니다. AI 보조 기여를 금지하는 프로젝트는 당장은 더 안전하다고 느낄지 모르지만, 오픈 소스 소프트웨어에 대한 수요가 커지는 바로 그 시점에 기여자 풀을 제한하게 됩니다. 저는 각 프로젝트가 자체 규칙을 정할 권리를 존중하지만, 성공하는 프로젝트는 사용하는 도구가 아니라 기여의 품질과 기여자의 책임에 집중하는 프로젝트라고 믿습니다.
소프트웨어 개발에서 가장 중요한 역할은 바뀌지 않았습니다. 코드를 쓰는 사람이나 도구가 아닙니다. 그것을 이해하고, 리뷰하며, 책임지는 사람입니다.
그것이 DCO가 강제하도록 설계된 바입니다. 그리고 지금도 여전히 그렇게 작동합니다.
