OpenRTB 3.0이 지향한 것과 2.6에 다시 반영된 것
문서 목적
OpenRTB 2.5 이후 표준이 어떤 방향으로 진화했는지, 3.0이 무엇을 지향했는지, 그리고 그 문제의식 일부가 왜 2.6 계열에서 현실적으로 다시 반영되었는지 설명한다.
핵심 요약
- OpenRTB 3.0은 단순한 minor upgrade가 아니라 AdCOM, Ad Management와 함께 더 큰 구조 개편을 제안했다.
- 이 방향은 개념적으로 정교했지만, 시장은 전면 마이그레이션보다 점진적 진화를 선호했다.
- IAB Tech Lab은 이후 OpenRTB 3.0과 AdCOM의 문제의식 일부가 2.x 생태계에 현실적으로 흡수되는 흐름을 반영해 OpenRTB 2.6을 제시했다.
- 따라서 현재 광고플랫폼 학습에서는
2.5의 기준선 -> 3.0이 지향한 것 -> 업계 저항 -> 2.6에 다시 반영된 것순서로 이해하는 편이 가장 자연스럽다.
버전 흐름 한눈에 보기
1. OpenRTB 3.0이 제시한 문제의식
OpenRTB 3.0은 기존 2.x의 bid request / bid response 구조를 단순히 확장하는 대신, 광고 객체 공통 모델과 관리 계층을 분리해서 더 일관된 구조를 만들려 했다. 이 방향은 장기적으로는 의미가 있다.
대표적인 특징은 아래와 같다.
- AdCOM과 함께 광고 객체 모델을 재정의하려 했다.
- 단순 경매 메시지보다 더 넓은 상호운용성을 지향했다.
- signed bid request, provenance, 보안성 강화 같은 방향을 더 강하게 포함했다.
2. 왜 업계가 바로 3.0으로 가지 않았는가
IAB Tech Lab은 이후 OpenRTB 3.0과 AdCOM 기능이 다시 2.x 생태계 안으로 흡수되는 현실을 설명했다. 이를 보면 아래 해석이 가능하다.
- 3.0은 단독 버전 업그레이드가 아니라 여러 사양을 함께 이해해야 하는 구조였다.
- 기존 2.x 연동이 이미 넓게 퍼져 있어 전면 마이그레이션 유인이 크지 않았다.
- 공급 측과 수요 측 모두 기존 연동을 유지하면서 필요한 기능만 빠르게 추가하는 편을 선호했다.
위 해석은 IAB Tech Lab이 3.0 / AdCOM 기능이 오래된 2.x에 hack되고 있었다고 설명한 흐름과, 2.6 공개 시 faster speed to market을 강조한 메시지를 종합한 것이다.
3. 무엇이 2.6에 현실적으로 다시 반영되었는가
OpenRTB 2.6은 2.x 계열을 유지하면서도 시장에서 필요한 기능을 더 직관적으로 반영하려는 접근에 가깝다. 따라서 3.0의 모든 방향이 되돌아온 것은 아니지만, 일부 문제의식은 2.x 안에서 다시 살아났다.
실무적으로는 아래 이유 때문에 이해 가치가 크다.
- 기존 2.5 기반 연동과의 연속성이 높다.
- 현재 운영 중인 SSP, DSP, exchange 연동 현실과 더 가깝다.
- 구현자 입장에서 incremental migration이 가능하다.
- CTV, pod bidding, AdCOM 연계, ID provenance 같은 현대적 요구를 2.x 계열에서 더 받아들이기 쉬운 형태로 흡수할 수 있다.
즉, 2.6은 3.0의 문제의식을 완전히 버린 결과라기보다, 시장이 실제로 받아들일 수 있는 속도로 되돌려 적용한 현실적 진화로 읽는 편이 맞다.
4. 이 핸드북에서의 해석 원칙
- OpenRTB 2.5는 현재 실무의 기준선이다.
- OpenRTB 3.0은 미래 지향적 설계 문제의식을 보여준다.
- OpenRTB 2.6은 현재 시장에서 더 중요한 현실적 연결고리다.
- 따라서
site,app,device,user,regs,pmp,deal같은 핵심 필드는 버전 비교보다 실무 관심사 기준으로 읽는 편이 낫다. - SSI, provenance, cryptographic proof 같은 논의는 그 다음 단계의 실험실 주제로 읽는 것이 적절하다.