100시간을 들여 의존성에서 LLM 코드를 걷어낸 개발자 이야기 — git-annex의 실험
핵심 요약
git-annex의 개발자 Joey Hess가 약 한 달간 100시간을 투입해, 자신의 프로젝트가 LLM 생성 코드가 포함된 의존성 없이 빌드되도록 전체 의존성 트리를 점검했습니다. 이 과정에서 드러난 것은 단순한 'AI 반대' 정서가 아니라, 의존성 품질과 협업 신뢰에 대한 근본적인 질문이었습니다.
무엇을, 왜 점검했나
git-annex는 Haskell로 작성된 대용량 파일 관리 도구입니다. 개발자는 LLM 생성 코드를 배제하겠다는 목표를 세웠지만, 진짜 어려움은 자기 코드가 아니라 프로그램이 의존하는 전체 의존성 트리를 계속 추적해야 한다는 데 있었습니다. 한 번 점검하고 끝나는 일이 아니라, 지속적인 유지보수 부담이 되는 것이죠.
점검 중 발견된 사례들
점검 과정에서 확인된 사례들은 취향의 문제를 넘어 유지보수와 신뢰의 문제로 이어집니다.
- 대규모 LLM 생성 변경이 다음 릴리스에서 아무 설명 없이 통째로 되돌려짐
- 26,000줄 규모의 코드베이스에 10,000줄짜리 변경이 들어갔고, 커밋 메시지는 1,489줄의 일관성 없는 내용이었음
- 다른 프로젝트에서 코드를 복사하라는 LLM 프롬프트가 발견됐고, 저작권 침해를 '운 좋게' 피한 것으로 보이는 사례도 있었음
개발자는 이번 작업으로 의존성 품질에 대한 추가 정보를 얻은 점은 긍정적으로 평가했지만, Software Freedom Conservancy나 FSF 같은 조직 차원의 대응에는 회의적인 시각을 내비쳤습니다.
커뮤니티의 반응: 도구가 아니라 신뢰의 문제
Lobste.rs 등 커뮤니티 토론에서 눈에 띄는 관점 몇 가지를 정리하면 이렇습니다.
"품질의 상대 가격이 바뀌었다"
한 댓글은 이를 집값에 비유합니다. 예전에는 부실한 집이 1000X, 좋은 집이 2000X였다면, LLM 이후 좋은 집은 1500X로 내려갔지만 부실한 집은 100X로 폭락했다는 것. 저품질 결과물이 시장을 뒤덮으면 구매자가 품질을 구분할 수 없는 '레몬 시장'이 형성될 수 있고, 1983년 비디오 게임 대폭락 같은 신뢰 붕괴로 이어질 수 있다는 우려입니다.
"검토를 망가뜨리는 것이 진짜 비용"
예전에는 허술한 제안이라도 핵심 아이디어가 그대로 드러나 지적하기 쉬웠지만, 이제는 누구나 허술한 생각을 LLM에 넣어 겉보기엔 그럴듯하지만 구멍투성이인 결과물로 포장할 수 있다는 지적도 있었습니다. 반대로 동료가 "이건 AI가 작성했어"라고 솔직하게 밝혀주면 검토 수준을 미리 조정할 수 있어 좋다는 경험담도 나왔습니다.
"신뢰가 깨진 시점은 LLM 사용이 아니다"
또 다른 시각은, 문제의 본질이 LLM 사용 자체가 아니라 거대한 변경을 읽기 어려운 커밋 메시지와 함께 무비판적으로 통합한 것이라는 지적입니다. 이는 도구와 무관한 소프트웨어 공학의 실패이며, 코드 기여는 어떤 도구로 만들어졌든 결과물의 장점으로 평가해야 한다는 입장이죠. 실제로 글에서 제시된 근거 중 일부(CI 설정 변경, 테스트만 생성된 커밋 등)는 'LLM 생성 의존성 코드'로 보기 어렵다는 반론도 있었습니다.
시사점: 쉬운 커밋의 숨은 비용
LLM에게 "포맷팅 정리해줘" 같은 프롬프트를 주고 결과를 그대로 커밋하는 건 아주 쉬워졌습니다. 하지만 이 글이 던지는 질문은 분명합니다. 그 쉬운 커밋이 협업 신뢰와 프로젝트 참여에 어떤 비용을 만드는가?
검토되지 않은 대규모 변경, 설명 없는 되돌림, 읽을 수 없는 커밋 메시지 — 이런 것들이 쌓이면 오픈소스 생태계를 지탱해 온 신뢰가 흔들립니다. AI 코딩 도구를 쓰든 안 쓰든, 변경을 이해하고 설명할 수 있는 사람이 커밋해야 한다는 원칙은 여전히 유효합니다. git-annex의 100시간짜리 실험은 '밀려오는 조류를 막으려는 시도'일지 모르지만, 우리가 의존성의 품질을 얼마나 모르고 있었는지 되돌아보게 만드는 계기임은 분명합니다.