유튜브급 동영상 플랫폼 시스템 설계: 업로드·트랜스코딩·추천 피드·CDN 경계
업로드 화면이 100%를 표시해도 창작자는 아직 영상을 공개할 수 없을 수 있다. 반대로 삭제 화면이 성공을 표시해도 오래된 피드와 캐시에는 흔적이 남을 수 있다. 유튜브급 동영상 플랫폼 시스템 설계는 이처럼 사용자가 보는 한 번의 행동을 업로드, 변환, 추천, 전달, 권한 철회라는 서로 다른 완료 조건으로 나누는 일이다.
이 글은 불안정한 네트워크에서 영상을 올리는 창작자와 빠르게 피드·재생 결과를 원하는 웹·모바일 시청자를 대상으로 한다. 2026년 7월 31일 기준 공개 표준, 공식 클라우드 문서, YouTube 공개 API와 Google Research 논문을 대조한 제품 중립 가상 설계다. 실제 YouTube의 비공개 구조나 운영 성능을 설명하지 않으며, 아래 처리량·지연·보존 수치는 선택을 비교하기 위한 설계 가정이다.
20초 핵심 요약
- 무엇: 창작자의 업로드·권한 변경과 시청자의 피드 조회·재생을 잇는 대규모 동영상 플랫폼 설계다.
- 왜: 업로드 완료와 게시 가능, 삭제 접수와 접근 차단을 한 상태로 다루면 중복 영상·끝없는 처리 중·삭제 영상 노출이 생긴다.
- 어떻게: 큰 동영상 바이트와 자주 바뀌는 제어 정보를 분리하고, 세 사용자 행동의 API·상태·실패 복구를 끝까지 따라간다.
세 사용자 행동이 시스템의 경계를 정한다
이 서비스가 먼저 지켜야 할 사용자 약속은 세 가지다.
- 창작자는 수 GB 파일을 올리다가 연결이 끊겨도 완료한 부분부터 이어야 한다. 업로드 뒤에는
업로드 중 → 처리 중 → 게시 가능상태와 실패 이유를 확인해야 한다. - 시청자는 홈 피드에서 관련성 있는 동영상을 빠르게 받고, 다음 페이지에서 같은 항목을 반복해서 보지 않아야 한다. 비공개·삭제 동영상은 목록에 남거나 재생되어서는 안 된다.
- 시청자가 재생을 누르면 기기와 네트워크에 맞는 화질로 빨리 시작해야 한다. 소유자가 공개 범위를 바꾸거나 삭제하면 이전 링크를 가진 사람의 새 접근도 막혀야 한다.
지원 환경은 현대 웹 브라우저와 iOS·Android 앱, 속도가 변하는 모바일·와이파이 네트워크로 가정한다. 원본과 시청 기록은 허가 없이 노출하지 않는다. 추천에는 기록 삭제와 개인화 해제 같은 사용자 제어도 포함한다. 좋아요·댓글·검색·라이브 방송·광고 입찰·저작권 매칭의 내부 구현은 이번 범위에서 뺀다.
응답 목표도 서버 이름이 아닌 사용자 경험을 기준으로 정한다. p95는 요청 100개 가운데 95개가 끝나는 시간이다. 피드와 업로드 세션 생성의 p95는 300ms 이내, 정상 광대역 재생 시작 p95는 2초 이내를 목표로 둔다. 5분 영상의 최소 360p 게시 준비는 업로드 성공 뒤 2분 이내를 목표로 하지만 길이·형식·작업 대기에 따라 달라진다는 사실을 화면에 보여준다. 재생 읽기 경로는 99.99%, 업로드 제어 경로는 99.9% 가용성을 목표로 한다. 모두 실제 YouTube 수치가 아닌 설계 목표다.
규모 가정은 저장보다 전송과 변환의 크기를 먼저 드러낸다
RPS(Requests Per Second)는 1초에 받는 요청 수이며, 여기서는 피드와 재생 시작 경로가 얼마나 커지는지 계산하는 단위다. 계산 입력과 결과를 함께 적어야 가정이 바뀔 때 설계도 조정할 수 있다.
| 입력 | 구분 | 계산 | 결과 | 민감도와 설계 영향 |
|---|---|---|---|---|
| 일간 활성 사용자 1억 명, 1인당 피드 10회 | 설계 가정 | 1억 ÷ 86,400 × 10 | 평균 11,574 RPS, 5배 피크 약 5.8만 RPS | 페이지 크기와 새로고침 정책이 피드 캐시·분할 규모를 바꿈 |
| 일일 업로드 100만 개 | 설계 가정 | 100만 ÷ 86,400 | 평균 11.6개/초, 10배 피크 약 116개/초 | 완료 요청과 변환 이벤트가 같은 비율로 늘어남 |
| 평균 원본 500MB | 설계 가정 | 100만 × 500MB | 원본 약 500TB/일 | 평균 크기가 2배면 유입 대역폭과 원본 저장도 2배 |
| 파생물 600TB/일 | 설계 가정 | 원본의 1.2배 | 원본+파생물 1.1PB/일 | 화질·코덱 수를 줄이면 비용은 줄고 기기 대응력도 낮아짐 |
| 30일 신규 보존 | 설계 가정 | 1.1PB × 30 | 복제 전 약 33PB | 보존 기간과 저빈도 저장 계층이 가장 큰 변수 |
| 일간 재생 50억 회 | 설계 가정 | 50억 ÷ 86,400 | 평균 57,870회/초, 5배 피크 약 28.9만 회/초 | 재생 시작과 권한 확인을 업로드와 따로 확장해야 함 |
| 재생당 평균 40MB | 설계 가정 | 50억 × 40MB | 200PB/일, 평균 약 18.5Tbps | CDN 적중률 95%면 원본 전송 약 10PB/일, 90%면 두 배 |
| 영상 1분당 4 CPU-분, 평균 10분 | 설계 가정 | 100만 × 10 × 4 | 4천만 CPU-분/일, 평균 약 27,778 CPU 코어 | 코덱·화질·가속 장치에 따라 크게 달라짐 |
CDN 적중률은 요청한 바이트가 중앙 원본이 아니라 시청자 가까운 캐시에서 나온 비율이다. 위 95%는 관측값이 아닌 목표 가정이다. 인기 분포에 따라 요청 수 기준과 바이트 기준 적중률이 달라질 수 있으므로 둘 다 측정한다.
첫 행동: 끊긴 업로드는 완료한 조각부터 잇는다
API(Application Programming Interface)는 앱과 서버가 정해진 요청과 응답으로 통신하는 접점이다. 창작자가 파일을 고르면 먼저 큰 파일 자체가 아니라 업로드를 통제할 작은 정보를 보낸다.
POST /v1/videos
Idempotency-Key: create-7f2...
{"title":"...","file_size":524288000,"checksum_sha256":"...","privacy":"private"}
201 Created
{"video_id":"v_123","upload_session_id":"u_456","part_size":16777216,
"part_urls":[...],"expires_at":"...","status":"UPLOADING"}
멱등성은 같은 작업을 여러 번 받아도 결과가 한 번 처리한 것과 같아지는 성질이다. 여기서 Idempotency-Key는 사용자가 생성 버튼을 두 번 눌러도 같은 video_id를 돌려주기 위해 필요하다.
- 업로드 세션 서비스가 파일 크기·전체 체크섬·초기 공개 범위를 확인하고
video_id,upload_session_id, 만료 시각을 만든다. 이 서비스의 역할은 파일을 운반하는 것이 아니라 누가 무엇을 어디에 올릴지 승인하는 것이다. - 서비스는 객체 저장소에만 쓸 수 있는 짧은 사전 서명 URL을 발급한다. 객체 저장소는 큰 파일을 키로 보관하는 저장 공간이며, 사전 서명 URL은 저장소 비밀키 없이 정해진 시간·객체·동작만 허용하는 주소다. 세션별로 예측하기 어려운 객체 키를 쓰고 완료 전 원본을 격리해야 같은 키 덮어쓰기를 막을 수 있다. AWS S3 사전 서명 URL
- 클라이언트는 파일을 조각으로 나눠 객체 저장소에 직접 보낸다. 멀티파트 업로드는 큰 파일을 독립된 조각으로 올리는 방식이며, 이 글에서는 끊겼을 때 성공한 조각을 보존하고 실패한 조각만 다시 보내기 위해 쓴다. AWS S3 멀티파트 업로드
- 완료 API는 소유권, 만료, 조각 목록, 전체 크기와 체크섬을 확인한다. 성공하면 원본을 확정하고
PROCESSING으로 한 번만 바꾼 뒤 변환 이벤트를 보낸다. - 트랜스코딩은 원본 영상을 여러 화질·전송 속도·기기 호환 형식으로 바꾸는 작업이다. 오래 걸리고 실패할 수 있으므로 사용자 요청과 분리된 작업 큐에서 비동기로 처리한다. 큐는 기다리는 작업을 워커에 전달하는 대기열이고, 워커는 실제 변환을 수행하는 실행 주체다.
- 상태 API는
PROCESSING, 단계별 진행률, 또는FAILED와 사용자가 조치할 수 있는 이유를 돌려준다. YouTube 공개 API도 업로드·처리·실패·거절·삭제 상태를 구분하지만, 이는 사용자 상태 모델의 공개 사례일 뿐 내부 구조가 같다는 뜻은 아니다. YouTube video 리소스
아래 그림은 왼쪽의 창작자 행동부터 번호대로 읽는다. 실선은 작은 제어 정보, 굵은 화살표는 큰 동영상 바이트, 점선은 오래 걸리는 비동기 작업을 뜻하도록 구성한다.
이 흐름에서 API 서버는 큰 파일을 중계하지 않는다. 권한·상태·메타데이터처럼 작고 자주 바뀌는 제어 경로와 원본·변환 조각처럼 크고 거의 바뀌지 않는 미디어 경로를 분리해야 두 경로를 독립적으로 확장할 수 있다.
둘째 행동: 피드는 후보를 줄인 뒤 최신 권한을 다시 확인한다
GET /v1/feed?cursor=eyJzY29yZSI6...&limit=20
200 OK
{"items":[{"video_id":"v_9","title":"...","thumbnail_url":"...",
"reason_code":"TOPIC_AFFINITY","published_at":"..."}],"next_cursor":"..."}
- 피드 접점은 로그인 사용자, 언어·지역, 기기, 제한 모드와 이전 페이지 커서를 받는다. 원시 시청 기록 전체 대신 추천에 필요한 특징만 식별을 최소화해 사용한다.
- 후보 생성기는 구독, 최근 시청 주제, 비슷한 이용자의 행동, 지역 인기와 신작 탐색에서 수백~수천 개를 모은다. 수억 개 전체를 요청마다 정밀 계산하지 않기 위한 첫 축소 단계다.
- 최신 권한 필터는
PUBLISHED가 아니거나 지역·연령·접근 정책에 맞지 않는 항목을 제거한다. 여기서 원장은 공개 상태와 소유권의 최종 기준이 되는 메타데이터 기록이며, 오래된 추천 캐시보다 이 기록을 우선해야 삭제 영상을 막을 수 있다. - 순위화기는 남은 후보의 관련성, 신선도, 다양성, 반복 피로와 안전 신호를 계산한다. 2016년 공개 YouTube 추천 논문도 후보 생성과 순위화의 두 단계를 설명하지만, 현재 YouTube의 모델이나 지연 수치를 뜻하지는 않는다. Google Research 후보 생성·순위화 논문
- TTL(Time To Live)은 캐시가 다시 확인되기 전 유지되는 시간이다. 짧은 TTL의 결과 캐시는 응답을 빠르게 하지만 권한 변경과 새 관심사의 반영을 늦추므로, 권한 차단을 TTL 만료에 맡기지 않고 응답 직전 다시 검사한다.
- 커서는 마지막 점수·게시 시각·동영상 ID와 피드 스냅샷 버전을 담는다. 단순 페이지 번호보다 중간 삽입으로 생기는 중복·누락을 줄이고, 응답 직전 이미 본
video_id를 한 번 더 제거한다.
추천 학습과 특징 계산은 요청을 처리하기 전에 수행하고, 온라인 요청에서는 준비된 사용자·동영상 특징을 읽는다. 새 동영상은 반응 이력이 없어 협업 필터링이 불리한 콜드 스타트, 즉 새 항목을 판단할 기록이 없는 문제가 생긴다. 소량의 탐색 노출이나 콘텐츠·상황 정보를 결합해 보완할 수 있다. Google Research 콜드 스타트 논문
fan-out은 한 사건을 여러 대상의 작업으로 펼치는 방식이다. 사용자별 피드를 게시 시점에 미리 써 두는 fan-out-on-write는 읽기가 빠르지만 팔로어가 많은 채널에서 쓰기가 폭발하고 오래된 권한 복사본이 남는다. 요청 때 후보를 합치는 fan-out-on-read는 최신성이 좋지만 온라인 계산비와 지연이 커진다. 이 설계는 구독·인기 후보를 미리 계산하고, 요청 때 개인화 후보와 합친 뒤 최신 권한·중복·다양성을 거르는 혼합형을 선택한다.
셋째 행동: 재생은 CDN으로 보내고 권한 판단은 제어 경로에 남긴다
POST /v1/videos/v_9/playback-session
{"device_caps":["h264","hls"],"network_hint":"cellular"}
200 OK
{"manifest_url":"https://media.example/.../master.m3u8",
"auth_cookie":"short-lived","expires_at":"..."}
- 재생 세션 서비스가 동영상 상태와 사용자 권한을 최신 메타데이터에서 확인한다. 공개 상태이거나 허용된 비공개 공유가 아니면 주소를 발급하지 않는다.
- 매니페스트는 재생할 화질과 작은 동영상 조각의 주소를 적은 안내서다. 서비스는 기기 지원 형식에 맞는 매니페스트 주소를 주고, 비공개 콘텐츠에는 짧게 유효한 서명 쿠키를 더한다. 서명 쿠키는 많은 조각에 같은 제한 접근 조건을 적용해 URL마다 서명하는 부담을 줄인다. Cloud CDN 접근 제어
- HLS(HTTP Live Streaming)는 HTTP로 작은 조각과 재생목록을 전달하며 네트워크에 따라 화질을 바꾸는 방식이다. 플레이어는 CDN에서 마스터 매니페스트와 첫 조각을 받고, CDN에 없을 때만 파생물 저장소에서 가져온다.
- 플레이어는 전송 속도와 남은 버퍼를 보고 다음 조각의 화질을 바꾼다. 자연스러운 전환을 위해 여러 화질의 내용과 타임스탬프를 맞춘다. RFC 8216 §6.2.4
- 재생 시작·진행·완료 이벤트는 비동기로 수집한다. 이벤트 저장 실패가 재생을 막아서는 안 되며,
playback_session_id + sequence_no로 중복을 제거한다. - 소유자가 비공개나 삭제를 요청하면 메타데이터부터
BLOCKED또는DELETING으로 바꾼다. 새 재생 세션을 막은 뒤 피드·검색·추천 제거, CDN 무효화, 객체 삭제를 각각 추적한다.
CDN은 시청자와 가까운 서버에 매니페스트와 조각을 잠시 보관하는 전달망이다. 재생 시작 지연과 중앙 저장소 부하를 줄여준다. 공개된 버전 고정 조각은 긴 TTL과 불변 URL을 쓴다. 마스터 매니페스트는 화질 구성이 바뀔 수 있어 조각보다 짧게 보관한다. 비공개 조각은 짧은 서명 쿠키나 URL과 비공개 원본을 사용한다. 개인화 피드와 사용자 메타데이터는 다른 사용자에게 섞일 수 있으므로 공유 CDN 캐시에 넣지 않는다.
데이터 모델은 서로 다른 완료 조건을 보존한다
| 엔터티 | 핵심 필드와 키 | 인덱스·일관성 | 보존 정책 |
|---|---|---|---|
videos |
PK video_id; owner_id, privacy, lifecycle_state, state_version, source_key, manifest_version, published_at |
(owner_id, created_at) 목록 인덱스; 권한·상태는 조건부 쓰기와 강한 읽기 |
삭제 뒤 법적 보존 사유가 없으면 개인정보와 객체 포인터 제거 |
upload_sessions |
PK upload_session_id; video_id, object_key, expected_size, checksum, expires_at, completed_at |
(owner_id, client_idempotency_key) 유일 |
미완료 세션은 24시간 뒤 중단·조각 정리한다는 가정 |
transcode_jobs |
PK (video_id, profile_version, rendition); 상태, 시도 횟수, 출력 키, 체크섬, 임대 만료 |
같은 작업 키는 하나; 성공 상태는 조건부 갱신 | 감사 기간 뒤 상세 로그 축약 |
renditions |
PK (video_id, manifest_version, rendition); 코덱, 해상도, 비트레이트, 조각 접두사 |
게시 전 필수 출력 체크섬 검증 | 삭제 또는 버전 유예 종료 뒤 제거 |
feed_events |
PK (user_id, event_time, event_id); 시청·건너뜀·좋아요 |
이벤트 ID 중복 제거, 시간별 분할 | 원시 이벤트 기한 제한, 집계 익명화 |
deletion_tasks |
PK (video_id, target, generation); 상태, 재시도, 마지막 오류 |
삭제 대상별 완료 기록 | 모든 대상 확인 뒤 최소 감사 증거만 보존 |
PK(Primary Key)는 각 행을 유일하게 찾는 기본 키다. 객체 키에는 사용자 제목을 넣지 않고 raw/{video_id}/{upload_generation}과 media/{video_id}/{manifest_version}/...처럼 만든다. 버전이 든 출력 URL을 바꾸지 않으면 정상 콘텐츠 갱신 때 넓은 캐시 삭제가 필요 없다. 다만 권한 철회는 이전 버전 접근도 막아야 하므로 별도의 차단과 무효화가 필요하다.
변환 작업의 정상 상태는 QUEUED → CLAIMED → RUNNING → VERIFYING → SUCCEEDED다. 워커가 죽거나 작업 임대가 끝나면 RETRYABLE로 보내고, 손상 원본이나 지원하지 않는 형식처럼 재시도로 낫지 않는 오류는 PERMANENT_FAILED로 보낸다. 큐가 같은 메시지를 다시 줄 수 있으므로 video_id + profile_version + rendition을 고유 작업 키로 삼는다. 같은 출력을 다시 받아도 한 번만 공개하는 멱등 소비자가 필요하다. Amazon SQS 중복 전달
매니페스트도 검증 중인 경로에 덮어쓰지 않는다. 새 manifest_version 아래에 모든 조각을 쓰고 체크섬·길이·타임스탬프 정렬을 확인한 뒤 현재 버전 포인터를 한 번에 바꾼다. HLS나 MPEG-DASH 매니페스트가 적응형 스트림의 콘텐츠와 메타데이터를 설명한다는 공식 문서가 이 경계를 뒷받침한다. Google Cloud Transcoder 개요
병목은 사용자 지표와 작업 나이로 찾는다
- 업로드 API는 동영상 바이트가 아니라 세션 생성·완료 폭주와 객체 저장소 요청 한도에서 막힌다. API 서버가 파일을 대신 운반하면 연결 수와 네트워크 비용이 먼저 커진다.
- 변환은 큐 길이만 보면 안 된다. 영상마다 길이가 다르므로 가장 오래 기다린 작업 시간, 남은 영상 분량, 화질별 처리 시간, 재시도율과 CPU·GPU 사용률을 함께 본다. 백필은 최소 화질 게시 뒤 고화질을 나중에 채우는 작업이며, 게시를 기다리는 작업과 별도 우선순위로 격리한다.
- 핫키는 인기 동영상 하나처럼 같은 키에 요청이 몰리는 현상이다. 메타데이터 읽기 캐시, 같은 CDN 요청 합치기, 중앙 저장소 보호 한도와 선택적 캐시 예열로 완화한다. 모든 새 영상을 예열하면 비용만 늘 수 있다.
- 유명 채널의 게시 이벤트는 미리 쓰는 피드를 폭발시킨다. 혼합형 피드와 대상별 우선순위 제한으로 격리한다.
- 삭제는 한 영상의 수천 개 조각과 여러 캐시를 건드릴 수 있다. 한 번의 거대한 저장 작업으로 묶지 않고
deletion_tasks에서 대상별 완료와 재시도 예산을 기록한다.
운영 화면에서는 업로드 재시작 바이트, 처리 완료 시간, 재생 시작 시간, 재버퍼링 비율, 첫 조각 CDN 적중률, 삭제 뒤 권한 거부 확인 시간, 피드의 차단 콘텐츠 노출률을 확인할 수 있어야 한다. 서버 자원 지표만으로는 사용자가 실제로 겪는 손실을 설명하기 어렵다.
사용자가 본 실패부터 감지·완화·복구한다
| 사용자에게 보이는 현상 | 감지 | 즉시 완화 | 복구와 정합성 확인 |
|---|---|---|---|
| 업로드가 80%에서 멈춤 | 조각 진행 시간, 세션 만료, 체크섬 오류 | 완료 조각 목록을 돌려주고 실패 조각만 재전송 | 전체 크기·체크섬 확인 뒤 한 번만 완료하고 고아 조각 정리 |
| 완료를 두 번 눌러 영상 두 개 생성 | 사용자와 Idempotency-Key 충돌 |
기존 video_id 반환 |
생성 요청과 원본 연결을 감사하고 중복 객체 정리 |
오랫동안 처리 중 |
작업 대기 시간, 임대 만료, 화질별 실패율 | 최소 화질 우선, 예상 대기와 오류 이유 표시 | 고유 작업 키로 재시도하고 영구 실패·성공 체크섬 확인 |
| 재생이 늦거나 끊김 | 시작 시간, CDN 미적중, 버퍼, 조각 오류율 | 낮은 화질이나 다른 전달 지점으로 전환 | 손상 조각 재변환, 매니페스트 교체, 지역별 점검 |
| 피드 반복 또는 삭제 영상 노출 | 커서 버전, 중복률, 최종 권한 필터 거부율 | 응답 직전 중복 제거와 PUBLISHED 재검사 |
오래된 후보·캐시 제거 뒤 표본 감사 |
| 비공개 뒤 이전 링크 재생 | 변경 시각 뒤 토큰 발급과 CDN 요청 | 메타데이터 차단, 새 토큰 중단, 세션 철회와 CDN 무효화 | 모든 지역의 접근 거부, 피드·검색·추천 제거, 객체 정리 확인 |
| 이벤트 중복으로 조회수 증가 | 같은 세션·순번 중복률 | 집계 전 중복 제거 | 원시 이벤트 재처리로 집계 교정; 재생은 계속 허용 |
삭제와 비공개 전환에는 여러 분기가 있어 상태 그림이 유용하다. 아래 이미지는 왼쪽의 사용자 요청에서 시작해 위쪽의 즉시 접근 차단을 먼저 읽고, 아래쪽의 비동기 정리 작업을 대상별로 따라간다.
이 순서에서 CDN 무효화가 늦어져도 새 권한 발급은 먼저 멈춘다. 삭제 API 성공은 물리 삭제 완료가 아니라 요청을 받아 차단 상태에 넣었다는 뜻으로 정의하고, 내부 대상의 완료는 별도로 추적한다. CloudFront 공식 문서가 설명하는 HLS 경로 무효화도 전파가 즉시 끝난다는 보장으로 확대하지 않는다. CloudFront 경로 무효화
보안·개인정보·비용은 같은 분리 원칙을 따른다
소유권, 공개 범위, 삭제 상태와 업로드 완료의 한 번뿐인 전이는 최신 값을 강하게 확인한다. 추천 점수, 조회수와 최근 시청 특징은 수초에서 수분 늦을 수 있다. 최종 일관성은 여러 복사본이 당장은 다르지만 변경이 멈추면 결국 같아지는 방식이며, 이 글에서는 추천 신선도를 조금 양보해 자주 쓰는 경로를 가볍게 만드는 데 사용한다.
모든 video_id API는 식별자만 믿지 않고 객체 수준 권한을 검사한다. 업로드 URL은 짧은 만료, 특정 객체 키·동작·크기·콘텐츠 유형·체크섬으로 제한한다. 원본은 검사 전 공개하지 않고, 비공개 미디어의 중앙 저장소는 인터넷에서 직접 열지 않는다. 저장·전송 암호화, 키 회전, 최소 권한 서비스 계정과 감사 로그를 적용하며 서명 URL은 로그와 분석 이벤트에 남기지 않는다.
파일명, 제목과 시청 기록은 개인정보가 될 수 있다. 추천 특징은 목적에 필요한 기간만 보존하고 기록 삭제·개인화 해제를 파생 저장소까지 전파한다. 업로드 크기·시간·동시 세션·변환 프로필에는 사용자별 할당량을 둬 저장소와 계산 자원의 고갈을 막는다.
비용이 크게 드는 지점은 원본·파생물 저장, 변환 계산, CDN 외부 전송이다. 모든 화질과 코덱을 즉시 만들면 기기 대응은 좋아지지만 거의 보지 않는 영상에도 비용이 든다. 낮은 화질과 주 기기용 형식을 먼저 만들고 실제 재생 수요에 따라 고화질·추가 코덱을 늦게 생성할 수 있다. 대신 첫 고화질 요청의 대기와 작업 운영 복잡성이 늘어난다.
선택안은 속도와 철회 보장을 서로 다른 곳에서 산다
| 결정 | 선택안 | 장점 | 단점과 바꿀 조건 |
|---|---|---|---|
| 업로드 | 사전 서명 URL로 객체 저장소에 직접 조각 업로드 | API 대역폭 절약, 중단 뒤 재개 | 완료 검증과 클라이언트가 복잡함. 작은 파일뿐이면 서버 중계가 단순할 수 있음 |
| 변환 | 큐 기반 비동기, 최소 화질 우선 | 긴 작업을 사용자 요청과 격리 | 처리 중 상태와 중복 관리가 필요함. 아주 짧은 내부 영상은 동기 처리 가능 |
| 작업 전달 | 중복 전달 허용 큐와 멱등 소비자 | 일시 장애에도 재전달 가능 | 중복 출력을 직접 막아야 하며 외부 효과까지 한 번뿐이라고 과장할 수 없음 |
| 미디어 형식 | HLS 중심, 필요 시 MPEG-DASH 병행 | 네트워크에 맞춘 화질과 기기 대응 | 형식·코덱 조합이 늘수록 계산·저장 증가 |
| 피드 | 미리 계산한 후보와 요청 시 후보를 합치는 혼합형 | 빠른 읽기와 최신 필터 절충 | 두 경로를 운영해야 함. 규모가 작으면 요청 시 계산부터 시작 가능 |
| CDN | 버전 URL과 긴 조각 TTL, 철회 때 무효화 | 정상 갱신의 캐시 효율과 긴급 차단을 분리 | 무효화 비용·전파 지연. 민감 콘텐츠는 매 요청 에지 권한 확인 필요 |
| 비공개 접근 | 짧은 서명 쿠키·URL과 비공개 원본 | CDN을 유지하면서 접근 제한 | 만료 전 링크 공유 위험. 유료 콘텐츠의 권리 관리는 별도 설계 필요 |
| 삭제 | 논리 차단 우선, 물리 삭제 비동기 | 노출을 먼저 막고 실패를 재시도 | 사용자에게 접수·차단·물리 삭제 완료를 구분해 알려야 함 |
확장은 실제로 깨진 경계부터 시작한다
- 초기에는 단일 지역, 객체 저장소 직접 업로드, 관리형 큐, 2~3개 화질, 단일 CDN과 인기·구독 피드로 시작한다. 상태 기계와 멱등 작업 키는 이때부터 둔다.
- 성장하면 변환 프로필별 워커, 최소 화질 우선순위, 버전 매니페스트, 메타데이터 분할, CDN 지표와 혼합형 추천을 추가한다.
- 대규모에서는 업로드 지역과 처리 지역을 분리하고 원본 복제 정책을 정한다. 후보와 특징 데이터를 지역화하며 지역 장애 우회 또는 다중 CDN을 검토하고, 삭제 원장을 모든 지역으로 넓힌다.
- 비용을 줄일 때는 인기 기반 지연 변환, 추가 코덱의 손익, 저빈도 저장 계층과 바이트 기준 CDN 적중률을 실제 지표로 다시 계산한다.
- 엄격한 권한·규제가 필요하면 지역 제한, 미성년자·개인정보 정책, 권리 관리, 법적 보존과 삭제 증명을 별도 영역으로 분리한다. 이 조건에서는 캐시 효율보다 철회 보장이 우선이다.
변환 작업 대기 시간이 목표를 계속 넘으면 화질 프로필 축소, 우선순위와 하드웨어 가속을 검토한다. 중앙 저장소 전송량이 예상보다 크면 CDN 키, TTL, 조각 크기와 인기 분포를 본다. 비공개 철회 목표를 못 지키면 서명 만료를 줄이고 에지 권한 확인을 강화한다. 피드 p95가 늘면 후보 수와 온라인 특징 조회를 줄이되 마지막 권한 필터는 제거하지 않는다.
선택한 설계는 업로드·피드·재생·삭제를 하나의 성공 상태로 묶지 않는다. 제어 경로는 권한과 최신 상태를 지키고, 미디어 경로는 큰 바이트를 저장·변환·전달한다. 남은 한계는 실제 YouTube의 트래픽·추천 모델·CDN 계약·삭제 시간이 공개 자료로 검증되지 않았고, 클라우드별 큐와 저장소 보장도 서로 다르다는 점이다. 실제 적용의 출발점은 복잡한 컴포넌트를 더하는 일이 아니라 예상 업로드량·재생량과 허용할 권한 철회 시간을 적고, 그 목표를 처음 깨는 사용자 지표를 찾는 일이다.
