YouTube·Twitch 라이브 스트리밍 참조 아키텍처 — OBS에서 재생까지

대형 라이브 스트리밍은 일반적으로 encoder output을 ingest한 뒤 여러 rendition으로 처리하고, HTTP media segment로 packaging해 CDN으로 배포합니다. YouTube와 Twitch의 공개 문서는 ingest 방식과 latency mode를 설명하지만 내부 transcoding·packaging topology 전체를 공개하지는 않습니다. 아래 구조는 공개된 동작과 표준을 바탕으로 한 참조 아키텍처입니다.

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

0. 핵심 명제 — HTTP 라이브는 미디어 조각을 CDN으로 배포한다

HTTP 기반 라이브 스트리밍은 입력 미디어를 렌디션과 세그먼트로 패키징하고, 시청자가 CDN을 통해 manifest와 미디어 조각을 가져가게 한다. 세그먼트 생성과 플레이어 버퍼는 확장성과 재생 안정성을 높이는 대신 지연을 추가한다.

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

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

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

그래서 라이브 스트리밍에서 지연은 단순한 서버 성능 문제가 아니라 아키텍처가 선택한 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는 이미 영상을 압축해서 보냅니다.

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

왜 아직도 RTMP인가

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

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

OBS
XSplit
Streamlabs
하드웨어 인코더
콘솔 송출
        │
        └── 목적지 플랫폼이 지원하는 RTMP 계열 설정 사용

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

YouTube 공개 문서는 RTMP/RTMPS와 HLS ingest를 안내하고, Twitch 개발자 문서는 RTMP ingest를 설명합니다. SRT는 목적지의 공식 ingest 문서가 지원한다고 명시한 경우에만 선택해야 합니다.

2. Ingest PoP — 방송 스트림을 받는 입구

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

방송자는 연결할 ingest endpoint를 선택하거나 플랫폼이 제공한 endpoint를 사용합니다. Twitch는 PoP별 ingest server 목록과 선택 방식을 공개하지만, 모든 플랫폼이 자동으로 지리상 가장 가까운 서버를 고른다고 단정할 수는 없습니다.

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

아래는 ingest 서비스가 사용할 수 있는 일반적인 라우팅 패턴입니다. YouTube나 Twitch의 실제 내부 구현을 설명하는 표는 아닙니다.

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를 조심스럽게 설계해야 합니다.

정리하면 이렇습니다.

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

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

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

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

WebRTC/SFU도 PoP에 붙나

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

WebRTC 접속 흐름

브라우저/앱
   │
   ├─ STUN으로 server-reflexive 후보 수집
   ├─ TURN으로 relayed 후보 수집
   ├─ SFU/media edge 후보 받기
   └─ ICE connectivity check와 우선순위로 후보 쌍 선택
        │
        ▼
선택된 media edge와 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

위 비트레이트와 렌디션은 구조를 보여주기 위한 예시입니다. 실제 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 생성

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

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

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

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

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

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

이 단계가 segmentation + packaging입니다.

각 화질의 연속 스트림
   │
   ▼
설정한 target duration에 맞춰 자르기
   │
   ▼
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

플레이어는 이 목록을 반복해서 받아 최신 세그먼트를 따라갑니다. 재생 시작 위치와 버퍼 정책은 플레이어·프로토콜 설정에 따라 다릅니다. RFC 8216은 일반 HLS 클라이언트가 live playlist 끝에서 최소 세 target duration보다 가까운 지점을 시작 위치로 선택하지 않도록 권고합니다.

5. CDN — 캐시 가능한 조각을 엣지에서 배포한다

대규모 HTTP 라이브 배포에서 CDN은 origin의 반복 전송 부담을 엣지로 분산하는 핵심 구성 요소입니다. 아래 그림은 특정 플랫폼의 내부망이 아니라 일반적인 계층을 단순화한 것입니다.

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

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

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

"HTTP 파일"이라는 말의 핵심은 세그먼트가 URL로 식별되는 캐시 가능한 HTTP 리소스가 된다는 뜻입니다. 플레이어는 manifest, 재생 위치, 버퍼와 ABR 상태를 유지하지만 CDN은 동일 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 입장에서는 이것이 가장 다루기 쉬운 형태입니다.

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

10만 명이 같은 2초 조각을 요청
   │
   ├─ CDN 없음: origin이 반복 전송 부담
   └─ 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가 훨씬 맞습니다. 하지만 대규모 단방향 시청에서는 비용 구조가 다릅니다.

구조 차이는 다음 비유로 설명할 수 있습니다.

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

CDN 기반 HTTP 스트리밍은 같은 미디어 조각을 여러 시청자에게 재사용할 수 있어 대규모 단방향 배포에 유리합니다. 실제 비용 우위는 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 모두 지연을 줄이지만, 줄이는 방식이 다릅니다.

이 참조 구조에서 HTTP 세그먼트와 CDN은 같은 콘텐츠를 대규모로 배포하는 데 유리하고, WebRTC는 시청자별 실시간 세션을 유지하는 대신 상호작용 지연을 줄이는 데 유리합니다. 규모별 비용과 지연은 실제 부하 시험으로 비교해야 합니다.

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처럼 몇 조각 뒤에서 재생하면 지연은 늘지만 안정적입니다.

플레이어 read-ahead와 플랫폼 처리 정책은 공개 latency 모드의 주요 tradeoff입니다. 정확한 내부 버퍼 값은 플랫폼이 공개한 범위에서만 말해야 합니다.

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 다운로드 + 버퍼
  ▼
디스플레이 출력

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

전통 HLS의 지연을 설명할 때는 RFC 8216의 live 시작 위치 권고를 예로 들 수 있습니다.

예시 target duration 6초 × live 끝에서 최소 3 target duration
= 시작 위치가 약 18초 뒤가 될 수 있음

여기에 인코딩, 업로드, 패키징, CDN, 디코딩 정책이 영향을 줌

이는 RFC의 6초 고정값이나 보편적인 20초 보장이 아닙니다. target duration과 플레이어 정책이 다르면 지연도 달라집니다.

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

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

Low-latency 계열의 예:
[partial segment][partial segment][partial segment]... → 더 일찍 전송, 버퍼 여유 감소

8. HTTP 스트리밍과 WebRTC의 지연 목표가 다른 이유

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

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

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

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

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

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

일반적인 HTTP 라이브 구조는 CDN이 같은 조각을 재사용할 수 있다는 장점이 있습니다. WebRTC SFU는 시청자별 실시간 전송 상태를 유지하므로 비용과 확장 방식이 다릅니다. YouTube와 Twitch의 정확한 내부 전달 포맷은 공개 자료 없이 단정하지 않습니다.

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

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

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

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

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

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

플랫폼은 설정 bitrate보다 충분한 업로드 여유를 두도록 안내합니다. 고정 30%를 보편적 기준으로 쓰기보다는 실제 회선의 지속 처리량, 지터, packet loss와 장시간 송출 시험으로 안정적인 headroom을 정해야 합니다.

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

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

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

NVENC, Apple VideoToolbox, Intel Quick Sync 같은 하드웨어 인코더는 CPU 부담을 줄일 수 있습니다. 다만 화질, 지원 코덱과 동시 세션 한계가 다르므로 같은 해상도·프레임레이트에서 software encoder와 비교 측정해야 합니다.

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

낮은 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. 실무 판단 기준

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

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

라이브 스트리밍 설계는 latency, scale, quality, cost의 균형 문제다. 플랫폼의 공개 latency 모드와 ingest 제약을 확인하고 목표 네트워크에서 측정해야 한다.

참고 자료

• YouTube Help — Understand live streaming latency
• YouTube Help — Choose live encoder settings, bitrates, and resolutions
• Twitch Developers — Video Broadcast
• Twitch Help — Low Latency Video
• Twitch Help — How Do I Stream FAQ
• RFC 8216 — HTTP Live Streaming
• Apple — Enabling Low-Latency HLS
• Haivision SRT — official repository