안녕하세요, 광고 엔진 팀의 Bale, 그리고 Liam입니다. 1편에서 버즈빌의 예산 제어 시스템 개선 여정과 가시성에 대해 얘기해 드렸는데요. 이번 편에서는 이전 시스템 수준 개선을 바탕으로 어떤 기능 개선과 비즈니스 임팩트를 만들었는지 소개 드리려 합니다. 1편의 개선을 바탕으로 이야기가 전개되니 여기에서 이전 여정을 먼저 읽어보시는 걸 추천드립니다.

더 정교한 예산 제어 시스템으로

계획된 예산을 더욱 정교하게 컨트롤하는 것은 여러 광고 시스템에서 공통적으로 풀고자 하는 예산 제어 시스템의 일반적인 문제입니다. 그에 대한 답은 어찌 보면 당연하게도 예산 제어를 더 자주 실행하고 세밀하게 조절하는 것인데요. 저희는 크게 3가지 개선을 진행하여 더 정교한 예산 제어 시스템을 달성할 수 있었습니다.

1. 더 자주 평가합니다

더 자주 평가하는 것은 예산 목표 달성과 성과 최적화에 있어 아주 중요합니다. 예를 들어 10분 단위로 예산 제어를 수행한다고 가정했을 때 그 사이에서 발생한 지출 스파이크에 의해 초과 지출이 발생할 수 있고 이러한 제어 실패가 누적되면 최악의 경우 예산 목표를 달성할 수 없거나 성과 최적화를 고려한 지출 계획이 무산될 수 있습니다.

하지만 버즈빌의 초기 예산 제어는 꽤 큰 주기로 동작했음에도 어느 정도 기능을 잘 수행했습니다. 어떻게 가능했을까요? 이는 실패가 누적되어도 지출 계획에 의해 교정될 수 있기 때문입니다. 예를 들면 시간당 10만 원을 소진해야 하는 캠페인이 12만 원씩 5시간을 소진하게 되면 그다음 한 시간 동안은 지출을 막아 계획대로 교정하게 되고 최종적으로는 목표 예산에 근접할 수 있기 때문입니다. 예시를 보면 알 수 있듯 평가 주기를 줄일수록 오차 교정이 많아지기에 더 정교하게 지출 계획을 달성할 수 있습니다.

버즈빌은 주기마다 모든 활성 캠페인에 대해 평가를 진행하고 있어 평가 성능과 지출 집계 등의 지연 시간에 의존합니다. 1편의 여정을 거치면서 마이크로서비스로 분리하며 성능상 이점을 확보하고 지출 집계를 개선하면서 지연 시간을 줄여 현재 버즈빌의 모든 캠페인은 15초에 한 번 평가되고 있으며 초기 상태와 비교해 훨씬 안정적으로 지출 계획을 달성하고 있습니다.

2. 더 세밀하게 지출을 계획합니다

만약 제어 평가 주기를 충분히 줄였으나 1시간당 10만 원의 지출 계획을 세우면 어떤 문제가 생길 수 있을까요? 아마 가장 큰 문제는 10분 만에 10만 원을 모두 지출해버리고 50분 동안 광고가 송출되지 않는 것입니다. 이는 지속적으로 광고가 노출되지 않는 그 자체로 문제가 될 수 있고 초반 지출에 의해 기회가 많은 시간에 예산을 못쓰게 되어 성과 최적화에도 영향을 줍니다.

초기 버즈빌은 1시간 단위로 지출을 계획했는데, 현재는 1분 단위로 지출을 계획하고 있습니다. 지출 계획의 범위를 좁히는 것은 어려운 일이 아니나 지출 계획의 범위가 평가 주기보다 큰 경우 사실상 의미가 없기 때문에 이 일 또한 평가 주기를 줄일 수 있는 시스템의 성장 덕분이었습니다.

3. 더 세밀하게 광고 송출량을 제어합니다

최초 예산 제어 로직은 예산 평가 후 지출이 필요하면 광고 송출을 활성화하고, 반대의 경우 비활성화하는 방식으로 동작했습니다. 충분히 동작하는 방식이지만, 만약 광고 트래픽이 10배, 100배 늘어난다면 어떻게 될까요? 기존 대비 100배 트래픽에 대해 송출이 활성화된다면 순식간에 엄청나게 많은 지출이 발생하고, 결국엔 제어 주기와 지출 계획을 줄였음에도 불구하고 의도대로 제어할 수 없을 것입니다. 버즈빌은 지난 몇 년에 걸쳐 제휴 지면이 늘어나면서 트래픽이 상당히 증가하였고, 광고 송출을 활성/비활성 하는 기존 방식으로는 예산 소진을 부드럽게 제어하기 힘든 상태였습니다.

저희는 링크드인이 게재한 논문에서 좋은 사례를 접할 수 있었는데요. 제어 방식만 보자면 광고 송출량을 활성/비활성 방식이 아닌 송출률로 제어하는 방식입니다. 이는 송출률을 점진적으로 조정하여 지출을 부드럽게 제어할 수 있고 트래픽이 늘어나더라도 일정 수준까지는 유연하게 대처 가능합니다. 실제 제안하는 방식은 더 디테일한 내용이 많아 궁금하시다면 원문을 읽어보시길 추천드립니다.

저희는 현재 버즈빌의 상황에 맞추어 적용하였고 최종적으로 1. 더 자주 평가하고 2. 세밀하게 지출을 계획하고 3. 세밀하게 송출량을 조절하여 위와 같은 긍정적인 변화를 만들 수 있었습니다.

더욱 빠르게 움직이기

지금까지 광고 시스템을 개선해왔는데요. 운이 좋게도 이러한 개선이 완료될 무렵, 광고 성과 최적화, 캠페인 운영 편의성 등을 개선하는 비즈니스 요구사항을 만날 수 있었습니다. 요구사항의 디테일은 다양했는데 각 요구사항은 광고 상품별로 다르게 적용되기도 하고 광고 목적에 따라 다르게 적용되기도 했습니다.

이때까지만 해도 제어력을 높이는데 열을 쏟던 터라 디테일한 내부 구성에 대해서는 자신감 있게 이해한 상태는 아니라서 먼저 내부 로직을 살펴보기 시작했습니다. 내부 로직은 모든 캠페인에 대한 예산 제어 동작을 추상화한 상태였는데 과도기에 발생한 비즈니스 요구사항들을 광고 상품, 광고 목적 등에 따라 코드 여러 곳에서 분기하여 처리하고 있어 동작을 파악하기 힘들고 변경 시 사이드 이펙트를 예측하기 어려운 상황이었습니다.

팀에서는 예산 제어 문제 영역에 대한 충분한 성숙도가 없는 상황에서 현재 상태는 이른 추상화로 판단되어 우선 변경에 유연한 구조로의 리팩터링을 결정했습니다. 현재 요구사항 및 기존 코드의 구현으로부터 구분되는 몇 가지 패턴을 찾아 ‘예산 제어 전략’을 도출하고 각 전략별로 제어 로직이 별도로 구현되도록 추상화 수준을 낮추었습니다.

이 과정에서 새로운 요구사항인 각 소진 전략별로 안전한 소진 마감을 위한 조기 마감 기능, 운영 리소스를 절감을 위한 일 지출 예산을 평균적으로 보장하는 기능 등을 추가하게 되었는데요. 이는 한 번에 많은 캠페인의 제어 로직을 변경하는 작업이라 이전보다 더 높은 수준의 검증이 필요했습니다.

이 문제를 만나기 전부터 예산 제어 로직 검증 과정의 개선이 필요하다 생각했는데요. 일반적인 API의 경우 요청에 대해 1. 응답이 즉각적이고 2. 상태 변화가 없거나 3. 시간의 흐름에 따른 검증이 크게 필요 없는 경우가 많기 때문에 단위 테스트와 통합 테스트에 포함시키면 자동화된 CI를 통해 검증이 가능한 반면 예산 제어 시스템은 1편에서 얘기했듯 일종의 피드백 루프를 가져 부분적으로 검증되어도 최종적으로 잘 동작한다는 자신감을 갖기 어려웠습니다.

이에 팀에서는 검증 기간을 단축하고 작업자와 리뷰어가 같은 결과를 보고 상호 신뢰할 수 있도록 캠페인 시뮬레이터를 개발하기로 결정했습니다. 시뮬레이터는 간단한 커맨드로 개발되었으며 광고 요청 트래픽을 생성하고 소진 제어 시스템이 결정하는 예산 제어 상태에 따라 캠페인 송출 및 노출 이벤트를 생성하고 이를 그라파나 패널로 시각화하여 리뷰 과정에 이용할 수 있도록 구성했습니다.

시뮬레이터는 이후 로직 개발 및 리뷰 과정에서 활용되었으며 팀에서는 기존 개발 및 검증에 1주일 정도 걸렸던 작업들도 평균 1-2일 내에 상용 환경에 반영할 수 있었습니다. 그리고 작업자로서는 불안함에 만성적으로 모니터링하는 시간이 줄어 만족스러웠고 시뮬레이터가 작업된 11월부터 자신감이 붙어 배포 빈도가 눈에 띄게 늘어난 것을 확인할 수 있었습니다.

물론 상용 환경 검증에서의 긴장감도 놓을 순 없었는데요. 이는 초기 수 분의 지연 시간을 가진 분석계 로그 기반의 패널에서 가시성 확보 과정에서 만든 실시간 패널로 이전하면서 현재 상태를 즉각적으로 확인하고 대응할 수 있어 전보다 더욱 자신감 있게 진행할 수 있었습니다. 또한 이 기능은 제품팀뿐만 아니라 캠페인 운영에도 도움이 될 것이라 판단하여 내부 캠페인 운영 도구에도 이식되어 유용하게 쓰이고 있습니다.

여기까지 비즈니스 요구사항이 늘어남에 따라 필요한 변경을 수행하고, 시뮬레이터를 만들어 검증 기간을 크게 단축한 경험을 얘기드렸는데요. 이 과정에서 각 상품에 대한 이해도도 높아졌고 동시에 예산 제어 시스템을 더 깊게 이해할 수 있게 되었습니다. 다음으로는 경험과 이해를 바탕으로 실제 성과까지 이어진 경험을 소개드리고자 합니다.

복리로 돌아오는 개선

라이브커머스 춘추전국시대의 생존법에서 소개 드린 대로 라이브커머스 광고는 운영 초반에 많은 사용자에게 노출하는 게 중요한 상품입니다. 라이브커머스 상품은 방송 중에 최대한 모객 되어야 하는 상품이기에 저희는 짧은 시간 안에 많은 노출을 발생시키고 있는데 이 중 일부는 사용자 환경에 따라 지연 노출되기도 합니다. 방송 종료 후에는 유입이 일어나더라도 광고주에게는 의미가 없고 광고 시스템도 불필요한 지면 구매 비용을 감수해야 해서 상품 수익성에도 악영향이 있는 상태였습니다.

라이브커머스 개선을 위한 첫 접근은 예산 제어 시스템이 고도화되면서 자연스럽게 일정 부분 개선될 것이라는 가설이었습니다. 저희는 지금까지 진행한 고도화 여정에서 틈틈이 라이브커머스 캠페인이 종료 후 소진되는 비율이 개선되는지를 확인했는데 아쉽게도 유의미한 개선은 확인할 수 없었습니다. 하지만 라이브커머스 상품 종료 후 발생하는 과도한 노출 문제는 명확하게 존재했고, 이를 해결하면 상품성과 수익성 모두 개선할 수 있기에 지금까지 시스템을 개선하면서 쌓아 온 자신감에 힘을 얻어 이 문제를 풀어보는 게 어떨지 팀에 제안하여 진행할 수 있게 되었습니다.

저희는 우선 문제를 더 잘 이해하기 위해 데이터를 확인하기 시작했습니다. 평균적으로 전체 노출의 약 10-15%가 운영 종료 후 발생하고 있었는데요. 광고 송출로부터 노출이 집계되기까지의 지연시간 분포를 확인했을 때 최대 2시간까지 지연되는 경우도 있었지만, 약 75% 노출은 광고 송출 시점으로부터 15분 이내에 집계되고 있었습니다. 라이브커머스 캠페인은 대부분 1-2 시간 이내의 운영시간을 가지기 때문에 운영 종료 후 노출 트래킹 지연이 미치는 영향이 큰 것으로 확인되었습니다. 여기서 광고 예산을 선형적으로 배정하지 않고 지수적 감소하도록 배정하여 운영 후반부에는 지연 발생하는 노출을 최대한 제어에 포함한다면 최종적으로 방송 종료 후 발생하는 노출이 줄어들 것이라는 가설을 세웠습니다.

가설을 검증하고 적용하는 일은 그동안 쌓아온 개선이 복리로 돌아와 수월하게 진행할 수 있었습니다. 이전에 여러 소진 패턴의 확장을 고려해 추가한 소진 타입 덕에 새로운 소진 타입을 쉽게 추가할 수 있었고 시뮬레이터에 지연 노출까지 반영할 수 있는 기능을 추가하여 상용 환경 배포 전에 개선과 동작을 확인할 수 있었습니다. 이 일들은 일사천리로 진행되어 구현, 검증 그리고 상용화까지 2일 만에 달성할 수 있었습니다.

최종적으로 방송 시간 종료 후 발생하는 매체 지출을 약 60% 줄일 수 있었고 상품의 전체 수익성 또한 약 3.5% 개선되었습니다. 동시에 방송시간 초반에 유입을 더 늘려서 후반부에 안정적으로 마감함으로써 라이브커머스 상품에 대한 광고주의 만족도도 높일 수 있었습니다. 결과도 만족스럽지만 풀어나가는 과정에서 그동안 점진적으로 개선해온 것의 이점을 피부로 느낄 수 있어서 더 좋은 경험이었습니다.

마무리하며

지금까지 광고 엔진팀의 예산 제어 시스템 고도화 여정을 읽어주셔서 감사합니다. 꽤 많은 내용을 다뤘는데, 요약해 보자면 가장 먼저 시스템의 핵심 입력과 출력, 그리고 핵심 지표를 정의하고, 목표 상태를 설정하였습니다. 그리고 목표한 상태에 도달하기 위해 한 번에 모든 것을 바꾸지 않고 점진적으로 개선해 나갔습니다. 그 과정에서 시스템의 가시성을 확보해나가면서 심리적 안정감을 갖게 되었고 가설 검증 속도를 가속할 수 있었습니다. 이것이 끝이 아닙니다. 앞으로 팀이 그리고 있는 계획의 일부만 진행한 상태인데요. 예를 들어 인벤토리 물량을 예측하는 모델을 만들어 예산 배정 전략을 고도화하거나, 예산 제어 상태를 결정하는 다양한 알고리즘 또는 모델을 실험해 볼 계획입니다. 이 이외에도 광고 성과를 개선하기 위한 다양한 문제들을 풀어나갈 예정이니 다음 글도 기대해 주시기 바랍니다.

이 모든 과정은 다양한 팀의 피드백과 지원이 있었기 때문에 가능했습니다. 특히 예산 제어 로직 고도화에 같이 힘써주신 Ad Management, CM 팀, 그리고 다양한 플랫폼적인 지원을 해주신 Datavil, DevOps 팀에 감사의 말씀을 전합니다.

버즈빌 개발자 지원하기 (클릭)

버즈빌 테크 리크루터와 Coffee Chat하기 (클릭)