유튜브 채널 데이터 수집 인프라 용량 산정 | 10만~2억 채널 규모별 스토리지 설계

유튜브 채널 데이터를 대규모로 수집·저장하는 프로젝트는 단순 행 수가 아니라 행당 평균 크기와 누적 속도가 인프라 비용을 결정한다. 채널 메타데이터, 영상 카탈로그, 트렌딩 스냅샷, AI 분석 캐시가 각기 다른 비율로 증가하기 때문에 동일한 채널 수라도 저장 방식에 따라 필요한 용량이 수 배에서 수십 배까지 차이가 난다.

이 문서는 한 운영 사례(추정치)에서 관측된 데이터 분포를 기반으로, 채널 10만에서 시작해 2억 규모까지 확장할 때 필요한 스토리지 용량을 단계별로 추정한다. 모든 수치는 실제 서버 운영 정보가 아닌 일반화된 추정 모델이며, 비슷한 구조의 유튜브 데이터 파이프라인을 설계할 때 참고할 수 있는 기준값으로 제시한다.

핵심은 정규화 저장과 JSON blob 저장의 단가 차이, 그리고 Cloudflare D1처럼 단일 DB 한도가 명확한 서버리스 환경에서의 샤딩 전략이다. 두 요소를 분리해서 살펴보면 채널 규모가 커져도 예측 가능한 인프라 비용을 유지할 수 있다.

1. 데이터 분포와 행당 평균 크기

유튜브 수집 파이프라인은 보통 채널 메타, 영상 카탈로그, 트렌딩 스냅샷, 트렌딩 이벤트 아카이브 네 종류의 핵심 테이블을 가진다. 한 운영 사례(추정)의 분포를 정리하면 다음과 같다.

여기서 가장 눈에 띄는 항목은 트렌딩 이벤트 아카이브의 행당 98KB다. 이 수치는 일반적인 단일 영상 메타데이터 크기(400~800B)의 100배가 넘기 때문에, 거의 확실하게 이벤트 단위로 영상 묶음을 JSON blob 형태로 저장하는 구조라고 추정할 수 있다. 정규화된 행 단위 저장이라면 같은 정보를 1/100 크기로 압축할 수 있다.

1.1. 저장 방식별 단가 비교

1. 트렌딩 현재 스냅샷 스타일은 행당 약 750B로 가장 균형 잡힌 정규화 단가다.
2. 카탈로그 스타일은 행당 약 430B로 최소한의 메타데이터만 담은 경량 구조에 해당한다.
3. JSON blob 묶음 방식은 행당 약 98KB로, 같은 정보를 정규화한 경우 대비 약 130배 이상 크다.

핵심 포인트: 트렌딩 이벤트를 영상 단위 행으로 정규화하면 같은 정보량을 60~90% 줄일 수 있다. JSON blob 구조는 초기 개발 속도는 빠르지만 누적 용량 폭증의 주범이 된다.

2. 채널 10만 단위 환산 모델

채널 수를 기준으로 용량을 환산하려면 먼저 채널 1개당 평균적으로 몇 개의 영상·트렌딩 레코드가 생성되는지를 정해야 한다. 운영 사례 기준으로 채널 1개당 평균 영상 3.59개, 채널당 트렌딩 영상 약 4.44개라는 비율이 관측됐다고 가정한다.

2.1. 구성요소별 채널 10만 기준 용량

2.2. 시나리오별 합계

1. 트렌딩을 카탈로그 수준(430B)으로 최소 정규화하면 10만 채널당 약 870 MB.
2. 트렌딩을 트렌딩 현재 스타일(750B)로 정규화하면 약 1.0 GB 수준이며, 이 값이 현실적 권장 기준이다.
3. 트렌딩을 현재 JSON blob 구조 그대로 누적하면 약 44 GB까지 폭증해 사실상 운영이 불가능하다.

3. 보관 용량과 처리 용량의 차이

실무에서 흔히 놓치는 부분이 순수 보관 용량과 운영 중 실제 점유 용량의 차이다. 데이터 자체 크기만 계산하면 1 GB여도, 인덱스·WAL·임시 큐·중복 스냅샷·AI 캐시까지 합치면 같은 데이터가 약 1.7~1.9배의 디스크 공간을 차지한다.

3.1. 오버헤드 0.8 GB의 내역

1. 보조 인덱스 3~5개 기준 데이터의 20~30% 수준인 약 250 MB.
2. jobs 테이블과 수집 큐가 합쳐 약 55 MB.
3. analytics 로그가 약 57 MB.
4. 트렌딩 current와 events의 중복 스냅샷이 약 100 MB.
5. AI 분석 캐시가 채널 전체에 분산되어 약 270 MB.
6. D1 내부 WAL·임시 영역이 약 50 MB.

합산하면 약 780 MB의 처리 오버헤드가 발생하며, 보관 1.0 GB와 합쳐 운영 중 약 1.8 GB라는 추정치가 나온다.

핵심 포인트: 용량 산정 시 "채널 수 × 18 KB"를 운영 기준으로 잡으면 인덱스·캐시·로그를 포함한 실제 D1 점유 용량을 비교적 정확히 예측할 수 있다.

4. 규모별 풀 스택 용량 예측

채널 1개당 트렌딩 4.44개라는 비율을 유지한다고 가정할 때, 채널 규모별 용량은 다음과 같이 확장된다.

4.1. Cloudflare D1 한도 관점

1. D1은 DB당 10 GB 한도(유료 플랜 기준 추정)가 적용되며 인덱스·WAL을 포함한 실제 점유 용량으로 계산된다.
2. 단일 D1 DB의 실용적 안전선은 약 5~5.5 GB, 즉 채널 약 50만 도달 시점이다.
3. 채널 100만을 단일 DB로 운영하는 것은 불가능하며, 최소 2개 이상의 D1 인스턴스 분리가 필수다.
4. 카탈로그 4샤드 구조는 채널 50만까지는 적정하지만, 그 이상에서는 8샤드 확장이 권장된다.

5. 1억~2억 채널 규모의 현실적 추정

전 세계 유튜브 채널 수는 약 1.38억 개로 추산되며, 그중 구독자 1천 명 이상의 활성 채널은 약 1천만 개 수준으로 알려져 있다. 따라서 1억~2억 채널 시나리오는 사실상 유튜브 전수 디렉토리 복제에 해당한다.

5.1. 단순 비례 vs 분포 보정

단순히 10만 채널 = 1.8 GB 비율을 그대로 곱하면 1억 채널은 1.8 TB, 2억 채널은 3.6 TB가 된다. 그러나 유튜브 채널 분포는 극심한 롱테일이라 이 단순 비례는 과대 추정이다.

분포를 보정해 가중 평균을 내면 1억 채널 평균 약 4.7 KB/채널로 떨어진다. 이 모델 기준 1억 채널의 운영 용량은 약 850 GB, 2억 채널은 약 1.7 TB 수준으로 추정된다.

5.2. 트렌딩 아카이브의 별도 변수

트렌딩 영상은 채널 수보다 시간·국가·카테고리에 비례해 누적된다. 유튜브 트렌딩은 국가별 약 50개 × 약 200개국 × 카테고리별 × 일별로 갱신되므로 이론상 연간 3천만 건 이상의 스냅샷이 발생할 수 있다. 5년치 트렌딩 아카이브만 따로 100~200 GB의 추가 스토리지를 요구할 수 있다는 의미다.

6. 대규모 확장을 위한 권장 아키텍처

채널 1억 규모에서는 D1 단일 스택만으로는 비효율적이며, 데이터 성격별 저장소 분리가 필수다.

6.1. 단계별 마이그레이션 우선순위

1. 트렌딩 이벤트 JSON blob을 영상 단위 행으로 정규화해 가장 큰 용량 절감 효과를 우선 확보한다.
2. AI 분석 캐시에 TTL 정책을 적용해 오래된 임베딩·요약 결과를 R2로 이관한다.
3. analytics 로그를 Workers Analytics Engine 또는 외부 시계열 DB로 분리해 D1 부담을 줄인다.
4. 채널 30만~50만 도달 시점에 core 테이블의 스냅샷 이력을 별도 DB로 분리한다.
5. 채널 100만 도달 전 카탈로그 샤드를 4개에서 8개로 확장한다.

핵심 포인트: 1억 채널 풀 수집보다 "활성 채널 500만~1천만"을 타깃으로 한 약 100~200 GB 인프라가 비용·운영 효율 면에서 훨씬 합리적이다. 비활성 채널은 외부 API 호출 시점에만 가볍게 캐싱하는 전략이 권장된다.

7. 용량 산정 시 자주 빠뜨리는 변수

실제 운영을 시작하면 초기 모델보다 용량이 더 빠르게 늘어나는 경우가 많다. 주요 원인은 다음과 같다.

1. 시간 누적 효과: 채널 수가 고정되어도 트렌딩·영상 메타가 시간에 따라 계속 추가된다. 채널당 트렌딩 평균이 4개에서 10개로 늘면 10만 채널당 용량이 1.0 GB에서 약 1.5 GB로 증가한다.
2. 인덱스 폭증: 검색·필터 요구가 늘면서 보조 인덱스가 5개에서 10개로 늘면 인덱스 용량만 데이터의 50%를 넘기도 한다.
3. 중복 스냅샷: trending current와 trending events가 같은 영상을 두 벌 저장하는 경우 카탈로그 대비 2배 용량을 소비한다.
4. AI 캐시 누적: 임베딩·요약 결과를 무제한 보관하면 채널 메타보다 더 큰 용량을 차지하기 쉽다.
5. WAL과 임시 영역: 트랜잭션이 많은 시기에는 WAL이 일시적으로 데이터 용량의 10~20%까지 부풀 수 있다.

8. 마무리

위에서 살펴본 유튜브 채널 데이터 수집 인프라 용량 산정의 핵심 내용을 정리하면 다음과 같습니다.

핵심 요약:

• 채널 10만 기준 순수 보관 약 1 GB, 운영 중 약 1.8 GB가 현실적 추정치다.
• 트렌딩 이벤트를 JSON blob으로 저장하면 정규화 대비 약 100배 용량을 소비하므로 행 단위 정규화가 필수다.
• 운영 중 실제 점유 용량은 인덱스·WAL·캐시·로그를 포함해 보관 용량의 약 1.7~1.9배로 잡아야 안전하다.
• Cloudflare D1 단일 DB의 실용적 안전선은 약 5 GB, 즉 채널 약 50만 수준이다.
• 1억 채널은 분포 보정 시 약 850 GB, 2억 채널은 약 1.7 TB로 추정되며 D1 단독으로는 운영이 불가능하다.
• 대규모 확장은 D1·R2·Vectorize·Workers Analytics Engine을 데이터 성격별로 분리하는 하이브리드 구조가 권장된다.

실무에서는 "전 채널 풀 수집"이라는 야심찬 목표보다 활성 채널 500만~1천만을 타깃으로 한 100~200 GB 인프라로 시작하고, 트렌딩 정규화·AI 캐시 TTL·analytics 외부 이관 세 가지를 우선 정비한 뒤 단계적으로 샤드를 확장하는 접근이 가장 비용 효율적이다.

자주 묻는 질문

• 채널 10만 개를 수집할 때 실제로 필요한 스토리지는 얼마인가요?

  정규화된 구조로 저장할 경우 순수 보관 용량은 약 1 GB 수준이지만, 인덱스·WAL·AI 캐시·로그를 포함한 운영 중 실제 점유 용량은 약 1.7~1.9배인 1.8 GB 정도로 잡는 것이 현실적입니다. 채널 수 × 약 18 KB라는 단순 공식으로 빠르게 추정할 수 있습니다.

• 트렌딩 데이터를 JSON blob으로 저장하면 왜 문제가 되나요?

  JSON blob 구조는 한 행에 여러 영상을 묶어 저장하기 때문에 행당 평균 크기가 약 98KB까지 커집니다. 같은 정보를 영상 단위 행으로 정규화하면 행당 약 750B로 줄어 약 130배의 차이가 발생하며, 시간이 지날수록 단일 DB 한도를 빠르게 소진하는 주요 원인이 됩니다.

• Cloudflare D1 단일 DB로 채널 몇 개까지 안전하게 운영할 수 있나요?

  D1은 일반적으로 DB당 10 GB 한도가 있으며 인덱스와 WAL을 포함한 실제 점유 용량으로 계산됩니다. 운영 안정성을 고려하면 약 5~5.5 GB를 안전선으로 잡는 것이 일반적이고, 이는 채널 약 50만 규모에 해당합니다. 그 이상에서는 샤딩이 필수입니다.

• 유튜브 전체 채널인 1억~2억 개를 수집하려면 어느 정도 인프라가 필요한가요?

  채널 분포가 극심한 롱테일이라 단순 비례보다는 보정 모델이 더 정확합니다. 보정 후 1억 채널은 약 850 GB, 2억 채널은 약 1.7 TB 수준으로 추정됩니다. 이 규모에서는 D1만으로는 불가능하고 R2, Vectorize, Workers Analytics Engine을 조합한 하이브리드 아키텍처가 필요합니다.

• 용량을 효과적으로 줄이려면 어떤 작업부터 해야 하나요?

  가장 효과가 큰 작업은 트렌딩 이벤트 JSON blob을 영상 단위 행으로 정규화하는 것입니다. 이것만으로 트렌딩 영역 용량을 60~90% 절감할 수 있습니다. 그다음 AI 분석 캐시에 TTL을 적용하고, analytics 로그를 Workers Analytics Engine 같은 시계열 전용 저장소로 옮기는 순서가 일반적으로 권장됩니다.

• 채널 수가 늘지 않아도 용량이 계속 증가하는 이유는 무엇인가요?

  트렌딩 영상, 영상 통계 스냅샷, AI 분석 결과는 시간에 비례해 누적됩니다. 채널 수가 고정되어도 채널당 트렌딩 평균이 4개에서 10개로 늘면 같은 채널 수에서도 용량이 약 1.5배로 증가합니다. 따라서 보관 기간 정책과 콜드 데이터의 R2 이관 전략을 함께 설계해야 합니다.