무엇이 문제였나 — 수집 프로그램들이 나눠 쓰는 IP 하나
SGK 스튜디오는 유튜브 영상 내용을 시청 없이 텍스트로 파악하려고 자동화 도구를 여러 개 운영합니다. 볼 만한 영상 후보를 찾는 검색 프로그램, 자막과 화면을 통째로 저장하는 프로그램, 화이트보드나 다이어그램이 나오는 영상에서 프레임을 직접 뽑아 보는 프로그램, 채널 하나를 통째로 훑어 자막을 대량으로 모으는 프로그램, 그리고 무엇을 감시할지 자체를 찾아내는 채널 발굴 프로그램까지 — 전부 `yt-dlp`라는 같은 프로그램을 실행 축으로 씁니다.
이 자동화 전체의 목적은 영상을 보지 않고 텍스트로 읽는 데 있습니다. 13분짜리 영상 하나를 자막으로 받으면 6천 자 안팎의 글이 되고, 이 정도면 3분이면 다 읽을 수 있습니다. 수집 자체가 막히면 이 시간 절감이 통째로 사라지고, 사람이 다시 영상을 열어 직접 봐야 하는 원래 방식으로 되돌아갑니다.
이 프로그램들은 전부 같은 컴퓨터에서 돌아가고, 그 컴퓨터는 인터넷 주소(IP) 하나를 씁니다. 유튜브 서버 입장에서는 어느 프로그램이 보낸 요청인지 구분하지 않고 같은 주소에서 온 요청으로만 봅니다. 그래서 프로그램 하나가 짧은 시간에 지나치게 자주 요청을 보내면, 유튜브는 그 요청을 보낸 프로그램만이 아니라 그 주소 전체를 일시적으로 막습니다. 검색·자막 수집·프레임 캡처·채널 발굴까지, 그 순간 돌고 있던 다른 모든 수집 작업이 함께 멈추는 결과로 이어집니다.
이 위험은 짐작이 아니라 실제로 두 차례 드러났습니다. 하나는 채널 하나를 통째로 훑어 자막을 대량으로 모으는 프로그램에서, 다른 하나는 감시할 채널 자체를 찾아내는 새 프로그램을 만드는 과정에서 났습니다. 원인은 서로 달랐지만 결과는 같았습니다 — 한 프로그램의 요청 방식이 다른 모든 프로그램의 수집을 멈추게 했습니다.
이 위험이 문제가 되는 이유는 단순합니다. 유튜브 수집은 사람이 앉아서 지켜보지 않고 예약된 시간에 자동으로 도는 경우가 많은데, 차단이 나면 그 회차의 수집만 실패하는 게 아니라 같은 컴퓨터에서 예정돼 있던 다른 회차의 수집까지 함께 밀립니다. 프로그램 하나의 설계 실수가 그 프로그램만의 손해로 끝나지 않는다는 뜻입니다. 검색·자막 수집·화면 캡처·채널 발굴 하나하나는 서로 다른 시기에 따로 만든 프로그램이었지만, 인터넷 주소라는 자원 앞에서는 전부 같은 줄에 서 있었습니다.
채널 발굴 프로그램이 필요했던 이유도 숫자로 남아 있습니다. 어떤 채널을 감시할지 정하는 단계가 따로 없어서 감시 대상 채널 목록은 5개에서 멈춰 있었고, 그 5개마저 전부 같은 주제 축이었습니다. 이 목록을 넓히려고 후보를 찾는 절차부터 새로 만들었습니다. 질의 하나당 후보 채널을 30개씩 모으고, 그중 상위 500개만 골라 구독자 수와 최근 활동을 채널당 요청 1번으로 붙이고, 대표 영상 자막을 채널당 1편씩 발췌해 한 파일로 모아 사람이 한 번에 판정하는 절차였습니다. 이 판정을 통과한 채널은 등급을 T1부터 T4까지 넷으로 나눠 매기고, 그중 가장 신뢰도가 높은 등급만 실제 감시 목록으로 올렸습니다. 채널 하나를 감시 목록에 넣으면서 왜 보는지 이유를 적을 수 없으면 애초에 넣지 않는다는 원칙도 이 절차에 함께 붙였습니다.
처음 잰 숫자 — 동시에 돌리면 45초, 기본값대로면 편당 8번
2026년 8월 31일, 채널 정보를 모으는 프로그램과 자막을 모으는 프로그램을 동시에 실행해 봤습니다. 두 프로그램이 같은 인터넷 주소에서 요청을 겹치자 병행을 시작한 지 45초 만에 429 오류와 함께 봇으로 판정돼 차단당했습니다. 프로그램 하나의 요청량이 많아서가 아니라, 두 프로그램의 요청이 같은 순간에 겹친 것 자체가 원인이었습니다.
같은 날 다른 자리에서는 채널 하나를 통째로 훑어 자막을 모으는 프로그램의 기본 설정값을 다시 쟀습니다. 아무것도 좁히지 않은 기본값대로 돌리면, 영상 한 편마다 `yt-dlp`를 8번 호출합니다. 사람이 직접 올린 자막을 세 개 언어로, 그것도 서로 다른 두 개의 접속 방식으로 각각 시도하고(3언어 × 클라이언트 2), 여기에 자동 생성 자막을 두 번 더 시도하는 구성입니다. 자막을 확보하는 데 필요한 시도라기보다, 될 만한 조합을 전부 순서대로 두드리는 방식이었습니다.
이 여덟 가지 조합은 처음부터 실패를 각오하고 순서대로 두드리는 방식이었습니다. 사람이 올린 자막이 있으면 언어 세 가지를 우선 시도하고, 그마저 없으면 자동 생성 자막으로 넘어가는 순서였는데, 실제로 걸리는 조합이 정해져 있다는 사실은 나중에야 확인됐습니다.
채널 발굴 프로그램 쪽 수치도 그 무렵 함께 기록해 뒀습니다. 후보 수집은 질의당 요청 1번으로 30개씩 모으고, 정보 보강은 채널당 요청 1번으로 상위 500개까지 처리하고, 최종 판정은 50개씩 끊어 대표편 자막을 발췌하는 구조였습니다.
세운 가설 — 좁게 돌리면 빠르고 안전할 줄 알았다
편당 8번을 두드리는 대신, 기록 파일에 남는 접속 방식 항목을 살펴보면 실제로 자막이 잡히는 조합이 무엇인지 알 수 있었습니다. 영어로 된 채널에서는 자동 생성 자막을 tv 계열 접속 방식 하나로 받는 조합 하나만 걸렸고, 나머지 일곱 개 조합은 매번 허탕이었습니다. 그렇다면 처음부터 이 조합 하나로 좁혀서 돌리면 되지 않을까 — 이 관찰에서 가설을 세웠습니다.
8배라는 숫자는 작지 않았습니다. 채널 하나를 통째로 훑는 작업은 편수가 많을수록 걸리는 시간도 함께 늘어나므로, 시도 횟수를 8번에서 1번으로 줄이는 것은 전체 소요 시간을 8분의 1로 줄이는 것과 같은 뜻이었습니다. 이 정도 이득이면 굳이 다른 접속 방식까지 챙길 필요가 없어 보였습니다.
이 가설대로 설정을 좁히면 8번의 시도가 1번으로 줄어드니 속도는 8배 빨라집니다. 필요한 조합 하나만 두드리니 유튜브 쪽에도 부담이 적어 오히려 더 안전할 것이라고 판단했고, 이 설정 하나로 대상 채널 519편 전체를 한 번에 끝낼 계획을 세웠습니다.
채널 발굴 프로그램을 새로 짜면서는 또 다른 가정을 세웠습니다. 질의당 30개, 상위 500개, 최종 50개로 끊어 도는 이 프로그램은 자막 대량 수집 프로그램의 편당 8번에 비해 요청 자체가 훨씬 적으니, 전체가 함께 쓰는 공용 관문을 매번 거치지 않아도 괜찮을 것이라는 가정이었습니다.
가설이 틀린 지점 — 왜 200편을 넘기면 전부 막혔을까?
실제로 519편 채널에 이 좁힌 설정을 돌려 봤습니다. 처음 200편 가까이는 계획대로 빠르게 진행됐습니다. 그런데 그 지점을 넘기자 단일 접속 방식 자체가 봇으로 판정됐고, 그 뒤로 이어지는 모든 편이 예외 없이 실패했습니다. 좁혀서 도는 방식 자체가 문제가 아니라, 같은 방식으로 오래 반복해서 두드리는 것이 문제였습니다.
비슷한 시기인 2026년 9월 1일, 다른 자리에서도 가설이 무너졌습니다. 무엇을 감시할지 스스로 찾아내는 채널 발굴 프로그램을 새로 만들면서, 이 프로그램은 요청 자체가 적으니 굳이 전체 공용 관문을 거치지 않아도 되겠다고 판단했습니다. 그런데 이 프로그램을 돌리는 자리에서 곧바로 인터넷 주소 전체가 차단당했고, 그것도 한 번이 아니라 3번 반복됐습니다. "각 프로그램이 알아서 절제하면 된다"는 가정도 이 사건으로 함께 무너졌습니다.
실제로 걸리는 접속 방식이 하나뿐이라는 사실 자체가, 모든 요청이 결국 그 하나의 통로로 몰린다는 뜻이기도 했습니다. 조합을 여덟 가지로 나눠 두드릴 때는 각 조합이 나눠 맡던 부담이, 하나로 좁히자 전부 그 조합 하나에 쌓였습니다. 속도를 얻은 대신 그 조합이 감당하는 누적량도 함께 늘어난 셈이었는데, 이 관계를 처음 가설을 세울 때는 계산에 넣지 않았습니다.
진짜 원인 — 절제는 프로그램의 선의가 아니라 관문 하나가 강제해야 했다
200편이라는 경계는 접속 방식을 좁힌 것과는 별개의 층에서 걸리는 신호였습니다. 유튜브 쪽은 어떤 방식으로 요청했는지가 아니라, 같은 방식으로 누적해서 보낸 요청 횟수 자체를 보고 있었습니다. 접속 방식을 하나로 좁혀 속도를 얻는 대신, 그 방식 하나로 버틸 수 있는 누적량에는 처음부터 한도가 있었던 셈입니다.
채널 발굴 프로그램이 낸 차단은 층이 다른 원인이었습니다. 문제는 요청량이 아니라, 공용 관문을 거치지 않아도 프로그램이 정상적으로 실행되는 구조 자체였습니다. 관문을 통과하는 절차가 스스로 강제되지 않고 각 프로그램의 판단에 맡겨져 있으니, 새 프로그램을 짤 때마다 그 절차가 빠질 여지가 그대로 남아 있었습니다. 이번에 그 여지가 실제로 채널 발굴 프로그램에서 드러났습니다.
채널 전수로 자막을 모으는 작업에는 이미 관문을 통과하도록 짜 둔 스크립트 일곱 개를 그대로 재사용하는 관행이 있었습니다. 데이터 경로·파일 접두·언어·속도를 환경변수 네 종류(경로 지정·파일 접두·수동자막과 자동자막 언어·작업자 수와 간격)로 갈아 끼우기만 하면 어떤 채널이든 같은 절차로 돌릴 수 있었고, 관문을 통과하는 절차도 그 절차 안에 이미 포함돼 함께 따라왔습니다. 이 절차에서 언어에 따라 갈아 끼우는 부분은 자막을 정리하는 압축 단계뿐이었습니다 — 한국어 채널은 한국어 전용 압축 스크립트를, 영어 채널은 영어 전용 압축 스크립트를 썼고, 요청을 내보내는 절차 자체는 언어와 무관하게 똑같았습니다. 채널 발굴 프로그램은 이 관행 밖에서 처음부터 새로 짠 스크립트였습니다. 재사용하는 자리에서는 저절로 딸려 오던 절차가, 새로 짜는 자리에서는 저절로 들어오지 않았고, 그 차이가 그대로 구멍이 됐습니다.
봇 판정을 우회하는 방법도 접속 방식마다 달랐습니다. 자막까지 사람이 아니라는 판정 메시지로 막히면, 기본 접속 방식과 안드로이드 VR용 접속 방식은 똑같이 봇 판정에 걸렸고, tv용 접속 방식은 페이지를 다시 불러오라는 메시지만 반복했고, 아이폰용과 모바일 웹용은 받을 수 있는 형식이 없다는 응답만 돌아왔습니다. 웹 사파리용 접속 방식만, 형식 없음 오류를 무시하는 옵션과 함께 쓰면 자막을 받아 왔습니다. 접속 방식마다 막히는 방식과 통하는 방식이 서로 다르다는 사실이, 하나로 좁혀서 도는 전략이 결국 여러 접속 방식을 다시 갖추게 된 이유였습니다.
조치 — 2단계 수집과 관문 강제, 무엇을 바꿨나?
채널 전수 자막 수집은 두 단계로 나눴습니다. 1차는 자동 생성 자막만, 접속 방식도 걸리는 조합 하나로 좁혀 최대한 빠르게 끝까지 돌립니다. 2차는 접속 방식을 다섯 개(웹 사파리·안드로이드·아이폰·tv 계열·모바일 웹)로 다시 넓혀, 1차에서 실패한 편만 골라 다시 시도합니다. 완료 여부는 저장된 파일을 기준으로 판정하므로 몇 번을 다시 돌려도 이미 받은 편을 중복으로 다시 받지 않습니다.
설정은 환경변수 세 개로 갈아 끼웁니다. 1차는 수동 자막 언어를 비우고 자동 자막 언어를 영어로, 접속 방식을 tv 계열 하나로 지정해 돌리고, 2차는 접속 방식만 다섯 개로 넓혀 같은 스크립트를 다시 돌립니다. 스크립트를 새로 짜지 않고 값만 바꿔 두 단계를 오갈 수 있게 만든 것도 앞서 확인한 재사용 관행을 그대로 지키기 위해서였습니다. 이 규칙은 앞서 확인한 동시 실행 금지 규칙과도 같은 방향입니다 — 같은 컴퓨터에서 유튜브를 두드리는 프로그램은 순서를 어떻게 나누든 결국 하나의 관문을 통해서만 요청을 내보내야 한다는 원칙입니다.
관문 우회는 사람이 기억하는 방식이 아니라 절차로 막기로 했습니다. 새 수집 프로그램을 짤 때는 파일과 잠금장치로 컴퓨터 전체가 함께 쓰는 공용 관문을 통과하는 함수 두 개(허용 요청을 받는 함수, 성공·차단을 기록하는 함수)를 반드시 넣기로 정했습니다. 그리고 관문 자체의 전역 처리 한도 값을 6에서 2.5로 낮추고, 한도를 넘기면 30분 동안 요청을 아예 멈추는 쿨다운을 새로 걸었습니다.
새 스크립트를 검토할 때는 관문을 통과하는 함수 두 개가 코드에 실제로 들어 있는지부터 확인하는 항목을 점검 목록에 추가했습니다. 코드를 짜는 순간 자동으로 막아 주는 장치는 아니지만, 점검 목록에 올라 있는 항목과 아예 없는 항목은 다릅니다.
재측정 결과 — 회수율 95%, 최종 98.5%
2단계 전략을 519편 채널에 다시 적용해 쟀습니다. 1차에서 실패한 편을 2차로 회수한 비율은 303/318, 95%였습니다. 1차와 2차를 합친 전체 회수율은 511/519, 98.5%였습니다. 좁혀서 빠르게 돈 뒤 실패분만 넓혀서 회수하는 순서를 지키자, 처음부터 넓게 돌 때보다 빠르면서도 결과는 거의 같은 수준까지 올라왔습니다.
어느 접속 방식이 실제로 걸리는지는 기록 파일의 접속 방식 항목을 10편만 미리 받아 보면 판정할 수 있습니다. 이 확인을 건너뛰고 519편 전체를 기본값 그대로 돌리면, 애초에 8배 빠르게 끝낼 수 있었던 일을 그대로 8배 느리게 태우는 셈입니다.
이 결과는 접속 방식을 무작정 다섯 개로 넓혀 처음부터 돌리는 것과도 다릅니다. 처음부터 넓게 돌리면 속도에서 손해를 보고, 처음부터 좁게만 돌리면 200편을 넘기는 순간 전량 실패로 되돌아갑니다. 좁게 먼저, 넓게 나중이라는 순서 자체가 이번 재측정에서 확인한 결과였습니다. 8배 빠른 지름길과 98.5%짜리 안전망을 각각 따로 챙기는 대신, 둘을 순서로 이어 붙인 것이 이번 조치의 핵심이었습니다. 이 순서는 이후 다른 채널에도 그대로 적용할 수 있는 절차로 남았습니다. 채널마다 처음부터 접속 방식 다섯 개를 다 시도해 보지 않아도, 10편만 먼저 확인하면 그 채널에 맞는 1차 설정을 바로 정할 수 있습니다.
남는 한계 — 아직 사람이 지켜야 하는 규율
메타 수집 프로그램과 자막 수집 프로그램을 동시에 돌리지 않는다는 규칙은 여전히 사람이 기억해서 지켜야 하는 규율입니다. 두 프로그램이 같은 시간에 실행되지 않도록 기계가 순서를 강제하는 장치는 아직 없습니다.
200편이라는 경계도 이번에 관측된 값일 뿐, 앞으로도 같은 수치가 유지된다고 보장할 수 없습니다. 채널 크기나 시점에 따라 그 경계가 달라질 가능성은 그대로 열려 있습니다.
쿨다운이 도는 30분 동안은 이 관문을 지나는 다른 모든 프로그램의 수집도 함께 멈춥니다. 관문을 하나로 통일한 대가로, 한 프로그램의 실수가 쿨다운을 일으키면 그 여파도 예전처럼 그 프로그램 하나에 그치지 않고 전체로 번집니다. 관문을 하나로 모은 이유가 바로 이 여파를 통제하려는 것이었지만, 여파 자체를 없앤 것은 아닙니다.
채널 이름을 한글로 걸러야 하는 작업에는 또 다른 함정이 남아 있습니다. 접속 프로그램의 기본값은 다국어 채널의 제목을 영어 번역본으로 돌려주기 때문에, 지역명이나 사람 이름 같은 한글 키워드로 채널 목록을 거르면 대상의 일부만 걸립니다. 실제로 183편짜리 채널 하나가 목록에서 전부 영어 제목으로 나와 한글 필터가 일부만 걸린 적이 있었고, 쇼츠 탭에서도 같은 함정이 그대로 나타났습니다. 이번에 정리한 관문 규칙은 요청 속도와 요청 경로를 다뤘을 뿐, 이 언어 문제는 아직 손대지 않은 채로 남아 있습니다.
영상 자체를 내려받을 때도 비슷한 문제가 별도로 있습니다. 자막은 받아지는데 영상 파일만 403 오류가 나는 경우가 있었고, 이때는 접속 방식을 안드로이드 VR용으로 바꿔야 통과했습니다. 자막과 영상은 같은 컴퓨터에서 같은 관문을 지나지만 막히는 지점은 서로 다를 수 있다는 뜻이고, 이번에 정리한 규칙이 그 경우까지 전부 포괄하지는 못합니다.
새 수집 프로그램을 짤 때 공용 관문을 빠뜨리는 실수도 지금은 "반드시 넣는다"는 규율로만 막고 있습니다. 코드를 작성하는 단계에서 관문 통과 여부를 자동으로 확인해 주는 장치는 아직 만들지 않았습니다. 지금은 관문을 통과한 요청과 차단된 요청을 기록으로 남기고 있어서, 다음에 비슷한 사건이 나면 그 기록을 먼저 확인하는 것부터 시작할 수 있습니다. 이번에 정리한 규칙은 자동화 프로그램 수가 늘어날 때 반복해서 걸리는 문제와 뿌리가 같습니다. 자동화가 늘어난 만큼 셀 자격을 다시 따진 이야기도 자동화 개수 자체보다 무엇을 셀 자격이 있는지가 먼저라는 사례를 다룹니다. 외부 서비스에 반복 요청을 보내는 자동화를 직접 설계해야 하는 상황이라면 상담에서 저희가 실제로 쓰는 방식을 더 자세히 나눌 수 있습니다.