AI에 대한 파스칼의 내기

오픈소스 프로젝트에는 AI 생성 기여를 당분간 거부하는 것이 실용적인 선택임. 나중에 수용으로 바꾸기는 쉽지만, 이미 유입된 생성 코드를 제거하고 통제권을 되찾기는 어려울 수 있음 중립적 지침이나 결정 유보도 장기적으로는 생성 코드 수용과 다르지 않음. 사람의 검토를 의무화해도 생성 기여가 결국 유입된다는 전제에서, 프로젝트는 수용 여부를 명확히 선택해야 함 AI 도입으로 기대하는 기여 증가와 생산성 향상에는 일부 커뮤니티의 이탈, 통제할 수 없는 고가의 독점 소프트웨어에 대한 의존이라는 대가가 따름 AI 거부는 LLM 사용을 원하는 일부 기여자를 떠나게 할 수 있지만, 기존 개발 방식을 유지하고 AI 반대 커뮤니티의 지지를 얻을 수 있음 생성 코드의 장기적 영향은 아직 불확실함. 코드와 아키텍처에 대한 이해 저하, AI 도구의 가격 상승, 호환되지 않는 라이선스의 코드 유입 가능성이 거부를 권하는 근거임 오픈소스 프로젝트가 선택해야 할 세 가지 입장 윤리적/생태적/사회적 논의를 잠시 제외하고, LLM 생성 기여의 수용 여부를 실용적이고 전략적인 기준으로 비교함 생성 코드를 싫어하는 쪽은 이를 “slop”, 선호하는 쪽은 “vibecode”라고 부름 가능한 입장은 세 가지로 나뉨 LLM을 기여자가 사용할 수 있는 중립적 도구로 대체로 수용함. 안전장치나 사람의 검토 정책을 둘 수도, 두지 않을 수도 있음 타협하거나 결정을 유보하고, 찬성도 반대도 아닌 지침을 마련함. 여기서는 이를 “Debian AI policy”라고 부름 강한 안전장치를 갖춘 예외를 허용할 수는 있지만, 원칙적으로 LLM을 강하게 거부함 중간 입장은 성급한 결정을 피하는 합리적인 기본값처럼 보이지만, Debian 사례에서는 어느 쪽도 만족시키지 못함 사람의 검토를 의무화하는 등의 장치가 있어도 생성 기여는 결국 들어오며, 중간 입장을 오래 유지할수록 유입을 피하기 어려워진다고 봄 이 전제에서 결정 유보는 속도만 느린 수용이며, 찬성 입장을 명시하지 않는 순진하거나 위선적인 선택과 다르지 않음 수용과 거부 모두 일부 커뮤니티와 핵심 기여자를 떠나게 할 수 있음 프로젝트는 모두를 만족시킬 수 없으며, 무엇이 최선인지는 핵심 커뮤니티 구성원이 결정해야 함 AI 도입의 이익과 대가 기대 이익은 기여 증가와 번거로운 개발 작업에 쓰는 시간의 감소임 LLM 사용이 직접 코딩보다 느리다는 연구 경향을 전제로 하면서도, 비교를 위해 이 생산성 이익을 일단 ...