딥러닝 추천 시스템: 후보 생성과 랭킹

왜 딥러닝으로 가나

행렬 분해 라이브러리만으로 실시간 개인화 피드를 만들면 세 가지가 막힌다.

• 학습 데이터가 늘면 메모리 사용량이 급격히 커지고 학습이 느려진다.
• 사용자를 ID 하나로만 표현해서 지역·시간 같은 다른 정보를 넣기 어렵다.
• 요청마다 빠르게 추천을 계산하는 구조가 고려돼 있지 않다.

이 문제를 푼 대표 설계가 유튜브의 「Deep Neural Networks for YouTube Recommendations」(2016)다. 이후 대부분의 대형 피드 추천이 같은 뼈대를 쓴다.

2단계 구조

아이템이 많으면 사용자 한 명에 대해 모든 아이템의 점수를 계산할 시간이 없다. 그래서 빠르고 거칠게 추린 뒤, 좁혀진 후보만 정밀하게 정렬한다.

flowchart TB
  all["전체 아이템 (수십만~수억)"]
  cand["후보 수백 개"]
  final["최종 추천 수십 개<br/>(+ 다양성·중복 제거·비즈니스 규칙)"]
  all -->|"1단계 후보 생성(candidate generation)<br/>사용자 벡터 · 아이템 벡터의 내적 → 유사 벡터 검색으로 수백 개"| cand
  cand -->|"2단계 랭킹(ranking)<br/>사용자·아이템·문맥 특성을 모두 이어 붙인 신경망 → 선호도 점수"| final

피드 추천의 다단계 파이프라인

소셜 피드처럼 후보 풀이 거대하고 응답 시간이 짧아야 하는 서비스는 2단계를 더 잘게 나눈다. 공개된 X(옛 Twitter)의 「For You」 타임라인 알고리즘이 대표 예다.

단계마다 계산 비용이 커지는 만큼 후보 수를 줄여서, 전체를 짧은 응답 시간 안에 끝낸다.

후보 모델 학습: 다음 아이템 맞히기

후보 모델은 사용자가 본 아이템 목록을 문장처럼 보고, 다음에 볼 아이템을 예측하는 언어 모델식으로 학습한다.

• 맥락은 모델을 나누지 말고 조건으로 넣는다. 지역별로 모델을 따로 두면 겹치는 범위와 여러 지역을 오가는 사용자를 다루지 못한다. 조건으로 넣으면 처음 가 본 지역에서도 각자 취향대로 추천을 받는다.
• 학습 데이터의 소비 패턴이 그대로 추천에 배어든다. 중고 거래처럼 최신 아이템 소비가 압도적인 서비스에서는 모델도 최신 아이템을 추천하는 경향을 띤다.
• 복잡한 시스템은 단계로 쪼개 빨리 내보낸다. 후보 모델만 먼저 붙여 배포하고 A/B 테스트로 개선한 뒤 랭킹 모델을 더한다.

서빙: 네트워크의 뒷부분을 벡터 검색으로 바꾼다

학습 때는 네거티브 샘플링 덕에 계산이 가볍지만, 예측 때는 사용자 벡터와 모든 아이템 벡터의 내적을 구해야 한다. 내적은 결국 가까운 벡터 찾기이므로 근사 최근접 이웃(ANN) 검색으로 바꿀 수 있다.

flowchart TB
  app["앱 서버"] --> rec["추천 서버"]
  rec --> s1["1. 캐시(Redis 등)에서 사용자의 최근 소비 이력 조회"]
  s1 --> s2["2. 모델 서버: 네트워크 앞부분만 실행해 사용자 벡터 생성"]
  s2 --> s3["3. ANN 검색 서버: 사용자 벡터와 가장 가까운 아이템 ID 수백 개"]
  s3 --> res["수십 밀리초 안, CPU만으로도 충분, 오토스케일링"]

ANN 인덱스(faiss 등)는 데이터가 많아지면 느려지고 메모리를 많이 쓰므로 배포 전에 인덱스를 학습(양자화·클러스터링)해 둔다. faiss 외에 ScaNN, HNSW 기반 라이브러리, 벡터 DB가 같은 역할을 한다.

학습·배포 파이프라인

새 아이템이 계속 들어오므로 주기적으로 다시 학습하고 배포해야 한다.

flowchart TB
  log["이벤트 로그"] --> mid["필요한 열만 모은 중간 테이블(비용 절감)"]
  mid --> pre["전처리(ID 사전, 희귀 ID 제거, 학습용 포맷)"]
  pre --> train["학습"] --> emb["아이템 임베딩 추출"]
  emb --> ann["ANN 인덱스 학습"]
  emb --> deploy["모델 파일 배포"]
  ann --> restart["서빙 재시작으로 새 모델 반영"]
  deploy --> restart

• 워크플로는 Kubeflow Pipelines, Airflow, Vertex AI Pipelines 같은 오케스트레이터로 자동화한다.
• 전처리를 모델 그래프 안에 넣으면 서빙 때 같은 전처리를 다시 짤 필요가 없다. 학습과 서빙의 전처리 불일치(training-serving skew)를 막는 방법이다.

아이템 시퀀스를 문장처럼: Item2Vec

word2vec은 문장 안에서 가까이 나오는 단어끼리 비슷한 벡터를 갖도록 학습한다. 이 「문장」과 「단어」 자리에 사용자 이력과 아이템을 넣으면 아이템 임베딩이 나온다. 이렇게 아이템을 벡터로 만드는 방법을 통틀어 Item2Vec이라 부른다.

from gensim.models import Word2Vec
 
sessions = [["item1", "item2", "item3"], ["item1", "item12", "item23"]]  # 사용자·세션별 아이템 ID 나열
model = Word2Vec(sessions, vector_size=100, window=10, min_count=3, sg=1, negative=5)
model.wv.most_similar("item1")   # 같이 소비되는 아이템

• 쓰임: 비슷한 아이템 추천, 아이템 벡터를 k-means로 묶은 세분류(예: 방송 13K개를 500개 군집으로 나누니 지상파 뉴스와 인터넷 뉴스가 갈리고 운세·그림 같은 틈새 분류가 드러났다), 다른 모델의 의미 특징.
• 장점: 레이블 없는 로그만으로 학습하고 코드가 짧다. 메모리 기반 최근접 이웃은 인기 아이템 쪽으로 쏠리는데, 임베딩은 내용상 가까운 아이템을 더 잘 찾는 경우가 있다.
• 한계: 벡터 공간을 해석하기 어렵고, 성능을 의도대로 올리려면 시행착오가 많다. 행렬 분해도 이미 잘 동작하므로 단독 대체재보다 앙상블의 한 구성 요소로 쓴다.

순서를 보는 모델: 세션 추천

협업 필터링은 과거 클릭을 근거로 하므로 방금 나온 뉴스를 추천하기 어렵고, 한 이슈를 깊게 파고드는 소비도 잘 못 잡는다. 그래서 순서를 보는 모델을 붙인다.

• 문서마다 벡터(Doc2Vec 등)를 만든다.
• 사용자가 읽은 순서대로 벡터를 이어 시퀀스를 만든다. 몇 분 안에 이어 읽은 문서는 같은 맥락(세션)으로 본다.
• 순환 신경망(RNN)이 다음에 읽을 문서를 예측한다. 같은 맥락의 새 문서가 들어오면 바로 추천할 수 있다.
• CF가 다양성을, 순서 모델이 깊이와 최신성을 맡는 하이브리드가 된다.

지금은 RNN 자리를 트랜스포머 기반 순차 추천(SASRec, BERT4Rec 계열)이 주로 차지한다. 「다음 아이템 예측」이라는 문제 설정은 같다.

여러 신호를 합치는 추천

지금의 흐름

후보 생성 → 랭킹 뼈대는 유지되고, 그 위에서 다음 방향으로 옮겨 간다.

추천 대상이 반경 몇 km 안으로 제한되는 지역 서비스는 후보 풀이 작아 정교한 개인화가 더 어렵다.

정리

• 아이템이 많으면 후보 생성(빠르게 수백 개) → 랭킹(정밀하게) 2단계로 나눈다.
• 후보 모델은 「최근 본 것으로 다음 것 맞히기」로 학습하고, 맥락은 조건으로 넣고, 서빙은 사용자 벡터 + ANN 검색으로 바꾼다.
• 추천은 한 번 만들고 끝나지 않는다. 수집 → 전처리 → 학습 → 인덱스 → 배포를 자동으로 반복하는 파이프라인이 본체다.
• 순서 모델은 최신 콘텐츠와 세션 맥락을, 크로스오버·멀티모달 신호는 콜드 스타트를 푼다.
• 복잡한 시스템은 후보 모델만 먼저 내보내고 A/B 테스트로 키운다.

관련 노트: 추천 시스템, 추천 시스템 기초, 실시간 추천과 실험, 딥러닝 직관으로 이해하기, LLM은 무엇을 하고 왜 작동하나