Debian은 LLM 허용을 택했다 — 18년 개발자가 떠나며 남긴 경고
한눈에 보는 핵심
Debian이 투표를 통해 개발 과정에서의 LLM 사용을 허용하기로 결정했습니다. 하지만 18년간 프로젝트에 참여했던 한 전(前) 개발자는 이 결정에 대해 뼈아픈 질문을 던집니다.
"LLM이 복잡성을 없애주는 게 아니라, 복잡성을 견딜 만하게 만들어서 영원히 남기는 건 아닐까?"
그의 우려는 단순한 기술 반대론이 아닙니다. 누적된 복잡성을 근본적으로 제거하려는 동기 자체가 약해질 수 있다는, 조직 구조에 관한 이야기입니다.
debhelper가 보여준 '개혁'의 모범 사례
이 주장을 이해하려면 Debian 패키징의 역사를 잠깐 들여다볼 필요가 있습니다.
debhelper 등장 이전:
debian/rules파일은 길고 복잡한 상용구(boilerplate)로 가득 차 있었습니다- 새 패키지를 만들 때 가장 흔한 방법은 "기존 파일을 복사해서 적당히 고치기"였습니다
- 즉, 아무도 그 코드를 온전히 이해하지 못한 채 복제만 반복하는 상태였죠
debhelper의 접근:
- 먼저 흩어진 상용구를 일련의
dh_명령으로 규격화했습니다 - 그다음 규격화된 것들을 거의 전부 제거했습니다
핵심은 순서입니다. 자동화가 목적이 아니라, 자동화는 제거를 위한 중간 단계였습니다.
마지막 3줄이 남긴 교훈
그런데 끝내 지우지 못한 3줄이 있었습니다. 기능적으로는 불필요했지만, 정책 문서를 법률주의적으로 해석한 결과 남아야만 했던 코드였습니다.
수천 개 패키지에서 이 3줄을 없애면 명백한 이득이 있는데도, 그 변화는 이미 불가능해진 상태였습니다. 개별적으로는 모두 타당했던 결정들이 조금씩 쌓여 마찰을 늘리고 유연성을 떨어뜨린 결과입니다.
"30년 전에 LLM이 있었다면"
여기서 글쓴이의 가장 날카로운 가정이 나옵니다.
만약 30년 전에 LLM이 있었다면, debhelper는 태어났을까요?
아마 아닐 겁니다. 복잡한 rules 파일을 없애는 대신, LLM에게 자동 생성시켰을 가능성이 높습니다. 그러면:
- 당장의 고통은 사라집니다 ✅
- 하지만 복잡성은 그대로 남습니다 ❌
- 그리고 아무도 그것을 없앨 동기를 갖지 못하게 됩니다 ❌
이것이 이 글의 핵심 논지입니다. LLM은 구조적 개혁의 대체재가 되어 현 상태를 고착화할 수 있다는 것이죠.
의존성 패키징: Guix와의 비교
같은 문제가 더 현실적인 형태로 나타나는 영역이 현대적인 의존성 트리 패키징입니다.
| | 접근 방식 | 결과 | |---|---|---| | Guix | 여러 언어의 패키지 저장소에서 의존성을 재귀적으로 가져옴 | 배포판에 추가할 만한 결과물을 프로그램이 생성 | | Debian | 정책 제약이 강함 | 프로그램이 같은 작업을 수행하기 어려움 |
Guix는 이 문제를 정책과 도구 설계로 풀었습니다. Debian이 같은 문제를 LLM으로 푼다면 어떻게 될까요?
- 자유 소프트웨어 배포판의 개발 과정이 독점 소프트웨어에 의존하게 됩니다
- 그러면서도 사람은 여전히 개입해야 하고, 맡는 일은 덜 매력적인 반복 잡무로 남습니다
기술적으로는 성공이지만, 프로젝트의 성격 면에서는 손해라는 진단입니다.
떠나는 사람의 태도
주목할 만한 건 글의 마무리 톤입니다. 글쓴이는 비난으로 끝내지 않습니다.
- 이 우려만으로도 프로젝트에 남아 있었다면 곧 떠났을 것이라고 인정합니다
- 앞으로는 Debian을 때때로 이용하면서 다른 방식을 살펴볼 계획입니다
- Debian이 정답이 없을 수도 있는 선택을 다루고 있다는 점을 존중합니다
- 어떤 절충안을 택하든, 무엇을 수행하고 무엇을 받아들일지는 각 개인이 결정할 몫이라고 말합니다
그리고 마지막 문장이 제목의 은유를 완성합니다.
Debian은 정책의 합보다 큰 공동체이며, 단순한 배가 아니라 승무원으로 이루어진 프로젝트다.
정리하며
세이렌의 노래는 거짓말이 아닙니다. 정말로 달콤하기 때문에 위험한 것이죠. LLM이 상용구를 잘 생성해준다는 것도 사실입니다. 문제는 그 편리함이 "이걸 애초에 없앨 수 있지 않나?"라는 질문을 지워버릴 때 발생합니다.
이 글이 던지는 질문은 Debian만의 것이 아닙니다. 여러분의 코드베이스에도 아무도 이해하지 못한 채 복제되는 상용구가 있다면, 지금 물어볼 만합니다.
우리는 이걸 자동화하려는 걸까, 아니면 없애려는 걸까?