Debian NEW 큐에 LLM 리뷰가 붙자 개발자 "옵트아웃 없으면 업로드 안 한다"
- Debian 개발자 Johannes Schauer Marin Rodrigues가 NEW 큐 처리에 공지 없이 LLM 리뷰가 붙었다며, 옵트아웃 수단이 생기기 전까지 NEW 업로드를 하지 않겠다고 선언함
- 리뷰문에는 'Debian Inference based workflow를 쓴 LLM 리뷰이고 DFSG 팀 구성원이 작성하거나 검토한 것이 아니며 틀릴 수 있다'는 면책 문구가 그대로 붙어 있음
- 그는 이번 조치가 2026년 GR의 '대규모 자동화 작업은 사전 논의와 합의를 거쳐야 한다' 조항을 어긴 것으로 보고, 기본값을 'LLM 리뷰 없음'으로 두고 개발자가 직접 옵트인하는 방식을 요구함
- Lintian은 같은 입력에 같은 결과를 주고 고칠 수도 있지만 LLM 모델은 바이너리 블롭이라 버그를 고칠 수 없다는 점을 자유 소프트웨어 원칙의 근거로 들음
- HN 스레드에서 인용된 대시보드 사례로는 성공 리뷰가 734단어, 실패 리뷰가 1,535단어(약 5쪽)여서 업로더가 읽어야 할 분량이 크게 늘었음
Hacker News opinions
Debian이 빌드 과정에 외부 LLM을 넣는 게 핵심 가치랑 정면으로 부딪히는데 대안이 없다는 게 슬프다. 이럴 거면 컴퓨터 다 처분하고 염소 키우러 가고 싶음.
OpenBSD 쪽 메일 링크 보면 대안이 없다는 말이 좀 과하다는 걸 알 수 있음.
모두가 생성 AI 출력에 시달리는 상황이라, 유일한 대응은 LLM으로 맞받거나 EU처럼 워터마킹해서 탐지하는 쪽밖에 없어 보인다. 아직 그 단계는 아니지만.
다른 방법은 간단함. LLM 출력을 뿌리지 말고 패키지를 직접 리뷰하면 되지.
NEW 큐는 아무나 못 올린다. DD나 DM만 업로드할 수 있는데 여기서 무슨 스팸 문제가 있다는 건지 모르겠음.
LLM 슬롭에 LLM 슬롭으로 맞대응하는 게 해법이란 건가.
내가 소유하지 않은 프로젝트는 예고 없이 바뀔 수 있고 거기 쏟은 시간이 사후에 헛수고가 될 수 있다는 걸 보여주는 사례임.
난 반AI는 아닌데, 자기가 안 읽은 LLM 출력을 남에게 읽히는 건 반대임. 무시하면 큐 순위가 밀리는 보상 구조까지 붙였더라.
결국 한 무리가 게을러서 자기 일을 다른 무리에 떠넘기는 문제임. 도구가 AI일 뿐이고.
스크립트가 만든 리뷰에도 같은 생각인가? 그건 괜찮고 LLM만 문제인 이유가 궁금함.
핵심은 사람 사이 소통을 망친다는 거임. 코드 작성에 쓰는 건 좋지만 남에게 던질 때는 자기 말로 정리하거나 최소한 읽고 덜어내야지. LLM 출력 그대로 붙이는 건 무례한 수준임.
AI 인터페이스로 은행 안 해도 되지만 기능이 빠지고 월 요금이 붙는다는 식으로 사회 전반에 퍼질 게 걱정됨. LLM 채점을 거부해도 인간 채점자는 과로해서 짜증날 거라는 경고까지 붙을 듯.
옵트아웃 하나면 풀릴 문제를 너무 크게 키운 것 같다. 업로드에 'No LLMs please' 한 줄 넣으면 LLM이 안 돌게 하면 되는데.
Debian은 쉬운 길 대신 옳은 길을 가는 걸로 유명했는데 이번엔 반대인 것 같아 아쉽다.
LLM이 얼마나 자주 틀리는지가 궁금하다.
개발자가 그걸 확인하느라 시간 쓸 이유가 없음.
잘못 짚은 질문임. 어떤 모델을 쓰고 요청을 어떻게 쪼개 보내는지 공개되지 않은 조직 구조가 문제지.
대시보드에서 성공 리뷰 734단어, 실패 리뷰 1,535단어를 봤는데 거의 5쪽임. 왜 실패했는지 알려고 그걸 다 읽으라고?
BSD 계열은 hard anti-AI인데, LLM 출력의 라이선스를 증명할 수 없어서 BSD 라이선스로 넣을 수 없다는 설명이 제일 명확했음. 리눅스는 돈과 기업 지원이 있어서 신경 안 쓰는 것 같고.
iTerm2 최신 버전에서 메뉴바에 마우스만 올려도 AI 이미지 툴팁이 뜨더라. 취향 문제를 떠나서 왜 넣었는지 모르겠음.
GR 투표에서 채택된 'Responsible Use of Generative AI' 조항에도 자동화 프로세스는 책임지는 인간이 감독해야 한다고 적혀 있음.