▲

유튜브 다운로더 Yt-dlp, 다운로드를 위해 Deno 설치 필수로 변경

 (github.com/yt-dlp)
23P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • yt-dlp에서 YouTube 다운로드를 계속 정상적으로 사용하기 위해 곧 Deno(또는 지원되는 JavaScript 런타임) 설치가 필수 조건으로 변경됨
  • YouTube 측의 최근 변화로 인해 내장 JavaScript "인터프리터"만으로는 JS 챌린지 해결이 불가해짐
  • PyInstaller 실행 파일 사용자는 Deno만 준비하면 되며, PyPI 패키지 이용 시는 추가 JavaScript 컴포넌트 설치 필요함
  • 타 JavaScript 런타임(Node, Bun 등) 지원도 가능성을 열어 두고 있으나, Deno만이 보안 및 샌드박싱 측면에서 적합함
  • Deno 및 관련 의존성 설치 방식, 경로 지정에 대해 별도의 옵션 및 안내가 제공될 예정임

yt-dlp의 YouTube 다운로드 변경사항 및 새로운 요구사항 발표

새로운 요구사항 도입 배경

  • 가까운 시일 내로 YouTube 다운로드 기능을 정상적으로 이용하기 위해 필수적으로 Deno나 기타 지원되는 JavaScript 런타임 설치 필요성 발생
  • 지금까지 yt-dlp는 내장 JavaScript 인터프리터를 활용하여 YouTube 측 JS 챌린지를 해결해왔으나, 최근 YouTube의 내부 로직 변화로 기존 방식만으로는 더 이상 대응이 불가능해짐
  • 변화의 폭이 매우 커서, yt-dlp는 정상 동작을 위해 반드시 정식 JavaScript 런타임 기반 알고리듬을 사용해야만 유튜브 요청을 통과할 수 있음

사용자별 준비 및 대응 방법

  • Deno(또는 지원되는 JS 런타임) 설치
    • FAQ 등 통해 추가적으로 지원되는 런타임 안내 예정
  • yt-dlp가 필요로 하는 일부 JavaScript 컴포넌트 설치 필요 가능
    • 설치 방식과 yt-dlp 배포 형태에 따라 추가 작업 필요 여부가 다름

공식 배포별 체크리스트

  • PyInstaller로 제공되는 공식 실행 파일(yt-dlp.exe, yt-dlp_macos, yt-dlp_linux 등)
    • Deno만 설치하면 되고, 추가 컴포넌트는 실행 파일에 이미 포함됨
  • PyPI 패키지(pip, pipx 등)
    • yt-dlp를 default 옵션 의존성 그룹으로 설치 및 최신 버전으로 업그레이드 필요
    • 예: pip install -U "yt-dlp[default]"
  • 공식 zipimport 바이너리(Unix용 yt-dlp)
    • Deno가 npm 의존성을 다운로드하도록 플래그 추가 필요
    • 또는, 별도의 yt-dlp용 JS solving 패키지를 Python 환경에 설치 필요(옵션 및 패키지명은 추후 공지)
  • 타사 패키지(pacman, brew 등)
    • 해당 배포판의 정책에 따라 조치가 달라질 수 있으나, zipimport 바이너리 이용자용 대응 방법 활용 가능

런타임 및 보안 관련 논의

  • Node, Bun 등 대체 JS 런타임 지원 가능성은 있으나, 현 시점에서 이들 런타임은 Deno만큼의 보안 및 샌드박싱 기능을 제공하지 못함
  • 향후 다른 JS 런타임 지원 여부는 논의 중이며, 최종 확정 전까지는 Deno를 기준으로 안내 진행

Deno 설치 관련 추가 안내

  • yt-dlp와 마찬가지로 Deno는 GitHub에서 제공하는 단일 실행 파일을 받아 경로에 두는 것만으로 사용 가능
  • 추후 yt-dlp에 --js-runtimes 옵션이 도입되어 Deno 실행 파일의 경로 지정이 가능해질 예정(옵션명 및 사용법은 변경될 수 있음)
  • Deno를 Curl 등으로 다운로드받은 후, yt-dlp 실행 파일과 같은 폴더에 두면 정상 동작 가능

FAQ 및 부가 안내

  • 사용 중인 OS나 패키지 관리자에 따라 PATH 추가 등이 필요할 수 있음
  • Linux 등 환경에 따라 Deno가 PATH에 자동으로 등록될 수 있음
  • 추가적인 질문 및 설치 관련 이슈는 FAQ나 커뮤니티에서 지원 예정

기타 커뮤니티 반응 및 향후 업데이트

  • 일부 사용자는 32bit 시스템 대응 중단 여부, 배포 옵션 등 다양한 파급효과에 대해 문의 중임
  • yt-dlp 개발팀은 이슈 등록, 패치, 커뮤니티 피드백을 바탕으로 더 나은 안내 및 지원 방안 마련 준비 중임

결론 및 요약

  • YouTube의 시스템 구조 변경에 따라 yt-dlp의 동작 구조 및 요구 사양이 대폭 변화함
  • 중요한 변화로, 정상적인 YouTube 다운로드 이용을 원할 경우 Deno 등 JS 런타임 준비 필수
  • 공식 배포 방식별 지침에 맞춰 신속한 대응 필요
  • 지속적으로 추가 안내와 FAQ, 설치 가이드 제공 예정
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 나는 YouTube Premium 유료 구독자임. 지난 주말 기차에서 볼 영상을 다운로드하려 했는데, iPad와 iPhone 양쪽에서 “다운로드 대기 중..” 단계에서 멈췄음. 재시작도 해결에 도움되지 않아 1시간을 시도하다 포기함. yt-dlp로 영상을 받아 USB c 플래시 드라이브에 옮겨서 시청함. 조만간 “가족 간 프리미엄 공유 제한” 정책이 도입되면, 그때는 진짜로 해지할 예정임. 가족이 광고 없는 환경을 잘 사용 중이기 때문임

    • 나도 프리미엄 구독자이지만 iPad 앱에서 비슷한 문제를 겪음. 아기에게 보여줄 영상을 다운로드하려 해도 한 번에 제대로 되지 않음. 짜증이 나서 중고로 Samsung Galaxy Tab A7을 사서 LineageOS로 커스텀 롬을 올렸음. 1TB sd카드에 원하는 미디어를 모두 담아 VLC로 잘 재생하고 있음. 추가로, F-Droid 스토어에서 받은 NewPipe는 공식 앱보다 훨씬 안정적으로 유튜브 영상을 다운로드할 수 있음. 원래는 yt-dlp 같은 걸로 미디어를 채우려 했지만 이젠 필요가 없어짐

    • YouTube Premium을 유료로 쓰고 있지만, 스마트폰에서는 번역 자동 적용을 꺼야 해서 ReVanced로 시청함. 공식 앱에서 사용자가 설정을 바꿀 수 없는 게 이해 안 됨

    • 유튜브에 동영상을 올린 다음, 크리에이터 대시보드에서 다운로드하려고 하면(예를 들어 라이브 스트림을 하고 로컬 백업 안 했거나 컴퓨터가 부담스러울 때) 720p 저화질로만 받을 수 있음. 반면, yt-dlp로 받으면 최고 화질을 얻을 수 있음

    • 광고 없는 환경이 YouTube Kids에서 동작하지 않아서(ShieldTV 이용 중) 구독을 취소함. 아마 버그였겠지만 고객 지원이 없으니 방법이 없었음. Play Music 유료 구독이었는데, 유튜브로 강제 전환된 뒤라 정말 마지막 실망이었음

    • 가족 공유 제한 정책 도입 소식을 기다렸다면, 이미 관련 소식이 있다는 정보를 전함. 나도 유튜브에서 이와 관련된 이메일을 받았음. 현재 광고 없이 사용 중이지만, 언제 실제 적용될지는 모르겠음. 관련 기사 확인 가능함

  • yt-dlp의 “JavaScript 해석기”에 들어간 엔지니어링 노력에 감탄함 yt-dlp jsinterp.py

    • 문제 해결에 딱 맞는 접근임. 추가 오버헤드 없이 이 정도까지 구현했다는 점이 정말 인상적임

    • 이번 발표에서 가장 숨겨진 핵심은 바로 이 부분임. 이미 이렇게까지 복잡한 구조가 되어 있는 줄 몰랐고 매우 감탄스러움

    • 자바스크립트의 일부분만 해석하는 방식임. 관련 HN 토론 링크 참고 가능함

    • 코드를 잠깐 들여다보니 파이썬의 ChainMap을 알게 됨

    • 실제로 얼마나 많은 자바스크립트를 해석하는지, 그리고 1,000줄도 안 되는 코드인데, 이를 컴파일러 입문 수업에서 활용할 수 있을지 궁금함

  • 30년 넘게 디지털 미디어를 수집해온 “디지털 hoarder”임. VHS, DVD 등 물리 매체는 없고 모두 디지털로 보관 중임. 진귀하거나 사라질 만한 자료들도 조금 있음. “집에서 넷플릭스처럼 운영”하는 내 시스템에 아내도 흥미를 가졌고, 광고 없는 시청을 즐거워했음. 나는 특별한 인물이라 생각하지 않았고 모든 이가 스트리밍을 쓸 거라 생각했음. 수년간 주변인에게 “내가 가진 미디어에 네가 좋아하는 프로그램 있으면 알려줘”라고 말해왔음. 최근 2년 간 가족, 친구들이 내 Jellyfin 서버 접근을 원하거나 자기 TV 밑에 소형 서버 구축을 요청함. 최근에는 Jellyfin에 유튜브 채널 아카이빙도 추가했고, 각 채널마다 디렉토리와 yt-dlp 명령어를 사용해 자동으로 영상을 받아옴. 다만, 내가 원하는 h264 코덱으로는 다운로드가 안 돼 재인코딩함. 유튜브 영상이 AV1 코덱으로 제공되는데, 아직 내 스마트 TV는 이 코덱을 지원하지 않아 직접 인코딩함

    • 예전엔 간단한 스크립트를 돌렸지만, 지금은 ytdltt ytdltt 깃허브로 Telegram 봇을 통해 어머니가 오디오북 같은 유튜브 영상을 원할 때 디렉토리별로 정리해 다운로드하고 Jellyfin으로 접근할 수 있게 해줌. 어머니가 3년 동안 모은 오디오북이 약 1.2TB임

    • 비슷한 목적으로 tubesync도 써볼 만함

    • h264 콘텐츠 다운로드가 안 되면 yt-dlp 문서가 어렵게 느껴졌는데, 현재 잘 되는 방법은 이런 식임
      yt-dlp -f "bestvideo[width<800][vcodec~='^(avc|h264)']+bestaudio[acodec~='^((mp|aa))']"

    • 최근 Pinchflat Pinchflat 깃허브를 알게 됐고, *arr 스타일의 웹 대안으로 yt-dlp를 백엔드에서 사용함. 다운로드하고 싶은 영상을 플레이리스트에 추가하면 자동으로 받아줌

    • 쿠키 등록 등으로 봇 감지 회피가 필요한지, VPN도 써야 하는지 궁금함

  • 이제 웹에서 단순히 데이터를 받아오는 시대는 끝나고, 수천 줄의 난독화된 자바스크립트를 실행해야 하는 시대임. 이전에는 1kb json 파일을 쉽게 받아 캐싱할 수 있었는데, 이제는 전체 브라우저를 실행해 100개의 요청에 10MB 데이터를 주고받으면서 분석 환경과 보안 프파일이 엉망이 됨. 모두에게 손해임

    • 긍정적으로 보면, 이렇게 불편한 환경 덕분에 10,000개의 스크래핑 회사가 10MB 쓰레기를 긁어와서 괜찮은 API로 제공하는 비즈니스 기회가 열렸음. 하지만 이제는 웹사이트 컨텐츠의 퀄리티도 낮아져서 이런 이슈가 점점 중요하지 않게 됨

    • 지금은 웹이 복잡해지면서 스크래핑-방지-우회가 끝없이 반복되는 게임 같음. 하지만 AI/LLMs가 등장하면서(더 비용은 들지만) 어떤 정보든 뽑아낼 수 있게 되었음. 곧 LLM이 모든 캡챠도 통과할 것임. “아날로그 홀”이 항상 열릴 수도 있는 시점임. 카메라와 마이크로 화면·소리를 비추기만 해도 AI가 인간보다 더 잘 해석할 수 있는 시대임

    • 다행이도 yt-dlp처럼 소규모 스크래핑은 그 어느 때보다 쉬워졌음. 한두 시간 투자해서 헤드리스 Firefox와 mitmproxy로 쉽게 스크립트를 만들 수 있고, 대규모로 VPS 여러 대를 돌려 전체 웹사이트를 긁지 않는 한 내가 원하는 콘텐츠는 무리 없이 아카이빙할 수 있음. Cloudflare도 저용량 일반 사용자는 막지 않음. 최신 브라우저 자동화는 쉬워서 단일 사용자는 사이트가 SPA라도 손쉽게 긁어올 수 있음. 캡챠도 적은 규모에서는 직접 풀 수 있음. 나도 최근엔 캡챠가 나오면 디스코드 알림으로 받고, 노트북에서 해결하고 계속 스크래핑하게 함. 유료로 산 웹툰을 “월드 가든” 앱이 통제하길래 내 데이터는 내가 컨트롤해야 한다고 생각함

    • 1kb json도 사실 최신 웹에서는 MB 단위의 자바스크립트를 받아야 실행해서 데이터 보여주는 구조임. 내가 원하는 건 그냥 10-20kb HTML과 약간의 CSS, 그리고 이미지 파일만 받아오면 됨. 동영상도 직접 mp4로 다운로드하면 끝임. 단순하고 효율적이지만, 뭔가를 팔 생각이 있으면 얘기가 달라짐

    • 이런 복잡함의 이유는 모두 더 많은 광고 판매가 목적임

  • Nsig/sig - API 호출에 반드시 포함돼야 하는 특수 토큰임. base.js(플레이어 코드)에서 생성되어 yt-dlp 등 3자 클라이언트가 우회해 추출해야 함. 예전엔 정규식 등으로 코드 일부를 뽑아 토큰을 얻었지만, 이제는 base.js 전체를 실행해서 토큰을 얻어야 할 정도로 코드가 분산되어 있음
    PoToken - 최근 구글이 강화한 기원 증명(token)임. 없으면 403 오류 발생함. 안드로이드에서는 DroidGuard, iOS는 앱용 내장 모듈, 웹에서는 JS 코드(챌린지) 실행이 필요함. 예전에는 외부 툴로 발급해야 했으나, yt-dlp의 Deno 기반 업데이트로 곧 내장 가능 예고됨
    SABR - 서버사이드 적응형 비트레이트 스트리밍 기술, 구글의 UMP 프로토콜과 함께 사용하며, 서버가 재생 위치/버퍼 상황을 받아 최적의 버퍼링과 광고 삽입까지 컨트롤함. 3자 클라이언트 대응은 아직 작업 중임
    Nsig/sig 추출 예시:

    • Google과 Cloudflare가 왜 웹을 서명되고 무결성 검증된 브라우저 몇 개로만 제한하려 하는지, 이제 이유를 알게 됨

    • 웹의 PoToken 관련해서, JS 스니펫을 돌리면 어떻게 봇이 아님을 증명하나 궁금함. 만약 그냥 클라이언트 JS라면 헤드리스 Chromimum에서도 동작하지 않나?

    • Google이 막 도입한 직후 벌써 우회 방법이 나오고 있음. 정말로 대기업이어도 클라이언트에 콘텐츠 전달하면 결국 우회 가능함. 그래서 이들은 모두 폐쇄된 독점적 생태계를 만들고 싶어함—그래야 광고를 끝까지 시청시키거나 사용료를 받을 수 있기 때문임

  • 얼마 전에 HN에 올라온 이야기 중 YouTube가 다운로드 툴이 돌아가길 원한다는 주장도 있었음 관련 글1 관련 글2. 유튜브는 전세계 30억 명이 쓰는 글로벌 서비스를 운영하면서, 다운로드를 완전히 막지는 않고 항상 ‘적당히’ 막는 느낌을 줌. 전 세계 사용자가 모두 최신 아이폰이나 안드로이드를 쓴다면 곧바로 DRM을 걸어버릴 수도 있다고 생각함

    • yt-dlp는 구식 스마트TV용 API를 활용함. 이들 기기는 더 이상 소프트웨어 업데이트를 받지 않으니 이 트래픽이 사라지면 이 기능도 종료될 수 있음

    • 콘텐츠 플랫폼이 수익 모델을 깨뜨리면서까지 다운로드를 지원하고 싶어한다는 음모론은 전혀 논리에 맞지 않는다고 생각함

  • 유튜브 플레이어·페이지가 점점 무거워져서 구형 PC엔 오히려 느린 진풍경이 펼쳐짐. 최근엔 “watch?v=”을 “/embed/”로 바꿔 480p로 봤는데, 같은 영상을 다운로드 받아 보면 CPU 사용량이 3% 정도에 불과함. 하지만 이마저도 점점 잘 동작하지 않게 변함. 한편, 다른 사이트(ex. 프론 사이트)들은 경험 최적화에 신경 쓰고, 다운로드 툴 차단에도 별 관심 없음
    영상(일반)
    영상(임베드)

    • GitHub도 마찬가지로 최적화가 안 되어 있어, i5 8세대 PC에서도 거의 못 쓸 정도임. 그래서 나는 아예 스냅샷을 받아서 오프라인으로 살펴봄

    • 요즘 유튜브 성능 저하의 원인은 모두가 최신 무거운 코덱만 사용하도록 강제해서임. 내 노트북은 4K h264 영상도 문제 없지만, 720p 유튜브 영상만 보면 금세 노트북이 뜨거워지며 버벅임. 브라우저 확장인 h264ify로 특정 코덱만 차단할 수 있는데, 왜 이런 기본 동작 자체를 조정할 수 없는지 아쉬움. 그냥 영상을 다운로드해서 보는 게 오히려 편하고 안정적임

    • 나만 그런 게 아님. 2025년 1분기에는 임베드 플레이어로 시청했지만, 3분기에는 임베드 플레이어를 Google이 일부러 막음. 현재 유튜브는 yt-dlp로만 접근 가능함. yt-dlp와 개발자들이 영원하길 바람

    • 나는 YouTube에서 벗어나 PeerTube/피어 기반 플랫폼으로 옮길 생각임

  • QuickJS(경량 JS 인터프리터)가 너무 느려서 각 영상마다 20분이 넘게 실행된다는 보고가 있음. Deno는 훨씬 빠른데, 어떻게 이렇게 차이가 날까 궁금함
    (참고 이슈#14404 / 답글)

    • QuickJS는 바이트코드 기반 인터프리터(파이썬처럼 느림)로 단순성과 안정성을 우선함. 반면 Deno는 Chrome 수준의 고효율 JIT 컴파일러를 사용하는데, 이 차이로 인해 특히 어떤 코드 상황에서는 실행 속도 차이가 20배 이상 벌어질 수 있음. QuickJIT(QuickJS의 포크, TCC 이용 JIT 추가)는 Deno보단 느리겠지만 개선 가능성은 있음

    • 성능이 이렇게까지 극적으로 나빠진 것은 Google이 일부러 다른 인터프리터에서 느리도록 만든 것 같기도 해서 무서울 지경임

    • 흥미로운 사실임. Minecraft(Bedrock, 모딩 용도)에서 QuickJS를 쓰는데, V8보다 느리긴 해도 이 정도까지 차이는 아닌 듯함

  • 이제 간편한 ripping 시대가 끝나려는 신호가 명확함. 장기 보관하고픈 YT 영상이 있다면 지금 당장 tubearchivist 같은 걸 설치해서 백업할 것을 추천함

    • pinchflat Pinchflat 깃허브도 대안으로 추천함. 완성도는 tubearchivist보다 낮지만, 경험상 버그가 적음

    • YT가 시장을 독점하며 얻은 가치 있는 문화·교육 자산은 지금이 마지막 보관 기회라 생각함. tubearchivist가 흥미로워 보이긴 하지만, 구축과 관리가 꽤 번거로워 보여서 부담됨. 게다가 구독 채널 전체에서만 다운로드하는 관점임. 내 경우엔 다운로드한 폴더만 있다면, 영상 이름을 해석해서 링크 페이지를 만들어주는 아주 가벼운 로컬 웹서버 솔루션이 있으면 충분함. 클릭 몇 번으로 설치할 수 있는 초경량 대안이 있다면 추천 바람

    • 유튜브 영화용으로는 이미 DRM 솔루션이 들어가 있는데, 왜 아직 전채널에 이 기술을 적용하지 않았는지도 궁금함

  • Deno를 선택한 점이 놀라웠지만, Deno는 단일 실행파일 형태로 배포가 쉬워 설치 이슈가 줄어듦. 파이썬 기반 인터프리터는 놀라운 해킹이었지만 한계가 있었고, 이 주제는 예전 Youtube-dl 프로젝트에서도 이미 논의됐음 과거 HN 토론

    • Node는 Deno처럼 보안과 격리 기능이 없음. 같은 쓰레드에서 메이턴러 의견도 볼 수 있음

    • Deno의 샌드박스 기능도 중요한 선택 이유임. 100% 신뢰할 수는 없지만 없는 것보다는 낫다고 생각함

    • yt-dlp는 유튜브뿐 아니라 수많은 다른(가끔은 위험한) 영상 스트리밍 사이트도 지원함. 따라서 브라우저처럼 최소한의 샌드박싱이 필수임. 설계상 신뢰할 수 없는 코드를 실행하게 되므로 기본 보안은 확보해야 함

답변달기