패스트캠퍼스 환급챌린지 37일차 : 30개 프로젝트로 끝내는 추천시스템 구현 초격차 패키지 강의 후기

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

 

공부 시작

강의 종료

강의장

학습 인증샷

학습후기

 

utility score 기반 추천 시스템

 

유저에게 진짜로 유용한 것을 추천하는 방향

 

추천 시스템을 공부하다 보면 CTR, 즉 클릭률을 높이는 게 목표처럼 느껴진다

클릭만 잘 유도하면 되는 거 아닌가 싶지만, 실제로는 클릭이 유저에게 도움이 되는 행동인지는 별개의 문제다

클릭 이후의 행동이 중요하다는 걸 고려하지 않으면 결국 유저 만족도와 서비스 성과가 연결되지 않는다

이런 고민 끝에 등장한 개념이 바로 유틸리티 기반 추천이다

---

CTR 중심 추천 시스템의 한계

 

CTR은 로그 수집도 쉽고 학습 구조도 간단하다. 클릭 여부만 확인하면 되기 때문에 데이터 정제나 라벨링도 빠르게 끝난다

하지만 클릭이라는 행동은 순간적인 흥미일 뿐 유저가 콘텐츠를 끝까지 이용했다거나 실제 구매로 이어졌는지를 보장하지 않는다

서비스 측면에서는 CTR만 믿고 추천을 구성했다가 낚시성 콘텐츠로 채워지는 문제가 생기기도 한다

유입은 늘어도 이탈률이 높아지고, 장기적으로는 유저 신뢰를 잃는다

---

Utility Score는 유저가 실제로 서비스를 쓰며 남긴 ‘가치 있는 행동’을 점수화한 개념이다

어떤 행동이 더 가치 있는지는 서비스 도메인마다 다르다

쇼핑 서비스라면 클릭보다는 구매, 영상 플랫폼이라면 재생 시간이나 공유 여부가 더 큰 유틸리티가 된다

각 행동마다 점수를 부여하고 그 점수를 예측하는 방식으로 추천 모델을 학습하게 된다

 

왜 유틸리티 점수 기반으로 학습해야 하는가

 

유틸리티 기반 추천의 장점은 단순한 반응 예측이 아니라 ‘실제 행동’을 기반으로 추천 품질을 정의할 수 있다는 것이다

클릭률만 높이려다 보면 사용자의 의도와 맞지 않는 결과를 보여주기 쉽다

반면 유틸리티 기반 모델은 유저가 긍정적인 행동을 할 가능성이 높은 콘텐츠를 예측한다

예를 들어 유저가 실제로 끝까지 본 콘텐츠 반복 시청한 영상 구매로 이어진 상품 등을 더 많이 추천하게 된다

 

실무 적용 시 어려운 점

 

Utility Score는 단일 지표가 아니기 때문에 설계가 복잡하다

점수를 어떻게 구성할지 정해야 하고 행동별로 어떤 가중치를 줄지도 고민해야 한다

예를 들어 클릭은 1점  장바구니 담기는 3점 구매는 10점처럼 점수화를 해야 하지만

그 기준은 임의로 정하기 어려워서 도메인 팀과의 협업이 필요하다

로그 수집도 클릭만큼 단순하지 않다

시청 시간, 결제 여부, 페이지 체류 시간 등 다양한 정보를 저장하고 분석할 수 있어야 한다

---

예시로 본 Utility 기반 추천

 

쇼핑몰에서는 상품 클릭은 1점, 장바구니 추가는 3점, 실제 구매는 10점처럼 정의할 수 있다

콘텐츠 플랫폼에서는 영상 클릭 1점, 3분 이상 시청 5점, 끝까지 시청 10점, 좋아요나 공유 15점처럼 구성할 수 있다

이렇게 정의된 점수 데이터를 라벨로 삼아 유저가 앞으로 어떤 콘텐츠에 높은 점수를 줄지 예측하는 모델을 학습하게 된다

이 방식은 CTR 기반보다 학습 난이도는 높지만, 추천 품질 자체는 더 안정적이다

 

서비스 기획과의 연결

 

추천 시스템은 기술이지만 동시에 서비스의 방향성과 맞닿아 있다

단순 클릭 유도보다 중요한 건 사용자의 반복 방문, 장기 체류, 전환 같은 ‘서비스 기여도’다

예를 들어 여행 플랫폼이라면 클릭보다 예약, 장기 사용 앱이라면 체류 시간이나 후기 작성 여부가 더 중요할 수 있다

유틸리티 점수를 어떻게 정의하느냐에 따라 추천 전략 자체가 달라지기 때문에, 기획 초기 단계부터 이 개념이 들어가야 한다

 

개발자로서 실무 적용 고민

 

초기에는 CTR 기반 이진 분류 모델로 시작해도 된다. 유저 수나 로그가 많지 않을 때는 단순한 구조가 더 안정적이다

하지만 유저가 늘고 행동 로그가 다양해지면 유틸리티 점수를 예측하는 모델로 확장해야 한다

회귀 모델을 쓰거나 클래스 수를 늘린 다중 분류로 구조를 바꿀 수도 있고

후속 A/B 테스트를 통해 유저 행동 변화까지 추적해야 한다.

또한 로그 수집 단계에서 다양한 행동을 정제하는 데이터 엔지니어링도 병행해야 한다