VPS vs 관리형 클라우드 서비스: 24시간 라이브 방송 비교
FFmpeg로 VPS에서 24시간 라이브 방송을 돌리는 건 간단해 보이지만, 재생목록이 처음부터 다시 시작되거나 밤새 프로세스가 죽거나 송출 대상을 하나 추가하는 순간 아웃바운드 트래픽이 두 배가 됩니다. 직접 운영(DIY)이 실제로 어떤 일인지, 그리고 언제 관리형 서비스가 더 합리적인지 정리했습니다.
읽는 데 약 6분
이 페이지의 내용
VPS에서 FFmpeg로 24시간 라이브 방송을 운영하는 것은 충분히 가능합니다. 임대한 서버에 영상을 올리고, concat 재생목록을 작성한 뒤 플랫폼의 RTMP URL로 반복 송출하면 됩니다. 실제로 작동하고, 좋은 학습 프로젝트가 될 수도 있습니다. 진짜 비용은 여러분의 시간입니다. 인코딩, 장애 복구, 모니터링, 대역폭 계획에 그 시간이 들어갑니다.
DIY가 실제로 무엇을 요구하는지, 그리고 언제 관리형 서비스가 여러분의 시간을 더 잘 쓰는 방법인지 살펴보겠습니다.
핵심 요약
- 기본적인 FFmpeg 반복 송출은 금방 만들 수 있지만, 몇 달 동안 계속 돌아가게 하는 것이 진짜 일입니다.
- 프레임 레이트나 타임스탬프가 맞지 않으면 copy 모드 재생목록이 멈추고 처음부터 다시 시작될 수 있습니다.
- FFmpeg는 스스로 재시작하지도, 여러분에게 알림을 보내지도 않습니다.
- 송출 대상을 하나 추가할 때마다 전체 비트레이트만큼 아웃바운드 트래픽이 늘어납니다.
DIY VPS 구성은 어떤 모습일까
일반적인 셀프 호스팅 구성은 네 부분으로 이루어집니다.
- Linux VPS: 영상 라이브러리를 담을 디스크 공간과, 절대 멈추지 않는 방송을 위한 아웃바운드 전송량이 필요합니다.
- 영상 파일: SFTP로 업로드하거나 스토리지에서 동기화합니다.
- 재생목록 파일: FFmpeg의 concat 디먹서가 읽는 파일입니다.
- FFmpeg 명령어: 재생목록을 실시간 속도로 읽고, 반복하며,
rtmp://a.rtmp.youtube.com/live2같은 인제스트 URL과 스트림 키로 송출합니다.
대부분의 튜토리얼은 stream copy 모드를 사용합니다. FFmpeg가 영상과 오디오를 다시 인코딩하지 않고 그대로 전달하는 방식이죠. CPU 사용량이 아주 적어서 작은 서버로도 충분하고, 첫 방송은 정말 빠르게 띄울 수 있습니다.
문제는 copy 모드가 모든 파일의 기술 사양이 일치할 때만 매끄럽게 돌아간다는 점입니다. 장기적인 노력은 바로 여기에 들어갑니다.
인코딩과 타임스탬프: FFmpeg 재생목록이 다시 시작되는 이유
stream copy에서는 FFmpeg가 파일을 있는 그대로 이어 붙이기 때문에, 이상한 파일 하나가 이음새를 망가뜨립니다. 흔한 원인은 다음과 같습니다.
- 프레임 레이트 불일치: 30 fps 파일 사이에 섞인 29.97 fps 내보내기 파일, 또는 가변 프레임 레이트(VFR)로 녹화된 휴대폰 영상 등.
- 다른 해상도나 오디오 형식: 1080p 파일들 사이에 섞인 720p 클립 같은 경우.
- 특이한 타임베이스나 누락된 타임스탬프: 일부 편집 프로그램이나 화면 녹화 도구가 남기는 문제입니다.
증상은 로그 경고부터 멈춘 화면, FFmpeg 종료까지 다양합니다. 재시작되면 재생목록이 첫 번째 영상부터 다시 시작되므로, 시청자는 같은 첫 한 시간을 반복해서 보게 됩니다.
해결책은 재생목록에 넣기 전에 모든 파일을 하나의 프로필로 다시 인코딩하는 것입니다. 해상도, 고정 프레임 레이트, 키프레임 간격, 오디오 형식을 모두 동일하게 맞추세요. 자세한 내용은 24시간 스트리밍을 위한 인코딩 설정을 참고하세요.
장애, 재시작, 모니터링을 모두 직접 해야 한다
FFmpeg는 훌륭한 도구지만, 살아 있어야 한다는 개념이 없는 단일 프로세스일 뿐입니다. 플랫폼이 연결을 끊거나, 네트워크가 잠깐 흔들리거나, 파일 하나가 오류를 일으키면 그냥 종료되고, 다음을 직접 구축해 두지 않았다면 아무것도 다시 살려 주지 않습니다.
- 프로세스 감시자(supervisor): 자동 재시작이 설정된 systemd 서비스 등.
- 재생 위치 추적: 재시작해도 재생목록이 맨 처음부터 시작되지 않도록.
- 상태 점검(헬스 체크): 프로세스가 실행 중이어도 방송은 오프라인으로 보일 수 있으므로, 플랫폼이 실제로 영상을 받고 있는지 확인해야 합니다.
- 알림: 새벽 3시에 끊긴 방송이 아침 식사 시간까지 이어지지 않도록 휴대폰으로 알림을 받아야 합니다.
여기에 유지보수도 있습니다. 업데이트, 재부팅, 로그로 가득 차는 디스크, 스크립트에 평문으로 저장된 스트림 키까지요. 하나하나는 어렵지 않지만, 모두 합치면 파트타임 일이 됩니다. 무엇을 지켜봐야 하는지는 방송 상태와 가동 시간 모니터링에서 확인하세요.
하나의 서버에서 대역폭과 여러 송출 대상 관리하기
쉬지 않는 방송은 생각보다 훨씬 많은 데이터를 사용합니다. 6 Mbps 방송 하나를 30일 동안 돌리면 약 1.9 TB를 송출합니다. 이를 세 플랫폼으로 보내면 서버는 24시간 내내 약 18 Mbps를 내보내고, 한 달에 6 TB 가까이 됩니다. 호스팅 업체의 아웃바운드 전송량 한도와 초과 요금 조건을 꼭 확인하세요.
여러 곳으로 송출하는 FFmpeg에는 나름의 까다로운 점이 있습니다. 플랫폼마다 프로세스를 하나씩 띄우면 감시해야 할 프로세스가 여러 개가 됩니다. FFmpeg의 tee 먹서는 하나의 입력을 여러 출력으로 보낼 수 있지만, 각 출력이 실패를 견디도록 설정하지 않으면 오래된 키를 플랫폼이 거부하는 것처럼 송출 대상 하나만 실패해도 프로세스 전체가 멈출 수 있습니다.
플랫폼별 특이사항도 여러분 몫입니다. 예를 들어 단순 반복 송출은 YouTube의 12시간 보관 제한을 전혀 고려하지 않습니다.
DIY VPS 방송이 올바른 선택인 경우
다음 조건 대부분에 해당한다면 셀프 호스팅이 잘 맞습니다.
- Linux 명령줄이 익숙하고 시스템 관리를 즐긴다.
- 송출 대상이 하나뿐이거나, 여러 곳에 대한 장애 처리를 직접 설계할 의향이 있다.
- 영상 라이브러리가 작고 자주 바뀌지 않으며, 모든 파일의 내보내기 방식을 직접 통제한다.
- 가끔 재생목록이 처음부터 다시 시작되어도 시청자에게 큰 문제가 되지 않는다.
- 스트리밍이 내부적으로 어떻게 작동하는지 배우고 싶다.
반면 방송이 수익이나 브랜드를 뒷받침하거나, 영상을 자주 추가하거나, 여러 플랫폼이 필요하거나, 시간을 콘텐츠에 쓰는 편이 낫다면 관리형 서비스가 더 합리적입니다. 공정한 비교는 서버 요금에 설정 시간과 한밤중 수리 시간을 더한 값과, 이미 그 문제들을 해결해 둔 서비스를 비교하는 것입니다.
같은 24시간 반복 방송을 StreamHouse에서 운영하기
StreamHouse는 위 구성의 모든 요소를 대신합니다. 업로드한 영상은 미리 하나의 일관된 인코딩 프로필로 준비되어 비트레이트와 타임스탬프가 안정적으로 유지되므로, 사양이 다른 파일 때문에 재생목록이 다시 시작되는 일이 없습니다. 브라우저에서 재생목록을 만들고, YouTube, Twitch, Rumble, Facebook, 사용자 지정 RTMP 또는 SRT 같은 송출 대상을 추가한 뒤 시작을 누르거나 시간을 예약하면 됩니다.
반복 방송은 클라우드에서 24시간 돌아가며, 플랫폼이나 네트워크에 문제가 생겨도 자동으로 다시 연결됩니다. 방송 중에도 영상을 추가, 삭제하거나 순서를 바꿀 수 있고, 변경 사항은 다음 영상부터 적용됩니다. 송출 대상을 추가해도 방송 슬롯을 더 쓰지 않으며, 연결된 YouTube 채널의 경우 녹화 보호 기능이 원하는 시점에 첫 번째 방송을 종료하고 재생목록을 다시 시작하지 않은 채 새 방송으로 이어 갈 수 있습니다.
구독 요금제와 종량제 크레딧은 요금 페이지에서 비교해 보세요.
자주 묻는 질문
VPS에서 FFmpeg로 YouTube 24시간 라이브 방송을 할 수 있나요?
네, 가능합니다. YouTube의 RTMP URL을 향하는 반복 FFmpeg 명령어만 있으면 채널을 라이브 상태로 유지할 수 있습니다. 어려운 부분은 몇 주 동안 건강하게 유지하는 것입니다. 일관된 인코딩, 자동 재시작, 모니터링, 장시간 방송 보관까지 모두 직접 챙겨야 합니다.
FFmpeg 재생목록이 계속 처음부터 다시 시작되는 이유는 무엇인가요?
대부분 파일 하나가 나머지와 맞지 않기 때문입니다. 프레임 레이트, 해상도, 오디오 형식이 다른 경우죠. copy 모드에서는 타임스탬프가 깨지고, FFmpeg가 종료된 뒤 첫 번째 영상부터 다시 시작합니다. 모든 파일을 하나의 고정된 프로필로 다시 인코딩하세요.
24시간 라이브 방송은 한 달에 대역폭을 얼마나 사용하나요?
6 Mbps 방송 하나를 30일 동안 쉬지 않고 돌리면 약 1.9 TB이며, 비트레이트가 높거나 송출 대상이 많으면 그에 비례해 늘어납니다. 같은 비트레이트로 세 플랫폼에 보내면 6 TB 가까이 되므로, 먼저 서버의 전송량 한도를 확인하세요.
24시간 방송을 하려면 고성능 VPS가 필요한가요?
파일을 미리 인코딩하고 stream copy를 사용한다면 필요 없습니다. CPU를 거의 쓰지 않기 때문입니다. 하지만 서버에서 1080p를 실시간 인코딩하는 경우는 다릅니다. 전용 코어가 필요하고, 작은 공유 요금제로는 실시간 속도를 따라가지 못하는 경우가 많습니다.
