컨텐츠 큐레이션 기능 리팩토링_(1)Planning

리팩토링 계획

01. Spring Batch+Redis의 조합

지난 포스팅에서 언급한 것처럼 프로젝트가 마무리 되니 체리픽 서비스에서 구현했던 컬렉션 큐레이션 기능을 단순 조회 로직 이상으로 구현하고 싶다는 생각이 들었다. 거기다가 다른 팀들이 구현한 내용을 보니 Spring Batch를 통해 통계 결과를 스케쥴링하는 사례가 꽤 많아서 예전 프로젝트에서 얼레벌레 적용했던 Redis를 함께 사용해서 리팩토링을 해보려고 한다.

 

02-01. 추천 알고리즘

또 성능 이슈와 관련된 리팩토링 외에도 팔로잉/팔로워 기능을 추가 구현하여 User-based CF 추천 알고리즘을 적용해볼 생각인데

정말 다행히도 Apache에서 제공하는 Mahout 이라는 추천 시스템 오픈소스가 있어 알고리즘을 직접 구현하지 않고..커스터마이징 해서 적용할 수 있을 것 같다.

사실 추천 알고리즘에는 대표적으로 CB(Content Based)와 CF(Collaborative Filtering) 두 가지 성격의 알고리즘이 있는데 이 둘의 차이는 이렇다.

 

02-02. 추천 알고리즘 종류

• CB(Content Based)
  • 사용자 혹은 아이템에 대한 프로필 데이터를 가지고 내가 좋아했던 아이템과 비슷한 유형의 아이템을 추천하거나 나와 비슷한 유형의 사람이 좋아하는 아이템을 추천
  • 사용자의 프로필(성별,나이,지역 등)을 미리 받아 이와 비슷한 사용자가 선호하는 상품을 추천해주는 방식
  • 단점 : 아이템의 데이터 일일히 작성해야함, 데이터가 주관적인 데이터면 객관성이 떨어짐(맛)
• CF(Collaborative Filtering)
  • 내가 남긴 평점 데이터를 가지고 나와 취향이 비슷한 사람이 선호하는 아이템을 추천
  • 프로필 데이터 없이 사용자의 활동 내역을 통해 추천을 제공 → 같은 컨텐츠에 비슷한 평점을 매긴 유저가 좋아하는 아이템을 추천
  • 단점 : 신규 사용자이거나 초기 데이터가 없으면 추천 정확도가 급격히 떨어짐, 어려움

 

02-03. User-based CF를 적용하는 이유

그럼 우선 이 두가지 방식 중 CF방식을 적용하려고 하는 이유에 대해 얘기해보자면,
일단 기존의 단순 추천 로직의 경우 유저가 선호하는 장르 타입을 기준으로 동일한 장르 타입을 가진 책 > 해당 책을 가진 컬렉션을 조회하는 방식인데

1. 체리픽 서비스가 가진 데이터의 종류가 다양하지 않기 때문에 CB 알고리즘을 적용하게 되면 기존의 로직과 크게 별다를 점이 없다는게 첫번째 이유이고
2. 그 다음으로 팔로잉/팔로워 기능을 중심으로 알림,채팅 등의 관련 기능을 함께 구현하여 mvp 서비스를 고도화 해보려는 내 속셈으로 팔로워/팔로잉 기능이 필수적으로 구현될 것이기 때문에 이를 활용한 알고리즘을 구현하는 것이 좋겠다는 것이 두번째 이유이다.

 

02-04. 추천 알고리즘 적용을 위한 작업 리스트

• 데이터 모델 만들기 (DataModel Class)
• 유저 데이터 기준으로 데이터 간 유사도 계산 (Similarity Class)
• 유사도 기준으로 데이터 분류
• 분류된 데이터 기준으로 추천 모델 작성 (Recommender Class)
• 유저가 추천받을 모델 관련 설정

 

이 포스팅 내용대로 구현이 완료될 날짜가 언제가 될지는 아직 잘 모르겠다. 아마도 새로 시작할 플젝이 무사히 마무리 된 이후가 아닐지...

그래서 미리 고민했던 계획을 기록해둔다. 그럼 to be continued.........!

 

 

---

 

참고)

https://pitzcarraldo.medium.com/apache-mahout-%EB%A7%9B%EB%B3%B4%EA%B8%B0-26316a5ba0a4

Apache Mahout 맛보기

https://jujeol-jujeol.github.io/2021/08/12/%ED%98%91%EC%97%85-%ED%95%84%ED%84%B0%EB%A7%81/#%ED%98%91%EC%97%85-%ED%95%84%ED%84%B0%EB%A7%81-%EC%A0%81%EC%9A%A9%EA%B8%B0

협업 필터링