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

• 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”도 지적받으면 피해자처럼 행동한다고 답함