Executive Summary

git-annex 개발자 Joey Hess가 지난 한 달간 약 100시간을 들여 자기 프로젝트의 전체 의존성 트리를 뒤졌다. 목적은 하나였다. "우리 소프트웨어와 그것이 기대는 라이브러리 어디에도 LLM이 생성한 코드가 없다"고 말할 수 있게 하는 것. 이 글은 그 감사가 무엇을 찾아냈고, 무엇을 지불했으며, 왜 그것이 데이터를 다루는 사람에게도 남의 일이 아닌지를 본다.

발단은 품질이 아니라 저작권이었다. 그가 검토 과정에서 마주친 것은 1,489줄짜리 두서없는 커밋 메시지, 이후 릴리스에서 아무 설명 없이 되돌려진 대량 변경, 그리고 다른 프로젝트 코드를 그대로 옮겨와 저작권 침해 소지를 남긴 복붙이었다. 문제는 "AI 코드가 나쁘다"가 아니라 "무엇이 들어왔는지 사후에 알 수 없다"는 데 있었다.

그리고 이 원칙에는 값이 붙었다. 이 결벽을 유지하려면 git-annex는 GHC 9.15 이후 대부분의 Haskell 언어 개선에서 스스로를 끊어야 했다. 저자 본인조차 "언어의 미래와 영구히 단절되는 편이 LLM 코드에 기대는 것보다 더 나쁠 수도 있다"고 인정했다.

~100시간

의존성 트리 감사

지난 한 달간 한 명이 투입

1,489줄

문제 커밋 메시지

코드에는 1만 줄 넘게 변경

6개

오염 확인된 하위 의존성

GHC·ram·persistent·yesod·Cabal·git

GHC 9.15+

포기한 미래 언어 개선

git-annex는 9.6.6까지만 지원

1

100시간의 코드 고고학

git-annex는 대용량 파일을 git으로 관리하는, 20년 가까이 이어진 성숙한 오픈소스 프로젝트다. 개발자 Joey Hess가 지난 한 달간 한 일은 새 기능을 만드는 것이 아니었다. 자기 프로젝트가 기대는 코드 전부를 거슬러 올라가며, 어디에 LLM이 쓴 코드가 섞여 들어왔는지 손으로 추적하는 작업이었다. 그는 이 과정에 100시간 가까이를 썼다고 적었다.

Git 버전관리 시스템 공식 로고 — git-annex가 그 위에 대용량 파일 관리 기능을 얹은 기반 시스템
▲ git-annex는 Git 위에 대용량 파일 이력 관리를 얹은 프로젝트다 | Source: Git 공식 로고, Jason Long (CC BY 3.0)

추적하면서 그가 실제로 마주친 사례들은 "AI가 코드를 잘 쓰느냐"는 논쟁과는 결이 달랐다. 그가 남긴 기록을 요약하면 세 가지다.

  • • 1,489줄짜리 커밋 메시지. 26,000줄 규모 코드베이스에 1만 줄 넘는 변경이 한 번에 들어오면서, 그 변경을 설명하는 커밋 메시지가 사람이 읽기 어려운 1,489줄로 늘어난 경우가 있었다. 무엇이 왜 바뀌었는지가 메시지 안에서 오히려 흐려졌다.
  • • 조용히 되돌려진 대량 패치. 대규모로 들어온 LLM 생성 변경이 이후 릴리스에서 아무 설명 없이 원상 복구된 흔적이 있었다. 들어올 때도, 사라질 때도 그 근거가 기록에 남지 않았다.
  • • 운으로 피한 저작권 침해. 다른 프로젝트의 코드를 거의 그대로 옮겨와 저작권 침해가 될 뻔한 복붙 시도도 있었다. 걸러진 것은 규칙이 막아서가 아니라 누군가 뒤늦게 알아챘기 때문이었다.

세 사례를 관통하는 문제는 코드의 품질이 아니다. 무엇이, 언제, 왜 들어왔는지를 사후에 되짚을 수 없다는 것이다. 저작권이 불투명한 코드가 기록의 공백을 타고 슬며시 들어오고, 또 슬며시 사라진다. Joey Hess가 100시간을 쓴 이유는 코드가 못 미더워서가 아니라, 그 출처가 증명되지 않아서였다.

2

보장이 아니라 빌드 플래그

감사의 결과물은 선언문이 아니라 하나의 빌드 옵션이었다. git-annex는 NoLLMDependencies라는 빌드 플래그를 도입했다(stack 사용자에게는 별도 설정 파일이 제공된다). 이 옵션으로 빌드하면, LLM 생성 코드가 유입되기 이전 버전의 의존성으로 고정해 소프트웨어를 만든다. "AI 코드 없는 git-annex"를 원하는 사람이 실제로 손에 쥘 수 있는 물건이 생긴 것이다.

중요한 것은 이 플래그가 무엇을 보장하지 못하는지다. 우선 기본 빌드가 아니다. 명시적으로 이 옵션을 켠 사람만 그 상태를 얻는다. 더 무거운 문제는 보안이다. 어떤 취약점이 새 버전에서만 고쳐졌다면, 구버전 의존성에 고정된 이 빌드는 그 보안 패치를 받지 못한 채 취약점을 그대로 안고 간다.

그래서 이것은 "완전한 안전"이 아니라 선택 가능한 트레이드오프다. AI 코드 유입 위험과 보안 패치 지연 위험 중 무엇을 더 감당할 수 있는지, 사용자가 스스로 고르게 만든 장치다. git-annex의 공식 문서 표현을 빌리면, 자유 소프트웨어에 들어온 LLM 생성 코드는 "잠재적 지뢰"이고 그 저작권은 "미해결 문제"다.

3

새로운 위협 표면이 된 의존성

git-annex 자신이 LLM 코드를 한 줄도 쓰지 않아도, 문제는 그 아래에서 올라온다. 감사가 드러낸 것은 이미 여러 하위 의존성이 LLM 생성 코드를 포함하기 시작했다는 사실이다. 공식 문서가 지목한 패키지와 그 시점은 구체적이다.

Haskell 프로그래밍 언어 공식 로고 — GHC·ram·persistent·yesod·Cabal 등 오염이 확인된 하위 의존성 다수가 이 생태계 소속
▲ 오염이 확인된 하위 의존성 대부분은 Haskell 생태계 소속이다 | Source: Haskell 공식 로고 (Public Domain)
  • • GHC — 9.15부터 (git-annex는 9.6.6까지만 지원)
  • • ram — 0.21.0부터. git-annex는 이 라이브러리 대신 그것이 포크되기 전 원본인 비유지보수 라이브러리 memory를 계속 쓰는 쪽을 택했다.
  • • persistent — 2.15.0.0부터, yesod — 1.7.0.0부터, Cabal, 그리고 git — 2.53부터 (git-annex는 2.22까지만 지원)

이 목록이 말하는 바는 분명하다. 한 프로젝트의 청결함이, 그 프로젝트가 통제할 수 없는 수백 개 하위 패키지의 결정에 좌우된다. 내가 아무리 조심해도 내가 기대는 라이브러리가 방침을 바꾸면 오염은 다시 흘러든다. AI 생성 코드가 개별 파일의 문제가 아니라 공급망 전체의 위협 표면이 되는 순간이다. git-annex가 memory 같은 낡은 라이브러리로 되돌아간 것은, 그 무력감 앞에서 택할 수 있는 몇 안 되는 우회로였다.

4

결벽이 치른 대가

가장 정직한 대목은 이 원칙의 값을 저자 스스로 계산해 공개했다는 점이다. GHC 9.15부터 LLM 코드가 들어왔고 git-annex가 9.6.6까지만 지원하기로 한 이상, git-annex는 그 이후 등장할 대부분의 Haskell 언어 개선을 앞으로 쓸 수 없다. 컴파일러가 나아가는 방향에서 스스로를 떼어낸 것이다. 저자는 이 상황을 "deeply unfortunate", 깊이 유감스러운 일이라고 적었다.

그는 여기서 한 걸음 더 나아가 자기 원칙의 한계를 인정한다. 언어의 미래와 영구히 단절되는 편이 LLM 코드에 기대는 것보다 오히려 더 나쁠 수도 있다는 것이다. 그래서 그는 "이 원칙을 앞으로도 반드시 지키겠다고는 약속할 수 없다"고 밝혔다. 결벽을 선언하되, 그 결벽이 언젠가 더 큰 손해가 될 수 있음을 같은 문장 안에서 인정하는 태도다.

커뮤니티 반응도 갈렸다. 한쪽에서는 과잉 대응이라 봤고, 다른 쪽에서는 지지하며 관심을 보였다. 반-AI 성향 개발자들 사이에서는 여러 프로젝트별로 "마지막으로 오염되지 않은 버전"을 추적하려는 비공식 시도도 언급됐다. 아직 포괄적이지는 않지만, 이 불안이 한 사람의 유별남만은 아니라는 신호다.

5

코드 출처 = 데이터 출처

여기서부터가 데이터를 다루는 사람에게 이 사건이 남의 일이 아닌 이유다. git-annex가 씨름한 질문을 한 줄로 줄이면 이렇다. "이 산출물을 누가, 무엇이 만들었는가를 사후에 증명할 수 있는가." 코드라는 단어를 데이터로 바꿔도 문장은 그대로 성립한다.

페블러스가 최근 다룬 아마존 메커니컬 터크 종료 사례가 정확히 같은 구조였다. 인간이 라벨을 붙인다고 믿었던 크라우드 작업에서, 한 연구는 워커의 33~46%가 실제로는 LLM으로 과제를 처리했다고 추정했다. 인간 라벨이라는 데이터의 출처 정보가 소실되는 순간, 그 데이터의 신뢰는 품질을 따지기도 전에 무너졌다.

코드에서든 데이터에서든 같은 패턴이 반복된다. 생성 주체의 출처 정보가 사라지면, 품질 검증보다 먼저 신뢰가 붕괴한다. git-annex가 뒤늦게 100시간을 들여 되짚어야 했던 것도, 메커니컬 터크에서 라벨의 진짜 저자를 알 수 없게 된 것도, 결국 출처를 처음부터 기록하지 않은 대가였다.

6

페블러스 관점

Joey Hess는 자신의 100시간을 일회성 감사로 규정하지 않았다. 의존성은 계속 갱신되고, 새 오염은 다음 릴리스에서 또 흘러들 수 있으니, 이 검토는 반복해야 하는 유지보수 부담이라고 못 박았다. 이 지점이 AI-Ready Data 관점에서 이 사례가 축소판으로 보여주는 핵심이다.

데이터와 모델의 계보를 증명 가능하게 유지하는 일도 똑같다. 한 번 검증하고 끝나는 기능이 아니라, 데이터가 흐르는 동안 계속 지불해야 하는 비용이다. git-annex가 한 명의 손과 100시간으로 감당한 것을, 조직 규모의 데이터 파이프라인에서는 누가, 어떤 자동화로, 어떤 주기로 감당할 것인가.

그래서 이 글이 남기는 질문은 "AI 코드를 쓸 것인가 말 것인가"가 아니다. 증명 가능한 출처를 유지하는 비용을 누가, 어떻게 분담할 것인가이다. 코드든 데이터든, 출처를 나중에 복원하는 값은 항상 처음부터 기록하는 값보다 비싸다. git-annex의 1,489줄과 100시간이 그 청구서를 미리 보여줬을 뿐이다.

R

참고문헌

1차 소스

  • 1.Hess, J. (2026). "no LLM code in dependencies." joeyh.name.
  • 2.git-annex. (2026). "no_llm_code." git-annex.branchable.com. (공식 정책 문서 — NoLLMDependencies 빌드 플래그, 영향받는 의존성 목록)

커뮤니티·보도