26-W | 볼라

진행 프로세스

주제 1. "와이스"의 라이브 방송 환경에 적합한 추천 시스템 구성

“와이스(WYYYES)” 어플의 주요 과제인 신규 판매자-구매자 쌍 생성을 촉진하기 위해, “유저가 최근 관심 있었던 콘텐츠 정보” 를 빠르게 반영하여 실시간 추천 순위를 정렬하는 알고리즘을 설계한다.

주제 1-1. 유저의 최근 관심사를 반영한 시청 예측 모델 (GRU4Rec)

추천 대상인 라이브 방송이 단기간(1-2시간) 동안만 존재하는 특수한 환경, 상호작용 정보를 바탕으로 상품 id 자체에 임베딩을 부여하는 보편적인 CF 방법론을 사용할 수 없다고 판단.
따라서 방송이 가진 메타 데이터(셀러, 카테고리, 서브카테고리, 제목) 각각의 임베딩을 합친 것을 방송의 임베딩으로 삼는 방식을 채택. 즉, 방송이 가진 콘텐츠적 성격에 따라 임베딩을 부여받게 됨.
시퀀셜 모델인 GRU4Rec을 채택하여, 유저의 최근 관심사를 빠르게 반영하여 유저가 흥미있게 시청할 가능성이 높다고 판단되는 방송들을 상위에 추천.

주제 1-2. 온라인 A/B 테스트 및 사후 분석

기존 사측 알고리즘 vs GRU4Rec 이 적용되는 유저 군을 50:50으로 분리하여 A/B 테스트 진행
WYYES 어플의 각 지면별로 새로운 추천 시스템의 효과를 비교 분석 (알고리즘이 높은 순위로 추천해준 방송을 유저가 실제로 클릭했는지, 이후 방송에 장시간 체류했는지)
이 과정에서 유저들의 방송 진입 경로에 관한 로그를 새롭게 적재하였으며, 사후 분석을 통해 유저들이 주로 어떤 지면을 많이 사용하는지 파악.

주제 2. 어플의 주요 지면에 최적화된 추천 알고리즘 설계

지난 진입 경로 로그 분석 결과, Feed 지면을 통해 방송에 진입하는 유저들의 비율이 예상했던 것보다 훨씬 높은 것으로 확인되었다. 따라서 Feed 지면, 그 중에서도 유저들의 이용이 가장 많은 “C” 카테고리 탭에 특화된 추천 알고리즘 설계를 기획한다. “C” 카테고리의 방송끼리만 경쟁하는 환경이므로, 모델의 목표는 유저의 특정 캐릭터(IP) 선호를 파악하여 추천에 반영한다.

주제 2-1. 상품의 IP 정보를 확보하기 위한 subcategory 라벨링 (LLM Prompting)

좀 더 정확한 유저의 IP선호 정보를 얻기 위해 유저들의 상품 구매 기록을 이용하기로 결정했지만, 판매된 상품 정보에는 subcategory가 별도로 기록되어 있지 않은 상황.
이를 타파하기 위해 LLM 프롬프팅을 통해 판매된 상품의 이미지를 보고 어떤 IP의 상품인지 라벨링하는 작업을 진행함. (Pydantic을 활용한 Structured Output 기반의 프롬프트 설계)

주제 2-2. 시청/입찰 확률 예측 모델 (2-track DIN)

상품 구매 기록을 이용할 수 있는 만큼, 이번에는 시청에 더해 “입찰” 자체를 직접적으로 예측하고자 함.
고객의 시청 시퀀스/ 구매 상품 시퀀스를 함께 고려하여 현재 라이브 방송 각각에 대해 “시청 확률/ 입찰 시도 확률”을 내뱉는 모델 구조.
“유저가 방송을 시청할 확률 A” 과 “유저가 방송을 시청한다면(조건부), 입찰 시도까지 할 확률 B” 을 각각 계산 - > 입찰 확률 = A*B

PM 소회

볼라와 프로젝트를 진행하며 좋았던 점은 무엇인가요?

볼라 프로젝트에서 가장 만족스러웠던 지점은 사측과의 원활한 소통과 방향성 일치였습니다. DS 프로젝트에서는 우리가 생각하는 타당하고 우수한 모델과, 사측의 니즈 사이의 간극을 좁히는 것이 중요합니다. 저희는 성과 지표를 1~2% 더 올리는 것보다, 현재 보유한 데이터로 영양가 있는 개인화 추천 시스템을 구현할 수 있는지 판단하는 데 초점을 두자는 의견을 전달드렸고, 사측 또한 과정에 대한 합의가 있다면 결과 수치에 연연하지 않겠다며 저희의 제안에 힘을 실어주셨습니다.
양측 모두 소통에 적극적으로 임했고, 특히 사측이 저희에게 많은 시간을 할애해주시는 걸 보며 우리가 하는 일이 이 회사에 꼭 필요한 일이라는 확신이 생겼습니다. 이러한 신뢰 관계와 긴밀한 드백 덕분에 프로젝트 기간 내에 A/B 테스트를 2회 완수하는 흔치 않은 성과를 이룰 수 있었던 것 같습니다.

프로젝트 진행 중 겪었던 가장 큰 어려움은 무엇이었나요? 이를 어떻게 해결했나요?

라이브 방송은 콘텐츠의 수명이 매우 짧아, 기존의 아이템 ID 기반 임베딩 방식을 쓰기 어려웠습니다. 이 한계를 극복하고자 방송 제목과 카테고리 등 메타 정보의 합을 임베딩으로 간주하는 방식을 도입했습니다. 하지만 기존 데이터는 카테고리 구분이 너무 광범위하여 추천의 정교함을 살리기 위한 해상도가 부족했습니다. 특히 상품의 핵심인 IP 정보가 누락되어 있어 모델 학습에 필요한 특징을 잡기 힘들었습니다. 이를 타개하기 위해 LLM 프롬프팅을 활용해 상품 이미지로부터 직접 IP 정보를 추출하고 라벨링하였고, 결국 필요한 데이터를 능동적으로 추가 확보하는 데 성공하였습니다.

이번 경험을 통해 어떤 인사이트나 역량을 얻으셨나요?

학교에서는 보통 구조가 잘 잡힌 예쁜 데이터를 가정하고, 이상적인 상황에서의 알고리즘 작동 원리를 배웁니다. 그간 제 관심사 또한 머신러닝 방법론의 이론적인 성능 한계를 다루는 것에 치우쳐 있었습니다. 하지만 실제 현업의 문제를 마주하며, 알고리즘의 설계만큼이나 데이터의 적재 상태와 구조, 그리고 추가 확보 가능 여부가 프로젝트 성패에 결정적인 영향을 미친다는 것을 실감했습니다.
이번 프로젝트를 통해 도메인 특성에 맞춰 활용 가치가 높은 데이터를 선별하고 구조화하는 '날카로운 눈'의 중요성을 깨달았고, 이론 공부와 현업에서의 경험은 굉장히 다른 영역이라는 것을 깊이 통감하게 되었습니다. 또한 개인적으로는 이상적인 상황에서의 한계 성능보다 데이터가 제한된 환경에서도 유의미한 결과를 낼 수 있는 robust 한 모델 설계에 더 큰 관심을 갖게 되었습니다.

향후 유사한 프로젝트를 진행할 학회원들에게 전하고 싶은 조언이 있나요?

기업과의 소통만큼이나 중요한 것은 팀 내부에서 지식의 격차를 줄이고 보폭을 맞추는 일입니다. DS 프로젝트에서는 특히 모델링을 맡은 인원에게 책임이 과중하게 쏠리게 되기 쉽습니다. 이때 진행 상황에 대한 공유와 소통이 잘 이루어지지 못하면, 다른 팀원들은 페이스를 놓쳐 버리고 해당 인원들은 외딴섬처럼 혼자 달리게 됩니다. 아무리 뛰어난 사람이라도 얼마든지 실수를 할 수 있기에, 옆에서 실수를 바로잡아 줄 사람이 아무도 없는 것은 프로젝트에서 가장 위험한 상황입니다.
자신이 빠르다면 동료를 이끌어 페이스를 높여주고, 느리다면 악착같이 따라붙어 고립을 막아야 합니다. 혼자 달리는 건 어디서든 할 수 있지만, 서로의 속도를 맞추며 끝까지 완주하는 경험이야말로 그로스해커스 프로젝트에서 얻을 수 있는 가장 값진 자산이라는 걸 꼭 기억했으면 합니다.