HLS 완전 정복 — 치지직 입사 수준으로

네이버 치지직 입사를 목표로 공부한 HLS 딥다이브. "이게 뭔지"가 아니라 "왜 이 선택을 했는지, 트레이드오프가 뭔지, 대규모 서비스에서 어떤 문제가 생기는지"까지.

HLS (HTTP Live Streaming)

왜 만들어졌나

2009년 애플이 만들었다. 당시 웹 영상 재생은 Flash 기반이었는데 아이폰에 Flash가 없었다. 그래서 Flash 없이 HTTP만으로 스트리밍할 수 있는 방법으로 만든 게 HLS다.

지금은 사실상 표준. 유튜브, 트위치, 넷플릭스 전부 HLS를 쓴다.

한 줄 요약

영상을 잘게 쪼개서 HTTP 파일로 만들어 전송하는 방식. 현재 인터넷 스트리밍의 사실상 표준.

전체 동작 흐름

HLS의 핵심 아이디어: 영상을 통째로 보내지 말고, 잘게 잘라서 HTTP로 파일처럼 보내자.

[방송 서버]                                  [시청자 플레이어]
    |                                               |
영상을 10초 조각으로 자름                            |
seg_0.ts, seg_1.ts, seg_2.ts ...                  |
playlist.m3u8 생성                                 |
    |                                               |
    |<------ GET /master.m3u8 -------------------- |  ① 화질 목록 요청
    |------- 200 OK (화질 목록) ----------------->  |  ② 어떤 화질 있는지 파악
    |                                               |
    |<------ GET /720p/playlist.m3u8 ------------- |  ③ 720p 세그먼트 목록 요청
    |------- 200 OK (세그먼트 목록) ------------->  |  ④ 뭘 받아야 하는지 파악
    |                                               |
    |<------ GET /720p/seg_0.ts ------------------ |  ⑤ 첫 조각 요청
    |------- 200 OK (영상 데이터) -------------->  |  ⑥ 받아서 재생 시작
    |                                               |
    |<------ GET /720p/seg_1.ts ------------------ |  ⑦ 다음 조각 요청
    ...                                             |

핵심: 플레이어가 능동적으로 "이거 줘, 저거 줘" 요청하는 Pull 방식. 서버가 밀어주는 게 아님.

TCP 기반이 왜 중요한가

HLS → HTTP → TCP → 인터넷

HLS는 HTTP 위에서 동작하고, HTTP는 TCP 위에서 동작한다.

TCP vs UDP 비교:

	TCP	UDP
비유	등기우편 (수신 확인)	전단지 배포 (그냥 던짐)
데이터 보장	손실 시 재전송	손실돼도 그냥 넘어감
순서 보장	있음	없음
속도	느림	빠름
사용처	HLS, DASH	WebRTC, SRT

HLS가 TCP 기반이라서 생기는 결과:

영상 데이터 손실 없음 → 화질 깨짐 없음
방화벽 통과 잘 됨 (일반 HTTP 트래픽과 구분 안 됨)
기존 웹 인프라 그대로 활용 가능
대신 지연이 길어짐

세그먼트 파일 — `.ts` vs `.fmp4`

MPEG-2 Transport Stream (.ts)

HLS 초기부터 쓰던 포맷
중간에 파일이 잘려도 재생 가능한 구조
단점: 오버헤드 있고, 부분 세그먼트(LL-HLS) 지원 안 됨

Fragmented MP4 (.fmp4)

HLS v7부터 지원
DASH와 동일한 포맷 → CMAF으로 HLS/DASH 통일 가능
LL-HLS에서 필수 (부분 세그먼트 지원)
현재 신규 서비스에선 .fmp4 권장

구형: seg_0.ts, seg_1.ts ...
신형: seg_0.m4s, seg_1.m4s ... (init.mp4 헤더 파일 별도)

`.m3u8` 파일 구조 완전 분석

마스터 플레이리스트 (master.m3u8)

어떤 화질 버전이 있는지 알려주는 목차.

#EXTM3U
#EXT-X-VERSION:6

#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360,CODECS="avc1.42c01e,mp4a.40.2",FRAME-RATE=30
360p/playlist.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2",FRAME-RATE=30
720p/playlist.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2",FRAME-RATE=60
1080p/playlist.m3u8

BANDWIDTH: 비트레이트(초당 데이터량). 플레이어가 현재 네트워크 속도와 비교해서 맞는 버전 선택.
CODECS: 어떤 코덱으로 인코딩됐는지. 플레이어가 지원 여부 미리 확인 가능.

미디어 플레이리스트 (720p/playlist.m3u8)

실제 세그먼트 목록.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6          ← 세그먼트 최대 길이 6초
#EXT-X-MEDIA-SEQUENCE:148        ← 현재 목록의 첫 세그먼트 번호 (슬라이딩 윈도우)

#EXTINF:6.0,
seg_148.ts
#EXTINF:6.0,
seg_149.ts
#EXTINF:6.0,
seg_150.ts

# 라이브면 여기서 끝 없이 계속 추가됨
# VOD면 아래 한 줄 있음
#EXT-X-ENDLIST

EXT-X-MEDIA-SEQUENCE: 라이브에서 플레이리스트는 최근 3~5개 세그먼트만 유지하는 슬라이딩 윈도우 방식. 오래된 건 삭제하고 새 거 추가.

ABR (Adaptive Bitrate) 동작 사이클

① 네트워크 속도 측정
   seg_150.ts (3MB) 다운받는 데 0.6초 걸림
   → 3MB / 0.6초 = 5MB/s = 40Mbps

② 다음 세그먼트 화질 결정
   현재 1080p (5Mbps 필요) → 40Mbps 여유 → 유지

③ 갑자기 느려짐
   seg_151.ts 다운받는 데 4초 걸림
   → 3MB / 4초 = 0.75MB/s = 6Mbps
   → 1080p 유지하면 버퍼 소진 → 720p로 다운그레이드

④ 회복
   다시 빨라지면 720p → 1080p 단계적으로 올라감
   (한 번에 올리면 또 깨질 수 있어서 단계적으로)

플레이어 내부에서 자동으로 일어난다. 사람이 보기엔 화질이 잠깐 낮아졌다 올라가는 것만 보임.

지연이 20~30초인 이유 — 수학으로

세그먼트 길이: 6초

지연 발생 구간:
  1) 서버 인코딩 대기: 6초 분량 쌓여야 세그먼트 생성   → +6초
  2) 플레이어 버퍼:   끊김 방지용으로 3개 미리 받아둠  → +18초
  3) 네트워크 전송:   실제 전송 시간                  → +2~5초

총 지연: 약 26~29초

버퍼를 3개 쌓는 이유: 갑자기 네트워크가 느려져도 이미 받아둔 걸 재생하면서 버틸 수 있게 하기 위함.

폴링(Polling) 방식의 추가 지연:

라이브에서 플레이어는 새 세그먼트를 이렇게 확인한다.

플레이어: playlist.m3u8 요청 → 응답 → 새 세그먼트 없음 → N초 기다림 → 다시 요청

이 대기 시간도 지연에 추가된다. 보통 세그먼트 길이의 절반 정도 간격으로 폴링.

트레이드오프

항목	내용
✅ 장점	방화벽 통과, CDN 완벽 활용, 전 세계 인프라 그대로 사용, 하위 호환성
✅ 장점	ABR로 끊김 없는 재생
❌ 단점	지연 20~30초 (라이브 인터랙션 불가)
❌ 단점	플레이어가 계속 폴링 → 서버 요청 많음
❌ 단점	애플 독점 시작 (지금은 오픈됐지만 DASH 진영과 분열)

언제 HLS 대신 다른 걸 쓰는가:

지연 2~5초 필요 → LL-HLS
지연 0.5초 미만, 소규모 동시 시청 → WebRTC
현장 → 방송국 고품질 전송 → SRT

실무 포인트 — 대규모 서비스 기준

세그먼트 길이 선택 (치지직 같은 서비스에서 실제로 고민하는 것)

세그먼트 길이	지연	CDN 요청 수	선택 기준
2초	짧음 (~8초)	많음 (시청자당 초당 0.5회)	저지연 중요할 때
6초	중간 (~20초)	보통	일반적 선택
10초	길음 (~30초)	적음	CDN 비용 최소화

동시 시청자 100만 명 기준, 세그먼트를 2초 vs 10초로 잡으면 CDN 요청 수가 5배 차이난다. 지연과 비용의 트레이드오프를 서비스 특성에 맞게 결정해야 한다.

Origin-CDN 구조

[인코딩 서버]
     ↓ 세그먼트 생성
[Origin 서버]  ← .ts 파일 / .m3u8 저장
     ↓
[CDN 엣지 - 서울]  [CDN 엣지 - 부산]  [CDN 엣지 - 도쿄]
     ↓                   ↓                  ↓
 한국 시청자          한국 남부           일본 시청자

m3u8은 계속 업데이트되는 파일이라 CDN 캐시를 짧게 설정해야 한다. 세그먼트 파일은 변하지 않으니 길게 캐시해도 됨.

seg_xxx.ts    → Cache-Control: max-age=3600  (변하지 않으니까)
playlist.m3u8 → Cache-Control: max-age=1    (계속 바뀌니까)

치지직 관점

스트리머 OBS → RTMP 입수 → 트랜스코딩 → HLS 세그먼트 생성
                                              ↓
                                   [VOD 클립 저장] ← HLS 주력
                                   [라이브 배포]   ← LL-HLS 또는 HLS 혼용
                                              ↓
                                          CDN → 시청자

치지직 라이브에서 실시간 채팅과 방송 화면이 30초 차이나면 시청자 경험이 망가진다. 그래서 라이브 시청은 LL-HLS나 WebRTC로 지연을 줄이고, 다시보기/클립은 일반 HLS로 처리하는 게 일반적인 아키텍처.

면접 포인트

Q. HLS와 DASH의 차이점은?

HLS는 애플이 만든 프로토콜로 .m3u8 플레이리스트를 쓰고, DASH는 MPEG 표준으로 MPD 파일을 씁니다. 동작 방식은 거의 같고 세그먼트 기반 HTTP 전송인 점도 같아요. 차이는 HLS가 애플 생태계에서 기본 지원되고, DASH가 오픈 표준이라는 점입니다. 최근엔 CMAF(.fmp4) 포맷을 공통으로 쓰면서 세그먼트 자체를 HLS/DASH 양쪽에 동시 제공하는 방식이 늘고 있습니다.

Q. HLS 지연을 줄이려면?

세 가지 방법이 있습니다. 첫째, 세그먼트 길이를 줄이는 것 — 6초에서 2초로 줄이면 지연은 줄지만 CDN 요청이 늘어나는 트레이드오프가 있어요. 둘째, LL-HLS로 전환 — Partial Segment와 Blocking Playlist Reload를 써서 2~5초까지 줄입니다. 셋째, 아예 WebRTC로 바꾸는 것 — 0.5초 미만 가능하지만 CDN 활용이 안 돼서 대규모 동시 시청엔 부적합합니다. 서비스 특성에 따라 선택해야 해요.

Q. HLS에서 CDN을 쓸 때 주의할 점은?

m3u8 플레이리스트 파일과 세그먼트 파일의 캐시 정책을 다르게 가져가야 합니다. 세그먼트는 한번 만들어지면 불변이라 길게 캐시해도 되지만, m3u8은 라이브 중 계속 업데이트되기 때문에 Cache-Control을 짧게 설정해야 합니다. 안 그러면 시청자가 오래된 플레이리스트를 계속 받아서 새 세그먼트를 못 가져오는 문제가 생겨요.

Q&A: 현대 플랫폼이 LL-HLS/WebRTC 쓰는 추세인데 왜 TCP라고 하나

"HLS는 TCP 기반" — 절반만 맞는 말

HLS가 HTTP 위에서 동작하는 건 맞다. 근데 HTTP 버전이 뭐냐에 따라 전송 레이어가 달라진다.

HTTP/1.1  →  TCP
HTTP/2    →  TCP
HTTP/3    →  QUIC (UDP 기반)

최근 유튜브, 넷플릭스, 클라우드플레어 같은 대형 서비스들이 **HTTP/3 (QUIC)**을 도입했다. HLS 세그먼트를 UDP 위에서 전송하는 것.

QUIC이 뭔지

구글이 만든 전송 프로토콜. UDP 기반인데 TCP의 신뢰성은 직접 구현해놨다.

TCP의 고질적인 문제: Head-of-Line Blocking

보낸 패킷:   [1] [2] [3] [4] [5]
도착한 것:   [1] [2]  ✗  [4] [5]   ← 3번 유실

수신 버퍼:   [1] [2] [  ] [4] [5]

애플리케이션이 읽을 수 있는 것: [1] [2] 까지만
→ [4] [5]는 받아뒀지만 [3]이 올 때까지 기다려야 함

[4] [5]는 이미 도착했는데도 [3] 때문에 막혀서 대기. 이게 Head-of-Line Blocking.

HTTP/2에서 더 심각해지는 이유:

HTTP/2는 멀티플렉싱(하나의 TCP 연결에 여러 요청 동시)을 지원한다.

HTTP/2 연결 하나에서:
스트림 A: seg_0.ts 전송 중
스트림 B: seg_1.ts 전송 중
스트림 C: m3u8 전송 중

TCP 패킷 유실 발생 (스트림 A 소속)
→ TCP 레벨에서 전체 연결이 막힘
→ 스트림 B, C도 같이 멈춤

HTTP/1.1은 연결을 여러 개 열어서 우회했는데, HTTP/2는 연결 하나를 공유하니까 TCP 레벨 블로킹이 더 크게 터진다.

QUIC이 해결하는 방법:

QUIC 연결 하나에서:
스트림 A: seg_0.ts 전송 중
스트림 B: seg_1.ts 전송 중

스트림 A 패킷 유실 발생
→ 스트림 A만 재전송 대기
→ 스트림 B는 계속 진행  ← 이게 차이

각 스트림이 독립적으로 손실 복구한다. A가 막혀도 B, C는 그냥 달린다.

그리고 QUIC은 연결 재확립이 TCP보다 훨씬 빠름 — 핸드셰이크가 0-RTT도 가능. 모바일에서 WiFi → LTE 전환할 때 TCP는 연결을 새로 맺어야 하는데, QUIC은 연결 유지 가능.

현대 플랫폼들이 실제로 뭘 쓰나

유튜브:   HLS + DASH, 전송은 QUIC(HTTP/3) 적극 사용
넷플릭스: DASH + QUIC 실험 중
트위치:   HLS(기본) + WebRTC 기반 저지연 모드
치지직:   HLS 기반 추정, 방향은 LL-HLS

응용 레이어(HLS/DASH/WebRTC)와 전송 레이어(TCP/QUIC/UDP)는 별개다. HLS 포맷을 쓰면서 전송을 QUIC으로 하는 것도 가능하다.

그러면 왜 끊기냐 — 실제 원인

TCP라서 끊기는 게 아니다.

1. ABR 반응 속도 문제

네트워크가 갑자기 1Mbps로 떨어짐
ABR이 감지하는 데 2~3세그먼트 시간 걸림
그 사이에 이미 받아둔 버퍼 소진
→ 끊김

2. 버퍼 크기 설정

버퍼 크게 → 끊김 줄지만 지연 늘어남. 버퍼 작게 → 지연 줄지만 끊길 위험. 치지직처럼 라이브 인터랙션이 중요한 서비스는 버퍼를 작게 가져가서 그만큼 끊킬 위험이 높다.

3. CDN Cache Stampede

갑자기 시청자가 몰릴 때:
CDN 엣지에 최신 세그먼트가 아직 없음
→ Origin 서버로 요청 몰림
→ Origin 과부하 → 세그먼트 응답 늦어짐 → 끊김

방송 시작 직후나 이벤트 때 특히 많이 발생하는 이유.

면접 포인트

"HLS는 TCP 기반 아닌가요, 그럼 느리지 않나요?"

HLS가 HTTP 위에서 동작하는 건 맞는데, 전송 레이어는 HTTP 버전에 따라 달라집니다. HTTP/3을 쓰면 QUIC 위에서 동작해서 UDP 기반이 돼요. 최근엔 많은 대형 서비스가 Head-of-Line Blocking 문제와 모바일 연결 전환 문제를 해결하기 위해 QUIC으로 전환 중입니다. 그리고 끊김 자체는 TCP/UDP 선택보다 ABR 알고리즘 품질, 버퍼 설정, CDN 캐시 히트율이 더 큰 영향을 미쳐요.

Q&A: 라이브 스트리밍인데 CDN이 어떻게 캐시하는가

HLS가 라이브를 "캐시 가능하게" 만드는 설계

라이브 스트림을 정적 파일의 연속으로 변환한다.

실시간 방송 (연속적인 데이터 흐름)
        ↓
패키저(Packager)가 6초마다 파일로 잘라냄
        ↓
seg_148.ts (완성된 파일) → Origin 서버에 저장
seg_149.ts (완성된 파일) → Origin 서버에 저장
seg_150.ts (지금 만들고 있는 중...)

seg_148.ts는 완성된 순간부터 정적 파일이다. 변하지 않는다. CDN이 이걸 캐시할 수 있다.

실제 캐시 흐름

시청자 A: seg_148.ts 요청
  → CDN 엣지에 없음 → Origin에서 가져옴 → CDN 엣지에 캐시

시청자 B, C, D, E... (수십만 명): seg_148.ts 요청
  → CDN 엣지에 이미 있음 → Origin 건드리지 않고 바로 응답

시청자 A 한 명만 Origin을 때리고, 나머지는 전부 CDN에서 처리된다. 100만 명이 봐도 Origin 부하는 거의 없다.

진짜 문제: 라이브 엣지 (Cache Stampede)

가장 최신 세그먼트(방금 완성된 seg_150.ts)는 CDN에 아직 없다.

시청자 100만 명이 동시에 seg_150.ts 요청
→ CDN 엣지 전부 miss
→ Origin으로 요청 몰림
→ Origin 서버 과부하 → 응답 늦어짐 → 끊김

방송 시작 직후, 시청자 폭증 시 끊기는 이유가 이거다.

해결 방법:

① Origin Shield (중간 캐시 레이어)

시청자들 → CDN 엣지 (miss) → Origin Shield
                               여기서 miss → Origin
                               여기서 hit  → 엣지에 전파

Origin Shield가 중간에서 막아줘서 Origin에 가는 요청이 1/100으로 줄어든다.

② Push 방식

Origin이 seg_150.ts 완성 → 주요 CDN 엣지에 미리 밀어넣음
시청자가 요청하기 전에 이미 CDN에 있음 → Cache Miss 자체가 안 생김

③ LL-HLS의 딜레마

LL-HLS는 세그먼트를 완성 전에 부분만 먼저 보내는 Partial Segment를 쓴다. 근데 일반 CDN은 파일이 완성돼야 캐시할 수 있다. Partial Segment를 캐시하려면 CDN이 특별 지원을 해야 한다.

이게 "LL-HLS 구현이 어렵다"고 하는 이유 중 하나. HLS 포맷만 바꾼다고 되는 게 아니라, CDN이 Partial Segment를 이해하고 처리할 수 있어야 한다. 치지직이 LL-HLS 도입할 때 CDN 선택이 중요한 이유가 바로 이거다.

Q&A: OBS → 치지직 → 시청자 전체 파이프라인

전체 흐름

[스트리머 OBS]
    H.264 인코딩 (1920x1080, 6000Kbps) 단일 스트림
    RTMP로 전송
    ↓
[치지직 인제스트 서버]  ← 스트리머가 보낸 거 받는 곳
    ↓
[트랜스코딩 서버]       ← 여기서 포맷팅 다 함
    1080p 5000Kbps
    720p  2500Kbps  → 여러 화질로 복제
    480p  1000Kbps
    360p   500Kbps
    ↓
[패키저(Packager)]      ← HLS로 포맷팅하는 곳
    6초짜리 .ts 파일로 자름
    m3u8 플레이리스트 생성
    ↓
[Origin 스토리지]
    ↓
[CDN 엣지]
    ↓
[시청자 플레이어]

OBS가 하는 일: 화면 캡처 → H.264 인코딩 한 번 → RTMP로 전송. 끝.
치지직 서버가 하는 일: 받아서 → 여러 화질로 트랜스코딩 → HLS 세그먼트로 자르기 → CDN에 올리기.

왜 클라이언트에서 트랜스코딩 안 하나

스트리머 PC 부하 문제

1080p 동시 인코딩 × 4개 화질 + 게임 실행 = PC 버팀

네트워크 업로드 대역폭 문제

4개 화질 동시 전송:
1080p (5Mbps) + 720p (2.5Mbps) + 480p (1Mbps) + 360p (0.5Mbps) = 9Mbps
게임하면서 9Mbps 업로드는 불안정

서버에서 하면 효율적

치지직 서버는 GPU 서버 수천 대가 트랜스코딩만 전담한다. NVENC(엔비디아 GPU 인코더)로 실시간 수만 채널을 동시에 처리.

Q&A: RTMP를 가로채서 HiPick 구현이 가능한가

로컬 RTMP 프록시 방식

기존:  OBS → [치지직 인제스트 서버]

HiPick 적용 후:
       OBS → [HiPick 로컬 에이전트] → [치지직 인제스트 서버]
                       ↓
                  영상 분석 / 하이라이트 태깅

OBS에서 설정 하나만 바꾸면 된다.

기존:  서버: rtmp://ingest.chzzk.naver.com/live
변경:  서버: rtmp://localhost:1935/live   ← 로컬로 변경

nginx-rtmp-module 설정 예시:

rtmp {
    server {
        listen 1935;

        application live {
            live on;

            # 치지직으로 원본 중계
            push rtmp://ingest.chzzk.naver.com/live/스트림키;

            # 분석용으로 복사
            exec ffmpeg -i rtmp://localhost:1935/live/$name
                        -c copy -f flv pipe:1 | 분석_스크립트;
        }
    }
}

Restream.io, Streamlabs 같은 서비스가 이 방식으로 유튜브 + 트위치 + 치지직 동시 방송 서비스를 만들었다.

구현 방식 비교

방식	핵심 과제	현실성
로컬 RTMP 프록시	스트리머 PC 부하 최소화	가능, 구현 난이도 있음
클라우드 분석	비용 최소화	가능, 스마트 트리거 필요
치지직 파트너십	API 계약	현실적으로 어려움

Q&A: 클라이언트 부하 최소화 — 기술적 핵심

나쁜 방법 vs 좋은 방법

나쁜 방법:
매 프레임 영상 분석 (60fps = 초당 60번 AI 추론)
→ GPU 다 잡아먹음, OBS 인코딩 품질 떨어짐

좋은 방법:
영상은 건드리지 않고, 간접 신호만 분석

하이라이트 간접 신호

하이라이트가 일어날 때 영상 말고 뭐가 변하는가:

① 오디오 에너지 급증

킬샷 → 효과음 폭발 → 음량 스파이크
→ 오디오 파형만 분석 (영상 분석 대비 1/100 연산량)

② 채팅 속도 폭증

"ㅋㅋㅋㅋ", "와", "클립" 채팅이 갑자기 폭발
→ 치지직 채팅 API만 모니터링 (영상 처리 0)

③ 게임 API (가능한 경우)

리그오브레전드 펜타킬, 오버워치 플레이오브더게임
→ 게임이 이벤트를 직접 쏴줌

최적 아키텍처

[로컬 HiPick 에이전트]  ← 아주 가벼움
  오디오 에너지 모니터링  (CPU 1% 미만)
  치지직 채팅 API 폴링   (네트워크만)
  타임스탬프 기록

하이라이트 신호 감지 시:
  "12:34:07에 이벤트 있었음" → 클라우드에 전송

[HiPick 클라우드]
  치지직에 이미 올라간 스트림에서
  12:34:07 ± 30초 구간만 잘라서 클립 생성

클라우드 비용이 생각보다 안 드는 이유

풀 스트림 클라우드 분석:
  6시간 방송 × 6000Kbps = 16GB → 비쌈

타임스탬프 기반:
  하이라이트 평균 10개 × 60초 = 10분만 처리
  → 비용 1/36로 줄어듦

면접 포인트

"스트리밍 데이터를 실시간으로 분석하려면 어디서 처리해야 하는가?"

세 가지 접근이 있습니다. 클라이언트 프록시 방식은 구현이 쉽지만 스트리머 PC 부하가 문제입니다. 서버사이드 처리는 스트리머 부담이 없지만 인프라가 필요합니다. 가장 효율적인 방법은 로컬에서는 오디오 에너지와 채팅 속도 같은 경량 신호만 감지해 타임스탬프를 기록하고, 클라우드에서는 해당 구간만 처리하는 방식입니다. 이렇게 하면 로컬 부하도 최소화되고 클라우드 비용도 1/36 수준으로 줄일 수 있습니다.

오늘 전체 요약

1. HLS = HTTP(TCP) 기반, 세그먼트 파일로 라이브를 "정적 파일화"해서 CDN 캐시 가능
2. HTTP/2 + TCP = HoL Blocking 여전히 존재 → QUIC(HTTP/3)이 스트림별 독립 처리로 해결
3. 라이브 CDN = 완성된 세그먼트는 캐시, m3u8은 짧게, 최신 세그먼트가 병목 (Cache Stampede)
4. OBS → 치지직 파이프라인 = 트랜스코딩/패키징 전부 서버사이드
5. HiPick 최적 설계 = 로컬에서 오디오+채팅 신호 감지 → 타임스탬프만 클라우드 전송 → 클라우드가 클립 추출

HLS (HTTP Live Streaming)

왜 만들어졌나

한 줄 요약

전체 동작 흐름

TCP 기반이 왜 중요한가

세그먼트 파일 — .ts vs .fmp4

.m3u8 파일 구조 완전 분석

ABR (Adaptive Bitrate) 동작 사이클

지연이 20~30초인 이유 — 수학으로

트레이드오프

실무 포인트 — 대규모 서비스 기준

치지직 관점

면접 포인트

Q&A: 현대 플랫폼이 LL-HLS/WebRTC 쓰는 추세인데 왜 TCP라고 하나

"HLS는 TCP 기반" — 절반만 맞는 말

QUIC이 뭔지

현대 플랫폼들이 실제로 뭘 쓰나

그러면 왜 끊기냐 — 실제 원인

면접 포인트

Q&A: 라이브 스트리밍인데 CDN이 어떻게 캐시하는가

HLS가 라이브를 "캐시 가능하게" 만드는 설계

실제 캐시 흐름

진짜 문제: 라이브 엣지 (Cache Stampede)

Q&A: OBS → 치지직 → 시청자 전체 파이프라인

전체 흐름

왜 클라이언트에서 트랜스코딩 안 하나

Q&A: RTMP를 가로채서 HiPick 구현이 가능한가

로컬 RTMP 프록시 방식

구현 방식 비교

Q&A: 클라이언트 부하 최소화 — 기술적 핵심

나쁜 방법 vs 좋은 방법

하이라이트 간접 신호

최적 아키텍처

클라우드 비용이 생각보다 안 드는 이유

면접 포인트

오늘 전체 요약

세그먼트 파일 — `.ts` vs `.fmp4`

`.m3u8` 파일 구조 완전 분석