YouTube 수집에서 search.list 는 아껴 쓰는 자원이다 — 채널 찾기에만 쓰고 나머지는 1 unit 경로로

YouTube Data API 로 영상을 모을 때 quota(하루 호출 한도)가 금방 바닥나는 사람을 위한 글이다. 다 읽으면 search.list 를 어디에만 쓰고 나머지를 어떤 호출로 바꿀지, 그리고 「지금 방송 중」 검색이 왜 놓치는 게 많은지 알 수 있다.

키워드를 16개까지 늘렸는데 0건

사이타마 라이브 카메라를 모아 지도에 올리고 있었다. 그런데 오미야 주변만 유난히 비었다. 검색어를 구 단위로 16개까지 늘려 봤지만 새로 나온 재생 가능 카메라는 0건이었다. 키워드 검색이 포화된 거다.

채널 이름이 곧 주소였다

찾던 카메라를 들여다보니 이 지역 라이브 카메라는 채널 하나에 카메라 하나였고, 채널 이름이 설치 주소 그대로였다. 埼玉県さいたま市大宮区桜木町ライブカメラ 같은 식이다.

그동안은 type=video&eventType=live 로 찾았다. 이건 지금 방송 중인 영상만 잡는다. 잠깐 끊긴 카메라는 통째로 안 보인다. 채널은 방송이 끊겨도 목록에 남는다. 그래서 type=channel 로 채널부터 찾고, 영상은 채널 안에서 꺼내는 쪽으로 바꿨다.

비싼 건 search 하나뿐이다

search.list 를 빼면 나머지는 전부 호출당 1 unit 이다. 채널을 찾은 다음에는 channels.list 로 업로드 재생목록 ID 를 받고, playlistItems.list 로 최근 업로드 50개를 받고, videos.list 로 50개씩 「지금 라이브인지」 「임베드가 되는지」 를 묻는다. playlistItems 에는 라이브 여부가 없어서 videos.list 가 꼭 필요하다(공식 문서의 playlistItem 리소스에 그런 필드가 없다).

채널 하나에 대략 2~3 unit 이다. 채널마다 search.list 로 「지금 라이브 중인 영상」 을 물어보는 방식과 비교하면 차이가 크다. 그쪽은 채널 수만큼 search 를 쓴다.

글 쓰려고 문서를 다시 봤더니 규칙이 바뀌어 있었다

수집 스크립트를 짤 때는 search.list 가 1회 100 unit 이고 하루 10,000 unit 을 다른 호출과 같이 나눠 쓴다고 알고 있었다. 이 글을 쓰면서 공식 문서를 다시 열어 보니 달라져 있었다. 2026년 6월 1일 개정으로 search.list 와 videos.insert 는 각자 따로 된 quota 통을 쓰게 됐고, 지금 quota 계산 페이지에는 search.list 가 「하루 100번, 1회 1」 로 적혀 있다(2026-10-15 갱신판 기준).

결론은 안 바뀐다. 예전 규칙이면 채널 65개마다 search 를 쓰는 데 6,500 unit, 하루치의 65% 였다. 지금 규칙이면 하루 100번 중 65번이다. 어느 쪽이든 search 는 제일 먼저 바닥난다. 프로젝트마다 한도가 다를 수 있으니 Google Cloud Console 에서 자기 숫자를 확인하자.

2026-08-24 에 잰 숫자

type=video 만 쓸 때는 65채널에서 라이브 24개를 찾았다. type=channel 을 더하니 138채널, 라이브 113개가 됐다. 지도에 실은 카메라는 41개에서 58개로, 오미야 10km 안은 16개에서 21개로 늘었다.

이때 138채널 · 5,710개 영상을 훑는 데 search.list 는 12번이었다. 나머지 호출은 약 275 unit. 스크립트는 예전 규칙으로 1,475 라고 셌고 그중 1,200 이 search 였다. 찾은 채널 ID 를 고정 목록으로 저장해 두면 다음부터는 search 를 거의 안 써도 될 거라고 보고 있는데, 이건 아직 재 보지 않았다.

YouTube API 로 수집 · 모니터링을 만들다가 quota 에 막혔다면 negabaro 에 구성을 보여 줘도 된다. 어디서 호출이 새는지 같이 본다.