처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.05.23 54

yt-dlp가 Bun 지원을 사실상 접었습니다 — "빠른 런타임"의 그늘

Hacker News 원문 보기
yt-dlp가 Bun 지원을 사실상 접었습니다 — "빠른 런타임"의 그늘

무슨 일이 있었나요

유튜브를 비롯한 수많은 동영상 사이트의 영상을 받아 주는 그 유명한 yt-dlp가, 자바스크립트 인터프리터로 쓰던 Bun을 deprecated 처리한다고 공지했어요. 즉, 앞으로 Bun으로 yt-dlp를 돌리다 문제가 생겨도 적극적으로 고쳐 주지 않을 거고, 머지않아 완전히 빠질 가능성이 큽니다. 기본 권장은 Node.js 또는 Deno로 옮기라는 거예요.

yt-dlp가 왜 JS 런타임을 쓰는데요

이 부분이 처음 듣는 분들에게는 좀 의아할 수 있어요. yt-dlp는 파이썬으로 짠 도구잖아요. 그런데 왜 자바스크립트 런타임이 필요할까요?

이유는 유튜브의 영상 URL 보호 방식에 있어요. 유튜브는 영상의 진짜 URL을 그대로 노출하지 않고, 매번 바뀌는 "signature"를 자바스크립트로 계산하게 만들어 둡니다. 이걸 영어로 signature deobfuscation이라고 부르는데, 쉽게 말해 "플레이어가 실행하는 JS 코드를 그대로 흉내 내야 진짜 영상 주소가 나온다"는 뜻이에요. 게다가 이 JS 코드는 유튜브가 수시로 바꿔서 난독화 강도도 올려요. 그래서 yt-dlp는 파이썬에서 외부 JS 런타임을 호출해 그 코드를 그대로 실행시켜 버립니다.

원래는 Node.js, Deno, Bun, PhantomJS, jsdom 등 여러 후보를 두고 사용자가 깔려 있는 걸 자동으로 골라 썼어요. 그중 Bun이 시작 속도가 빨라서 매력적이었거든요. 매번 짧은 JS 한 조각만 실행하는 yt-dlp 입장에서는 "콜드 스타트"가 곧 사용자 체감 속도라서요.

그런데 왜 빼는 걸까요

이슈 트래커를 읽어 보면 이유는 비교적 단순해요. 호환성 버그가 너무 많이 들어온다는 거죠. Bun이 Node API와 웹 표준 사이를 자기 식으로 구현해 두다 보니, 같은 JS 코드를 돌려도 Node에서는 멀쩡한데 Bun에서만 묘하게 다른 결과가 나오는 경우가 종종 생긴다고 해요. yt-dlp가 다루는 JS는 유튜브가 "자기 플레이어에서 잘 돌아가게" 만든 코드라서, 표준 준수가 미묘하게 어긋나면 곧바로 "영상이 안 받아진다"는 사용자 보고로 이어집니다.

게다가 yt-dlp는 자원봉사자가 굴리는 프로젝트예요. 한정된 시간에 Node, Deno, Bun을 동시에 부드럽게 지원하려면 각 런타임의 미묘한 차이를 다 추적해야 하는데, 그 부담이 한계에 다다른 거죠. 결국 "가장 안정적이고 사용자가 많은 런타임에 집중하겠다"는 결정이 나온 셈입니다.

업계 흐름에서 보면

이 사건이 흥미로운 건, 최근 "새 자바스크립트 런타임"을 둘러싼 분위기를 압축적으로 보여 주기 때문이에요. Bun은 등장하자마자 "npm install이 빛의 속도다", "node 대비 4배 빠르다" 같은 벤치마크로 큰 주목을 받았죠. 그런데 production 환경, 특히 다른 사람들이 짠 JS 코드를 받아서 실행해야 하는 환경에서는 단순 성능보다 호환성과 예측 가능성이 훨씬 중요하다는 게 점점 드러나고 있어요.

반면 Deno는 비교적 보수적으로 Node 호환 레이어를 키워 왔고, 권한 모델과 표준 준수에 무게를 두면서 yt-dlp의 "권장 대안" 자리를 받아 갔습니다. 같은 "포스트 Node 런타임"이라는 카테고리 안에서 두 프로젝트의 방향성 차이가 이런 식으로 드러나는 게 인상적이에요.

한국 개발자에게 주는 시사점

현업에서 새 런타임을 도입할 때 "속도가 N배 빠르다"는 벤치마크만 보고 결정하는 건 위험하다는 걸 다시 일깨워 주는 사건이에요. 특히 우리 코드만 돌리는 게 아니라 외부에서 들어오는 JS, 서드파티 SDK, 빌드 도구 체인을 돌려야 한다면 호환성 이슈가 곧 운영 사고로 직결됩니다. 사내 도구나 CI에서 Bun을 "속도 때문에" 깔아 둔 곳이라면, 의존성 라이브러리들이 진짜 다 잘 도는지 한 번 점검해 볼 만한 타이밍이에요.

동시에 Bun을 폄하할 일은 아니에요. Bun도 빠르게 호환성을 메우고 있고, 단순한 스크립트나 패키지 매니저 용도로는 이미 충분히 쓸 만하니까요. "어디까지가 안전 지대인지"를 팀 안에서 합의해 두는 게 핵심이에요.

마무리

한 줄 정리하면, 벤치마크 위의 속도가 아니라 "내 코드가 진짜 돌아가는가"가 런타임을 고르는 진짜 기준이라는 거예요. 여러분은 사이드 프로젝트나 회사 도구에 Bun, Deno, Node 중 무엇을 쓰고 있고, 만약 yt-dlp 같은 결정을 내려야 한다면 어떤 우선순위로 판단하시겠어요?


🔗 출처: Hacker News

이 뉴스가 유용했나요?

이 기술을 직접 배워보세요

파이썬으로 자동화를 시작해보세요

파이썬 기초부터 자동화까지 실전 강의.

파이썬 강의 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.