월 수십억 원 광고 수익을 만들기까지의 여정

“AdMob SDK 연동에 3일, 미디에이션 세팅에 일주일, 그런데 eCPM은 왜 이렇게 낮지?”

앱 광고 수익화를 시도해보신 분이라면 한 번쯤 겪어보셨을 텐데요. 수많은 광고 네트워크의 개별 연동, 복잡한 워터폴 구조 설정, eCPM(천 회 노출당 수익) 최적화를 위한 끝없는 A/B 테스트. 그리고 본격적인 수익 최적화를 위해서는 결국 자체 AdServer 구축까지 요구되는 현실. 대부분의 개발팀에게 이는 사실상 불가능한 미션에 가깝습니다.

세계 1위 알람 앱 알라미를 운영하며 매달 수십억 원 규모의 광고 수익을 직접 운영해온 저희 팀도 같은 고민을 했습니다. 그리고 축적된 노하우와 기술력을 Daro라는 통합 솔루션에 모두 녹여냈는데요. 그 중에서도 오늘은 SSP(Supply-Side Platform)에 대해 이야기해보려고 합니다. 이번 글에서는 Daro의 SSP가 어떻게 OpenRTB 프로토콜을 구현했는지, 그리고 실제로 어떤 아키텍처로 수익을 극대화하고 있는지 살펴보겠습니다.

‍

SSP는 왜 필요할까?

프로그래매틱 광고의 진화

먼저 SSP가 왜 중요한지 이해하려면 프로그래매틱 광고의 진화를 살펴볼 필요가 있는데요. 2000년대 초반, 퍼블리셔들이 광고주와 일일이 협상하던 시절을 기억하시나요? 각 캠페인 협상에 수 주가 걸리고, 상당량의 인벤토리가 미판매 상태로 남았던 비효율적인 시대였습니다.

2009년 RTB(Real-Time Bidding)가 도입되면서 판도가 완전히 바뀌었습니다. 수백 밀리초 안에 실시간 경매가 완료되고, 2025년 현재는 전 세계 디지털 광고 지출의 대부분이 프로그래매틱으로 거래되고 있습니다.

‍

SSP의 역할

SSP는 이 혁신의 핵심 인프라입니다.

SSP의 핵심 가치는 단순히 여러 광고주를 연결하는 것이 아닙니다. 수 많은 DSP(Demand-Side Platform)와 직접 연동하여 퍼블리셔의 각 광고 지면을 실시간으로 경매에 부치는 기술 인프라를 제공합니다.

개발자가 수십 개 DSP와 개별적으로 계약하고, 각각의 SDK를 연동하고, OpenRTB 프로토콜을 구현하는 것은 현실적으로 불가능합니다. SSP는 이 모든 복잡성을 하나의 통합 인터페이스로 해결합니다.

‍

자체 SSP 구축이 어려운 세 가지 현실적인 이유

“그렇게 좋다면 우리도 SSP를 만들면 되지 않나?” 라고 생각하실 수 있는데요. 현실은 그리 녹록지 않습니다.

첫째, 기술적 장벽이 만만치 않습니다.

• 전 세계 분산 데이터센터 구축
• 99.99% 가동률 유지
• OpenRTB 프로토콜 완벽 구현
• 실시간 데이터분석을 통한 최적화

둘째, 운영 비용이 상당합니다. 중소 AdTech 기업도 연간 수십억 원의 인프라 비용을 지출하는데요. 대형 플랫폼은 이보다 훨씬 큰 규모입니다.

셋째, 규모의 경제가 작동합니다. DSP들은 충분한 트래픽이 없는 SSP와는 연동을 꺼립니다. Daro의 파트너 DSP 중에는 일일 최소 10억 건의 bid request를 요구하는 곳도 있었습니다. 닭이 먼저냐 달걀이 먼저냐의 문제입니다.

결국 SSP는 ‘구축’보다는 ‘파트너십’의 영역입니다. 그래서 Daro 같은 검증된 솔루션이 필요한 거죠. 이러한 SSP가 실제로 어떻게 작동하는지, 그 핵심인 OpenRTB 프로토콜부터 자세히 알아보겠습니다.

‍

OpenRTB: 글로벌 광고 거래의 표준 프로토콜

OpenRTB란?

SSP와 DSP가 소통하려면 공통의 언어가 필요한데요. 그것이 바로 OpenRTB(Open Real-Time Bidding)입니다.

2010년 IAB Tech Lab이 제정한 이 프로토콜은 어떻게 작동할까요? 실제 예시를 통해 살펴보겠습니다.

‍

데이터 구조

OpenRTB의 핵심은 정교하게 설계된 데이터 구조입니다.

Bid Request는 광고 기회를 설명하는 JSON 객체로, Impression(광고 슬롯 정보), Site/App(퍼블리셔 컨텍스트), Device(기기 정보), User(사용자 데이터) 등의 중첩된 구조로 구성됩니다. DSP는 이를 분석하여 짧은 시간 내에 Bid Response를 반환해야 하며, 일반적으로 업계에서는 수백 밀리초 이내의 응답을 요구합니다.

또한 OpenRTB는 모든 광고 형식을 표준화된 방식으로 처리하는데요. Banner는 크기와 위치를, Video는 VAST(Video Ad Serving Template, 비디오 광고 제공 템플릿) 표준에 따른 재생 시간과 비트레이트를, Native는 제목, 이미지, CTA 버튼 등 개별 에셋을 정의합니다. 이러한 통합된 구조 덕분에 퍼블리셔는 하나의 시스템으로 모든 광고 형식을 관리할 수 있습니다.

‍

100밀리초의 전쟁

사용자가 앱을 열었습니다. 광고 슬롯이 나타나는 그 순간, 다음과 같은 일이 벌어집니다:

1. Bid Request 생성 (10ms)
   - Impression: "배너 광고, 320x50 사이즈"
   - Device: "iPhone 14, iOS 17"
   - User: "관심사: 스포츠, 위치: 서울"
   
2. DSP들에게 동시 전송 (20ms)
   - 30개 DSP에 병렬 요청
   
3. DSP 응답 수집 (50ms)
   - DSP A: 100원 입찰
   - DSP B: 150원 입찰
   - DSP C: 120원 입찰
   
4. 경매 및 광고 송출 (20ms)
   - 승자: DSP B
   - 광고 렌더링

총 소요 시간: 100밀리초

이 모든 과정이 사용자가 눈치채지 못하는 찰나에 일어납니다.

‍

OpenRTB 구현의 현실적 어려움

이론은 간단해 보이지만 실제 구현은 어떨까요?

첫째, 엄청난 처리량 대규모 SSP는 초당 수백만 건의 쿼리를 처리해야 합니다. 일일 수십억 개 요청을 안정적으로 처리하려면 분산 처리, 인메모리 캐싱, 비동기 메시지 처리 등 고도화된 아키텍처가 필수인데요.

둘째, 극한의 속도 요구 네트워크 지연까지 고려하면 실제 처리 시간은 더 짧아집니다. 연결 재사용, 데이터 압축, 병렬 처리… 모든 구간에서 밀리초를 아껴야 합니다.

셋째, 보안 및 정책 준수

• HTTPS/TLS 1.2+ 암호화
• sellers.json / ads.txt 정책 준수
• GDPR/CCPA 동의 처리

이 모든 것을 동시에 만족시켜야 합니다.

OpenRTB를 구현한 Daro는 클라우드 인프라를 활용한 자동 스케일링, 지능형 트래픽 라우팅, 실시간 성능 모니터링을 통해 밀리초 단위 경매를 안정적으로 처리합니다. 개발자는 복잡한 프로토콜 구현 대신 단일 SDK 연동만으로 글로벌 프로그래매틱 생태계에 즉시 접근할 수 있습니다.

OpenRTB는 단순한 기술 표준을 넘어 빠르게 성장하는 프로그래매틱 광고 시장의 기반입니다. 이제 Daro가 이 표준을 어떻게 구현했는지, 실제 시스템 아키텍처를 통해 구체적으로 살펴보겠습니다.

‍

Daro SSP는 어떻게 구현되었을까?

우리가 선택한 기술 스택

Daro SSP를 구축하면서 가장 중요하게 생각한 것은 ‘실전에서 검증된 기술’이었습니다.

Go + Fiber v3 조합을 선택한 이유

• Go의 경량 고루틴: 수만 개의 동시 연결 처리
• Fiber v3의 제로 메모리 할당: 극한의 성능 최적화

이를 바탕으로 대용량 입찰 요청을 안정적으로 처리하는 고성능 시스템을 구현했습니다.

OpenRTB 2.x/3.x 듀얼 지원

레거시 DSP와의 호환성을 유지하면서도 최신 표준의 이점을 모두 활용할 수 있도록 했는데요. 이를 통해 접근 가능한 수요처를 극대화했습니다.

‍

실시간 입찰의 핵심: ‘조율’

단순히 빠르게 처리하는 것이 전부가 아닙니다.

실시간 입찰의 진짜 도전은 단순 병렬 처리가 아닌 ‘조율’에 있습니다. Daro는 수십 개 DSP의 서로 다른 응답 속도, 프로토콜 버전, 데이터 형식을 실시간으로 조정하며 단일 경매로 수렴시킵니다. 예를 들면 가장 느린 DSP를 기다리지 않으면서도 가장 높은 입찰가를 놓치지 않는 균형점을 찾아, 전체 경매를 수백 밀리초 내에 완료합니다.

‍

확장 가능한 아키텍처

DDD(Domain-Driven Design) 원칙을 따라 설계했는데요.

AdUnit (광고 단위)
  ├── 자체 비즈니스 규칙 캡슐화
  └── 독립적인 도메인 엔티티
Bidder (입찰자)
  ├── DSP별 프로토콜 구현
  └── 단일 인터페이스로 통합
Publisher (퍼블리셔)
  ├── 수익 최적화 로직
  └── Floor Price 관리

새로운 DSP를 추가할 때도 기존 시스템에 영향 없이 인터페이스만 구현하면 됩니다. 실제로 국내외 주요 DSP들이 이 구조 위에서 안정적으로 통합되어 있고, 계속해서 파트너가 빠르게 추가되고 있습니다.

이러한 구조는 단순히 기술적 우아함을 위한 것이 아닙니다. 광고 기술 시장은 빠르게 변화하고, 새로운 광고 형식과 프로토콜, DSP등이 계속 등장할 수 있습니다. Daro의 도메인 중심 모듈화 구조는 이러한 변화에 민첩하게 대응할 수 있는 기반이 됩니다.

‍

데이터 기반 최적화의 핵심, 이벤트 분석 시스템

매 입찰마다 발생하는 BidRequest 부터 Click 까지 모든 입찰 이벤트는 Kafka를 통해 실시간으로 스트리밍됩니다. 하루 수십억 건씩 쌓이는 이 데이터는 ClickHouse에서 분석되어 더 스마트한 수익 최적화 전략을 만들어냅니다.

이와 함께 Win Notice URL(NURL)과 Loss Notice URL(LURL) 지원은 투명성과 최적화를 동시에 달성합니다. DSP는 자신의 입찰이 왜 실패했는지 알 수 있고, Daro는 이 데이터를 분석하여 Floor Price를 조정합니다. 예를 들어, 특정 시간대에 입찰 경쟁이 치열하다면 Floor Price를 상향 조정하여 수익을 극대화하고, 경쟁이 적은 시간에는 하향 조정하여 Fill Rate를 높입니다.

‍

기술을 넘어, 검증된 수익화 노하우까지

이 글에서는 Daro SSP가 OpenRTB를 어떻게 구현했는지, 그리고 실제로 어떤 기술적 도전을 해결하며 성장해 왔는지 살펴보았습니다.

하지만 Daro의 진짜 가치는 단순한 기술 인프라에만 있는 것이 아닙니다. 월 수십억 원의 광고 수익을 직접 운영하며 축적한 알라미 팀의 노하우가 시스템 곳곳에 녹아있다는 점입니다.

어떤 시간대에 Floor Price를 조정해야 수익이 극대화되는지, 특정 DSP의 응답이 느려질 때 어떻게 대응해야 하는지, Fill Rate와 eCPM 사이의 최적 균형점은 어디인지. 이런 질문들의 답은 문서나 이론이 아닌, 수년간의 실전 경험에서만 나옵니다.

즉, Daro를 선택한다는 것은 단순히 SSP를 도입하는 것이 아닙니다. 알라미 팀이 수십억 원의 수익을 만들며 겪은 시행착오, 그 과정에서 발견한 최적화 노하우, 그리고 지금도 매일 개선되는 운영 전략을 그대로 여러분의 앱에 적용한다는 의미입니다.

이 모든 것을 단 하나의 SDK로 3일 만에 연동할 수 있습니다.

더 이상 복잡한 광고 기술과 씨름하지 마세요. 개발자는 더 나은 앱을 만드는 데 집중하고, 광고 수익화는 이미 그 길을 걸어본 Daro에게 맡기세요.

Daro와 함께라면 여러분의 앱도 월 수십억 원 수익의 주인공이 될 수 있습니다.

‍