광고 네트워크 워터폴 vs 헤더비딩 차이와 선택법
- 워터폴은 정해진 순서로, 헤더비딩은 여러 수요처에 병렬로 입찰을 요청합니다.
- 병렬 입찰도 타임아웃과 광고 적격성 때문에 최고가 낙찰을 보장하지 않습니다.
- 웹과 앱은 구현 환경이 달라 각 플랫폼에 맞는 비딩 방식을 검토해야 합니다.
워터폴과 헤더비딩의 핵심 차이는 광고 수요처에 입찰 기회를 주는 순서입니다. 워터폴은 미리 정한 순서대로 네트워크에 광고를 요청하고, 헤더비딩은 여러 수요처에 동시에 입찰을 요청해 결과를 비교합니다. 다만 헤더비딩이 항상 최고가를 보장하거나 지연을 없애는 것은 아닙니다. 입찰 제한 시간, 광고 소재 검증, 수수료와 광고 서버의 최종 선택까지 함께 봐야 합니다.
워터폴과 헤더비딩은 어떻게 작동할까
워터폴: 정해 둔 순서대로 채우는 방식
광고 워터폴은 광고 미디에이션(여러 광고 수요처를 연결하고 노출을 조정하는 시스템)이 비어 있는 광고 슬롯을 네트워크별로 차례로 요청하는 방식입니다. 설정한 순서나 eCPM(광고 1,000회 노출당 유효 수익)을 바탕으로 첫 번째 수요처에 기회를 주고, 광고가 채워지지 않으면 다음 수요처로 넘어갑니다. 네트워크가 광고를 반환하면 뒤쪽 네트워크는 해당 요청에 입찰할 기회를 얻지 못할 수 있습니다.
순서는 고정값일 수도 있고, 네트워크가 제공한 과거 수익 데이터나 자동 최적화 기능에 따라 조정될 수도 있습니다. 따라서 워터폴을 단순히 “항상 과거 eCPM 순으로 정렬하는 방식”이라고만 이해하면 실제 설정과 다를 수 있습니다. 네트워크별 기본 eCPM 값이 오래되거나 특정 지역·광고 형식의 성과를 대표하지 못하면 우선순위가 실제 수익 기회와 어긋날 수 있습니다.
헤더비딩: 여러 수요처의 응답을 모아 경쟁시키는 방식
헤더비딩은 보통 웹페이지에서 여러 광고 거래소나 수요 파트너에 입찰 요청을 병렬로 보내고, 정해진 시간 안에 들어온 응답을 광고 서버에 전달해 경쟁시키는 구조입니다. 웹에서는 Prebid.js 같은 클라이언트 측 솔루션이나 서버 측 입찰 구성을 사용할 수 있습니다. 이름의 ‘헤더’는 웹 구현에서 페이지 헤더 영역의 코드가 입찰을 시작하던 방식에서 왔습니다.
앱에는 웹페이지의 헤더가 없으므로 앱 미디에이션의 비딩 기능이나 서버 간 입찰처럼 플랫폼에 맞는 연동을 사용합니다. 이런 앱 환경을 설명할 때 ‘인앱 비딩’ 또는 ‘병렬 비딩’이라는 말을 쓰기도 합니다. 제품마다 지원하는 네트워크와 경쟁 방식이 다르므로 용어만 보고 웹 헤더비딩과 동일한 구현이라고 가정하지 말고, 사용 중인 SDK와 미디에이션 문서를 확인해야 합니다.
기억할 기준: 워터폴은 순차 요청, 헤더비딩은 여러 수요처의 병렬 입찰 요청입니다. 병렬 요청의 응답이 늦거나 광고가 게재 조건을 충족하지 못하면 해당 입찰은 최종 경쟁에서 빠질 수 있습니다.
두 방식의 차이를 한눈에 비교하기
| 비교 항목 | 워터폴 | 헤더비딩·병렬 비딩 |
|---|---|---|
| 요청 흐름 | 수요처를 차례로 호출 | 여러 수요처에 동시에 요청 |
| 우선순위 기준 | 설정 순서, 예상 eCPM, 최적화 설정 | 응답 입찰가와 플랫폼의 경쟁 규칙 |
| 주요 점검점 | 기본 CPM 값, 순서, 미충족 구간 | 타임아웃, 응답률, 연동·호출 비용 |
| 적합할 수 있는 상황 | 비딩 미지원 네트워크를 연결할 때 | 실시간 경쟁을 넓히고 운영 역량이 있을 때 |
최고 입찰가와 실제 수익은 다를 수 있습니다
헤더비딩에서 가장 높은 숫자의 응답이 왔다고 해서 항상 그 광고가 노출되는 것은 아닙니다. 응답이 시간 제한 안에 도착했는지, 광고 소재와 크기가 적격인지, 가격 하한선에 걸리지 않는지, 광고 서버가 다른 광고 후보와 비교해 어떤 선택을 하는지에 따라 결과가 달라집니다. 플랫폼에 따라 수수료를 반영한 순수익이나 노출이 실제로 발생할 가능성 등도 비교에 영향을 줄 수 있습니다.
따라서 보고서에서 입찰가만 따로 보지 말고, 광고 서버에서 승리한 비율과 실제 노출, 순수익을 연결해 해석해야 합니다. eCPM 상승만으로 성과를 판단하면 광고 호출이 늘어 페이지 반응이나 앱 이용 경험이 나빠지는 경우를 놓칠 수 있습니다.
장점과 비용: 수익만 보지 말아야 하는 이유
워터폴이 유용한 경우와 한계
워터폴은 구조가 비교적 단순하고, 비딩 연동을 제공하지 않는 광고 네트워크도 수요로 포함할 수 있습니다. 운영팀이 특정 파트너의 지역별·형식별 성과를 반영해 순서를 관리하기도 쉽습니다. 반면 첫 번째 네트워크가 광고를 채우면 뒤에 있는 파트너는 같은 노출 기회를 받지 못할 수 있습니다. 낮은 기본 CPM이 설정되어 있으면 더 높은 지불 의사가 있는 후순위 수요를 놓칠 가능성도 있습니다.
헤더비딩의 이점과 운영 부담
동시에 여러 곳의 입찰을 모으면 한 곳의 고정 순서에 의존하는 정도를 줄이고 더 많은 수요를 경쟁에 참여시킬 수 있습니다. 하지만 참여자와 코드가 늘수록 요청·응답 추적, 어댑터와 SDK 관리, 타임아웃 조정, 광고 품질 점검이 복잡해집니다. 클라이언트 측 요청은 사용자의 기기와 네트워크 환경 영향을 받을 수 있고, 서버 측 입찰은 브라우저 부담을 덜 수 있는 대신 사용자 식별 신호나 입찰 범위가 달라질 수 있어 결과를 따로 비교해야 합니다.
- 수익: 요청수나 최고 입찰가뿐 아니라 실제 노출 기준 순수익을 비교합니다.
- 속도: 광고 응답 시간과 페이지·앱의 체감 로딩 변화를 함께 확인합니다.
- 운영: 연동 장애, 어댑터 업데이트, 중복 요청을 관리할 담당자와 절차가 있는지 봅니다.
- 광고 품질: 소재 검토와 차단 설정이 각 수요 경로에 동일하게 적용되는지 확인합니다.
웹과 앱에서 선택할 때 확인할 기준
웹 퍼블리셔라면
광고 슬롯별로 어떤 수요처가 실제 응답하고, 입찰 결과가 광고 서버에서 어떻게 경쟁하는지부터 확인하세요. 헤더비딩의 요청 제한 시간을 짧게 잡으면 늦은 입찰을 자주 놓칠 수 있고, 너무 길게 잡으면 광고 표시가 늦어질 수 있습니다. 광고 서버의 가격 규칙이나 바닥가(floor price, 입찰을 허용하는 최소 가격)도 입찰 참여를 제한할 수 있으므로, 설정 전후의 응답률과 미노출률을 함께 살피는 편이 좋습니다.
Google Ad Manager를 사용하는 경우 헤더비딩, Open Bidding(광고 서버가 서버 간 연결로 여러 수요처를 경쟁시키는 기능), 워터폴 미디에이션이 서로 다른 경로라는 점에 유의하세요. Google은 Open Bidding 참여자와 입찰가, 광고 서버의 다른 후보를 통합 경매에서 비교하는 흐름을 안내합니다. 자세한 조건은 Google Ad Manager의 Open Bidding 작동 방식에서 확인할 수 있습니다.
앱 퍼블리셔라면
미디에이션 플랫폼이 각 광고 소스를 비딩과 워터폴 중 어떤 방식으로 지원하는지, 앱의 광고 형식과 운영체제에서 해당 연동이 가능한지 확인해야 합니다. 비딩을 지원하지 않는 소스는 워터폴에 남겨 하이브리드로 운영할 수도 있습니다. Google AdMob은 광고 소스별로 비딩·워터폴 연동과 최적화 지원 여부가 다를 수 있다고 안내합니다. 지원 목록은 AdMob 공식 광고 소스 가이드에서 확인하세요. 다른 네트워크 선택 기준은 애드익스체인지와 애드네트워크의 차이를 참고하면 수요처 구성을 정리하는 데 도움이 됩니다.
전환 전후에 검증할 실무 절차
워터폴에서 병렬 비딩으로 바꾸는 작업은 한 번의 eCPM 비교로 결론 내리기보다, 같은 광고 위치와 유사한 트래픽 조건에서 성과와 사용자 경험을 함께 비교해야 합니다. 다음 순서로 작은 범위부터 확인하세요.
- 현재 설정을 기록합니다. 슬롯·광고 형식별 수요처, 순서, 기본 CPM, 바닥가, 호출 제한 시간과 주요 지표를 정리합니다.
- 변경 구간을 나눕니다. 가능한 경우 일부 인벤토리나 트래픽에 먼저 적용하고, 동시에 여러 설정을 바꾸지 않습니다.
- 입찰 요청부터 노출까지 연결해 봅니다. 요청·응답·낙찰·실제 노출·수익이 각각 집계되는지 확인합니다.
- 비교 기간과 조건을 맞춥니다. 지역, 광고 형식, 기기, 요일 차이를 고려해 같은 기준의 eCPM, 채움률, 지연시간을 비교합니다.
- 품질과 오류를 점검하고 조정합니다. 광고 표시 지연, 빈 광고, SDK 오류나 특정 파트너의 낮은 응답률이 늘면 설정을 되돌리거나 범위를 줄입니다.
특히 채움률(fill rate, 광고 요청 중 실제 광고가 제공된 비율)만 높아졌다고 성공으로 단정하지 마세요. 낮은 가격의 광고가 더 많이 노출돼 총수익이 기대에 못 미칠 수 있고, 반대로 높은 eCPM이 소수 노출에만 발생할 수도 있습니다. 광고 위치별 총수익과 사용자 경험 지표를 함께 살펴야 합니다.
자주 묻는 질문
Q. 헤더비딩을 도입하면 수익이 반드시 오르나요?
아닙니다. 경쟁 수요가 늘어날 수 있지만, 실제 결과는 참여 수요처, 입찰 응답률, 타임아웃, 가격 하한선, 수수료와 광고 서버 설정에 달려 있습니다. 변경 전후에 같은 기준으로 순수익과 지연시간을 비교하세요.
Q. 워터폴은 이제 사용하지 않는 방식인가요?
그렇지 않습니다. 비딩을 지원하지 않는 네트워크를 연결하거나 기존 수요처를 유지해야 할 때 워터폴이 쓰일 수 있습니다. 비딩과 워터폴을 함께 구성하는 것도 가능하며, 플랫폼의 지원 범위와 운영 여건에 따라 판단해야 합니다.
Q. 헤더비딩은 웹사이트에서만 쓸 수 있나요?
‘헤더비딩’이라는 이름은 웹에서 시작했지만, 앱도 미디에이션의 인앱 비딩이나 서버 간 병렬 입찰을 사용할 수 있습니다. 앱에는 웹페이지 헤더가 없으므로 앱 SDK와 미디에이션 플랫폼이 지원하는 연동을 확인해야 합니다.
Q. 입찰 타임아웃은 짧을수록 좋은가요?
항상 그렇지는 않습니다. 너무 짧으면 늦게 응답한 입찰을 놓치고, 너무 길면 광고 결정과 표시가 지연될 수 있습니다. 실제 응답 시간 분포와 광고 표시 지연을 관찰해 광고 형식과 이용 환경에 맞게 조정하세요.
