yt-dlp, Bun 지원을 제한하고 폐기 수순으로 전환

• yt-dlp가 Bun 지원을 사실상 정리하기 시작함

  • 다음 yt-dlp 또는 ejs 릴리스부터 Bun은 1.2.11 이상 1.3.14 이하 버전만 지원됨
  • 기존 최소 지원 버전은 Bun 1.0.31이었는데, 이번에 하한선도 올리고 상한선도 새로 둔 셈임

• 하한선을 Bun 1.2.11로 올린 이유는 보안 쪽이 큼

  • Bun 1.2.0 이전 버전으로 ejs 패키지를 빌드하면 ejs 잠금 파일이 무시되는 문제가 있음
  • 요즘 npm 공급망 공격이 계속 터지는 상황에서, 잠금 파일이 무시된다는 건 꽤 위험한 신호임
  • 게다가 ejs 테스트 스위트가 Bun 1.2.11 이전 버전에서는 제대로 돌지 않아서, 검증 가능한 최소선도 1.2.11로 잡힘

• 상한선을 Bun 1.3.14로 둔 대목이 더 매콤함

  • yt-dlp 쪽 설명에 따르면 Bun은 최근 Claude를 이용해 Rust로 다시 작성됐고, 개발 흐름이 “vibe-coded” 쪽으로 간 것처럼 보인다고 봄
  • 그래서 기존 Zig 코드베이스에서 나온 마지막 릴리스인 Bun 1.3.14까지만 지원하겠다는 입장임
  • 표현이 꽤 직설적임. “나중에 골치 아플 게 보이니 미리 피하겠다”에 가까움

• Bun 지원은 제한만 되는 게 아니라 deprecated 처리됨

  • 당장은 좁아진 버전 범위 안에서 yt-dlp와 ejs 요구사항을 만족하는 동안 지원을 유지함
  • 하지만 유지보수 부담이 커지는 순간 Bun 지원을 완전히 제거할 권리를 남겨둠
  • 즉, Bun을 yt-dlp/ejs 조합에서 쓰는 사용자는 이제 “언젠가 빠질 수 있음”을 전제로 봐야 함

• 오픈소스 의존성 관리에서 꽤 흥미로운 선례임

  • 런타임의 성능이나 인기보다, 테스트 가능성·잠금 파일 처리·코드베이스 변화에 대한 신뢰가 더 중요하게 작동한 사례임
  • 특히 AI로 대규모 재작성된 런타임을 downstream 프로젝트가 어떻게 받아들이는지 보여주는 장면이라, Bun만의 얘기로 끝나진 않을 듯함

---

기술 맥락

• yt-dlp가 고른 선택은 “Bun을 당장 없애기”가 아니라 “검증 가능한 버전만 남기기”예요. 왜냐하면 ejs를 실행하는 런타임이 빌드와 테스트에서 예측 가능해야 하는데, Bun의 오래된 버전은 잠금 파일 처리부터 흔들렸거든요.

• 잠금 파일 문제는 단순한 귀찮음이 아니에요. 패키지 의존성의 정확한 버전을 고정하지 못하면, 같은 소스라도 설치 시점에 따라 다른 코드가 들어올 수 있고, 최근 npm 공급망 공격처럼 악성 패키지가 끼어들 여지가 커져요.

• Bun 1.3.14를 상한선으로 둔 건 코드베이스 신뢰도에 대한 판단이에요. 원문은 이 버전이 기존 Zig 코드베이스 기반의 마지막 릴리스라고 보고, 이후 Rust 재작성 흐름은 유지보수 리스크가 크다고 본 거예요.

• 이 결정이 개발자에게 중요한 이유는 런타임 선택이 “빠르냐 느리냐”만의 문제가 아니라는 점이에요. 내가 쓰는 도구가 의존성 잠금, 테스트 실행, 릴리스 신뢰성을 얼마나 잘 지키는지가 실제 운영 리스크로 바로 이어지거든요.