'LLM 코드는 우리 라이브러리에 못 들어옵니다' — git-annex 관리자가 100시간 들여 만든 새 플래그

핵심 요약 (TL;DR)

Debian 원로이자 git-annex 유지관리자 Joey Hess가 7월 2일 새 빌드 플래그 NoLLMDependencies를 공개했습니다. 약 100시간 작업으로 LLM 생성 코드가 들어간 상류 의존성 6개를 우회하는 정책이에요. "LLM 코드의 저작권은 아직 미해결"이라는 이유로 하류 격리를 선택했고, 이는 대형 OSS 유지관리자가 취한 첫 정면 대응입니다.

100시간짜리 청소가 시작된 자리

Joey Hess라는 이름은 리눅스 오래 쓰신 분에게는 낯설지 않을 겁니다. Debian 초기부터 활동한 원로, git-annex 유지관리자죠. 그가 7월 2일에 쓴 블로그 글 하나가 Hacker News에서 108점을 받으며 조용히 논쟁을 일으켰습니다.

내용은 이렇습니다. git-annex에 새 빌드 플래그를 추가했어요. 이름은 NoLLMDependencies. 이 플래그를 켜면 LLM 생성 코드가 들어간 것으로 확인된 상류 의존성 6개를 빌드에서 우회합니다. 예를 들면 이런 의존성들이에요.

• GHC 9.15 — Joey가 처음 LLM 코드를 감지한 곳
• ram 0.21.0 — 대체제로 이 라이브러리의 이전 포크인 미유지 memory 패키지를 그대로 사용
• persistent 2.15.0.0
• yesod 1.7.0.0
• Cabal
• git 2.53

한 사람이 100시간을 들여서 만든 우회로입니다. 이게 왜 사건일까요.

트리거는 하나의 커밋

원문 블로그에는 트리거 정황이 명확히 나옵니다. 어떤 프로젝트에 1,489줄짜리 커밋 메시지와 함께 10,000 LOC 규모의 AI 변경이 던져진 사례가 있었어요. 프로젝트 전체가 26,000 LOC 규모였습니다. 즉 코드베이스의 약 40%가 한 번의 커밋으로 갈아엎어진 거죠.

거기에 더해 Joey는 LLM이 다른 프로젝트에서 코드를 복사하도록 프롬프트되어 저작권을 아슬아슬하게 회피한 사례, 그리고 대형 LLM 변경이 다음 릴리스에서 아무 설명 없이 롤백되는 패턴을 관찰했습니다. 이 흐름을 지켜본 결과가 100시간짜리 청소예요.

Joey의 근거는 명확합니다. "LLM 코드의 저작권은 아직 해결되지 않은 문제다. 향후 판례나 규제가 바뀌면, 우리 하류 프로젝트가 소급 청구를 받을 수 있다. 그 리스크를 사전에 격리한다."

우리 앱에는 무슨 의미인가

바이브코더 관점에서 이 사건은 두 가지 방향으로 읽힙니다.

첫째, 상용 SaaS를 굴리는 바이브코더에게는 실무 리스크입니다. 여러분이 지금 npm/pip/cargo로 붙이는 라이브러리 하나하나가 앞으로 "이 의존성 안에 LLM 코드가 있는가?"라는 질문을 통과해야 할 수도 있어요. 특히 엔터프라이즈 고객사가 라이선스 감사를 걸어오는 시나리오에서요. git-annex의 대응은 다른 대형 OSS(Debian/Alpine 패키지 정책 포함)의 참조 사례가 될 확률이 높습니다.

둘째, 오픈소스에 코드를 미는 바이브코더에게는 문화적 신호예요. 1,489줄 커밋 + 10,000 LOC AI 변경이 유지관리자에게 어떻게 상륙하는지 실측치가 나왔습니다. "AI로 청소해 드립니다" 스타일의 대규모 리팩터 PR은 이제 리뷰어에게 환영받지 못할 확률이 급격히 높아졌다는 뜻인 거죠.

FAQ

Q. LLM 생성 코드의 저작권이 정말 문제가 되나요?
아직 판례가 확정되지 않은 회색 지대예요. 미국 저작권청은 AI 단독 생성물에 대해 저작권을 인정하지 않는 방향으로 가이드를 내고 있지만, "AI가 만든 코드"의 라이선스 계승 문제는 여전히 미해결입니다. Joey Hess의 판단은 "미해결이므로 하류 격리"라는 보수적 접근인 거죠.

Q. 6개 의존성만 우회해도 실질적 효과가 있나요?
git-annex 케이스에서는 실질적이에요. 왜냐하면 나머지 스택은 여전히 LLM 코드가 유입되지 않은 상태로 유지되고 있고, 문제가 된 특정 의존성만 조기 이탈시켰기 때문입니다. 다만 시간이 지나면 우회할 대상이 계속 늘어날 것이고, 그때가 진짜 결정 지점이 됩니다.

Q. 우리는 지금 뭘 준비해야 할까요?
당장은 두 가지입니다. (1) 새 프로젝트에 붙이는 의존성의 라이선스와 유지 정책을 다시 읽는 습관. (2) 여러분이 미는 큰 PR에 "AI 도움을 어떻게 받았는지" 커밋 메시지에 명시하는 습관. 유지관리자가 후자를 요구하는 시점이 곧 옵니다.

마무리

git-annex의 100시간은 시작이자 경고입니다. 바이브코드로 짠 오픈소스가 하류 유지관리자에게 청구서를 보내기 시작했다는 신호인 거죠. 여러분이 지금 미는 코드가 6개월 뒤 누군가의 "우회 대상 리스트"에 오르지 않으려면, 어떤 흔적을 남기고 어떤 흔적을 남기지 않을지 지금부터 계산해야 합니다.

원문은 joeyh.name/blog/entry/no_LLM_code_in_dependencies/, 기술 문서는 git-annex.branchable.com/no_llm_code/에서 확인하실 수 있습니다.