들어가면서: 광고 내재화 프로젝트
오늘의집 광고 서비스는 2025년까지 업계 최고의 외부 솔루션을 사용하며 지속적으로 높은 성과를 유지해 왔습니다. 그럼에도 불구하고 내부 역량 강화를 위해 내재화 프로젝트를 진행하게 된 배경은 다음과 같습니다. 첫째, 해당 도메인에 성숙한 경험을 보유한 구성원들의 전문성을 활용하고자 했습니다. 둘째, 다년간 추천 및 검색 도메인을 통해 축적한 충분한 기술력을 기반으로 시너지를 내고자 했습니다. 셋째, 적지 않은 수수료 절감을 통해 공헌이익을 극대화하는 것이 목표였습니다.
광고 추천 시스템은 다양한 요소가 복잡하게 얽혀 있는 구조입니다. 이 시스템에서 추천팀의 역할은 지면에 맞춰 사용자에게 개인화된 상품을 추천하고, 사용자가 클릭할 확률(pCTR) 값을 함께 제공하는 것이었습니다. 기존에 이미 추천 시스템과 pCTR 예측 모델이 있었기에, 이를 최대한 활용하여 내재화 시스템을 구성했습니다.
2025년 4월 21일, 소규모 트래픽을 대상으로 첫 A/B 테스트(ABT)를 시작했습니다. 첫 내재화 대상이었던 검색 광고는 오픈 초기 CTR(클릭률)이 1% 중반대로, 동종 벤치마크 대비 약 50% 수준에 불과했습니다. 그러나 집중적인 개선 노력 끝에 2025년 6월 10일 MoM(전월 대비) 비교 기준으로 상품 광고는 CTR +35%/CVR +33.4%, 검색 광고는 CTR +55%/CVR +38.4%까지 개선하는 성과를 거두었습니다. 결과적으로 벤치마크 대비 평균 90% 수준의 성능을 달성하며 성공적인 내재화의 방향성이 유효함을 입증했습니다.
현재는 동종 벤치마크와 유사한 수준의 퍼포먼스를 달성했으며, 내재화된 광고 시스템을 통해 광고주와 사용자 모두에게 다양한 가치를 제공하고 있습니다. 이번 테크 블로그를 통해, 2025년 5월부터 6월까지 약 두 달 동안 진행된 모델 개선 과정에서 얻은 경험과 인사이트를 공유하고자 합니다.
문제 정의 : CTR 향상을 위한 도전
검색 광고는 사용자의 검색 의도에 가장 적합한 상품이나 콘텐츠를 노출하여 클릭과 전환을 유도하는 광고 방식입니다. 이는 플랫폼 수익 구조의 핵심이자 검색 품질을 구성하는 중요한 요소입니다. 그러나 전통적인 키워드 매칭 검색 시스템에는 구조적인 한계가 있었습니다. 키워드별 품질 편차가 존재할 수 있고, 높은 연관성을 확보하더라도 키워드 중심의 단순 매칭에 의존하여 문맥을 충분히 반영하지 못하며, 사용자 취향이나 의도 변화에 둔감하다는 문제가 발생할 수 있습니다. 또한 광고 순서가 잘 변경되지 않아 반복적인 노출로 인한 비효율이 발생해 낮은 CTR(클릭률) 및 CVR(전환율)로 이어질 수 있습니다. 결국 광고주 입장에서는 예산 대비 성과가 제한되고 사용자 경험 역시 저하되는 결과를 낳게 됩니다.
예를 들어, 첫 내재화 타겟 중 하나인 검색 광고의 오픈 초기 CTR이 1% 중반대에 머물렀는데요. 앞서 말한 이유로 인해 비슷한 상품군만 반복적으로 노출되거나 검색어 조합에 과민하게 반응하는 현상이 나타났습니다. 이 한계를 극복하기 위해, 검색 엔진과 추천 엔진을 통합한 새로운 방식으로 전환하고(개인화 추천 시스템 1: Multi-stage Recommender System), CTR이 검증된 Producer를 광고 시스템에도 재사용하는 방향으로 문제를 재정의했습니다. 이에 따라 연관이 적은 상품들이 상단에 노출되는 경우가 발생할 가능성이 생길 수 있지만, 연관성에 대한 부분만 잘 컨트롤한다면 유저의 선호에 따라 더 다양한 상품군을 노출할 수 있다고 생각했습니다.
광고 추천 시스템 구조에서 Producer는 검색 결과뿐만 아니라 다양한 사용자 맥락과 상태를 기반으로 추천 알고리즘을 활용한 후보(Candidate)들을 제공합니다. Mixer는 다양한 Producer에서 생성된 후보들을 중복 제거(deduping)하고 필터링합니다. Ranker는 Calibration된 pCTR(예측 클릭 확률) 결과를 제공하며, Twiddler는 추가적인 후처리 로직을 적용합니다. 이러한 일련의 시스템을 통해 다양한 Producer, 필터링, 랭킹 로직을 손쉽게 테스트할 수 있는 환경을 구축했습니다.
이후 목표는 명확해졌습니다. 검색 광고를 검색과 추천이 결합된 복합 문제로 정의하고, 사용자 로그와 쿼리 맥락을 통합 처리할 수 있는 데이터/모델링 및 실험 환경을 구축하는 것이었습니다.
실험 엔지니어링 방식의 변경 시도
Bolder Faster
ML Engineer로서, 저는 종종 “입력이 달라지지 않으면 출력도 달라지지 않는다”는 말을 되새깁니다. 기존 방식으로는 큰 성능 향상을 달성하기 어렵다고 판단했습니다. 새로운 성과를 내기 위해서는 단순히 모델 품질을 높이는 것을 넘어, 실험을 더 빠르고 더 정확하게 반복할 수 있는 환경이 필수적이었습니다.
이 문화 코드는 집중 개선 기간 동안 기존보다 더 빠르고 효과적으로 움직이기 위해 팀의 사고방식을 동기화하고자 진행되었습니다.
- Move Fast: 정해진 목표 달성에 꼭 필요한 것만 진행하며, 완벽한 실험 설계를 기다리기보다 일단 동작하는 구조를 만드는 데 집중했습니다. 그 위에서 학습하고 개선해 나가는 자세를 취했습니다.
- Be Bold: 각 실험을 Product Owner나 매니저가 설계하기보다, 개별 MLE(Machine Learning Engineer)가 주도적으로 설계하고 결과를 책임지는 원칙을 세웠습니다.
일반적으로 ML Engineer들은 "성능을 높이려면 모델 구조를 바꿔야 한다"고 생각하며 모델 개선에 많은 초점을 맞춥니다. 하지만 이번 프로젝트의 성공 방안을 고민하면서, 당시의 진짜 병목은 모델이 아니라 실험의 속도에 있다는 것을 깨달았습니다. 기존에는 하나의 가설을 검증하기 위해 약 2주간의 실험이 필요했기에 두 달이라는 정해진 기간 동안 할 수 있는 실험은 최대 8회에 불과했습니다. 이러한 상황에서 우리는 ‘정확히 맞는 해답’을 찾는 것보다 ‘빠르게 실수하고 바로잡을 수 있는 환경’을 구축하는 것이 더 중요하다는 가설 아래 다양한 시도를 진행했습니다.
집중 개선 기간 동안 실험의 반복 속도를 높이기 위해 시도한 주요 방식은 다음과 같습니다.
과거 데이터를 기반으로, 목적에 따라 다른 실험 기간 활용
수개월간의 과거 데이터를 분석한 결과, CTR의 경우 1~2일 정도만 추세가 유지되어도 순위가 쉽게 역전되지 않는 경향을 발견했습니다. 반면, 전환율(CVR)은 새로운 알고리즘의 추천으로 인해 노출된 상품을 사용자가 직접 구매하기까지 최소 며칠의 시간이 필요했습니다. 이러한 과거 현상을 바탕으로 더 과감하게 움직일 수 있도록, 집중 개선 기간 동안은 실험 목적이 CTR 향상이라면 1~2일만 지켜보고 뚜렷한 업사이드가 보일 경우 과감하게 런칭하고 다음 실험을 진행했습니다.전환율 관련 지표 확인이 목적이라면 7~14일 정도로 기존과 유사한 기간의 실험을 진행했습니다. 이 방식의 장점은 빠른 실험과 반복(iteration)이 가능하다는 점, 그리고 짧은 시간에 더 많은 시도를 할 수 있다는 점이었습니다. 단점으로는 엄밀한 의미의 통계적 검증이 어렵고, 다양한 실험 기간이 겹칠 때 의사결정이 복잡해진다는 점이 있었습니다. 이번에는 프로젝트 전체의 성공을 위해 빠른 시간 내에 더 많은 업사이드를 만드는 것이 중요했기에 불확실성을 감내했지만, 일반적으로는 좀 더 엄밀한 검증 프로세스가 필요합니다.
다양한 실험 기간을 가진 실험들이 공존할 수 있는 데이터 분석 도구 활용
다양한 실험을 병렬적으로 실행하다 보면 기간이 겹칠 때 의사결정이 교착상태에 빠지기 쉽습니다. 예를 들어, 특정 실험군이 CTR은 매우 높지만 전환율은 기존보다 떨어지는 상황이 발생할 수 있습니다. 광고는 사용자와 광고주 모두의 가치가 중요하므로, 새로운 모델 도입 환경에서 사용자가 구매 의사결정을 할 수 있도록 조금 더 긴 호흡으로 전환율 추이를 관찰해야 합니다. 동시에 그 기간 동안 다른 실험들은 지속적으로 변경되며 시도되어야 했습니다. 이를 위해 다양한 실험을 서로 다른 기간 동안 동시에 진행할 수 있는 체계를 시도했습니다.
오늘의집 실험 플랫폼인 XPC에서는 하나의 인벤토리에 대한 여러 실험들을 version이라는 요소로 구분합니다. 그룹의 수와 그룹당 비율이 변하지 않는다면, 단순히 version을 올리는 것은 기존 실험군에는 영향을 주지 않습니다. 이 특징을 활용하여 그림의 Group D와 같이 전환율 확인이 필요한 실험의 경우 그룹의 수와 비율을 유지함으로써 해당 그룹을 지속적으로 관찰하고, Group A, B, C는 다른 그룹들의 실험군만 변경하는 방식으로 다수의 실험을 효과적으로 통제할 수 있었습니다. 여러 버전에 걸쳐있는 그룹에 대한 지표를 통합하여 비교했음에도, 실험군 내 사용자군은 동일했기에 지표의 변화는 여전히 유의미했습니다.
오히려 의사결정이 어려웠던 부분은 중간중간 짧은 시간으로 진행되는 클릭률 개선 실험들이었습니다. 이 경우에는 winner 선정이 어렵지 않다면 즉각 winner로 선정하여 A그룹에 런칭했고, 런칭된 결과는 동시에 그룹 D에 반영되어 winner로 인한 효과를 양쪽에 반영하도록 했습니다. 정확한 규칙보다는 상황에 따른 의사결정을 진행했으며, 결과적으로 더 업사이드가 있어 보이는 것들을 빠르게 적용하는 방향인지 고민하고, 빠르게 시도하여 더 적절한 솔루션을 찾는 과정을 반복했습니다. 이러한 실험 방식이 엄밀하지는 않았지만, 단기적으로 더 많은 실험을 통해 추세적으로 더 좋은 선택을 하기 위해 지속적으로 관찰을 이어나갔습니다.
실시간 지표 수집 엔진
광고 시스템은 OLAP(Online Analytical Processing) 엔진을 통해 지표를 수집하고 추적할 수 있도록 구성되었습니다. 저희는 Imply 서비스를 활용하여 지표를 실시간으로 수집하고 파악함으로써 실험에 대한 다양한 측면을 확인할 수 있었습니다. 예를 들어, OLAP 엔진을 통해 그룹별 성능뿐만 아니라 Producer별 성능, Producer 점수 또는 랭크별 성능까지 거의 실시간으로 확인할 수 있었습니다. 이러한 도구들을 통해 시스템을 지속적으로 모니터링 하면서 빠른 의사결정이 가능했고, 다음 목표를 위한 데이터 탐색에도 소요되는 시간을 크게 줄일 수 있었습니다.
이러한 실시간 지표 도구는 특히 과정 중 변화에 대한 업사이드와 다운사이드를 빠르게 파악할 수 있게 하여 의사결정 속도를 크게 향상시켰습니다. 예를 들어, PO와 Engineer 등 직무에 관계없이 회의마다 Data Analyst의 도움 없이도 각자가 실시간으로 다양한 축으로 지표를 분석하며 의견을 나눌 수 있었습니다. 이렇게 실시간으로 이루어지는 지표 분석 결과를 바탕으로, 실험군의 변경 사항이 적용되더라도 사용자와 광고주의 가치를 손상시키지 않을지에 대한 논의와 의사결정이 매번 막힘없이 진행될 수 있었습니다.
서버 기반 컨피그(Server Driven Config)로 배포 없이 실험을 진행할 수 있는 환경
실험 속도를 높이기 위해 Central Dogma(https://github.com/line/centraldogma) 기반의 Server Driven Config 구조를 적극적으로 활용했습니다. 이 config에는 어떤 producer, mixer, ranker, twiddler를 어떤 순서로 사용하는지에 대한 정보가 담겨 있습니다. 기존에는 단순한 Producer 변경이나 필터링 추가와 같은 간단한 실험 변경 사항조차도 '코드 수정 → 빌드 → 배포' 과정을 거쳐야 했기 때문에 실험 한 번에 수 시간에서 수 일이 소요되기도 했습니다. 그러나 서버에서 각 실험군의 파라미터를 중앙 집중적으로 관리하고, 추천 서비스에서는 해당 설정값을 실시간으로 조회하도록 구성함으로써 배포 없이도 ABT 실험을 빠르게 반복할 수 있는 환경을 만들었습니다.
특히 이 방식의 가장 큰 장점은 실험의 반복 주기를 획기적으로 단축할 수 있었다는 점입니다. Producer의 추가/삭제, 점수 가중치 변경, 필터링 임계값 조절과 같은 간단한 실험 등은 컨피그 값 업데이트만으로 수 분 이내에 즉시 반영할 수 있었습니다. 더 나아가, 실험 도중에도 값 변경이 실시간으로 반영되었기 때문에 앞서 언급한 실시간 지표 수집 환경과 결합하여 지표를 보면서 즉각 개선 방향을 적용하고 그 결과를 다시 관찰하는 짧은 피드백 루프(loop)를 만들 수 있었습니다.
이러한 서버 기반 컨피그 운영 체계는 실험 속도를 비약적으로 높였을 뿐 아니라, '실험 자체를 안전하게 수행할 수 있는 통제력'을 제공했습니다. 문제가 발생할 여지가 보이면 컨피그 롤백만으로 즉시 복구가 가능했기에, 새로운 시도를 두려움 없이 진행할 수 있었고, 결과적으로 더 많은 아이디어를 더 짧은 주기로 검증할 수 있는 문화가 자리 잡을 수 있었습니다.
명확한 RnR(Role and Responsibility) 설정
일반적인 상황에서는 다양한 역할이 섞여서 시도가 이루어지지만, 집중 개선 기간에는 개발자에게는 업무와 실험에 몰입할 수 있는 시간, 매니저와 PO에게는 의사결정할 수 있는 시간을 확보하는 것이 중요하다고 판단했습니다. 이 기간 동안은 더 많은 실험과 의사결정, 그리고 방향성 검토를 위해 각자의 책임을 다하는 것이 중요했기 때문입니다. 이를 위해 Daily Scrum을 세팅하여 PO와 Eng lead들이 모여 매일 진행된 실험에 대한 의사 결정을 진행했습니다. 이때 실험의 성격에 따라 짧으면 1~2일, 길면 3~14일 관찰 후 downside가 크지 않다는 확신이 들면 바로바로 winner를 선정했습니다.
빠른 의사결정과 다양한 실험을 위해 실험 결과가 비슷하다면 일단 런칭하고 다음 실험으로 넘어가는 방향으로 결정이 내려졌습니다. 남은 시간들은 다음 아이템에 대한 아이디어 도출 및 방향성 논의, 현재 상황에 대한 분석 및 공유, 그리고 조직 간 모호한 부분들에 대한 의사결정에 주로 할애되었습니다. 이러한 명확한 역할과 책임 분리는 더 빠르고 많은 시도를 할 수 있는 원동력이 되었습니다. 그 결과 개발자들은 각자의 실험과 업무 우선순위를 스스로 선택하여 실험에 몰입했고, PO와 Eng Lead들은 실험의 속도와 방향성을 유지하기 위해 빠른 의사결정과 방향성 제시, 그리고 충분한 멘탈 서포트를 위해 노력했습니다.
실패를 통한 성공
실패는 중요합니다. 실패를 통해 얻을 수 있는 것은 단순히 '틀렸다'는 사실을 넘어섭니다. 우리는 실패를 통해 틀린 방향임을 인지하게 되었고, 오히려 궁극적으로는 더 맞는 방향을 더 빠르게 탐색할 수 있었습니다. Tech Lead, Tech Lead & Manager, PO로 구성된 의사결정 그룹에서는 매일 Scrum을 진행하며 실패한 시도도 공유했고, 그 안에서 발견한 통찰을 팀의 자산으로 축적했습니다. 그동안 MLE들은 각자의 가설과 실험을 반복하여 검증하고 실행했으며, 이러한 반복 과정을 통해 ‘빠른 실험’이 단순한 실행 속도 문제가 아니라 학습 속도를 높이는 전략이라는 것을 실감하게 되었습니다. 결국 우리의 목표는 모델을 조금 더 정교하게 만드는 것을 넘어, 팀 전체가 더 빠르게 배우고 적응하도록 시스템을 설계하는 것이었습니다. 이 변화가 ‘Bolder Faster’의 핵심이었으며, 지금은 이것이 엔지니어링 문화의 한 축이 되었습니다.
이러한 노력으로 팀은 약 두 달 동안 학습 → 평가 → 배포 → 모니터링이 하나의 자동화 흐름으로 이어지는 워크플로를 구축했습니다. 그 결과, 하루 평균 1.2회의 신규 버전을 테스트 및 런칭할 수 있는 실험 속도를 확보했습니다. 특히 5월 15일부터 6월 13일까지 약 한 달 동안 총 100회가량의 실험을 진행했으며, 이 중 24회 가량의 런칭을 성공적으로 이끌어냈습니다. 이는 팀 내에서 진행하던 기존 실험 런칭 확률에 비해서는 성공률이 낮지만, 런칭 횟수는 압도적이었고 결과의 향상 속도는 훨씬 가팔랐습니다.
매일 진행된 Daily Scrum에서는 전일 실험 데이터를 검토하여 가장 우수한 모델을 ‘승자(winner)’로 선정하고, 이를 다음 실험의 베이스라인으로 삼는 사이클을 통해 원하는 수준으로 빠르게 성장시켰습니다. 이 과정은 단순 모델 개선을 넘어, ‘가설 → 실험 → 측정 → 학습’이 빠르게 반복되는 지속적 탐색(continuous exploration) 문화를 성공적으로 경험해 보았고, 문제 상황에 따라 유연하게 활용할 수 있다는 점에서 소중한 경험이었다고 생각합니다.
다음 블로그에서는 ML 모델링 측면에서의 도전과 개선(Producer 및 Ranker 개선)에 대한 내용이 이어집니다.
오늘의집 Discovery 팀은 검색/추천/광고 및 관련 기반 기술 전반에 대한 도전을 이어가고 있습니다.
함께하실 분들은 아래 링크에서 더 자세한 내용을 확인해주세요!
