개발·ML 경험 없이 시작한 쇼츠 추천 개선기

이번에 랭플릭스의 쇼츠 추천 개선 프로젝트에 참여했습니다. 이전에는 SQL과 Python으로 데이터를 분석하는 작업을 해왔는데요. 개발이나 머신러닝, 딥러닝을 다뤄본 경험은 거의 없었습니다. 추천의 목표를 정하기 위한 분석부터 파이프라인 작업과 A/B 테스트 설계까지 맡다 보니, 익숙하지 않은 내용을 배우고 적용할 일이 많았죠.

이 글에서는 그 과정에서 제가 맡았던 작업을 돌아보려고 합니다. 쇼츠 추천으로 무엇을 개선할지 고민했던 이야기부터, 필요한 지식을 익히며 작업한 과정, 실험 결과와 아쉬웠던 점까지 정리해보겠습니다.

추천을 개선하기 전에 정해야 했던 것​

프로젝트를 시작하며 가장 먼저 궁금했던 것은 추천 개선이 왜 중요한가였습니다. 추천을 바꿔서 영상을 더 많이 보게 하면 되는 걸까요? 앱 전체에서 쇼츠가 어떤 역할을 하는지 알아야 추천의 목적도 정할 수 있다고 생각했습니다.

처음에 제가 본 쇼츠 탭은 사용자가 랭플릭스의 콘텐츠와 기능을 빠르게 접할 수 있는 공간이었습니다. 롱폼보다 가볍게 접근할 수 있고, 영상을 보면서 표현 저장이나 쉐도잉, 리스닝 같은 학습 기능도 바로 사용할 수 있었거든요.

분석하면서도 이 생각 자체는 크게 바뀌지 않았습니다. 당시 쇼츠는 그 정도의 역할을 하고 있다고 봤어요. 다만 쇼츠를 활용해 서비스의 가치를 더 빨리 경험하게 하려면 어떻게 해야 할지 생각하면서 초점이 조금 달라졌습니다.

학습 기능은 이미 화면 안에 있었습니다. 그렇다면 사용자가 관심을 느낄 만한 영상을 보여줬을 때, 시청하다가 표현을 저장하거나 직접 따라 말해보는 행동도 더 많이 일어날 수 있지 않을까요?

그래서 앱 전체에서 리텐션과 관련된 행동을 찾아봤습니다. 분석에서 주목한 것은 복습, 북마크, 표현 저장, 쉐도잉, 리스닝이었는데요. 이런 행동을 추천의 목표로 삼으면서 무엇을 개선할지 구체적으로 이야기할 수 있게 됐습니다.

여기에는 분석과 판단이 함께 들어갔습니다. 분석으로 학습 행동과 리텐션의 관계를 살펴봤고, 그 결과를 바탕으로 쇼츠에서 학습 행동을 늘려보자는 방향을 선택한 거죠. 추천을 바꾸면 실제로 행동이 늘어날지는 이후 실험으로 확인할 문제였습니다.

추천으로 어디까지 해결할 수 있을까​

직접 앱을 사용해보면 비슷한 영상이 계속 나왔습니다. 다른 팀원들의 계정에서도 마찬가지였어요. 당시 추천은 인기도와 플랫폼에 새로 등록된 순서를 중심으로 구성돼 있었고, 영상 풀도 풍부하지 않았습니다.

솔직히 공급 문제가 더 시급하다고 생각했습니다. 사용자에게 맞는 영상을 고르려면 고를 수 있는 영상부터 있어야 하니까요. 콘텐츠만으로 학습 행동을 얼마나 유도할 수 있을지에 대해서도 의문이 있었고요.

그렇다고 기존 추천을 그대로 둘 이유는 없었습니다. 사용자마다 다를 수 있는 관심사와 반응을 추천에 반영할 여지는 있었거든요. 공급을 늘리는 일과 현재 콘텐츠를 어떻게 보여줄지 개선하는 일을 함께 진행할 수 있다고 봤습니다.

사측 개발자분이 콘텐츠 공급 자동화 파이프라인을 구축해주신 덕분에, 저희는 추천 개선을 병렬로 진행할 수 있었습니다. 저 역시 영상 풀에서 콘텐츠를 가져오는 파이프라인 작업에 참여했고요.

추천 방식은 사용자 이력이 부족한 경우와 충분한 경우를 나눠 검토했습니다. 이력이 없는 사용자에게는 무엇을 근거로 추천할지, 이력이 있는 사용자에게는 어떤 행동을 반영할지 정해야 했는데요. 팀에서는 콘텐츠 유사도와 인기도, MF와 Two-Tower 등을 검토했습니다.

저는 이런 논의에서 지금 풀려는 문제가 무엇인지 놓치지 않으려고 했습니다. 기술적인 내용이 깊어지면 다시 전체 방향을 짚고, 논의 중인 방법이 우리가 정한 목표와 어떻게 연결되는지 확인하고자 했죠.

제가 맡은 난이도 피처 엔지니어링도 사용자 반응을 이해하기 위한 작업이었습니다. 자막의 어휘 수준과 사용 빈도 등을 계산하고, 그 값이 시청이나 표현 클릭, 저장 같은 행동과 어떤 관계가 있는지 살펴보려 했어요.

이 작업에서는 난이도를 계산하는 기준부터 검토해야 했습니다. 사용하는 어휘 자료에 따라 같은 자막에서도 다른 값이 나올 수 있었고, 자료에 없는 단어를 처리하는 방법도 정해야 했거든요. 계산된 값이 의미하는 바가 명확해야 이후 행동 데이터와 비교할 수 있었습니다.

행동을 해석할 때도 주의할 점이 있었습니다. 예를 들어 표현을 클릭할 기회가 많은 영상은 클릭 수도 많을 수 있죠. 그런 차이를 고려하지 않으면 클릭이 많은 이유를 난이도로 잘못 설명할 수 있습니다. 피처를 만드는 일과 그 피처가 유용한지 확인하는 일을 함께 고민하게 된 이유입니다.

개발과 ML을 모르는 상태에서 작업하기​

추천 시스템을 처음 접하다 보니 모르는 내용의 범위가 넓었습니다. 개별 모델의 개념뿐 아니라 모델끼리 어떻게 상호작용하는지, 여러 결과를 어떻게 조합하는지도 알아야 했어요. Git으로 협업하는 방식과 데이터베이스 활용도 익숙하지 않았고요.

저는 AI가 이런 지식을 익히는 속도를 크게 높여줄 수 있다고 생각했습니다. 이해되지 않는 내용은 계속 물었고, 팀원들에게도 질문했죠. 모델과 앙상블에 관해 묻다가 실제 작업에서는 Git 사용법을 묻는 식이었습니다.

모든 내용을 공부한 뒤 작업을 시작하기는 어려웠습니다. 맡은 일을 진행하면서 필요한 개념을 익히고 다시 작업으로 돌아왔어요. 데이터 분석 경험이 있어도 개발과 모델에 관한 논의를 바로 이해할 수 있는 것은 아니었거든요.

제 역할도 하나로 정리하기는 어려웠습니다. 전체 방향을 함께 고민하면서 콘텐츠를 가져오는 파이프라인, 난이도 피처, A/B 테스트용 파이프라인 설계를 맡았는데요. 각각 필요한 지식이 달라 작업할 때마다 새로 배워야 하는 내용이 생겼습니다.

그래도 모르는 내용을 질문하고 이해할 수 있는 수단이 있다는 점이 도움이 됐습니다. 특히 AI는 같은 개념을 여러 번 묻거나 다른 설명을 요청하는 데 부담이 적었어요. 팀원들과 논의하며 이해를 보충하는 과정도 필요했고요.

무엇을 확인해야 개선됐다고 말할 수 있을까​

학습 행동을 늘리자는 목표를 정한 뒤에도 실험을 위해 결정할 것이 많았습니다. 무엇을 한 번의 노출로 볼지, 학습 행동을 어느 영상에 연결할지에 따라 지표가 달라졌기 때문입니다.

초기에는 같은 세션에서 시청과 학습 행동이 발생했는지를 보는 정의를 사용했습니다. 이후에는 영상이 노출된 단위로 시청과 학습 행동을 연결하는 방향으로 수정했는데요.

한 세션에서는 여러 영상을 볼 수 있습니다. 세션 안에서 학습 행동이 발생했다는 것만으로는 어느 영상을 보고 한 행동인지 구분하기 어렵죠. 개별 영상 노출을 기준으로 평가하려면 이를 연결할 수 있는 정보가 필요했습니다.

그래서 노출마다 구분할 수 있는 impression_id를 사용했습니다. 같은 영상을 여러 번 봐도 각각의 노출을 구분하고, 시청과 학습 행동을 해당 노출에 연결하기 위한 값입니다.

추천 요청과 실제 노출도 구분해야 했습니다. 앱이 다음 영상을 미리 가져왔어도 사용자가 그 영상까지 보지 않을 수 있거든요. 추천 API가 응답한 것을 모두 노출로 세면 학습 행동률의 분모가 실제보다 커집니다. 실제 화면에 노출된 영상을 기준으로 집계하도록 설계한 이유죠.

처리군에 배정됐다고 항상 새로운 추천이 제공되는 것도 아니었습니다. 모델이나 데이터 문제로 기존 추천이 대신 제공될 수 있었어요. 따라서 배정된 정책과 실제 실행된 정책을 따로 기록하고, 실험에서는 배정된 집단을 기준으로 비교하도록 설계했습니다.

배포 후에는 이 정보가 실제로 들어오는지 확인해야 했습니다. 노출에는 ID가 있지만 행동에는 없으면 두 이벤트를 연결할 수 없고, 같은 행동이 중복으로 기록되면 행동 수가 부풀려지니까요. 초기에는 이런 문제 때문에 결과를 탐색적으로만 살펴본 시기도 있었습니다.

A/B 테스트용 파이프라인을 설계하면서 지표의 정의가 구현 세부사항과 얼마나 밀접한지 알게 됐습니다. 같은 ‘학습 행동률’이라는 이름을 사용해도 노출과 행동을 기록하고 연결하는 방식이 다르면 다른 값을 보게 되는 거죠.

8월 마지막 주 배포 이후 진행한 A/B 테스트에서는 처리군의 학습 행동률이 대조군보다 약 4–5%p 높게 나타났습니다. 처음 목표로 정했던 행동에서 두 집단의 차이를 확인할 수 있었습니다.

다시 한다면 먼저 정리할 것​

가장 아쉬운 부분은 초기 EDA입니다. 처음에는 방향을 빠르게 정한 뒤 분석을 나눠 병렬로 진행하고 싶었어요. 하지만 팀원 모두 추천 시스템이 처음이다 보니 무엇을 확인해야 하는지 배우는 데에도 시간이 들었습니다.

지금 돌아보면 분석할 질문과 그 결과로 결정할 내용을 더 일찍 정리할 수 있지 않았을까 싶습니다. 어떤 분석이 추천 방식의 선택에 필요한지, 어떤 분석은 나중에 진행해도 되는지 먼저 나눴다면 역할을 분담하기도 더 수월했을 것 같아요.

다음에는 분석을 시작하기 전에 각자 확인할 질문과 결과를 모아 논의할 시점을 정해보고 싶습니다. 이번에 원했던 병렬 작업을 더 잘하려면, 처음에 그 정도의 합의는 필요했을 것 같습니다.