QGIS가 AI 지원 기여에 대해 제한하는 이유

대화

|
안녕하세요, 이 강한 주장이 왜 우리가 이전의 'Human in the loop' 정책보다 더 나아가야 하는지에 대한 배경 설명이 필요할 것 같습니다.
그래서 이러한 이유로 저에게는 큰 지지(huge +1)입니다. 저는 LLM을 검토, 감사 및 보안 목적으로 사용하는 것에 대해 또 다른 주제를 열고 싶지만, 이것은 매우 별개의 논의라고 생각하며, 공식적인 논의가 있기 전에 사용자 컨퍼런스에서 토론을 열겠습니다. 상황이 너무 빠르게 움직이고 있으니, 먼저 이 QEP(QGIS Enhancement Proposals)부터 다루도록 합시다. |

|
안녕하세요, 제가 버그의 원인을 조사하고, 수정 사항을 제안하며, 코드를 검토하기 위해 2개의 AI 지원 회귀 수정 PR(Pull Request)을 만들었을 때, 이것이 QGIS의 이미 취약한 리뷰어 커뮤니티에 어떤 해를 끼칠 수 있는지 깨닫지 못했습니다. 저는 명백히 QGIS처럼 복잡한 프로젝트의 버그를 수정할 만큼 충분한 기술을 갖추지 못했지만, LLM은 그것이 가능하다고 착각하게 만듭니다. 몇 토큰(tokens) 후에 버그가 고쳐집니다. 이렇게 함으로써 우리는 리뷰어와 기여자 사이에 신뢰 계약을 깨뜨렸습니다. 이 프로젝트처럼 큰 곳에 기여하려면 무엇을 하는지 알고 있다는 계약 말입니다. 저는 두 번째 효과도 있을 것 같지만 온라인에서 많이 읽지는 않았습니다: 이런 종류의 용이성을 제공함으로써, AI를 사용하는 기여자들은 배우는 것이 거의 없거나 아무것도 배우지 못하고 프로젝트 내 기술을 쌓지 못합니다. 그들은 스스로 리뷰어가 되기를 진정으로 기대할 수 없게 되고, 커뮤니티가 정체됩니다. 이것은 열정적인 오픈 소스 사용자이자 초보 개발자로서 오늘날의 세상에서 제 자리를 찾으려고 노력하는 사람의 관점이며, AI가 실제로 모든 것을 더 쉽게 만들지 못합니다. 달리기를 배우기 전에 걷는 법을 배워야 합니다.
|

저는 이에 동의하지만, 이 시스템을 시작한 이후로 제출된 보안 권고 사항(security advisories)의 100%가 AI를 사용하여 작성되었다는 점은 지적하고 싶습니다. (대부분 저희 웹사이트에 관한 것이지 QGIS 코어 자체는 아닙니다.) |

제 비판을 오해하지 말아 주십시오. 저는 'AI'를 둘러싼 현재의 광풍이 윤리적, 사회적, 경제적 등 여러 면에서 거대한 문제라고 생각합니다. 그리고 그 남용이 유지 관리자(maintainers)와 개발자들에게 가하는 크고 불공평한 압박을 목격하고 있습니다. 이 모든 것이 일어나지 않았으면 좋겠지만, 지금은 이렇게 되었습니다. 저는 이것이 비윤리적이라고 간주되는 것을 금지하는 '정치적' 움직임일 수도 있다고 충분히 이해할 수 있는 몇 가지를 강조하고 싶습니다. 하지만 그것이 의도인가요? 개발자들의 압박을 줄이기 위함인가요? 아니면 'AI'에 대한 강력한 입장을 표명하기 위함인가요? 어쨌든, 저는 이것이 더 명확하고 아마도 더 강할 수 있다고 생각합니다. 현재 작성된 대로라면, 저는 정책을 이해할 수 있을 것 같습니다. 가끔 QGIS 코어의 C++ 세계로 작은 발걸음을 내딛는 용기를 느끼는 사람으로서, 저는 LLM(대규모 언어 모델)이 코드에서 추가적이고 명백하지 않은 맥락을 발견하는 데 유용하다는 것을 알게 되었습니다. 이들은 종종 틀리지만, 결과가 인간에게 코드를 더 깊이 이해하고 실제로 더 나은 기여를 만드는 데 도움이 될 수 있다는 것이 저의 확고한 믿음입니다. 저는 또한 LLM이 리뷰어 시뮬레이션을 얻는 데 유용할 때도 있습니다. 코드를 던지고 검토를 받고, 목록형 결과물(listicle)을 받은 다음, 쓰레기나 관련 없는 부분을 버리고 나머지를 살펴보며 실제 문제를 찾고 수정한 다음, 약간 덜 나쁜 PR(Pull Request)을 가지고 동료들에게 가져가는 식입니다. IDE에서 제공하는 'Clippy'와 같은 기능으로, 개발 과정에 때로는 유용한 피드백이나 비판을 주는 것입니다. 이러한 용도는 제가 이해하기로는 이 정책에 의해 금지될 것입니다.

네, 우리가 목욕물과 아기를 함께 버릴 수도 있다는 것을 알고 있지만, 그 아기는 생존할 수 없을지도 모릅니다. 그래서...

의도는 이것이 '돌에 새겨진 영원한' 정책이 되는 것이 아닙니다. 오히려 '닫힌 문으로 시작하되, 안전하고 적절한 논의가 이루어진 경우에만 선택적으로 조금씩 열어가는 방식'입니다. 따라서 우리는 매우 제한적인 상태로 시작하며, 나중에 누군가(다른 사람)가 'AI를 IDE의 자동 완성 기능 대체재로 사용할 수 있다' / 'AI를 언어 번역에 사용할 수 있다' 등과 같은 사례들을 제기하고, 이 모든 것은 개별 사례별로 고려될 것입니다. |

이것은 이전 QEP(Quality Enhancement Proposal)에 대한 수정으로 의도되었습니다. 그것은 명백히 작동하지 않았습니다 (지적해주셨듯이, 그 과정은 현실에서 일어나지 않았고, 우리는 이미 최소한 한 명의 매우 높은 가치 기여자를 잃었습니다). 따라서 위에서 언급했듯이, 우리는 문을 닫아버림으로써 수정하고, 나중에 얼마나 멀리 열 것인지를 선택할 것입니다. |

이번 주 말까지 개방하는 것이 가능할까요? 그 이유가 있습니다.
|

늦어서 죄송합니다... 저는 이 정책에 대해 큰 걱정이 있습니다. 실제로 무엇이 금지되는지가 그다지 명확하지 않습니다. Claude Code/Github Copilot CLI 등 사용하기? 물론 그것은 허용되지 않는다는 것이 명확합니다. 하지만 LLM 기반 자동 완성 기능은요? LLM이 아닌 AI(예를 들어, Jetbrains 기반 IDE는 오랫동안 ML 모델을 사용하여 자동 완성 결과를 순위 매겨 왔습니다)는요? 디자인 아이디어를 브레인스토밍하기 위해 ChatGPT를 사용한다면요? 오류 메시지를 검색하다가 Google의 AI 답변에서 우연히 정답을 본다면요? PyQGIS에서 발생하는 문제에 대한 도움을 받기 위해 Claude에게 요청했는데, 그것이 실제로는 QGIS Core 버그임을 깨닫고 수동으로 수정하게 된다면요? 영어로 된 용어를 생각할 수 없어 모국어로 번역한 후 코드에 사용하는 것은 어떨까요? 여기서 조금이라도 유연성을 부여하면 문제가 지속될 것이라는 두려움이 있다는 것을 알고 있지만, 저는 이 정책이 매우 명확해야 한다고 생각합니다. 특히 페널티를 고려할 때 더욱 그렇습니다. 제안을 드리자면:
(예: 'AI'라는 너무 광범위한 용어를 삭제하여)

Jetbrains의 랭킹 모델은 의문스러우며, 예시로 검색/브레인스토밍 등을 허용한다고 명확하게 '작성된(written)'을 명시하고 있습니다. 가급적 정책에는 무엇이 허용되고 무엇이 허용되지 않는지에 대한 정보가 담긴 예시도 포함되어야 합니다. |

저는 준수 여부를 측정하는 기준은 '당신이 양심적으로 코드를 직접 작성했는가'라고 생각합니다. 저희는 당신의 컴퓨터를 들여다보고 무엇을 했는지 볼 수 있는 구조가 아닙니다. 당신은 자신의 뇌가 원하는 코드를 만들었는지 아니면 다른 사람의 뇌가 만들었는지 알 것입니다. |

@nyalldawson과 이 QEP(Quick Enhancement Proposal)를 지켜보는 다른 분들께 말씀드립니다. @3nids가 언급했듯이, 저희는 UC2026에서 이에 대해 논의한 적이 있습니다. 예정대로 투표를 진행합시다. 이것이 통과한다면 분명히 이 문을 열어보려는 새로운 QEP들이 생겨날 것입니다.... 하지만 우리 모두 같은 배에 타고 같은 방향으로 노를 저을 수 있도록 한 번에 하나의 사용 사례부터 다루도록 합시다. |

문서화, 버그 보고서, 토론, PR 설명, 댓글 등 GitHub의 모든 작성된 상호작용(written interactions)을 포함할 것을 강력히 권장합니다. 이러한 기록들은 종종 코드 자체보다 더 상세하고 추출적입니다. |

@timlinux 네, 하지만 거기에서도 현재 제안에는 빠져 있는 동사 '쓰다(write)'를 포함하셨습니다. 분명히 암시될 수는 있겠지만, 명시적인 것이 암묵적인 것보다 낫습니다 (Zen of Python을 인용하며). 수정하여 명확히 하자면: 저는 정책의 의도 자체(특히 단순히 작성에 관한 경우)는 개의치 않지만, 단어 선택이 걱정됩니다.