140줄의 세칙을 7줄로 축소, 유서 깊은 프로젝트가 빗장을 걸어 잠근 이유
2026년 9월 24일, 20년 넘게 개발을 지속해 온 오픈소스 지리정보 소프트웨어 QGIS 리포지토리에 PR #387이라는 제안이 등록되었다. 이는 매우 이례적인 조치였다. 관리팀은 정책 문서에서 무려 140줄의 내용을 삭제하고 단 7줄만을 새로 추가하여, 문서 전체를 148줄에서 15줄로 대폭 축소시켰다.
삭제된 것은 기존의 온건한 권고사항 일체였다. 새롭게 들어선 조항은 명확한 단 한 문장이었다. QGIS 저장소는 앞으로 LLM, AI 또는 에이전트의 보조를 받은 어떠한 코드 기여도 수용하지 않는다. 사후에 이러한 워크플로를 사용한 사실이 확인될 경우 제출된 코드는 즉시 되돌려지며(revert), 기여자의 권한은 제재를 받게 된다. 이 제안은 커뮤니티의 압도적인 지지를 받으며 빠르게 머지되었다.
No LLM, AI or agent assisted code contributions are allowed in the qgis repository. If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your contribution, you will be subject to code reversion and contributor rights sanctioning.정책 문서는 버전 1.0에서 2.0으로 갱신되었고, 서명 주체 역시 개별 메인테이너에서 ‘QGIS 프로젝트 전체 기여자’로 변경되었다. 거버넌스 문서의 90% 이상을 덜어냈지만, 집행의 강도는 유례없이 단호해졌다. 자율적 준수에 기대던 과거의 신사협정은 물러설 여지를 두지 않는 확고한 레드라인으로 대체되었다.
그림: 제안의 변경 내역: 방대한 정책 문서가 단 한 단락으로 간결하게 압축되었다. 출처: GitHub(QGIS-Enhancement-Proposals PR #387)
삭제된 옛 정책은 사실 꽤나 너그러운 편이었다. 기여자는 어떤 도구든 자유롭게 사용할 수 있었으나, ‘인간이 루프 안에 머무를 것(Human-in-the-loop)‘이라는 전제조건이 붙어 있었다. 제출 전에 스스로 LLM이 생성한 코드와 텍스트를 끝까지 정독하고 검토해야 하며, 서명한 기여자가 온전히 책임을 져야 했다. 또한 커밋 메시지에 도구 이름을 명시하는 등 도구 사용 여부를 투명하게 밝히도록 요구했다. 당시 문서는 이 규칙이 협업 방식을 규정할 뿐, ‘LLM 생성 코드를 수용할 수 있는지’에 대한 프로젝트 차원의 가치 판단을 뜻하는 것은 아니라고 명시하기도 했다.
그러나 몇 달 지나지 않아 그 길었던 문서는 거친 현실 앞에 무너져 내렸다. 메인테이너 timlinux의 평가는 단도직입적이었다. 이 7줄짜리 짧은 규정으로 전환함으로써 얻는 가장 큰 이점은 모든 모호함이 사라진다는 점이다.
코드 생성은 3초면 끝나지만, 인간의 검토는 한 줄씩 버텨내야 한다
오래된 프로젝트들의 불안감은 검증 비용의 비대칭성에 집중되어 있다. 엔터 키 한 번이면 수백 줄의 코드가 순식간에 작성되지만, 그 코드를 검토하는 작업 속도는 조금도 빨라지지 않았다.
식당 주방에 잘게 썬 감자채를 트럭째로 쏟아붓는 격이다. 기계는 몇 초 만에 물량을 쏟아내지만, 품질 검수자는 통 앞에 엎드려 썩은 부분이 없는지 감자채를 한 가닥씩 골라내야 한다. QGIS가 다루는 데이터는 지리 공간 데이터와 복잡한 기하학적 연산이다. 좌표 투영 변환의 소수점 자리가 하나 어긋나거나 반복문 깊숙한 곳에 메모리 누수가 숨어 있어도 컴파일 단계에서는 아무런 오류도 발생하지 않는다. 생성 측의 비용은 0에 가깝게 떨어졌지만 검증 측의 비용은 단 1원도 줄어들지 않았으며, 그 불균형은 오롯이 인간의 노동으로 메워야 한다.
메인테이너 haubourg는 토론 스레드에서 그 이유를 가장 명확하게 짚었다. 외부 기여자들이 AI를 사용하는 것은 자원봉사 메인테이너들의 어깨 위에 감당하기 어려운 거대한 압박을 얹어 놓았다. LLM이 등장하기 전에도 이 작업은 이미 극도로 힘겨웠다. 도구의 보급은 부담을 덜어주기는커녕, 상류의 생산량만 폭발적으로 키워 하류로 고스란히 쏟아부었을 뿐이다.
그는 두 가지 결말을 제시했다. 코드 유입 속도가 인간의 검토 역량 한계를 넘어서면, 프로젝트는 방치된 PR이 끝없이 쌓이거나 검증되지 않은 코드가 메인 저장소에 유입되는 상황을 마주하게 된다. 두 가지 결과 모두 산업용 기반 소프트웨어가 받아들일 수 없는 파국이다.
그림: 제안 토론 스레드에서 메인테이너가 빗장을 걸어 잠그는 이유를 설명하고 있다. 출처: GitHub(QGIS-Enhancement-Proposals PR #387)
타인의 계정으로 모델과 실랑이하기: 메인테이너는 AI의 숙제를 대신 채점하고 있다
haubourg가 제시한 또 다른 이유는 더 깊은 울림을 준다. 자유 소프트웨어 커뮤니티의 근간은 ‘사람의 네트워크’라는 점이다. 기업과 공공기관이 QGIS를 신뢰하는 까닭은, 필요할 때 프로젝트에 기여할 수 있고 교육, 기술 지원, 기능 개발을 맡길 전문가를 고용할 수 있음을 알기 때문이다. 이러한 전제는 모두 ‘화면 반대편에 소통이 가능하고 책임을 질 수 있는 인간이 존재한다’는 신뢰 위에 서 있다.
그러나 메인테이너들은 무너진 전제의 대가를 온몸으로 치르고 있다. 비슷한 시기 Hacker News에서는 ‘AI 코딩 에이전트가 더 많은 코드를 생산하지만, 더 많은 소프트웨어를 생산하지는 못한다’는 주제의 토론이 큰 반향을 일으켰다. 댓글 창은 오픈소스 관리자들의 생생한 고발장으로 변했다. Plotly 측은 제대로 읽어보지도 않은 3페이지짜리 이슈와 ‘그럴듯해 보이지만 허술한’ 패치가 검토 시간을 갉아먹어 외부 기여 수용 중단을 고민 중이라고 밝혔다. Hatchet은 최근의 PR 검토를 두고 “다른 사람의 계정을 빌려 Claude와 끝없이 입씨름하는 기분”이라고 토로했다. PgDog는 아예 코드 기여 경로를 차단하고 이슈만 열어두었으며, Godot 개발진은 AI가 만든 무성의한 PR에 시달리다 무력한 사과문을 남겨야 했다.
haubourg의 우려는 단지 눈앞의 업무량에 그치지 않는다. 외부 기여에 기계적 소음이 대량으로 섞여 들면, 진지하게 배우려는 진짜 신규 개발자들이 묻혀버린다. 결국 프로젝트의 후속 세대 육성 고리가 끊어지는 것이다. 그가 지키고자 하는 것은 바로 그 대역폭이다. 사소한 수정부터 차근차근 배우려는 인간 초보자들을 맞이할 여력을 남겨두려는 것이다.
빗장을 닫는 것은 제도적 조치이지, 기술에 대한 평가가 아니다
QGIS의 이번 결정을 접할 때 흔히 저지르기 쉬운 오해가 있다. 이 조치가 외부에서 제출되는 코드를 대상으로 하고 있다는 점을 간과하는 것이다. 프로젝트가 AI 기술 자체를 전면 부정한 것은 아니다. haubourg는 거대언어모델을 코드 검토, 감사, 보안 점검 등의 목적으로 활용하는 방안은 별도의 트랙에서 논의되어야 한다고 분명히 밝혔다. 그는 사용자 콘퍼런스에서 먼저 의견을 나눈 뒤 공식 의제로 올릴 계획이다.
이러한 구분은 매우 중요하다. 동일한 도구라도 문지기의 손에 쥐어지면 결함을 찾아내는 탐상기가 되지만, 문밖의 흙탕물 속에 섞여 들면 진흙과 모래가 된다. 제도가 가로막아야 하는 것은 책임 소재가 증발한 결과물이지 도구 자체가 아니다.
140줄의 유연한 지침에서 7줄의 강경한 전면 금지로 회귀한 것 역시 이 논리의 극단적 귀결이다. 생성 속도는 눈부시게 빨라지는 반면 검증 능력은 제자리에 머문다면, 자율적인 규약에 의존하던 방어선은 무너질 수밖에 없다. 병목은 더 이상 코드를 작성하는 단계가 아니라, 그 코드가 무엇을 하는지 검증하는 단계에 있다. 빗장을 굳게 걸어 잠그는 것은 사람과 사람 사이의 신뢰와 대화가 온전히 유지되는 환경을 지켜내기 위한 선택이다.
참고 링크:
- QGIS 제안 PR #387(QEP428)
- QGIS 제안 토론 스레드 메인테이너 발언 기록
- Hacker News: AI 코딩 에이전트가 더 많은 코드를 생산하지만, 더 많은 소프트웨어를 생산하지는 못한다
- Plotly, Hatchet, PgDog, Godot 메인테이너의 공개 피드백
