▲

Debian, AI 생성 기여물에 대한 결정을 유보

 (lwn.net)
1P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • 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 생성 기여물 처리 기준은 미정 상태
  • 복잡한 기술 변화와 다양한 의견 속에서, 현상 유지가 가장 실용적 선택으로 평가됨
▲
GN⁺ 11시간전  [-]
Hacker News 의견들

  • 평생 코딩을 해왔지만 손목 부상으로 타이핑이 거의 불가능해진 이후, 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를 썼지만 최대한 검증한 코드”가 훨씬 더 받아들여질 만함

답변달기