SSAI와 CSAI에 대해 알아보자
광고 삽입, 어디서 끼워 넣을 것인가
VOD나 라이브 스트리밍 서비스를 운영하다 보면 결국 마주하게 되는 질문이 있습니다. 사용자가 보고 있는 본편 영상 사이에 광고를 어떻게 끼워 넣을 것인가? 그리고 그 끼워 넣기는 클라이언트가 할 일인가, 서버가 할 일인가?
이 질문에 대한 두 가지 표준 답이 CSAI(Client-Side Ad Insertion, 클라이언트측 광고 삽입)와 SSAI(Server-Side Ad Insertion, 서버측 광고 삽입)입니다. 이름 그대로 광고가 콘텐츠에 합쳐지는 시점이 클라이언트(플레이어)인지 서버인지가 갈리는 지점이고, 그 선택이 사용자 경험·운영 비용·광고 수익·디바이스 호환성에 동시에 영향을 미칩니다.
이 글에서는 두 방식이 각각 어떻게 동작하는지, 무엇을 잘하고 무엇을 못 하는지, 그리고 실제 서비스 환경에서 어떤 기준으로 골라야 하는지를 정리합니다.
CSAI란 무엇인가
CSAI는 광고 요청과 삽입을 모두 사용자 기기의 비디오 플레이어가 직접 수행하는 방식입니다. 본편 콘텐츠는 콘텐츠 서버에서 받아오고, 광고는 별도의 광고 서버에서 받아와 플레이어가 두 스트림을 번갈아 재생합니다.
전형적인 동작 흐름은 다음과 같습니다.
- 플레이어가 본편 콘텐츠를 로드해 재생합니다.
- 광고 큐 시점(pre-roll/mid-roll/post-roll)에 도달하면 플레이어가 본편을 일시 정지합니다.
- 플레이어가 광고 서버에 VAST(Video Ad Serving Template) 또는 VMAP(Video Multiple Ad Playlist) 요청을 보냅니다.
- 광고 서버가 광고 메타데이터와 미디어 URL을 응답으로 반환합니다.
- 플레이어가 광고 미디어를 별도로 로드하여 재생합니다.
- 광고가 끝나면 다시 본편 위치로 복귀해 재생을 재개합니다.
대부분의 웹·모바일 환경에서는 Google IMA SDK나 그와 유사한 광고 SDK가 이 흐름을 추상화해 제공합니다. 플레이어 입장에서는 SDK에 광고 태그 URL만 넘기면 SDK가 광고 요청·재생·이벤트 통보를 알아서 해주는 식입니다.
CSAI의 핵심 특징은 광고 결정이 실시간으로 클라이언트에서 이루어진다는 점입니다. 사용자의 행동·디바이스·세션 정보를 광고 서버에 그대로 전달할 수 있어서, 매 시청마다 다른 광고를 동적으로 보여줄 수 있습니다.
SSAI란 무엇인가
SSAI는 광고 요청과 본편-광고 합치기(stitching)를 서버에서 미리 수행한 뒤, 그 결과를 단일 스트림으로 클라이언트에 내려보내는 방식입니다. 클라이언트 입장에서는 그냥 본편 manifest 하나를 받아서 재생하는 것과 다르지 않습니다.
전형적인 동작 흐름은 다음과 같습니다.
- 콘텐츠 서버 앞단의 광고 stitching 서버가 본편 manifest와 광고 manifest를 받습니다.
- stitching 서버가 광고 결정(누가 어떤 광고를 볼지)을 수행합니다.
- 본편 세그먼트 사이에 광고 세그먼트를 끼워 넣은 새로운 통합 manifest를 생성합니다.
- 클라이언트는 이 통합 manifest를 받아 재생합니다.
- 광고 구간은 manifest에 포함된 SCTE-35나 HLS DateRange 같은 메타데이터로 표시됩니다.
- 플레이어는 이 메타데이터를 보고 광고 구간에 진입했음을 인지하지만, 재생 자체는 단일 스트림으로 끊김 없이 진행됩니다.
대표적인 SSAI 솔루션으로는 Google DAI(Dynamic Ad Insertion), AWS Elemental MediaTailor, Yospace 등이 있습니다.
SSAI의 핵심 특징은 본편과 광고가 같은 코덱·같은 프로파일로 사전 트랜스코드되어 하나의 스트림으로 묶인다는 점입니다. 클라이언트의 디코더가 재생 중간에 재초기화될 필요가 없고, 광고 차단기가 광고 URL을 식별해 차단할 여지도 거의 없습니다.
CSAI의 장단점
장점
- 실시간 개인화: 매 광고 요청마다 사용자 컨텍스트를 광고 서버에 전달할 수 있어 정교한 타겟팅이 가능합니다.
- 풍부한 측정 데이터: 광고 시작·일시정지·완료·클릭 같은 이벤트를 플레이어가 직접 잡아낼 수 있어 측정 표준(VAST/VPAID 트래커)을 그대로 활용할 수 있습니다.
- 상호작용형 광고 지원: VPAID 기반의 클릭형·확장형 광고처럼 사용자 입력을 받는 광고 포맷을 자연스럽게 다룰 수 있습니다.
- 구현 진입 장벽이 낮음: IMA SDK 같은 검증된 라이브러리가 있어, 별도 인프라 없이도 광고 수익화를 시작할 수 있습니다.
단점
- 광고 차단기에 취약: 광고 URL 요청이 클라이언트에서 발생하기 때문에 브라우저 확장이나 네트워크 레벨 차단기에 그대로 노출됩니다.
- 재생 전환 비용: 본편→광고→본편 사이에 디코더가 재초기화되어 검은 화면이나 짧은 stall이 발생할 수 있습니다. 특히 TV·셋톱처럼 하드웨어 디코더 파이프라인이 긴 환경에서는 더 두드러집니다.
- 저사양 기기 부담: 클라이언트가 VAST 파싱·광고 매체 디코드·트래커 호출까지 모두 처리하므로 CPU·메모리 여유가 적은 디바이스에서는 끊김이 발생할 수 있습니다.
- 플랫폼 제약: iOS Safari 풀스크린이나 일부 셋톱처럼 비디오 엘리먼트를 동시에 두 개 띄울 수 없는 환경에서는 광고용 비디오를 별도로 오버레이하기 어렵습니다.
SSAI의 장단점
장점
- 광고 차단기 회피: 광고 세그먼트가 본편과 같은 호스트·같은 manifest에서 내려오기 때문에 광고 URL만 골라 차단하기가 사실상 불가능합니다.
- 매끄러운 시청 경험: 단일 스트림 재생이라 본편↔광고 전환에서 디코더 재초기화가 없고, 검은 화면이나 buffering이 거의 발생하지 않습니다.
- 디바이스 호환성: 클라이언트는 그냥 표준 HLS/DASH 플레이어로 재생만 하면 되므로, SDK 호환성 이슈가 없는 다양한 디바이스(특히 TV·CTV)에서 동작합니다.
- 높은 광고 완료율(fill rate): 광고 차단·플레이어 오류로 인한 광고 누락이 적어 광고 수익률이 안정적입니다.
- 클라이언트 코드 부담 감소: 광고 SDK 통합·업데이트가 필요 없어 앱 빌드 사이즈와 유지보수 비용이 줄어듭니다.
단점
- 인프라 복잡도와 비용: 광고 stitching 서버·트랜스코딩 파이프라인·광고 결정 백엔드를 구축·운영해야 하므로 초기 투자와 운영 비용이 큽니다.
- 개인화 유연성 제약: 광고 결정이 서버에서 일어나므로, 정교한 사용자별 타겟팅을 구현하려면 manifest 조작 API를 빈번히 호출해야 합니다.
- 상호작용형 광고 지원이 까다로움: VPAID 같은 클라이언트 의존 포맷을 SSAI 환경에서 다루려면 별도 통합이 필요합니다.
- 광고 측정의 표준화 부족: 광고 임프레션·viewability를 서버측에서 어떻게 측정할지에 대한 표준이 불완전해, OMID 같은 보조 표준이 필요합니다.
- 인코딩 정렬 요구: 본편과 광고가 같은 코덱·같은 GOP 구조·같은 키프레임 정렬을 가져야 stitching 지점에서 디코더가 흔들리지 않습니다.
SSAI vs CSAI 한눈에 비교
| 항목 | CSAI | SSAI |
|---|---|---|
| 광고 합치기 위치 | 클라이언트(플레이어) | 서버(stitching 서비스) |
| 클라이언트 인입 스트림 | 본편 + 광고 별도 | 단일 통합 manifest |
| 광고 차단기 저항성 | 낮음 | 높음 |
| 재생 전환 매끄러움 | 디코더 reinit 가능 | 매끄러움 |
| 개인화 유연성 | 높음 (실시간) | 중간 (서버 결정) |
| 상호작용형 광고 | 자연스러움 | 별도 통합 필요 |
| 디바이스 호환성 | SDK 의존 | 표준 플레이어로 충분 |
| 측정 데이터 풍부도 | 높음 (표준 트래커) | 중간 (OMID 보강 필요) |
| 초기 구현 비용 | 낮음 | 높음 |
| 운영·인프라 비용 | 낮음 | 높음 |
| 광고 완료율 | 차단·오류로 변동 큼 | 안정적으로 높음 |
어떤 환경에 어느 방식을 써야 할까
두 방식 중 어느 쪽이 절대적으로 우월하다고 말하기는 어렵습니다. 서비스의 특성과 시청 환경에 따라 답이 갈립니다. 일반적으로 권장되는 패턴을 정리하면 다음과 같습니다.
SSAI를 권장하는 환경
- 라이브 스트리밍·FAST 채널: SCTE-35 마커로 광고 시작·종료를 정확히 표시할 수 있고, 실시간 전환이 매끄러워야 하는 환경에 강합니다.
- CTV·TV 셋톱: 하드웨어 디코더가 광고와 본편 사이에서 재초기화되면 stall·검은 화면이 두드러지는데, SSAI는 이 경계를 아예 없애줍니다.
- 광고 차단기 노출이 큰 서비스: 무료 광고 기반 모델에서 광고 수익이 핵심이라면 차단기 저항성이 곧 매출과 직결됩니다.
- 다양한 디바이스 지원이 필요한 OTT: 디바이스마다 SDK 통합 상태가 다른 상황에서, 표준 플레이어만으로 동작하는 SSAI는 호환성 부담을 줄여줍니다.
CSAI를 권장하는 환경
- VOD 중심·정밀 타겟팅 서비스: 사용자 행동 데이터를 활용한 실시간 광고 개인화가 비즈니스 모델의 핵심인 경우 CSAI의 유연성이 빛납니다.
- 초기 단계의 광고 수익화: 광고 stitching 인프라를 구축하기 어려운 단계에서 IMA SDK 기반 CSAI는 빠른 진입 경로입니다.
- 상호작용형 광고 포맷: 사용자 클릭·확장·리워드 시청 같은 인터랙션이 광고 포맷의 핵심인 경우 CSAI가 자연스럽습니다.
- 데스크톱·모바일 브라우저 중심 서비스: 비디오 엘리먼트를 두 개 띄우거나 SDK가 잘 동작하는 환경이라 CSAI의 단점이 상대적으로 작게 작동합니다.
하이브리드 접근 — SGAI
최근에는 두 방식의 장점을 결합하려는 **SGAI(Server-Guided Ad Insertion)**도 등장하고 있습니다. 서버가 광고 결정과 manifest 가이드를 제공하되, 실제 광고 재생은 클라이언트가 자체 디코더로 처리하는 절충안입니다. SSAI의 안정성과 CSAI의 유연성을 모두 챙기려는 시도지만, 표준화가 아직 진행 중이라 즉시 도입하기에는 검증이 더 필요합니다.
정리
SSAI와 CSAI의 차이는 결국 광고와 본편을 어디서 합치느냐입니다. 이 질문 하나가 다음 다섯 가지를 동시에 결정합니다.
- 광고 차단기에 얼마나 강한가
- 본편↔광고 전환이 얼마나 매끄러운가
- 광고 개인화를 얼마나 유연하게 할 수 있는가
- 클라이언트 디바이스 호환성은 어디까지 챙길 수 있는가
- 인프라·운영 비용이 얼마나 드는가
한 줄로 요약하면 다음과 같습니다.
CSAI는 가볍고 유연하지만 차단기와 디코더 전환에 약하다. SSAI는 매끄럽고 견고하지만 인프라가 무겁다.
서비스의 시청 환경이 TV·라이브 중심이고 광고 수익이 핵심이라면 SSAI가 정답에 가깝고, 데스크톱·모바일 중심에 실시간 개인화가 중요한 단계라면 CSAI가 더 합리적인 출발점이 됩니다. 어느 쪽을 고르든 핵심은 사용자가 광고를 "끼어든 다른 영상"이 아니라 "콘텐츠의 자연스러운 일부"로 느끼게 만드는 것이고, 그 목표를 어느 정도까지 양보할 것인지가 결국 선택의 기준이 됩니다.