▲

Flathub, LLM 기반 제출을 허용하지 않음

 (social.treehouse.systems)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Flathub 제출 심사에서 LLM 기반 저품질 제출이 늘며 자원봉사 리뷰어 부담이 커졌고, 정책을 명확히 하는 배경이 됨
  • 예외는 커뮤니티 참여, 릴리스 주기, CI, 짧은 기간에 만든 저노력 결과물이 아닌 흔적이 있는 프로젝트에 적용될 가능성이 큼
  • 기존의 개발 이력과 프로젝트 건강도 기준만으로는 리뷰 업무량이 줄지 않았고, 규칙 해석을 둘러싼 분쟁만 늘어남
  • 새 정책은 LLM을 일부 쓴 성숙한 FOSS 앱이나 기존 독점 앱 전체를 금지하려는 것이 아니라, 저노력 제출을 막는 데 초점이 있음
  • 일부는 Flatpak 생태계의 배포 파편화 재발과 기업의 Flathub 회피를 우려하며, 완전 금지보다 수수료 부과를 제안함

Flathub의 LLM 제출 정책 변경

  • Flathub 제출 심사에서 LLM 기반 저품질 제출이 늘며 자원봉사 리뷰어의 부담이 커진 점이 정책 변경의 핵심 배경임
  • Sjoerd Stendahl는 Flathub PR 목록에 “AI-slop” 제출이 많았고, 그 규모 때문에 이번 조치가 더 나은 선택일 수 있다고 봄
  • Bart Piotrowski는 프로젝트에 커뮤니티 참여, 릴리스 주기, CI, 짧은 기간에 만든 저품질 결과물이 아닌 흔적이 있으면 예외가 될 가능성이 높다고 밝힘
  • 기존에도 충분한 개발 이력과 전반적인 프로젝트 건강도를 기준으로 저품질 제출을 막으려 했지만, 리뷰 업무량은 줄지 않았고 규칙 해석을 둘러싼 분쟁만 생김

예외와 성숙도 기준

  • Nexi는 저노력 Flathub 제출 문제는 실제지만, AI 생성 또는 AI 보조 코드 전체를 일괄 금지하는 방식은 과도하다고 봄
  • Firefox, VSCode, Chromium 같은 기존 프로젝트까지 예외 없이 삭제 대상이 될 수 있다면, 저품질 제출을 걸러낼 객관적 프로젝트 성숙도 지표가 더 적절하다고 제안함
  • Bart Piotrowski는 성숙도 기준이 이미 사실상 존재했지만, 결과적으로 리뷰 부담을 줄이지 못했다고 답함
  • Nexi는 예외 기준을 정책에 명확히 반영하고, 코드 품질이 너무 낮으면 추가 설명 없이 거절될 수 있다는 단서도 둘 수 있다고 봄
  • Sjoerd Stendahl는 새 정책이 성숙하고 잘 유지되는 프로젝트에 예외를 두며, LLM을 일부 사용한 검증된 FOSS 애플리케이션이나 기존 독점 애플리케이션 전체를 금지하는 정책은 아니라고 봄

생태계 영향과 배포 경로 우려

  • Dmitry Mantis는 이 정책이 Flatpak이 해결하려는 Linux 배포 파편화를 다시 만들 수 있다고 우려함
  • Slack과 Spotify 같은 독점 앱이 Flathub에서 샌드박스 형태로 제공되는 점은 장점이며, 폐쇄형 코드는 작성 방식을 알 수 없다는 이유로 오히려 유리해질 수 있는지 의문을 제기함
  • 새롭고 알려지지 않은 개발자의 독점 애플리케이션은 이 정책이 없더라도 Flathub에 즉시 게시하지 않는 편이 좋다는 반론도 나옴
  • AppImage로만 쓰던 일부 앱이 공식 Flatpak을 지원하기 시작한 흐름은 긍정적이지만, 이런 정책 이후 기업들이 Flathub 진입을 피할 수 있다는 우려가 있음
  • AI 기반 제출에 리뷰 비용을 충당하는 수수료를 부과하는 방식이 완전 금지보다 낫다는 제안도 있음
  • 일정 수준의 사용자를 확보하기 전에는 다른 곳에서 배포하라는 신호가 될 수 있고, 테스트나 문서 자동화 일부에 LLM을 쓴 잘 유지되는 앱이 다른 배포 경로에 정착하면 Flathub로 옮길 동기가 줄어들 수 있음

LLM 도구를 둘러싼 상반된 평가

  • Thomas Fuchs는 LLM 문제가 기술 자체보다 사람과 마케팅의 문제에 가깝다고 봄
  • LLM 기업들이 LLM을 마법이나 개인 작업 노예처럼 판매하고, 사용자가 그 주장을 그대로 믿는 문제가 있다고 지적함
  • 숙련된 사용자가 강점과 약점을 알고 좁은 용도에 쓰면 훌륭한 도구가 될 수 있지만, 업계는 “불붙은 전기톱을 저글링용으로 무료 배포”하는 식으로 공격적으로 홍보한다고 표현함
  • Wolkensteine는 LLM이 전혀 쓸모없다고 보지는 않지만, 대부분의 경우 유용하지 않고 윤리적으로 지지하고 싶은 방식으로 만들어진 유용한 모델은 아직 없다고 봄
  • 온디바이스 모델이 맞춤법 검사나 휴대폰 키보드 자동수정의 단어 예측에는 도움이 될 수 있지만, 오류 없이 할 수 있는 일은 대체로 사람이 쉽게 하면서 배울 수 있다고 봄
  • Ember는 그런 잠재적 용도도 생성형 AI 이전 도구로 가능했고, 드문 경우에는 특정 데이터로 훈련한 특화 ML이 더 낫다고 봄
  • Kroc Camen는 코드 도용, 내재된 편향, 환경 영향 때문에 LLM에는 어디에도 유효한 사용처가 없다고 주장함

커뮤니티 문화와 논쟁의 양극화

  • trisweb는 LLM 생성 코드와 그 사용자를 둘러싼 문화가 오픈소스 커뮤니티를 유지하는 데 필요한 친절하고 협력적인 접근과 맞지 않는 경우가 많다고 봄
  • ragectl는 새 앱에 냉각 기간 같은 철학이 필요할 수 있으며, 여러 릴리스와 두 번째 인간 기여자가 생기기 전까지는 위험할 가능성이 높다고 봄
  • Sjoerd Stendahl는 마녀사냥은 조심해야 하지만, 빅테크의 공격적인 LLM 추진이 사람들의 반발을 키운다고 봄
  • 일부 고용주는 해고 위협과 함께 업무에서 LLM 사용을 요구하고, 검색 같은 단순한 기능도 망가졌으며, “Agentic future”는 매우 좁은 수요인데도 여러 제품이 인간 작업을 닮은 잔여물처럼 변하고 있다고 표현함
  • razze는 검색이나 챗봇에 LLM을 쓰는 문제와 코드에 쓰는 문제는 별개이며, 코드는 증명 가능하고 트레이드오프가 명확하므로 따로 판단해야 한다고 봄
  • Zeeshan Ali Khan는 반LLM 진영의 공격성을 지적했고, Bart Piotrowski는 pro-LLM과 anti-LLM 양쪽 모두에서 양극화가 심하며 “vibecoders”도 지적받으면 피해자처럼 행동한다고 답함

함께 보면 좋은 글 β

▲
GN⁺   [-]
Lobste.rs 의견들

  • "AI가 생성했거나 보조한 코드, 문서, 기타 콘텐츠가 포함된 애플리케이션은 허용하지 않는다"는 건 꽤 강경해 보임
    Flathub은 리눅스 데스크톱 사용자들이 앱을 받는 매우 대중적인 곳이고, 스스로를 "리눅스용 앱 스토어"라고 부르며 1000개 이상의 앱이 있음
    정말 그 앱들 중 어느 것도 AI 보조 코드를 쓰면 안 된다는 뜻인가? 현실적인가? 이미 늦은 것 아닌가?

    • "성숙하고 잘 유지되는 프로젝트에는 예외가 허용될 수 있다"는 문구를 보면, 완전히 바이브 코딩으로 만든 프로젝트를 올려놓고 방치하는 걸 막으려는 의도에 가까워 보임
    • 늦은 때는 없음
      이미 FlatHub에 올라간 프로젝트라도 바이브 코딩된 것으로 드러나면 제거할 수 있고, 명확한 메시지도 보낼 수 있음
    • 이 규칙은 재량껏 집행된다고 봐야 할 듯함
      기존 주요 애플리케이션 중 일부는 예외로 인정될 가능성이 있고, 그런 경우에도 제한은 앱 자체 코드보다 독립적인 flatpak 패키징에 더 많이 적용될 것 같음

  • 이런 강경한 접근이 100% 집행 가능하지는 않겠지만, 기업들이 LLM 도입을 밀어붙이는 상황에서 커뮤니티가 할 수 있는 최소한의 반발로는 이런 강한 입장이 필요함

  • 최근 공급망 관련 사건들을 생각하면, 꽤 타당한 결정처럼 들림

  • 프로젝트가 LLM을 금지하든, 흰머리인 사람이나 키가 정확히 160cm인 사람을 금지하든, 원하는 대로 정할 자유는 100% 지지함
    그 자유를 제한하자는 뜻은 아니지만, 패키지 관리는 LLM의 도움을 크게 받을 수 있는 전형적인 반복 작업임
    자기 코드가 순수예술이나 장인정신의 산물이라고 여기는 사람들도 어느 정도 이해는 하지만, 가장 지루한 일을 자동화하게 두지 않을 이유가 뭔가?

    Arch Linux의 AUR가 시작된 지 얼마 안 됐을 때, 수백 개 패키지를 성공적으로 유지보수하던 사람들이 있었던 기억이 남
    항상 최신 상태였고 거의 깨지지 않았는데, 당연히 자동으로 갱신하고 있었을 것임
    오늘날 같은 일을 LLM 보조로 한다면 거의 확실히 더 견고해질 수 있음

    어쩌면 과정에서 인간을 금지해야 할지도 모름
    공급망 공격 말고 인간이 뭘 기여할 수 있나? 언젠가 내 입장이 맞는지 틀린지 증명하려고 LLM 배포판을 만들어봐야겠음
    그 전에 이 프로그래밍 언어부터 끝내야 함 웃김

답변달기