QGIS, AI 보조 코드 기여 금지 정책 채택

AI 요약

QGIS 프로젝트가 qgis/qgis 저장소에 제출하는 코드 기여에 LLM, AI, 에이전트를 활용하지 못하도록 하는 정책을 채택했습니다. 제안 문구는 AI나 에이전트 기반 작업 흐름을 사용한 사실이 나중에 드러나면 코드를 되돌리고 기여자 권한을 제한할 수 있다고 명시합니다. 단순한 공개나 결과물 검토를 요구하던 이전 정책보다 훨씬 강한 조치입니다.

기존 정책에서 전면 금지로

이전 QEP-408 정책은 LLVM의 AI 도구 사용 정책을 참고했습니다. LLM이 만든 코드를 기여자가 검토하고, Assisted-by 꼬리표로 AI 사용 사실을 공개하도록 했습니다. 검토하지 않은 에이전트 댓글은 허용하지 않았습니다. 그러나 QGIS 기여자들은 절차가 실제로 지켜지지 않았다고 판단했습니다. 제안자 Nyall Dawson은 기존 정책으로 충분히 대응하지 못했고, 그 결과 가치가 큰 기여자 한 명을 이미 잃었다고 설명했습니다.

새 정책은 우선 문을 닫고, 안전성과 적절성을 논의한 뒤 필요하면 사례별로 허용 범위를 다시 정하자는 임시 조치로 제시됐습니다. 이후 자동완성 대체, 번역 같은 사용 사례를 별도 논의로 검토할 수 있다는 설명도 나왔습니다. AI를 이용한 보안 검토나 감사를 허용할지는 이번 정책과 분리해 다루자는 의견이 있었습니다.

유지보수 부담과 기여자의 학습

토론에서 정책을 지지한 한 기여자는 회귀 버그를 고치려고 AI를 활용한 PR 두 건을 만들었지만, 복잡한 QGIS 코드베이스를 충분히 이해하지 못한 채 수정이 가능하다는 착각에 빠졌다고 돌아봤습니다. 기여자가 코드의 동작을 설명하고 책임지는 신뢰 관계가 흔들릴 수 있고, AI에 의존하면 프로젝트를 배우며 실력을 쌓을 기회도 줄어든다는 우려입니다. 새로운 기여자가 나중에 리뷰어로 성장하지 못하면 커뮤니티가 정체할 수 있다고 덧붙였습니다.

반대쪽에서는 AI 사용 자체가 품질 저하를 뜻하지 않는다고 주장합니다. LLM으로 코드 맥락을 찾거나 리뷰를 미리 시뮬레이션하면 실제 문제를 발견하고 PR을 개선할 수 있다는 경험담도 나왔습니다. 하지만 정책 문구의 ‘AI 보조’가 너무 넓어 IDE 자동완성, 설계 브레인스토밍, 번역, 검색 결과에 포함된 AI 답변까지 금지하는지 불분명하다는 지적이 이어졌습니다. 유지보수자 측은 기여자가 스스로 코드를 작성했다고 양심적으로 판단할 수 있는지가 기준이라고 설명했지만, 어디까지가 허용되는지 예시를 명시해야 한다는 요구는 남았습니다.

Hacker News 반응

• @coffeeaddict1 — 코드는 직접 쓰지만, 구현을 정하기 전에 AI로 여러 시제품을 만듭니다. 최종 코드는 자동완성도 쓰지 않고 손으로 작성합니다. 그래도 AI 보조 기여에 해당하나요?
  • @smithofsmiths — 논점은 코드 소유권이 아닙니다. ‘보조’가 반드시 ‘작성’을 뜻하지는 않습니다. 코드를 쓰지 않고 검토를 돕는 일도 보조에 해당할 수 있는데, 정책 문구가 모호하다는 점이 문제입니다.
• @KolmogorovComp — 유지보수자들은 이미 감당할 일이 많습니다. 외부 기여를 받지 않으면서 새 유지보수자를 어떻게 찾을 수 있을까요?
  • @Stevvo — 특정 저장소 하나의 외부 기여만 막는 정책입니다. QGIS 플러그인 생태계나 다른 오픈소스 프로젝트까지 모두 막는 것은 아닙니다.
• @rcxdude — AI 보조가 반드시 코드 품질을 낮추지는 않습니다. 다만 허용하면 저품질 기여가 대량으로 들어와 선별 부담이 커질 수 있습니다. 지금은 흐름을 멈춘 뒤, 나중에 어떻게 다시 허용할지 살펴보려는 것으로 보입니다.
• @perrygeo — AI 기여를 전면 금지하면서 무엇이 금지되는지 정의하지 않았습니다. 모호한 정책은 손으로 코드를 쓰는 기여자까지 위축시킬 수 있습니다.
  • @bornfreddy — AI를 사용했는지 유지보수자가 알아낼 수 없다면 PR은 좋은 결과물일 수도 있습니다. 이 규칙은 저품질 기여가 쏟아지는 흐름을 줄이려는 조치이며, 나중에 바뀔 여지도 있습니다.
• @jcolot — 이제 병목은 코드를 쓰는 일이 아니라 코드가 무엇을 하고 의도대로 동작하는지 계속 파악하는 일입니다. 낯선 사람이 올린 대형 PR을 검토하는 유지보수자라면 부담이 더 클 것입니다.
  • @jebarker — 작성에서 리뷰로 병목이 옮겨갔습니다. 코드가 작동한다는 이유로 대충 검토하면 설계 선택이나 더 넓은 영향을 놓칠 수 있습니다.
• @mpalczewski — 여러 모델이 서로 검토하게 해 AI를 활용한 기여의 품질을 높였다고 생각합니다. 그래도 프로젝트 관리자가 원하지 않는다면 포크하면 됩니다.
  • @bayindirh — QGIS는 전문 분야 소프트웨어입니다. 작은 결함도 중요할 수 있고, 유지보수자는 도메인 지식과 코드베이스의 맥락을 바탕으로 패치를 판단합니다.
• @Gigachad — 요즘 오픈소스에 기여하는 가장 좋은 방법은 자세한 이슈를 작성하는 일일 수 있습니다. 유지보수자가 그 내용을 AI 도구에 넣고 직접 작업하면 피드백을 기다리는 것보다 빠릅니다.
  • @derwiki — 팀에는 한 번 프롬프트를 넣어 만든 덜 익은 PR보다, 그 프롬프트를 GitHub 이슈에 적어 나중에 활용하게 하는 편이 낫다고 PM에게 말해 왔습니다.
• @simonw — “장기적으로 코드 품질이 좋아질 객관적으로 좋은 변화”라고 했는데, 그렇게 보는 이유가 무엇인가요? QGIS가 C++로 작성됐다는 점이 답에 영향을 주나요?
• @Roark66 — AI로 만든 대규모 패치를 직접 쓰고 몇 주간 사용했지만, 다른 모델을 깨뜨릴지나 설계 의도에 맞는지 알 수 없어 PR로 올리지 않았습니다. 완전히 이해하지 못한 코드를 제출해 직업적 평판을 걸고 싶지 않았습니다.

원문: Hacker News / 번역·요약: Trawling