QGIS, AI 기여를 완전히 금지하다. 그 이유에 대한 가장 좋은 논거는 직접 실행한 사람에게서 왔다

세계에서 가장 인기 있는 오픈 소스 GIS 애플리케이션 중 하나가 AI 지원 기여는 어떤 형태로든 환영하지 않기로 결정했습니다. 그리고 병합된 정책 문서는 대부분의 풀 리퀘스트 템플릿보다 더 짧습니다. 'AI 기여 허용 안 함(No ai contributions permitted)'이라는 제목의 QGIS 개선 제안 QEP428이 2026년 10월 7일에 병합되었으며, 이는 프로젝트의 이전 '인간 개입 (human in the loop)' AI 정책을 엄격한 '허용 안 함 (NOT ALLOWED)' 정책으로 공식 대체합니다. 이 내용이 Hacker News 메인 페이지에 올라왔을 때 몇 시간 만에 수백 점과 수백 개의 댓글을 모았는데, 대부분은 자원봉사 커뮤니티가 이런 규칙을 강제할 수 있는지에 대해 논쟁하는 것이었습니다.

강제 집행에 대한 주장은 타당합니다. 하지만 이 이야기에서 가장 흥미로운 두 가지 문서를 놓치고 있습니다. 바로 자신의 AI 지원 풀 리퀘스트로 프로젝트를 한계까지 몰아붙인 기여자(contributor)의 자백과, 모든 신규 기여자가 첫 커밋이 승인되기 전에 살아있는 인간임을 증명하도록 요구하는 후속 제안입니다.

전체 공개: 저는 QGIS에 기여한 적이 없으며, 매일 AI 코딩 에이전트를 사용합니다. 이는 아마도 이 정책이 겨냥하는 바로 그 종류의 기여자라는 것을 의미할 것입니다. 아래 내용은 병합된 QEP, QGIS 개발자 메일링 리스트, 그리고 토론 스레드에서 가져온 것입니다. 제가 출처가 있는 사실 대신 의견을 제시하는 부분은 그렇게 명시하겠습니다.

정책이 실제로 말하는 것

• 검토 부담이 감당하기 어렵다. 외부 기여자들의 AI 사용은 논의에서 말하는 것처럼 유지보수자들에게 막대하고 감당할 수 없는 압박을 가합니다. 이들은 이미 LLM 시대 이전에도 힘든 일을 하고 있었습니다.
• 양(Volume)이 인간 검토 능력을 초과한다. AI 도움을 받은 제출물 흐름은 인간 검토자들이 진지하게 다룰 수 있는 양보다 많습니다. 따라서 프로젝트는 검토되지 않은 풀 리퀘스트가 쌓이는 것과, 실제로는 검토가 아닌 검토를 하는 것 사이의 선택에 직면합니다. 두 가지 옵션 모두 품질을 저하시킵니다.
• 자유 소프트웨어는 인간 네트워크 위에서 운영된다. 조직들이 QGIS를 신뢰하고 자금을 지원하는 이유는 기여할 수 있고, 지원 및 교육을 위해 기여자를 고용하며, 기능에 영향을 미칠 수 있다는 것을 알기 때문입니다. 이 경제적이고 사회적인 순환은 실제 인간이 참여할 때만 작동합니다.

댓글 섹션에서는 이 정책이 집행 불가능하다고 말할 것이고, 프로젝트 자체도 이에 동의합니다. QEP(QGIS Enhancement Proposal)에 앞서 진행된 메일링 리스트 논의에서, QGIS 프로젝트 운영 위원회(Project Steering Committee)의 멤버인 Tim Sutton이 직접 실행 문구를 작성했습니다: 저장소에 'LLM 도움을 받은 코드 기여는 허용되지 않는다'고 명시하고, 자신의 말로 '우리는 이것이 시행하기 어렵다는 것을 알지만, 만약 나중에 당신이 LLM을 사용하여 기여했다는 사실을 발견한다면, 코드 되돌림(code reversion)과 기여자 권리 제재의 위험을 감수해야 합니다.'라고 했습니다. 같은 논의에서는 이 정책을 기여자 라이선스 계약 워크플로우에 연결하여 모든 풀 리퀘스트가 명시적인 증명서(attestation)를 갖도록 제안했습니다.

이것은 올해 초 OpenJDK가 선택했던 것과 동일한 집행 모델입니다. AI 텍스트를 신뢰성 있게 감지할 수 없기 때문에, 기여자들에게 준수 사항을 확인하고 그 책임 자체를 지게 만드는 것입니다. 이 정책은 명예 시스템(honor system)으로 작동하며, 그 명예 시스템을 결과로 뒷받침합니다.

고백 (The confession)

여기에 있는 병합 논의 부분은 어떤 정책 토론보다 더 많은 주목을 받을 자격이 있습니다. Amalvir라는 기여자가 QEP 논의 중에 댓글을 달았는데, 이 댓글은 금지 조치가 직접 영향을 미치는 사람으로부터 나온 지지 의견입니다.

"저는 이 새로운 정책에 대해 직접적으로 우려하며, 저에게도 긍정적인 변화입니다. 버그의 원인을 조사하고, 수정 사항을 제안하며, 코드를 검토하기 위해 제가 AI 도움을 받아 작성한 회귀 수정(regressions-fix) PR 두 개를 만들었을 때, 이것이 QGIS가 이미 취약한 리뷰어 커뮤니티에 어떤 해를 끼칠지 깨닫지 못했습니다. 저는 명백히 아직 QGIS처럼 복잡한 프로젝트의 버그를 고치기에 충분한 기술을 갖추지 못했지만, LLM은 그것이 가능한 착각을 줍니다."

다시 읽어보세요. 이 네 문장 안에 전체 AI 기여 논쟁이 압축되어 있습니다. 의욕적인 개발자가 버그를 발견하고, 도움을 주고 싶어서, 사용 가능한 도구를 이용해, 그럴듯해 보이는 수정 풀 리퀘스트(PR) 두 개를 만들었고, 그러다가 자신이 느꼈던 '기여'가 사실은 자원봉사자들에게 짐을 지우는 것에 가까웠다는 것을 깨달았습니다. 모델이 어려운 문제를 해결된 것처럼 느끼게 만든 것입니다. 리뷰어는 여전히 그것이 실제로 맞는지 검증하는 실제 작업을 해야 했습니다.

이것이 온건한 정책들이 전혀 대비하지 못한 실패 모드입니다. '인간의 개입(human in the loop)' 규칙은 인간이 AI를 감독한다고 가정합니다. 하지만 이 규칙은 AI의 출력이 정확한지 독립적으로 판단할 수 없는 사람, 즉 QGIS처럼 복잡한 코드베이스에 있는 대부분의 사람들에게는 아무런 도움이 되지 못합니다. '능력의 착각(illusion of competence)'은 가이드라인으로 정책을 만들어서 해결할 수 있는 규율 문제가 아닙니다. 따라서 전면 금지입니다.

여기에는 이 도구들을 전문적으로 다루는 우리 모두에게 불편한 거울이 비치고 있습니다. 제 AI 도움을 받은 작업과 그 고백에 나온 풀 리퀘스트의 차이는 모델이 QGIS에 대해 더 똑똑해졌기 때문이 아닙니다. 제가 이미 시스템을 알고 있기 때문에, 저는 보통 출력이 잘못되었을 때를 알 수 있다는 점입니다. 낯선 코드베이스에서는 그 안전망이 사라지고, 이 고백은 남아있는 것을 보여줍니다.

'생존 증명(proof of life)' 제안

금지 조치는 QEP의 작성자이자 QGIS에서 가장 생산적인 기여자 중 한 명인 Nyall Dawson이 원래 제안했던 것의 절반에 불과했습니다. 나머지 절반은 더 이상하고, 아직 채택되지 않았습니다.

9월 말 메일링 리스트 스레드에서 그는 모든 신규 기여자에게 첫 번째 기여가 어떤 형태로든 받아들여지기 전에 '생존 증명(proof of life)'을 요구할 것을 제안했다. 한 가지 제안은 프로젝트에 의도적으로 아주 적은 금액의 재정적 기여를 하는 것이었는데, 이는 그가 프로젝트에 관심이 없는 카르마 농부(karma farmers)들을 막기 위함이었다. 그는 어떤 금액이라도 봇(bots)을 차단하기에 충분할 것이라고 주장했다. 제시된 또 다른 대안은 더 급진적인 것이었다: 신규 기여자가 변경 사항을 제출하기 전에 기존 기여자와 직접 만나야 한다는 것이다.

이에 대한 반발은 즉각적이고 합리적이었다. 한 응답자는 QGIS에 기여하는 것 자체가 이미 수천 달러 상당의 하드웨어를 요구하며 종종 수년간의 교육 과정을 거쳐 이루어지기 때문에, 프로젝트는 이미 불평등 장벽을 가지고 있으며 결제 게이트를 추가하는 것은 또 다른 장벽을 만든다고 지적했다. 그들은 자신들이 처음 시작했을 때의 기억을 공유했는데, QGIS 클린 빌드 하나가 예전 노트북에서 밤 전체를 차지했던 적이 있다고 했다.

병합된 QEP(QGIS Enhancement Proposal)에는 생존 증명에 대한 내용은 포함되어 있지 않다. 이는 여전히 논의 중인 아이디어이며, 그 자체로 주목할 만하다. FOSS GIS 세계의 기둥 중 하나인 확립된 오픈 소스 프로젝트가 검증되지 않은 사람들의 익명 첫 커밋(anonymous first commits)이 여전히 지속 가능한지에 대해 심각하게 논의하고 있다. 구체적인 제안에 대해 어떻게 생각하든, 나아가는 방향은 명확하다: 주요 자원봉사 프로젝트에서 걸어 들어오는 듯한 익명성은 시대가 끝나고 있으며, 그 이유는 AI 범람 때문이다.

패턴과 QGIS가 이를 깨는 방식

나는 일주일 전에 OpenJDK의 AI 정책을 자세히 검토했기 때문에 QGIS 결정의 형태가 친숙해 보였지만, 두 번째로 살펴보니 그렇지 않았다. 프로젝트들을 나열해보면 흥미로운 점이 보인다:

• OpenJDK (Oracle): 코드, 버그 보고서, 위키 페이지, 이메일 전반에 걸쳐 AI 생성 콘텐츠가 부분적 또는 완전히 금지됩니다. AI를 사용하여 읽고, 디버깅하고, 검토하는 것은 명시적으로 허용됩니다. 제시된 이유는 리뷰어의 부담, 안전성, 그리고 결정적으로 지적 재산권(IP)입니다. 기여자 계약은 AI 출력물에 대해 법적으로 소유하지 않을 수도 있는 권리를 부여하도록 요구합니다.
• GraalVM (역시 Oracle): 동일한 기여자 계약 하에서 반대 규칙이 적용됩니다. AI 비서가 코드, 테스트 및 문서를 초안 작성하고, 변형하고, 검토할 수 있지만, 책임성(accountability)이 기준입니다. 리뷰에서 변경 사항을 설명하고 방어할 수 없다면 거부됩니다.
• QGIS (자원봉사 커뮤니티): 세 곳 중 가장 완만한 금지이며, 근거가 가장 좁습니다. 논의 어디에서도 IP 주장이 나타나지 않습니다. 전체 사례는 리뷰어의 주의력과 커뮤니티 건강에 관한 것입니다.

이 세 번째 행(row)이 신호입니다. Oracle의 금지는 다른 무엇이었든 간에 그 밑바탕에는 기업 법률적 논리가 있었습니다. QGIS는 전혀 법적인 동기가 없습니다. 기여자들은 AI 출력이 오염시킬 것이라는 양도 계약서에 서명한 적이 없습니다. 커뮤니티는 자체 리뷰 대기열과 자체 번아웃 수준을 살펴보고, AI 지원 볼륨(심지어 선의의 AI 지원 볼륨조차)이 제공하는 것보다 비용이 더 많이 든다는 결론을 내렸습니다. 이는 노동을 수행하는 사람들에 의해 내려진 순수한 노동 경제학적 결정입니다.

한 Hacker News 댓글 작성자는 근본적인 변화를 잘 지적했습니다. 병목 현상은 더 이상 코드를 작성하는 것이 아니라, 그것에 맞춰 유지되는 것, 즉 무엇인지 알고 그리고 의도했던 대로 작동하는지 아는 것입니다. 그리고 낯선 사람들의 대규모 풀 리퀘스트(pull requests)를 검토해야 하는 관리자들에게 그 문제는 훨씬 더 심각합니다. 또 다른 사람은 Peter Naur의 오래된 에세이

이것에서 하나의 예측을 원한다면: 향후 6개월 동안 다른 자원봉사 기반 프로젝트들이 비슷한 금지 조치를 채택하는지 지켜보고, 어떤 프로젝트인지 주목하세요. 유료 유지보수자가 있는 기업 지원 프로젝트들은 AI 기여를 계속 용인하거나 수용할 것입니다. 기부된 저녁 시간을 활용하여 운영되는 프로젝트들은 문을 닫아갈 것입니다. 이 분열은 AI에 대한 신념의 문제가 아닐 것입니다. 누가 검토 비용을 지불하느냐의 문제일 것입니다.

제가 실제로 오픈 소스에 기여한다면

어떤 프로젝트가 공식적인 정책을 가지고 있는지 여부와 관계없이, QGIS 사례는 2026년 AI 지원 오픈 소스 기여를 위한 작업 규칙 세트를 시사합니다:

• 코드의 첫 줄을 작성하기 전에 기여자 가이드를 읽으세요. 정책들은 올해 빠르게 변화하고 있습니다. OpenJDK의 임시 정책은 4월에 발표되었고, QGIS QEP428은 10월에 병합되었으며, 이 두 가지 모두 이전 규범을 뒤집었습니다. 여러분이 2024년에 기억하는 규칙은 오늘 페이지에 있는 규칙과 정반대일 수 있습니다.
• 익숙하지 않은 코드베이스에서는 기본적으로 읽기 전용 AI를 사용하세요. LLM(거대 언어 모델)을 사용하여 대규모 프로젝트를 이해하고, 탐색하며, 디버깅하는 것은 가장 엄격한 정책조차 명시적으로 허용하는 사용 사례입니다. 또한 이 도구들이 최고의 성능을 발휘하는 곳이기도 합니다.
• 라인별로 설명할 수 없는 수정 사항은 절대 제출하지 마세요. 이것이 GraalVM의 책임성 기준이며, 모든 곳에 적용되어야 할 올바른 기준입니다. 모델의 도움 없이 검토 과정에서 변경 사항을 방어할 수 없다면, 테스트가 아무리 성공적이라도 그 변경 사항은 준비되지 않은 것입니다.
• AI 초안으로 작성된 이슈를 제출하지 마세요. OpenJDK와 QGIS 모두 비코드 콘텐츠를 범위 내로 취급합니다. 유지보수자의 관점에서 볼 때: 잘 쓰인 이슈는 관심의 선물이지만, 그럴듯하게 들리는 AI 이슈는 같은 계정에서의 철회에 가깝습니다.
• 합법적인 경우에도 공개하세요. 일부 프로젝트는 여전히 AI 지원 코드를 허용합니다.

만약 당신이 테이블의 반대편에 앉아 당신의 작업 대기열(queue)이 차오르는 것을 지켜보는 유지보수자라면: QGIS의 순서는 사용 가능한 템플릿입니다. 부드러운 정책을 먼저 세우고, 다음으로 측정할 수 있는 기준을 마련하며, 마지막으로 이해하지 못했다고 주장할 수 없을 만큼 충분히 짧은 강력한 규칙(hard rule)을 만드는 것입니다.

핵심 요약

QGIS가 AI를 금지한 것은 AI 코드가 나쁘기 때문이 아닙니다. 그중 일부는 괜찮습니다. QGIS가 AI를 금지한 이유는 자원봉사 프로젝트에서 가장 부족한 자원이 코드 자체가 아니라, 코드를 검토할 의지와 능력을 가진 소수의 사람들의 '주의력(attention)'이기 때문이며, AI는 몇 방울씩 들어오던 기여를 어떤 검토 프로세스도 정직하게 흡수할 수 없는 홍수로 만들었기 때문입니다. 병합 토론(merge discussion)에 담긴 고백이 이 모든 이야기를 축소판으로 보여줍니다: 책임감이라는 역량 없이 기여의 느낌만을 만들어내는 도구들입니다.

모든 오픈 소스 프로젝트가 향후 1년 동안 어떤 식으로든 답해야 할 질문은 'AI 코드가 좋은가?'가 아닙니다. 그것은 '누가 이를 검토하며, 그들이 동의했는가?'입니다. QGIS가 방금 크게 답변했습니다.

올해 오픈 소스 프로젝트에 AI 도움을 받은 기여를 제출한 적이 있습니까? 유지보수자들이 알고 있었습니까? 댓글 창에서 확인할 수 있습니다.