TL;DR

  • 7년 넘게 릴리스가 없는 typescript-ioc의 의존성 보안 문제를 고친 패치가 병합되지 않아, 사용자가 수년간 직접 유지하는 상황임.
  • 오픈소스의 어려움은 코드의 부족이 아니라 프로젝트를 이해하고 변경을 책임질 유지관리자 부족에 있으며, AI는 코드 이해에 드는 비용을 낮춤.
  • 특히 대규모 커뮤니티와 자금이 없는 소규모 라이브러리에서는 의존하는 사람들이 유지보수의 일부를 맡는 방안이 현실적임.
  • AI 덕분에 패치를 직접 유지하기 쉬워질 수 있지만, 기업이 변경 사항을 계속 보유하면 기여가 줄고 생태계가 더 파편화될 위험이 있음.
  • 오픈소스가 약속한 ‘소프트웨어가 작동하지 않으면 직접 고칠 수 있는 자유’를 AI가 실용적으로 만들 수 있으며, 수정 사항을 원 프로젝트에 돌려보낼지는 참여자에게 달려 있음.

오래된 의존성의 보안 문제와 미병합 패치

  • 7년 넘게 새 릴리스가 없지만 매주 수천 회 다운로드되는 소규모 의존성 주입 라이브러리 typescript-ioc를 사용함.
  • 의존성에 심각도가 높은 공통 취약점 및 노출(CVE)이 있어 보안 스캐너에서 경고가 발생함.
  • 의존성을 업데이트하고 패키지를 교체하는 풀 리퀘스트를 제출했으며, 테스트와 검증은 통과했지만 풀 리퀘스트는 여전히 처리되지 않은 상태임.
  • 이에 따라 패치를 직접 유지하며 수년간 사용함.

오픈소스 유지보수에서 AI가 줄이는 비용

  • 오픈소스에는 코드가 충분히 많고 때로는 지나치게 많지만, 프로젝트를 맡아 책임지려는 사람을 찾는 일이 늘 어려움.
  • 프로젝트에는 변경 사항을 이해하고 수정하고 검토할 책임감을 갖는 유지관리자가 필요함. 이 일 자체에 AI가 필요한 것은 아니며, 수십 년간 직접 해온 일임.
  • 다만 AI는 대개 비용이 가장 많이 드는 과정인 코드 이해를 더 쉽게 함.
  • 이 사례는 쉬운 편임. 패치가 작동하면 할 일이 거의 없음. 더 어려운 경우는 요구사항이 원 프로젝트와 달라지는 상황임.
  • 1년 뒤 새 릴리스가 나오면 무엇이 바뀌었는지, 프로젝트가 완전히 다시 작성됐는지, 기존 패치가 여전히 유효한지 파악해야 함. 첫 패치를 작성하는 일보다 시간이 지난 뒤 맥락을 다시 이해하고 재구축하는 일이 실제 비용임.
  • AI를 활용하면 코드를 훨씬 빠르게 이해할 수 있음.

소규모 라이브러리와 의존자의 유지보수

  • Linux, Kubernetes, React처럼 대규모 커뮤니티와 자금이 있는 프로젝트를 제외하면, 사람들이 매일 의존하는 소규모 라이브러리가 수천 개에 이름.
  • 사용자가 수천 명인 라이브러리도 유지관리자 한 명에게 의존할 수 있음. 유지관리자가 5년 전에 필요해서 만든 프로젝트가 어느새 인터넷 절반을 위한 무급 인프라가 된 경우도 있음.
  • 이런 프로젝트에서 가장 현실적인 방안은 의존자들이 유지보수의 작은 부분을 직접 맡는 것임.
  • 오픈소스는 원 프로젝트가 사라지거나 작동을 멈춰도 코드를 계속 보유할 수 있다는 뜻임. 동시에 유지보수 문제도 함께 물려받는다는 뜻임.
  • AI는 오픈소스가 제공하는 자유를 실제로 행사하는 비용을 낮출 수 있음.

패치 유지와 업스트림 기여 사이의 긴장

  • 패치를 직접 유지하는 일이 쉽고 저렴해지면 변경 사항을 원 프로젝트에 기여할 이유가 줄어들 수 있음.
  • 기업이 자체 변경 사항을 영구히 보유하기로 결정할 수도 있으며, 이는 오픈소스에 좋지 않음. 프로젝트 기여는 줄고 생태계는 더 파편화됨.
  • 소프트웨어가 더는 작동하지 않을 때 직접 고칠 수 있다는 것이 오픈소스가 오랫동안 약속해온 가치임.
  • AI는 그 약속을 마침내 실용적인 선택지로 만들 수 있음. 수정 사항이 업스트림으로 돌아갈지는 참여자에게 달려 있음.
  • 게시일: 2026년 10월 5일임.