Debian LLM 사용에 관한 일반 결의안: 제안 A-D 설명

개요

2026년 7월 25일 Debian 일반 결의안 투표는 프로젝트가 대형 언어 모델(LLM) 또는 기타 생성형 AI 도구를 포함하는 기여를 어떻게 대해야 하는지에 대한 네 가지 경쟁 제안을 제시합니다. 이러한 제안은 완전 금지에서 조건이 있는 허용 프레임워크까지 스펙트럼을 아우르며, 최종 결정 전에 커뮤니티에서 논의되고 있습니다.

제안 A: 완전 금지

제안 A는 LLM 또는 기타 생성형 AI 도구의 사용 또는 도움을 받아 작성된 Debian에 대한 모든 기여를 명시적으로 금지하려고 합니다. 그 범위는 Debian 소스 패키지, 공식 프로젝트 소프트웨어, 웹 리소스, 문서, 번역, 공식 통신을 포함하지만, LLM을 사용하는 상류 프로젝트 및 AI 관련 소프트웨어는 제외합니다. rationale는 네 가지 우려를 제시합니다: LLM 출력물의 저작권 상태 불명확, 품질 및 정확도 문제, 커뮤니티 검토자에 대한 부담, LLM 학습 데이터 스크래핑 및 자원 소비에서 발생하는 윤리적 피해. 의심을 없애기 위해 제안은 Debian이 LLM을 통해 생성된 직접적인 기여를 허용하지 않겠다는 조항을 사회 계약에 추가합니다. 집행은 어렵다고 인정되지만 커뮤니티의 선의에 의존합니다.

제안 B: 조건부 허용

제안 B는 다음과 같은 six 가지 조건이 충족될 때 AI 지원 기여(LLM에 의해 부분적으로 또는 완전히 생성됨)를 허용합니다: (1) 도구 법적 호환성, AI의 이용 약관이 Debian의 배포, 수정, 사용과 충돌하지 않도록 보장; (2) 라이선스 및 atribuição, 출력물에 있는 제3자 저작권 자료가 관련 오픈소스 라이선스 하에 사용될 수 있음을 확인해야 함; (3) 책임, 제출자는 기술적 가치, 보안, 라이선스 준수, 유용성에 대해 전적으로 책임짐; (4) 공개, AI 생성 또는 AI 지원 작업의 상당한 부분이 눈에 띄게 표시되어야 함(예: Git 트레일러를 통해); (5) 대량 또는 자동 변경에 대한 사전 토론, mass‑bug filing 과정과 유사하며 인간 감독자가 있음; (6) 기밀성 및 개인정보 보호, 비공개 또는 민감한 프로젝트 정보를 노출시킬 수 있는 클라우드 기반 AI 사용을 금지함.

제안 C: 공개 요구 사항과 함께 권장하지 않음

제안 C는 완전 금지를 부과하지는 않지만, 모든 기여자가 Debian 작업에서 LLM 사용을 피하도록 요청하고, 의사 결정자들이 실제적으로 LLM 사용을 dissuade하도록 하며, 더 넓은 자유 소프트웨어 커뮤니티가 해당 기술을 자제하도록 합니다. 이는 행동 규범에 여덟 가지 요구 사항을 추가하여 보완합니다: (1) 인간에게 전달되는 메시지는 LLM 도움 없이 인간만이 작성해야 함; (2) Debian 작업에서의任何 LLM 사용은 공개해야 함; (3) 개별 프로젝트와 유지관리자는 LLM 기여를 완전히 금지할 수 있으며, 그러한 금지는 존중되어야 함; (4) 위반은 행동 규범 위반으로 처리되며 신속하고 비례적인 징계 조치의 대상이 됨; (5) 도움 없이 영어로 작성할 수 없는 기여자는 모국어로 작성할 수 있으며, 인간이 작성한 영어 요약은 환영되지만 필수는 아님; (6) 제안은 상류 사용을 고려할 때 현재 완전 금지는 비현실적임을 인정함.

제안 D: Debian‑specific 작업에 대한 AI 기여 허용

제안 D는 AI 지원 관행이 이미 사용되고 있음을 인정하며, 이를 금지하는 대신 기여자에게 책임을 둡니다. 지침은 Debian 프로젝트를 위해 특별히 수행된 코드 및 작업(웹사이트, 애플리케이션, 리소스, 패키지)에 exclusivamente 적용됩니다. 기여자는 작업이 DFSG를 준수하도록 보장해야 하며, 제출된 작업에 대해 전적으로 책임지고, 이를 이해하고 방어할 수 있어야 하며, Signed‑off‑by 태그와 GPG 서명을 직접 적용해야 하며, 생산 인프라에 업로드되는 모든 콘텐츠가 명시적으로 그들에 의해 제출되도록 해야 합니다. 생성형 AI 에이전트 또는 도구의 도움을 받은 작업은 적절한 장소(커밋 메시지, 변경 로그 등)에 이와 같이 표시되어야 하며, 탭 완성과 같은 경량 도구가 무의식적으로 사용될 수 있음을 알리고, 기여자는 해당 규칙이 적용되는 시점을 평가해야 합니다. 마지막으로, 전송된 데이터가 프로젝트에 민감하거나 공개되지 않을 수 있는 경우 클라우드 기반 AI를 사용해서는 안 됩니다.

Hacker News에서의 커뮤니티 토론

댓글 작성자들은 여러 가지 쟁점과 명확히 해야 할 사항들을 강조했습니다:

• @simonw는 이 페이지가 논의되고 투표될 세 개의 별도 제안(A, B, C)을 제시한다고 지적했으며, 최종 결정은 아니라고 했습니다.
• @hkalbasi는 LLMs가 단지 훈련 데이터의 '구문적으로 가능성 있는 조합'만을 생성한다는 주장을 수정했으며, 강화 학습이 LLMs가 훈련 데이터를 넘어갈 수 있게 한다고 지적했습니다.
• @Meneth는 Gentoo가 2년 전에 LLMs를 금지했으며 현재 잘 진행되고 있다고 관찰했습니다.
• @rixed는 upcoming Trixie 출시의 어느 정도가 제안 A에서 제시한 금지를 이미 위반하고 있는지 궁금해했습니다.
• @zzo38computer은 제안 A의 요소(실제로 LLM 출력 또는 무신뢰에 관여하는 기여에 한정)를 다른 경우에 제안 C와 결합하는 것을 제안했으며, 제안 C에서 '도움'의 정의를 의문시했습니다.
• @russfink는 Claude Code를 사용하여 버그를 찾고 수정을 제안하면서 인간이 소스를 편집하고 테스트하는 것이 도움으로 간주되는지 물었습니다.
• @mike_hock는 커뮤니티가 제안 C를 선택하기를 희망한다고 표현했습니다.
• @dismalaf는 Gemini를 광고 없는 Google 검색 프론트엔드로 사용하는 것이 금지된 '사용' 또는 '도움'으로 간주될지 의문을 제기했습니다.
• @mmooss는 기여자가 LLM 출력물이 기존 저작권이 있는 자료를 포함하지 않는지를 어떻게 확인할 수 있는지에 대한 우려를 제기했으며, 실제적인 어려움과 잠재적인 책임 문제를 지적했습니다.
• @nilespotter는 제안 D를 'LLM을 사용하지만 아무도 말하지 말라'고 특징지었습니다.
• @sublinear은 실제 문제는 변경 사항을 정당화하는 토론의 부족이지 LLMs 자체가 아니며, 적절한 검토가 위험을 완화할 수 있다고 주장했습니다.
• @JuettnerDistrib은 OSS가 LLMs의 개발을 가능하게 한 후에 OSS 프로젝트가 LLMs 금지를 고려하는 것이 아이러니하다고 생각했습니다.
• @TZubiri는 제안들이 LLM 출력 사용과 대화 또는 분석을 위한 LLM 도움 사용을 구분하지 않는 점을 비판했습니다.
• @Kon5ole은 엄격한 'LLM 금지' 정책이 LLMs가 개선됨에 따라 유지하기 어려워질 것이라고 예측했으며, 에너지 사용에 대한 윤리적 우려를 인정했습니다.
• @logicallee은 trade‑off를 요약했습니다: LLMs는 코드를 빠르게 생성하고 테스트할 수 있지만 유지관리자의 경험에서 파생된 비문서화된norm을 무시할 수 있습니다.

결론

Debian 프로젝트는 엄격한 금지, 조건부 허용 프레임워크, 공개와 함께 강력한 dissuade, 또는 지침과 함께 수용 방식 중 하나를 선택해야 합니다. 각 제안은 저작권 위험, 품질 보증, 커뮤니티 영향, 윤리적 고려 사항에 서로 다른 가중치를 반영합니다. Hacker News 댓글에서 볼 수 있는 지속적인 논의는 집행, '도움'의 의미, 그리고 광위한 상류 상용 LLM 사용을 고려할 때 금지의 실현 가능성에 대한 깊은 불확실성을 드러냅니다.