- 오픈소스 프로젝트는 당분간 AI 생성 기여를 거부하는 편이 실용적임. 나중에 받아들이기는 쉽지만, 이미 들어온 코드를 제거하고 통제권을 되찾기는 어려울 수 있음
- 사람의 검토를 요구하는 중립적 정책도 생성 코드의 유입을 막지 못한다면, 장기적으로는 속도만 느린 수용과 다르지 않음
- AI 도입으로 기여가 늘고 번거로운 개발 작업이 줄어들 수 있지만, 일부 커뮤니티의 이탈과 외부 AI 도구에 대한 의존이라는 대가가 따름
- 생성 코드가 쌓일수록 코드와 아키텍처를 이해하는 사람이 줄어들거나, 도구 가격 상승과 호환되지 않는 라이선스의 코드 유입이 문제가 될 수 있음
- ‘파스칼의 내기’처럼 불확실한 선택의 이익과 손실을 비교하면, AI 도입을 늦춰 생기는 아쉬움보다 이미 받아들인 코드를 걷어내야 하는 위험을 피하는 편이 유리함
- 파스칼의 내기는 신의 존재를 확신할 수 없더라도, 신을 믿거나 믿지 않았을 때의 이익과 손실을 따져 믿는 편이 유리하다는 논증임
- 이 글은 그 논리를 오픈소스 프로젝트의 AI 코드 수용 여부에 빗댐
- 지금 거부했다가 AI가 유용하다고 밝혀지면 나중에 받아들일 수 있음
- 지금 받아들였다가 문제가 커지면 이미 쌓인 코드를 제거하고 통제권을 되찾기 어려울 수 있음
- 핵심은 AI의 미래를 확실히 예측하는 것이 아니라, 판단이 틀렸을 때 되돌리기 쉬운 선택을 하는 것임
- 윤리적/생태적/사회적 논의를 잠시 제외하고, LLM 생성 기여의 수용 여부를 실용적이고 전략적인 기준으로 비교함
- 생성 코드를 싫어하는 쪽은 이를 “slop”, 선호하는 쪽은 “vibecode”라고 부름
- 가능한 입장은 세 가지로 나뉨
- LLM을 기여자가 사용할 수 있는 중립적 도구로 대체로 수용함. 안전장치나 사람의 검토 정책을 둘 수도, 두지 않을 수도 있음
- 타협하거나 결정을 유보하고, 찬성도 반대도 아닌 지침을 마련함. 여기서는 이를 “Debian AI policy”라고 부름
- 강한 안전장치를 갖춘 예외를 허용할 수는 있지만, 원칙적으로 LLM을 강하게 거부함
- 중간 입장은 성급한 결정을 피하는 합리적인 기본값처럼 보이지만, Debian 사례에서는 어느 쪽도 만족시키지 못함
- 사람의 검토를 의무화하는 등의 장치가 있어도 생성 기여는 결국 들어오며, 중간 입장을 오래 유지할수록 유입을 피하기 어려워진다고 봄
- 이 전제에서 결정 유보는 속도만 느린 수용이며, 찬성 입장을 명시하지 않는 순진하거나 위선적인 선택과 다르지 않음
- 수용과 거부 모두 일부 커뮤니티와 핵심 기여자를 떠나게 할 수 있음
- 프로젝트는 모두를 만족시킬 수 없으며, 무엇이 최선인지는 핵심 커뮤니티 구성원이 결정해야 함
- 기대 이익은 기여 증가와 번거로운 개발 작업에 쓰는 시간의 감소임
- LLM 사용이 직접 코딩보다 느리다는 연구 경향을 전제로 하면서도, 비교를 위해 이 생산성 이익을 일단 인정함
- 대가는 커뮤니티 이탈과 독점 소프트웨어 의존임
- 바이브 코딩으로 만든 소프트웨어를 거부하는 사람들이 떠날 수 있으며, 일부 FLOSS 커뮤니티에서는 영향력 있는 사용자도 여기에 속함
- 개발이 점점 비싸고 완전히 독점적이며 프로젝트가 통제할 수 없는 소프트웨어에 의존하게 됨
- 단기적으로 AI 도입은 실제인지 확실하지 않은 생산성 향상을 위해 일부 구성원과 독립성을 포기하는 선택임
- AI를 거부하면 윤리를 중시하는 커뮤니티의 지지를 얻고 기존 방식을 유지할 수 있음
- 늘어나는 AI 반대 소프트웨어 목록이 이런 지지의 사례임
- 직접적인 단점은 AI를 꼭 사용하려는 기여자의 이탈임
- 다만 LLM 없이는 기여하려 하지 않는 사람은 코드를 스스로 검토하고 이해하지 못하거나, 머지않아 그 능력을 잃을 가능성이 있다고 봄
- GitHub에는 제출자가 자신의 코드를 테스트할 지식이 없다고 인정하는 풀 리퀘스트들이 있음
- 이 전제라면 그런 기여를 거절하는 것은 단점보다 장점일 수 있으며, AI의 절제된 사용을 허용하는 프로젝트에서도 마찬가지임
- 사용자 측면의 비대칭성도 있음
- AI 사용 때문에 소프트웨어를 거부하는 사람은 있지만, 사람이 만들었다는 이유로 사용을 거부하는 사람은 없다고 봄
- 생성 코드가 코드베이스에 미치는 장기적 영향은 아직 알 수 없음
- 각 기여를 사람이 점점 덜 이해하게 되면 코드베이스가 어떻게 변할지 불확실함
- AI 도구가 갑자기 너무 비싸지고 아키텍처를 이해하는 사람도 남지 않는 상황이 생길 수 있음
- 코드의 상당 부분이 호환되지 않는 라이선스의 다른 프로젝트에서 복사됐을 가능성도 고려해야 함
- Cory Doctorow의 석면 비유는 도입과 제거의 비용 차이를 강조함
- 생성 코드는 보기 좋고 곳곳에 넣기 쉽지만, 통제권을 되찾거나 제거해야 한다면 잘 풀려도 수년의 작업이 필요할 수 있음
- 대규모 마케팅이 뒤처질지 모른다는 두려움인 FOMO를 부추기더라도, 현재로서는 생성 기여를 강하게 거부하는 쪽이 더 합리적이고 실용적임
- 나중에 LLM이 세상에 도움이 되고, 윤리적이고 신뢰할 수 있으며 지속 가능한 도구로 발전하고, 사용자도 더 행복해진다면 수용 정책으로 바꾸면 됨
- 그런 변화가 실제로 일어난다면 정책 변경 자체에는 비용이 들지 않는다고 봄
- 반대로 생성 코드를 지금 받아들이면 되돌리기 어려운 후회가 남거나 프로젝트를 포기해야 할 수도 있음
- 지금 거부했을 때의 최악의 가상적 후회는 “좀 더 일찍 도입할 걸 그랬다”에 그침
- 따라서 AI의 가치를 아직 판단하지 못한 프로젝트라면, 당분간 AI 생성 기여를 모두 강하게 거부하는 것이 실용적인 선택임