LLM 정책: 대가를 따지지 않는 진보

AI 요약

GNOME과 KDE에서 LLM 사용 규칙을 논의하는 가운데, 글쓴이는 쟁점이 단순히 개발 절차에 있지 않다고 봅니다. FLOSS가 어떤 가치를 위해 존재하는지, 즉 결과물의 개선만 추구하는지 아니면 함께 만들고 배우는 공동체의 과정도 중시하는지를 묻습니다.

공동체와 완성도

글쓴이는 FLOSS를 바라보는 관점을 ‘집단주의(collectivism)’와 ‘완성주의(completionism)’로 나눕니다. 집단주의는 함께 목표를 이루는 과정과 그 안에서 생기는 유대, 배움을 가치로 봅니다. 완성주의는 소프트웨어를 제품으로 보고 더 낫고 빠르고 안전하게 만드는 일을 우선합니다. 기술 문제를 개인적으로 해결하는 재미는 중요하지만, 동료는 공동체 구성원이라기보다 함께 일하는 사람에 가깝습니다.

두 관점은 지금까지 공존했지만, LLM이 개발 작업을 대신하면서 균형이 흔들린다는 것이 글쓴이의 진단입니다. LLM이 목표의 80%를 채워주면 멘토링이나 토론, 다른 사람을 설득하는 과정을 ‘낭비’로 여기기 쉬워집니다. 특히 자신을 전문가라고 생각하는 사람은 나머지 20%도 직접 완성할 수 있다고 믿을 수 있습니다. LLM이 중립적인 도구처럼 보이는 만큼, 결과물에 이의를 제기하는 행위도 객관적인 진보에 반대하는 것처럼 포장될 수 있다고 지적합니다.

진보에 따르는 비용

글쓴이는 이런 태도를 ‘전문가 슬롭(expert slop)’이라고 부릅니다. 자기 판단을 과신하는 개발자가 LLM 산출물을 진보로 규정하면, 다른 기여자는 함께 문제를 푸는 사람이 아니라 작업을 늦추는 장애물로 취급될 수 있습니다. 그 결과 멘토링과 논쟁, 협업이 사라지고 소프트웨어를 완성하는 일만 남는다고 우려합니다.

비용은 프로젝트 안에만 머물지 않습니다. 글쓴이는 데이터센터의 무책임한 운영, 소비재 가격 상승, 투자 거품이 꺼질 때 연금 수급자가 입을 피해 등을 LLM 산업의 외부 비용으로 듭니다. 글로벌 사우스에서 엘니뇨로 피해를 볼 사람들까지 언급하며, 개발자가 문서 읽기나 보일러플레이트 작성, 낯선 코드 학습, 동료와의 협업을 피하는 대가를 화면 밖의 사람들이 치른다고 주장합니다.

원칙을 지키는 소프트웨어

글쓴이는 약 10년 전 Allan Day가 GNOME을 ‘원칙 있는 소프트웨어(Principled Software)’라고 설명한 일을 언급합니다. 편의나 유행, 압박 때문이 아니라 옳다고 판단한 일을 코드와 디자인에서 실천하는 태도입니다. 책을 읽는 이유가 요약을 더 효율적으로 논의하기 위해서만은 아니듯, FLOSS에서도 생산성만으로 공동 작업의 가치를 판단해서는 안 된다고 말합니다.

글쓴이는 LLM 생산성 향상이 실제라기보다 자기 인식에 가깝고, 기술주 성장과 엔지니어의 참여를 유지하려는 대기업의 서사라고 단언합니다. GNOME은 LLM 없이도 30년 동안 엔지니어링, 디자인, 현지화, 포용과 협업을 이어왔다며, LLM이 부추기는 개인주의 때문에 그 유산을 버릴 필요가 없다고 주장합니다.

Reddit 반응

• @u/SinnohConfirmed — Linux와 FOSS 커뮤니티에서 LLM을 받아들이는 범위가 빠르게 넓어지는 모습이 두렵습니다. 자유를 위해 편의를 포기하던 Linux 이용자 중 상당수가 이제는 악의적이고 수익도 내지 못하는 거대 기술 기업 몇 곳에 소프트웨어 개발 대부분을 맡기자고 말하는 듯합니다. 하드 드라이브는 쓸모없으니 모든 것을 Google Drive에 저장하자는 말과 비슷합니다. LLM이 계속 쓰이더라도 지금처럼 대부분의 AI 이용이 규제받지 않는 기술 봉건 제국을 돕는 상황을 당연한 미래로 받아들이고 싶지는 않습니다.
  • @u/Psionikus — 편의를 포기하는 일 자체가 미덕은 아니었습니다. 어떤 사람에게 자유란 사용자를 붙잡아 두려는 플랫폼이 일방적으로 통제하지 못하게 하는 일이었습니다. 또 다른 사람에게는 재능과 끈기를 가진 사람이 소프트웨어를 개선하고 정당한 경력을 쌓는 데 장애물을 두지 않는 일이었습니다. OSS가 우리 삶을 더 낫게 만든다는 믿음을 포기한 뒤에야, 끝없는 고집을 도덕적 가치인 것처럼 포장하기 시작했습니다.
• @u/DaRealGladi8r — 제 걱정은 Asahi 프로젝트 등이 제기한 법적 문제와는 다릅니다. 저는 ‘중독’이 걱정됩니다. 처음엔 놀라울 정도로 편하고 값도 보조받는 듯합니다. 하지만 그걸 필요로 하게 된 다음엔 어떻게 될까요? 실제 가격이 적용되면 어떻게 될까요? 회사가 규모를 줄여 인사팀과 면담해야 할 사람이 늘어날지도 궁금합니다.
  • @u/ComprehensiveSwitch — LLM 가격이 의미 있게 보조된다는 주장은 좋은 근거가 아닙니다. 직접 운영하는 사람과 여러 제공업체가 추론 비용을 확인하고 있습니다. 공개 가중치 모델과 성능을 비교해 독점 모델의 규모와 비용도 추정할 수 있습니다. 이 주장은 타당하지 않습니다.
• @u/AssistingJarl — “AI를 쓰는 선임 개발자가 쓰지 않는 선임 개발자보다 낫다”는 말은 무엇을 기준으로 하는지, 장기적으로 어떤 결과를 낳는지 묻고 싶습니다. 코드 작성량이 대부분의 프로젝트에서 병목인가요? 사람이 쓴 코드와 LLM 코드의 외부 비용은 같은가요? 검토자가 이해하기 어려운 코드가 쌓이면 누가 그 부담을 집니까? LLM을 쓰는 프로젝트에 참여하지 않는 제 선택을 극단적이라고 볼 수도 있지만, 저는 엄격한 ‘LLM 작성 코드 금지’ 정책이 있는 프로젝트에 시간을 보태고 싶습니다.
  • @u/Mysterious_Focus6144 — 선임 개발자가 LLM을 쓴다고 시스템 설계를 다시 살펴보지 않을 이유가 무엇인가요? 오히려 원래 작성자가 떠나 구조만 누적된 시스템을 이해하는 데 LLM이 도움이 될 수 있습니다.
  • @u/AssistingJarl — LLM이 소프트웨어 개발에 쓸모 있을 수 있다는 점 자체에는 동의합니다. 하지만 논의가 전면 금지와 무조건 수용이라는 두 극단으로 갈리는 듯합니다. 장기적으로 적절한 조합은 모르겠습니다. 다만 여가 시간을 들여 오픈소스에 참여할 때는 엄격한 ‘LLM 작성 코드 금지’ 정책을 둔 프로젝트를 고르는 편입니다.
• @u/DrollAntic — 회사들이 형편없고 일부는 실패하더라도 기술은 남을 것입니다. 닷컴 버블 때 모두가 뛰어들고 시장이 붕괴한 뒤에도, 재건된 기술은 세계 상거래의 기반이 됐습니다. AI와 함께하는 선임 개발자는 그렇지 않은 개발자보다 더 많은 일을 합니다. 품질은 누가 도구를 쓰고 코드를 제대로 검토하느냐에 달렸습니다.
  • @u/AssistingJarl — “더 많은 일을 한다”는 말은 어떤 기준인가요? 코드 생산량이 실제 프로젝트의 병목인지, 사람이 작성한 코드만큼 유용한지, 검토할 시간이 있는지도 물어야 합니다. 고속도로가 생겼다는 비유도 낭만적으로만 볼 수 없습니다. 미국 고속도로망은 여러 도시의 가난한 소수자 거주지를 파괴했고, 지금은 그 길을 지하로 옮기려는 곳도 있습니다. 더 많은 코드를 쓰는 일이 어떤 문제를 누구를 위해 해결하는지부터 따져야 합니다.
• @u/MatchingTurret — 커널 프로젝트는 기술을 위한 프로젝트이며, 오픈소스 작업의 사회적 측면은 동기 부여가 되더라도 부수적인 혜택입니다. Linux 커널은 사회운동 프로젝트가 아니며, 앞으로도 아닙니다.
  • @u/PoL0 — 프로젝트마다 어디에 설지 선택할 수 있습니다. 글은 어느 쪽의 입장을 강요하지 않습니다.
• @u/slimepop6 — 공동체가 중요하게 여기는 가치가 마음에 들지 않는다면 포크해 다른 가치를 가진 공동체를 만들면 됩니다. 이 글의 외부 비용은 LLM 자체보다 자본주의적 데이터센터 확장에 대한 비판입니다. GPU에서 Qwen을 실행하면 글이 말한 외부 비용에 기여하지 않습니다. 문제를 만든 자본 대신 이웃을 부끄럽게 만드는 글은 실제 문제를 해결하지 못합니다.
  • @u/Educational-Goal279 — 로컬 모델도 자본주의적으로 확장된 데이터센터에서 비윤리적으로 훈련됐습니다. LLM을 쓰는 데 자본주의를 벗어난 방법은 없습니다.
• @u/throwaway6560192 — KDE 초안을 ‘LLM 친화적’이라고 부르는 건 다소 오해를 부를 수 있습니다. 초안의 주된 내용은 대충 만든 LLM 패치 제출을 막는 것이었습니다. LLM을 쓸 때도 사람이 결정하고 결과를 수정해야 하며, 단순히 프롬프트만 입력하는 ‘고기 대리인(meat proxy)’이 되지 말라고 했습니다. 커밋 메시지나 리뷰 답변을 LLM으로 작성하지 말라는 지침도 있었습니다. 이런 내용을 통째로 ‘LLM 친화적’이라고 요약하기보다 구체적으로 설명해야 합니다.

원문: diegoe.be / 번역·요약: Trawling