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

> Clean Markdown view of GeekNews topic #24333. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24333](https://news.hada.io/topic?id=24333)
- GeekNews Markdown: [https://news.hada.io/topic/24333.md](https://news.hada.io/topic/24333.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-11-13T09:51:08+09:00
- Updated: 2025-11-13T09:51:08+09:00
- Original source: [github.com/yt-dlp](https://github.com/yt-dlp/yt-dlp/issues/15012)
- Points: 12
- Comments: 2

## Summary

인기 **CLI 다운로드 도구 yt-dlp**가 이제 **YouTube의 n/sig 복호화**를 위해 **외부 JavaScript 런타임**을 필수로 요구합니다. 새로 추가된 **yt-dlp-ejs 모듈**이 YouTube의 복잡해진 암호화 구조를 처리하기 위해 JS 실행 환경을 필요로 하기 때문인데요, 기본값은 **Deno**이며 Node.js, Bun, QuickJS도 선택 가능합니다. Python 기반 도구에 JS 런타임 의존성이 추가된 것은 이례적이지만, 이는 YouTube의 빈번한 암호화 변경에 대응하기 위한 현실적인 선택으로 보입니다. 오픈소스 생태계가 점점 **언어 경계를 넘나드는 구조적 통합**으로 진화하고 있음을 보여주는 흥미로운 사례입니다.

## Topic Body

- **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](https://github.com/yt-dlp/ejs/blob/main/LICENSE) 하에 배포되며, **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의 지속적인 보안·암호화 업데이트에 대응하기 위한 구조적 전환으로, **향후 유지보수 및 기능 확장에 핵심적인 변화**임

## Comments



### Comment 46324

- Author: kimjoin2
- Created: 2025-11-14T13:58:33+09:00
- Points: 1

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

### Comment 46262

- Author: neo
- Created: 2025-11-13T09:51:09+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45898407) 
- 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 패키지](https://aur.archlinux.org/packages/yt-dlp-ejs)가 바로 그 목적에 맞는 것 같음
  - 나는 Deno를 Chocolately로 수동 설치했고, yt-dlp도 choco로 설치해서 버전은 v2025.10.22임

- 최근 YouTube가 **임베드 영상에 referrer 헤더**를 강제하기 시작했음  
  직접 `youtube.com/embed/<videoid>`로 접근하면 오류가 뜨고, FAQ에도 의도된 정책이라고 명시됨  
  [공식 문서](https://support.google.com/youtube/answer/171780?hl=en#zippy=%2Cprovide-a-http-referer-header-to-enable-video-playback)에 따르면, 임베더는 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](https://github.com/yt-dlp/yt-dlp/issues/14404)에서 Selenium이나 헤드리스 브라우저를 쓰자는 제안이 있었지만,  
  유지보수 팀은 “그건 **패배 선언**이며 프로젝트의 정신에 어긋난다”고 답했음

- 스크래핑은 정말 고된 일임. API가 자주 깨지고, 제공자가 우리를 싫어하는 상황에서 유지하는 건 대단한 일임
  - “제공자가 우리를 싫어한다”는 게 오히려 이 프로젝트의 묘미 같음
  - 나 같으면 절대 yt-dlp 유지보수 못 할 것 같음. 너무 **소모적 작업**임

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

- [yt-dlp EJS 위키](https://github.com/yt-dlp/yt-dlp/wiki/EJS)에 따르면 Deno가 추천되는 이유는  
  제한된 권한으로 코드 실행이 가능하고, npm에서 EJS 의존성을 원격으로 받을 수 있기 때문임
  - 하지만 Deno의 샌드박싱을 **보안 수단으로 과신**하면 안 됨. 런타임 수준의 격리는 약하므로,  
    Firecracker 같은 **OS/VM 레벨 격리**를 사용하는 게 안전함
  - 예전엔 yt-dlp가 Python만으로 JS를 해석했지만, 점점 복잡한 런타임 요구가 생기면서 자체 인터프리터로는 한계가 있었음