Debian과 세이렌

Debian은 개발 과정에서 LLM 사용을 허용하기로 결정했지만, 18년간 프로젝트에 참여한 전 개발자는 누적된 복잡성을 근본적으로 제거하려는 동기가 약해질 수 있다고 우려함 debhelper는 길고 복잡한 debian/rules 상용구를 dh_ 명령으로 정리한 뒤 대부분 없앴지만, 정책의 법률주의적 해석 탓에 불필요한 3줄마저 제거하기 어려웠음 30년 전에 LLM이 있었다면 복잡한 규칙 파일을 없애는 대신 자동 생성했을 수 있으며, 앞으로도 정책과 수작업을 개혁하기보다 복잡성을 재생산할 가능성이 있음 Guix는 여러 프로그래밍 언어 저장소에서 의존성을 재귀적으로 가져올 수 있는 반면, Debian 정책은 현대적인 의존성 트리를 프로그램으로 패키징하기 어렵게 만듦 LLM으로 이를 해결하면 Debian 개발이 독점 소프트웨어에 의존하면서도 사람은 덜 매력적인 반복 작업을 계속 맡을 수 있으며, 무엇을 수행하고 받아들일지는 각 구성원의 선택으로 남음 LLM이 구조적 개혁을 대신할 위험 Debian은 투표를 통해 개발 과정의 LLM 사용을 허용하기로 결정함 프로젝트를 떠난 배경에는 개별적으로 타당한 결정들이 조금씩 마찰을 늘리고 유연성을 떨어뜨려, Debian이 방향을 바꾸거나 새로운 가능성을 탐색하기 어려워졌다는 판단이 있었음 debhelper가 등장하기 전 debian/rules는 길고 복잡한 상용구로 가득했고, 기존 파일을 복사·수정해 패키지를 빌드하는 방식이 흔했음 debhelper는 먼저 상용구를 일련의 dh_ 명령으로 규격화한 뒤 거의 모두 제거함 마지막에 남은 불필요한 3줄은 정책 문서를 법률주의적으로 해석한 결과였지만, 수천 개 패키지에 이점이 있어도 이를 없애는 변화는 이미 불가능했음 LLM은 상용구와 무의미한 수작업을 없애도록 정책을 개혁하는 대신, 기존 복잡성을 자동 생성해 현 상태를 고착화할 수 있음 의존성 패키징과 개인의 선택 Debian은 현대적인 의존성 트리를 패키징하는 데 큰 어려움을 겪음 Guix는 여러 프로그래밍 언어의 패키지 저장소에서 의존성을 재귀적으로 가져와 배포판에 추가할 만한 결과를 만들 수 있음 Debian 정책 아래에서는 프로그램이 같은 작업을 수행하기 어려움 LLM으로 의존성 패키징에 성공하더라도 Debian은 개발 과정에서 독점 소프트웨어에 의존하고, 사람은 계속 개입해 덜 매력적인 잡무를 맡을 수 있음 이 우려만으로도 프로젝트에 남아 있었다면 곧 떠났을 것이며, 앞으...