QGIS, AI 보조 기여 금지

이제 병목은 코드 작성이 아니라 코드를 이해하고 의도와 일치하는지 확인하는 일임. 일종의 정렬 문제지만, 인간 쪽에서 발생하는 문제임. 내 업무에서도 직접 요청한 코드조차 이를 확인하는 데 대부분의 노력이 들어감.
낯선 사람이 보내온 대규모 PR을 검토하는 유지보수자에게는 훨씬 더 버거울 것임. 금지는 다소 가혹하지만, 한정된 주의력을 아끼려는 이유는 이해함.

소프트웨어가 무엇을 하는지 확신하는 일은 정말 어려움. 대부분의 개발자는 대략 안다고 여기지만, 어떻게 확신하느냐고 물으면 이해의 빈틈이 드러남. 대개 제대로 작동한다는 신호에 만족하고, 직접 입증하는 수고를 피하려고 이론과 머릿속 모델에 의존함.
LLM으로 코드를 생성하기 시작하면 그 이해의 지름길마저 잃어버리고, 실제로는 거의 모르면서 이해했다고 자신을 속이기 쉬움. 얼마 안 되는 코드 검토 연구에서도 한 시간 동안 수백 줄 이상을 읽고 나면 코드 품질에 미치는 영향이 매우 작아진다고 함.
여기서 “AI가 나보다 프로그래밍을 잘한다”로 도약하곤 하지만, 그래도 더 나은 프로그래머가 되는 노력은 가치가 있다고 봄. 왕도는 없고, 직접 코드를 쓰며 나쁜 코드와 씨름해야 함.

나는 반대로 AI 사용을 중단함. 코드에 대한 이해를 유지하는 부담이 너무 커서, AI가 업무를 편하게 해준다고 느끼지 못함.

코드 작성 자체가 병목이었던 적은 없음. 시간 대부분은 나머지 일에 들어감. 다만 코드를 쓰면서 이해가 깊어지고 난관과 함정을 발견해, 다시 설계 단계로 돌아가는 일이 잦음.

Peter Naur의 Programming as Theory Building과 같은 맥락임. 언어와 라이브러리 몇 개를 익힌 뒤 코드를 작성하는 일은 원래 쉬웠고, 도구로 더 쉽게 만들 수도 있음. 어려운 것은 이미 작성된 내용과 앞으로 추가해야 할 내용을 제대로 이해하는 일임.
나는 코드 한 줄을 쓸 때마다 명세와 문서를 읽는 데 2~5시간을 쓴 것 같음. 소프트웨어 개발은 늘 이해의 문제임. 문법과 라이브러리의 식별자에 너무 많은 신경을 쓰고 있다면 아직 초보 단계임. 외국어를 배우며 문법을 의식하거나, 초보 운전자가 자동차 조작 하나하나에 신경 쓰는 것과 비슷함.

누구나 참여하는 기여 방식의 종말처럼 느껴짐. 유지보수자는 이미 할 일이 너무 많음. 유지보수자가 직접 LLM을 쓰고 결과를 검토하는 것보다 더 잘해서, 실제로 시간을 절약해주는 기여자를 찾기도 갈수록 어려워짐.

최근에는 상세한 이슈 작성이 오픈소스에 기여하는 가장 좋은 방법이라고 느낌. 유지보수자가 이를 AI 도구에 넣고 직접 주고받는 편이, 기여자에게 피드백을 남기고 수정을 기다리는 것보다 빠름.

기여하려면 프로젝트에 가치를 더한다는 것을 입증해야 함. 논란의 여지가 있는 요구라고 생각하지 않음.
오픈소스이므로 기여가 거절되면 포크하면 됨. 자유로운 경쟁을 통해 원래 소유자가 가치를 잘못 판단했는지, 아니면 그 기여가 사실상 무가치했는지 곧 드러날 것임.

외부 기여가 끝나는 것은 특정 저장소 하나뿐임. 이번 조치는 UI 애플리케이션인 QGIS에만 해당하며, 기능을 뒷받침하는 GDAL/GEOS 등 다른 라이브러리는 대상이 아님.
최근 몇 년간 외부 기여를 받는 신규 오픈소스 프로젝트의 수와 인기는, 이를 받지 않는 소수의 오래된 프로젝트를 훨씬 넘어섬.

외부 기여를 받지 않으면 새 유지보수자를 어떻게 찾을지도 문제여서, 유지보수 병목이 더 심해질 수 있음.
적어도 신규 기여자에게는 PR 검토 비용을 소액 받는 방안도 가능함. 학생이나 저소득층을 배제할 위험은 있지만, 무성의한 AI 생성물을 억제하는 데는 1달러 이하로도 충분할 것이라고 낙관함.

연결된 이메일 토론에는 AI 기업의 재정적 기여를 요구하자는 제안이 있음. Claude Code를 쓰려면 Anthropic이 먼저 QGIS.org의 지속 후원 회원이 되고, Codex나 Gemini를 쓰려면 OpenAI와 Google이 수천 달러 규모로 기여하도록 하자는 것임.
정말 좋은 아이디어라고 봄. 저장소에 Markdown 지침을 두어, 지침을 잘 따르는 모든 모델이 기여를 거부하게 만들 수 있을까?

끔찍한 아이디어임. 도둑들이 오픈소스 프로젝트를 더 사들이게 만드는 셈임.

조직이 QGIS를 신뢰하는 이유가 직접 기여할 수 있고, 기여자를 고용해 지원·교육·기능 개발을 맡길 수 있기 때문이라며 이를 보호하겠다고 함.
그렇다면 경제적 동기도 있는 셈임. 외부 기여를 더 허용하면 기존 전문가의 전문성 가치와 고용 가능성이 낮아질 것을 걱정하는 것임. 공정하게 보자면, 실제로 그럴 가능성도 높음.

HN에서는 왜 항상 모두가 AI에 찬성하는 걸까? 이번 조치는 장기적으로 코드 품질을 개선할 것이므로 객관적으로 좋은 변화임.

HN 이용자는 자신이 매우 똑똑하다고 여기지만 실제로는 기대에 못 미치는 경우가 많고, 전문 분야 밖에서도 자신을 과신하는 태도부터 더 어리석은 판단까지 이어짐.
AI 분야에 흘러드는 자금 규모와 HN의 영향력을 고려하면, 예상보다 큰 규모의 위장 여론 조성이 있어도 놀랍지 않을 것임. 또 AI를 적극 도입한 사람은 그 선택에 대한 회의나 비판을 자신에 대한 공격으로 받아들이기도 함.
HN 특유의 말꼬리 잡기도 있음. “왜 AI 찬성 활동이 이렇게 많냐”는 취지인데도, “항상 모두가 AI에 찬성한다”를 문자 그대로 해석해 틀렸다고 할 것임.

“항상 모두가 AI에 찬성한다”는 것은 객관적으로 사실이 아님. 품질은 주관적이므로 이번 변화가 객관적으로 좋다고 단정할 수도 없고, 인간이 쓴 코드가 LLM 생성 코드보다 항상 낫다는 전제도 성립하지 않음.
소프트웨어 공학에서 코드는 전체 프로젝트의 일부이고, 코드 품질 역시 그 일부일 뿐임. LLM이 어떤 지표로든 완벽한 코드를 쓰더라도, 검토자가 완벽한 기여의 물량에 압도된다면 소용없음.

AI 보조가 곧 낮은 코드 품질을 뜻하지는 않음. 여러 방식으로 품질 개선을 도울 수 있음. 문제는 신중한 검토 없이 전적으로 바이브 코딩에 의존하는 것임.
하지만 적정선을 찾기 어려움. LLM 보조 기여를 허용하면 품질 지침을 아무리 써도 저품질 기여가 밀려들고, 일괄 금지할 때보다 걸러내고 거절하는 데 훨씬 많은 노력이 듦. 연결된 논의도 모든 LLM 보조 기여가 나쁘다는 취지가 아니라, 일단 유입을 막고 나중에 다시 개방할 방법을 찾자는 것임.

AI가 유용하고 대체로 잘 작동하기 때문 아닐까? 대규모 AI 생성 PR을 던져놓고 사라지는 행위를 막는 것은 도움이 됨. 노력 없이 이름만 올리려는 문제는 AI 이전에도 존재했음.
하지만 이번 금지는 수정이나 새 기능을 담은 고품질 PR까지 막을 수 있음. 결과는 지켜봐야 하며, 누구나 포크할 수 있으니 더 나은 프로젝트가 된다면 그쪽이 이길 것임.

HN의 분위기를 그렇게 묘사하는 것은 정확하지 않다고 봄. 다만 우리 중 상당수는 오래전부터 거의 전적으로 최상위 모델로 코딩하고 있음.
나는 3월 이후 직접 코드를 한 줄도 쓰지 않고 10만 줄 이상을 출시함. 코딩에 대부분의 노력을 쓰는 것도 아님. 실제로 잘 작동함. 금요일에는 Opus 5.5로 분산 부하 테스트 서비스를 만들었고, 주말 동안 모델이 그 서비스를 사용해 반복 개선하고 문제를 진단했음.

강압적인 AI 금지는 모두 운영진의 통제와 독단이 지나친 커뮤니티의 한 사례일 뿐임.

“LLM, AI 또는 에이전트의 도움을 받은 코드 기여”를 전면 금지하면서 정작 그 범위를 거의 정의하지 않음. 정책이 형편없이 작성됐으니 QGIS 유지보수자는 집행 가능한 명확한 기준을 마련해야 함.
GPL의 “파생 저작물”과 관련된 법적 모호함이 떠오름. GPL 소프트웨어를 사용하는 것만으로는 다른 조항이 발동하지 않지만 배포하면 달라짐. 그런데 배포의 법적 정의가 무엇인지 불분명함. 그래서 대부분의 소프트웨어 회사가 GPL을 전면 금지하며, 준수할 의지가 있어도 정의가 모호하면 실질적으로 준수하기 어려워 아예 피하게 됨.
반AI 정책도 마찬가지일 것임. 기꺼이 손으로 작성하려는 기여자도 누군가의 AI 감지 기준에 우연히 걸릴지 알 수 없어 프로젝트를 피하게 됨. 마녀사냥식 집행을 막을 장치가 없음.

일부는 AI를 맹목적으로 싫어하지만, 실제로 금지하려는 대상은 완전 자동 코딩이나 적어도 바이브 코딩으로 만든 제출물임. LLM 없이 자기 변경 사항을 뒷받침할 수 없다면 대형 프로젝트에 넣어서는 안 됨.
바이브 코딩을 하지 않고도 LLM을 유용하게 활용하면서 결과를 이해하고, 생산성을 크게 높이는 것은 충분히 가능함.

대부분의 소프트웨어 회사가 GPL을 전면 금지한다는 것은 이상함. 예를 들어 대부분 Linux를 광범위하게 사용함.
내가 익숙한 기준은 내부 사용과 SaaS 제품에서의 GPL 사용은 허용하고, GPL 소프트웨어가 회사 인프라 밖으로 나갈 때는 피하거나 사업상 필요가 크면 법무팀을 참여시키는 것임. 소규모 신생 기업이 아예 금지하기도 하는 AGPL과는 다름.

유지보수자가 집행 주체라면, 어떤 규칙을 만들든 원하는 방식으로 집행할 수 있는 것 아닐까?

추가 정의는 필요하지 않다고 봄. 코드를 만들 때 LLM이나 AI, 에이전트를 사용했는지는 본인이 알 것임. 범위를 넓게 두면 집행이 단순해짐. 세세하게 정의하면 Google의 AI 검색 요약을 본 것도 LLM의 영향인지 같은 논쟁에 빠지게 됨.

나처럼 QGIS가 무엇인지 몰랐던 사람을 위해 덧붙이면, 무료 지리정보시스템(GIS) 임. 지리공간 정보를 생성·관리·분석·저장·시각화하는 도구로, 3D 지도 등을 떠올리면 됨.

역설적으로 LLM이 포인트 클라우드인 LiDAR 데이터를 조작·변환하는 스크립트를 쉽게 작성해주면서 QGIS를 쓸 일이 사라졌음. 전문가도 아니고 주로 등고선 지도를 만드는 정도지만, 작업 과정이 크게 간소화됨. 여기서 소프트웨어의 미래가 보임.

간단한 데이터 변환은 이제 바이브 코딩으로 만든 스크립트가 더 편리한 것이 사실임. 하지만 QGIS의 진짜 가치는 기반 시설, 도시·환경 계획처럼 크고 복잡한 프로젝트의 데이터를 관리할 수 있게 해주는 데 있음.

어떤 초지능이든 이전 작업의 결과를 저장하고 재사용함. 물리 세계가 그렇게 작동하기 때문임. 또 사실로 단정할 수는 없지만, 어떤 초지능이든 안정적인 추상화를 만들고 싶어 할 것이라고 봄. 모든 작업을 저장하고 일부를 재사용하는 것과, 이를 종합해 추상화를 만드는 것은 다른 일임. 추상화에는 손실이 따름. 명시된 계약을 지키지 못할 수도 있고, 애초에 목표로 삼은 문제와 해법의 범위가 잘못됐거나 세상과 요구사항이 바뀔 수도 있음. 결국 누군가 또는 무언가가 유지보수해야 함.
그 끝은 어떤 모습일까? 소수의 연구소가 전 세계 오픈소스 프로젝트의 소유권을 나눠 가질까, 아니면 커뮤니티 주도 프로젝트가 그 어느 때보다 많아질까? 모든 것을 너무 강하게 결합하고 일체화해 몇몇 제품 외에는 쓸 수 없게 만드는 더 나쁜 길도 가능함.

오픈소스 프로젝트를 포크하고 수정하는 난도가 크게 낮아져, 프로젝트 수는 역대 어느 때보다 많아질 것이라고 예상함. 다만 상당수는 사실상 서로 복제품일 것임.