들어가기 전에

StreamLive 글에서 “DRM이나 오리진은 어디서 처리하나”라는 질문이 자연스럽게 나온다. 답은 대체로 StreamPackage 쪽이다.

StreamPackage는 라이브 스트림을 받아 HLS나 DASH 엔드포인트로 패키징하고, CDN이 가져갈 수 있는 오리진 역할을 제공하는 서비스다. 여기에 DRM, SSAI, time-shift, harvest job, channel assembly까지 붙는다.

AWS로 치면 Elemental MediaPackage에 가까운 포지션이다. StreamLive가 인코딩 채널이라면 StreamPackage는 패키저와 오리진이다. 인코더가 재료를 굽고, StreamPackage가 포장해서 진열대에 올리는 느낌이다.

파이프라인에서의 위치

StreamPackage는 StreamLive 뒤쪽, CSS/CDN 앞쪽에 놓이는 경우가 많다.

StreamLive가 트랜스코딩과 출력 생성을 담당한다면, StreamPackage는 그 출력을 받아 플레이어와 CDN이 가져갈 수 있는 형태로 정리한다.

공식 문서에서는 StreamPackage를 channel, input, endpoint, CDN 네 구간으로 설명한다. 이게 구조를 이해하는 핵심이다.

채널, 입력, 엔드포인트

StreamPackage는 채널 단위로 관리된다. 채널은 입력과 엔드포인트를 담는 기본 단위다.

공식 Channel Management 문서 기준으로 StreamPackage 채널은 HLS와 DASH 입력 프로토콜을 지원한다. 채널을 만들면 해당 채널의 입력 정보가 생성되고, 채널 안에서 endpoint를 만들어 시청 또는 CDN pull에 사용할 수 있다.

채널에는 HLS TS segment나 DASH M4S segment의 max segment duration, playlist duration 같은 값이 있다. 공식 문서의 기본값은 segment 15초, playlist 600초로 설명된다. primary와 backup 두 스트림을 보내 failover를 구성할 때는 segment duration을 실제보다 약간 길게 잡으라는 권고도 있다.

이런 값은 그냥 숫자 같지만, 운영에서는 꽤 중요하다. segment duration을 너무 짧게 잡으면 요청 수와 manifest 갱신 부담이 늘고, 너무 길게 잡으면 latency와 장애 감지가 둔해진다. 결국 세그먼트는 영상 파일 조각이 아니라 운영자의 혈압 조절 장치다.

Endpoint가 실제 오리진 URL이다

Endpoint는 채널에서 만들어지는 pull 지점이다. CDN이나 플레이어는 이 endpoint를 통해 manifest와 segment를 가져간다.

공식 문서 기준 endpoint type은 기본적으로 채널 input protocol과 같고, HLS 입력의 경우 CMAF-DASH나 CMAF-HLS endpoint도 만들 수 있다. 즉 HLS 입력을 받아 CMAF 계열 출력으로 remuxing하는 구성이 가능하다.

Endpoint 단위로 다음 설정을 붙일 수 있다.

여기서 중요한 건 endpoint 단위 설정이라는 점이다. 같은 입력 스트림이라도 DRM 적용 endpoint와 내부 테스트용 endpoint를 분리할 수 있다. 운영에서는 이 분리가 꽤 유용하다. 하나의 URL에 모든 요구사항을 때려 넣으면, 나중엔 그 URL을 아무도 못 건드리는 유물이 된다.

CDN 연동 (CSS)

그러나 일반적으로 라이브 오리진의 주소를 그대로 최종 사용자에게 제공하는 경우는 거의 없다. 오리진 주소가 외부에 노출될 경우 비인가 접근이나 과도한 트래픽 집중 등의 위험이 존재하기도 하지만, 더 중요한 이유는 라이브 오리진이 대규모 시청자를 직접 수용하도록 설계된 시스템이 아니기 때문이다. 수만~수십만 명 이상의 사용자가 동시에 접속하는 환경에서는 CDN을 통해 콘텐츠를 분산 배포해야 안정적인 서비스 품질과 확장성을 확보할 수 있다.

이러한 경우 Tencent Cloud의 통합 라이브 스트리밍 솔루션인 CSS (Cloud Streaming Services) 에서 제공하는 CSS CDN을 연동하여 서비스를 제공할 수 있다. 또한 이미 타 CDN 사업자를 사용하고 있거나 멀티 CDN(Multi-CDN) 구조를 운영하는 경우에는 CSS CDN을 중간 계층으로 활용하는 것도 가능하다. 예를 들어 StreamPackage → CSS CDN → Third-party CDN → Viewer 형태의 구성도 지원할 수 있다.

타 CDN 환경에서도 일반적으로 StreamPackage Endpoint를 CDN의 직접적인 오리진으로 사용하기보다는 CSS CDN을 한 단계 앞단에 두는 구성이 선호된다. 이는 CDN 간 캐시 계층(Cache Hierarchy)을 구성하여 오리진 요청 수를 최소화할 수 있을 뿐만 아니라, Origin Shield 역할을 수행하여 오리진 부하를 줄이고 장애 전파 범위를 제한할 수 있기 때문이다. 또한 인증(Authentication), 접근 제어, 로그 수집, 트래픽 분석, 멀티 CDN 전환 등의 기능도 CDN 계층에서 보다 유연하게 구현할 수 있다.

결과적으로 StreamPackage는 패키징과 오리진 기능에 집중하고, 대규모 사용자 트래픽 처리와 글로벌 배포는 CDN 계층이 담당하는 역할 분리가 일반적인 서비스 아키텍처라고 볼 수 있다.

DRM과 Multi-DRM

StreamPackage는 DRM/Multi-DRM 구성을 지원한다. 공식 Multi-DRM 문서 기준으로 Widevine, PlayReady, FairPlay를 지원하고, CPIX 프로토콜을 지원하는 DRM provider와 연동한다. Key rotation도 지원한다. 다만 조건이 있다. 공식 문서에서는 현재 StreamPackage DRM 구성이 CMAF-DASH 또는 CMAF-HLS 타입 endpoint에서만 가능하다고 설명한다.

DRM은 “체크박스 켜면 보호됨” 같은 기능이 아니다. 플레이어, license server, key server, endpoint type, manifest, client SDK가 다 맞아야 한다. 하나만 삐끗하면 시청자는 검은 화면을 보고, 개발자는 DRM 로그를 보면서 인간성을 잃는다. DRM은 Tencent cloud에서 제공하는 DRM벤더를 이용해도 되지만, 일반적으로 doverunner 같은 멀티DRM 서비스를 연동하는 것이 좋다. DRM은 상당히 복잡하므로, 다른 글에서 더 자세히 다루기로 한다.

SSAI는 manifest를 만지는 기능이다

StreamPackage는 서버 사이드 광고 삽입(SSAI)을 지원한다. 공식 SSAI 문서 기준으로 플레이어가 manifest를 요청하면 StreamPackage가 origin manifest를 가져오고, SCTE-35 ad marker를 확인해 광고 삽입을 처리한다.

이 구조에서 핵심은 광고가 플레이어 SDK에서만 끼워지는 게 아니라, 서버 쪽에서 manifest와 세그먼트 흐름에 끼어든다는 점이다.

SSAI가 잘 동작하려면 앞단에서 SCTE-35 marker가 살아서 와야 한다. StreamLive가 marker를 전달하고, StreamPackage가 이를 해석해 광고 결정 서버와 연결한다. 여기서 marker가 빠지면 광고 삽입 타이밍도 사라진다. 시스템은 멀쩡히 돌아가는데 광고가 안 붙는, 제일 귀찮은 종류의 장애가 된다. 광고는 곧 돈이고, 돈과 관련된 기술은 매우 민감하고 복잡하므로 SSAI 역시 별도의 글에서 더 자세히 다루기로 한다.

Harvest Job과 Time-shift

Harvest Job은 라이브 스트림의 과거 특정 구간을 VOD 자산으로 추출하는 기능이다. 공식 문서 기준으로 harvest job은 endpoint에서 특정 timeframe을 추출하는 요청이고, 생성 후 한 번 실행된다.

중요한 제약도 있다.

• harvest job은 endpoint의 startover window 안에 있어야 한다.

• 추출 구간은 최대 24시간을 넘을 수 없다.

• 저장 대상은 Tencent Cloud COS를 사용한다.

• 완료 후 callback URL로 성공/실패 상태를 받을 수 있다.

이 기능은 스포츠 하이라이트, 방송 다시보기, 특정 프로그램 단위 아카이브에 적합하다. 라이브를 통째로 녹화한 뒤 사람이 잘라내는 방식보다 운영 자동화에 가깝다.

Channel Assembly와 FAST

StreamPackage에는 Channel Assembly 기능도 있다. 공식 문서 기준으로 여러 VOD 소스와 라이브 소스를 사용자가 정한 순서로 배열해 linear streaming channel로 변환하는 기능이다. FAST 채널 구현이 대표적인 사용 사례다.

Channel Assembly의 핵심 개념은 Source Location, Channel, Program이다.

Channel type도 Basic과 Standard로 나뉜다. Basic은 VOD source만 지원하고, Standard는 VOD와 Live source를 모두 지원한다. 재생 모드는 Program Scheduled List를 반복하는 Loop와 순서대로 실행하는 Linear가 있다. 이 기능은 “VOD 파일 여러 개를 이어 붙여 24시간 채널처럼 내보내는” 요구에 맞다. 인코더 없이 FAST 채널을 만들 수 있다는 점이 핵심이다.

그리고 StreamLive가 아닌 다른 인코더의 입력을 직접 StreamPackage로 받고 싶을 때 선택할 수 있는 사실상 유일한 옵션이기도 하다. 일부 인코더나 방송 장비는 RTMP Push와 같은 일반적인 라이브 송출 방식 대신 HLS Pull 형태만 지원하는 경우가 있는데, StreamPackage는 본래 라이브 인코더가 직접 신호를 Push하는 구조를 제공하지 않는다. 따라서 이러한 환경에서는 Channel Assembly 기능을 활용하여 HLS Source를 Source Location으로 등록하고, 이를 Program에 편성하여 채널 형태로 출력할 수 있다.

즉, 원래는 FAST 채널이나 가상 채널(Virtual Channel) 구성을 목적으로 설계된 기능이지만, 결과적으로는 외부 HLS Source를 StreamPackage로 유입시키는 우회적인 Ingest 수단으로도 활용할 수 있다. 특히 AWS MediaPackage와 유사한 구조를 가진 StreamPackage 특성상 일반적인 Live Input 기능이 제한적인 상황에서, Channel Assembly는 외부 Pull 기반 콘텐츠를 StreamPackage 생태계 안으로 가져올 수 있는 중요한 연결 고리 역할을 수행한다.

결과적으로 Channel Assembly는 FAST 채널 기능뿐 아니라, Pull 방식만 지원하는 외부 소스를 StreamPackage에 연동하기 위한 실질적인 대안으로 활용될 수 있다.

언제 쓰면 좋을까

StreamPackage는 이런 경우에 잘 맞는다.

• StreamLive 출력물을 HLS/DASH 오리진으로 안정적으로 제공해야 할 때

• DRM/Multi-DRM을 적용해야 할 때

• SCTE-35 기반 SSAI가 필요할 때

• Live-to-VOD 하이라이트나 아카이브를 자동 생성해야 할 때

• FAST 같은 linear channel assembly가 필요할 때

• CDN 앞단에 origin resilience를 두고 싶을 때

반대로 단순한 라이브 배포라면 CSS만으로 충분할 수 있다. StreamPackage는 패키징, DRM, SSAI, 오리진 요구가 있을 때 의미가 크다. 복잡한 기능을 미리 다 켜두면 나중에 운영자가 설정 화면에서 길을 잃는다.

정리

StreamPackage는 단순한 패키저가 아니다. HLS/DASH endpoint를 만들고, DRM과 SSAI를 붙이고, live-to-VOD harvest와 Channel Assembly까지 처리하는 미디어 오리진 플랫폼에 가깝다.

StreamLive가 “라이브 신호를 어떻게 가공할 것인가”의 문제라면, StreamPackage는 “가공된 스트림을 어떻게 안전하고 유연하게 제공할 것인가”의 문제다. 이 둘을 분리해서 보면 Tencent Cloud 미디어 파이프라인의 역할이 훨씬 선명해진다.

참고 : Tencent cloud Streampacakge https://www.tencentcloud.com/document/product/1063?lang=en