유대선
← 프로젝트로
·기술 회고·9 분

YouTube 자막 가져오기 7가지 방안 — 하나도 모르는 사람을 위한 딥 해설

레지덴셜 프록시, CORS 프록시, 브라우저 확장, 큐레이션... 용어를 하나도 모를 때 각 방안이 정확히 무엇이고 왜 되거나 안 되는지를 바닥부터 푼다.

이 글은 2026-06-04-youtube-transcript-fetch-architecture.mdx의 후속이다. 거기선 비교표를 줬고, 여기선 각 용어/방안을 모른다는 전제로 바닥부터 푼다.

0. 먼저 — 5개 기초 개념

(1) IP 주소, 그리고 "가정용 vs 데이터센터"

인터넷의 모든 기기는 IP 주소(집 주소 같은 식별 번호)를 가진다. 그런데 IP는 출신이 둘로 나뉜다:

YouTube는 이 차이를 안다. 데이터센터 IP에서 오는 대량 요청 = 봇으로 의심 → 차단(쿠키/로그인 요구). 우리 백엔드가 AWS(데이터센터)에 있어서 yt-dlp가 막힌 게 정확히 이것.

(2) 스크래핑 / yt-dlp

스크래핑(scraping) = 웹사이트를 프로그램으로 긁어 데이터를 추출하는 것. yt-dlp는 YouTube를 스크래핑해서 영상·자막을 받아오는 유명한 오픈소스 도구. YouTube 공식 API가 임의 영상의 자막을 안 주기 때문에(자기 영상만 줌), 학습앱들은 yt-dlp류 스크래핑에 의존한다. → 그래서 ToS(이용약관) 회색지대.

(3) transcript / timedtext

transcript = 영상의 자막 텍스트(+타임스탬프). YouTube 플레이어가 자막을 켜면 내부적으로 **timedtext**라는 비공개 엔드포인트에서 자막을 받아온다. yt-dlp나 클라이언트가 노리는 게 이 timedtext 데이터다. (단, 이 URL엔 서명 토큰이 붙어 몇 분 뒤 만료된다 — 그래서 갓 따와야 한다.)

(4) CORS — 브라우저의 칸막이

CORS(Cross-Origin Resource Sharing) = 브라우저가 강제하는 보안 규칙. "A 사이트의 JS가 B 사이트(youtube.com)에 요청해서 응답을 읽으려면, B가 'A는 읽어도 돼'라는 헤더를 줘야 한다." YouTube는 그 헤더를 안 주므로, 웹앱 JS는 youtube.com 자막을 읽지 못한다. 이건 IP와 무관 — 브라우저 자체가 막는다. (네이티브 앱·서버엔 CORS가 없다. 브라우저에만 있다.)

(5) 프록시 — 남의 IP를 빌려 쓰기

프록시(proxy) = 내 요청을 대신 보내주는 중계 서버. 내가 프록시한테 부탁하면, 프록시가 자기 IP로 YouTube에 요청하고 결과를 나한테 돌려준다. → YouTube엔 프록시의 IP만 보인다. 그래서 "가정용 IP 프록시"를 쓰면 데이터센터 차단을 피한다.

7가지 방안, 하나씩 딥하게

방안 1 — 서버에서 yt-dlp (지금 Mimi가 하는 것)

구조: 폰/웹 → 우리 백엔드(AWS) → yt-dlp가 YouTube 긁음 → 자막 저장. 왜 깨지나: 백엔드가 데이터센터 IP라 YouTube가 봇으로 차단. (내 맥에선 가정용 IP라 됐다.) 비유: 회사(데이터센터) 전화로 100번 걸면 "스팸" 차단당하고, 집 전화로 걸면 받아주는 것.

방안 2 — 클라이언트(기기)에서 직접 가져오기 ← 우리가 가기로 한 길

구조: 폰 자체가 가정용 IP로 timedtext를 가져와 백엔드로 보냄. 백엔드는 저장만. 모바일은 ✅: 네이티브 앱엔 CORS가 없어서 youtube.com을 직접 fetch해 읽을 수 있고, 폰은 가정용 IP라 차단도 안 됨. 웹은 ❌: 브라우저의 CORS가 youtube.com 응답 읽기를 막음(IP와 무관). 비유: 자막을 서버에 시키지 말고 사용자 손(폰)으로 직접 따게 하는 것. 손이 진짜 사람이라 안 막힌다.

방안 3 — 브라우저 확장(extension)

구조: Chrome 확장이 youtube.com 페이지 안에서 실행(content script)되어 자막을 직접 읽음. 왜 되나: 확장은 일반 웹앱과 달리 CORS를 우회할 특권(host_permissions)이 있고, youtube.com 페이지 컨텍스트에서 돌아서 그 페이지의 자막 데이터에 접근 가능. 한계: 이건 웹사이트가 아니라 별도 제품(설치형 확장). Language Reactor가 이 방식. Mimi가 웹앱으로 하려는 것과는 다른 형태.

방안 4 — 레지덴셜 프록시 (서버 + 빌린 가정용 IP)

구조: 백엔드 → 레지덴셜 프록시 업체(Bright Data, Oxylabs 등) → 프록시가 진짜 가정집들의 IP로 YouTube에 요청 → 백엔드로 결과. 왜 되나: YouTube엔 가정용 IP만 보임 → 데이터센터 차단 회피. 웹·모바일 둘 다 서버가 처리하니 됨. 문제:

방안 5 — 큐레이션 카탈로그 (운영자가 미리 채움)

구조: 운영자(나)가 내 노트북(가정 IP)에서 영상들을 미리 import → 자막을 DB에 저장 → 유저는 카탈로그에서 고름. 유저 시점엔 live fetch가 0. 왜 되나: 차단도 CORS도 유저 요청 시점에 안 일어남. 이미 따둔 걸 보여줄 뿐. 문제: 유저가 임의 URL 못 넣음 / 운영자 노동 / 배포는 개인용보다 저작권 노출 큼 / 영상 삭제 시 stale. 장점: 어디서나 됨, fragile 0, "좋은 학습영상만 골라줌"은 오히려 기능. (LingQ식) 비유: 식당이 손님더러 장 봐오라 하지 않고, 주방장이 미리 손질한 재료로 메뉴를 차리는 것.

방안 6 — 유료 transcript API (남에게 위임)

구조: 백엔드 → 자막 API 업체(예: Supadata류) → 그쪽이 알아서 자막 돌려줌 → 저장. 왜 되나: 그 업체가 내부적으로 방안 4/프록시를 운영. 나는 결과만 산다. 문제: 호출당 과금 💰 / 제3자 의존(걔네가 죽거나 가격 올리면 끝) / 결국 ToS 회색을 위임한 것. 비유: 자막 따오는 걸 외주 대행사에 맡기는 것. 편한 대신 돈 + 의존.

방안 7 — 가정용 워커(셀프호스팅)

구조: 내 집에 작은 서버(라즈베리파이/구형 PC)를 두고, AWS 백엔드가 자막 일만 그 집 워커에 위임. 집 워커가 가정 IP로 따서 회신. 왜 되나: 집 IP = 가정용 → 차단 회피. 무료(전기값). 문제: 집 인터넷에 의존(끊기면 다운) / 운영 복잡 / 보안(집을 인터넷에 노출). 비유: 외주(방안 6) 대신 우리 집 차고에 직접 작업실을 차린 것. 공짜지만 내가 다 챙겨야 함.

핵심 한 줄 + Mimi의 길

"웹 + 임의 URL + 무료"를 동시에 만족하는 방안은 없다. 그래서: