AI 기반 SCTE-35 자동 삽입으로 라이브 스트리밍 광고 운영 자동화하기

AWS Elemental MediaLive의 썸네일 API와 Amazon Rekognition Custom Labels, AWS Step Functions를 결합하여 라이브 방송 화면을 AI가 실시간으로 인식하고, 하프타임 등 브레이크 진입 시 송출되는 필러(Filler) 영상을 감지하여 SCTE-35 광고 신호를 자동으로 삽입하는 아키텍처를 소개합니다.

소개

라이브 스트리밍과 광고 삽입 운영의 과제

라이브 스트리밍(특히 스포츠 중계)에서 SCTE-35 광고 삽입 신호는 수익화를 위한 매우 중요한 핵심 과제이지만, 현재 대부분의 방송 미디어 사업자는 운영자가 수동으로 신호를 삽입하거나 사전 스케줄에 의존하고 있습니다. 수동 방식은 24/7 상주 인력이 필요하고, 사전 스케줄 방식은 경기 상황에 따라 변동하는 하프타임 등의 이벤트 시점을 정확히 포착하지 못합니다. 이로 인해 광고 삽입 타이밍이 부정확하거나 광고 기회를 놓치는 문제가 발생하며, 채널 수가 증가할수록 운영 비용이 선형적으로 증가합니다.

SCTE-35는 방송 스트림 내에 광고 구간의 시작과 끝을 알리는 표준 신호(Cue)입니다. 라이브 스트림에 SCTE-35 마커가 삽입되면 다운스트림의 AWS Elemental MediaTailor와 같은 SSAI(Server-Side Ad Insertion) 솔루션이 이 신호를 인지하여 시청자별 맞춤 광고를 원본 콘텐츠 대신 송출합니다. 즉, SCTE-35 마커가 정확한 시점에 삽입되어야만 광고 수익화 파이프라인 전체가 동작합니다. 이 블로그에서는 사람이 화면을 보고 판단하던 광고 삽입 시점 결정을, AWS Elemental MediaLive와 Amazon Rekognition, AWS Step Functions의 조합으로 자동화하는 방법을 소개합니다.

한계 1: 수동 삽입 방식

운영자가 방송 화면을 지켜보다가 하프타임 진입 시점에 콘솔이나 API로 직접 SCTE-35 신호를 삽입하는 방식입니다. 타이밍 정확도는 확보할 수 있지만, 채널당 24/7 상주 인력이 필요하고 야간이나 새벽 경기 대응 부담이 큽니다. 사람의 반응 속도와 집중력에 의존하기 때문에 휴먼 에러 가능성이 상존하며, 채널 수가 늘어나면 운영 인력과 비용이 선형적으로 증가합니다.

한계 2: 사전 스케줄 방식

편성표를 기준으로 예상 시각에 SCTE-35 삽입을 미리 예약해 두는 방식입니다. 인력은 필요 없지만, 스케줄 방식은 “광고를 언제 넣을지 사전에 알 수 있다”는 전제 위에서만 동작합니다. 라이브 스포츠는 이 전제가 성립하지 않는 대표적인 사례입니다. 축구의 추가 시간(Injury Time)처럼 브레이크 진입 시점이 경기 상황에 따라 매 경기 달라지고, 야구의 이닝 교체는 시점 예측이 사실상 불가능합니다. 하프타임이 예상보다 늦게 시작하면 경기 장면 위에 광고가 송출되고, 예상보다 일찍 시작하면 광고 기회를 놓치게 됩니다. 즉 삽입 시점을 미리 알 수 없는 환경에서는 스케줄 자체를 만들 수 없다는 것이 이 방식의 근본적인 한계입니다.

AI 화면 인식 기반 자동 삽입

감지 대상: 광고 전 송출되는 필러(Filler) 영상

두 방식 모두 타이밍 정확도와 운영 확장성을 동시에 만족하지 못합니다. 이 간극을 메우는 것이 화면 인식 기반 자동화입니다. 방송사와 OTT 사업자는 통상 하프타임 등 브레이크에 진입하면 경기 화면 대신 사전에 준비한 필러 영상(채널 브랜딩 루프, 대기 화면, 광고 전 안내 영상 등)을 송출합니다. 즉 “필러가 화면에 나타났다”는 것은 “광고를 삽입할 수 있는 빈 구간이 시작되었다”는 가장 확실한 신호입니다.

필러는 사업자가 직접 준비한 고정 영상 자산이므로 매번 동일한 화면이 반복됩니다. 경기 장면처럼 카메라 앵글과 조명이 계속 변하는 대상이 아니라, 사전에 알고 있는 화면을 찾는 문제이기 때문에 컴퓨터 비전 모델 입장에서 매우 안정적인 감지 대상입니다. 운영자가 “필러로 전환되었는지” 화면을 보고 판단하던 과정을 AI가 대신하도록 하는 접근입니다.

이 접근의 핵심 아이디어는 세 가지 AWS 기능의 조합입니다.

• MediaLive 썸네일 API: 채널에 썸네일 기능을 활성화하면 MediaLive가 현재 송출 중인 화면의 썸네일 이미지를 주기적으로 생성하고, DescribeThumbnails API로 이를 조회할 수 있습니다. 별도의 프레임 추출 파이프라인 없이, 실행 중인 채널에서 곧바로 “지금 이 순간의 화면”을 얻을 수 있습니다.
• Amazon Rekognition Custom Labels: 필러 화면과 일반 경기 화면을 각각 라벨링한 소량의 데이터셋으로 커스텀 이미지 분류 모델을 학습합니다. ML 전문 지식 없이도 콘솔에서 학습부터 배포까지 완결할 수 있습니다.
• MediaLive Schedule API: 대상 화면이 감지되면 BatchUpdateSchedule API의 Scte35SpliceInsert 액션을 Immediate Mode로 실행하여 스트림에 SCTE-35 신호를 즉시 삽입합니다.

이 세 가지를 AWS Step Functions가 1초 간격의 모니터링 루프로 오케스트레이션하면, “화면을 지켜보다가 필러로 전환되면 광고 신호를 넣는” 운영자의 업무가 그대로 자동화됩니다.

아키텍처 개요

그림 1. SCTE-35 자동 삽입 아키텍처 — 스트리밍 경로(상단)와 AI 감지/삽입 루프(하단)

전체 아키텍처는 시청자에게 영상을 전달하는 스트리밍 경로와, 화면을 감시하며 SCTE-35를 삽입하는 자동 감지 경로로 구성됩니다. 스트리밍 경로는 AWS Elemental Live(현장 인코더)에서 시작하여 AWS Elemental MediaLive, AWS Elemental MediaPackage, AWS Elemental MediaTailor를 거쳐 Amazon CloudFront로 시청자에게 전달되는 일반적인 SSAI 구성입니다. 자동 감지 경로는 이 스트리밍 경로에 영향을 주지 않고 병렬로 동작합니다.

자동 감지 경로의 처리 단계는 다음과 같습니다.

• 1단계 — 썸네일 수집: Step Functions가 1초마다 AWS Lambda 함수를 호출하고, Lambda는 MediaLive의 DescribeThumbnails API로 지정한 파이프라인의 최신 화면 썸네일(JPEG)을 가져옵니다. 라이브 스트림을 직접 디코딩하지 않고도 화면 샘플링이 가능하다는 점이 이 아키텍처의 비용과 복잡도를 크게 낮추는 포인트입니다.
• 2단계 — AI 화면 분석: 썸네일 이미지를 Rekognition Custom Labels의 DetectCustomLabels API로 전달합니다. 학습된 모델이 filler, normal 등의 라벨과 신뢰도(Confidence)를 반환하며, 대상 라벨이 사전 정의한 임계값(예: 80%) 이상이면 필러 전환, 즉 브레이크 진입으로 판정합니다.
• 3단계 — SCTE-35 삽입: 감지 즉시 BatchUpdateSchedule API로 SpliceInsert 타입의 SCTE-35 액션을 Immediate Mode로 삽입합니다. 광고 구간 길이(Duration)는 90kHz 틱 단위로 지정합니다(예: 15초 = 1,350,000 틱). 삽입된 마커는 MediaPackage를 거쳐 HLS 매니페스트의 광고 마커로 변환되고, MediaTailor가 이를 기반으로 필러 구간을 시청자별 맞춤 광고로 치환합니다. 광고가 준비되지 않은 시청자에게는 필러가 그대로 노출되므로, 필러는 자연스러운 Fallback 콘텐츠 역할도 합니다.
• 4단계 — 증거 보관과 쿨다운: 감지를 트리거한 썸네일은 타임스탬프, 라벨명, 신뢰도를 파일명에 포함해 Amazon S3에 저장합니다. 이후 30초의 쿨다운에 진입하여, 필러 화면이 연속으로 감지되더라도 SCTE-35가 중복 삽입되지 않도록 합니다.

감지 로직 구현 예시

앞의 세 단계를 Lambda 함수로 구현하면 다음과 같은 형태가 됩니다. AWS SDK for JavaScript v3 기준의 개념 코드로, 오류 처리와 상태 관리는 생략했습니다.

// 1. 현재 화면 썸네일 조회
const thumbnailResponse = await mediaLiveClient.send(
  new DescribeThumbnailsCommand({
    ChannelId: channelId,
    PipelineId: pipelineId,
    ThumbnailType: 'CURRENT_ACTIVE',
  })
);
// 썸네일 데이터 추출
Const thumbnail = thumbnailResponse.ThumbnailDetails[0].Thumbnails[0];
const imageBuffer = Buffer.from(thumbnail.Body, 'base64');
 
// 2. Custom Labels 모델로 분석
const labelResponse = await rekognitionClient.send(
  new DetectCustomLabelsCommand({
    ProjectVersionArn: PROJECT_ARN,
    Image: { Bytes: imageBuffer },
    MinConfidence: minConfidence,
  })
);
 
// 3. 대상 라벨 감지 시 SCTE-35 즉시 삽입
if (targetFound) {
  await mediaLiveClient.send(
    new BatchUpdateScheduleCommand({
      ChannelId: channelId,
      Creates: {
        ScheduleActions: [{
          ActionName: `scte35-filler-${Date.now()}`,
          ScheduleActionStartSettings: {
            ImmediateModeScheduleActionStartSettings: {},
          },
          ScheduleActionSettings: {
            Scte35SpliceInsertSettings: {
              SpliceEventId: scte35EventId,
              Duration: 1350000, // 15초 (90kHz 틱)
            },
          },
        }],
      },
    })
  );
}

Rekognition Custom Labels: 소량의 데이터로 시작하는 화면 분류

이 아키텍처에서 AI의 역할은 “지금 화면이 필러인가, 경기 중인가?”라는 이진 분류에 가깝습니다. 범용 객체 인식이 아닌, 특정 사업자가 준비한 특정 필러 영상에 특화된 판단이 필요하므로 Rekognition Custom Labels가 적합합니다.

데이터셋 구성

그림 2. Rekognition Custom Labels 워크플로우 — 데이터셋 생성, 라벨링, 학습, 평가의 4단계

Custom Labels는 이미지 수준 분류(Image-level Classification)와 객체 탐지(Object Detection) 두 가지 모드를 지원하는데, 여기서는 “화면 전체가 필러인가”를 판단하는 것이므로 이미지 수준 분류가 적합합니다. 따라서 데이터셋 준비 시 바운딩 박스 라벨링 없이 이미지 단위로 라벨만 지정하면 됩니다.

주목할 점은 필요한 학습 데이터의 규모입니다. 필러는 사업자가 직접 준비한 고정 영상 자산이므로 매번 동일한 화면이 반복되고, 경기 화면과 시각적으로 뚜렷하게 구별됩니다. 따라서 라벨당 10~20장 수준의 이미지로도 실용적인 정확도의 모델을 얻을 수 있습니다. 필러 영상 원본에서 프레임을 추출하고 과거 경기 녹화본에서 일반 화면을 샘플링하면 되므로, 새 시즌 개막 전 반나절 정도의 준비로 모델을 갖출 수 있습니다. 필러 영상이 교체되면 새 필러의 프레임으로 데이터셋을 갱신하고 재학습하는 운영 절차만 함께 정의해 두면 됩니다.

모델 학습과 평가

모델 준비는 Rekognition 콘솔에서 코드 작성 없이 진행할 수 있습니다.

1. 프로젝트 생성: Rekognition 콘솔 → Custom Labels → Create project
2. 데이터셋 구성: filler / normal 라벨로 이미지 업로드 및 라벨 지정 (학습/테스트 세트는 자동 분할 가능)
3. 모델 학습: Train model 클릭 — 이 규모의 데이터셋 기준 약 30분~1시간 소요
4. 평가 확인: 학습 완료 후 콘솔 Evaluation 탭에서 Precision, Recall, F1 Score 확인

그림 3. 학습 완료된 Custom Labels 모델의 Use model 화면 — Start/Stop과 추론 유닛 설정

Custom Labels는 학습 시 분리해 둔 테스트 세트로 모델을 평가하고, 라벨별 및 전체 기준으로 다음 세 가지 지표를 제공합니다. 이 유스케이스에서 각 지표가 무엇을 의미하는지 함께 정리하면 다음과 같습니다.

평가 지표를 볼 때는 이 유스케이스의 특성을 고려해야 합니다. Precision과 Recall은 일반적으로 트레이드오프 관계에 있는데, 미탐(필러인데 감지 못함)은 하이브리드 구성의 스케줄 Fallback으로 보완할 수 있지만, 오탐(경기 화면을 필러로 오인)은 경기 중 광고 송출이라는 시청자 경험 사고로 직결됩니다. 즉 이 워크로드에서 두 지표의 값어치는 대등하지 않습니다.

그런데 F1 Score는 두 지표를 대등하게 취급하는 값입니다. 따라서 콘솔에서 F1 Score(Model performance)로 모델의 전반적인 완성도를 확인한 뒤, 도입 여부는 filler 라벨의 Precision을 기준으로 판단하는 것을 권장합니다. 같은 F1 점수라도 Precision이 낮고 Recall이 높은 모델은 이 유스케이스에 부적합할 수 있기 때문입니다. Precision이 충분히 높지 않다면 필러 이미지의 다양성(필러 영상의 서로 다른 구간 프레임)을 보강하거나, 운영 시 신뢰도 임계값을 상향하는 방식으로 보수적으로 조정하면 됩니다.

이 Precision/Recall 트레이드오프를 운영 단계에서 조정하는 수단이 DetectCustomLabels API의 MinConfidence 파라미터입니다. MinConfidence를 높이면 Precision이 올라가고 Recall이 내려가며, 낮추면 그 반대가 됩니다. MinConfidence(0~100)보다 낮은 신뢰도의 라벨은 아예 응답에서 제외되므로, 학습 시 자동 산출되는 라벨별 기본 임계값(Assumed Threshold) 대신 운영 정책에 맞는 값을 적용할 수 있습니다. 여기에 Lambda 로직에서 응답된 라벨의 신뢰도를 한 번 더 비교하는 이중 확인을 두면 판정 기준을 명시적으로 남길 수 있습니다. 임계값은 Lambda 환경 변수 등 외부 설정으로 빼두면 모델 성능과 운영 경험에 따라 코드 수정 없이 조정할 수 있습니다.

모델 시작과 중지: 온디맨드 운영 패턴

Custom Labels 모델은 사용 전 명시적으로 시작(Start)해야 하고, 실행 중에는 추론 유닛 단위로 시간당 비용이 발생합니다. 따라서 24시간 상시 구동이 아니라, 경기 시작 전 모델을 시작하고 종료 후 중지하는 운영 패턴이 비용 효율적입니다. 이 시작/중지 자체도 EventBridge Scheduler로 경기 편성표에 맞춰 자동화할 수 있습니다.

# 경기 시작 전: 모델 시작
aws rekognition start-project-version \
  --project-version-arn "<모델 ARN>" \
  --min-inference-units 1
 
# 경기 종료 후: 모델 중지 (비용 절감)
aws rekognition stop-project-version \
  --project-version-arn "<모델 ARN>"

Step Functions: 감시 루프의 오케스트레이션

“1초마다 화면을 확인한다”는 요구사항을 구현하는 방법은 여러 가지가 있지만, Step Functions의 상태 머신 루프가 가장 적합합니다. EventBridge의 최소 스케줄 단위(1분)로는 초 단위 폴링이 불가능하고, Lambda 내부에서 장시간 루프를 도는 방식은 타임아웃(최대 15분)과 상태 관리 문제가 있습니다. Step Functions는 Wait 상태로 초 단위 간격을 정밀하게 제어하면서, 실행 이력이 콘솔에 시각적으로 남아 “몇 시 몇 분 몇 초의 어떤 썸네일이 삽입을 트리거했는지”를 추적하기 쉽다는 운영상 이점이 있습니다.

그림 4. Step Functions 상태 머신 — 1초 간격 감시 루프, 감지 시 30초 쿨다운, 1시간 후 자동 종료

상태 머신은 일곱 개의 상태로 구성됩니다. Lambda를 호출하는 상태 하나를 제외하면 모두 대기, 분기, 카운터 갱신을 담당하는 경량 상태입니다.

여기서 눈여겨볼 점은 경과 시간을 실제 시계가 아니라 카운터로 관리한다는 것입니다. 대기한 시간만큼 카운터를 더하는 방식이므로 Choice 상태의 숫자 비교만으로 “1시간 경과” 판정이 끝나고, 타임스탬프를 계산하거나 상태 간에 시각을 전달할 필요가 없습니다. 폴링 주기나 쿨다운 시간을 바꾸고 싶다면 Wait 상태의 값과 대응하는 카운터 증가값만 함께 조정하면 됩니다. 또한 상태 머신이 표준(Standard) 워크플로로 동작하므로 상태 전이 하나하나가 실행 이력에 남아, 어느 시점의 어떤 판정이 삽입으로 이어졌는지를 콘솔에서 그대로 되짚을 수 있습니다.

이 구조에 담긴 세 가지 안전장치도 눈여겨볼 만합니다.

• 쿨다운(Wait30s): 필러 영상은 브레이크 동안 계속 송출되므로, 첫 감지 후 일정 시간 재삽입을 차단해 SCTE-35 중복 삽입을 방지합니다. 광고 구간 길이에 맞춰 조정하면 됩니다.
• 자동 종료(CheckTimeout): 운영자가 중지를 잊더라도 상태 머신이 스스로 종료되어 불필요한 비용과 오탐 리스크를 차단합니다. 경기 길이에 여유를 둔 값으로 설정하는 것이 좋습니다.
• 증거 보관(S3): 삽입을 트리거한 썸네일을 신뢰도와 함께 저장하여, 광고 삽입 시점에 대한 사후 감사와 모델 개선(오탐 이미지의 재학습 반영)에 활용합니다. 저장된 이미지는 수명 주기 정책으로 7일 후 자동 삭제됩니다.

감지 지연 시간

이 아키텍처의 이론적 반응 시간은 다음 요소의 합입니다.

종합하면 필러 영상으로 전환된 후 수 초 이내에 SCTE-35가 삽입됩니다. 사람이 화면을 확인하고 콘솔에서 수동 삽입하는 데 걸리는 시간과 비교하면 동등하거나 빠른 수준이며, 무엇보다 모든 채널에서 일관된 반응 속도를 보장한다는 점이 다릅니다. 광고 구간 자체가 수 분 단위인 점을 고려하면, 수 초의 감지 지연은 SSAI 광고 치환에 실질적인 영향을 주지 않습니다.

아키텍처 설계 인사이트

이 아키텍처를 실제로 도입할 때 함께 검토할 만한 설계 인사이트를 정리합니다.

전제 조건: 감지 대상은 송출 패턴에 맞춰 정의

이 아키텍처는 “브레이크 진입 시 사전에 준비한 필러 영상을 송출한다”는 방송사/OTT의 일반적인 운영 관행을 전제로 합니다. 필러가 고정 자산이라는 점이 소량 데이터 학습과 높은 감지 정확도의 근거가 되기 때문입니다. 만약 필러 없이 곧바로 스튜디오 중계나 하이라이트로 전환되는 피드라면, 스코어보드 그래픽이나 스튜디오 화면 등 해당 송출 패턴에서 반복적으로 나타나는 시각 요소를 감지 대상으로 학습시키면 됩니다. 핵심은 “어떤 화면이 브레이크의 시작을 알리는가”를 사업자의 송출 워크플로우에 맞춰 정의하는 것입니다.

스케줄 방식과의 하이브리드 구성

AI 감지를 유일한 트리거로 두기보다, 사전 스케줄을 안전망(Fallback)으로 함께 운용하는 구성을 권장합니다. 예를 들어 EventBridge Scheduler로 “전반 시작 40분 후부터 AI 감시 시작”을 예약하면, AI 감시 구간을 하프타임 예상 시간대로 좁혀 오탐 가능성과 Rekognition 구동 비용을 동시에 줄일 수 있습니다. 반대로 AI가 일정 시간 내 감지에 실패하면 예상 시각에 강제 삽입하는 이중화도 가능합니다.

오탐 제어: 임계값, 쿨다운, 감시 구간의 3중 장치

화면 인식 기반 자동화에서 가장 큰 리스크는 경기 중 오탐으로 인한 잘못된 광고 송출입니다. 필러는 고정 영상이므로 경기 장면과 혼동될 가능성 자체가 낮지만, 보수적으로 (1) 신뢰도 임계값(예: 80%), (2) 감지 후 쿨다운, (3) 감시 구간 제한(1시간 자동 종료)의 3중 장치를 함께 두면 리스크를 더 낮출 수 있습니다. 여기에 “N초 연속 감지 시에만 삽입”과 같은 연속 프레임 확인 로직을 추가하면 순간적인 화면 전환에 의한 오탐도 줄일 수 있습니다.

증거 보관과 MLOps 루프

광고 삽입은 매출과 직결되므로, “왜 그 시점에 삽입되었는가”를 설명할 수 있어야 합니다. 트리거 썸네일을 신뢰도, 타임스탬프와 함께 S3에 남기는 설계는 사후 감사 대응뿐 아니라, 오탐/미탐 이미지를 데이터셋에 추가해 모델을 지속 개선하는 MLOps 루프의 출발점이 됩니다.

다양한 시나리오로의 확장

“특정 화면 패턴 감지 → 스트림 제어”라는 구조는 필러 감지에 국한되지 않습니다.

• 야구 이닝 교체, 농구 쿼터 종료 등 종목별 브레이크 시 송출되는 필러/전환 화면 감지
• 방송 사고 화면(컬러바, 블랙 프레임) 감지 시 자동 슬레이트 전환 및 알림
• 프로그램 시작/종료 그래픽 감지 기반의 아카이빙 자동 마킹

또한 감지 엔진 자체도 발전시킬 수 있습니다. Amazon Bedrock의 멀티모달 Foundation Model을 활용하면 사전 학습 없이 “이 화면이 경기 중인지, 브레이크 구간인지”를 프롬프트로 판단하는 접근도 가능하며, 필러 자산이 자주 바뀌거나 학습 데이터 준비가 어려운 초기 단계의 대안으로 검토할 만합니다.

보안과 최소 권한

PoC 단계라도 프로덕션 전환을 염두에 둔다면 처음부터 보안 기준을 갖추는 것이 좋습니다. Lambda 실행 역할은 대상 MediaLive 채널과 Custom Labels 프로젝트 ARN으로 리소스를 한정한 최소 권한으로 구성하고, S3와 CloudWatch Logs는 AWS KMS로 암호화하며, AWS CDK로 정의한 뒤 cdk-nag로 보안 규칙을 검증하는 방식을 권장합니다.

결론

라이브 스트리밍의 광고 삽입 운영은 오랫동안 “사람의 눈”에 의존해 왔습니다. 이 블로그에서 소개한 아키텍처는 MediaLive 썸네일 API, Rekognition Custom Labels, Step Functions라는 관리형 서비스의 조합만으로 — 별도의 영상 분석 인프라나 ML 파이프라인 구축 없이 — 그 판단 과정을 자동화할 수 있음을 보여줍니다.

• 낮은 진입 장벽: 라벨당 10~20장의 이미지와 서버리스 구성만으로 시작할 수 있어, PoC부터 프로덕션까지의 거리가 짧습니다.
• 경제성: 경기 시간 동안만 구동하는 온디맨드 서버리스 구성으로 채널당 상주 인력을 대체하며, 채널 수가 늘어날수록 효과가 커집니다.
• 정확성과 일관성: 경기 상황에 따라 변동하는 이벤트 시점을 화면 기반으로 포착하므로, 사전 스케줄로는 불가능했던 타이밍 정확도를 모든 채널에서 일관되게 확보합니다.

수동 운영과 사전 스케줄 사이에서 고민하고 있는 미디어 사업자라면, 다가오는 시즌의 일부 채널을 대상으로 이러한 화면 인식 기반 자동화를 검증해 보시기를 권합니다. 광고 운영의 자동화는 단순한 비용 절감을 넘어, 놓치고 있던 광고 기회를 수익으로 전환하는 일이기도 합니다.