Our Multi-Agent Architecture for Smarter Advertising

🖼️ 인포그래픽

Our Multi-Agent Architecture for Smarter Advertising 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Spotify Engineering은 광고 구매 채널마다 흩어진 의사결정 로직을 통합하기 위해, 기존 Ads API를 도구처럼 호출하는 멀티 에이전트 기반 미디어 플래닝 아키텍처를 도입했다고 설명한다.

📌 핵심 요약

Spotify의 광고 시스템은 Direct, Self-Serve, Programmatic 등 여러 구매 방식이 하나의 통합된 백엔드 위에 올라가 있지만, 실제 워크플로와 의사결정 기준은 채널별로 달라 동일한 예산 배분·인벤토리 선택·도달률과 효율성 균형 판단이 여러 표면에서 반복 구현되는 문제가 있었다.
기존 방식처럼 새 서비스와 고정된 상태 머신, REST 엔드포인트를 추가하는 접근은 미디어 플래닝의 조합적 복잡성과 빠르게 바뀌는 비즈니스 조건을 감당하기 어렵다고 보았다.
Spotify는 거대한 규칙 엔진 대신, 사용자의 목표를 이해하고 공유 신호를 바탕으로 추론하며 기존 Ads 서비스를 오케스트레이션하는 통합적이고 프로그래밍 가능한 의사결정 계층이 필요하다고 판단했다.
초기 적용 분야로 Media Planning을 선택했고, RouterAgent, GoalResolverAgent, AudienceResolverAgent, BudgetAgent, ScheduleAgent, MediaPlannerAgent 등 역할별 에이전트를 구성해 자연어 캠페인 요구사항을 구조화하고 최적화된 광고 세트 추천을 생성했다.
결과적으로 수동 미디어 플랜 작성에 15~30분 걸리던 작업을 5~10초 수준으로 줄이고, 20개 이상의 입력 필드를 1~3개의 자연어 메시지로 대체하며, 과거 캠페인 성과 데이터를 기반으로 추천을 생성하는 방향으로 사용자 경험과 시스템 일관성을 개선했다.

🧩 주요 포인트

Spotify의 광고 시스템은 Direct, Self-Serve, Programmatic 등 여러 구매 방식이 하나의 통합된 백엔드 위에 올라가 있지만, 실제 워크플로와 의사결정 기준은 채널별로 달라 동일한 예산 배분·인벤토리 선택·도달률과 효율성 균형 판단이 여러 표면에서 반복 구현되는 문제가 있었다.
기존 방식처럼 새 서비스와 고정된 상태 머신, REST 엔드포인트를 추가하는 접근은 미디어 플래닝의 조합적 복잡성과 빠르게 바뀌는 비즈니스 조건을 감당하기 어렵다고 보았다.
Spotify는 거대한 규칙 엔진 대신, 사용자의 목표를 이해하고 공유 신호를 바탕으로 추론하며 기존 Ads 서비스를 오케스트레이션하는 통합적이고 프로그래밍 가능한 의사결정 계층이 필요하다고 판단했다.
초기 적용 분야로 Media Planning을 선택했고, RouterAgent, GoalResolverAgent, AudienceResolverAgent, BudgetAgent, ScheduleAgent, MediaPlannerAgent 등 역할별 에이전트를 구성해 자연어 캠페인 요구사항을 구조화하고 최적화된 광고 세트 추천을 생성했다.
결과적으로 수동 미디어 플랜 작성에 15~30분 걸리던 작업을 5~10초 수준으로 줄이고, 20개 이상의 입력 필드를 1~3개의 자연어 메시지로 대체하며, 과거 캠페인 성과 데이터를 기반으로 추천을 생성하는 방향으로 사용자 경험과 시스템 일관성을 개선했다.

🧠 상세 정리

1. 문제의 출발점: AI 기능이 아니라 구조적 운영 문제

Spotify가 이 프로젝트를 시작한 이유는 단순히 새로운 “AI 기능”을 출시하기 위해서가 아니었다. 원문은 광고 비즈니스가 소프트웨어 안에서 실제로 작동하는 방식에 구조적 문제가 있었다고 설명한다. Direct, Self-Serve, Programmatic 같은 여러 구매 방식은 대부분 통합된 백엔드를 공유하지만, 각 채널은 서로 다른 워크플로와 의사결정 로직, 성공 기준을 갖고 있었다. 엔지니어링 관점에서는 완전히 다른 기술 스택이라기보다, 하나의 몸체에 여러 개의 서로 다른 “두뇌”가 연결된 형태에 가까웠다. 그 결과 동일한 서비스와 데이터가 여러 구매 경험을 떠받치면서도, 실제 행동 방식은 표면과 채널마다 분절되어 있었다.

2. 통합 백엔드 위에 남아 있던 분절된 의사결정

원문은 Spotify가 이미 서비스 통합을 어느 정도 진행했음에도 워크플로 계층에서는 여전히 파편화가 남아 있었다고 지적한다. 예산을 어떻게 배분할지, 어떤 인벤토리를 선택할지, 도달률과 효율성 및 STR 사이의 균형을 어떻게 맞출지 같은 핵심 판단이 채널과 표면마다 다시 구현되고 있었다. Spotify Ads Manager, Salesforce, Slack, 내부 도구 등 여러 표면에서 비슷한 자동화가 서로 조금씩 다른 방식으로 같은 문제를 풀고 있었다. 작은 워크플로 변경도 사실상 동일한 계획·최적화 문제의 변형이지만, 여러 곳에 따로 반영하고 유지해야 했다. 시간이 지날수록 이런 중복 구현은 로직의 드리프트와 기술 부채를 만들 수밖에 없었다.

3. 전통적 서비스 설계 방식의 한계

일반적인 해결책은 새로운 서비스를 설계하고, 캠페인 계획과 관리를 위한 올바른 상태 머신을 정의한 뒤, REST 엔드포인트를 만들고 UI에 연결하는 방식일 수 있었다. 그러나 Spotify는 이 접근이 현재 문제의 형태와 맞지 않는다고 판단했다. 미디어 플래닝은 사용자 유형, 사용 가능한 인벤토리, 비즈니스 우선순위, 광고주 목표, 예측, 오디언스 선택, 크리에이티브 안내, 페이싱, 최적화가 서로 얽혀 있는 조합적 문제다. 몇 개의 하드코딩된 “해피 패스”를 채널별로 만들어 두는 방식으로는 변화하는 조건을 견디기 어렵다. 더 나은 예산 배분이나 인벤토리 우선순위 결정 방식이 생겨도, 그것이 여러 표면에 일관되게 반영되지 않으면 다시 중복과 불일치가 발생한다.

4. 필요했던 것은 통합된 의도와 의사결정 계층

Spotify가 정의한 핵심 문제는 새 백엔드의 부재가 아니었다. 원문은 목표를 이해하고, 공유 신호를 바탕으로 추론하며, 기존 Ads API를 사용자 대신 일관되게 오케스트레이션할 수 있는 통합적이고 프로그래밍 가능한 의사결정 계층이 없었다고 정리한다. 기존 시스템은 라인 아이템 생성, 예측 실행, 인사이트 조회처럼 개별 작업을 수행하는 데는 능숙했다. 하지만 “브라질에서 도달을 극대화하고, 비디오 인벤토리를 보호하면서도 STR을 맞춘다” 같은 목표를 받아 도구 호출, 트레이드오프, 점검 절차의 시퀀스로 바꾸는 데는 약했다. 이 의도 계층의 결여가 채널과 표면을 가로지르는 일관된 자동화를 어렵게 만들었다.

5. 거대한 규칙 엔진 대신 에이전트 접근을 택한 이유

Spotify는 반대편 극단인 거대한 규칙 엔진을 만드는 것도 원하지 않았다고 설명한다. 광고 로직은 복잡하고 확률적이며 끊임없이 변한다. 예측, 최적화, 인사이트는 이미 머신러닝에 크게 의존하고 있으며, 이를 정적인 결정 트리로 고정하면 곧바로 취약해지고 유지보수가 어려워질 수 있다. 그래서 Spotify는 캠페인 계획과 관리를 모듈형 에이전트들의 집합으로 다루는 에이전트형 접근에 베팅했다. 이 에이전트들은 인벤토리, 오디언스, STR, 품질과 리스크, 성과 이력 같은 같은 기반 신호를 소비하고, 광고주 목표와 Spotify의 비즈니스 제약을 함께 최적화하며, 기존 Ads 서비스를 새로 구현하지 않고 도구처럼 사용한다.

6. Media Planning을 첫 적용 사례로 선택한 배경

원문은 이 접근을 어디에서 먼저 검증할지에 대한 답으로 Media Planning을 선택했다고 밝힌다. 미디어 플래닝은 영업, 광고주, 인벤토리, 페이싱, 광고 상품이 한곳에서 충돌하는 지점이기 때문에 앞서 설명한 복잡성이 한꺼번에 드러난다. 또한 캠페인 라이프사이클의 비교적 앞단에 위치하기 때문에, 이 단계에서 더 나은 결정을 내리면 이후의 예약, 트래피킹, 전달, 최적화 단계 전체에 긍정적 영향을 줄 수 있다. 기존 미디어 플래닝에서는 목표 정의, 오디언스 타기팅, 예산 배분, 일정 계획, 포맷 선택 등 여러 상호 연결된 결정을 광고주가 수동으로 구성해야 했다. 특히 유사 캠페인에서 무엇이 잘 작동했는지에 대한 과거 성과 데이터 접근성이 낮다는 점이 큰 pain point였다.

7. 멀티 에이전트 구성과 각 에이전트의 역할

Spotify의 구현은 전문화된 AI 에이전트들이 미디어 플래닝의 서로 다른 측면을 맡는 멀티 에이전트 아키텍처를 중심으로 한다. RouterAgent는 사용자의 입력 메시지를 분석해 어떤 정보가 들어 있는지 판단하고, 불필요한 LLM 호출을 줄이며 조건부 에이전트 실행을 가능하게 한다. GoalResolverAgent는 사용자의 의도를 REACH, CLICKS, APP_INSTALLS 같은 캠페인 목표로 매핑하고 적절한 광고 카테고리를 찾는다. AudienceResolverAgent는 관심사, 지역, 연령대, 성별 등 타기팅 기준을 추출하고, BudgetAgent는 다양한 예산 표현을 파싱해 마이크로 단위로 변환한다. ScheduleAgent는 “다음 달”, “30일” 같은 상대 날짜를 포함한 일정 해석을 담당하며, MediaPlannerAgent는 해석된 정보를 바탕으로 과거 성과 데이터와 휴리스틱 엔진을 활용해 최적화된 광고 세트 추천을 만든다.

8. 최적화 규칙, 도구 통합, 구현상의 절충

MediaPlannerAgent의 최적화는 과거 성과 데이터를 바탕으로 한 휴리스틱 엔진에 의해 수행된다. 원문은 비용 지표를 과거 중앙값 대비 최소화하는 비용 최적화, 전달률을 100%에 가깝게 맞추는 전달률 최적화, 유사한 예산 범위와 캠페인 기간을 가진 과거 성공 사례 매칭, 인구통계와 관심사 겹침 기반 타기팅 매칭, 포맷과 목표 조합의 다양성 확보 등을 핵심 규칙으로 제시한다. 예산 규모에 따라 추천 수를 자동 조정하는 규칙도 포함되어, 0~1,000유로는 1개, 1,000~5,000유로는 2개, 5,000~15,000유로는 3개, 15,000유로 이상은 4~5개의 추천을 생성한다. 단일 에이전트는 프롬프트가 거대해지고 병렬화가 어렵다는 이유로 배제했고, 인메모리 캐시는 지연 시간을 낮추기 위해 선택했으며, 초기에는 단순성을 위해 스트리밍보다 동기 응답을 택했다.

9. 성과와 영향: 입력 감소, 속도 개선, 데이터 기반 추천

원문에서 제시된 성과는 수동 미디어 플래닝과 에이전트형 접근의 차이를 분명히 보여준다. 기존에는 미디어 플랜 작성에 15~30분이 걸렸지만, 에이전트 기반 시스템에서는 5~10초 수준으로 줄었다. 사용자가 입력해야 하는 항목도 20개 이상의 폼 필드에서 1~3개의 자연어 메시지로 감소했다. 최적화에 사용되는 근거도 사람의 직관에 의존하던 방식에서 수천 개 캠페인의 과거 성과 데이터로 바뀌었다. 병렬 실행을 활용한 에이전트 응답 지연 시간은 약 3~5초로 제시되며, 전체적으로 광고주는 캠페인을 자연어로 설명하고 시스템은 데이터 기반 추천을 생성하는 방향으로 인지 부담과 반복 비용을 줄였다.

🧾 핵심 주장 / 시사점

이 글의 핵심은 LLM을 UI 보조 기능으로 붙이는 것이 아니라, 흩어진 의사결정 로직을 하나의 재사용 가능한 의도 계층으로 끌어올리는 데 있다.
멀티 에이전트 구조의 장점은 단순히 ‘여러 에이전트가 있다’는 점보다, 목표·오디언스·예산·일정·최적화처럼 도메인 책임을 나누고 병렬 실행과 개별 테스트가 가능해진다는 점이다.
Spotify의 사례는 통합 백엔드만으로는 제품 경험의 일관성이 보장되지 않으며, 채널과 표면을 가로지르는 결정 로직을 어떻게 중앙화하고 관찰·평가·보호할지가 중요하다는 점을 보여준다.

✅ 액션 아이템

광고 API와 Ads Manager UI에서 같은 캠페인 의도가 일관된 결과로 이어지는지 검증할 수 있도록 공통 intent layer와 회귀 테스트를 정의한다.
STR 기반 라우팅, 채널별 에이전트, 중앙 의사결정 로직이 각각 어떤 판단을 맡는지 문서화하고 실패 시 fallback 경로를 분리한다.
multi-agent 광고 시스템에서 사람이 검토해야 하는 지점과 자동 실행 가능한 지점을 구분해 예산, 타기팅, 크리에이티브 변경의 승인 정책을 마련한다.