더는 NEW에 업로드하지 않겠습니다

AI 요약

Debian 개발자 josch는 신규 패키지를 심사하는 NEW 대기열에서 자신이 올린 패키지가 LLM 검토를 받았다는 사실을 다른 개발자에게 들었다고 말합니다. 검토 결과에는 Debian Inference 기반 워크플로로 생성했으며 DFSG 팀원이 작성하거나 확인하지 않았고, 패키지에 대한 결정이 아니며 오류나 누락이 있을 수 있다고 적혀 있었습니다.

제기한 문제

josch는 검토문을 읽고 확인하는 데 개발자의 여가 시간을 쓰게 하면서, 정확하지 않을 수도 있는 결과를 만든 자원까지 낭비한다고 주장합니다. Debian의 생성형 AI 관련 총회 결의안(GR)은 사용을 장려하거나 금지하지 않는다고 명시했지만, 모든 NEW 업로드를 LLM으로 처리하는 일이 사실상 프로젝트의 사용 승인이자 대규모 자동화에 해당한다며 사전 논의와 합의가 있었는지 묻습니다.

요구와 대안

josch는 LLM 검토를 거부할 선택지가 생기기 전까지 NEW에 패키지를 올리지 않겠다고 밝혔습니다. 기본값을 검토하지 않음으로 두고 원하는 개발자만 신청하는 방식을 선호합니다. 또 비공개 모델의 결과는 재현하거나 고치기 어렵지만 Lintian 규칙은 재현 가능하고 수정이나 예외 처리가 가능하다며, 기존 자유 소프트웨어 도구를 개선하는 데 시간을 쓰자고 제안합니다. 프로젝트를 떠나는 것은 아니며 다른 개발자가 업로드하는 방식은 열어 두었습니다.

Hacker News 반응

• @monsieurbanana — 저는 AI 자체에 반대하지 않지만, 자신은 읽지 않은 LLM 결과를 다른 사람에게 읽으라고 하는 데는 분명히 반대합니다. 이번 방식은 그 문제를 만듭니다.
  • @voidUpdate — 다른 방법은 누군가에게 LLM이 만든 결과물을 보내지 않고 실제로 패키지를 검토하는 것입니다.
  • @agwa — 접근 방식에 반대할 수는 있지만, 무급 자원봉사자로 구성된 DFSG 팀을 게으르다고 부르는 건 공정하지 않다고 봅니다. 새 패키지가 Debian에 들어올 때마다 심사해야 하고, 대기열은 프로젝트에서 오래된 병목이었습니다.
• @cadamsdotcom — 거부 선택지만 줘도 문제를 해결할 수 있습니다. 업로드에 "LLM 사용 금지"라고 적으면 실행을 막는 식이면 됩니다. 팀이 원하는 기본 적용 방식도 유지할 수 있습니다.
  • @philipwhiuk — 거부보다 사전 동의 방식이 더 나은 해결책입니다.
• @vconnor — 이메일 스레드에서 성공한 LLM 리뷰 하나와 실패한 리뷰 하나를 무작위로 골랐더니 각각 734단어와 1,535단어였습니다. 두 결과를 전부 읽거나 타당성을 확인하지는 않았지만, 새 절차에서 업로더가 검토문을 읽고 이해하는 데 시간을 써야 한다는 점을 강조하고 싶습니다.
• @WesolyKubeczek — 승인이나 거절을 맡은 사람이 LLM을 보조 도구로 쓰는 건 그 팀의 선택입니다. 하지만 "무슨 말을 하는지 모르고 판단에는 반영하지 않지만, 무슨 도움이 될지 모를 긴 글을 읽어 보라"며 다른 사람에게 던지는 건 좋지 않습니다.
• @viraptor — 유용성을 보여 주는 백테스트 근거와 통계, 간결하고 명확한 검토 체계를 먼저 마련할 수도 있었습니다. 자동 초기 검토에 찬성하지만, 이번에는 구현과 소통을 모두 잘못해 스스로 문제를 만든 것 같습니다.
• @slybot — 관련 총회 결의안은 Proposal E, Choice 5의 책임 있는 생성형 AI 사용입니다. "이런 자동화 과정은 행동과 결과에 책임을 지는 사람이 감독해야 한다"고 명시합니다.

원문: Debian 개발자 메일링 리스트 / 번역·요약: Trawling