페이지를 여는 순간, 우리 눈에 광고가 뜨기까지의 시간은 0.1초도 되지 않습니다. 그 사이에 전 세계 수백 개 입찰자가 그 광고 한 자리를 두고 경매를 한 번 치릅니다. 누가 참여하고, 어떤 정보가 오가며, 어떤 가격으로 낙찰되는지가 모두 그 100ms 안에 끝납니다. 이 시간 제약이 광고 산업의 거의 모든 기술 인프라를 결정했습니다.
RTB 한 사이클의 단계별 분해, OpenRTB라는 산업 공통 언어, 워터폴에서 헤더 비딩으로의 진화, 거래 4유형, 1차가 경매(1st-price Auction) 시대의 경매 메커니즘, 그리고 매체에서 광고주까지 도달하는 공급 경로 최적화(SPO, Supply Path Optimization). 마지막에는 광고 사기와 그것을 막기 위해 만들어진 신뢰 인프라(ads.txt 가족)를 함께 짚습니다.
1. RTB 한 사이클: 사용자가 페이지를 열고 광고가 뜨기까지
실시간 입찰(RTB, Real-Time Bidding)은 말 그대로의 “실시간 입찰”에 그치지 않습니다. 사용자가 페이지를 여는 순간부터 광고가 송출되기까지 일곱 단계의 정밀한 흐름이 100ms 안에 일어납니다. 이 단계를 풀어보면 그다음에 등장하는 모든 기술 인프라(OpenRTB, 헤더 비딩, ads.txt)가 왜 만들어졌는지가 자연스럽게 보입니다.
1) 일곱 단계의 흐름
페이지가 열리는 순간 매체는 “여기 광고 자리 하나, 사용자 프로필은 이렇다”라는 쪽지를 SSP(Supply-Side Platform, 공급측 플랫폼)에 던지고, SSP는 그 쪽지를 거래소로 보냅니다. 거래소는 같은 쪽지를 수십·수백 개 DSP(Demand-Side Platform, 수요측 플랫폼)에 동시에 뿌리고, 각 DSP는 자기 광고주들의 캠페인 조건과 그 사용자가 맞는지 0.05초 안에 판단해 입찰가를 적어 보냅니다. 거래소가 그중 최고가를 골라 낙찰자에게 광고 소재를 매체로 흘려보내면, 사용자는 페이지가 다 뜨기 전에 자기 화면에 광고가 자리 잡는 모습을 봅니다.
2) 시간 제약이 결정한 것
사용자가 “페이지가 느리다”고 인지하기 시작하는 한계가 100ms 부근입니다. 이 시간 안에 입찰·낙찰·송출이 모두 끝나야 페이지 로딩 경험이 무너지지 않습니다.
이 100ms라는 숫자가 광고 산업 전체의 아키텍처를 결정했습니다. DSP는 입찰 결정을 50ms 안에 내야 하고, SSP·광고 거래소(Ad Exchange)는 그 입찰을 모으고 정렬하는 과정을 또 그 안에서 처리해야 합니다. 데이터 센터의 물리적 위치, 네트워크 지연, 입찰 알고리즘의 복잡도까지 전부 지연 시간(latency) 최소화를 기준으로 설계됩니다. 시간이 짧을수록 정교한 판단보다 빠른 판단이 우선되기 때문에, 이후 본문에 등장하는 비드 셰이딩(Bid Shading) 같은 도구들이 “사후 보정”의 형태로 발전하게 됩니다.
3) 입찰 요청(Bid Request)에 담기는 정보
입찰 요청은 “이 자리 비어 있음” 신호의 정식 명칭입니다. 그 안에는 다음 세 종류의 정보가 들어갑니다.
| 정보 카테고리 | 담기는 내용 |
|---|---|
| 사용자 정보 | 쿠키 ID, 모바일 광고 식별자(MAID, IDFA/GAID), 디바이스, 위치, 언어 |
| 페이지·앱 정보 | URL, 콘텐츠 카테고리(IAB Taxonomy), 광고 자리(Ad Slot)의 위치와 크기 |
| 인벤토리 정보 | 광고 포맷, 시청 가능성(viewability) 예측치, 최저 입찰가(Floor Price) |
여기서 사용자 정보가 어떻게 담기느냐가 광고가 “나에게 맞는 광고”가 되는지를 결정합니다. 그런데 그 식별자들이 쿠키 종말 이후 어떻게 변했는지, 그 자리에 무엇이 들어왔는지는 다음 편(데이터·식별자)의 핵심 주제입니다. 이번 편에서는 식별자가 어떤 형태로든 입찰 요청에 담겨 들어온다는 사실까지만 짚고, 거래 메커니즘 자체로 들어가겠습니다.
2. OpenRTB: 산업 공통 언어
100ms 안에 SSP와 DSP가 정보를 주고받으려면 같은 언어를 써야 합니다. SSP가 보낸 입찰 요청을 DSP가 알아듣지 못하면 거래는 시작도 안 됩니다. 이 언어가 OpenRTB입니다.
OpenRTB는 IAB 테크 랩(IAB Tech Lab)이 관리하는 RTB 표준 프로토콜입니다. 입찰 요청(Bid Request)과 입찰 응답(Bid Response)의 데이터 구조, 광고 포맷별 확장 명세(비디오는 VAST, CTV는 SIMID·OMID 등)가 모두 이 표준 위에 얹혀 있습니다. OpenRTB가 없었다면 SSP와 DSP가 1대1로 사양을 맞춰야 했을 것이고, 글로벌 거래는 사실상 불가능했을 것입니다.
1) 버전의 진화와 산업 실무의 괴리
OpenRTB 버전을 보면 흥미로운 점이 있습니다. 가장 최신 버전인 3.0은 2018년에 확정됐고, AdCOM 1.0과 함께 산업 채택 단계에 들어갔습니다. 그런데 2026년 현재까지도 산업 실무의 절대 다수는 2.x 버전(특히 2.5와 2.6)을 사용합니다.
이유는 두 가지입니다. 하나는 3.0이 객체 모델을 근본적으로 바꿔놔서 기존 시스템 전환 비용이 너무 컸다는 점입니다. 다른 하나는 IAB Tech Lab이 3.0의 핵심 기능들을 2.x에 역으로 흡수하는 전략(이른바 2.x 플랫폼 전략)을 택했다는 점입니다. 2.6에서 CTV용 광고 묶음(Ad Pod) 기능이, 그 이후에도 DOOH(Digital Out-of-Home, 디지털 옥외 광고)·Privacy Sandbox 적응 모듈, 가장 최근(2026년 4월 28일)에는 라이브 콘텐츠 시그널과 가격 매크로 업데이트가 5월 28일까지 공개 의견 수렴(public comment) 단계에 들어갔습니다. 결과적으로 3.0은 확정된 상태로 남아 있고, 실제 산업은 2.x 위에서 계속 진화하는 묘한 구도가 만들어졌습니다.
| 버전 | 출시 시점 | 핵심 변화 |
|---|---|---|
| 2.0 | 2011 | 디스플레이·비디오·모바일 통합 표준 |
| 2.5 | 2016 | 헤더 비딩, 청구·손실 알림, Flex Ads |
| 2.6 | 2022 | CTV용 광고 묶음(Ad Pod), 구조화된 User-Agent |
| 3.0 | 2018 확정 | 4계층 아키텍처, AdCOM 분리 (실무 채택은 제한적) |
| 2.x 후속 업데이트 | 2023~2026 | DOOH, Privacy Sandbox 적응, 라이브 콘텐츠 시그널 |
OpenRTB의 깊은 사양은 표준 문서 자체를 봐야 하는 영역이라 여기서는 더 들어가지 않습니다. 이번 편에서 짚을 핵심은 단 하나입니다. 산업 공통 언어가 있어야 100ms 안의 글로벌 거래가 가능하고, 그 언어가 진화하는 방식이 산업의 권력 구도를 반영한다는 점입니다.
3. 워터폴에서 헤더 비딩으로: 매체사의 진화
매체사가 자기 인벤토리를 파는 방식은 한 번 크게 진화했습니다. 워터폴이라는 비효율적 방식에서 헤더 비딩이라는 동시 입찰 방식으로의 전환이 그것이고, 이 진화가 매체사 수익 구조를 바꿔놨습니다.
1) 워터폴: 순서가 가격을 결정하는 구조
초기 프로그래매틱 광고는 워터폴(Waterfall) 방식으로 작동했습니다. 매체사는 여러 SSP에 동시에 요청하지 않고, 우선순위를 정해 한 곳씩 순차적으로 호출합니다. 일반적으로는 과거 수익이 높았던 SSP를 상단에 두고, 그 아래로 점점 낮은 가격대의 파트너를 배치합니다.
문제는 이 구조가 시장 가격을 제대로 발견하지 못한다는 점입니다. 상위 SSP에서 낮은 가격으로 낙찰되면 그 순간 거래가 종료되고, 더 높은 가격을 낼 수 있었던 다른 수요는 아예 참여 기회조차 얻지 못합니다. 결과적으로 매체사는 실제 수요 대비 낮은 가격에 인벤토리를 판매하게 됩니다.
즉, 워터폴은 “누가 더 비싸게 살 수 있는가”가 아니라 “누가 먼저 불렸는가”가 결과를 결정하는 구조입니다.
2) 헤더 비딩: 가격 경쟁을 복원한 구조
헤더 비딩(Header Bidding)은 이 문제를 해결하기 위해 등장했습니다. 페이지가 로드되는 순간, 매체사는 여러 SSP와 광고 거래소에 동시에 입찰 요청을 보내고, 그 중 가장 높은 가격을 선택합니다.
이 구조의 핵심은 경쟁을 동시화했다는 점입니다. 모든 수요가 동일한 시점에 같은 인벤토리를 놓고 경쟁하기 때문에, 매체사는 더 이상 순서에 의해 가격이 왜곡되지 않습니다. 결과적으로 각 임프레션이 시장에서 형성 가능한 최고 가격에 가까운 값으로 거래됩니다.
기술적으로는 Prebid.js 같은 오픈소스 라이브러리가 이 과정을 중개합니다. 브라우저에서 여러 SSP의 입찰을 동시에 받아 최고가를 결정하고, 그 값을 광고 서버(Ad Server)로 전달해 최종 낙찰을 진행합니다.
(1) 무엇이 실제로 바뀌었나
헤더 비딩 도입 이후 매체사의 수익 구조는 두 가지 측면에서 바뀌었습니다.
첫째, 가격 발견(price discovery)이 정상화되었습니다. 모든 수요가 동시에 경쟁하면서 각 임프레션의 시장 가격이 더 정확하게 반영됩니다.
둘째, SSP 간 경쟁이 본격화되었습니다. 과거에는 워터폴 상단에 들어가기 위한 경쟁이었지만, 이제는 동일한 인벤토리를 두고 실시간으로 가격 경쟁을 벌이게 됩니다.
이 두 가지 변화로 인해 매체사는 일반적으로 워터폴 대비 더 높은 eCPM을 확보하게 되었고, 산업 전반에서 헤더 비딩은 사실상의 표준 구조로 자리잡았습니다.
(2) 클라이언트 사이드와 서버 사이드의 분기
헤더 비딩은 입찰을 어디서 처리하느냐에 따라 두 가지 구현 방식으로 나뉩니다. 그리고 이 방식은 각각 별도의 기술 스택과 도구를 갖고 있습니다.
| 비교 축 | 클라이언트 사이드(Client-side, 브라우저) | 서버 사이드(Server-side, 서버) |
|---|---|---|
| 입찰 처리 위치 | 사용자 브라우저 | 별도 서버 |
| 대표 구현 | Prebid.js | Prebid Server, Amazon TAM |
| 페이지 로딩 속도 | 느림 (브라우저 부하) | 빠름 |
| 투명성 | 높음 (입찰 로그 확인 가능) | 낮음 |
| 사용자 데이터 활용 | 높음 (쿠키 매칭 용이) | 낮음 (쿠키 동기화 제한) |
| 입찰 참여자 수 | 제한적 | 확장 가능 |
클라이언트 사이드 헤더 비딩의 핵심 도구는 프리비드.js(Prebid.js)입니다. 매체사가 페이지 <head>에 이 라이브러리를 삽입하면, 브라우저가 여러 SSP에 동시에 입찰 요청을 보내고 결과를 취합합니다. 가장 널리 쓰이는 표준 구현 방식입니다.
서버 사이드 헤더 비딩은 이 과정을 별도 서버에서 처리합니다. 프리비드 서버(Prebid Server)나 아마존 TAM(Transparent Ad Marketplace) 같은 솔루션이 대표적입니다. 브라우저 부하를 줄이고 더 많은 SSP를 연결할 수 있지만, 쿠키 기반 사용자 매칭이 어려워져 입찰 품질이 떨어질 수 있습니다.
실무에서는 두 방식을 혼합한 하이브리드 구조가 일반적입니다. 주요 수요는 클라이언트 사이드에서 확보하고, 추가 수요 확장은 서버 사이드로 보완하는 방식입니다.
(3) 헤더 비딩이 등장한 진짜 이유
헤더 비딩의 등장 배경에는 권력 균형의 문제가 있습니다. 워터폴 시대에는 Google AdX가 매체사의 광고 서버(Google Ad Manager) 안에서 우선 호출되는 구조였습니다. 다른 SSP보다 먼저 답할 권리를 갖고 있었고, 이는 곧 다른 SSP들이 더 높은 가격을 낼 의사가 있어도 기회를 받지 못한다는 뜻이었습니다.
헤더 비딩은 정확히 그 우대 구조를 깨려고 만들어졌습니다. 페이지의 <head>에서 모두를 동시에 호출하면 Google AdX는 다른 SSP들과 동등한 위치에서 가격으로만 경쟁하게 됩니다. Google은 결국 자체적인 서버 사이드 헤더 비딩 솔루션 오픈 비딩(Open Bidding)으로 대응했지만, 산업 권력은 그 사이 한 차례 재분배됐습니다.
4. 거래 4유형: 모든 거래가 개방형 경매는 아니다
프로그래매틱 거래는 하나의 방식이 아닙니다. 경매 기반 거래부터 사전 계약 기반 거래까지 네 가지 유형이 공존하며, **가격을 언제 결정하느냐(사전 vs 실시간)**와 노출을 보장하느냐에 따라 구분됩니다.
| 유형 | 영문 약어 | 가격 결정 시점 | 노출 보장 | 광고주 접근 | 거래 성격 |
|---|---|---|---|---|---|
| 보장형 직거래 | PG (Programmatic Guaranteed) | 사전 확정 | 있음 | 1:1 계약 | 자동화된 직거래 |
| 우선 협상 거래 | PD (Preferred Deals) | 사전 확정 | 없음 | 계약 광고주 | 우선 구매권 |
| 초청 경매 | PMP (Private Marketplace) | 실시간 경매 | 없음 | 초청 광고주 | 제한된 경매 |
| 개방 경매 | OA (Open Auction) | 실시간 경매 | 없음 | 누구나 | 공개 경매 |
이 네 가지는 단순히 기술이 아니라 인벤토리 가치에 따라 다른 방식이 선택되는 구조입니다.
이 네 유형은 서로 다른 방식이라기보다, 하나의 흐름 위에 놓여 있습니다.
[통제·보장 ↑] [경쟁·확장 ↑]
───────────────────────────────────────────────────────────────────▶
PG PD PMP OA
가격 확정+보장 가격 확정+비보장 경매+제한 참여 경매+전체 공개
왼쪽으로 갈수록 통제와 안정성(가격·물량 확정)이 강해지고, 오른쪽으로 갈수록 경쟁과 확장성(참여자 증가, 경매 기반)이 커집니다.
1) PG: 거래를 먼저 확정하고, 집행을 자동화한다
Programmatic Guaranteed는 가장 전통적인 광고 거래에 가깝습니다. 광고주와 매체사가 가격, 물량, 기간을 사전에 확정하고, 실제 집행만 프로그래매틱 시스템으로 처리합니다. 여기서 ‘Programmatic’은 경매를 의미하는 것이 아니라 이미 확정된 계약을 시스템으로 자동 집행한다는 의미입니다.
핵심은 경매가 아니라 계약 기반 보장입니다. 광고주는 노출량을 확정적으로 확보하고, 매체사는 수익을 미리 고정할 수 있습니다. 메인 지면, CTV, 브랜드 캠페인처럼 “반드시 노출되어야 하는 자리”에 사용됩니다.
2) PD: 가격은 정해두고, 살지는 선택한다
Preferred Deal은 PG보다 한 단계 느슨한 구조입니다. 가격은 사전에 합의하지만, 광고주는 각 노출 기회를 보고 구매 여부를 선택할 수 있습니다.
즉, 다음과 같은 구조입니다.
- 매체는 “이 가격에 먼저 살 기회를 준다”
- 광고주는 “마음에 들면 산다”
물량은 보장되지 않지만, 프리미엄 인벤토리를 경매에 넘기기 전에 선별된 광고주에게 먼저 제공하는 방식입니다.
3) PMP: 제한된 참여자끼리 경쟁한다
Private Marketplace는 초청된 광고주만 참여하는 경매입니다. 구조는 RTB와 동일하지만, 참여자가 제한됩니다.
이 방식의 핵심은 품질 통제입니다.
매체사는 광고주를 선별해 브랜드 안전을 유지하고, 광고주는 검증된 인벤토리에 접근할 수 있습니다.
최근 몇 년간 PMP 비중이 빠르게 증가한 이유도 여기에 있습니다. 개방형 경매에서는 광고 사기, 저품질 매체(MFA, Made for Advertising) 문제가 발생할 수 있기 때문에, 광고주들이 통제 가능한 환경으로 이동하고 있는 것입니다.
4) OA: 모든 수요가 경쟁하는 시장
Open Auction은 가장 순수한 형태의 프로그래매틱입니다. 누구나 참여할 수 있고, 가격은 실시간 경매로 결정됩니다.
도달 범위는 가장 넓지만, 인벤토리 품질과 가격 변동성이 큽니다. 그래서 성과 마케팅처럼 대량 트래픽과 효율이 중요한 영역이나, 매체사가 다른 방식으로 판매하지 못한 잔여 인벤토리를 처리하는 데 주로 사용됩니다.
5) 매체사의 실제 전략
매체사는 이 네 가지를 동시에 사용합니다.
- 프리미엄 지면 → PG / PD / PMP로 보호
- 남는 지면 → OA로 수익화
이렇게 가치에 따라 다른 거래 방식을 적용하는 다층 구조가 현재 프로그래매틱 시장의 기본 형태입니다.
5. 경매 메커니즘: 2차가 경매, 1차가 경매, 비드 셰이딩
경매에서 어떤 가격이 최종 지불액이 되는지는 단순하지 않습니다. 산업이 한 번 경매 방식을 통째로 바꾸면서 새로운 문제가 생겼고, 그 답으로 비드 셰이딩이라는 도구가 등장했습니다.
1) 옛 표준: 2차가 경매(2nd-price Auction)
2010년대 중반까지 RTB의 표준은 2차가 경매였습니다. 학계에서는 비크리(Vickrey) 경매로 알려진 방식입니다. 1등이 낙찰받되, 자기 입찰가가 아니라 2등 가격에 1센트 더 낸 만큼만 지불합니다.
예를 들어 세 개의 DSP가 각각 100원, 70원, 50원을 입찰했다면 100원을 낸 광고주가 낙찰되지만 실제 지불 가격은 약 70원입니다.
이 방식의 장점은 광고주가 자신의 가치 판단을 그대로 입찰해도 된다는 점입니다. 어차피 실제 결제는 경쟁자 기준으로 이뤄지기 때문에 입찰 전략이 단순합니다.
문제는 헤더 비딩 환경에서 발생했습니다. 다수의 SSP가 동시에 경매를 열면서 “2등 가격”의 기준이 서로 달라졌습니다. 어떤 SSP는 내부 경쟁 기준을, 다른 SSP는 외부 경쟁까지 포함한 값을 기준으로 삼으면서 동일한 입찰이라도 실제 지불 가격이 달라졌습니다. 광고주는 비용을 예측하기 어려워졌고, 경매 구조에 대한 신뢰가 흔들렸습니다.
2) 현재 표준: 1차가 경매(1st-price Auction)
이 혼란을 정리하기 위해 산업은 2017~2019년 사이에 1차가 경매로 전환했습니다. AppNexus·Index Exchange·OpenX·Pubmatic 등 주요 SSP가 2017~2018년에 먼저 움직였고, 마지막으로 구글 애드 매니저(Google Ad Manager)가 2019년 8월에 전환을 마치며 산업 전반의 표준 전환이 마무리됐습니다.
| 비교 축 | 2차가 경매 | 1차가 경매 |
|---|---|---|
| 지불 가격 | 2등 가격 + 1센트 | 자기 입찰가 |
| 광고주 전략 | 진짜 가치 그대로 | 깎아서 입찰 |
| 산업 표준 시점 | ~2018년까지 | 2019년 이후 |
| 핵심 문제 | 헤더 비딩에서 가격 왜곡 | 과지불 위험 |
1차가 경매는 단순하고 투명하지만 새로운 문제를 만들었습니다. 이 문제를 이해하려면 먼저 광고주가 왜 입찰을 하는지부터 봐야 합니다.
광고는 사용자가 페이지를 열 때마다 생성되는 개별 노출 단위로 거래됩니다. 매번 하나의 광고 자리가 생기고, 그 자리마다 여러 광고주가 동시에 경쟁합니다.
광고주는 이때 “이 노출에 얼마까지 낼 수 있는가”를 기준으로 입찰가를 넣습니다. 이 금액은 실제 지불 가격이 아니라, 그 노출이 만들어낼 것으로 기대하는 가치의 상한선입니다. 즉, “이 이상 내면 손해”라는 기준선입니다.
예를 들어 한 광고주가 100원까지는 낼 수 있다고 판단해 입찰했고, 다른 광고주는 50원을 넣었다고 가정하면, 이 광고주가 경매에서 승리합니다.
2차가 경매에서는 이 경우 실제 지불 가격이 50원 수준에 맞춰졌습니다. 반면 1차가 경매에서는 낙찰과 동시에 100원을 그대로 지불하게 됩니다.
실제 경쟁 수준은 50원이었음에도 불구하고 두 배의 가격을 지불하게 되는 구조가 됩니다. 즉, 광고주는 “최대 지불 가능 금액”을 넣었을 뿐인데, 그 금액이 그대로 결제되면서 과지불이 발생합니다.
3) 비드 셰이딩(Bid Shading): 1차가 경매 시대의 보정 도구
비드 셰이딩은 이 과지불 문제의 답으로 등장했습니다. DSP가 광고주 대신 입찰가를 적정선으로 조정하는 알고리즘입니다.
광고주가 100원을 넣었더라도, 해당 인벤토리의 실제 낙찰 가격이 과거 데이터 기준으로 60~70원 구간에 형성되어 있다면 DSP는 입찰가를 그 수준으로 낮춰 제출합니다. 낙찰 확률을 유지하면서 지불 가격을 줄이는 방식입니다.
이 기능은 DSP의 핵심 경쟁 영역입니다. 같은 캠페인을 같은 조건으로 집행해도 어떤 DSP를 쓰느냐에 따라 실제 지불 가격과 성과가 달라질 수 있습니다.
한계도 있습니다. 과거 데이터에 기반하기 때문에 시장 상황이 급변하면 예측이 어긋날 수 있습니다. 너무 많이 낮추면 낙찰을 놓치고, 너무 적게 낮추면 과지불이 발생합니다. 이 균형을 맞추는 것이 알고리즘 경쟁의 핵심입니다.
4) 최저 입찰가(Floor Price): 매체 측의 안전장치
매체사 쪽에도 가격 통제 장치가 있습니다. 최저 입찰가가 그것입니다. 특정 인벤토리를 일정 가격 이하로는 판매하지 않겠다는 기준입니다.
예를 들어 최저 입찰가가 80원으로 설정되어 있다면, 모든 입찰이 80원 미만일 경우 해당 노출은 판매되지 않습니다. 반대로 최저 입찰가를 낮추면 더 많은 낙찰이 발생하지만 평균 단가는 떨어집니다.
최저 입찰가에는 두 종류가 있습니다. 하드 플로어(Hard Floor)는 해당 가격 미만 입찰을 모두 거부하는 기준이고, 소프트 플로어(Soft Floor)는 입찰 전략에 영향을 주는 참고 기준입니다.
| 구분 | 하드 플로어(Hard Floor) | 소프트 플로어(Soft Floor) |
|---|---|---|
| 정의 | 설정한 가격 미만 입찰을 모두 거부 | 가격 참고 기준으로 활용 |
| 작동 방식 | 기준 미만 입찰 시 경매 참여 불가 또는 낙찰 불가 | 기준 이상/미만에 따라 경매 로직 또는 가격 적용 방식 변경 |
| 목적 | 최소 수익 보장 | 가격 유도 및 수익 최적화 |
| 영향 | 인벤토리 미충족(unfilled) 가능성 증가 | 낙찰률 유지하면서 평균 단가 조정 |
| 활용 방식 | 절대 하한선 설정 | 동적 가격 전략, 경매 방식 전환 등에 활용 |
최저 입찰가를 너무 높게 잡으면 인벤토리가 채워지지 않고, 너무 낮게 잡으면 수익을 놓칩니다. 매체사는 트래픽과 수요 상황에 따라 이 값을 계속 조정합니다.
6. 공급 경로 최적화(SPO): 광고주가 같은 자리를 더 좋은 경로로
같은 인벤토리를 여러 SSP·광고 거래소가 동시에 팔 수 있다는 사실이 산업의 비밀입니다. 매체사가 자기 인벤토리를 여러 SSP에 동시 등록하기 때문입니다. 광고주 입장에서는 같은 자리를 두고 여러 경로로 입찰 요청이 들어옵니다.
이 자체는 문제가 아닙니다. 문제는 경로마다 수수료, 투명성, 사기 위험이 다르다는 점입니다. 같은 인벤토리를 더 비싼 수수료를 떼는 경로로 사거나, 검증되지 않은 경로로 사면 광고주는 손해입니다. 이걸 정리하는 작업이 공급 경로 최적화(SPO, Supply Path Optimization)입니다.
SPO는 DSP가 같은 사용자·같은 자리에 대해 들어온 다수의 입찰 요청을 비교해, 가장 짧고 투명하고 수수료가 낮은 경로만 입찰 대상으로 남깁니다. 결과적으로 광고주는 더 적은 SSP·광고 거래소와 거래하되, 더 직접적인 경로를 선호하게 됩니다.
SPO가 중요해진 이유는 ANA의 2023년 Programmatic Media Supply Chain Transparency Study가 결정적이었습니다. 광고주가 DSP에 투입한 1달러 중 사용자에게 의미 있는 광고로 도달하는 금액은 36센트뿐이라는 결과가 나왔습니다. 나머지는 중간 수수료, 측정 불가능 임프레션, 사기, 그리고 다음 절에서 다룰 MFA 사이트로 흩어집니다. 이 36센트라는 숫자가 광고주들에게 충격으로 받아들여졌고, 이후 산업 전체가 SPO와 PMP 방향으로 빠르게 이동하는 동력이 됐습니다.
7. 광고 사기: 표준이 막으려고 했던 것
지금까지의 메커니즘은 모든 참여자가 정직하다는 가정 위에 작동합니다. 그런데 자동화가 깊어질수록 그 가정이 무너지는 자리가 많아졌습니다. 광고 사기가 어떤 형태로 일어나는지 짚어야, 그다음 절의 ads.txt 가족이 왜 만들어졌는지가 자연스럽게 이해됩니다.
1) 도메인 위장(Domain Spoofing, 도메인 스푸핑)
가장 흔한 사기 유형이 도메인 위장입니다. 가짜 사이트가 입찰 요청에 “나는 nytimes.com이다”라는 거짓 도메인 정보를 담아 보내면, 광고주는 NYT 같은 프리미엄 매체에 광고가 나가는 줄 알고 비싼 입찰가를 제출합니다. 실제로는 듣도 보도 못한 사이트에 광고가 노출되고, 그 사이트 운영자는 NYT급 CPM을 받아갑니다.
2) MFA(Made for Advertising): 광고 노출만을 위한 사이트
MFA는 콘텐츠는 거의 없고 광고로 가득 찬 저품질 사이트를 가리킵니다. 자동 생성 콘텐츠와 SEO 조작으로 트래픽을 끌어모은 뒤 그 트래픽에 광고를 무한히 노출시키는 모델입니다. 사용자에게는 가치가 거의 없고, 광고주에게는 임프레션 숫자만 늘어날 뿐 실제 효과가 없습니다.
MFA가 산업의 얼마나 많은 부분을 차지하는지의 추정치는 시점에 따라 빠르게 변했습니다. ANA의 2023년 study는 광고비의 15%, 임프레션의 21%가 MFA로 흘러갔다고 보고했습니다. 그러나 이 충격적인 수치가 공개된 뒤 광고주들이 MFA 차단·PMP 이동·SPO 도입으로 빠르게 대응하면서, 2025년 4분기 기준 ANA Benchmark에서는 MFA 비중이 광고비의 0.8% 수준까지 감소했습니다(직전 분기 2.3%에서 65% 추가 감소). 즉 MFA는 한때 산업의 큰 누수원이었지만, 광고주들이 능동적으로 막아내면서 절대 수치는 줄어든 상태입니다. 다만 PMP 안에서도 MFA가 일부 섞여 들어온다는 보고가 있어, 완전히 사라진 문제는 아닙니다.
3) 무효 트래픽(IVT): 사람이 아닌 트래픽
무효 트래픽(IVT, Invalid Traffic)은 광고를 본 주체가 사람이 아닌 경우를 모두 포괄합니다. 미디어 평가 위원회(MRC, Media Rating Council)가 두 가지로 분류합니다.
| 유형 | 의미 | 예시 |
|---|---|---|
| 일반 IVT(GIVT, General IVT) | 명백한 비인간 트래픽 | 검색 엔진 크롤러, 데이터 센터 봇 |
| 정교한 IVT(SIVT, Sophisticated IVT) | 사람처럼 행동하는 정교한 봇 | 마우스 움직임을 흉내 내는 봇넷, 클릭 농장 |
GIVT는 표준 필터로 어느 정도 걸러집니다. 문제는 SIVT입니다. 사람처럼 페이지를 스크롤하고 클릭하기 때문에 단순 패턴 분석으로는 잡히지 않고, 머신러닝 기반 행동 분석이 필요합니다.
4) 모바일·앱 사기
모바일과 앱 환경은 사기 유형이 더 다양합니다. 앱 위장(App Spoofing, 앱 스푸핑), SDK 위장(SDK Spoofing, SDK 스푸핑), 설치 직전 가짜 클릭 삽입(Click Injection), 거대량 가짜 클릭으로 마지막 클릭을 가로채는 클릭 플러딩(Click Flooding) 같은 유형들이 있습니다. 이 중 일부는 모바일 어트리뷰션의 라스트 클릭 모델을 노린 사기인데, 이 부분은 7편(측정과 어트리뷰션)에서 다시 깊이 다룹니다.
이런 사기 유형들의 공통점은 자동화된 거래를 악용한다는 것입니다. 100ms 안에 거래가 끝나는 환경에서는 누가 누구에게 무엇을 팔고 있는지 일일이 검증할 시간이 없습니다. 그 검증을 거래 이전 단계의 인프라로 옮긴 것이 다음 절에서 짚을 표준들입니다.
8. 신뢰 인프라: ads.txt와 그 친구들
광고 사기에 대한 산업의 답은 IAB Tech Lab이 만든 네 개의 표준입니다. ads.txt, app-ads.txt, sellers.json, SupplyChain Object. 이 네 개가 함께 작동해야 거래 경로의 신뢰가 확보됩니다.
| 표준 | 발행 주체 | 어디에 올라가나 | 무엇을 담나 | 시점 |
|---|---|---|---|---|
| ads.txt | 매체사 | 매체사 도메인 root | 권한 있는 판매자 명단 | 거래 이전 |
| app-ads.txt | 앱 개발사 | 개발사 사이트 root | 앱 인벤토리 권한자 명단 | 거래 이전 |
| sellers.json | SSP·광고 거래소 | SSP 사이트 | 다루는 판매자 정체 | 거래 이전 |
| SupplyChain Object | DSP에 도달하는 입찰 | 입찰 요청(Bid Request) 내부 | 거래 경로의 모든 노드 | 거래 시점 |
1) ads.txt: 인증된 디지털 판매자
ads.txt는 2017년에 도입된 가장 단순한 표준입니다. 매체사가 자기 도메인 root에 텍스트 파일 하나를 올려둡니다. 그 파일에는 “내 인벤토리를 팔 권한이 있는 회사는 다음과 같다”라는 목록이 적혀 있습니다.
광고주(또는 DSP)는 입찰 시점에 그 매체의 ads.txt를 읽어 “이 입찰 요청을 보낸 SSP가 정말 권한 있는 판매자인가”를 검증합니다. 권한이 없으면 입찰을 거부합니다. 도메인 위장이 정확히 이 메커니즘으로 차단됩니다. 가짜 도메인이 가짜 인벤토리를 팔겠다고 신호를 보내도, 진짜 도메인의 ads.txt 명단에 그 판매자가 없으면 거래가 성사되지 않습니다.
ads.txt는 산업에 빠르게 채택됐습니다. 출시 1년 만에 주요 매체 절반 이상이 도입했고, 현재는 프로그래매틱으로 거래되는 주요 매체의 절대 다수가 ads.txt를 갖고 있습니다. 도입 비용이 거의 없는 데다, Google Display & Video 360을 비롯한 주요 DSP들이 “ads.txt 없는 매체는 사지 않는다”는 정책을 채택하면서 사실상 의무 표준이 됐습니다.
2022년 ads.txt 1.1 업데이트에서는 OWNERDOMAIN과 MANAGERDOMAIN이라는 새 항목이 추가됐습니다. 다중 사이트를 운영하는 매체와 수익 관리자(yield manager)의 관계를 명시할 수 있게 한 것입니다. SPO 시대에 들어오면서 누가 누구를 대신해 인벤토리를 파는지를 더 정확히 표시할 필요가 생겼기 때문입니다.
2) app-ads.txt: 앱 환경의 ads.txt
ads.txt는 웹 도메인 환경을 전제로 만들어졌습니다. 앱은 도메인이 없기 때문에 같은 방식으로 적용되지 않았고, 2019년에 별도 표준이 나왔습니다.
app-ads.txt는 앱 개발사의 웹사이트 root에 올라갑니다. 앱스토어에 등록된 개발사 사이트 정보를 통해 광고주가 그 앱이 누구의 것인지 확인하고, 그 사이트의 app-ads.txt를 읽어 권한 있는 판매자인지 검증합니다.
앱 환경의 채택률은 웹보다 낮습니다. 2026년 4월 기준 구글 플레이 전체 앱의 약 24%가 app-ads.txt를 도입한 상태이고, 상위 1,000개 앱으로 좁히면 66% 정도입니다. 작은 앱 개발자가 자체 웹사이트를 갖고 있지 않거나 유지하지 않는 경우가 많아 채택이 느린 것이 한 원인입니다. 다만 주요 SSP·DSP들이 app-ads.txt 없는 앱 인벤토리를 점차 거부하면서 채택률은 계속 올라가고 있습니다.
3) sellers.json: 판매자의 정체 공개
ads.txt가 매체사가 발행하는 표준이라면, sellers.json은 판매자(SSP·광고 거래소) 측이 발행하는 표준입니다. 각 판매자가 자기 사이트에 sellers.json 파일을 올려, “내가 다루는 판매 대상은 누구이고, 그 판매자들의 정체는 무엇인가”를 공개합니다.
ads.txt와 sellers.json이 함께 작동하면 양방향 검증이 가능해집니다. 매체사 측에서 “이 SSP에게 팔 권한을 줬다”고 선언하고, SSP 측에서 “내가 이 매체를 다룬다”고 선언합니다. 두 선언이 일치해야 거래가 정당하다고 판단할 수 있습니다.
4) SupplyChain Object: 거래 경로의 모든 노드 공개
마지막 표준인 SupplyChain Object는 OpenRTB의 입찰 요청 안에 포함되는 객체입니다. 광고가 매체에서 광고주에게 도달하기까지 거쳤던 모든 중간 노드(SSP, 광고 거래소, 리셀러(Reseller))를 명시합니다.
이전 세 표준이 거래 이전에 정적으로 검증하는 도구라면, SupplyChain Object는 거래 시점에 동적으로 검증하는 도구입니다. 광고주가 입찰을 결정하기 직전에 “이 거래는 어떤 경로로 왔는가”를 확인하고, 그 경로가 비정상적으로 길거나 검증되지 않은 노드를 포함하면 입찰을 거부할 수 있습니다.
100ms 안의 RTB는 OpenRTB라는 공통 언어, 헤더 비딩이라는 동시 입찰 방식, 거래 4유형의 선택지, 1차가 경매와 비드 셰이딩의 경매 메커니즘, SPO를 통한 공급 경로 최적화, 그리고 ads.txt 가족의 신뢰 인프라가 함께 작동해야만 굴러갑니다. 이 인프라들은 따로따로 만들어진 게 아니라, 0.1초 안의 자동화 거래가 만들어낸 문제(가격 왜곡, 매체 수익 손실, 사기, 불투명한 공급 경로)에 산업이 차례로 답을 내놓은 결과물입니다.
거래 메커니즘은 여기까지 봤습니다. 그런데 정작 광고가 “나에게 맞는 광고”가 되는 원리는 다른 차원에 있습니다. 입찰 요청에 어떤 사용자 정보가 담기는가, 그 식별자들이 쿠키 종말 이후 어떻게 변했는가. 다음 편에서 다룹니다.
프로그래매틱 광고 시리즈
(2) 광고가 거래되는 시장: 오픈 웹, 월드 가든, 리테일 미디어
(4) RTB와 헤더 비딩의 메커니즘: 100ms 안의 경매
(5) 데이터와 식별자: 광고가 “나에게 맞는 광고”가 되는 원리
(6) 크리에이티브와 캠페인 운영: 광고를 만들고 올리기
(7)-① 측정·어트리뷰션·검증: 광고비와 성과 측정의 기본
답글 남기기