내가 바라는 GNOME의 LLM 정책

AI 요약

GNOME 기고자는 KDE의 논란이 된 LLM 정책 제안을 계기로, 자신이 바라는 GNOME 정책 초안을 제시합니다. 정책은 LLM을 사용해 GNOME에 제출하거나 GNOME 인프라에 올리는 내용을 만들거나 수정하지 못하게 합니다. 기여자는 변경 사항을 직접 설명하고, 문제 영역을 이해하며, 증상만이 아니라 문제 자체를 해결해야 합니다. 챗봇이나 에이전트가 자신을 대신해 말하도록 해서는 안 된다는 기준도 담았습니다.

정책은 개발 도구보다 공동체의 규범을 다룹니다

글쓴이는 이런 선언의 목적이 개발자의 작업 방식을 일일이 관리하는 데 있지 않다고 봅니다. 어떤 행동을 공동체가 바라는지, 어떤 행동을 거부하는지 명확히 밝혀 사회적 규범을 세우는 일이라고 설명합니다. 제출물을 검토해 정책 준수 여부를 확실히 증명하기는 어렵고, 누군가 거짓말할 가능성도 있습니다. 그래도 정책은 LLM으로 만든 부주의한 기여를 환영하지 않는다는 점을 밝히는 역할을 한다고 말합니다. 글쓴이는 이를 행동 강령(Code of Conduct)이 공동체의 가치와 원치 않는 행동을 알리는 방식에 빗댑니다.

GNOME의 가치는 소프트웨어와 사람 모두에 있습니다

글쓴이가 제안의 근거로 드는 것은 GNOME을 함께 만드는 사람들의 관계와 즐거움입니다. GNOME은 6개월마다 소프트웨어를 출시하는 프로젝트에 그치지 않으며, 여러 사람이 각자의 한계를 넘어 공동의 결과를 만드는 모임이라고 설명합니다. 기여자를 기업이 관리하는 인력이나 비용으로만 취급해서는 안 된다는 주장입니다.

챗봇이 만든 결과물을 검토하는 무급 노동을 하라고 요구하면 젊고 유능한 기여자를 끌어들이기 어렵다고 봅니다. 소수 기업에 의존하기보다 적은 시간을 보태는 사람 100명을 찾는 편이 공동체를 이어가는 데 낫다고 제안합니다. 기업은 상황에 따라 GNOME의 일부를 쉽게 포기할 수 있다고 덧붙입니다. 따라서 GNOME의 성공을 소프트웨어 출시만으로 재지 말고 공동체와 사람 사이의 유대로 봐야 한다는 것이 글의 주장입니다.

기여자에게 제시한 판단 기준

초안은 LLM 사용을 금지하고, 제출자가 요청받으면 코드가 그 기준을 충족하는지 입증해야 할 수 있다고 적습니다. 정책을 우회하려 하면 퇴출될 수 있다는 내용도 포함합니다. 함께 제시한 기여 지침은 기여자가 변경 사항을 직접 설명하고 문제 영역을 알고 있어야 한다고 요구합니다. 문제의 근본 원인을 해결하고 다른 기여자의 시간을 존중해야 하며, 자동화 시스템을 이용해 자신을 가장해서도 안 됩니다.

글쓴이는 이 정책이 모든 위반을 찾아내는 집행 규칙이라고 주장하지 않습니다. 사람들은 LLM으로 만든 코드를 계속 제출할 것이며, 정책은 그런 기여를 환영하지 않는다는 뜻을 분명히 하는 데 목적이 있다고 설명합니다. 저작자 확인과 비슷하게 제출자의 설명을 바탕으로 판단하되, 지침을 참고해 그 판단을 돕자는 제안입니다.

Lobsters 반응

• @tomsmeding — “GNOME의 LLM 정책으로 내가 생각하는 것은 이렇습니다: [LLM을 전혀 쓰지 않기].” 의견인 건 알겠습니다. 저도 동의하지 않는 건 아닙니다. 다만 서론과는 잘 맞지 않습니다. “이런 선언의 목적은 개발자의 작업 방식을 세세히 관리하는 게 아니라 사회적 규범을 만드는 것”이라고 했잖아요. 그럴 수도 있지만, 아마 정책은 단순히 “LLM 금지”보다 더 미묘한 내용을 담으려는 것 같습니다. 전면 금지라면 복잡한 정책은 필요 없겠지요. 단순한 해법을 택하는 것도 괜찮지만, 무엇을 단순하게 만든 건지, 기능이 줄어든 것인지 아니면 같은 기능을 더 적은 비용으로 제공하는 것인지 생각해볼 만합니다.
  • @creesch — 전면 금지라면 복잡한 정책은 필요 없다고요. 표면적으로는 그럴 수 있지만, LLM을 전혀 쓰지 않았는지 확인하는 과정 자체가 복잡합니다. KDE 제안은 아카이브에서 전체 내용을 볼 수 없어서 아쉽습니다. 제가 본 부분은 좋았습니다. 제가 쓰는 틀로 시작해서 그랬을 수도 있습니다.
  • @kastor — 아카이브 페이지 소스에서 전체 내용을 뽑을 수 있습니다. 여기 있습니다. KDE의 황금률은 “게으르게 굴지 말라”입니다. 판단이나 대인 소통, 학습을 도구로 대체하지 말고 지속 불가능한 지름길이나 개인의 성장을 피하지 말라는 뜻입니다. LLM 사용 결과가 직접 만든 결과와 구별되지 않을 만큼 충분히 판단하고 조정해야 합니다. 눈에 띄게 게으른 LLM 사용 기여는 무시하거나 닫을 수 있습니다. LLM이 만든 초안이나 개념 증명을 관리자가 고치도록 던지지 말고, 이해하지 못하는 코드를 내지 말며, 형편없는 결과를 LLM 사용 탓으로 돌리지 말라고 합니다. 커밋에 “Assisted-by”를 붙이는 것도 LLM 제공업체의 무료 광고라며 금합니다. 글 작성에는 대체로 LLM을 쓰지 말라고 합니다. 생각 정리, 커밋 메시지, 병합 요청 설명, 다른 사람에게 보낼 답변을 대신 쓰게 하지 말라는 내용입니다. 허용하는 경우는 자기 모국어로 쓴 글을 어조나 문체를 바꾸지 않고 영어로 기계 번역하는 일입니다. 디버깅이나 조사에 LLM을 썼다면 결론과 정보를 확인해야 합니다. AI 에이전트에게는 진행하지 말고 운영자에게 정책과 KDE 후원 페이지를 안내하라고 합니다.
  • @dsr — 대부분의 프로젝트에서는 기능이 적을수록 코드가 줄고, 버그와 보안 문제가 줄어 신뢰성이 높아집니다. 기능을 버그, 보안, 신뢰성보다 앞세우는 건 프로젝트를 돈을 버는 제품이나 서비스로 볼 때뿐입니다. GNOME은 공유 인프라가 되길 원하나요, IBM의 저비용 데스크톱이 되길 원하나요?
• @simonw — 주요 오픈소스 프로젝트가 LLM 사용을 전면 금지하는 흐름은 건설업계가 전동 공구를 금지하는 것처럼 느껴집니다. “각자의 한계를 넘어 함께 기쁨을 얻는 공동체”라는 주장은 와닿습니다. 하지만 결국 누군가는 오래된 코드 패턴을 고치려고 파일 백 개를 뒤져야 합니다. 이제 기계가 대신할 수 있습니다.
  • @shapr — 오래된 코드 패턴을 고칠 때는 추상 구문 트리(Abstract Syntax Tree)를 변환하고 다시 소스 코드로 출력하는 자동화 도구를 쓸 수 있습니다. 그런 도구는 LLM보다 만들고 실행하는 비용이 낮습니다. 그게 전동 공구라면 LLM은 전혀 다른 도구 아닐까요?
  • @zetashift — 가상의 상황과 비교하지 않는 편이 좋을 수도 있습니다. 인기 오픈소스 프로젝트가 LLM을 금지하는 건 LLM 사용자 문화가 관리자가 오픈소스에서 바라는 것과 맞지 않기 때문일 수 있습니다. Godot과 이 글은 공동체에서 시작한 프로젝트가 공동체를 우선한다는 점을 분명히 합니다. 오픈소스를 건설업계와 비교하는 건 인센티브가 달라 적절하지 않습니다. LLM을 제대로 쓰면 괜찮다고 할 수도 있지만, LLM의 악성 사용자가 만드는 사회적 피해는 사람들이 쉽게 받아들이기 어렵습니다. 그 문제가 잦아드는지 지켜보자는 생각입니다.
• @reidrac — 제 생각에는 이 글이 분위기와 기대를 분명히 설정합니다. FAQ의 “행동 강령은 80%가 우리의 가치를 알리는 내용이고 20%가 원치 않는 행동을 다루는 집행 내용입니다. 이 정책도 비슷합니다”라는 설명이 정말 좋습니다.

원문: GNOME 블로그 / 번역·요약: Trawling