2026년 10월 14일, Prebid는 광고 서버가 다른 방향(원래의 방식)으로 아닌 Prebid Server로 입찰하는 경매 모델을 미리 보여주었습니다 (AdExchanger). 더 많은 수요 경로들은 여전히 동일한 아티팩트, 즉 SSP가 구매자에게 전달하는 JSON 입찰 요청으로 끝납니다. IAB Tech Lab의 ARTF v1.0 마일스톤은 병렬적인 변화를 추가합니다: 이는 해당 스트림 옆에 컨테이너화된 에이전트들을 배치하여, 누군가 입찰하기 전에 패치를 제안하는 것입니다. 저희 자체 Prebid remedies 작성 글에서 입찰 요청이 새로운 홉(hops)을 얻는다고 이야기할 때, ARTF는 인 플라이트(in flight) 객체를 변형시키는 홉 중 하나입니다.
Agentic Real Time Framework는 OpenRTB의 대체재가 아닙니다. 그것은 OpenRTB 주변의 gRPC 확장 지점입니다. 호스트가 경매를 유지하고, 에이전트가 델타(deltas)를 제안하며, 오케스트레이터가 각 변형을 자체적으로 수락하거나 거부합니다. 전송 성공과 경매 유효성은 서로 다른 질문입니다.
호스트가 보내는 것: 엔벨로프, 라이프사이클 및 적용 가능한 인텐트
ARTF 호출은 단순한 입찰 요청이 아니라 RTBRequest입니다. Protobuf JSON에는 최소한 다음 내용이 포함됩니다:
lifecycle: 이 호출이 속하는 프로그래매틱 경매 단계(퍼블리셔 입찰 요청, 입찰 응답 및 IAB 경매 정의가 명명하는 다른 단계).id: 이 컨테이너 호출을 위한 확장 지점 요청 ID (OpenRTB의 bidrequest.id와는 다름).bid_request: 프로토콜 버퍼 JSON 형태의 OpenRTB 페이로드 (열거형 이름, 부울 의미론 및 참조 스택이 예상하는 필드 대소문자).bid_response: 패치할 응답이 존재하는 단계에서만 존재합니다.tmax: 네트워크 지연 시간을 포함하여 호스트가 변형을 기다릴 밀리초(milliseconds)입니다.
호스트는 또한 이 라이프사이클에서 어떤 변이(mutation) **의도(intent)**가 합법적인지 ext.applicable_intents를 통해 광고합니다. 퍼블리셔 입찰 요청에 대해 BID_SHADE를 제안하는 에이전트는 아직 존재하지 않는 입찰에 대해 이야기하고 있는 것입니다. gRPC 스택은 여전히 OK를 반환할 수 있지만, 변이는 해당 단계에 부적절합니다. 이러한 불일치 유형은 artf.mutation.intent_not_applicable입니다. 적용 가능한 의도 목록이 누락되거나 비어 있는 것 또한 자체적인 실패 모드입니다: 호스트가 에이전트에게 무엇을 할 수 있는지 전혀 알려주지 않았을 때 artf.intents.missing입니다.
라이프사이클은 명시적이어야 합니다. 지정되지 않은 열거형(enum) 값은 중첩된 OpenRTB 객체가 정상적으로 보여도 artf.lifecycle.unspecified에서 실패합니다. 컨테이너 상태만 모니터링하는 운영자들은 엔벨로프 계약이 비어 있음에도 녹색(green)을 볼 수 있습니다.
변이가 경매 객체를 패치하는 방법
에이전트는 RTBResponse로 응답합니다: 엔벨로프 id, 선택적 메타데이터, 그리고 mutations 배열입니다. 각 변이는 네 가지 아이디어가 연결된 것입니다:
- 의도(Intent) (왜):
ACTIVATE_DEALS, ADJUST_DEAL_FLOOR, ADD_METRICS, 그리고 v1.0 의도의 나머지 카탈로그.
- 작업(Operation) (어떻게): OpenRTB 용어로 추가(add), 대체(replace), 또는 제거(remove).
- 경로(Path) (어디서): JSON 포인터가 아닌 비즈니스 엔티티에 대한 의미론적 경로입니다. 딜 플로어는 의도가 딜 노드를 필요로 할 때, 느슨한
/imp/imp-1이 아니라 /imp/{imp id}/pmp/deals/{deal id}를 대상으로 합니다.
- 값(Value) (무엇을): 프로토콜 버퍼트(protobuf) oneof.
ACTIVATE_DEALS는 ids를 전달하고, ADJUST_BID는 adjust_bid를 전달합니다. 오직 하나의 팔(arm)만 설정될 수 있습니다. 다른 의도에서 잘못된 생성자(constructor)를 복사하면 RPC가 여전히 성공하지만 의도와 페이로드(payload)가 불일치하게 됩니다.
경로는 호스트가 실제로 첨부한 **요청(request)**을 기준으로 해석되며, 여기에는 해당 스냅샷의 impression id와 deal id가 포함됩니다. 요청이 deal-standard만 나열했을 때 deal-premium으로 가는 경로는 artf.mutation.deal_unknown입니다. 아예 path를 생략하는 것은 artf.mutation.path_missing입니다. ARTF는 뮤테이션을 독립적으로 평가합니다: 배열 전체에 걸친 트랜잭션은 없습니다. 승인된 바닥가 변경(floor change) 하나와 거부된 세그먼트 추가(segment add) 하나는 정상이며, 오케스트레이터(orchestrator)는 신뢰하는 모든 하위 집합을 전달합니다.
승인 후, 호스트는 패치들을 다운스트림으로 보낼 OpenRTB 객체에 병합합니다. 이 병합된 객체는 거래소의 특정 스냅샷에서 허용되지 않는 필드(예: metrics shapes OpenRTB 2.6-202606이 거부하는 경우)를 포함할 수 있습니다. 에이전트가 gRPC 단계에서 중단되었다면 실패를 전혀 알지 못합니다.
RPC OK가 검증하지 않는 것들
GetMutations가 OK를 반환한다는 것은 컨테이너가 파싱 가능한 protobuf JSON 문서와 함께 제시간에 응답했다는 의미일 뿐입니다. 다음을 의미하지 않습니다:
- 응답의
id가 오케스트레이터가 발행한 RTBRequest.id와 일치한다.
- 모든 뮤테이션의 의도(intent)가 이 라이프사이클의
applicable_intents에 나타난다.
- 모든 의미론적 경로(semantic path)가 전달된 입찰 요청 또는 입찰 응답에서 해석된다.
- 적용된 뮤테이션이 거래소가 자신의 버전 트레인에서 검증하는 OpenRTB를 산출한다.
전달된 입찰 요청이 누락되었거나 객체가 아닌 경우, 뮤테이션의 품질과 관계없이 전체 구조(envelope)는 artf.request_unusable가 됩니다. 이는 캐시된 전체 구조, 잘못된 키 조회, 그리고 경매를 추가 JSON 레이어로 감싸는 LLM 출력의 실패 모드입니다.
호스트는 세 가지 단계를 거쳐야 합니다: 요청 엔벨로프와 내장된 OpenRTB를 검증하고, 뮤테이션 세트를 라이프사이클 및 경로와 비교하여 검증한 다음, 승인된 뮤테이션을 **적용(apply)**하고 OpenRTB를 재검증하여 바이어가 볼 객체에 필드 손상이 나타나도록 해야 합니다. ARTF simulator는 브라우저에서 apply-then-revalidate 과정을 실행하며, 더 자세한 설명은 ARTF 뮤테이션 및 입찰 요청 검증을 참고하세요.
어떻게 포착하는가 (How you catch it)
모델이 ARTF 엔벨로프와 뮤테이션 목록을 방출할 수 있게 하는 구현체라 할지라도, 여전히 이를 와이어 계약(wire contract)에 따라 확인해야 합니다. rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp)가 이 검사를 담당합니다: validate_artf_request, validate_artf_response 그리고 패치 후 OpenRTB에 대한 apply를 사용한 응답 검증입니다. 동일한 규칙은 CI, MCP 도구(자체 출력에 호출할 수 있는 에이전트), 그리고 openadtech.rtblint.v1의 gRPC 검증기에서도 실행됩니다. rtblint는 IAB Tech Lab 및 AAO와 독립적이며; 사양은 이를 요구하지 않으며, v1.0에서 포워딩하기 전에 세 번째 단계를 대체하는 것은 아무것도 없습니다.
컨테이너가 뮤테이션을 반환한 후의 예시 CLI:
$ rtblint validate --type artf-response --request rtb-request.json --apply rtb-response.json
FAILED (OpenRTB 2.6-202606 ARTF mutation set): …
다음으로 나아갈 곳 (Where to go next)
- ARTF 설명에서 라이프사이클 및 의도 어휘를 한 페이지에서 확인하세요.
- 엔벨로프, 뮤테이션, 그리고 apply 시점 OpenRTB 관련 내용을 rtblint 문서의 규칙 참조 인덱스에서 확인하세요.
- RTBlint 블로그에서 ARTF 옆에 배치된 날짜별 OpenRTB 트레인 및 에이전트 스택을 확인하세요.
프로덕션 ARTF는 프로덕션 패치 버그를 의미합니다. gRPC의 OK는 전송(transport)일 뿐이며; 경매 객체는 여전히 세 번째 단계를 거쳐야 합니다.