방송이 끊기는 진짜 이유 - CDN과 스트리밍 서버 구조 이해하기
인터넷은 빠른데 방송만 끊긴다면, 문제는 내 컴퓨터가 아니라 그 사이 어딘가에 있을 수 있습니다. CDN부터 엣지 서버까지, 스트리밍 인프라의 구조를 알기 쉽게 풀어봅니다.
내 화면이 시청자에게 도달하는 여정
OBS에서 '방송 시작'을 누른 순간부터 시청자 화면에 영상이 나타나기까지, 데이터는 놀라울 정도로 복잡한 경로를 거칩니다. 이 여정을 이해하면 "왜 끊기는지"를 스스로 진단할 수 있게 됩니다.
여정은 크게 5단계입니다.
- 인코딩: OBS가 게임 화면과 오디오를 압축된 영상 데이터로 변환합니다.
- 업로드: 압축된 데이터가 인터넷을 통해 플랫폼의 수신 서버(Ingest Server)로 전송됩니다.
- 트랜스코딩: 수신 서버가 원본 영상을 여러 화질(1080p, 720p, 480p 등)로 변환합니다.
- CDN 분배: 변환된 영상이 전 세계 CDN 서버로 복제됩니다.
- 시청자 수신: 시청자와 가장 가까운 CDN 서버에서 영상을 받아 재생합니다.
이 5단계 중 어느 하나라도 병목이 생기면 끊김이 발생합니다. 스트리머가 직접 제어할 수 있는 건 1단계(인코딩)와 2단계(업로드)뿐이고, 3~5단계는 플랫폼과 시청자 환경에 달려 있습니다. 하지만 구조를 알면 문제 구간을 특정할 수 있고, 플랫폼 측 이슈인지 내 측 이슈인지 구분할 수 있습니다.
CDN이 하는 일 - 택배로 이해하기
CDN(Content Delivery Network)을 택배 시스템에 비유하면 이해하기 쉽습니다.
트위치 본사가 미국 샌프란시스코에 있다고 가정합시다. 한국 시청자 100만 명이 모두 샌프란시스코 서버에 직접 접속하면 어떻게 될까요? 서버가 감당할 수 없는 트래픽이 몰리고, 한국에서 미국까지 데이터가 태평양을 건너는 시간만 100ms 이상 걸립니다.
CDN은 이 문제를 해결합니다. 전 세계 주요 도시에 '배송 거점(엣지 서버, Edge Server)'을 두고, 원본 영상의 복사본을 각 거점에 배포합니다. 한국 시청자는 서울이나 부산에 있는 엣지 서버에서 영상을 받습니다. 미국까지 갈 필요가 없으니 지연이 줄고, 하나의 서버에 트래픽이 집중되지 않으니 안정적입니다.
주요 스트리밍 플랫폼의 CDN 구성을 살펴보면, 트위치는 자체 CDN과 함께 Amazon CloudFront를 사용합니다(트위치가 아마존 소유이므로). 유튜브는 Google의 글로벌 네트워크와 자체 캐시 서버를 활용합니다. Google은 주요 ISP의 데이터센터 안에 캐시 서버를 직접 설치해서 시청자와의 물리적 거리를 극도로 줄입니다. 치지직은 네이버클라우드 인프라를 기반으로 국내에 엣지 서버를 운영합니다.
끊김이 발생하는 4가지 구간
구간 1: 인코딩 과부하
OBS가 실시간으로 영상을 압축하지 못하면 프레임이 누락됩니다. OBS 하단 상태 표시줄에 "인코딩 과부하" 경고가 나타나면 이 구간에서 문제가 발생한 것입니다. 해결법은 인코더 프리셋을 가볍게 변경하거나(x264 fast → veryfast), 하드웨어 인코더(NVENC)로 전환하거나, 출력 해상도를 낮추는 것입니다.
OBS 통계 창('보기' → '통계')에서 '건너뛴 인코딩 프레임'이 증가하면 인코딩 과부하입니다. '드랍된 프레임(네트워크)'과는 다른 항목이므로 구분해서 확인하세요.
구간 2: 업로드 경로
인코딩된 데이터가 플랫폼 서버에 도달하지 못하면 드랍 프레임이 발생합니다. OBS 통계 창에서 '드랍된 프레임(네트워크)' 비율이 0% 이상이면 업로드 경로에 문제가 있습니다.
원인은 다양합니다. 업로드 속도 부족(비트레이트보다 실제 업로드 속도가 낮음), ISP의 네트워크 혼잡(저녁 시간대 피크), 플랫폼 수신 서버의 일시적 과부하, 라우팅 문제(데이터가 비효율적인 경로로 돌아가는 것).
구간 3: 플랫폼 내부 처리
스트리머의 영상이 서버에 잘 도착했지만 트랜스코딩(다중 화질 변환)이나 CDN 분배 과정에서 지연이 생길 수 있습니다. 이 경우 스트리머 측에서는 아무 문제가 보이지 않지만 시청자만 끊김을 경험합니다. 대규모 이벤트(인기 게임 출시, 대형 스트리머 방송)로 플랫폼 전체 트래픽이 급증할 때 발생하기 쉽습니다.
구간 4: 시청자 측
시청자의 인터넷이 느리거나 불안정하면 영상 데이터를 제때 받지 못합니다. 이 경우 특정 시청자만 끊김을 보고하고 다른 시청자는 정상적으로 시청합니다. 스트리머가 해결할 수 있는 부분은 아니지만, 다중 화질 옵션을 제공(트위치 파트너/제휴 채널)하면 시청자가 낮은 화질로 전환해서 시청할 수 있습니다.
플랫폼별 인프라 차이가 만드는 품질 차이
같은 인터넷 환경에서 플랫폼에 따라 방송 안정성이 다른 이유는 인프라 규모와 구조의 차이 때문입니다.
유튜브
Google이 보유한 글로벌 네트워크는 압도적입니다. 전 세계 ISP 내부에 Google Global Cache 서버를 설치해서 시청자와 서버 사이의 홉(hop, 데이터가 거치는 중간 장비 수)을 최소화합니다. 한국에서 유튜브 라이브가 안정적인 이유는 데이터가 해외까지 나가지 않고 국내 캐시 서버에서 바로 전달되기 때문입니다.
트위치
Amazon 인프라를 기반으로 하지만, 한국에는 수신 서버가 제한적입니다. 한국 스트리머의 데이터가 일본이나 동남아 서버로 우회하는 경우가 있어, OBS에서 수신 서버를 수동 선택하는 것이 중요합니다. Twitch Inspector(inspector.twitch.tv)에서 서버별 연결 상태를 테스트할 수 있습니다.
치지직
네이버클라우드 기반으로 국내 인프라는 탄탄하지만, 해외 시청자에게는 불리할 수 있습니다. 국내 시청자 대상의 방송이라면 안정성이 매우 좋은 편입니다.
끊김 원인 진단하고 해결하기
끊김이 발생했을 때 원인 구간을 특정하는 체크리스트입니다.
1단계: OBS 통계 창 확인
'보기' → '통계'를 열어서 두 수치를 확인합니다.
- '건너뛴 인코딩 프레임' 증가 → 인코딩 과부하 (구간 1)
- '드랍된 프레임(네트워크)' 증가 → 업로드 문제 (구간 2)
- 둘 다 0%인데 시청자만 끊긴다고 함 → 플랫폼 또는 시청자 측 문제 (구간 3, 4)
2단계: 인코딩 과부하인 경우
작업 관리자에서 CPU/GPU 사용률을 확인합니다. CPU가 90% 이상이면 소프트웨어 인코더 부하가 과한 것입니다. 해결: 하드웨어 인코더로 변경, 출력 해상도 하향, 게임 그래픽 옵션 조정.
3단계: 네트워크 드랍인 경우
speedtest.net에서 업로드 속도를 측정합니다. 비트레이트의 1.5배 미만이면 비트레이트를 낮추세요. 속도가 충분한데도 드랍이 발생하면 서버를 변경해봅니다. OBS '설정' → '방송'에서 서버를 수동 선택하고, 다른 지역 서버로 테스트합니다.
traceroute 명령어로 데이터 경로를 확인할 수도 있습니다. Windows 명령 프롬프트에서 "tracert live-sel.twitch.tv" 같은 명령을 실행하면 데이터가 어떤 경로로 가는지, 어디서 지연이 발생하는지 볼 수 있습니다.
4단계: 플랫폼 측 문제인 경우
Downdetector(downdetector.com)에서 해당 플랫폼의 장애 현황을 확인합니다. 다수의 사용자가 동시에 문제를 보고하고 있다면 플랫폼 측 이슈입니다. 이 경우에는 기다리는 것 외에 할 수 있는 게 없습니다. 트위치의 경우 status.twitch.tv에서 실시간 서비스 상태를 확인할 수 있습니다.
끊김의 원인은 대부분 이 네 가지 구간 중 하나에 있습니다. 체계적으로 진단하면 막연히 "왜 끊기지?"라고 고민하는 시간을 크게 줄일 수 있습니다.
