RTB(실시간 입찰)는 프로그래매틱 광고의 기반이 되는 경매 프로토콜입니다. 각 광고 노출이 50~150밀리초 내에 경매됩니다 — SSP가 입찰 요청을 발사하면, 여러 DSP가 평가하고 입찰로 응답하며, 경매가 해결되고 낙찰 크리에이티브가 렌더링됩니다. OpenRTB 사양(IAB Tech Lab 관리)은 프로토콜을 정의합니다. 입찰 요청의 형태, 포함 필드, 입찰이 반환해야 하는 내용 등을 규정합니다.
50~150ms 경매 타임라인
- 0ms — 사용자가 퍼블리셔 앱 / 페이지를 엽니다. 앱 / 페이지가 SDK에 광고 요청을 발사합니다.
- 5~20ms — SSP가 요청을 받아 오디언스 데이터로 보강하고 광고 거래소에 브로드캐스트합니다.
- 20~100ms — 광고 거래소가 연결된 DSP에 입찰 요청을 브로드캐스트합니다. 각 DSP가 광고주의 타겟팅 규칙에 따라 요청을 평가하고, 입찰 가격을 계산하여 응답합니다.
- 100~130ms — 거래소가 입찰을 수집하고 경매를 실행하여 낙찰자를 선정합니다.
- 130~150ms — 낙찰 크리에이티브 URL이 반환되고 광고가 렌더링됩니다.
~150ms를 초과하는 지연은 광고 슬롯 포기를 유발합니다(노출이 타임아웃되고 대체 광고가 렌더링됨). 느리게 응답하는 입찰자는 불이익을 받습니다 — 거래소는 느린 DSP를 경매에서 제외합니다.
경매 유형
- 1차가 경매: 낙찰자가 자신의 입찰가를 지불합니다. 2026년 업계 표준 — Google AdX와 대부분의 주요 SSP가 2017~2019년 사이 2차가에서 1차가로 전환했습니다. 광고주가 더 전략적으로 입찰해야 합니다(최고가가 아닌 낙찰 예상가를 입찰).
- 2차가 경매: 낙찰자가 2위 입찰가보다 1센트 더 지불합니다. 2010년대 후반 전환 이전까지 프로그래매틱에서 널리 사용된 클래식 eBay 방식 메커니즘. 이론적으로는 솔직한 입찰(최고가를 써도 낙찰 후 과다 지불 없음)을 유도하지만, 불투명한 메커니즘과 헤더 비딩으로 인해 실제로는 불안정했습니다.
모바일 앱에서의 RTB
- SDK 기반: 앱에 내장된 SDK(일반적으로 퍼블리셔의 미디에이션 SDK — AppLovin MAX, ironSource LevelPlay, Google Admob)가 로컬에서 입찰 요청을 처리합니다. SDK가 요청을 발사하고, 입찰을 받아 낙찰 크리에이티브를 렌더링합니다.
- 서버 간(S2S): 퍼블리셔의 백엔드가 입찰 요청을 처리하여 서버에서 거래소를 호출합니다. 입찰 로직에 대한 더 많은 컨트롤을 원하는 퍼블리셔를 위한 헤더 비딩 방식 경매에 사용됩니다.
모바일에서의 입찰 요청 페이로드에는 앱 ID, 광고 형식, 사용자 신호(사용 가능한 경우), 기기 신호, 위치 정보(허가 시), 콘텐츠 컨텍스트가 포함됩니다. iOS에서 post-ATT 이후 사용자 수준 신호가 크게 줄어들어 — 입찰 요청이 Android나 pre-ATT iOS보다 훨씬 덜 풍부해졌습니다.
일반적인 RTB 함정
- 입찰 타임아웃: 느리게 응답하는 DSP는 경매에서 제외됩니다. 응답 시간을 100ms 미만으로 유지하세요.
- 오래된 오디언스 데이터: 5분 전에는 신선했지만 지금은 오래된 오디언스 신호를 기준으로 입찰하는 것. 실시간 오디언스 업데이트가 중요합니다.
- 경매 담합: 여러 입찰자가 데이터 소스를 공유할 때 입찰이 의심스럽게 상관관계를 가질 수 있습니다. 성숙한 DSP의 반담합 분석.
- 입찰 쉐이딩: 1차가 경매에서 정교한 DSP는 역사적 낙찰가를 기반으로 입찰을 하향 조정합니다 — 최고가가 아닌 낙찰 예상가를 입찰합니다. 단순 입찰은 과다 지불로 이어집니다.