기술 해설
방송 시작부터 재생까지 — 가정으로 살펴보는 라이브 트랜스코딩 인프라
이 글은 가상의 라이브 파이프라인을 구성해 책임과 비용을 비교하는 학습 노트다. 처음부터 등장하는 6.2초는 단계별 시간을 임의로 배정한 예시이며, 치지직이나 다른 서비스에서 측정한 시작 지연이 아니다.
기술 해설
스트리밍, 데이터베이스, 네트워크의 동작 원리.
기술 해설
HLS와 DASH가 미디어 조각을 공유하는 방법 — CMAF
HLS와 DASH는 서로 다른 매니페스트를 사용한다. 그렇다고 항상 영상을 두 번 인코딩해야 하는 것은 아니다. 같은 압축 비트스트림을 다른 컨테이너로 포장할 수 있기 때문이다.
기술 해설
NVENC와 x264의 비용을 비교하려면 — GPU 트랜스코딩의 조건
NVENC의 비용을 x264와 비교하려면 같은 입력·출력 사다리·화질 목표에서 지속 처리량을 측정해야 한다. 동시 방송 1,000개와 5개 출력이 있다는 사실만으로 서버 대수를 결정할 수 없다. 5개 출력의 해상도와 처리 비용도 서로 다르다.
기술 해설
콘텐츠마다 다른 화질 사다리 — ABR Ladder 설계
ABR은 같은 콘텐츠를 여러 해상도·비트레이트로 준비해 재생 조건에 맞게 선택하는 방식이다. 코덱까지 나누면 출력 개수가 더 늘어난다. 그러나 “Netflix는 모든 영화를 50번 인코딩한다”는 고정 숫자를 뒷받침할 근거는 없어 제거했다.
기술 해설
코덱은 기술이 아니라 비즈니스 결정이다 — 시나리오/비용/디버깅 종합
지금까지 H.264, AAC, H.265, Opus, AV1, VP9까지 코덱 6개를 봤다. 각각의 압축 원리와 라이센스 구조를 알아도, 실무 질문은 결국 하나로 모인다.
기술 해설
FFmpeg로 읽는 라이브 미디어 파이프라인 — 입력부터 인코딩과 출력까지
치지직, Twitch, Netflix의 라이브/VOD 인프라를 뜯어보면 공통점이 있다. 모두 FFmpeg 위에서 굴러간다. 그것도 인프라만이 아니다.
기술 해설
AV1과 VP9 — 압축 기술과 로열티 프리 목표를 구분해서 보기
영상 코덱의 역사는 단순했다. ITU + ISO가 H.264 만들고, H.265 만들고. 모두 그걸 쓰면 됐다.
기술 해설
Discord 음성이 1초도 안 끊기는 비밀 — Opus
Discord 음성 채팅을 켜놓고 게임할 때, 통신사가 LTE 약전계에 진입해도 목소리가 거의 안 끊기는 경험. WhatsApp 보이스 메시지가 1990년대 모뎀 같은 인터넷에서도 들리는 경험. Zoom이 카페 와이파이에서도 화면은 깨져도 음성은 계속 들리는 경험.
기술 해설
H.265를 선택할 때 압축 효율만으로 부족한 이유 — 호환성과 HDR
H.265(HEVC)는 H.264보다 발전한 압축 도구를 제공한다. 실제 비트레이트 절감률과 인코딩 비용은 콘텐츠·설정·구현에 따라 달라진다. 보급률 1%나 항상 50% 절감처럼 단일 숫자로 일반화할 근거는 이 글에 없다.
기술 해설
영상 옆의 128kbps — AAC와 오디오 코덱을 따로 살펴야 하는 이유
영상 6Mbps와 오디오 128kbps를 가정하면 오디오 비중은 128 ÷ (6000 + 128) × 100 ≈ 2.09%다. 오버헤드를 제외한 예시이며, 고정적인 5%가 아니다.
기술 해설
373MB/s에서 6Mbps로 — 조건을 명시하고 이해하는 H.264 압축
1080p 60fps를 RGB 8비트 × 3채널, 패딩 없는 raw 영상으로 계산하면 1920 × 1080 × 3 × 60 = 373,248,000바이트/초, 즉 373.248MB/s다. 1시간은 약 1.344TB다. 여기서 MB·TB는 10진 단위다.
기술 해설
RTMP를 IETF가 끝내려고 하는 중 — WHIP/WHEP
[지난 시리즈](../rtmp-still-alive/)에서 RTMP가 20년이 지나도 안 죽는 이유를 봤다. 도입 비용 0, 호환성 100%, 생태계 관성.
기술 해설
Google이 Skype 독점을 깨려고 만든 — WebRTC
2010년만 해도 화상 통화는 무조건 별도 프로그램 설치가 필요했다. Skype, MSN Messenger, 시스코의 WebEx. 브라우저에서 카메라/마이크에 접근할 방법이 없었다. 자체 P2P 프로토콜은 폐쇄적이었고, 기업이 가입자를 가두는 도구였다.
기술 해설
방송사들이 인터넷으로 송출할 때 쓰는 비밀병기 — SRT
올림픽이나 월드컵 중계를 보면 현장 카메라 → 본사 → 시청자로 신호가 흐른다. 옛날엔 위성/전용선이었다. 한 번 깔면 안정적이지만 한 번 쏘는 데 수천만 원.
기술 해설
HLS의 25초 지연을 2초로 — LL-HLS는 무엇을 바꿨나
라이브 방송을 보다가 채팅이 영상보다 빠른 경험, 게임 스포일러가 채팅으로 먼저 새는 경험, 다 해봤을 거다. 이게 일반 HLS의 18~25초 지연 때문이다.
기술 해설
DASH가 기술적으로 더 좋은데 왜 HLS가 이겼나
기술 표준의 역사에서 자주 보이는 패턴이 있다. 기술적으로 더 우수한 게 시장에서 진다.
기술 해설
라이브 영상이 그냥 파일이라고? — HLS의 미친 발상
2009년 Apple이 한 결정이 라이브 스트리밍의 모든 걸 바꿨다.
기술 해설
Flash는 2020년에 죽었는데 RTMP는 왜 안 죽나
OBS 켜본 사람은 다 알 거다. 방송 설정에 들어가면 "서버"와 "스트림 키"를 입력하라고 한다. 그 서버 주소가 rtmp://로 시작한다.
기술 해설
시청자 수와 비트레이트로 계산하는 CDN 전송량과 비용
라이브 CDN의 전송량은 평균 동시 시청자 수, 비트레이트, 시간으로 추산할 수 있다. 청구 금액에는 실제 계약 단가와 과금 조건이 더 필요하다.
기술 해설
버퍼링은 왜 생기나 — TCP HoL Blocking부터 Origin Shield까지
"왜 갑자기 영상이 멈추지?"
기술 해설
화질이 좋다는 건 정확히 무슨 뜻인가 — 해상도, 비트레이트, ABR
"이 영상 1080p인데 왜 깨져 보이지?"
기술 해설
1080p 영상의 데이터량부터 다시 계산하기 — 스트리밍의 기초 4가지
치지직 입사를 목표로 스트리밍 기술을 공부 중이다. HLS, WebRTC 같은 프로토콜부터 본 게 아니라 더 아래 — "동영상이 도대체 뭐길래 압축이 필요한가", "TCP는 왜 라이브에 안 맞나" 같은 기초부터 다시 정리했다.
기술 해설
RTMP, MPEG-TS, SRT - 직접 짜면서 이해한 것들
치지직 스트림에서 오디오를 분리해서 분석하는 파이프라인을 짜야 했다. 처음엔 HLS로 받으면 되는 거 아닌가 싶었는데, 알고 보니 완전히 다른 문제였다.
기술 해설
HLS 완전 정복 — 치지직 입사 수준으로
2009년 애플이 만들었다. 당시 웹 영상 재생은 Flash 기반이었는데 아이폰에 Flash가 없었다. 그래서 Flash 없이 HTTP만으로 스트리밍할 수 있는 방법으로 만든 게 HLS다.
기술 해설
Kafka 핵심 개념 기술 피드백
카프카란 대용량 이벤트 처리 시스템 디스크에 순차적으로 저장하기 때문에 속도가 빠름 비동기 처리 백에서 작동 직접적으로 클라이언트와 소통하지 않음 이녀석의 역할을 단순히 데이터를 저장하는 역할 jvm에 접근하지 않고 os cache page를 사용하기 때문에 속도가 빠름 실시간성이 강함 메세지 묶음 처리 그러나 용도…