블로그로 돌아가기

모바일 앱의 open bidding vs header bidding: 완벽 가이드

2026년 3월 27일 · RevenueFlex 팀

앱 수익화 업계에 있어 봤다면 "open bidding"과 "header bidding"이 거의 같은 의미로 사용되는 것을 들어봤을 것입니다. 두 가지는 같은 목표를 공유합니다 — 디맨드 소스 간 실시간 경쟁으로 eCPM을 끌어올리는 것 — 하지만 내부 작동 방식은 다릅니다. 이 차이를 이해하는 것이 앱에 적합한 접근 방식을 선택하는 핵심입니다.

Header bidding이란?

Header bidding은 웹 광고에서 시작되었습니다. 퍼블리셔들은 페이지의 "헤더"에 JavaScript 코드를 추가하여 메인 ad server로 광고 호출을 보내기 전에 여러 디맨드 파트너로부터 동시에 입찰을 요청했습니다. 가장 높은 입찰이 이기면서 진정한 경쟁이 만들어졌고, 디맨드 소스를 하나씩 차례로 호출하는 순차적 waterfall 문제가 해결되었습니다.

모바일 앱 맥락에서 header bidding은 클라이언트 사이드 SDK를 통해 작동합니다. 참여하는 각 디맨드 파트너는 앱에 SDK를 통합합니다. 광고 기회가 발생하면 모든 SDK가 동시에 호출되고, 각각 입찰을 반환하며, 가장 높은 입찰이 승리합니다. AppLovin MAX와 Unity LevelPlay는 in-app bidding 기능을 통해 이 모델을 지원합니다.

Open bidding이란?

Open bidding(이전의 Exchange Bidding)은 Google의 서버 사이드 대안입니다. 여러 SDK를 통해 사용자의 기기에서 경매를 실행하는 대신, open bidding은 Google의 서버에서 경매를 실행합니다. 디맨드 파트너는 Google 인프라에 연결되어 server-to-server로 입찰을 제출하므로, 클라이언트 측에서 개별 SDK 통합이 필요 없습니다.

Open bidding은 Google Ad Manager를 통해 이용할 수 있으며, Google의 광범위한 디맨드 생태계와 프로그램에 참여한 서드파티 exchange에 대한 접근을 제공합니다.

주요 차이점

지연 시간

이것이 가장 중요한 실질적 차이점입니다. 클라이언트 사이드 header bidding은 각 SDK가 네트워크 호출을 수행하고, 경매를 처리하고, 입찰을 반환해야 합니다 — 모두 사용자의 기기에서 이루어집니다. SDK가 많을수록 처리 시간이 길어집니다. Open bidding은 server-to-server로 실행되며 일반적으로 더 빠르고 기기 리소스를 소비하지 않습니다. 광고 로드 속도가 사용자 경험에 직접 영향을 미치는 앱에서는 이것이 중요합니다.

SDK 복잡성

모든 header bidding 파트너는 앱에 SDK 통합이 필요합니다. SDK가 많을수록 앱 바이너리가 커지고, SDK 간 충돌 가능성이 높아지며, SDK 업데이트가 필요할 때 유지보수 비용이 증가합니다. Open bidding은 Google Mobile Ads SDK만 필요하며, 디맨드 파트너는 서버 측에서 연결됩니다. 이는 기술적 복잡성을 크게 줄여줍니다.

디맨드 다양성

AppLovin MAX와 같은 플랫폼을 통한 header bidding은 각각 고유한 광고주 관계와 디맨드를 가진 다양한 광고 네트워크에 대한 접근을 제공합니다. Open bidding은 Google의 디맨드와 참여 exchange에 대한 접근을 제공하지만, 참여 파트너 풀은 클라이언트 사이드 입찰에서 이용 가능한 것보다 작습니다. 최적의 접근 방식에는 종종 두 가지 모두가 포함됩니다.

투명성

클라이언트 사이드 header bidding은 각 파트너의 입찰을 실시간으로 완전히 볼 수 있게 해줍니다. 어떤 네트워크가 얼마로 입찰했는지, 누가 이겼는지, 그 이유를 정확히 볼 수 있습니다. Open bidding은 GAM을 통해 리포팅을 제공하지만, 경매는 Google 서버에서 이루어지므로 입찰 프로세스에 대한 실시간 가시성이 약간 덜 세밀합니다.

어떤 것을 선택해야 할까?

솔직히 말해 성공한 대부분의 퍼블리셔는 둘 다 사용합니다. 실용적 프레임워크는 다음과 같습니다:

GAM open bidding을 기본 경매 메커니즘으로 사용하세요. 최소한의 SDK 오버헤드와 빠른 광고 로드로 강력한 디맨드를 제공합니다. 그런 다음 mediation 플랫폼(AppLovin MAX 또는 Unity LevelPlay)을 통해 2~3개의 최고 성과 네트워크의 클라이언트 사이드 입찰로 보완하여 최대 디맨드 다양성을 확보하세요.

가장 높은 광고 수익을 창출하는 퍼블리셔는 open bidding과 header bidding 중 하나를 선택하지 않습니다 — 기술적 복잡성을 관리 가능하게 유지하면서 경쟁을 최대화하는 하이브리드 접근 방식으로 두 가지를 결합합니다.

실전에서의 하이브리드 접근

일반적인 하이브리드 설정에서 waterfall은 다음과 같이 보입니다: GAM을 통한 open bidding이 2~3개의 in-app bidding 네트워크와 나란히 경쟁합니다. 그 아래에는 실시간 입찰을 지원하지 않는 네트워크를 위한 전통적 waterfall 항목이 있습니다. 매니지드 디맨드 파트너는 이 스택의 어느 수준에나 배치할 수 있으며, 사용되는 경매 메커니즘과 관계없이 전체 yield에 도움이 되는 추가 경쟁을 제공합니다.

핵심은 지나치게 복잡하게 만들지 않는 것입니다. GAM open bidding으로 시작하고, mediation 플랫폼의 최고 입찰 파트너를 추가하고, 매니지드 파트너로 공백을 채우세요. 그런 다음 데이터 기반으로 최적화하세요.