의존성에 LLM 생성 코드 금지

 (joeyh.name)
1P by GN⁺ | ★ favorite | 댓글 1개
  • git-annex는 LLM 생성 코드가 포함된 의존성 없이 빌드되도록 지난 한 달간 약 100시간을 들여 점검됨
  • 이 작업은 개별 코드보다 전체 의존성 트리를 계속 추적해야 하는 현실을 드러내며, 유지보수 부담을 크게 키움
  • 점검 중에는 대규모 LLM 생성 변경의 무설명 되돌림, 26,000 LOC 코드베이스의 10,000줄 변경, 1,489줄짜리 일관성 없는 커밋 메시지 같은 사례가 확인됨
  • 의존성의 품질 정보를 추가로 얻은 점은 긍정적이지만, Software Freedom Conservancy나 FSF 같은 조직 차원의 대응에는 회의적인 시각이 남아 있음
  • LLM으로 설정 추가나 포맷팅 변경을 쉽게 만들 수 있어도, 그런 커밋은 협업 신뢰와 프로젝트 참여에 직접적인 비용을 만들 수 있음

git-annex 의존성 점검

  • git-annex는 LLM 생성 코드를 포함한 의존성 없이 빌드되도록 약 한 달 동안 약 100시간을 투입해 점검함
  • 현재까지는 목표를 달성한 상태로 보임
  • 관련 페이지로 git-annex no LLM code가 있음
  • 문제의 핵심은 프로그램의 전체 의존성 트리를 계속 검토해야 하는 부담에 있음

점검 중 드러난 사례와 영향

  • 확인된 사례들은 단순한 취향 문제가 아니라 유지보수와 신뢰의 문제로 이어짐
    • 큰 규모의 LLM 생성 변경이 다음 릴리스에서 아무 설명 없이 되돌려짐
    • 26,000 LOC 코드베이스에 10,000줄 변경이 들어갔고, 커밋 메시지는 1,489줄의 일관성 없는 내용이었음
    • 다른 프로젝트에서 코드를 복사하라는 LLM 프롬프트가 있었고, 운 좋게 저작권 침해를 피한 것처럼 보였음
  • 이번 작업으로 의존성의 품질에 대한 추가 정보를 얻었고, 이 정보는 앞으로의 선택에 영향을 줄 수 있음
  • Software Freedom Conservancy는 LLM 기반 생성 AI 권고에서 해당 문제를 넘긴 것처럼 보이며, FSF가 더 잘할지도 불확실함
  • 이런 변화 속에서 관련 커뮤니티 참여를 재고하고 있지만, 작업과 사용자 지원은 계속함
  • LLM에 Add fourmolu config and restyled, neat, format a module 같은 프롬프트를 주고 결과를 커밋하는 방식은 쉬워 보일 수 있으나, 그 행동의 광범위한 영향을 고려해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 오늘 알게 된 건데 git-annex가 Haskell로 작성됐다는 게 멋짐

    오늘 집에 오는 지하철에서 옆 사람이 YouTube Shorts를 최대 음량으로 보고 있었고, 조용하고 꽉 찬 열차 안에서는 소음 공해라 짜증났음
    더 짜증났던 건 그가 보던 영상이 완전히 AI로 생성된 저품질 영상이었다는 점임

    이 글에서 의존성 작성자들이 LLM으로 이해하기 어려운 변경을 만든다는 일화가 와닿았음
    LLM 오용에서 가장 답답한 부분은 서로의 상호작용을 망가뜨린다는 데 있음
    예전에는 회사에서 허술하게 생각한 제안을 검토하더라도 핵심 아이디어가 그대로 드러나서 집어내고 코멘트하기 쉬웠지만, 이제는 누구나 허술한 변경을 LLM에 넣어 겉보기엔 잘 짜인 듯하지만 검토하면 구멍투성이인 결과물로 만들 수 있음
    마찬가지로 겉보기엔 좋아 보이는 나쁜 코드도 만들 수 있음

    새로운 불평은 아니지만 점점 신경을 건드리기 시작함
    일과 삶을 즐겁고 충만하게 만들던 인간적 연결의 핵심 일부를 잃어가고 있는 느낌임

    • 동료가 “이건 🤖가 했어”라고 솔직히 알려줘서, 어느 수준의 검토를 기대하는지 미리 알 수 있어 좋음
      보통은 코드베이스를 더 배우려고 사용한 과정의 문서라서, 동료가 LLM 출력을 읽었고 제대로 배웠는지 확인받고 싶어 한다고 믿을 수 있음

    • LLM이 바꾼 건 품질의 상대 가격이라고 봄
      집에 비유하면, 예전에는 지붕이 새고 기초가 나쁜 형편없는 McMansion이 1000X, 숨은 골칫거리가 없는 좋은 집이 2000X였음

      이제 LLM 기술로 숙련자가 기계적이고 검증 쉬운 작업 일부를 맡겨 좋은 집 가격을 이론상 1500X로 낮출 수 있음
      그런데 형편없는 McMansion은 100X로 떨어졌음

      그래서 저품질 McMansion들이 품질 좋은 작업을 추한 방식으로 밀어낼 가능성이 큼
      좋은 집을 2000X에서 1500X로 낮추는 장인들을 괴롭힐 생각은 없지만, 100X짜리 조악한 집들이 더 나은 것을 시장에서 밀어내고 레몬 시장을 만들면 고객들이 소프트웨어 전반을 훨씬 더 의심하게 될 수 있음
      구매자가 품질과 쓰레기를 구분할 방법이 없다는 점에서 레몬 시장은 보기 흉함
      소프트웨어에서 가장 유명한 예는 1983년 비디오 게임 대폭락으로, 엄청난 쓰레기 게임 물결에 많은 고객이 데이고 구매를 멈췄던 사건임

  • 이 입장은 충분히 합리적이라고 봄
    개인적으로는 시간이 지나면 대부분 헛수고가 될 것 같고, 내 소프트웨어 사용에서는 크게 신경 쓰지 않지만, 주관적 관점으로는 충분히 타당하고 흥미로우며 이 사람이 이렇게 하는 것도 좋다고 생각함

    AI 낙관론자들이 과장하는 것처럼, 반AI 쪽도 부정적 측면을 지나치게 극적으로 말하는 경향이 있음
    이 글 자체는 예외에 가깝지만, 마지막 문단의 성급한 일반화를 뺐다면 전체 의도와 메시지가 훨씬 강해졌을 것 같음

    그래도 이런 글을 읽고 감정 속에서 흥미로운 부분을 찾아보는 걸 좋아함
    프로젝트별로 마지막으로 알려진 100% 비LLM 코드 데이터베이스가 있으면 흥미로울 듯함
    영향 있는 슬롭 데이터베이스도 재미있을 것 같고, 여기서 “영향 있는”은 긍정·부정 양쪽 모두, “슬롭”은 검토되지 않은 출력이라는 의미가 중요함

    대충 2023년 초의 GitHub 아카이브를 가져오는 식으로 속일 수도 있겠지만, 단순한 특정 시점 스냅샷이 아니라 프로젝트별 마지막 커밋 스냅샷이면 더 흥미로울 것임
    이 데이터셋에서 나올 만한 흥미로운 결과가 많아 보이고, 이 글처럼 비LLM 소프트웨어만으로 생태계를 만들고 싶은 사람들에게도 도움이 됨

    이미 짐작하겠지만 나는 LLM 사용자임
    그래도 합리적인 쪽이라고 생각함
    궁금하면 내 웹사이트 글을 읽어도 되는데, 블로그 글 본문은 100% 사람이 썼다고 약속함
    반대 의견을 읽는 것이 배우고 성장하는 가장 좋은 방법 중 하나라고 생각해서 이런 시도에 참여하는 걸 좋아함

    • 프로젝트별 마지막 비LLM 버전을 추적하는 것에 가까운 프로젝트가 있긴 함
      열성적인 반AI 성향 사람들이 운영하는 https://codeberg.org/ethical-foss/open-slopware 임
      몇몇 프로젝트에는 “마지막 오염되지 않은 버전 또는 커밋 ID”가 있지만 모든 프로젝트를 다루지는 않음

  • 이 글을 제출한 이유는 작성자가 의존성에서 LLM 사용을 시사하는 특정 커밋을 직접 찾아보고, 발견 내용을 정리한 페이지를 만든 점이 좋았기 때문임

    개인적으로는 이 글이 바이브 코딩보다는 커뮤니티와 관행에 관한 내용이라 vibecoding 태그를 붙여야 할지 확신이 없었음

  • “이 시점에서 밀려오는 조류를 막으려는 것일지도 모른다는 걸 안다”는 대목이 있음

    프로젝트가 의존하는 컴파일러가 영향을 받으면 이길 수 없음
    나도 피해 통제를 하고 있지만, 결국 대안을 고집하는 쪽이 더 나빠서 양보할 수밖에 없는 순간이 옴

  • 까다로운 문제임
    아무리 잘 분석해도 LLM 코드를 피하기는 어려울 가능성이 큼
    예를 들어 코드 자동완성으로 들어간 코드는 잡아내지 못함

  • 신뢰가 깨진 시점은 이 라이브러리들이 LLM을 쓰기 시작했을 때가 아니라, 거대한 변경을 받아들이고 통합하면서 읽기 어렵고 쓸모없는 커밋 메시지를 붙였을 때라고 봄

    이건 LLM 사용 여부와 별개인 소프트웨어 공학 실패임

    참고로 Joey Hess와 그의 소프트웨어를 좋아하고, 코드 기여는 어떤 도구로 만들어졌든 결과물의 장점으로 평가해야 한다는 쪽임

  • 설명 방식이 좀 실망스러움
    persistent 커밋은 LLM이 작성한 게 아닌 것 같음
    사람들이 “Co-authored-by”가 붙은 모든 커밋을 LLM 생성이라고 말하지 않았으면 함

    첫 번째 yesod 링크는 CI 변경이라, 의존하는 코드라고 보기는 어렵다고 생각함
    “1489줄짜리 커밋 메시지가 붙은 LLM 생성 커밋”이라길래 커밋 자체가 미친 상태일 줄 알았지만, 실제로는 합리적인 스쿼시 병합이고 다만 차이가 엄청 클 뿐임

    cabal 커밋은 LLM이 테스트만 생성했다고 되어 있고, 그것도 내가 의존하는 코드로 봐야 하는지는 의문임
    git 커밋도 그냥 CI임

    이 의존성들 중 일부가 LLM을 쓰는 건 의심하지 않지만, 제시된 근거가 충분히 버틴다고 보기는 어려움
    반면 기대보다 훨씬 많은 수고가 들어간 작업이고, 어떤 의존성을 쓰지 않을 구체적 이유로 가리킬 만한 것이 있다는 점은 좋음

답변달기