youtube-transcript-api가 유튜브에 차단됐을 때 — 실제로 통하는 해결책 4가지

증상: 로컬에서는 되고 프로덕션에서는 차단된다

Python 라이브러리 youtube-transcript-api는 유튜브 자막을 프로그래밍 방식으로 가져오는 가장 널리 쓰이는 방법입니다. 로컬 컴퓨터에서는 대개 아무 문제 없이 동작합니다. 그런데 코드가 클라우드 서버에서 실행되는 순간 IpBlocked, RequestBlocked, TooManyRequests 같은 예외가 발생하기 시작합니다. 유튜브가 IP를 차단하고 있다는 메시지가 함께 나오는 경우도 많습니다.

스크래핑에 의존하는 모든 방식이 똑같은 벽에 부딪힙니다. Node.js 자막 패키지, yt-dlp 자막 추출, 직접 만든 스크래퍼 모두 마찬가지입니다. 원인은 코드가 아니라 요청이 어디에서 출발했는가입니다.

워크로드가 AWS Lambda, Google Cloud Run, Vercel, Railway, Fly.io, 또는 아무 VPS에서 돌아간다면 유튜브에게는 데이터센터 IP 주소로 보입니다. 이 IP 대역은 공개되어 있고 봇이 대량으로 악용해 온 탓에 통째로 차단됩니다. 반면 집 Wi-Fi 같은 가정용 회선은 거의 차단되지 않습니다 — "내 컴퓨터에서는 되는데"가 이 경우엔 문자 그대로 사실인 이유입니다.

유튜브가 이런 요청을 차단하는 이유

유튜브 자막은 원래 외부 사용을 염두에 두지 않은 내부 비인증 엔드포인트에서 제공됩니다. 임의의 영상 자막을 가져올 수 있는 공식 공개 API는 존재하지 않습니다. 공식 Data API의 captions 엔드포인트는 영상 소유자의 OAuth 인증을 요구하므로 본인 영상에만 쓸 수 있습니다.

이 내부 엔드포인트는 무료이고 인증도 필요 없기 때문에 AI 기업, SEO 도구, 각종 스크래퍼가 끊임없이 두드립니다. 유튜브가 대응할 수 있는 방법은 하나뿐입니다 — 공격적인 요청 제한과 데이터센터 IP 대역의 통째 차단, 그리고 스크래핑 라이브러리를 하룻밤 사이에 망가뜨리는 엔드포인트 변경입니다.

결국 직접 운영하는 모든 방식은 영원한 술래잡기가 됩니다. 아래 네 가지 해결책은 직접 구축하는 쪽에서 관리형에 맡기는 쪽 순서로 정리했습니다.

해결책 1: 주거용 프록시로 요청 우회하기

가장 일반적인 자체 해결책은 회전형 주거용(residential) 프록시를 거쳐 요청을 보내, 유튜브가 서버 IP 대신 평범한 가정용 IP를 보게 만드는 것입니다. 최근 버전의 youtube-transcript-api는 이 방식을 직접 지원합니다. 클라이언트를 만들 때 프록시 설정을 넘기면 됩니다(라이브러리에 WebshareProxyConfig 헬퍼가 있고, 아무 HTTP/SOCKS 프록시나 쓰려면 GenericProxyConfig를 사용합니다).

동작은 하지만 비용이 만만치 않습니다. 주거용 프록시 대역폭은 보통 GB당 수 달러로 비싸고, 업체마다 품질 편차가 크며, 새로운 실패 지점이 생깁니다. 요청 도중 프록시 IP가 차단되면 재시도 로직, 헬스 체크, 업체 장애 조치를 직접 만들어야 합니다. 요청량이 적을 때는 프록시 네트워크를 한 번 더 거치는 만큼 가장 느린 선택이 되기도 합니다.

완전한 통제권이 필요하고, 유지보수에 쓸 엔지니어링 시간이 있으며, 구축 비용을 정당화할 만큼 트래픽이 많다면 이 방법을 고르세요.

해결책 2: 가정용 회선에서 수집기 돌리기

더 단순한 변형입니다. 파이프라인에서 자막을 가져오는 부분만 가정용 IP가 있는 환경 — 집에 둔 라즈베리파이, 사무실 PC, 저렴한 미니 PC — 에서 실행하고, 결과를 큐나 웹훅으로 클라우드 인프라에 넘기는 방식입니다.

프록시 비용이 전혀 들지 않고, 개인 노트 정리나 소규모 뉴스레터처럼 작은 워크로드에서는 의외로 잘 돌아갑니다. 단점도 분명합니다. 물리적인 단일 장애점이고, 확장이 불가능하며, 프로덕션 제품의 아키텍처로는 어색합니다.

해결책 3: 적극적으로 캐싱하고 오류 시 백오프하기

어떤 수집 방식을 쓰든 두 가지 습관이 차단률을 크게 낮춥니다. 첫째, 가져온 자막은 전부 캐싱하세요. 자막은 거의 바뀌지 않으므로 같은 영상을 두 번 가져올 이유가 없습니다. 영상 ID를 키로 하는 테이블 하나만 있어도 반복 트래픽 대부분이 사라집니다.

둘째, 차단을 즉시 재시도할 오류가 아니라 신호로 다루세요. 지터를 섞은 지수 백오프(1초, 2초, 4초, 8초…)는 눈에 띄지 않게 해 줍니다. 차단당한 직후 엔드포인트를 계속 두드리는 것은 IP 대역 전체를 밴당하는 가장 빠른 길입니다.

다만 이것은 완화책이지 해결책이 아닙니다. 데이터센터 IP에서는 첫 요청부터 차단될 수도 있습니다. 다른 세 가지 해결책 중 하나와 함께 쓰세요.

해결책 4: 호스팅 자막 API 사용하기 (관리할 인프라 없음)

관리형 선택지입니다. IP 문제를 이미 해결해 둔 서비스가 대신 자막을 가져오게 하는 것입니다. ParseJet은 엔드포인트 하나만 제공합니다 — 영상 URL과 함께 POST /v1/parse/youtube를 호출하면 자막 전문과 영상 제목, 채널, 재생 시간이 JSON으로 돌아옵니다. 차단 대응, 프록시 관리, 엔드포인트 변경은 서버 쪽에서 처리하므로 여러분의 코드는 세 줄이고, 앞으로도 세 줄입니다.

youtube-transcript-api에서 옮겨오는 데는 몇 분이면 충분합니다. 라이브러리 호출을 HTTP POST 한 번으로 바꾸면 됩니다(Python, Node.js 등 HTTP를 쓸 수 있는 어디서나 동작하며, 라이브러리 방식이 가장 잘 차단되는 서버리스 함수에서도 마찬가지입니다). 특정 자막 언어가 필요하면 language 파라미터로 요청하세요.

무료 플랜은 월 300 크레딧을 제공하고 유튜브 자막 1건에 5 크레딧이 드니 영상 60개를 처리할 수 있습니다. 유료 플랜은 월 $19부터입니다. 대부분의 제품에서는 주거용 프록시 대역폭 비용에 이를 관리할 엔지니어링 시간까지 더한 것보다 저렴합니다.

어떤 방법을 골라야 할까?

개인 프로젝트이고 요청량이 적으며 직접 만지는 데 거부감이 없다면: 해결책 2(가정용 회선 장비)가 무료이면서 충분히 안정적입니다.

요청량이 많고 인프라를 전담할 엔지니어링 역량이 있다면: 해결책 1(회전형 주거용 프록시)이 가장 큰 통제권을 줍니다. 프록시 비용과 지속적인 유지보수를 예산에 넣으세요.

자막이 핵심 사업이 아니라 하나의 기능인 프로덕션 앱, 에이전트, RAG 파이프라인이라면: 해결책 4(호스팅 API)입니다. HTTP 호출 한 번이면 끝이고 술래잡기도 없습니다. 어떤 경우든 해결책 3(캐싱과 백오프)은 함께 적용하세요.