▲

Yt-dlp: 전체 YouTube 지원을 위해 외부 JavaScript 런타임이 이제 필수

 (github.com/yt-dlp)
7P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • yt-dlp는 수천 개의 사이트에서 오디오·비디오를 다운로드할 수 있는 명령줄 기반 다운로드 도구로, youtube-dl의 포크 버전
  • YouTube의 n/sig 복호화를 위해 새로 추가된 yt-dlp-ejs 모듈과 함께 외부 JavaScript 런타임(예: Deno, Node.js, Bun, QuickJS)이 필요
  • Deno가 기본 런타임으로 설정되어 있으며, 사용자는 --js-runtimes 옵션으로 다른 런타임을 지정 가능
  • 이 변경으로 YouTube 관련 기능을 완전하게 사용하려면 yt-dlp-ejs와 JS 런타임 설치가 필수
  • 외부 런타임 의존성 추가는 YouTube 암호화 구조 변화에 대응하기 위한 필수 조치로, 향후 유지보수의 핵심 요소로 작용

yt-dlp 개요

  • yt-dlp는 youtube-dl의 포크로, 더 이상 유지되지 않는 youtube-dlc를 기반으로 개발된 프로젝트
  • 수천 개의 웹사이트에서 오디오 및 비디오를 다운로드할 수 있으며, 다양한 형식 선택·후처리·자막·플러그인 기능을 지원

YouTube 지원 관련 변경

  • YouTube의 n/sig 값 복호화를 위해 yt-dlp-ejs 패키지가 필요
    • 이 패키지는 Unlicense 하에 배포되며, MIT 및 ISC 라이선스 구성요소를 포함
  • yt-dlp-ejs 실행에는 JavaScript 런타임이 필수
    • 지원 런타임: deno(권장), node.js, bun, QuickJS
    • 관련 설정은 --js-runtimes 옵션으로 지정 가능
  • --no-js-runtimes 옵션을 사용하면 기본 런타임 설정을 초기화할 수 있음

설치 및 의존성

  • yt-dlp는 Python 3.10+ (CPython) 및 3.11+ (PyPy) 버전을 지원
  • 강력히 권장되는 의존성:
    • ffmpeg / ffprobe: 오디오·비디오 병합 및 후처리용
    • yt-dlp-ejs: YouTube 암호화 해제용
    • JavaScript 런타임: yt-dlp-ejs 실행용
  • 선택적 네트워크 의존성으로 certifi, brotli, requests, curl_cffi 등이 있음

주요 명령 옵션

  • --js-runtimes RUNTIME[:PATH]: 사용할 JS 런타임 지정
  • --no-js-runtimes: 모든 JS 런타임 비활성화
  • --remote-components COMPONENT: 외부 JS 구성요소를 허용할 수 있는 옵션
  • --no-remote-components: 원격 구성요소 로드를 차단

중요성

  • 이번 변경으로 yt-dlp는 YouTube의 최신 암호화 구조를 완전 지원하기 위해 외부 JS 런타임을 필수로 요구
  • 이는 YouTube의 지속적인 보안·암호화 업데이트에 대응하기 위한 구조적 전환으로, 향후 유지보수 및 기능 확장에 핵심적인 변화임
▲
kimjoin2 17시간전  [-]

우와... 막는것도 대단하고 그걸 뚫는것도 대단 한 것 같아요. 어떻게 분석하고 뚫는거지

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • Arch 리포지토리에 이미 포함되어 있어서 바로 작동함
    yt-dlp --cookies-from-browser firefox --remote-components ejs:github ... 명령어에 플래그만 추가하면 됨
    실행 시 solver를 런타임에 다운로드하는데 0.5초 정도밖에 안 걸림. 다운로드 시작 속도가 훨씬 빨라진 느낌임
    다만 제한된 환경에서 실행할 때는 solver를 미리 별도 명령으로 받아둘 수 있으면 좋겠음. 지금도 만족스럽지만, 패키징 자동화가 되면 더 편할 것 같음

    • 속도가 빨라졌다니 반가움. 요즘 브라우저에서도 YouTube가 제대로 안 돌아가는데, Python 스크립트로 접근 가능하게 유지하는 팀이 대단함
    • 어떤 환경에서 Python은 되는데 JS는 안 되는지 궁금함
      보안이 걱정이라면 Deno를 쓰는 한 샌드박스 처리가 잘 되어 있음
      만약 Deno나 Node가 지원되지 않는 OS라면 C로 작성된 QuickJS를 고려할 수도 있음. 느리긴 하지만 거의 모든 환경에서 작동함
      다만 이 경우 샌드박싱은 사라짐. 그래도 공식 YouTube 도메인에서 제공되는 코드라면 신뢰할 만하다고 생각함
    • solver를 미리 받고 싶다면, 아무 영상이나 한 번 다운로드한 뒤 yt-dlp의 캐시 디렉터리(예: /home/username/.cache)에서 ejs 파일을 복사하면 됨
      혹은 make yt-dlp-extra로 패키징 자동화를 시도해볼 수 있음
    • AUR의 yt-dlp-ejs 패키지가 바로 그 목적에 맞는 것 같음
    • 나는 Deno를 Chocolately로 수동 설치했고, yt-dlp도 choco로 설치해서 버전은 v2025.10.22임

  • 최근 YouTube가 임베드 영상에 referrer 헤더를 강제하기 시작했음
    직접 youtube.com/embed/<videoid>로 접근하면 오류가 뜨고, FAQ에도 의도된 정책이라고 명시됨
    공식 문서에 따르면, 임베더는 HTTP Referer를 제공해야 하며, 그렇지 않으면 “error 153” 화면이 표시됨

    • 대부분의 임베드 서비스가 점점 이런 식으로 변함. 트래킹 강화가 목적임. 심지어 로그인 요구까지 하는 경우도 있음
    • 사실 간단한 JS 리디렉터 한 줄로 우회 가능함. 구현 비용은 수십만 달러인데, 우회 비용은 0임. 결국 “우리가 원하면 얼마든지 막을 수 있다”는 메시지 같음

  • 1991년 QuickTime이 나왔을 때는 영상도 그냥 복사·붙여넣기·저장이 당연하다고 생각했음
    지금은 DRM도 없는 영상조차 사용자 경험이 너무 나빠진 게 믿기지 않음

    • 예전보다 지금이 훨씬 나음. 과거엔 RealPlayer, Flash, 코덱팩 등 설치하다가 애드웨어로 시스템이 망가지는 일이 흔했음.
      지금은 OS 기본 플레이어나 VLC 하나면 대부분 해결됨
    • 90년대 초는 PC가 가장 흥미롭던 시기였음. 지금은 스마트폰이 주류가 되면서 일반 사용자에게 복사/저장 개념은 스크린샷이나 화면 녹화로만 남아 있음
    • 영상은 데이터 밀도가 높아서 호스팅 비용이 큼. 그래서 YouTube 같은 대형 플랫폼만 남았고, Nebula·PeerTube·Odysee 같은 대안은 품질이나 비용 면에서 한계가 있음
    • 예전엔 사용자 중심 최적화가 목표였지만, 지금은 기업이 자기 이익 우선으로 움직이는 시대임
    • ATSC 3 방송 표준도 DRM을 늦게 추가하면서 기존 수신기들이 호환되지 않는 문제가 생김

  • 나는 2010년부터 yt-dlp(youtube-dl 시절 포함)를 써서 좋아요한 영상을 모두 아카이브하고 있음
    지금은 수만 개의 영상이 저장되어 있고, 그중 상당수는 이미 사이트에서 사라졌음
    NHK 스모 하이라이트처럼 한 달만 공개되는 영상도 저장해둠

    • 디지털 수집광이라고 할 수 있음. Google Memories처럼 주기적으로 예전 영상을 리마인드해주는 기능을 만들면 재밌을 듯함
    • 채널이 스스로 영상을 지우거나 삭제하는 경우가 많아서, 좋은 콘텐츠가 사라지기 전에 저장하기 시작했음
    • 인터넷의 모든 것은 언제든 사라질 수 있음. 중요한 건 직접 저장해야 다시 볼 수 있음
    • 스모 영상 저장하는 사람을 여기서 보게 될 줄은 몰랐음. 우리 같은 사람 꽤 있음
    • 콘텐츠가 넘쳐나는 시대에 굳이 모든 걸 저장할 필요가 있을까 생각함. 예전엔 MP3·영화 다 모았지만 지금은 사진만 클라우드에 보관함

  • 광고 차단과 광고 삽입의 끝없는 대결 속에서 결국 AGI/ASI가 등장할지도 모른다는 생각임.
    양쪽 모두 LLM을 쓰게 되고, 인간은 그 사이에서 주머니와 주의력을 빼앗기는 존재가 될 것 같음

  • 10년 후엔 YouTube가 브라우저에서 완전히 접근 불가능해질지도 모름
    태블릿 앱에 익숙한 세대가 주류가 되면, Google은 웹을 버릴 자신감을 가질 것 같음

    • 진짜 DRM을 강제하려면 전용 하드웨어가 필요함. 암호화된 스트림을 L2 인증된 기기에서만 재생하게 해야 함
    • 모바일 웹앱은 버그가 너무 많아서 거의 쓸 수 없음. 댓글도 자주 사라짐
    • 그래도 Google은 항상 웹 중심 전략을 유지해왔음
    • 브라우저로 YouTube 보는 세대도 여전히 많고, 중국의 bilibili 같은 대안도 존재함
    • 하지만 구매력 있는 세대가 브라우저 사용자라서, Google이 그 시장을 완전히 버리진 않을 것 같음

  • yt-dlp 이슈 #14404에서 Selenium이나 헤드리스 브라우저를 쓰자는 제안이 있었지만,
    유지보수 팀은 “그건 패배 선언이며 프로젝트의 정신에 어긋난다”고 답했음

  • 스크래핑은 정말 고된 일임. API가 자주 깨지고, 제공자가 우리를 싫어하는 상황에서 유지하는 건 대단한 일임

    • “제공자가 우리를 싫어한다”는 게 오히려 이 프로젝트의 묘미 같음
    • 나 같으면 절대 yt-dlp 유지보수 못 할 것 같음. 너무 소모적 작업임

  • YouTube가 점점 사용자와 대립적 태도를 보이는 게 느껴짐
    광고 차단 차단, AI 학습용 콘텐츠 수집, API 제한 등 경쟁이 없다는 걸 이용하는 듯함

    • 사실 Google의 진짜 고객은 광고주임. 우리는 그들의 상품일 뿐임
      광고주 만족에는 민감하지만, 사용자나 크리에이터는 소모품 취급임
      무료로 시작해 경쟁자를 없앤 뒤 독점 구조를 만든 건 일종의 미끼 전략이었음.
      이제는 새로운 대안이 필요함. 유료라도 투명한 서비스라면 좋겠음
    • 요즘 특히 어린이 영상에서 건너뛸 수 없는 광고가 늘었음
    • YouTube의 운영 비용이 워낙 커서, 광고 차단이 서비스 유지에 영향을 줄 수 있다고 생각함
    • 결국 지금의 엉망진창 UX(enshittification) 자체가 비즈니스 모델의 일부가 되어버림

  • yt-dlp EJS 위키에 따르면 Deno가 추천되는 이유는
    제한된 권한으로 코드 실행이 가능하고, npm에서 EJS 의존성을 원격으로 받을 수 있기 때문임

    • 하지만 Deno의 샌드박싱을 보안 수단으로 과신하면 안 됨. 런타임 수준의 격리는 약하므로,
      Firecracker 같은 OS/VM 레벨 격리를 사용하는 게 안전함
    • 예전엔 yt-dlp가 Python만으로 JS를 해석했지만, 점점 복잡한 런타임 요구가 생기면서 자체 인터프리터로는 한계가 있었음
답변달기