IMA SDK 광고 차단, 설명

IMA SDK가 실제로 무엇인지

인터랙티브 미디어 광고(IMA) SDK는 Google의 비디오 광고를 위한 클라이언트 사이드 라이브러리입니다. 비디오를 수익화하고자 하는 웹사이트는 일반적으로 자체 광고 플레이어를 구축하지 않고, imasdk.googleapis.com/js/sdkloader/ima3.js(또는 동적 변형인 ima3_dai.js)를 로드한 후, AdDisplayContainer를 초기화하고 SDK에 광고 태그 URL을 전달합니다. SDK는 이후 VAST 응답을 가져와 플레이어 내에 광고를 렌더링하고, 임프레션 및 쿼터일(Quartile)을 추적한 뒤, 최종적으로 게시자 콘텐츠로 제어를 다시 넘깁니다.

하나의 도메인에서 제공되는 하나의 공유 스크립트이기 때문에, IMA SDK는 웹 비디오 광고에서 가장 핵심적인 병목 지점입니다: 이 SDK를 무력화하면, 이를 기반으로 구축된 모든 플레이어가 광고를 더 이상 제공하지 않습니다.

광고 요청의 수명 주기

시청자가 재생 버튼을 누르면, 플레이어는 일반적으로 다음 순서를 실행합니다:

1. 페이지는 Google 서버에서 ima3.js를 로드합니다.
2. 플레이어는 광고 로더를 생성하고, 광고 서버를 가리키는 광고 태그를 사용해 광고를 요청합니다.
3. SDK는 광고(보통 DoubleClick을 통해 전달되는 VAST/VMAP 문서)를 가져와 파싱한 후, 비디오 위에 컨테이너 형태로 광고 미디어를 렌더링합니다.
4. 트래킹 픽셀이 실행되고, 플레이어는 대기합니다.
5. 광고가 종료되거나 오류가 발생하면, SDK는 CONTENT_RESUME_REQUESTED 이벤트를 발생시키고, 플레이어는 실제 비디오를 재생합니다.

마지막 이벤트가 핵심입니다: 플레이어는 이 이벤트를 기다리도록 작성됩니다. SDK를 제어하는 사람이 콘텐츠 재개 시점을 결정합니다.

단순히 SDK를 차단하는 것이 플레이어를 깨뜨리는 이유

거친 접근법은 네트워크 수준에서 imasdk.googleapis.com을 차단하고 그대로 끝내는 것입니다. 문제는 많은 플레이어가 SDK가 실패하거나 누락된 경우 치명적 오류로 간주하고 영상 재생을 아예 거부하며, 콘텐츠 대신 로딩 스피너나 “광고 차단 탐지됨” 방어장치를 표시한다는 점입니다.

이 때문에 고전적인 네트워크 수준의 차단기는 동영상 광고에 약합니다: 광고 요청은 차단할 수 있지만, 플레이어가 묻는 “이제 다시 재생해도 되나요?”라는 질문에는 대답할 수 없습니다. SDK를 대신할 수 있는 무언가만이 가능합니다.

대체를 통한 무력화: 스텁(stub) 접근 방식

AdOff는 다른 접근 방식을 채택합니다: SDK를 차단하는 대신, 이를 대체합니다. IMA SDK의 공개 API를 흉내 내는 스텁이 삽입되어, 플레이어는 여전히 작동 중인 SDK를 “보는” 효과를 얻지만, 이 SDK는 모든 광고 브레이크가 비어 있는 것처럼 동작합니다.

플레이어가 adsManager.start()를 호출하면, 스텁은 즉시 CONTENT_RESUME_REQUESTED를 발생시킵니다. 플레이어는 즉시 콘텐츠 재생을 재개합니다. 광고는 가져오지 않으며, 광고는 렌더링되지 않으며, 플레이어는 결코 오류 상태에 진입하지 않습니다. 왜냐하면 플레이어는 결코 뭔가 누락된 것을 인식하지 못하기 때문입니다.

동일한 스텁을 위한 두 가지 전달 채널

AdOff는 서로 다른 사이트가 SDK를 로드하는 방식이 다르기 때문에 동일한 스텁을 두 가지 채널을 통해 제공합니다.

• 페이지 내 주입. 제외 목록에 포함되지 않은 사이트에서는 메인 월드 스크립트가 플레이어가 초기화되기 전에 window.google.ima를 정의하므로, 번들화되거나 외부에서 로드된 SDK는 스텁(stub)에 의해 대체됩니다.
• 네트워크 리디렉션. 42개 유럽 방송사 도메인에 대해, declarativeNetRequest 규칙이 ima3.js 및 ima3_dai.js 요청을 확장 프로그램 내에 번들로 포함된 스텁 파일로 리디렉션합니다. 페이지는 구글 SDK인 줄 알고 로드하지만, 실제로는 AdOff의 SDK를 로드하게 됩니다.

두 채널 모두 동일한 결과로 수렴합니다: 플레이어는 반응형 SDK를 받고, 시청자는 콘텐츠를 받습니다.

이 접근 방식이 도달하는 범위와 도달하지 못하는 범위

이 스텁은 클라이언트 측 IMA 기반 광고를 무력화합니다. 이는 서버 측 광고 삽입(SSAI)에는 영향을 주지 않으며, 이 경우 광고는 배달 전에 비디오 스트림 자체에 통합되므로 가로채야 할 SDK 호출이 없습니다. 자체 광고 파이프라인을 사용하는 프리미엄 구독 서비스는 의도적으로 제외되어 플레이어가 계속 작동하도록 합니다.

주요 동영상 플랫폼은 상단에 전용 파이프라인도 제공됩니다: 광고 스케줄링은 페이지가 읽기 전에 플레이어의 응답에서 제거되며, 이 과정에서 빠져나온 광고는 빠르게 건너뜁니다.

이러한 내용이 광고 차단의 미래에 왜 중요한지

광고 플랫폼은 정확히 이러한 이유로 클라이언트 측 SDK에 점점 더 많은 무게를 두고 있습니다. 바로 순진한 차단 도구가 이러한 SDK를 처리하기 어려우기 때문입니다. 플레이어를 고갈시키는 대신 플레이어를 해결하는 접근 방식은 견고합니다. 이는 모든 광고 URL을 열거하는 데 의존하지 않고, SDK 자체의 계약—즉, 콘텐츠가 반드시 재개되어야 한다는 조건—에만 의존합니다.

AdOff는 Chrome, Firefox, Safari, Edge 및 Opera에서 사용 가능한 무료 계정 없이 설치 가능한 Manifest V3 확장 프로그램이며, 비디오 중화 레이어는 모든 사용자에게 포함됩니다.

자주 묻는 질문

IMA SDK 차단은 SDK를 대체하는 것과 동일한가요?

아니요. 네트워크 수준에서 차단하면 플레이어가 SDK가 콘텐츠 재개를 알릴 때까지 대기하므로 영상 재생이 방해될 수 있습니다. 이를 스텁(stub)으로 대체하면 광고 요청이 전혀 발생하지 않으면서도 플레이어가 완전히 정상 작동합니다.

스텁이 광고 요청을 수신하면 어떤 일이 발생하나요?

이 스텁은 플레이어가 기대하는 동일한 API 인터페이스를 노출합니다. 광고 시작을 요청받으면 즉시 콘텐츠 재개(content-resume) 이벤트를 발생시켜, 광고를 가져오거나 렌더링하지 않고도 재생을 계속합니다.

IMA 스텁은 서버 측 광고 삽입에 효과가 있나요?

아니요. SSAI(Server-Side Ad Insertion)의 경우 광고는 서버에서 영상 스트림에 미리 삽입된 후 전달되므로 클라이언트 측 SDK 호출을 가로채는 것이 불가능합니다. 서버 측 삽입 방식에는 별도의 대응 방안이 필요하며, 브라우저 확장 프로그램으로는 해결할 수 없습니다.

이 종류의 확장 프로그램을 실행할 수 있는 브라우저는 어떤 것들이 있나요?

AdOff는 Manifest V3 기반으로 구축되어 Chrome, Firefox, Safari, Edge, Opera에서 작동합니다. IMA 중립화 레이어는 무료 버전에 포함되어 있으며, 계정 등록이나 가입이 필요 없습니다.

사이트에서 SDK가 대체되었는지 감지할 수 있나요?

이것이 스텔스(stealth) 레이어의 목적입니다. 베이트 위조(bait spoofing)와 fetch/XHR 가로채기를 통해 환경을 일반적인 상태로 위장하여 애드블록 우회 스크립트가 이상 징후를 감지하지 못하게 합니다. 플랫폼이 탐지 방식을 자주 변경하기 때문에 어떤 방법도 영구적인 해결책은 아닙니다.

관련 글: 스트리밍 광고 차단: 완벽 가이드, 프리롤, 미들롤, 포스트롤: 비디오 광고 형식 설명, AdOff 작동 원리, 레이어별 설명.