yt-dlp가 Bun을 손절했다 — 오픈소스가 보내는 런타임 경고음

오픈소스 생태계에서 “지원 중단(deprecate)“이라는 단어는 생각보다 무겁습니다. 특히 yt-dlp처럼 전 세계 수많은 개발자와 일반 사용자가 매일 쓰는 도구가 특정 런타임을 손절했다면, 그건 단순한 기술적 결정 이상의 신호인데요. 최근 yt-dlp가 Bun 지원을 공식적으로 deprecate하면서, 그동안 조용히 쌓여왔던 차세대 JavaScript 런타임에 대한 의구심이 수면 위로 떠올랐습니다.

yt-dlp는 왜 Bun을 버렸나

yt-dlp는 youtube-dl의 포크로 시작해 지금은 영상 다운로더의 사실상 표준이 된 프로젝트입니다. 메인은 Python으로 작성됐지만, 일부 플러그인과 확장 도구들이 JavaScript 런타임을 활용해왔는데요. 그중 Bun을 지원 옵션으로 두고 있었습니다.

하지만 메인테이너들이 결국 손을 들었습니다. 핵심 이유는 런타임 동작의 비일관성입니다. 같은 코드가 Node.js에서는 멀쩡히 돌아가는데 Bun에서는 예상치 못한 방식으로 깨지고, 버전이 올라갈 때마다 새로운 엣지 케이스가 튀어나오는 상황이 반복됐다는 거죠. 사용자 환경 디버깅에 들어가는 시간이 Bun 지원으로 얻는 이점을 넘어선 순간, 결정은 자명해집니다.

“빠른 런타임"의 그림자

Bun은 2022년 등장 이후 속도를 무기로 빠르게 주목받았습니다. Node.js보다 빠른 시작 시간, 내장 번들러, TypeScript 네이티브 지원까지. 벤치마크 그래프 한 장으로 개발자 커뮤니티를 흔들었던 기억이 있는데요.

문제는 벤치마크가 곧 프로덕션 신뢰도는 아니라는 점입니다. yt-dlp 같은 프로젝트는 윈도우, 맥, 리눅스, 그것도 수많은 배포판과 아키텍처에서 동일하게 돌아가야 합니다. 빠른 게 중요한 게 아니라 예측 가능한 게 중요한 영역이죠. Bun이 자랑하는 호환성 레이어는 “대부분의 Node.js 코드가 돌아간다"는 수준이지, “모든 케이스에서 동일하게 동작한다"는 보장은 아닙니다. 그 미세한 차이가 대형 OSS 프로젝트에서는 치명상이 됩니다.

이게 Bun만의 문제일까

흥미로운 건 이번 결정이 Bun이라는 특정 런타임을 넘어선 함의를 가진다는 점입니다. Deno 역시 비슷한 길을 걸어왔습니다. 야심차게 등장했지만, 결국 Node.js 호환 모드를 강화하는 방향으로 선회했죠. 차세대 런타임들이 공통적으로 부딪히는 벽은 단순합니다. npm 생태계 20년치 무게를 따라잡는 게 생각보다 훨씬 어렵다는 것.

yt-dlp의 결정은 “우리는 새 런타임을 지원할 여유가 없다"는 솔직한 고백이기도 합니다. 메인테이너 리소스가 한정된 OSS 프로젝트일수록, 검증되지 않은 런타임을 떠받치는 비용은 누적됩니다. 사용자가 “Bun에서 안 돼요” 이슈를 올리면, 그게 yt-dlp의 버그인지 Bun의 버그인지 가려내는 것부터가 일입니다.

그럼에도 Bun이 죽었다는 뜻은 아니다

오해는 말아야 합니다. Bun은 여전히 활발히 개발되고 있고, 특히 풀스택 신규 프로젝트나 내부 도구, 단순한 API 서버 같은 영역에서는 좋은 선택지입니다. 통제된 환경, 정해진 의존성, 명확한 배포 타깃이 있다면 Bun의 속도는 실질적인 이점이 됩니다.

다만 yt-dlp 케이스가 보여주는 건 명확합니다. 수만 명이 제각각의 환경에서 쓰는 범용 도구의 런타임으로는 아직 시기상조라는 것. “프로덕션 레디"라는 표현은 단순히 1.0 버전을 찍었다고 얻어지는 게 아니라, 수년간 다양한 사용자 환경에서 두들겨 맞으며 쌓이는 신뢰의 결과물입니다.

마치며

yt-dlp의 Bun deprecate 결정은 차세대 런타임의 실패라기보다는, 오픈소스 생태계가 신기술을 검증하는 자연스러운 과정에 가깝습니다. 화려한 벤치마크와 마케팅이 만들어낸 거품이 한 꺼풀 벗겨지고, 진짜 신뢰가 무엇으로 만들어지는지 다시 묻는 순간인 거죠.

여러분의 프로젝트에서는 어떤 런타임을 쓰고 계신가요? “빠르다"는 이유로 새 도구를 도입했다가 디버깅에 더 많은 시간을 쓴 경험은 없으신가요? 어쩌면 가장 지루한 선택이 가장 합리적인 선택일지도 모릅니다.