brunch

You can make anything
by writing

C.S.Lewis

알고리즘은 개발자가 짜고, 추천기획자는 뭘 할까?

추천 기획자가 하는 일

[지난 글] '좋아할 가능성', 추천 알고리즘 
https://brunch.co.kr/@candigka/34


지난 글에서 추천 알고리즘에 관해 이야기했는데, 추천시스템은 특히 알고리즘의 역할이 강하다 보니 기획자는 어떤 역할을 하는지 궁금해하는 경우가 있다. 


그래서 오늘은 추천서비스를 기획하는 기획자는 무슨 일을 하는지 다뤄보고자 한다. (물론, 조직마다 역할의 범주는 다를 수 있지만.)


기획의 관점에서는 추천서비스를 위해 무엇에 집중해야 할까?




비슷한 모델을 사용해도 달라지는 추천


추천시스템은 일반적으로 CBF모델, CF모델 또는 두 모델은 섞은 모델을 활용하여 구축한다. 일반적이란 건, 큰 틀에서는 유사한 알고리즘으로 추천서비스를 제공하고 있다는 것이다.


그런데 왜 플랫폼마다 추천만족도에서 차이가 느껴지는 걸까?


물론, 기타 어느 서비스들과 마찬가지로 기획의도와 목적이 다르기 때문이겠지만 추천서비스는 특히 아래와 같은 차이점이 만족도에 영향을 줄 수 있다.


1. Where : 제공 영역의 차이

첫 번째로는 추천영역을 어떤 기획의도와 목적을 가지고 어디서 제공하느냐에 따라 사용자가 느끼는 만족도가 달라진다. 예를 들어, 한 음악스트리밍 앱에서는 음원 차트의 순위도 희망한다면 개인화된 순위로 변경하여 볼 수 있도록 서비스를 제공하고 있다. 대부분 '메인'페이지를 통해 특정 영역에서 추천을 제공하는 것과 달리, 기대하지 못했던 영역에서까지 개인화를 경험할 때 사용자들은 더 큰 만족감을 느낀다. 


2. What : 추천 풀(Pool)의 차이

두 번째로는  추천이 가능한 콘텐츠 풀의 차이가 있다. 서비스가 사용자에게 제공할 수 있는 콘텐츠의 수 그리고 추천을 제공할 만큼 데이터를 가지고 있는 콘텐츠의 수 자체가 적다면 적은 수의 콘텐츠를 다수의 사용자에게 제공하기 때문에 사용자의 취향 정보를 충분히 얻기 어렵다.


3. How : 필터링 로직의 차이

세 번째로는 추천을 제공할 때 어떤 기준으로 필터링을 하느냐에 따라 결과가 다를 수 있다. 예를 들면, 추천 영역에서 사용자가 이미 봤던 콘텐츠는 제거하는 서비스가 있고, 사용자가 봤던 콘텐츠는 제거하지 않고 구매까지 한 콘텐츠만 제거하는 서비스가 있을 것이다. 그렇다면 어떤 사용자에게는 이미 본 콘텐츠가 자신의 추천 영역에서 다시 노출되는 것에 불편함을 느낄 수 있다.



위와 같이 추천 만족도에 영향을 주는 대표적인 세 가지 차이점 모두 기획자의 역할이 필요하다. 어느 영역에서 어떤 기획의도로 추천서비스를 제공할지 정하고, 추천으로 제공할 콘텐츠의 범위를 설정하고, 어떤 콘텐츠들을 걸러내는 것이 사용자의 만족도를 높일지에 대해 기획자의 의사결정이 필요하기 때문이다.


이에 관하여 추천기획자는 큰 틀에서 아래와 같은 고민들을 하게 된다.


어떤 화분에 담을 것인가

기획자답게 추천콘텐츠를 제공할 그릇, 새로운 추천 영역의 기획의도와 목적을 고민한다. 이를 위해 현재 제공하고 있는 전체 추천영역에서 부족한 부분은 무엇인지, 새로 추가되면 좋을 추천은 무엇일지 고민해 보고 1) 어느 영역에서 2) 어떤 타이틀로 3) 어떤 스케줄에 따라 추천콘텐츠를 제공할 것인가에 대한 기본적인 설계를 시작한다.


어떤 씨앗(Seed)을 심을 것인가

추천콘텐츠를 담을 그릇이 정해지면 추천의 씨앗(Seed)으로 어떤 것을 심을지 결정하게 된다. 시드를 선정하는 작업은 수만 개의 콘텐츠들 중 사용자에게 추천할 콘텐츠를 선별할 때 무엇을 기준으로 추천 풀을 구성할지 결정하는 일이다. 


예를 들면, 넷플릭스에서 '당신이 좋아하는 장르'의 영화를 제공하는 추천 영역이라면 해당 영역의 시드는 바로 '장르'이다. 또 음원사이트에서 '당신이 좋아하는 아티스트'의 곡을 추천하는 영역이라면 해당 영역의 시드는 바로 '아티스트'이다. 


이러한 시드는 추천영역에서 제공하는 대표적인 콘셉트와 풀을 결정하는데 가장 중요한 요소이다. 


어디까지 가지를 칠 것인가

시드를 기준으로 사용자에게 추천할 수 있는 콘텐츠의 기본 풀이 정해졌다면 더 상세하게 어느 범위까지 추천에 활용할지 결정해야 한다. 


예를 들어, 장르를 기준으로 추천을 제공한다면 사용자에게 모든 장르를 제공할 것인지, 추천할 수 있는 콘텐츠의 수가 충분한 대표 장르들만 제공할 것인지, 사용자가 좋아하는 몇 가지 장르에 대해서만 제공할 것인지 등등 범위를 설정해주어야 한다.


추천 풀의 범위를 설정하는 과정에서 여러 방법을 고려해도 추천모델을 통해 충분한 결과를 제공할 수 없다면 다시 추천의 시드를 바꿔볼 수도 있다.


여기서 더 나아가 추천만족도를 위해 잔가지를 치는 작업들이 추가된다. 바로 필터링 로직을 설계하는 일이다. 최신 취향정보일수록 가산점을 주고 수개월이 경과됐다면 감점을 하는 등 추가적인 다듬기 작업이 필요하다. (필터링 로직을 설계하는 일은 아래의 '휴먼지능, 스코어링 로직' 파트와도 관련이 있다.)


계속되는 잡초 뽑기

추천영역을 제공한 후에는 사용자의 만족도와 관련된 데이터들을 살펴보며 추천이라는 열매가 잘 자랄 수 있도록 불필요한 정보들을 필터링하는 로직을 추가하고 만족도를 높이기 위한 A/B테스트들이 진행된다.


한편, 기획자는 상황에 따라 아래와 같이 알고리즘의 힘에서 벗어나 기획자의 노동을 더 많이 들여야 하는 추천 방식을 고려하기도 한다.


휴먼지능, 스코어링 로직


소위 '휴먼지능'을 기반으로도 추천 서비스를 제공할 수 있다. 대표적인 '휴먼지능'은 딥러닝을 활용하지 않고 정해진 계산법에 따라 점수를 반영해 추천하는 방식이다. 


간단한 예를 들어보자. 100곡을 청취한 사용자가 60곡은 발라드, 40곡은 댄스 음악을 들었다면 사용자에게 추천하고 싶은 음악 중 발라드와 댄스음악을 6:4 비율로 추천할 수 있다. 


또 기존의 추천 모델을 보완하는 방식으로 스코어링을 사용할 수도 있다. 예를 들어, 추천모델을 통해 산출된 추천 콘텐츠 풀 중 사용자의 최근 활동과 관련된 콘텐츠에는 별도의 스코어링 로직을 추가하여 우선 제공하는 것이다. 


100곡을 청취한 사용자가 60곡은 발라드, 40곡은 댄스 음악을 들었다. 곡 수로만 보면 발라드를 더 많이 청취했지만 최근에 더 많이 들은 곡은 댄스 음악이다. 그렇다면 최근 7일간 청취한 장르에 대해 가산점을 부여하여 댄스 음악이 더 높은 비율로 추천할 수 있다. 특정 아티스트를 '좋아요'한 경우, 해당 아티스트의 곡에 가산점을 더해 더 자주, 상위에 노출되도록 하거나 이미 청취한 곡의 점수는 감점하여 하단에 노출되거나 추천에서 제외되도록 할 수도 있다.


위와 같이 로직에 의한 스코어 계산을 활용하면 스코어 계산만으로 간단한 추천 콘텐츠를 제공할 수도 있고, 사용자가 더 만족할 수 있는 다양한 기준을 찾아 스코어를 더하거나 빼는 방식으로 기존 추천 모델도 보완할 수도 있다.


사용자의 콘텐츠 소비 활동을 비율(%)로 계산하여 추천 콘텐츠 제공에 활용

더 상단에 노출하고 싶은 콘텐츠 카테고리에 대해 가산점 부여

필터링하고 싶은 콘텐츠에 대해 감점 부여 등


운영자의 큐레이션을 활용한 추천


실제로는 대부분의 사용자가 같은 추천 콘텐츠를 보게 되는 경우도 있다. 바로 운영자에 의한 큐레이션 콘텐츠를 '추천콘텐츠'라고 생각하게 되는 경우이다.


추천은 일반적으로 '개인화'된 영역이라고 여긴다. 그러나 큐레이션 콘텐츠의 로직은 개인화와 관련이 없을 수 있다. 운영자가 생각하는 최신 유행 콘텐츠 또는 주목할만한 콘텐츠를 메인에 노출시키며 '추천'처럼 제공하는 경우이다. 최근에는 쇼핑몰과 같은 곳에서는 '추천순'이라는 정렬 방식을 활용하여 특정 콘텐츠들을 상위에 노출하기도 한다.




이와 같이 추천기획자는 알고리즘 외 영역에서 추천의 열매를 맺을 화분을 정하고 씨앗을 심고 가지를 치고 잡초를 뽑으며 사용자의 만족도를 높이기 위해 다양한 시도들을 한다. 


그러나 개발자와 많은 소통을 하고 다양한 방식을 통해 A/B 테스트를 진행하더라도 사용자의 만족도를 높이는데 아래와 같은 이유로 한계를 겪을 때도 있다. 


1. 결과 도출까지의 과정을 알 수 없을 때

딥러닝을 통해 제공되는 경우, 추천의 결과는 다차원에서 학습과 연산을 통해 산출되기 때문에 연산의 과정을 하나, 하나 직접 볼 수 없다. 그래서 만족도를 높이기 위한 의사결정 또는 로직의 수정이 필요할 때 어려움을 겪기도 한다.


2. 사용자마다 만족하는 추천의 기준이 다를 때

어떤 사용자는 새로운 콘텐츠를 발견했음에 만족하고, 어떤 사용자는 구매까지 이어질만한 콘텐츠가 아니기 때문에 만족하지 못할 수 있다. 어떤 사용자는 좋아하던 가수의 새로운 곡을 발견했을 때 만족하고, 어떤 사용자는 원래 좋아하던 가수가 추천되는 것을 식상해할 수 있다.


3. 추천 모델의 성능 개선이 사용자에게 와닿지 않을 때

오랜 기간 A/B 테스트를 진행하며 추천모델의 성능을 높였어도 사용자의 데이터는 주춤할 수 있다. 개발자와 기획자가 생각하는 성능의 개선이 사용자에게까지 와닿지 않는 경우다. 성능의 개선은 사용자가 직접 추천콘텐츠를 클릭하여 경험하고, 만족하는 경험이 쌓여 지속적인 데이터를 생성할 수 있어야 사용자에게 와닿기 때문이다.


이처럼 추천을 기획하는 일은 모델과 로직을 다듬고 다듬고 또 다듬어 사용자 한 명, 한 명 개인에게 와닿을 수 있도록 만들어야 하는 서비스이다. 그래서 결코 쉽지 않다. 그러나 그렇기 때문에 사용자 한 명, 한 명을 위한 일이고 한 명, 한 명이 느끼는 만족도가 기획자에게는 큰 즐거움으로 다가올 것이다. 

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari