# Debian, AI 생성 기여물에 대한 결정을 유보 > Clean Markdown view of GeekNews topic #27416. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27416](https://news.hada.io/topic?id=27416) - GeekNews Markdown: [https://news.hada.io/topic/27416.md](https://news.hada.io/topic/27416.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-12T05:33:37+09:00 - Updated: 2026-03-12T05:33:37+09:00 - Original source: [lwn.net](https://lwn.net/SubscriberLink/1061544/125f911834966dd0/) - Points: 1 - Comments: 1 ## Topic Body - Debian 커뮤니티가 **AI 또는 LLM 기반 코드 기여 허용 여부**를 논의했으나, 결론 없이 논의를 종료함 - 제안된 초안은 **AI 도구 사용 시 명시적 공개, 책임 명확화, 민감 정보 사용 금지** 등을 조건으로 허용하는 내용이었음 - 개발자들은 **‘AI’ 용어의 모호성**, LLM의 사용 범위, 그리고 **품질·저작권·윤리 문제**를 두고 의견이 갈림 - 일부는 **신규 기여자 온보딩 저해**, **비윤리적 기업 행태**, **법적 불확실성** 등을 이유로 반대 입장을 표명함 - Debian은 당분간 **기존 정책에 따라 사례별 판단**을 유지하며, 향후 논의 지속 가능성을 열어둠 --- ### Debian의 AI 기여 논의 개요 - Debian은 **AI 생성 코드 수용 여부**를 둘러싸고 내부 토론을 진행했으나, **일반 결의(GR)** 발의 없이 종료됨 - 논의는 Lucas Nussbaum이 AI 보조 기여물에 대한 입장을 명확히 하자는 초안을 제시하며 시작됨 - 그는 피드백 수집 후 공식 제출을 검토했으나, 논의가 진정되며 결의안은 발의되지 않음 - 초안은 **AI 도구로 생성된 코드의 공개 의무**, **기여자 책임 명시**, **보안·라이선스 준수 보증**, **비공개 정보 사용 금지** 등을 포함함 ### 용어 정의와 기술 구분 논쟁 - 여러 개발자가 **‘AI’ 용어의 불명확성**을 지적하며, **LLM 등 구체적 기술 명시 필요성**을 강조함 - Russ Allbery는 “AI”가 지나치게 포괄적이라 정책 수립에 부적합하다고 지적 - Sean Whitton은 **LLM의 사용 목적별 구분(코드 리뷰, 프로토타입, 프로덕션 코드)** 을 제안 - Andrea Pappacoda는 **Claude’s C Compiler** 같은 프로젝트는 Debian에 포함되어선 안 된다고 언급 - 반면 Nussbaum은 **도구의 종류보다 자동화된 코드 생성 행위 자체**가 핵심이라 주장함 ### 신규 기여자 온보딩과 비용 문제 - Simon Richter는 **AI가 신규 개발자 학습 기회를 대체**할 수 있다고 우려 - AI는 지도를 받아도 학습하지 않으며, 프로젝트 자원이 지속적 지식 전수로 이어지지 않는다고 지적 - AI 사용이 **유료 도구 의존**을 초래해 기여자 접근성을 낮출 수 있다는 우려도 제기 - Nussbaum은 현재 무료 접근이 가능하나, **향후 비용 문제 발생 가능성**을 인정 - 그는 AI가 오히려 **복잡한 작업 접근성을 높일 수 있다**고 반박함 - Ted Ts’o는 **AI 사용자 배제는 자기모순적**이라며, 기여자 다양성을 제한할 수 있다고 반대함 ### 윤리·저작권·품질 논의 - Matthew Vernon은 **AI 기업의 비윤리적 데이터 수집과 환경 피해**를 이유로 Debian이 명확히 반대해야 한다고 주장 - 그는 **저작권 침해, 비동의 이미지 생성, 허위 보안 보고서** 등 부작용을 지적 - Jonathan Dowland은 **법적 불확실성 해소 전까지 AI 생성물 수용을 제한**하자고 제안 - Thorsten Glaser는 **LLM 기반 코드 포함 프로젝트를 ‘non-free’ 영역으로 이동**해야 한다고 주장했으나, **Linux 커널·Python 등 주요 프로젝트 배제 위험**으로 지지를 얻지 못함 - Allbery는 **AI 코드 품질 논란은 무의미**하다고 지적하며, 인간도 나쁜 코드를 작성할 수 있다고 언급 - Bdale Garbee는 **AI를 진화 단계로 보고 장기적 영향 관찰 필요성**을 강조함 ### ‘수정의 선호 형태(Preferred form of modification)’ 논의 - Nussbaum은 **LLM 입력(prompt)** 이 수정의 선호 형태라고 답변했으나, **비결정성 문제**로 논쟁이 이어짐 - 일부는 LLM이 **비결정적이라 reproducible build에 부적합**하다고 주장 - 다른 이들은 **PRNG 시드와 동일 환경 유지 시 재현 가능**하다고 반박 - 논의는 **determinism, reproducibility, GPU 연산의 비동기성** 등 기술적 세부로 확장됨 ### 결론: 결정을 유보한 Debian - Debian 내부는 **AI 생성 기여물 정의조차 합의되지 않은 상태** - 다수는 **지금은 결의안 투표 시점이 아니며**, **메일링리스트 수준의 논의 지속**이 바람직하다고 판단 - Nussbaum은 **“AI를 허용하되 보호장치를 두는 절충안”** 이 현실적일 것이라 언급 - 현재로서는 **기존 정책에 따라 사례별 판단**이 유지되며, **AI 모델·LLM 코드·AI 생성 기여물 처리 기준**은 미정 상태 - 복잡한 기술 변화와 다양한 의견 속에서, **현상 유지가 가장 실용적 선택**으로 평가됨 ## Comments ### Comment 52851 - Author: neo - Created: 2026-03-12T05:33:37+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47324087) - 평생 코딩을 해왔지만 손목 부상으로 **타이핑이 거의 불가능**해진 이후, LLM과 AI 자동완성, 에이전트 기반 개발 덕분에 다시 고품질 코드를 낼 수 있게 되었음 AI의 **환각(hallucination)** 도 오히려 프롬프트를 다듬고 의도를 명확히 하는 데 도움이 됨 접근성 측면에서 AI는 나에게 필수적인 도구이며, “좋음이 나쁨을 상쇄하느냐”보다 **생태계에 통합적으로 받아들이는 태도**가 중요하다고 생각함 - 네 말처럼 AI를 합리적으로 쓰는 사람도 있지만, 모든 사용자가 그렇다고 가정하는 건 위험함 일부 프로젝트는 **저품질 PR**이 넘쳐나고, 기여자들이 단순히 GitHub 프로필을 채우려는 경우도 많음 결국 중요한 건 “**선의(good faith)**”로 기여하는가의 문제이며, 프로젝트는 그 허용 범위를 명확히 해야 함 - 나도 비슷한 접근을 함. AI에게 어려운 문제를 맡기기보다, 이미 내가 구현하려던 **기술적 해법**을 주고 코드를 생성하게 함 이렇게 하면 리뷰 피로도가 줄고, 예상과 다른 부분만 집중적으로 검토할 수 있음 - 나도 손목 통증이 있어 **Whisper + LLM 조합**으로 음성 입력과 정리를 함. 이메일, 문서 작성, 영수증 분류까지 자동화되어 건강에도 도움이 됨 이제는 이런 기능을 막는 회사에서는 일하고 싶지 않을 정도임 - 나도 RSI가 있어 AI 자동완성이 큰 도움이 되었음. 다만 **에이전트형 AI**는 실시간 C++/Rust 환경에서는 별로 유용하지 않음 접근성 측면은 매우 중요하지만, **저작권과 책임 문제**는 여전히 복잡함 - 코드에 서명하고 자신의 **전문성과 평판**을 걸 수 있다면, AI는 단순한 고급 자동완성 도구일 뿐 “no AI” 규칙의 예외로 봐야 함 - PR(풀리퀘스트) 리뷰는 결국 **신뢰의 문제**라고 생각함. 제출자가 최선을 다했다고 믿는 것임 AI 사용 여부보다, 그것을 **책임감 있게 사용하는가**가 핵심임 - 물론 악의적인 행위자도 존재함. XZ 공격처럼 **지속적 위협(APT)** 이 오픈소스에도 현실임 여러 가짜 계정이 하나의 공격자일 수도 있고, LLM이 만든 코드는 LLM이 보기엔 괜찮아 보이기 때문에 검증이 더 어려움 결국 **PR을 평가하는 게 만드는 것보다 더 어렵게** 된 상황임 - 하지만 나는 여전히 모든 코드를 잠재적 트로이 목마로 보고 검증해야 한다고 생각함 - 리뷰 과정이 **인간이든 AI든 오류를 잡아낼 만큼 견고**해야 함 - AI 기여의 품질 논쟁은 이상함. 품질은 언제나 **제출자의 책임**임 AI를 썼다고 해서 면책이 되는 건 아니며, 오히려 **AI 사용 제한 정책이 선의의 기여자만 해칠 수 있음** - 문제는 LLM 코드가 겉보기엔 좋아 보여도 실제로는 **이해 없이 구현된 코드**일 수 있다는 점임 - 중요한 건 도구가 아니라, 기여자가 리뷰에서 자신의 코드를 **설명하고 방어할 수 있는가**임 나는 AI로 300커밋짜리 포크를 유지하지만 모든 라인을 검토하고 설명할 수 있음 결국 **참여의 질**이 핵심이지, 도구의 종류가 아님 - 진짜 불변 조건은 **책임감**임. 패치를 제출했다면 그 설계와 유지보수까지 책임져야 함 - 하지만 AI는 사람들에게 그 책임을 회피하게 만들 위험이 있음 - 장기적으로 AI가 발전하면 **인간과 AI의 산출물을 구분하기 어려워질 것** 같음 결국 “충분히 좋은” 수준이 되면 인간이 만든 것처럼 보일 텐데, 그때는 어떤 일이 벌어질까 궁금함 - 완벽히 막을 수는 없지만, **정책을 세워두는 것**이 아무것도 안 하는 것보다 낫다고 생각함 지금은 대부분의 AI PR이 저품질이지만, 품질이 높아져도 **법적·이념적 이유**로 거부할 수는 있음 - AI 기여는 결국 **개인의 확장**으로 봐야 함. 계정이 실제 사람에게 속하고, 그 **평판이 걸려 있어야 함** - 갑자기 방대한 코드가 올라오면 AI 사용을 의심할 수 있음. 중요한 건 AI 사용 여부가 아니라 **문제를 이해하고 있는가**임 - AI는 여전히 **토큰 단위 예측**에 머물러 있어서 인간이 설계한 코드와는 구별됨 지나치게 세분화된 추상화나 불필요한 리팩터링이 흔함 인간이 AI를 도구로 쓰는 건 괜찮지만, **AI가 인간을 대체하는 수준**은 아직 멀었다고 봄 다만 **vibecoding 남용**은 리뷰와 유지보수 비용을 급격히 늘리고 있음 - 결국 올바르게 사용하는 사람의 코드는 **인간 코드와 구분되지 않음**. 문제는 도구가 아니라 사용법임 - “작동하면 그걸로 충분함”이라는 입장임 코드가 **기능·문서·테스트·정확성** 기준을 충족한다면 AI가 썼든 사람이 썼든 상관없음 중요한 건 “작동의 정의”를 명확히 하고, **유능한 리뷰 체계**를 갖추는 것임 - AI가 수천 줄의 코드를 한 번에 생성해 PR을 올릴 수 있지만, 결국 **리뷰 가능한 크기로 제한**해야 함 AI가 테스트를 통과하더라도 작성자가 내용을 이해하지 못한다면 위험함 **작업 범위 제한**과 **이전 수작업 기여 이력**이 필요함 - Debian의 정책은 단순함 — “**누구도 상처받지 않게 하자**”는 것임. 좋은 원칙임 - Debian이 다른 사람의 코드를 자기 것처럼 제출하는 걸 금지하는 규칙이 있느냐는 질문이 있었음 사실상 **저작권 침해로 불법**이기 때문에 명시되지 않아도 암묵적으로 존재함 LLM은 사람이 아니지만, 그 코드의 저작권은 여전히 불분명함 - 웹앱이나 모바일앱의 **vibecoding**은 상관없지만, 커널·컴파일러·운영체제 같은 **핵심 인프라 소프트웨어**에 AI를 쓰는 건 위험함 이런 영역에서는 **Ada/SPARK 같은 형식 검증 언어**가 필요함 언젠가 **AI가 만든 제동 시스템**을 단 자동차를 타게 될까 두렵다고 느낌 - 동의함. 핵심 시스템에는 세심한 주의가 필요하고, LLM은 **주의와 저작권 리스크** 모두 부족함 - 사실 자동차 업계는 이미 **AI 이전부터 자동 생성 코드**가 많았다고 들음 - “YOLO식 코드 제출”보다 “AI를 썼지만 **최대한 검증한 코드**”가 훨씬 더 받아들여질 만함