18개월 전, 에이전트 주도형 광고 구매(agent-driven ad buying)는 핵심 주제였습니다. 오늘날 이는 서로 공개적으로 협력하지 않는 두 개의 서로 다른 조직에 의해 출시된 소프트웨어를 포함하며, 경쟁하는 두 가지 표준 스택으로 자리 잡았습니다.

만약 당신이 애드테크(adtech)를 구축한다면, 두 스택 모두 당신의 파이프라인에 나타나게 될 것입니다. 요약하자면 다음과 같습니다.

스택 1: IAB Tech Lab의 AAMP

AAMP (Agentic Advertising Management Protocols)는 2026년 1월에 출시되었으며 6월에 2.0 버전에 도달했습니다. 철학은 다음과 같습니다: 이미 돈이 흐르고 있는 레일(rails) 위에 구축하는 것입니다. 이는 OpenRTB, AdCOM, OpenDirect, VAST를 하나로 연결하며, MCP와 Google의 Agent2Agent 프로토콜을 에이전트 인터페이스로 사용합니다.

버전 1.0은 직접 거래(direct deals)만 처리할 수 있었습니다. 2.0 릴리스에서는 프로그래매틱(programmatic) 기능이 추가되었습니다: 3계층 에이전트 계층 구조(오케스트레이션, 채널 전문가, 기능 에이전트)를 갖춘 구매 에이전트 SDK(Buyer Agent SDK), 정적인 미디어 키트를 구매자에 따라 가격을 조정하는 스토어프론트로 변환하는 판매 에이전트 SDK(Seller Agent SDK), 그리고 OpenDirect 2.1 지원을 포함하는 기록 시스템으로서의 딜 라이브러리(Deals Library)가 포함됩니다. 승인 게이트(Approval gates)와 감사 로그(audit logs)를 통해 인간이 최종 승인 지점에 머물도록 유지합니다.

스택 2: AAO의 AdCP

Ad Context Protocol은 Yahoo, PubMatic, Optable, Scope3, Swivel, Triton Digital을 포함하는 컨소시엄으로부터 2025년 10월에 출시되었습니다. 현재는 브랜드, 대행사, 퍼블리셔, 기술 제공업체라는 네 개의 동등한 투표권을 가진 클래스로 구성된 무역 협회인 AgenticAdvertising.Org (AAO)에 의해 관리됩니다. 참조용 셀 사이드(sell-side) 구현은 Prebid 커뮤니티에 있습니다.

AdCP는 처음부터 에이전트 네이티브(agent-native)로 설계되었습니다. 이는 MCP를 기반으로 직접 구축되었으며, 에이전트가 협상하는 동안 인간이 승인할 수 있도록 비동기식(asynchronously)으로 작동합니다. 버전 3.0(2026년 4월)은 발견(discovery), 미디어 구매, brand.json을 활용한 크리에이티브 제작, 거버넌스, 그리고 20개 미디어 채널에 걸친 보고를 포함하는 전체 캠페인 라이프사이클을 다룹니다. 현재 Snap, Pinterest, Reddit, Netflix, Vox Media에서 운영 중입니다.

실제 차이점

• 거버넌스 (Governance). Tech Lab은 이미 VAST 및 OpenRTB를 유지 관리하고 있는 기존 사업자 (incumbent)입니다. AAO는 에이전트 기반 광고 (agentic advertising)를 위해 특별히 구축된 새로운 협회입니다.
• 설계 중심 (Design center). AAMP는 기존의 프로그래매틱 레일 (programmatic rails) 위에 에이전트를 계층화합니다. AdCP는 새로운 MCP 네이티브 태스크 (MCP-native tasks)를 먼저 정의하고, 레거시 시스템을 통합 대상 (integration targets)으로 취급합니다.
• 범위 (Coverage). AAMP는 트랜잭션 계층 (transaction layer)에서 가장 깊이 있게 다루며, 비더 (bidder) 인프라 내부에서 실행되는 ARTF 에이전트 컨테이너를 활용합니다. AdCP는 계획부터 보고에 이르기까지 라이프사이클 (lifecycle) 전반에 걸쳐 가장 넓은 범위를 다룹니다.
• 인터페이스 (Interfaces). 두 스택 모두 MCP를 핵심 프로토콜로 명시합니다. MCP 서버로 노출된 도구는 수정 없이 두 스택 중 어느 쪽의 에이전트에게도 서비스를 제공할 수 있습니다.
• 검증 (Verification). 두 스택 모두 크리에이티브 페이로드 (creative payload)를 검증하지 않습니다. 딜 (deal) 상태와 컨텍스트 (context)는 에이전트 간에 이동하며, 전달되는 내용의 정확성은 두 사양 (specs) 모두의 범위 밖입니다.

두 스택이 공유하는 계층

어느 쪽 스택을 통해서든 비디오 구매를 따라가 보면 엔드포인트 (endpoint)는 동일합니다. 광고 서버가 VAST XML을 반환합니다. InLine 또는 Wrapper, MediaFiles, Impression 픽셀, TrackingEvents 등이 포함됩니다. 한쪽에서는 20개의 프로토콜 채널이 나타나지만, 다른 한쪽에서는 하나의 XML 문서로 나타납니다.

그 문서가 바로 전달 (delivery)이 실패하는 지점입니다. 누락된 Duration, HTTPS를 요구하는 CTV 기기에서의 HTTP 미디어 URL, 플레이어의 깊이 제한을 초과한 래퍼 체인 (wrapper chain) 등은 프로토콜 계층에서는 전혀 보이지 않습니다. 딜은 깔끔하게 확정되고, 에이전트는 성공을 기록하지만, 임프레션 (impression)은 아무도 지켜보지 않는 VAST 에러 코드와 함께 런타임 (runtime) 중에 소멸합니다.

과거에는 트래피커 (trafficker)가 최후의 보루 역할을 했습니다. 하지만 에이전트 대 에이전트 (agent-to-agent) 트랜잭션에는 트래피커가 없습니다. 검증은 런칭 후의 QA 단계가 아니라, 딜이 확정되기 전에 에이전트가 호출하는 도구여야 합니다.

실질적인 시사점

승자에게 베팅할 필요는 없습니다. MCP가 공유 인터페이스이기 때문입니다. AAMP의 Buyer Agent SDK는 추가적인 MCP 도구 서버를 수용하며, AdCP는 엔드 투 엔드 (end to end)로 MCP 네이티브입니다. 오늘날 MCP를 통해 노출하는 모든 것은 두 스택 모두에서 작동합니다.

그것이 우리가 vastlint를 출시하는 방식입니다: IAB VAST, OMID, 그리고 SIMID 사양에 기반한 187개의 규칙, 결정론적 (deterministic) JSON 출력, 그리고 호스팅된 MCP 엔드포인트(endpoint), CLI, 라이브러리 형태로 제공됩니다. 어느 스택의 에이전트든 이를 가리키게 하고, 깨끗한 태그를 기준으로 거래 확인을 제어(gate)하십시오.

프로토콜은 계속해서 변할 것입니다. 페이로드(payload)는 지난 20년 동안 VAST였으며, 거버넌스(governance) 문제가 해결된 후에도 여전히 VAST일 것입니다.

출처를 포함한 전체 비교 내용은 vastlint 블로그에서 확인할 수 있습니다: AAMP vs AdCP: What IAB Tech Lab and AAO Are Each Building for Agentic Advertising.