DEVOCEAN

모바일 라이브커머스(MLC) 시장이 커지면서 방송 편성 횟수와 동시 시청자 트래픽이 빠르게 증가하고 있습니다. 방송이 하루 한두 개에 불과할 때는 AWS IVS(Interactive Video Service, 대화형 라이브 스트리밍 완전관리형 서비스) 같은 완전관리형 PaaS(서비스형 플랫폼)를 쓰는 것이 가장 빠르고 간편합니다. 스트림 키만 발급받아 인제스트(Ingest, 영상 입력) 엔드포인트로 영상을 쏘아 올리면 트랜스코딩부터 전송까지 클라우드가 알아서 처리하기 때문입니다.

하지만 방송 편성이 하루 수십 편으로 늘어나고, 원본 라이브 영상을 재가공해 재방송 편성을 정규화하는 단계에 이르면 상황이 달라집니다. 완전관리형 서비스는 인코딩 프로파일을 미세하게 제어하기 어렵고, 비디오와 오디오 트랙을 규격화하여 VOD(주문형 비디오) 및 재방송 스트림으로 연결하는 파이프라인을 커스텀하기에 제약이 많습니다.

오늘 살펴볼 소식은 CJ온스타일이 모바일 라이브커머스 송출 인프라를 AWS IVS에서 자체 AWS Elemental Live 어플라이언스를 도입한 파이프라인으로 전환하고, 연이어 재방송 송출 자동화 파이프라인을 구축한 사례입니다. 관리형 클라우드 서비스에서 온프레미스 하드웨어 어플라이언스를 결합한 하이브리드 스트리밍 인프라로 내려온 이유와, 이를 통해 재방송 운영을 어떻게 자동화했는지 살펴봅니다.

완전관리형 IVS에서 Elemental Live 어플라이언스로 전환한 이유

라이브커머스 플랫폼 초기에는 개발팀의 미디어 전문 지식이 부족하더라도 즉시 송출이 가능한 AWS IVS가 훌륭한 선택지입니다. IVS는 RTMP(Real-Time Messaging Protocol, 실시간 메시징 프로토콜) 입력을 받아 ABR(Adaptive Bitrate Streaming, 네트워크 대역폭에 맞춰 화질을 조절하는 적응형 비트레이트) HLS 스트림을 자동으로 생성해 줍니다. 인프라 운영 부담이 거의 없습니다.

하지만 서비스 규모가 커지면서 세 가지 한계가 드러납니다. 첫째는 트랜스코딩 세부 파라미터의 제어권 부족입니다. 인코더의 GOP(Group of Pictures, 화면 간 압축을 묶는 프레임 단위) 크기나 비트레이트 할당 정책, 프레임률, 코덱 프로파일을 서비스 플랫폼의 UX(사용자 경험) 요구사항에 맞게 정밀하게 튜닝할 수 없습니다. 둘째는 송출 신뢰성과 지연 시간(Latency) 제어입니다. 방송 스튜디오 현장의 네트워크 변동성이나 카메라 SDI(Serial Digital Interface, 방송용 디지털 비디오 전송 규격) 입력 신호를 클라우드로 직접 올리는 과정에서 발생하는 패킷 손실을 하드웨어 수준에서 복구하기 어렵습니다.

셋째는 비용과 확장성입니다. 완전관리형 서비스는 방송 시간과 시청 시간당 과금 체계가 고정되어 있어, 방송 편성이 급증할수록 단위 비용 절감 효과를 보기 어렵습니다. CJ온스타일 MLC 팀이 모바일 라이브커머스 송출 파이프라인 다시 설계하기에서 밝힌 핵심 배경도 여기에 있습니다. 방송 편성이 지속적으로 증가하고 동시 사용자 수가 늘어남에 따라, 클라우드 완전관리형에만 의존하던 방식에서 벗어나 하드웨어 인코더 어플라이언스인 AWS Elemental Live를 자체 스튜디오 인프라에 직접 도입하기로 결정했습니다.

여기서 AWS Elemental Live는 방송국 및 전문 송출 환경에서 주로 사용하는 온프레미스 랙마운트 하드웨어 어플라이언스입니다. SDI나 고대역 비압축 IP 비디오 신호를 직접 입력받아, 내장된 전용 가속 칩을 통해 실시간으로 다중 비트레이트 H.264/HEVC 스트림으로 인코딩합니다. 이 어플라이언스는 AWS 클라우드의 미디어 서비스(AWS Elemental MediaStore, MediaPackage 등)와 API로 유기적으로 연동됩니다.

이 결정에 대한 DEVOTEE의 판단은 조건부로 유효하다입니다. 모바일 커머스 플랫폼이 자체 스튜디오를 운영하고 하루 고정 방송 편성이 5~10회 이상 일정 궤도에 오른 팀에게는 화질 균일화와 전송 지연 단축, 중장기 인프라 비용 절감 효과가 뚜렷합니다. 반면, 외부 크리에이터나 셀러가 각자의 모바일 기기에서 송출하는 오픈 플랫폼 형태이거나 스튜디오 엔지니어가 없는 스타트업이라면 하드웨어 어플라이언스 도입은 유지보수 공수만 늘리는 선택이 됩니다.

어플라이언스와 클라우드가 결합된 하이브리드 파이프라인

스튜디오 현장에 AWS Elemental Live 어플라이언스를 배치하면 전체 스트리밍 파이프라인은 하이브리드 구조로 재편됩니다. 현장 카메라와 비디오 스위처에서 나오는 고품질 SDI 비디오 신호가 어플라이언스의 캡처 카드로 직접 들어갑니다.

어플라이언스 내부에서는 방송 규격에 맞춘 렌디션(Rendition, 해상도 및 비트레이트 조합) 세트를 생성합니다. 1080p60, 720p30, 480p30 등으로 인코딩된 스트림은 HLS(HTTP Live Streaming) 청크 단위로 패키징되거나, RTP/SRT(Secure Reliable Transport, 오류 복원력이 높은 스트리밍 전송 프로토콜)를 통해 클라우드의 인제스트 엔드포인트로 전송됩니다.

클라우드 단에서는 인제스트된 원본 스트림을 두 갈래로 분기합니다. 하나는 시청자 배포를 위한 오리진 서버(AWS Elemental MediaStore 또는 Amazon S3)와 CloudFront CDN(콘텐츠 전송 네트워크)으로 흘려보내고, 다른 하나는 방송 종료 후 재방송 송출과 VOD 서비스를 위해 아카이빙 스토리지에 원본 상태 그대로 저장합니다.

AWS Elemental Live는 REST API를 제공하므로, 방송 스케줄러 시스템과 연동해 방송 시작과 종료에 맞춰 자동으로 인코딩 채널을 프로비저닝하고 프로파일을 주입할 수 있습니다. 아래 예시는 어플라이언스의 REST API를 통해 특정 비디오 입력을 1080p와 720p H.264 스트림으로 인코딩하여 출력 그룹으로 내보내는 채널 생성 XML 페이로드의 기본 구조입니다.

<?xml version="1.0" encoding="UTF-8"?>
<channel>
  <name>MLC_Live_Studio_01</name>
  <input>
    <type>sdi</type>
    <sdi_settings>
      <input_format>1080i59.94</input_format>
    </sdi_settings>
  </input>
  <output_group>
    <type>hls_output_group</type>
    <hls_settings>
      <segment_duration>2</segment_duration>
      <destination_url>http://cloud-ingest.internal/live/stream1</destination_url>
    </hls_settings>
    <order>1</order>
    <output>
      <name_modifier>_1080p</name_modifier>
      <video_description>
        <codec>h.264</codec>
        <width>1080</width>
        <height>1920</height>
        <bitrate>4500000</bitrate>
        <rate_control_mode>cbr</rate_control_mode>
        <gop_size>60</gop_size>
      </video_description>
      <audio_description>
        <codec>aac</codec>
        <bitrate>128000</bitrate>
        <sample_rate>48000</sample_rate>
      </audio_description>
    </output>
    <output>
      <name_modifier>_720p</name_modifier>
      <video_description>
        <codec>h.264</codec>
        <width>720</width>
        <height>1280</height>
        <bitrate>2500000</bitrate>
        <rate_control_mode>cbr</rate_control_mode>
        <gop_size>60</gop_size>
      </video_description>
      <audio_description>
        <codec>aac</codec>
        <bitrate>96000</bitrate>
        <sample_rate>48000</sample_rate>
      </audio_description>
    </output>
  </output_group>
</channel>

여기서 모바일 라이브커머스의 세로형 화면(9:16) 규격에 맞게 너비 1080, 높이 1920 및 너비 720, 높이 1280 픽셀을 지정했습니다. GOP 크기를 60(30fps 기준 2초)으로 설정하고 HLS 세그먼트 단위를 2초로 고정함으로써 전송 지연 시간을 안정적인 저지연(Low-Latency) 수준으로 유지할 수 있습니다.

재방송 송출 자동화: 라이브 아카이브에서 가상 라이브 스트림으로

라이브커머스에서 본방송만큼 매출 비중이 큰 영역이 '재방송'입니다. 본방송이 끝난 뒤 트래픽이 높은 시간대에 녹화 영상을 마치 실시간 라이브인 것처럼 송출하는 유사 라이브(Simulated Live 또는 Linear Virtual Stream) 환경을 구성하면, 스튜디오 운영 인력을 추가로 투입하지 않고도 매출을 이어갈 수 있습니다.

하지만 모바일 라이브커머스 재방송 송출 자동화하기에 소개된 사례처럼, 기존 방식은 사람이 직접 VOD 원본 파일을 다운로드받아 편집 툴에서 앞뒤 불필요한 부분을 자르고, 인코더에 다시 수동으로 업로드하여 재생 목록을 걸어두는 형태가 많았습니다. 방송 수가 하루 수십 편으로 늘어나면 운영 담당자의 작업 병목이 발생하고, 인적 실수로 잘못된 영상이 나가거나 송출 싱크가 어긋나는 사고가 일어납니다.

CJ온스타일 팀은 이 문제를 해결하기 위해 AWS Elemental Live의 입력 소스 스케줄링 기능을 클라우드 백엔드와 연결하여 재방송 송출 파이프라인을 자동화했습니다. 본방송이 종료되는 즉시 S3 아카이브에 적재된 MP4/TS 원본을 이벤트 기반으로 감지하고, CMS(콘텐츠 관리 시스템)의 재방송 편성 스케줄에 맞춰 Elemental Live 채널의 파일 입력(File Input) 소스로 자동 등록하는 아키텍처입니다.

재방송 자동화 워크플로는 다음과 같은 단계로 실행됩니다:

1. 방송 종료 시 라이브 인코더가 미디어 아카이브 버킷에 녹화 파일과 메타데이터를 저장합니다.
2. Lambda 함수가 S3 ObjectCreated 이벤트를 수신하여 영상의 재생 길이(Duration)와 오디오 트랙 정상 여부를 검증합니다.
3. 방송 편성 API 서버가 재방송 시작 시간 10분 전에 Elemental Live 어플라이언스의 REST API를 호출하여 해당 VOD 파일 경로를 다음 재생 큐(Schedule Queue)에 등록합니다.
4. 어플라이언스는 정해진 시각에 SDI 라이브 입력 대신 S3 파일 입력을 디코딩하여 동일한 HLS 라이브 배포 엔드포인트로 연속적으로 밀어 넣습니다.

아래 스크립트는 방송 스케줄러가 Elemental Live API를 호출하여 파일 기반 재방송 입력을 예약하는 Node.js 자동화 처리의 핵심 예시입니다.

import axios from 'axios';

interface SchedulePayload {
  channelId: string;
  vodS3Uri: string;
  startTimeUtc: string;
}

export async function scheduleRebroadcast(payload: SchedulePayload): Promise<void> {
  const { channelId, vodS3Uri, startTimeUtc } = payload;
  const elementalEndpoint = `https://elemental-live.internal/api/channels/${channelId}/schedule`;

  const requestBody = `
    <schedule_entry>
      <start_time>${startTimeUtc}</start_time>
      <input>
        <type>file</type>
        <file_input>
          <uri>${vodS3Uri}</uri>
        </file_input>
      </input>
    </schedule_entry>
  `.trim();

  try {
    const response = await axios.post(elementalEndpoint, requestBody, {
      headers: {
        'Content-Type': 'application/xml',
        'Accept': 'application/xml',
      },
      timeout: 5000,
    });

    if (response.status === 201 || response.status === 200) {
      console.log(`재방송 스케줄 등록 성공: 채널 ${channelId}, 시작시각 ${startTimeUtc}`);
    }
  } catch (error) {
    console.error(`재방송 스케줄 등록 실패: ${(error as Error).message}`);
    throw error;
  }
}

이 자동화가 적용되면 클라이언트 앱(사용자 스마트폰) 입장에서는 본방송과 재방송이 기술적으로 동일한 CDN 도메인과 HLS 플레이리스트 규격으로 전송됩니다. 앱 플레이어를 재방송 전용으로 따로 분기하거나 복잡한 클라이언트 예외 로직을 짤 필요가 없어집니다.

재방송 송출 자동화에 대한 DEVOTEE의 판단은 지금 써볼 만하다입니다. VOD 아카이브를 라이브 스트림으로 재송출하는 작업은 운영 리소스를 소모하는 대표적인 반복 노동입니다. 이를 API와 스케줄러 기반으로 자동화하는 것은 라이브커머스 운영 비용을 절감하고 휴먼 에러를 방지하는 실질적인 엔지니어링 개선입니다.

실무에서 고려할 인프라 트레이드오프

완전관리형 클라우드 서비스(AWS IVS 등)에서 자체 어플라이언스(AWS Elemental Live) 중심 파이프라인으로 전환할 때는 분명한 트레이드오프를 따져보아야 합니다.

첫째는 가용성(High Availability) 확보의 책임 소재입니다. 완전관리형 서비스는 클라우드 벤더가 다중 AZ(가용 영역) 장애 복구와 리전 페일오버를 내부적으로 책임집니다. 반면 온프레미스 어플라이언스를 도입하면 하드웨어 전원 이중화, 네트워크 회선 이중화(Active-Standby), 장비 고장 시 예비 장비로 절체(Failover)하는 메커니즘을 자체 인프라 팀이 직접 구성해야 합니다.

둘째는 모니터링 경계의 확장입니다. 클라우드에서는 CloudWatch 지표만 확인하면 되지만, 어플라이언스를 운영하면 CPU 부하율, 하드웨어 온도, 팬 동작 상태, SDI 입력 신호의 비트 에러율, 내부 인코딩 버퍼 언더런 여부까지 SNMP(Simple Network Management Protocol)나 온프레미스 모니터링 도구(Prometheus, Zabbix 등)로 수집하고 알람을 설정해야 합니다.

셋째는 확장 속도(Elasticity)의 제약입니다. 갑자기 방송 편성이 평소의 3배로 늘어나는 특수 기획전이나 프로모션 기간에 클라우드 PaaS는 API 호출 몇 번으로 동시 채널 수를 늘릴 수 있습니다. 하지만 하드웨어 어플라이언스는 장비 한 대당 처리 가능한 최대 인코딩 채널 수가 물리적으로 제한됩니다. 초과 수요가 발생했을 때 클라우드의 AWS Elemental MediaLive로 버스팅(Bursting)하여 일시적으로 트래픽을 넘기는 하이브리드 오버플로 아키텍처를 사전 준비해 두지 않으면 용량 한계에 부딪힐 수 있습니다.

도입 전 확인할 것

AWS Elemental Live와 같은 온프레미스 인코딩 어플라이언스를 도입해 라이브 및 재방송 파이프라인을 구축하려는 팀이라면, 다음 네 가지 항목을 먼저 점검하시기 바랍니다.

• 스튜디오 물리 회선의 안정성: 사내 스튜디오에서 클라우드 오리진(S3/MediaStore)으로 올라가는 업링크 대역폭이 이중화된 전용선(AWS Direct Connect 등)이나 기업용 고정 IP 회선으로 확보되어 있는지 확인해야 합니다.
• 일평균 정규 방송 편성 수: 하루 고정 방송이 3~5편 미만이라면 어플라이언스 구매 및 랙 상면 비용, 유지보수 계약 비용이 클라우드 관리형 과금보다 높을 수 있습니다.
• 세로형 비디오 및 메타데이터 동기화 규격: 모바일 환경 특유의 9:16 인코딩 프로파일과 상품 정보 타임스탬프 메타데이터(Timed Metadata, ID3 태그 등)가 어플라이언스를 거쳐도 누락 없이 클라이언트로 전달되는지 PoC(개념 검증) 단계에서 반드시 검증해야 합니다.
• 장애 절체 자동화 수준: 송출 도중 어플라이언스에 장애가 발생했을 때 백업 인코더나 클라우드 인코더로 끊김 없이 전환(Seamless Failover)할 수 있는 라우팅 정책이 마련되어 있는지 확인해야 합니다.

그 밖의 소식

• 추천 후보는 많을수록 좋을까? TopK를 최적화해 전환율을 높인 방법 — 토스 커머스 팀이 리트리벌 모델의 후보 상품 수(TopK)를 조합 최적화하여 랭커 부하를 줄이고 전환율을 개선한 사례입니다.
• 에이전트도 읽는 디자인 시스템, Clay 개편기 — 아임웹이 개발자 경험(DX) 중심이었던 디자인 시스템을 AI 에이전트가 코드를 생성하고 해석하기 유리한 AX 구조로 재설계한 경험을 공유했습니다.
• 전체 Cloudflare API를 위한 에이전틱 CLI, cf를 소개합니다 — Cloudflare가 전체 API를 지원하고 TypeScript 구성을 제공하는 CLI 도구 cf와 SDK 생성기 Forge를 공개했습니다.
• LLM이 만든 SQL을 믿고 실행하기까지: A2A 기반의 대화형 BI 애플리케이션 개발기 — 자연어로 데이터베이스를 조회하는 대화형 BI에서 SQL 생성 안정성을 확보한 개발기입니다.
• 내 네트워크에 무엇이 연결되어 있나요? - Genian DPI가 자산을 인식하는 방식 — GDPI 엔진을 활용해 에이전트 설치 없이 네트워크 연결 단말을 식별하는 접근제어 기술 소개입니다.
• 미 연방 판사, Flock을 ‘무차별적 대규모 감시’로 규정 — 영장 없는 차량 번호판 자동 조회가 수정헌법 제4조 위반이라는 판결 소식입니다.
• ICE, 시위 참가자 사진을 Palantir 데이터베이스에 쌓아 와 — 이민세관집행국(ICE)의 데이터베이스 감시 활용에 관한 외신 보도입니다.
• MMP와 게임 이벤트를 연결해 이용자 행동 확인하기 — 컴투스의 모바일 마케팅 성과 측정 및 이용자 분석 연동 사례입니다.
• 우라늄 큐브가 드러낸 사실, 나치 독일에는 원자폭탄을 만들 가망이 없었다 — 역사 과학 분석 기사로, 개발 실무와 거리가 있어 링크만 남깁니다.
• 고무줄이 늘어난 바지 수선하기 — 일상 수선에 관한 개인 글이라 링크만 남깁니다.