Media2026-08-0318분 읽기

YouTube·Twitch 라이브 스트리밍 아키텍처 — OBS에서 시청자 화면까지 glass-to-glass 지연 분해

라이브 방송은 카메라 앞 장면이 어떻게 수십 초 이하 지연으로 전 세계 시청자 화면에 도착할까요? OBS 인코더, RTMP/RTMPS ingest, 가까운 PoP, 플랫폼 백본, 트랜스코딩, ABR ladder, HLS/DASH 패키징, CDN, 플레이어 버퍼까지 glass-to-glass 경로를 시각적으로 분해합니다. YouTube의 latency knob과 Twitch의 low latency 모드가 실제로 무엇을 줄이고 무엇을 희생하는지도 함께 정리합니다.

Live StreamingYouTube LiveTwitchRTMPRTMPSSRTHLSDASHABRCDNLatency

목차(23개 항목)

0. 핵심 명제 — 라이브 방송은 "거대한 실시간 파일 공장"이다
1. 방송자 쪽 — 먼저 인코더가 영상을 압축한다
1. 방송자 쪽 — 먼저 인코더가 영상을 압축한다
1. 왜 아직도 RTMP인가
2. Ingest PoP — 방송자는 가장 가까운 입구로 들어간다
2. Ingest PoP — 방송자는 가장 가까운 입구로 들어간다
1. DNS 기반 라우팅 vs Anycast
2. WebRTC/SFU도 PoP에 붙나
3. 플랫폼 내부 — 한 줄기 입력을 여러 화질로 다시 만든다
3. 플랫폼 내부 — 한 줄기 입력을 여러 화질로 다시 만든다
1. 트랜스코딩 내부를 더 풀면
4. Packaging — 시청자가 이해할 수 있는 HLS/DASH로 바꾼다
4. Packaging — 시청자가 이해할 수 있는 HLS/DASH로 바꾼다
1. HLS는 목록과 조각의 조합이다
5. CDN — 대형 플랫폼은 원본 서버가 아니라 엣지에서 먹여 살린다
5. CDN — 대형 플랫폼은 원본 서버가 아니라 엣지에서 먹여 살린다
1. 왜 이게 WebRTC보다 대규모 방송에 경제적인가
2. WebRTC PoP와 CDN PoP는 무엇이 다른가
6. 플레이어 — 가장 최신을 보지 않고, 조금 늦게 안정적으로 본다
7. Glass-to-glass 지연은 어디서 쌓이나
8. 왜 WebRTC처럼 0.5초로 안 하나
9. 방송자가 실제로 줄일 수 있는 지연
9. 방송자가 실제로 줄일 수 있는 지연
10. 전체 아키텍처를 한 장으로 정리
11. 실무 판단 기준
참고 자료

"유튜브 라이브나 트위치는 왜 실시간처럼 보이는데도 채팅 반응은 몇 초에서 수십 초 늦을까요? 방송자가 말한 내용이 시청자 화면에 도착하기까지, 서버에서는 정확히 무슨 일이 일어날까요?"

답부터 말하면, YouTube와 Twitch 같은 대형 라이브 플랫폼은 실시간 통화처럼 한 프레임씩 직접 전달하지 않습니다. 방송자의 인코더가 보낸 한 줄기 영상을 플랫폼이 받아서, 여러 화질로 다시 만들고, 몇 초 단위의 조각으로 쪼개고, CDN에 뿌린 뒤, 시청자 플레이어가 HTTP로 계속 가져갑니다.

이 전체 지연을 보통 glass-to-glass latency라고 부릅니다. 카메라 렌즈 앞의 장면이 방송자 쪽 "유리"를 지나, 시청자 디스플레이 "유리"에 도착할 때까지의 시간입니다.

0. 핵심 명제 — 라이브 방송은 "거대한 실시간 파일 공장"이다

YouTube·Twitch식 라이브 스트리밍의 본질은 실시간 파일 생산·배포 시스템이다. 인코더는 RTMP/RTMPS로 플랫폼에 영상을 밀어 넣고, 플랫폼은 그 영상을 여러 화질의 짧은 HLS/DASH 세그먼트로 계속 생산한다. 시청자는 CDN에서 최신 세그먼트를 조금 늦게 따라가며 재생한다. 지연은 이 공장이 안정적으로 돌아가게 하기 위한 버퍼 비용이다.

한 줄 그림으로 보면 이렇습니다.

카메라/게임 화면
   │
   ▼
[OBS/인코더]
   │  RTMP/RTMPS 업로드
   ▼
[가까운 Ingest PoP]
   │  플랫폼 백본
   ▼
[라이브 처리 파이프라인]
   │  트랜스코딩 + 세그먼트화 + 패키징
   ▼
[CDN Edge]
   │  HTTP GET
   ▼
[시청자 플레이어]
   │
   ▼
디스플레이

이 구조의 장점은 명확합니다.

얻는 것	비용
전 세계 수십만~수백만 명에게 확장 가능	초 단위 지연이 생김
CDN 캐싱 가능	완전한 1초 미만 상호작용은 어려움
네트워크가 흔들려도 플레이어 버퍼로 버팀	버퍼가 곧 지연이 됨
시청자마다 자동 화질 선택 가능	트랜스코딩 비용이 큼

그래서 라이브 스트리밍에서 지연은 단순한 서버 성능 문제가 아니라 아키텍처가 선택한 tradeoff입니다.

1. 방송자 쪽 — 먼저 인코더가 영상을 압축한다

방송자는 보통 OBS, Streamlabs, 콘솔, 모바일 앱, 브라우저 기반 송출 도구를 씁니다. 이 도구의 핵심 역할은 하나입니다.

카메라·마이크·게임 화면을 받아서, 인터넷으로 보낼 수 있을 만큼 압축하고, 플랫폼이 받을 수 있는 프로토콜로 밀어 넣는다.

카메라 + 마이크 + 게임 캡처
        │
        ▼
┌─────────────────────┐
│ OBS / Encoder        │
│                     │
│ 1. 캡처              │
│ 2. 합성              │
│ 3. H.264/AAC 인코딩  │
│ 4. RTMP/RTMPS 전송   │
└─────────────────────┘
        │
        ▼
rtmps://ingest.platform.example/live/{stream_key}

여기서 중요한 점은 플랫폼이 raw video를 받는 게 아니라는 것입니다. OBS는 이미 영상을 압축해서 보냅니다.

항목	일반적인 값
비디오 코덱	H.264, 일부 플랫폼/설정은 HEVC·AV1
오디오 코덱	AAC
송출 프로토콜	RTMP 또는 RTMPS
전송 방향	방송자 → 플랫폼 단방향 push

YouTube 공식 문서는 live encoder 설정에서 RTMP/RTMPS streaming을 안내하고, YouTube가 입력 스트림을 자동으로 여러 출력 포맷으로 트랜스코딩한다고 설명합니다. Twitch 개발자 문서도 방송 도구가 RTMP로 Twitch ingest subsystem에 스트림을 보낸다고 설명합니다.

왜 아직도 RTMP인가

RTMP는 오래된 프로토콜입니다. Adobe Flash 시대의 유산입니다. 그런데 송출 구간에서는 아직 강합니다.

이유는 기술적으로 가장 최신이라서가 아니라, 생태계 호환성 때문입니다.

OBS
XSplit
Streamlabs
하드웨어 인코더
콘솔 송출
        │
        └── 대부분 RTMP/RTMPS를 안정적으로 지원

RTMP의 약점도 분명합니다. TCP 기반이라 패킷 손실이 생기면 재전송 때문에 지연이 늘 수 있고, 불안정한 네트워크에서는 UDP 기반 프로토콜보다 불리할 수 있습니다. 그래서 SRT(Secure Reliable Transport) 같은 대안이 있습니다. SRT는 UDP 기반으로 손실 복구와 암호화를 제공하며, 방송 contribution 구간에서 점점 쓰이고 있습니다.

다만 YouTube·Twitch 같은 대중 플랫폼의 표준 송출 경로는 여전히 RTMP/RTMPS 중심입니다. 특정 플랫폼의 SRT 지원 여부는 계속 바뀔 수 있으므로 운영 도입 전에는 반드시 해당 플랫폼의 최신 ingest 문서를 확인해야 합니다. [NEEDS VERIFICATION]

2. Ingest PoP — 방송자는 가장 가까운 입구로 들어간다

대형 플랫폼은 전 세계 여러 지역에 ingest server를 둡니다. Twitch 문서 표현을 빌리면, ingest server는 PoP(Point of Presence)에 위치한 방송 수신 서버입니다.

방송자는 보통 가장 가까운 ingest endpoint로 연결됩니다.

서울 방송자
   │
   ├─ 나쁜 경우: 서울 → 미국 서부 ingest → 플랫폼 내부 처리
   │
   └─ 좋은 경우: 서울 → 가까운 아시아 ingest PoP → 플랫폼 내부 처리

라우팅은 플랫폼마다 다르지만, 일반적으로 다음 방식이 조합됩니다.

방식	설명
DNS 기반 라우팅	방송자 위치·지연을 보고 가까운 ingest 주소 반환
Anycast	같은 IP를 여러 지역에서 광고하고 네트워크가 가까운 곳으로 보냄
수동 ingest 선택	Twitch처럼 특정 ingest server를 선택하거나 테스트 가능

DNS 기반 라우팅 vs Anycast

둘 다 "가까운 입구로 보내기" 위한 기술입니다. 차이는 결정권이 DNS에 있느냐, 인터넷 라우팅 자체에 있느냐입니다.

DNS 기반 라우팅

1. OBS가 ingest.example.com의 IP를 물어봄
2. DNS/GSLB가 방송자 위치·ISP·헬스체크를 보고 IP를 골라 줌
3. OBS는 받은 IP로 RTMP/RTMPS 연결

서울 방송자 → DNS 응답: 203.0.113.10(서울/도쿄 ingest)
LA 방송자   → DNS 응답: 198.51.100.20(LA ingest)

DNS 기반 라우팅은 운영자가 제어하기 쉽습니다. 특정 리전을 점검 중이면 DNS 응답에서 빼고, 특정 ISP가 문제면 다른 리전으로 우회시킬 수 있습니다. 대신 DNS 캐시와 TTL 때문에 즉시 바뀌지 않을 수 있고, DNS resolver 위치가 실제 방송자 위치와 다르면 엉뚱한 리전이 선택될 수 있습니다.

Anycast

1. 서울, 도쿄, LA PoP가 모두 같은 IP를 인터넷에 광고
2. OBS는 항상 같은 IP로 접속
3. BGP 라우팅이 네트워크상 가장 가까운 PoP로 패킷을 보냄

서울 방송자 → 192.0.2.10 → 서울/도쿄 PoP로 수렴
LA 방송자   → 192.0.2.10 → LA PoP로 수렴

Anycast는 클라이언트 입장에서 단순합니다. 같은 IP 하나만 쓰는데도 인터넷 라우팅이 가까운 곳으로 보냅니다. DNS 캐시 문제도 작습니다. 대신 "가까움"은 지리적 거리가 아니라 BGP 경로 기준입니다. 특정 ISP의 라우팅 정책 때문에 실제로는 기대와 다른 PoP로 갈 수도 있고, 긴 RTMP 연결이 경로 변화에 민감할 수 있어 플랫폼은 TCP 장기 연결, 장애 감지, 리전 failover를 조심스럽게 설계해야 합니다.

정리하면 이렇습니다.

항목	DNS 기반 라우팅	Anycast
결정 시점	접속 전 DNS 응답 시점	패킷이 인터넷을 지나가는 라우팅 시점
클라이언트가 보는 IP	지역별로 다를 수 있음	전 세계에서 같은 IP일 수 있음
운영 제어	리전별 가중치·우회 제어가 쉬움	BGP/네트워크 제어 중심
약점	DNS 캐시, resolver 위치 오차	BGP 경로가 항상 체감 지연 최적은 아님
라이브 ingest에서의 의미	방송자를 적절한 수신 리전으로 배정	하나의 주소로 가까운 PoP에 자동 수렴

이 단계의 목표는 간단합니다.

방송자의 불안정한 공용 인터넷 구간을 최대한 짧게 만들고, 이후에는 플랫폼의 빠르고 안정적인 내부망으로 태운다.

방송자 집/스튜디오
   │  공용 인터넷, 가장 불안정한 구간
   ▼
가까운 Ingest PoP
   │  플랫폼 제어 구간
   ▼
라이브 처리 리전

glass-to-glass 지연을 줄이려면 이 첫 구간이 중요합니다. 방송자의 업로드 회선이 흔들리면 뒤쪽 파이프라인이 아무리 좋아도 지연·버퍼링·화질 저하가 발생합니다.

WebRTC/SFU도 PoP에 붙나

붙습니다. WebRTC도 가까운 media edge 또는 SFU PoP에 붙이는 것이 중요합니다. 다만 RTMP ingest나 CDN과 다른 점은, WebRTC에서는 접속 전에 ICE 후보 수집과 연결성 체크가 들어간다는 것입니다.

WebRTC 접속 흐름

브라우저/앱
   │
   ├─ STUN으로 내 공인 후보 확인
   ├─ TURN 후보 준비
   ├─ SFU/media edge 후보 받기
   └─ ICE connectivity check로 실제로 되는 경로 선택
        │
        ▼
가까운 SFU PoP와 DTLS/SRTP 미디어 세션 생성

즉 HLS/DASH 시청자는 "가까운 CDN에서 파일 다운로드"를 하고, WebRTC 사용자는 "가까운 SFU와 실시간 미디어 세션"을 맺습니다. 둘 다 가까운 PoP가 중요하지만, 한쪽은 파일 배달이고 한쪽은 지속적인 실시간 패킷 교환입니다.

3. 플랫폼 내부 — 한 줄기 입력을 여러 화질로 다시 만든다

플랫폼이 RTMP 스트림을 받으면 바로 시청자에게 뿌리지 않습니다. 먼저 여러 화질과 비트레이트로 다시 만듭니다. 이것이 transcoding입니다.

입력: 1080p60, 8 Mbps
        │
        ▼
┌───────────────────────────┐
│ Transcoding Pipeline       │
│                           │
│ 1080p60 6 Mbps             │
│  720p60 3 Mbps             │
│  480p30 1.2 Mbps           │
│  360p30 700 Kbps           │
└───────────────────────────┘
        │
        ▼
출력: ABR ladder

왜 굳이 여러 화질을 만들까요? 시청자 네트워크가 모두 다르기 때문입니다.

기가 인터넷 시청자 ─────▶ 1080p
지하철 LTE 시청자 ──────▶ 720p 또는 480p
혼잡한 Wi-Fi 시청자 ───▶ 360p

이 구조를 ABR(Adaptive Bitrate) streaming이라고 합니다. 플레이어는 다운로드 속도, 버퍼 상태, 기기 성능을 보고 적절한 화질을 선택합니다. 네트워크가 좋아지면 올리고, 나빠지면 내립니다.

트랜스코딩 내부를 더 풀면

트랜스코딩은 "압축 파일 이름만 바꾸는" 작업이 아닙니다. 보통 다음 흐름입니다.

RTMP/FLV 안의 H.264
   │
   ▼
디먹스: 컨테이너에서 비디오/오디오 추출
   │
   ▼
디코드: H.264 → raw frame
   │
   ▼
스케일: 1080p → 720p/480p/360p
   │
   ▼
인코드: 각 해상도·비트레이트로 다시 H.264/HEVC/AV1 생성

이 단계가 무겁습니다. 압축된 영상을 다시 풀고, 해상도를 바꾸고, 여러 버전으로 재압축하기 때문입니다.

작업	비용
디코딩	압축 해제, 참조 프레임 처리
스케일링	픽셀 리샘플링
인코딩	가장 무거움. CPU/GPU/ASIC 사용
키프레임 정렬	화질 전환이 깨지지 않게 모든 렌디션의 GOP 경계 맞춤

대형 플랫폼은 이 작업을 병렬로 처리합니다. 다만 "하나의 인코더 인스턴스가 모든 화질을 동시에 만든다"는 식의 단정은 피해야 합니다. 실제 구현은 플랫폼마다 다르고, 대개 내부 블랙박스입니다.

정확한 표현은 이렇습니다.

단일 입력 스트림에서 여러 출력 렌디션을 병렬 생성하도록 라이브 트랜스코딩 파이프라인을 구성한다.

4. Packaging — 시청자가 이해할 수 있는 HLS/DASH로 바꾼다

트랜스코딩 결과는 아직 "연속된 비디오 스트림"입니다. 시청자 브라우저와 모바일 앱이 안정적으로 재생하려면 이것을 작은 조각과 목록 파일로 바꿔야 합니다.

이 단계가 segmentation + packaging입니다.

각 화질의 연속 스트림
   │
   ▼
2초~6초 단위로 자르기
   │
   ▼
segment_001.ts / segment_002.ts / segment_003.ts
또는
segment_001.m4s / segment_002.m4s / segment_003.m4s
   │
   ▼
manifest 생성/갱신
master.m3u8, index.m3u8
또는
manifest.mpd

HLS는 목록과 조각의 조합이다

HLS를 단순화하면 다음 구조입니다.

master.m3u8
 ├─ 1080p/index.m3u8
 │    ├─ seg_101.ts
 │    ├─ seg_102.ts
 │    └─ seg_103.ts
 ├─ 720p/index.m3u8
 │    ├─ seg_101.ts
 │    ├─ seg_102.ts
 │    └─ seg_103.ts
 └─ 480p/index.m3u8
      ├─ seg_101.ts
      ├─ seg_102.ts
      └─ seg_103.ts

master.m3u8은 "어떤 화질들이 있는지" 알려줍니다. 각 index.m3u8은 "현재 재생 가능한 최신 조각들이 무엇인지" 알려줍니다.

라이브에서는 이 목록이 계속 바뀝니다.

t=0초
index.m3u8: seg_100, seg_101, seg_102

t=2초
index.m3u8: seg_101, seg_102, seg_103

t=4초
index.m3u8: seg_102, seg_103, seg_104

플레이어는 이 목록을 반복해서 받아 최신 세그먼트를 따라갑니다. 다만 완전히 최신 조각을 바로 재생하지는 않습니다. 네트워크 흔들림을 버티기 위해 몇 조각 뒤에서 따라갑니다.

5. CDN — 대형 플랫폼은 원본 서버가 아니라 엣지에서 먹여 살린다

YouTube나 Twitch에서 인기 방송을 수십만 명이 동시에 봐도 가능한 이유는 CDN 때문입니다.

Origin / Packaging 서버
        │
        ▼
CDN Regional Cache
        │
        ├── CDN Edge 서울 ─────▶ 한국 시청자
        ├── CDN Edge 도쿄 ─────▶ 일본 시청자
        ├── CDN Edge LA ───────▶ 미국 서부 시청자
        └── CDN Edge 프랑크푸르트 ─▶ 유럽 시청자

HLS/DASH가 강한 이유는 이것입니다.

비디오 조각이 결국 HTTP 파일이기 때문에 CDN이 잘 캐시하고 잘 배달할 수 있다.

이 문장은 조금 더 풀어야 합니다. "HTTP 파일"이라는 말의 핵심은 요청이 상태 없는 URL 조회로 바뀐다는 뜻입니다. 시청자는 서버와 실시간 미디어 세션을 맺는 것이 아니라, 그냥 다음 파일을 요청합니다.

GET /live/channel-a/720p/seg_103.ts
GET /live/channel-a/720p/seg_104.ts
GET /live/channel-a/720p/seg_105.ts

CDN 입장에서는 이것이 가장 다루기 쉬운 형태입니다.

CDN이 잘하는 일	HLS/DASH에서 왜 잘 맞나
URL 단위 캐싱	`seg_103.ts`라는 같은 URL을 여러 시청자가 요청
정적 파일 배달	세그먼트는 생성된 뒤에는 내용이 바뀌지 않는 작은 파일
엣지 복제	한 지역에서 인기 있는 조각을 가까운 엣지에 저장 가능
HTTP 최적화	keep-alive, HTTP/2, TLS 종료, range 요청, 캐시 정책을 그대로 활용
장애 격리	한 엣지가 조각을 갖고 있으면 origin까지 매번 가지 않아도 됨

실시간 통화처럼 모든 시청자에게 서버가 개별 미디어 세션을 유지하면 대규모 확장이 어렵습니다. 반면 HLS/DASH는 시청자가 같은 seg_103.ts를 많이 요청합니다. CDN은 한 번 받아 둔 조각을 여러 시청자에게 재사용할 수 있습니다.

10만 명이 같은 2초 조각을 요청
   │
   ├─ 원본/패키징 서버가 10만 명에게 직접 전송 ❌
   └─ CDN Edge가 캐시한 파일을 반복 제공 ✅

여기서 "원본 서버가 10만 번 생성"이라고 말하면 부정확합니다. 세그먼트는 원본에서 한 번 생성됩니다. 문제는 생성 횟수가 아니라 전송과 연결 부담입니다. CDN이 없다면 origin 또는 packaging 서버가 같은 파일을 10만 명에게 직접 내려줘야 합니다. CDN이 있으면 origin은 조각을 한 번 게시하고, 실제 반복 전송은 엣지가 맡습니다.

조금 더 실제 요청 흐름으로 보면 이렇습니다.

첫 번째 한국 시청자
   │
   │ GET /720p/seg_103.ts
   ▼
서울 CDN Edge ── cache miss ──▶ Origin/Regional Cache
   │                              │
   │ ◀──────── seg_103.ts ────────┘
   │
   └─ 서울 Edge에 저장

두 번째~10만 번째 한국 시청자
   │
   │ GET /720p/seg_103.ts
   ▼
서울 CDN Edge ── cache hit ──▶ 바로 응답

즉 origin은 "모든 시청자에게 영상 전송"을 하지 않습니다. origin은 최신 조각을 만들고 게시합니다. 실제 시청자 트래픽 대부분은 가까운 CDN edge가 흡수합니다.

왜 이게 WebRTC보다 대규모 방송에 경제적인가

WebRTC도 live streaming에 많이 씁니다. 특히 1초 미만 상호작용이 필요한 라이브 경매, 원격 진료, 실시간 Q&A, 소규모 팬미팅, 양방향 방송에서는 WebRTC가 훨씬 맞습니다. 하지만 대규모 단방향 시청에서는 비용 구조가 다릅니다.

가장 적절한 비유는 신문 배달 vs 전화 연결입니다.

HLS/DASH + CDN = 신문 배달

신문사는 오늘자 신문을 한 번 인쇄한다.
지역 물류창고와 편의점에 신문을 쌓아 둔다.
사람들은 가까운 편의점에서 같은 신문을 가져간다.

WebRTC + SFU = 전화 연결

방송자가 말하는 순간,
전화 교환국은 듣고 있는 사람 10만 명 각각에게
실시간으로 같은 말을 계속 연결해 줘야 한다.

신문 배달은 몇 분 늦어도 괜찮지만, 한 번 찍은 신문을 복사·배포하기 쉽습니다. 전화 연결은 즉각적이지만, 듣는 사람이 늘어날수록 교환국이 유지해야 하는 연결과 전송량이 같이 늘어납니다. 라이브 방송에서 HLS/DASH+CDN은 "영상 신문"에 가깝고, WebRTC+SFU는 "대규모 전화 회의"에 가깝습니다.

HLS/DASH + CDN
방송자 1명 → 세그먼트 파일 생성 → CDN 캐시 → 시청자 N명

WebRTC + SFU
방송자 1명 → SFU가 RTP 패킷 수신 → 시청자 N명 각각에게 실시간 패킷 포워딩

차이는 재사용 단위입니다.

항목	HLS/DASH + CDN	WebRTC + SFU
재사용 단위	완성된 HTTP 세그먼트 파일	거의 재사용 없음. 시청자별 RTP 패킷 전송
연결 상태	HTTP 요청/응답 중심, 상대적으로 stateless	PeerConnection, ICE, DTLS, SRTP 상태 유지
엣지 역할	파일 캐시 후 반복 제공	실시간 미디어 서버로 패킷 포워딩
확장 방식	같은 URL을 캐시해서 fan-out	SFU 노드 증설, cascading, 지역 라우팅
지연	수 초~수십 초	수백 ms~1초대 가능
비용 구조	CDN 대역폭 중심, 캐시 효율 좋음	미디어 서버 CPU/메모리/네트워크 세션 비용 큼

여기서 말하는 비용은 단순히 클라우드 청구서의 "돈"만 뜻하지 않습니다. 실제로는 네 가지 비용이 동시에 들어갑니다.

비용 종류	HLS/DASH + CDN	WebRTC + SFU
네트워크 egress	CDN edge가 대량 전송을 흡수. 캐시 hit가 높으면 origin egress 감소	SFU가 시청자별로 RTP를 계속 내보냄. 시청자 수만큼 egress 증가
서버 세션 상태	HTTP 요청은 짧고 상대적으로 stateless	PeerConnection, ICE, DTLS, SRTP, bitrate 상태를 연결별로 유지
CPU/메모리	CDN은 정적 파일 전송에 최적화. origin CPU 부담 낮음	SFU는 패킷 라우팅, 암호화, NACK/PLI, simulcast layer 선택 등 실시간 처리
운영 복잡도	CDN 캐시 정책, TTL, purge, origin 보호 중심	SFU autoscaling, cascading, 지역 간 라우팅, TURN fallback, congestion control

왜 이런 차이가 나느냐면, HLS/DASH는 이미 완성된 조각을 나눠 주는 구조이고 WebRTC는 지금 들어오는 패킷을 각 시청자 상태에 맞춰 즉시 보내는 구조이기 때문입니다. 같은 1080p 방송을 10만 명이 본다고 해도, CDN은 seg_103.ts라는 같은 물건을 반복 배달합니다. WebRTC SFU는 각 시청자와 별도 SRTP 흐름을 유지하면서 패킷을 계속 복제해 보내야 합니다.

그래서 결론은 단순합니다.

YouTube/Twitch가 HLS/DASH+CDN 계열을 쓰는 이유는 느린 기술이라서가 아니다. 같은 비디오 조각을 수많은 시청자에게 재사용할 수 있어, 전 세계 대규모 동시 시청에 가장 경제적인 구조이기 때문이다.

WebRTC PoP와 CDN PoP는 무엇이 다른가

둘 다 "가까운 엣지로 붙인다"는 점은 비슷합니다. 하지만 엣지에서 하는 일이 다릅니다.

CDN PoP
   시청자 → 가까운 CDN edge
   역할: 이미 만들어진 HTTP 파일을 캐시하고 내려줌

WebRTC/SFU PoP
   참가자 → 가까운 SFU/media edge
   역할: 실시간 RTP 패킷을 받고, 라우팅하고, 필요하면 다른 SFU와 연결

CDN PoP는 "편의점 물류창고"에 가깝습니다. 이미 포장된 상품(seg_103.ts)을 근처 창고에 쌓아 두고, 손님이 오면 같은 상품을 계속 내줍니다.

WebRTC PoP는 "실시간 교환국"에 가깝습니다. 들어오는 음성·영상 패킷을 참가자별로 즉시 분기하고, 네트워크 상태에 따라 레이어 선택, 재전송 제어, congestion control 같은 실시간 판단을 합니다.

그래서 두 PoP 모두 지연을 줄이지만, 줄이는 방식이 다릅니다.

질문	CDN PoP	WebRTC/SFU PoP
가까운 곳에 붙는 이유	파일 다운로드 RTT와 origin 부하를 줄이기 위해	RTP 왕복 지연과 패킷 손실을 줄이기 위해
캐시 가능한가	가능. 핵심 장점	거의 불가능. 실시간 패킷은 시청자별 상태가 있음
같은 데이터를 재사용하나	같은 세그먼트를 여러 명에게 재사용	같은 입력을 받아도 각 시청자 연결로 별도 전송
적합한 규모	초대규모 단방향 시청	저지연 상호작용, 제한된 규모 또는 별도 cascading 설계

이것이 YouTube/Twitch 같은 플랫폼이 대규모 방송을 처리하는 핵심입니다. "실시간성"만 보면 WebRTC가 더 빠르지만, "전 세계 수십만 명에게 같은 방송을 안정적으로 뿌리는 비용"까지 보면 HLS/DASH+CDN이 더 강합니다.

6. 플레이어 — 가장 최신을 보지 않고, 조금 늦게 안정적으로 본다

시청자 플레이어는 단순히 "영상 URL 하나를 재생"하지 않습니다. 계속 판단합니다.

1. manifest 다운로드
2. 현재 가능한 화질 목록 확인
3. 네트워크 속도 측정
4. 적절한 화질의 segment 다운로드
5. 버퍼에 쌓기
6. 디코딩 후 화면 출력
7. 네트워크가 바뀌면 화질 전환

플레이어의 핵심 자산은 buffer입니다.

라이브 실제 시점:      [seg_108 생성 중]
CDN에 있는 최신 조각:  [seg_107]
플레이어가 재생 중:    [seg_104]
플레이어 버퍼:         [seg_105][seg_106]

플레이어가 seg_107을 바로 재생하면 지연은 줄어듭니다. 하지만 다운로드가 조금만 늦어도 화면이 멈춥니다. 반대로 seg_104처럼 몇 조각 뒤에서 재생하면 지연은 늘지만 안정적입니다.

이것이 YouTube의 latency 설정이나 Twitch의 low latency 모드가 실제로 조절하는 핵심입니다.

모드	플레이어 버퍼	장점	비용
Normal latency	큼	안정성·화질 우선	채팅 반응 늦음
Low latency	중간	상호작용과 안정성 균형	일부 환경에서 버퍼링 증가
Ultra-low latency	작음	빠른 채팅 반응	네트워크 흔들림에 취약, 일부 기능/해상도 제한 가능

YouTube 공식 도움말도 같은 tradeoff를 설명합니다. 낮은 latency는 read-ahead buffer를 줄여 상호작용성을 높이지만, 시청자 버퍼링 가능성을 높입니다. YouTube는 low latency에서 대체로 10초 미만, ultra-low latency에서 대체로 5초 미만을 목표로 설명합니다. Twitch도 low latency 모드를 제공하며, 시청자 플레이어에서 broadcaster latency를 확인할 수 있게 합니다.

7. Glass-to-glass 지연은 어디서 쌓이나

이제 전체 지연을 쪼개 보겠습니다.

카메라 캡처
  │ ① 캡처/합성/인코딩
  ▼
RTMP 업로드
  │ ② 공용 인터넷 + ingest
  ▼
플랫폼 처리
  │ ③ 트랜스코딩
  │ ④ 세그먼트화/패키징
  ▼
CDN
  │ ⑤ 캐시 전파/엣지 응답
  ▼
플레이어
  │ ⑥ manifest 갱신 + segment 다운로드 + 버퍼
  ▼
디스플레이 출력

대략적인 감각은 다음과 같습니다. 실제 수치는 플랫폼, 설정, 코덱, 세그먼트 길이, 네트워크, 플레이어 정책에 따라 달라집니다.

구간	지연 성격
카메라/게임 캡처	보통 작지만 장비·캡처 방식 영향
OBS 인코딩	preset, hardware encoder, bitrate 영향
RTMP 업로드	업로드 품질·가까운 ingest 여부 영향
플랫폼 트랜스코딩	compute-intensive, 병렬 처리 필요
세그먼트화	세그먼트가 닫혀야 배포 가능
CDN	대체로 빠르지만 첫 요청·지역별 차이 존재
플레이어 버퍼	가장 의도적으로 크게 잡는 지연

전통 HLS에서 20초 안팎의 glass-to-glass 지연이 흔한 이유는 여기 있습니다.

세그먼트 6초 × 플레이어가 3개 정도 여유분 유지
= 이미 18초 근처

여기에 인코딩, 업로드, 패키징, CDN, 디코딩 시간이 추가

반대로 low latency 모드는 세그먼트 길이를 줄이거나, 세그먼트를 더 작은 part로 나누거나, 플레이어 버퍼를 줄여 지연을 낮춥니다.

일반 HLS:
[ 6초 segment ][ 6초 segment ][ 6초 segment ] → 안정적, 느림

Low-latency 계열:
[0.5초 part][0.5초 part][0.5초 part]... → 빠름, 민감함

8. 왜 WebRTC처럼 0.5초로 안 하나

가능은 합니다. 하지만 목적이 다릅니다.

WebRTC live streaming도 유명하고 실제로 많이 씁니다. 다만 WebRTC가 강한 영역은 초저지연 상호작용입니다. 서버가 SFU 형태로 패킷을 거의 실시간으로 중계하고, 플레이어 버퍼도 작습니다. 대신 CDN 캐싱 모델과는 맞지 않습니다.

항목	HLS/DASH 라이브	WebRTC
목표	대규모 시청	실시간 상호작용
일반 지연	수 초~수십 초	수백 ms~1초대
배달 방식	HTTP segment + CDN	RTP/UDP 기반 실시간 미디어
확장	CDN으로 매우 강함	SFU/cascading 설계 필요
적합 사례	YouTube, Twitch, 스포츠 중계, 라이브 커머스 대형 방송	화상회의, 1:1 상담, 라이브 경매, 실시간 Q&A

실무적으로는 이렇게 나눠 보면 됩니다.

내가 원하는 것 = "같은 방송을 엄청 많은 사람이 안정적으로 보기"
   → HLS/DASH + CDN

내가 원하는 것 = "방송자와 시청자가 1초 안쪽으로 주고받기"
   → WebRTC + SFU

내가 원하는 것 = "둘 다"
   → WebRTC로 저지연 인터랙션 방을 만들고,
      대규모 시청자는 HLS/LL-HLS/CDN으로 분리하는 하이브리드 구조 검토

YouTube/Twitch가 기본적으로 HLS/DASH 계열 구조를 쓰는 이유는 "느린 기술이라서"가 아니라, 전 세계 대규모 동시 시청에 가장 경제적인 구조이기 때문입니다. WebRTC는 더 빠르지만, 모든 시청자에게 개별 실시간 미디어 세션을 유지해야 하므로 CDN처럼 "같은 파일을 캐시해서 반복 제공"하는 경제성이 나오지 않습니다.

9. 방송자가 실제로 줄일 수 있는 지연

플랫폼 내부 파이프라인은 방송자가 직접 제어할 수 없습니다. 방송자가 만질 수 있는 것은 대부분 입력 품질입니다.

1) 업로드 회선을 안정화한다

평균 업로드 속도만 보면 안 됩니다. 라이브는 순간 끊김에 민감합니다.

나쁜 상태:
평균 20 Mbps지만 2초마다 0으로 떨어짐 → dropped frames / reconnect / 지연 증가

좋은 상태:
안정적으로 8 Mbps 유지 → 낮은 bitrate라도 훨씬 안정적

Twitch FAQ도 설정 bitrate보다 여유 있는 upload bandwidth를 권장합니다. 실무적으로는 목표 송출 bitrate보다 최소 30% 이상 여유를 잡는 방식이 안전합니다.

2) 인코더 preset을 무리하지 않는다

x264의 느린 preset은 품질은 좋아질 수 있지만 CPU를 많이 씁니다. CPU가 밀리면 프레임이 늦게 나오고, 그 지연이 전체 파이프라인 앞단에서부터 쌓입니다.

CPU 과부하
   ▼
OBS encoding lag
   ▼
RTMP 전송 불안정
   ▼
플랫폼 ingest health 악화
   ▼
시청자 버퍼링 또는 latency 증가

가능하면 NVENC, Apple VideoToolbox, Intel Quick Sync 같은 하드웨어 인코더를 쓰는 것이 안정적입니다. 품질 최고보다 프레임 타이밍 안정성이 우선입니다.

3) 플랫폼 latency knob을 목적에 맞게 고른다

방송 목적	권장 방향
콘서트, 강의, 이벤트 중계	Normal 또는 Low latency
채팅 반응이 중요한 게임 방송	Low latency
실시간 Q&A, 빠른 상호작용	Ultra-low latency 또는 WebRTC 검토
1초 미만 응답이 필요한 경매·상담	YouTube/Twitch형 HLS보다 WebRTC/SFU 구조 검토

낮은 latency는 공짜가 아닙니다. 버퍼를 줄이는 것이므로 네트워크가 흔들릴 때 더 쉽게 멈춥니다.

10. 전체 아키텍처를 한 장으로 정리

┌─────────────────────────────────────────────────────────────────────┐
│ Broadcaster                                                          │
│                                                                     │
│ Camera/Game/Mic → OBS/Encoder → H.264/AAC → RTMP/RTMPS              │
└───────────────────────────────┬─────────────────────────────────────┘
                                │ public internet
                                ▼
┌─────────────────────────────────────────────────────────────────────┐
│ Ingest Layer                                                         │
│                                                                     │
│ 가까운 PoP 선택 → stream key 인증 → ingest health 체크               │
└───────────────────────────────┬─────────────────────────────────────┘
                                │ platform backbone
                                ▼
┌─────────────────────────────────────────────────────────────────────┐
│ Live Processing                                                      │
│                                                                     │
│ demux → decode → scale → encode many → ABR ladder                    │
│                         ├─ 1080p                                     │
│                         ├─ 720p                                      │
│                         ├─ 480p                                      │
│                         └─ audio                                     │
└───────────────────────────────┬─────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────────┐
│ Packaging                                                            │
│                                                                     │
│ segment 생성 → HLS/DASH manifest 갱신 → origin에 게시                │
└───────────────────────────────┬─────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────────┐
│ CDN                                                                  │
│                                                                     │
│ regional cache → edge cache → viewer에게 HTTP segment 제공            │
└───────────────────────────────┬─────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────────┐
│ Viewer Player                                                        │
│                                                                     │
│ manifest poll → segment download → ABR 선택 → buffer → decode → display│
└─────────────────────────────────────────────────────────────────────┘

11. 실무 판단 기준

마지막으로 의사결정 기준만 압축하면 이렇습니다.

요구사항	맞는 구조
수만~수백만 명에게 안정적으로 방송	HLS/DASH + CDN
채팅 반응이 몇 초 늦어도 괜찮음	YouTube/Twitch형 low latency
5초 이하가 중요하지만 대규모 배포도 필요	LL-HLS/LL-DASH 검토
1초 미만 양방향 상호작용	WebRTC/SFU
방송자 업로드망이 불안정	RTMP보다 SRT/전용 contribution 경로 검토
시청자 품질 자동 조절 필요	ABR ladder 필수

핵심은 "가장 낮은 지연"이 항상 정답이 아니라는 점입니다.

라이브 스트리밍 설계는 latency, scale, quality, cost의 균형 문제다. YouTube와 Twitch는 기본적으로 scale과 안정성을 우선하고, latency knob으로 상호작용성을 조절하게 만든다.

참고 자료

YouTube Help — Understand live streaming latency: https://support.google.com/youtube/answer/7444635
YouTube Help — Choose live encoder settings, bitrates, and resolutions: https://support.google.com/youtube/answer/2853702
Twitch Developers — Video Broadcast: https://dev.twitch.tv/docs/video-broadcast/
Twitch Help — Low Latency Video: https://help.twitch.tv/s/article/low-latency-video
Twitch Help — How Do I Stream FAQ: https://help.twitch.tv/s/article/how-do-i-stream-faq