오픈소스 프로젝트는 왜 AI 기여를 금지할까? QGIS 모라토리엄으로 본 쟁점

오픈소스 AI 기여를 금지하는 프로젝트가 늘어나는 가장 큰 이유는 두 가지예요. 하나는 AI로 빠르게 만든 PR이 사람이 검토할 수 있는 양을 넘어 메인테이너를 지치게 한다는 점이고, 다른 하나는 AI 출력물의 저작권·라이선스 상태를 기여자가 책임지고 인증하기 어렵다는 점이에요. 2026년 10월 기준으로 오픈 GIS 소프트웨어 QGIS는 QEP 408 2.0판을 승인해 qgis/qgis 저장소에 LLM·AI·에이전트 보조 코드 기여를 받지 않기로 했어요. 이 글은 QGIS의 결정 과정과 근거, QEMU·젠투·리눅스 커널 정책과의 차이, 기여자가 확인할 점을 2026년 10월 13일에 읽은 원문 기준으로 정리해요.

QGIS 모라토리엄은 무엇을 금지하나요

정책 본문은 아주 짧아요. QGIS 코드 저장소에 LLM, AI 또는 에이전트의 보조를 받은 코드 기여를 허용하지 않고, 나중에 AI·LLM·에이전트 기반 작업 흐름을 쓴 사실이 드러나면 코드 되돌리기(reversion)와 기여자 권한 제재를 받을 수 있다는 내용이에요. 문서의 버전은 2.0이고 날짜는 2026년 9월 24일, 작성자는 QGIS 프로젝트 기여자들로 표기돼 있어요. 같은 문서의 이전판은 2026년 1월 31일 작성된 AI 도구 사용 정책이었고, 토론 참가자들은 이를 사람이 개입하는 조건의 이른바 human in the loop 정책으로 불렀어요.

이 변경은 GitHub의 QGIS 개선 제안 PR #387로 진행됐어요. PR 제목은 QEP428로 시작하지만 실제 수정 파일은 기존 qep-408 정책 문서예요. 2026년 9월 24일 토론 단계로 열렸고, 10월 5일 투표 단계로 넘어갔으며, 10월 7일 찬성표를 근거로 승인이 선언된 뒤 병합됐어요. 사용자가 QGIS를 쓰는 것이나 외부에서 AI 관련 소프트웨어를 만드는 것을 막는 정책은 아니며, 대상은 QGIS 본체 저장소로 들어오는 코드 기여예요.

QGIS가 강한 금지를 택한 배경

2026년 9월 QGIS 개발자 메일링 리스트에서 제안자는 지금까지의 부드러운 정책이 효과가 없었다며, 일단 안전한 금지를 기본값으로 두고 이후 어떤 형태의 LLM 기여가 받아들여질지 논의하자고 했어요. PR 토론에서는 세 가지 이유가 정리됐어요. 외부 기여자의 AI 사용이 이미 일이 많은 메인테이너에게 감당하기 어려운 압박을 준다는 점, AI로 생산되는 PR의 흐름이 사람이 진지하게 검토할 수 있는 양보다 많아 검토되지 않은 PR이 쌓이거나 충분히 검토되지 않은 코드가 들어갈 위험이 있다는 점, 그리고 QGIS가 사람 사이의 신뢰 네트워크로 유지되는 공동체라는 점이에요.

이전 정책의 실효성에 대한 수치도 토론에 나왔어요. 한 기여자는 이전 정책에서 예정했던 분류 태그 일부는 만들어지지 않았고, AI Assisted 태그가 붙은 PR 약 50건 중 약 40건이 병합되지 않고 닫혔다고 지적했어요. 제안자는 이전 정책이 현실에서 작동하지 않았고 그 과정에서 가치가 큰 기여자를 적어도 한 명 잃었다고 답했어요. AI 보조 PR을 직접 올렸던 한 초보 기여자는 LLM이 복잡한 프로젝트의 버그를 고칠 수 있다는 착각을 주고, 기여자가 스스로 배우지 못해 결국 리뷰어로 성장하지 못한다는 점을 들어 찬성 의견을 남기기도 했어요.

오픈소스 AI 기여 정책은 프로젝트마다 어떻게 다를까요

모든 오픈소스 프로젝트가 같은 이유로 같은 규칙을 두는 것은 아니에요. QGIS는 메인테이너 부담과 공동체 신뢰를 전면에 내세웠고, QEMU와 젠투는 저작권·라이선스와 품질 문제를 더 직접적으로 근거로 들어요. 리눅스 커널은 금지 대신 사람의 책임과 표시 의무를 강조해요. 아래 표는 각 프로젝트의 공식 문서를 2026년 10월 13일 기준으로 읽고 요약한 것이며, 정책은 언제든 바뀔 수 있어요.

QEMU: DCO를 지킬 수 없다는 논리

QEMU의 코드 출처 문서는 모든 기여자가 Signed-off-by 한 줄로 개발자 원산지 증명서(DCO) 1.1을 인증하게 해요. DCO는 기여물을 해당 오픈소스 라이선스로 제출할 권리가 있다는 선언이에요. QEMU는 AI 생성 도구 출력물의 저작권·라이선스 상태가 일반적으로 받아들여진 법적 기반 없이 불분명하고, 학습 데이터에 제한적 라이선스의 자료가 대량 포함되는 경우가 흔하며, 오픈소스만 학습했더라도 QEMU 라이선스와 호환되지 않는 조건이 섞일 수 있다고 설명해요. 그래서 기여자가 DCO 조항을 어떻게 지킬 수 있는지 불분명하다는 이유로 AI 사용이 알려졌거나 의심되는 기여를 거절해요. 다만 API나 알고리즘 조사, 정적 분석, 디버깅처럼 출력물이 기여에 들어가지 않는 사용은 이 정책 대상이 아니라고 명시해요.

젠투와 리눅스 커널: 금지와 책임 표시의 차이

젠투 위원회 AI 정책은 2024년 4월 14일 표결로 자연어 처리 AI 도구의 도움을 받아 만든 콘텐츠의 기여를 명시적으로 금지했어요. 근거로는 각국에서 아직 형성 중인 생성물 저작권 규정, 그럴듯하지만 의미 없는 내용을 만들어 검토자에게 불공정한 노력을 요구하는 품질 문제, 학습 데이터·에너지 사용·스팸 같은 윤리 문제를 들어요. 반면 리눅스 커널의 AI 코딩 어시스턴트 문서는 AI 보조를 전제로 규칙을 정해요. AI 에이전트는 Signed-off-by 태그를 달 수 없고 사람만 DCO를 인증할 수 있으며, 사람 제출자가 모든 AI 생성 코드를 검토하고 라이선스 준수와 전체 책임을 져야 해요. 사용 사실은 Assisted-by 태그로 남기도록 안내해요.

AI 생성 코드 라이선스 문제는 왜 해결이 어려울까요

오픈소스 라이선스는 저작권을 바탕으로 작동해요. 기여자가 자기 코드에 권리를 갖고 그 권리를 프로젝트 라이선스로 내놓아야 GPL 같은 카피레프트 조건이 제대로 성립해요. 젠투 문서가 생성물 사용이 저작권 침해 위험을 만들 수 있을 뿐 아니라 프로젝트의 저작권 주장을 약하게 하고 카피레프트 보장을 무력화할 수 있다고 쓴 이유가 여기에 있어요. 미국 저작권청도 2023년부터 AI 관련 저작권 쟁점을 검토해 보고서를 여러 부로 내고 있으며, 2부는 생성형 AI 출력물의 저작권 인정 문제를, 3부(사전 공개본)는 학습 데이터 문제를 다뤄요. 국가마다 해석이 다르고 논의가 이어지고 있으므로, 프로젝트 입장에서는 법적 결론을 기다리기보다 보수적인 규칙을 택하는 경우가 생겨요.

다만 모든 금지 정책이 저작권만으로 설명되지는 않아요. QGIS PSC 위원은 메일링 리스트에서 정책 문서에 이유를 길게 적으면 세부 해석을 둘러싼 논쟁으로 빠진다며 무엇을 지켜야 하는지만 명확히 하자는 의견을 냈어요. 실제 PR 토론에서 가장 많이 언급된 이유도 법률보다는 리뷰 용량과 공동체 신뢰였어요. 따라서 특정 프로젝트의 정책을 읽을 때는 그 프로젝트가 무엇을 가장 걱정하는지 확인하면 예외의 범위를 이해하기 쉬워요.

남아 있는 쟁점: 범위와 집행

• 범위: 정책 문구의 assisted와 used가 넓어 LLM 자동완성, 오래된 머신러닝 기반 IDE 순위 기능, 설계 아이디어 브레인스토밍, 번역기 사용까지 포함되는지 묻는 의견이 나왔어요.
• 리뷰·보안 용도: LLM을 리뷰 시뮬레이션이나 보안 감사에 쓰는 것도 막히는지에 대한 질문이 있었고, 이 주제는 별도 논의로 다루자는 의견이 나왔어요.
• 문서·이슈: 코드뿐 아니라 이슈, PR 설명, 댓글에도 적용하자는 제안과, 이미 접수된 보안 권고가 AI로 작성되고 있다는 현실적 지적이 함께 나왔어요.
• 집행: 프로젝트는 기여자의 컴퓨터를 들여다볼 수 없으므로 스스로 코드를 썼는지 양심적으로 판단하라는 기준을 제시했어요. 이는 신고 기반 정책이라는 한계와 함께, 발견 시 제재라는 강한 결과를 동반해요.

제안자는 이 정책을 영구 규칙이 아니라 일단 문을 닫고, 자동완성이나 번역처럼 안전하다고 판단되는 사례를 하나씩 별도 제안으로 여는 출발점이라고 설명했어요. 다른 핵심 기여자도 AI 기여가 어떤 형태로든 영원히 금지된다는 뜻이 아니라고 덧붙였어요. 그러니 이 정책을 AI 코딩 도구 전반에 대한 기술적 평가로 읽기보다는, 자원봉사 중심 공동체가 검토 용량을 지키기 위해 고른 운영 규칙으로 보는 것이 정확해요.

기여하기 전에 확인할 단계

1. 1

   저장소의 정책 문서를 찾아요

   CONTRIBUTING 문서, 개발자 문서, 프로젝트 위키, 개선 제안(QEP 같은) 저장소를 확인해요. QGIS는 QEP 저장소, QEMU는 code provenance 문서, 리눅스 커널은 process 문서에 규칙이 있어요.

2. 2

   날짜와 적용 범위를 기록해요

   정책의 버전과 날짜, 어느 저장소와 어떤 기여(코드, 문서, 이슈)에 적용되는지 적어 둬요. 같은 프로젝트라도 저장소마다 규칙이 다를 수 있어요.

3. 3

   허용된 사용과 금지된 사용을 나눠요

   QEMU처럼 조사·디버깅은 허용하고 출력물 포함만 막는 곳이 있고, QGIS처럼 보조 자체를 넓게 막는 곳도 있어요. 애매하면 제출 전 메일링 리스트나 이슈로 메인테이너에게 먼저 물어요.

4. 4

   설명할 수 없는 코드는 내지 않아요

   AI를 허용하는 프로젝트에서도 Signed-off-by는 사람의 책임 선언이에요. 리뷰에서 한 줄 한 줄 이유를 설명할 수 없다면 제출하지 않는 것이 공동체와 본인의 신뢰를 지키는 방법이에요.

AI 정책 논쟁은 개발자 커뮤니티와 텔레그램 채널에서도 빠르게 퍼지는 주제예요. 더따리의 AI 텔레그램 트렌드와 블로그 트렌드에서 어떤 이슈가 함께 언급되는지 흐름을 살펴볼 수 있지만, 정책의 정확한 문구와 날짜는 반드시 프로젝트 원문으로 확인하세요.

페이지 참고

트렌드theddari.com›트렌드텔레그램 · AIAI 채널 실시간 포스팅 피드

페이지 참고

트렌드theddari.com›트렌드블로그 포스팅요약된 네이버 블로그 글 피드