이더넷, MAC 주소, TCP/UDP(아직), MTU(아직) 등 네트워크의 기본 구성 요소를 배웠습니다. 영상 스트리밍은 이 모든 지식이 왜 중요했는지를 보여주는 내용 중 하나!
TCP vs UDP의 선택: 넷플릭스는 왜 TCP 기반의 HLS를 선택했을까요? 구글 미트는 왜 UDP 기반의 WebRTC를 사용할까요? 이 질문에 답하는 과정에서 우리는 '신뢰성'과 '실시간성'이라는 두 개념의 트레이드오프를 확인할 수 있다.
대역폭과 지연 시간: 영상 데이터는 네트워크의 대역폭(Bandwidth)과 지연 시간(Latency)을 극한으로 시험합니다. "왜 우리 서비스 영상이 자꾸 끊길까?"라는 문제를 해결하려면, 네트워크의 물리적인 한계를 이해하고 그 위에서 동작하는 적응형 비트레이트(ABR) 같은 기술을 알아야 한다.
현재 테크팀에서 주요하게 항상 논의되고 있는 기술들 중 하나이다.
넷플릭스 영화와 CCTV 실시간 영상은 똑같은 인터넷 선을 통해 전달됩니다. 그런데 왜 넷플릭스는 버퍼링이 걸릴지언정 화면이 깨지지 않고, CCTV는 가끔 화면이 깨져도 절대 멈추지 않을까?
넷플릭스 : 버퍼링이 걸리더라도 사용자에게 항상 좋은 품질의 프레임을 전달해야함.
CCTV : 프레임의 품질이 좋지 않더라도 항상 실시간성을 유지해야함.
영상 스트리밍은 어떤 목적으로 스트리밍을 하느냐에 따라서 선택이 진행되어야 한다.
- TCP (Transmission Control Protocol): "꼼꼼하고 신뢰도 높은 등기우편"
특징: 3-way handshake로 연결 확인, 패킷마다 번호를 매겨 순서 보장, 잘 받았는지 응답(ACK) 확인, 누락 시 재전송.
결과: 데이터 전송은 100% 신뢰할 수 있지만, 확인 절차 때문에 조금 느림.
핵심: 신뢰성(Reliability)
- UDP (User Datagram Protocol): "빠르지만 보장은 없는 일반 엽서"
특징: 연결 확인 없음, 순서 보장 없음, 응답 확인 없음, 재전송 없음. 그냥 보냄.
결과: 매우 빠르고 오버헤드가 적지만, 중간에 엽서(패킷)가 유실될 수 있음.
핵심: 속도와 실시간성(Latency)
각 영상 스트리밍(프로토콜)은 어떤 것을 기반으로 진행이 되는가?
프로토콜: HLS (HTTP Live Streaming) - 넷플릭스, 유튜브, 대부분의 VOD/라이브 서비스
동작 방식: 영상을 잘게 쪼갠 수많은 .ts 파일(과거엔 10초였으나, 최근엔 지연 시간을 줄이기 위해 2~6초가 일반적)과, 그 재생 목록인 m3u8 파일로 구성.
애플에 의해 2009년 제안된 라이브 비디오 스트리밍 프로토콜
선택은?: HTTP는 TCP 위에서 동작합니다.
선택의 이유: "영화나 드라마는 1초라도 화면이 깨지면 사용자 경험이 급격히 나빠집니다. 따라서 조금 버퍼링이 걸리더라도, 모든 영상 조각(.ts)과 재생 목록(.m3u8)이 100% 온전하게 도착하는 것(신뢰성)이 무엇보다 중요하기 때문입니다."
- 적응형 비트 전송률 스트리밍
- 비트 전송률 스트리밍(ABR)
이 파일 안에는 '똑같은 영상 구간이지만, 화질은 다른' 여러 버전의 .ts 파일 주소들이 모두 나열
플레이어는 사용자의 현재 네트워크 속도(대역폭)를 계속 확인하면서, '지금은 인터넷이 빠르니 고화질용 .ts 파일을 받아야겠다', '어, 와이파이가 약해졌네. 이제 저화질용 .ts 파일을 받아야겠다'라고 스스로 판단하고 다음 조각을 선택. 이것이 바로 끊김 없이 최적의 화질을 제공
단점
-
높은 지연 시간(Latency): HTTP 기반의 특성상, 영상을 조각내고 목록을 업데이트하는 과정에서 최소 수 초 이상의 지연이 발생합니다. (최대 30초 이상) 이는 실시간 소통이 중요한 서비스에는 치명적입니다. (최신 동향: 이를 해결하기 위해 'Low-Latency HLS'라는 확장 기술이 등장하여 지연 시간을 2초 미만으로 줄이려는 노력이 계속되고 있습니다.)
-
단방향 통신: HTTP는 요청-응답 모델이므로, 서버가 클라이언트에게 일방적으로 푸시하는 양방향 통신에는 적합하지 않습니다.
Ref. https://heenee.tistory.com/177
프로토콜: RTSP/RTP - CCTV, IP 카메라, 화상회의, 드론 영상
실시간 스트리밍 프로토콜(Real Time Streaming Protocol, RTSP)은 실시간 속성을 가진 데이터 전송을 제어하기 위한 응용 프로그램 수준의 프로토콜이다.
RTSP는 오디오 및 비디오와 같은 실시간 데이터의 제어된 주문형 전송을 가능하게 하는 확장 가능한 프레임워크를 제공한다.
동작 방식: RTSP로 '재생/정지' 같은 제어 신호를 보내고(리모컨), 실제 영상 데이터는 RTP라는 프로토콜로 전송.
제어 신호(RTSP)는 명령이 유실되면 안 되므로 TCP로, 실제 영상 데이터(RTP)는 속도가 중요하므로 주로 UDP로 보냅니다.
하지만 방화벽이 UDP 포트를 막는 경우가 많아, 이런 환경을 통과하기 위해 RTP 데이터를 TCP 연결에 실어 보내는 'RTSP Interleaved Mode'라는 방식도 존재합니다. UDP의 장점을 포기하는 대신 연결성을 확보하는 타협책입니다.
선택의 이유: "CCTV의 목적은 과거의 완벽한 화질이 아니라 '지금 이 순간'을 최대한 지연 없이 보는 것(실시간성)입니다. 1초 전의 완벽한 화면보다, 중간에 약간의 노이즈가 끼더라도 0.1초 전의 현재 화면이 훨씬 중요합니다. 따라서 속도를 위해 손실을 감수하는 UDP를 선택한 것입니다.
단점
- TSP는 웹 표준인 HTTP와 직접 호환되지 않습니다. 따라서 웹 브라우저에서 RTSP 스트림을 직접 재생하려면 별도의 플러그인이나 복잡한 변환 과정이 필요합니다.
3. 프로토콜: gRPC - MSA 백엔드 통신, AI 모델 실시간 데이터 스트리밍
동작 방식: HTTP/2 기반의 현대적인 API 통신 기술. 양방향 스트리밍을 지원.
gRPC는 HLS나 RTSP처럼 사용자에게 직접 영상을 보여주기 위한 스트리밍 프로토콜이 아님. gRPC의 주 무대는 마이크로서비스 아키텍처(MSA)에서 서비스 간에 데이터를 주고받는 내부 통신망
선택은?: HTTP/2는 TCP 위에서 동작합니다.
선택의 이유: "gRPC는 서비스 간의 안정적이고 구조화된 데이터 통신을 위해 만들어졌습니다. AI 모델에 영상 프레임을 보내 분석 결과를 받을 때, 프레임 하나라도 유실되면 분석 결과가 완전히 틀어질 수 있습니다. 따라서 신뢰성을 보장하는 TCP를 기반으로, HTTP/2의 스트림 멀티플렉싱 기능을 활용해 TCP의 단점(느린 속도)을 극복한 현대적인 방식입니다."
번외.
DASH (Dynamic Adaptive Streaming over HTTP)
포지션: "HLS의 국제 표준 라이벌"
설명: HLS가 Apple의 기술인 것에 반해, DASH는 ISO 국제 표준으로 지정된 기술입니다. 동작 원리는 HLS와 거의 동일하지만(TCP 기반, 적응형 비트레이트), 특정 제조사에 종속되지 않고 어떤 코덱이나 DRM(디지털 저작권 관리) 기술과도 유연하게 결합할 수 있는 '개방성'이 가장 큰 장점입니다. 넷플릭스, 유튜브 등 대부분의 글로벌 서비스는 여러 디바이스를 지원하기 위해 HLS와 DASH를 함께 사용합니다.
WebRTC (Web Real-Time Communication)
포지션: "실시간 상호작용의 끝판왕"
설명: HLS나 DASH의 수 초 단위 지연 시간으로는 불가능한 0.5초 이하의 초저지연 양방향 통신을 위해 태어난 기술입니다. UDP 기반으로 동작하며, 서버를 거치지 않는 P2P 통신을 지향하여 압도적인 실시간성을 보여줍니다. Google Meet, Zoom, Discord 등이 모두 WebRTC를 기반으로 합니다.
왜 중요한가?: 이 기술의 등장은 '보는' 비디오를 넘어, '참여하고 소통하는' 비디오 서비스 시대를 열었습니다. 모든 엔지니어 직군에게 새로운 기회를 제시하는 핵심 기술입니다.
코덱 (CODEC): "영상의 부피를 줄이는 압축의 마법"
역할: 프로토콜이 '배송 방식'이라면, 코덱은 '내용물을 진공 포장하는 기술'입니다. 원본 영상을 화질 손실은 최소화하면서 용량은 획기적으로 줄여주는 역할을 합니다.
왜 중요한가?: 코덱의 압축률이 높을수록 사용자는 더 적은 데이터로 더 좋은 화질을 경험할 수 있습니다. 이는 통신비 절감과 직결되며, 낮은 대역폭 환경에서도 원활한 스트리밍을 가능하게 합니다.
종류: H.264(가장 보편적), HEVC/H.265(H.264보다 압축률 높음), 그리고 최근 구글, 넷플릭스 등이 밀고 있는 AV1(로열티 없는 고효율 오픈소스 코덱)이 있습니다. AV1의 등장은 기술 생태계에 큰 변화를 주고 있습니다.
CDN (Content Delivery Network): "전 세계 우리 동네 앞 물류창고"
역할: 프로토콜이 '배송 방식', 코덱이 '포장 기술'이라면, CDN은 '효율적인 물류 시스템' 그 자체입니다.
왜 중요한가?: 넷플릭스가 한국의 시청자에게 미국 본사 서버에서 직접 영상을 보내주지 않습니다. 대신, 전 세계 곳곳에 위치한 CDN 캐시 서버(물류창고)에 영상 파일(.ts, .mp4)을 미리 복사해 둡니다.
효과: 사용자가 영상을 요청하면, 물리적으로 가장 가까운 CDN 서버에서 영상을 보내줍니다. 이 덕분에 로딩 속도(Latency)가 비약적으로 빨라지고, 수백만 명이 동시에 접속해도 넷플릭스 본사 서버가 다운되지 않는 것입니다. 백엔드, 프론트엔드 개발자 모두에게 CDN의 동작 원리 이해는 필수적입니다.
