TL;DR

  • AI 생성 기여를 받아들일지 거부할지 결정하지 않거나 중간 입장을 택하면, 장기적으로 생성 코드가 프로젝트에 스며들어 사실상 AI 수용을 선택하게 됨.
  • AI를 수용하면 기여가 늘고 번거로운 개발 작업에 드는 시간이 줄 수 있지만, 커뮤니티 일부와 프로젝트의 독립성을 잃을 수 있음.
  • AI를 거부하면 AI 사용을 원하는 기여자를 잃을 수 있지만, 그들이 떠나는 일은 프로젝트에 이점일 수도 있으며 사용자는 소외되지 않음.
  • 생성 코드가 누적되면 코드베이스를 사람이 이해하기 어려워지고, 도구 비용과 라이선스 충돌이 장기 위험으로 남음.
  • AI에 중립적이라면 지금 생성 코드 기여를 강하게 거부하는 편이 실용적이며, 나중에 정책을 바꾸는 데는 비용이 없다는 주장임.

오픈소스 프로젝트는 LLM 기여를 받아들여야 하는가

  • 생성 코드 사용에 관한 윤리·환경·사회적 고려는 잠시 제쳐 두고, 오픈소스 프로젝트에서 LLM이 만든 코드의 기여를 받아들일지 실용적 관점에서 살펴봄.
  • 가능한 입장은 세 가지임.
  • 안전장치나 사람의 검토 정책을 두거나 두지 않은 채, LLM을 기여자가 사용할 수 있는 중립적 도구로 대체로 받아들임.
  • 타협하거나 결정을 미루고, 찬성도 반대도 아닌 지침을 내놓음. 이를 현재 ‘Debian AI 정책’이라고 부름.
  • 주요 안전장치를 둔 예외를 허용할 수는 있지만, LLM을 강하게 거부함.
  • 두 번째 중간 입장은 가장 합리적으로 보일 수 있고 기본 선택이기도 하지만, Debian 사례에서 알 수 있듯 누구도 만족하지 못함.
  • 장기적으로 보면 중간 입장은 지속 가능하지 않음. ‘사람의 검토가 필수’ 같은 안전장치가 있더라도 LLM 생성 기여는 결국 들어오며, 중간 입장을 오래 유지할수록 생성 코드가 프로젝트에 스며드는 일을 피하기 어려워짐.
  • 결정을 내리지 않거나 중간 입장을 택하는 것은 생성 코드의 완전한 수용을 늦출 뿐이며, 이를 명시하지 않은 채 사실상 첫 번째 입장, 즉 AI 찬성 입장을 고르는 일임. 이는 순진하거나 위선적인 선택이라는 주장임.
  • 외부 상황이 대신 결정하게 두지 말고, 각 오픈소스 프로젝트가 AI 생성 기여를 받을지 긴급히 선택해야 한다는 입장임.
  • 어느 쪽을 택해도 커뮤니티 일부와 핵심 기여자를 소외시킬 수 있으며, 프로젝트가 모두를 만족시킬 수는 없음.
  • 바이브코드 찬성이나 생성 코드 반대가 철학적·윤리적·실용적으로 더 나은지 논의할 수 있지만, 프로젝트에 최선인 선택은 핵심 커뮤니티 구성원만 결정할 수 있음.

AI 수용

  • 장점은 기여가 늘고 번거로운 작업에 들이는 개발 시간이 줄어드는 점임. 관련 연구가 LLM 사용이 직접 코드를 작성하는 것보다 느리다고 보는 경향이 있지만, 여기서는 그 이점을 인정함.
  • 단점은 바이브코드 소프트웨어를 거부하는 커뮤니티 구성원을 소외시킬 수 있다는 점임. 일부 자유·오픈 소스 소프트웨어(FLOSS) 커뮤니티에서는 영향력 있는 사용자도 여기에 포함될 수 있음.
  • 프로젝트 개발이 비싸고 완전히 독점적이며 프로젝트가 통제할 수 없는 소프트웨어에 점점 더 의존하게 됨.
  • 단기적으로 AI를 수용하는 일은 일부 커뮤니티 구성원을 소외시키고 독립성을 포기하는 대가로, 인식된 생산성을 높이는 선택임.

AI 거부

  • 장점은 ‘윤리적’ 커뮤니티 구성원의 강한 지지를 얻는 점임. 반AI 소프트웨어 목록이 늘어나는 현상이 그 사례임.
  • 또 다른 장점은 아무것도 바뀌지 않는다는 점임.
  • 단점은 AI를 정말 사용하고 싶어 하는 일부 기여자를 소외시킬 수 있다는 점임.
  • LLM을 사용할 수 없다는 이유만으로 프로젝트 참여를 완전히 포기하는 기여자는, 프로젝트가 Debian식 ‘AI 적당히 사용’ 입장을 취하더라도 함께하지 않는 편이 나을 수 있다는 주장임.
  • LLM 없이는 기여하고 싶지 않은 사람은 코드를 스스로 검토하고 이해할 수 없거나, 머지않아 그 능력을 잃을 수 있음.
  • 이를 보여 주는 사례로, 자신의 코드를 시험할 지식이 없다고 인정한 GitHub 풀 리퀘스트(PR)의 수가 제시됨.
  • 따라서 이들의 기여를 거부하는 일은 단점보다 장점에 가까울 수 있음.
  • 더 중요한 점은 AI 거부가 사용자를 소외시키지 않는다는 주장임. 사람이 만들었다는 이유로 소프트웨어 사용을 거부한다는 사람은 없다는 논리임.

장기적 관점

  • 생성 코드 사용의 주요 문제 가운데 하나는 장기적인 영향이 아직 밝혀지지 않았다는 점임.
  • 기여를 거듭할수록 사람이 이해하는 정도가 낮아지면 코드베이스가 어떤 모습이 될지, AI 도우미가 갑자기 너무 비싸져 아무도 아키텍처를 이해하지 못하게 되면 어떻게 될지 질문을 던짐.
  • 코드의 상당 부분이 서로 호환되지 않는 라이선스를 가진 다른 프로젝트에서 복사된 것이라면 생길 문제도 제기함.
  • Cory Doctorow는 생성 코드를 석면에 비유함. 처음에는 보기 좋고 반짝이며 어디에나 쉽게 쓰이지만, 통제권을 되찾거나 제거해야 할 때는 최소 수년의 작업이 들 수 있다는 비유임.

각 프로젝트의 파스칼의 내기

  • 대중 마케팅이 놓칠까 봐 두려워하는 심리(FOMO)를 부추기는 상황에서, 가장 합리적이고 실용적인 접근은 당분간 프로젝트에 들어오는 모든 AI 생성 기여를 강하게 거부하는 것이라는 주장임.
  • 언젠가 LLM이 세상에 도움이 되고, 윤리적이고 신뢰할 수 있으며 지속 가능한 해결책으로 발전하고, 이를 쓰는 사람들이 더 행복하다는 사실을 깨달을 수도 있음. 그런 일이 실제로 일어난다면 AI 정책은 언제든 바꿀 수 있고, 그 변경에는 비용이 들지 않음.
  • 반대로 지금 생성 코드를 받아들이면 영원히 후회하거나 프로젝트를 포기해야 할 수도 있음.
  • 지금 AI 생성 기여를 거부해서 생길 수 있는 최악의 후회는 ‘진작 그렇게 했어야 했다’는 정도의 매우 가설적인 후회임.
  • 결론은 AI에 중립적인 프로젝트라면 실용적인 선택은 AI 생성 기여를 강하게 거부하는 것이라는 주장임.