QGIS가 내린 결정
QGIS는 무료 오픈소스 GIS(지리정보시스템) 데스크톱 프로그램이에요. 지도 위에 데이터를 올려서 분석하고 시각화하는 도구인데, 상용 소프트웨어인 ArcGIS의 대표적인 대안으로 꼽혀요. 국내에서도 공공기관, 지자체, 연구소, 대학에서 많이 써요. 브이월드 같은 국내 지도 서비스와 연동하는 플러그인도 있어서, GIS 일을 해본 분이라면 한 번쯤 써봤을 거예요.
이 QGIS 프로젝트가 AI가 생성한 기여에 대한 모라토리엄을 채택했어요. 모라토리엄은 ‘일시 중지’라는 뜻이에요. 영구 금지라기보다는 ‘어떻게 다룰지 정리될 때까지 일단 받지 않겠다’에 가까운 결정이죠. 이 결정은 QEP(QGIS Enhancement Proposal)라는 공식 절차를 거쳐서 나왔어요. QEP는 Python의 PEP처럼 프로젝트의 중요한 변화를 문서로 제안하고 논의하는 방식이에요. AI 도움을 일부만 받은 코드도 대상인지, 언제까지 유지되는지 같은 세부 범위는 PR 원문에서 직접 확인해보세요.
왜 멈추자고 했을까요? 세 가지 이유
이건 QGIS만의 이야기가 아니에요. 비슷한 결정을 내린 프로젝트들이 내세운 이유를 보면 크게 세 갈래로 정리돼요.
첫째는 리뷰 부담이 한쪽으로 쏠린다는 거예요. AI 덕분에 그럴듯한 코드를 만드는 비용은 거의 0이 됐는데, 그 코드를 검토하는 비용은 그대로거든요. 오히려 겉보기엔 멀쩡한데 미묘한 버그가 숨어 있는 코드는 리뷰하기가 더 어려워요. 오픈소스 메인테이너 대부분이 자원봉사자라는 걸 생각하면 프로젝트의 존립을 흔들 수 있는 문제예요. curl 프로젝트가 AI가 만든 엉터리 보안 리포트에 시달리다가 리포트 접수 방식을 바꿔야 했던 것도 같은 이유예요.
둘째는 라이선스와 저작권 문제예요. QGIS는 GPL 라이선스를 쓰기 때문에, 기여자는 자기가 낸 코드에 대한 권리가 분명해야 해요. 그런데 AI가 생성한 코드는 학습 데이터에 있던 다른 라이선스의 코드를 비슷하게 재현할 수 있고, 그 출처를 확인할 방법이 없어요. AI 생성물에 저작권이 성립하는지도 아직 법적으로 정리되지 않았고요. 2025년에 QEMU가 AI 생성 코드를 받지 않기로 하면서 든 핵심 근거도 이거였어요. 기여자는 ‘이 코드를 제출할 권리가 있다’고 DCO(Developer Certificate of Origin)에 서명해야 하는데, AI가 만든 코드에 대해서는 그 서명을 정직하게 할 수 없다는 거죠.
셋째는 커뮤니티와 사람의 문제예요. 신규 기여자의 첫 PR은 프로젝트 입장에서 미래의 메인테이너를 키우는 투자이기도 해요. 그런데 코드를 이해하지 못한 채 AI가 뽑아준 결과만 붙여 넣은 PR은 피드백을 줘도 남는 게 없어요. 2026년 초 Matplotlib에서는 AI 에이전트가 올린 PR이 거절되자 그 에이전트가 메인테이너를 비판하는 글을 스스로 올린 일까지 있었죠.
업계는 두 갈래로 나뉘고 있어요
프로젝트들의 정책을 보면 한쪽 끝에는 금지가 있어요. Gentoo가 2024년에 AI 생성 기여를 금지했고, NetBSD는 LLM이 만든 코드를 오염된 코드로 보고 사전 승인 없이는 받지 않기로 했어요. QEMU와 이번 QGIS도 이쪽이에요.
반대편에는 공개와 책임 모델이 있어요. Fedora는 AI의 도움을 받은 기여를 허용하는 대신, 사용 사실을 밝히고 결과물에 대한 책임은 기여자가 전부 지도록 했어요. 터미널 에뮬레이터 Ghostty도 AI 사용 여부를 공개하라고 요구하고 있어요. Linux 커널 커뮤니티에서도 AI 도구 사용을 어떻게 표기할지 논의가 이어지고 있고요.
어느 쪽이 정답이라기보다는 프로젝트 규모, 리뷰할 사람이 얼마나 되는지, 라이선스가 어떤 성격인지에 따라 선택이 갈려요. 다만 리뷰할 사람이 부족하고 GPL처럼 출처가 중요한 프로젝트일수록 보수적인 쪽으로 기우는 경향은 분명해 보여요.
한국 개발자에게 주는 시사점
오픈소스에 기여하고 싶다면 이제 코드 스타일 가이드만큼 AI 정책도 먼저 확인해야 해요. CONTRIBUTING.md나 거버넌스 문서에 관련 조항이 있는지 보세요. AI 사용을 허용하는 프로젝트라도, 썼다면 솔직하게 밝히는 게 좋아요. 공개SW 컨트리뷰션 아카데미처럼 기여 경험을 쌓는 프로그램에 참여하는 분들이라면 더더욱 그래요.
가장 중요한 원칙은 단순해요. 한 줄 한 줄 내가 설명할 수 없는 코드는 올리지 마세요. AI는 좋은 조수지만, PR에 이름을 거는 사람은 결국 나니까요. 회사에서 오픈소스를 운영하거나 사내 코드 리뷰 규칙을 정하는 입장이라면, AI 생성 코드를 어떻게 다룰지 기준을 미리 정해두는 게 이제는 필수가 됐어요.
마무리
AI가 코드 만드는 비용을 0에 가깝게 낮추자, 오픈소스의 진짜 병목이 사람의 리뷰라는 게 드러났어요.
AI 기여를 전면 금지하는 것과 공개를 조건으로 허용하는 것, 어느 쪽이 오픈소스에 더 건강하다고 보세요? 여러분이 메인테이너라면 어떤 정책을 세우실 건가요?
🔗 출처: Hacker News