올바른 토대 없이는 에이전트 기반 미디어 바잉을 확장할 수 없습니다. 구매자와 판매자가 Databricks에서 이를 어떻게 실현하는지 확인해 보세요.

오늘날 미디어 바잉의 병목 현상은 인재가 아니라 조율의 문제입니다

매일 수십억 달러의 광고 거래가 수십 년 동안 거의 변하지 않은 방식인 이메일, 스프레드시트, PDF, 전화 통화 등을 통해 이루어집니다. 구매자가 캠페인을 설정하면, 숙련된 팀이 퍼블리셔에게 연락하고, RFP를 보내고, 요금표를 기다리고, 미디어 키트를 비교하고, 가격을 협상한 후 마침내 게재 신청서를 작성합니다. 뛰어난 인재들이 전략적이고 창의적인 업무를 관리하는 대신 거래를 조율하는 데 대부분의 시간을 허비하고 있습니다.

이러한 마찰은 파편화에서 비롯됩니다. 인벤토리를 검색하고, 오디언스를 평가하거나, 파트너 간에 신뢰할 수 있는 관계를 구축하는 표준화된 방법이 없기 때문에 모든 구매자와 판매자의 연결은 개별적인 맞춤형 통합이 됩니다. 이러한 조율에 며칠이 걸리기 때문에 이미 몇 시간 또는 며칠이 지난 정보를 바탕으로 의사 결정이 내려지는 경우가 많습니다. 인벤토리, 가격 책정, 오디언스 신호는 끊임없이 변하므로, 캠페인이 승인될 때쯤에는 가장 좋은 기회가 이미 지나갔을 수 있습니다.

에이전트 기반 워크플로(agentic workflows)의 부상은 이러한 팀이 수동적이고 반복적인 조율 작업을 프로세스에서 제거할 수 있는 기회를 열어줍니다. 이를 통해 가장 중요한 판단이 필요한 영역, 즉 더 정교한 타겟팅, 더 나은 크리에이티브, 그리고 단순히 빠른 출시를 넘어 더 효과적인 캠페인을 만드는 데 시간을 집중할 수 있습니다.

이 문제가 마침내 해결 가능한 이유와 표준이 중요한 이유

지난 AI의 물결은 답변하는 소프트웨어를 만들었습니다. 다음 물결은 행동하는 소프트웨어, 즉 목표를 추구하고, 의사 결정을 내리고, 도구를 호출하고, 사용자를 대신해 거래하는 에이전트를 만듭니다. 이것이 바로 수동 미디어 바잉이 겪고 있는 조율 작업입니다. 브리프 읽기, 퍼블리셔 조사, 요금표 비교, 가격 협상, 주문서 작성 등이 이에 해당합니다. 이제 처음으로 LLM과 MCP 같은 프로토콜을 사용하는 멀티 에이전트 시스템이 이 루프를 자동으로 실행할 수 있게 되었습니다.

하지만 자동화만으로는 충분하지 않습니다. IAB Tech Lab의 에이전트 기반 광고 관리 프로토콜(AAMP) 표준은 일관된 통신 패턴을 확립합니다. 즉, 인벤토리 및 오디언스를 위한 공유 어휘(AdCOM, 분류 체계), 공통 거래 프로토콜(OpenDirect, OpenRTB 딜), 검색 및 신뢰를 위한 레지스트리 모델을 제공합니다. 두 당사자 간에 표준 없이 AI만으로 이 문제를 해결할 수도 있습니다. 하지만 표준은 업계 전체가 함께 움직일 수 있도록 하는 원동력입니다. 마치 어떤 브라우저든 어떤 웹사이트든 로드할 수 있는 것처럼, 표준을 준수하는 구매자 에이전트라면 누구나 표준을 준수하는 판매자 에이전트와 거래할 수 있게 됩니다.

개방형 표준은 에이전트가 서로 소통하는 방식을 정의합니다. 그다음 질문은 이러한 에이전트가 실제로 실행되는 위치, 즉 에이전트의 상태, 모델, 신원, 거버넌스가 어디에 있는지입니다. 바로 이 부분에서 Databricks가 역할을 합니다.

저희는 완전히 Databricks 상에서 실행되는 에이전트 기반 미디어 구매 및 판매의 예시를 구축했습니다. 자율적인 구매자와 판매자가 서로를 검색하고, 가격에 합의하고, 거래를 성사시킵니다. 이는 공식 오픈 소스 IAB Tech Lab SDK를 기반으로 구축되어 프로토콜 레이어에서의 락인(lock-in)이 없으며, 이제 단일 명령어로 배포할 수 있는 액셀러레이터로 제공됩니다. 지침은 블로그 끝부분에 있습니다.

에이전트 기반 미디어 바잉의 구성 요소

에이전트 기반 미디어 바잉은 세 명의 참여자가 있는 간단한 거래입니다.

• 구매자: 캠페인(예산, 도달하려는 오디언스, 초과하지 않을 가격)을 보유한 광고주(또는 대행사)입니다.
• 판매자: 광고 인벤토리를 보유한 퍼블리셔로, 각각 카탈로그(패키지 및 상품의 미디어 키트)와 자체 가격 책정 기준을 가지고 있습니다.
• 레지스트리: 구매자가 판매자를 찾고, 구매자의 신원과 구매자가 얻는 액세스 권한 및 가격을 확인하여 신뢰를 구축할 수 있도록 지원하는 디렉터리입니다.

구매 자체는 적절한 인벤토리를 보유한 판매자를 찾고, 가격을 책정하고, 거래를 예약(또는 취소)하는 짧은 루프입니다. 오늘날 이 루프는 대부분 수동으로 이루어지지만, 저희가 보여드리고자 하는 변화는 양측 모두에서 AI 에이전트를 통해 이를 실행하는 것입니다.

서로 다른 회사의 에이전트가 거래하려면 공유된 언어가 필요하며, 바로 이 부분에서 IAB Tech Lab의 개방형 표준이 가치를 더할 수 있습니다. 여기서는 해당 SDK의 세부 사항을 다루지 않고, 대신 Databricks에서 구매자 및 판매자 에이전트를 실행하는 데 필요한 사항에 집중하겠습니다.

구매자 및 판매자 에이전트를 위한 완전한 에코시스템

복잡한 에이전트는 대규모 언어 모델(LLM)에 대한 단순한 요청을 훨씬 뛰어넘습니다. 이러한 에이전트가 오디언스 기획, 예산 분할, 퍼블리셔 검색, 최고 가격 제한 준수, 거래 예약 등 다양한 작업이 포함될 수 있는 미디어 거래를 실행하려면 다음을 관리하는 시스템이 필요합니다.

• 상태(State): 지속되어야 하고 트랜잭션 측면에서 정확해야 하는 브리프, 신원, 카탈로그, 견적 및 주문입니다.
• 서빙되는 모델(Models served): 에이전트가 호출할 수 있는 거버넌스가 적용된 파운데이션 모델로, 각 작업에 적합한 모델이 제공됩니다.
• 거버넌스가 적용된 데이터(Governed data): 에이전트가 추론하는 카탈로그 및 오디언스 데이터로, 액세스 제어가 적용됩니다.
• 신원 및 신뢰(Identity and trust): 이 에이전트는 누구이며, 무엇을 보고 수행할 수 있는 권한이 있습니까?
• 관찰 가능성(Observability): 디버깅 및 감사를 위한 모든 의사 결정 및 도구 호출의 추적(trace)입니다.

이 시스템은 데이터베이스 벤더, 모델 호스트, 거버넌스 도구, 앱 플랫폼, 추적 서비스 등을 조합하여 구성할 수 있습니다. 하지만 Databricks에서는 이 모든 것이 단 하나의 플랫폼에서 제공됩니다.

올바른 아키텍처는 어떤 모습일까요?

이 시장의 사실 한 가지부터 시작해 보겠습니다. 구매자, 판매자, 레지스트리는 서로 독립된 주체입니다. 이로 인해 문제는 두 가지로 나뉩니다. 당사자들이 서로 소통하는 방법과 각 당사자가 실제로 거래를 실행하는 위치입니다. 개방형 프로토콜은 첫 번째 질문에 대한 답을 제공합니다. 프로토콜은 당사자 간의 연결선 역할을 하여 검색, 협상, 정산을 전달하며 거기서 역할을 마칩니다. 에이전트가 실행되고, 상태를 유지하고, 신원을 증명하고, 거버넌스를 유지하는 것은 플랫폼의 몫입니다. 따라서 각 당사자는 Databricks Apps를 기반으로 구축된 독립적인 애플리케이션을 보유하며, 이 애플리케이션은 자체 상태, 신원, 실행 모델을 소유하고 프로토콜을 통해서만 다른 당사자와 만납니다. 이어지는 섹션에서는 이러한 구성 요소를 하나씩 살펴보며 왜 각 요소가 그 자리에 있어야 하는지 설명합니다.

Databricks Model Serving: 에이전트 크루

내부적으로 구매자 에이전트는 CrewAI를 사용하여 구축된 전문 에이전트들의 “크루(crew)” 또는 그룹입니다. 이 크루는 3개 레벨에 걸쳐 계층적으로 작동하며, 레벨 1 에이전트는 레벨 2 에이전트에게 작업을 위임할 수 있는 방식입니다. 이러한 에이전트에는 전략을 설정하고 예산을 분할하는 레벨 1 포트폴리오 매니저, 특정 미디어 구매를 전문으로 하는 레벨 2 채널 전문가, 오디언스를 기획하고 구매를 실행하는 레벨 3 전술 담당자가 포함됩니다. 이들은 Databricks Foundation Model API에서 실행되며 작업 복잡성에 따라 Claude 모델을 사용하도록 구성됩니다. Databricks Unity AI Gateway를 사용하여 이러한 에이전트를 실행하면 다른 부분을 변경하지 않고도 각 에이전트를 구동하는 LLM을 쉽게 변경할 수 있습니다.

Lakebase: 에이전트를 위한 트랜잭션 상태

에이전트는 데이터로부터 두 가지를 필요로 합니다. 행동의 기준이 되는 컨텍스트와 수행한 작업을 기록할 공간입니다. 구매자는 브리프를 읽고, 각 판매자는 인벤토리 카탈로그와 가격 책정 규칙을 읽으며, 예약된 모든 주문을 다시 기록합니다. 이는 전형적인 OLTP이므로, 레이크하우스 바로 옆에서 실행되는 Databricks의 서버리스 Postgres인 Lakebase에 이를 배치했습니다. 에이전트는 트랜잭션 보장을 통해 상태를 빠르게 읽고 쓰며, Postgres 기반이기 때문에 판매자 구성 요소가 별도의 맞춤형 데이터 레이어 없이 바로 적용됩니다. 또한 Lakebase는 서버리스이므로 급증하는 수요에 맞춰 밀리초 단위로 자동 확장(autoscale)됩니다. 에이전트는 일정한 속도로 유입되지 않으며, 구매자는 용량을 미리 프로비저닝하지 않고도 한 번에 여러 판매자에게 분산하여 요청할 수 있습니다.

거버넌스: 현재는 Lakebase, 다음은 Unity Catalog

현재 이 데모는 Lakebase만 사용합니다. 실제 환경에서 Lakebase는 거버넌스가 적용된 두 개의 Unity Catalog 경계 사이에 위치합니다. 데이터가 들어오는 과정에서는 Unity Catalog 테이블의 데이터가 Lakebase로 하이드레이션(hydration)됩니다. 여기에는 판매자의 인벤토리 및 ML 모델 기반 가격 책정, 구매자의 캠페인 브리프 및 오디언스 정의가 포함됩니다. 데이터가 나가는 과정에서는 에이전트가 생성한 트랜잭션 상태(누가 무엇을 얼마에 구매했는지)가 보고 환경으로 다시 동기화됩니다. 양방향 모두 불안정하고 수동으로 작성된 ETL 대신 Databricks 관리형 파이프라인에서 실행됩니다. 이를 통해 거버넌스가 적용된 왕복 프로세스가 가능해집니다. Unity Catalog는 모든 하이드레이션 및 동기화의 리니지(lineage)를 자동으로 추적하므로 어떤 데이터가 어디로 이동했는지 언제든지 추적할 수 있습니다. 레이크하우스는 양쪽 끝에서 단일 진실 공급원(source of truth)으로 유지되며, Lakebase는 에이전트가 거래하는 운영 및 핫 서빙(hot-serving) 레이어 역할을 합니다.

신원 및 신뢰

앱은 서로를 증명하고 확인하는 메커니즘인 OAuth를 사용하여 상호 인증하며, 레지스트리는 각 구매자에게 신뢰 등급을 할당합니다. 이 등급에 따라 구매자가 볼 수 있는 정보가 결정됩니다. 신원을 알 수 없는 공개 구매자는 가격대만 볼 수 있고 거래할 수 없지만, 신뢰할 수 있고 검증된 구매자는 정확한 가격을 확인하고 예약할 수 있습니다. 구매자의 신뢰 등급을 전환하면 가격대만 볼 수 있도록 제한되었던 동일한 캠페인을 이제 예약할 수 있게 됩니다. Databricks에서는 이러한 신원 확인 방식이 앱 및 데이터 액세스의 기존 작동 방식에 기본적으로 통합되어 있습니다. IAB 참조 SDK가 API 키를 요구하는 부분에서, 당사는 플랫폼의 내장 서비스 주체(service principals)와 OAuth를 활용하여 오늘날의 모범 사례에 따라 인증하므로 추가로 구축할 필요가 전혀 없습니다.

관찰 가능성(Observability)

에이전트 크루는 MLflow 추적(tracing)을 사용하도록 구성되어 있으며, 이는 한 줄의 CrewAI 자동 로깅(autolog) 훅을 통해 쉽게 구현할 수 있습니다. 이를 통해 모든 에이전트 실행의 추론 단계, 도구 호출, 조회된 가격, 예약 또는 패스 결정을 캡처할 수 있습니다. 데모에서는 이 기능을 선택 사항으로 유지했지만, 예산 통제와 관련하여 자율 시스템을 프로덕션에 도입하고, 디버깅하고, 튜닝하고, 신뢰하기 위해 정확히 이 방식을 사용하고자 할 것입니다.

에이전트 기반 구매 앱의 작동 모습 확인하기

한 캠페인의 전체 실행 과정을 살펴보겠습니다. 먼저 광고주의 브리프를 제출하는 것으로 시작합니다. 이 시나리오에서는 CTV 및 Linear TV 미디어 유형에 걸쳐 $200,000의 예산과 $38의 CPM(Cost Per Mille) 상한선을 가진 '3분기 브랜드 출시(Q3 Brand Launch)' 캠페인입니다. 이 브리프가 구매자 앱으로 전송되면 에이전트 크루가 구매 프로세스를 시작합니다.

1. 예산 계획: 포트폴리오 관리자(Portfolio Manager)가 브리프를 읽고 채널별로 지출을 나누어 CTV에 $120k, Linear에 $80k를 할당합니다.

2. 타겟 오디언스 변환: 전문가가 브리프의 일상어 오디언스를 IAB Tech Lab Audience Taxonomy에 따라 검증된 표준 세그먼트로 매핑합니다. 예를 들어 "sports fans"는 “Sports Enthusiasts”로, "auto intenders"는 “Auto Intenders”로 매핑됩니다.

3. 판매자 검색: 구매자가 레지스트리에서 게시자(Seller A(CTV) 및 Seller B(Linear))를 검색하면, 게시자가 구매자의 신원을 확인하고 액세스 등급을 부여합니다.

4. 가격 책정: 각 채널의 채널 전문가(Channel Specialist)가 MCP를 통해 해당 판매자를 탐색하고, 오디언스 세그먼트를 사용 가능한 상품과 매칭한 후 공식 가격을 확인합니다.

5. 예약 또는 패스: 규칙은 간단합니다. 가격이 $38 상한선 이하이고 상품 오디언스가 일치하면 예약하고, 그렇지 않으면 취소합니다.

향후 계획

여기서 보여드린 것은 거래의 중간 단계인 거래를 수행하는 에이전트입니다. 하지만 동일한 플랫폼에서 거래의 이전 및 이후 단계도 구축할 수 있습니다. 구매자의 브리프 생성, 판매자의 패키지 가격을 설정하는 ML 모델, 수익 및 지출을 추정하는 데 사용되는 모델과 대시보드 등이 이에 해당합니다. 이러한 문제의 해결은 거버넌스가 적용된 데이터와 ML에 의존하며, 이 두 가지 모두 Databricks에 기본적으로 내장되어 있습니다. 저희 팀은 리포지토리를 지속적으로 업데이트하여 추가적인 AAMP 기능이 출시됨에 따라 IAB Tech Lab과 함께 발전할 수 있도록 최선을 다하고 있습니다.

직접 배포해 보기

이 시스템은 Databricks Automation Bundle 액셀러레이터로 제공됩니다. 리포지토리를 복제하고, Databricks CLI가 작업 공간을 가리키도록 설정한 후, 단일 명령어를 실행하기만 하면 됩니다.

이 명령어를 사용하여 앱과 Lakebase 인스턴스를 빌드 및 배포하고, 데이터를 시딩하며, 레지스트리를 통해 구매자와 판매자를 연결합니다. 몇 분 후면 두 개의 라이브 판매자 에이전트, 레지스트리, 구매자 콘솔이 모두 여러분의 작업 공간에서 거래를 수행하게 됩니다.

이제 여러분의 환경에 맞게 맞춤 설정해 보세요. 자체 인벤토리, 가격 책정 규칙, 오디언스로 교체하거나 Lakebase 레이어를 실제 카탈로그 및 모델에 연결할 수 있습니다. 구매자 또는 판매자로 거래에 참여하여 에이전트가 어떻게 반응하는지 확인해 보세요. 가격을 변경하거나, 구매자의 신뢰 등급을 전환하거나, 판매자를 추가하면서 협상이 어떻게 진행되는지 관찰할 수 있습니다. 이는 에이전트 기반 미디어 구매 및 판매에 맞춤화된 실용적인 청사진입니다.

5분 분량의 데모를 시청한 후, 여러분의 작업 공간에 액셀러레이터를 배포해 보세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)