오픈소스 GIS 플랫폼으로 널리 알려진 QGIS 프로젝트가 AI 생성 코드를 기여물로 받지 않겠다는 정책을 QEP428로 공식화하고 PR을 병합했다. 제목은 단순하다. "No AI contributions permitted." 정책 내용의 세부 범위는 원문 PR에서 확인해야 하지만, 프로젝트 공식 제안 프로세스를 거쳐 채택됐다는 사실 자체가 중요하다. 유지보수자 한 명의 판단이 아니라, 커뮤니티 거버넌스 차원의 결정이기 때문이다.
이 결정을 "AI 도구에 반대하는 커뮤니티의 반응"으로 읽으면 핵심을 놓친다. 오픈소스 프로젝트가 기여 흐름을 어떻게 통제할지, 그 과정에서 지속 가능성과 법적 책임 사이에서 어떤 선택을 내리는지에 대한 신호로 봐야 한다.
무엇이 바뀌었고, 무엇은 바뀌지 않았나
바뀐 것은 QGIS 코드베이스로 들어오는 기여의 조건이다. AI 생성 코드를 포함한 기여물은 이제 공식 정책 위반이 된다. 기여자 입장에서는 제출 전 자신의 코드가 이 조건을 충족하는지 스스로 판단해야 한다.
바뀌지 않은 것은 QGIS를 사용하는 방식이다. 이 정책은 프로젝트 내부 기여 흐름을 대상으로 하며, QGIS를 GIS 분석 파이프라인이나 제품에 통합해 쓰는 팀의 운영에 직접 영향을 주지는 않는다. 당장 무언가를 바꿔야 하는 상황은 아니다.
그러나 중장기적으로 이 결정이 해당 프로젝트의 기여 속도와 유지보수 인력에 어떤 영향을 미칠지는 아직 알 수 없다. AI 보조 도구 사용이 기여자들 사이에서 이미 보편화됐다면, 금지 정책이 기여 진입 장벽을 높이는 방향으로 작용할 가능성도 있다. 반대로 검토 부담이 줄어 기존 유지보수자들이 더 오래 활동을 지속하는 결과로 이어질 수도 있다. 지켜봐야 할 부분이다.
이 결정 뒤에 있는 두 가지 구조적 긴장
AI 기여를 금지하는 결정이 나오는 데는 통상 두 가지 이유가 작동한다. QGIS가 어떤 이유를 명시적으로 밝혔는지는 QEP428 본문에서 확인해야 하지만, 오픈소스 커뮤니티 전반에서 반복되는 구조적 긴장이라는 점에서 살펴볼 가치가 있다.
첫째는 저작권 귀속 문제다. AI 생성 코드의 저작권이 누구에게 있는지, 학습 데이터에 포함된 원본 코드의 라이선스 의무를 AI 출력물이 어떻게 승계하는지는 아직 법적으로 정리되지 않았다. 카피레프트 라이선스(GPL·LGPL처럼 파생 저작물에 동일 라이선스 적용을 요구하는 조건)를 채택한 프로젝트는 기여자가 코드를 이해하고 라이선스 조건에 동의한다는 전제 위에 운영된다. AI가 생성한 코드를 기여자가 충분히 검토하지 않은 채 제출하면 이 전제가 흔들린다.
둘째는 유지보수자의 검토 비용이다. AI 생성 코드는 겉으로 그럴듯해 보이지만 프로젝트 관습을 따르지 않거나 미묘한 결함을 포함하는 경우가 있다. 이 코드를 검토하는 부담은 기여자가 아니라 유지보수자에게 떨어진다. 핵심 기여자가 소수인 오픈소스 프로젝트에서 검토 부담이 쌓이면 유지보수자 이탈로 이어질 수 있다. 금지 정책은 AI를 거부한다는 선언이라기보다, 유지보수 구조의 한계를 공식화한 것으로 읽히는 면이 있다.
이 결정이 선례로 작동할 가능성
QGIS가 주목받는 이유는 정책 자체만이 아니다. 공식 제안 프로세스를 통해 커뮤니티 합의를 거쳤다는 방식이, 다른 프로젝트들이 같은 문제를 다룰 때 참조할 수 있는 틀을 제공한다는 점이다.
비슷한 결정을 내릴 이유가 생기는 프로젝트는 어느 정도 공통점이 있다. 카피레프트 라이선스를 채택해 법적 불확실성에 더 민감한 프로젝트, 도메인 전문성이 필요한 코드베이스(의료, 금융, 지리정보 등 오류의 파급이 큰 영역), 핵심 기여자가 적어 검토 여력이 제한적인 프로젝트가 여기 해당한다. 이 세 조건이 겹치는 프로젝트일수록 QGIS와 같은 선택을 검토할 가능성이 높다.
반면 MIT나 Apache 2.0처럼 비카피레프트 라이선스를 쓰고, 대기업이 스폰서로 참여해 검토 인력이 충분한 프로젝트는 다른 접근을 택할 수 있다. AI 기여 정책이 오픈소스 생태계 전체에서 단일한 방향으로 수렴할 것이라고 보기는 어렵다. 프로젝트의 구조와 조건에 따라 선택이 갈릴 가능성이 크다.
오픈소스를 의존성으로 쓰는 팀이 요구사항 단계에서 확인할 것들
이 사건이 프로덕트 매니저나 IT 의사결정자에게 실질적인 의미를 갖는 이유는 세 가지 확인 항목 때문이다.
의존하는 프로젝트가 AI 기여 정책을 명시하고 있는가. 정책이 없다는 것이 AI 기여를 허용한다는 의미는 아니다. 아직 결정을 미루고 있거나, 내부 논의가 진행 중일 수 있다. 정책 부재 상태에서 AI 생성 코드가 이미 코드베이스에 유입돼 있을 가능성도, 반대로 갑자기 금지 정책이 채택될 가능성도 열려 있다. 어느 쪽이든 의존 팀 입장에서는 모르는 상태가 더 불편하다.
해당 프로젝트의 라이선스가 카피레프트 계열인가. GPL·LGPL 라이선스라면 AI 생성 코드의 저작권 불확실성이 우리 조직 코드에까지 파급될 수 있다는 점을 법무팀과 공유할 항목으로 올려두는 것이 낫다. MIT나 Apache 2.0이라면 리스크의 성격이 다르다. 두 유형을 같은 기준으로 취급하지 않는 것이 좋다.
해당 프로젝트의 기여자 구조가 정책 변화에 취약한가. 핵심 기여자가 소수이고 외부 스폰서십도 제한적인 프로젝트라면, AI 기여 금지로 기여 속도가 줄 때 유지보수 공백이 생길 수 있다. GitHub 기여자 활동 추이, 릴리스 주기, 이슈 해결 속도를 주기적으로 확인하는 것이 현실적인 의존성 관리 방법이다.
세 항목 모두에 지금 당장 답할 수 있다면 할 일이 없다. 하나라도 "잘 모른다"라고 답해야 한다면, 요구사항 단계에서 다루지 않은 항목이 나중에 라이선스 감사나 의존성 교체 비용으로 돌아올 수 있다. QGIS의 결정은 그 전환이 예고 없이 올 수 있다는 것을 보여준 사례다.
