2025 Wrapped 하이라이트를 만든 기술

Spotify의 Wrapped Archive는 각 사용자에게 최대 5개의 “remarkable day”를 찾아, 실제 청취 기록만으로 LLM이 서술형 리포트를 만들도록 설계됐다. 대상은 2025년 청취 이력에서 뽑은 특별한 하루였고, 결과는 개인화된 스토리로 제공됐다.

특별한 날은 우선순위가 있는 휴리스틱으로 선정됐다. Biggest Music Listening Day, Biggest Podcast Listening Day, Biggest Discovery Day, Biggest Top Artist Day, Biggest Top Genre Day 같은 단순 지표부터, 오래된 곡 비중이 높았던 Most Nostalgic Day와 평소 취향에서 가장 벗어난 Most Unusual Listening Day까지 포함됐다. 여기에 Your Birthday, New Year’s Day 같은 맥락 앵커를 더해, 수억 건의 이벤트를 사용자당 최대 5개로 압축했다.

생성 단계에서는 프롬프트 엔지니어링이 핵심이었다. 시스템 프롬프트는 데이터 기반 서사, 위트 있고 절제된 톤, 그리고 약물·술·섹스·폭력·비속어를 피하는 안전 기준을 정의했다. 사용자 프롬프트에는 해당 일자의 청취 로그, 요약 통계, 전체 Wrapped 데이터, 카테고리, 이전에 생성된 리포트, 국가 정보까지 넣어 중복과 모호함을 줄였다.

성능과 비용 문제를 해결하기 위해 distillation과 DPO를 적용했다. 프론티어 모델로 고품질 예시를 만들고, 엄선된 gold dataset으로 작은 생산용 모델을 fine-tune했으며, A/B 테스트 기반 인간 선호 신호로 Direct Preference Optimization을 추가했다. 그 결과 더 작은 모델로도 원래 baseline에 가까운 선호 품질을 확보했다.

규모는 압도적이었다. 약 3.5억 eligible users에게 사용자당 최대 5개씩, 총 약 14억 개 reports를 미리 생성했다. 며칠 동안 초당 수천 요청을 처리해야 했고, 첫 배치에서 전량을 돌린 뒤 진행 상황은 실시간 대시보드로 추적했다. 생성은 4일 연속 멈추지 않았고, 완료 후에는 누락이나 불일치를 다시 확인해 재생성했다.

저장 구조도 동시성을 염두에 뒀다. 사용자별 row 안에 날짜를 YYYYMMDD 컬럼 qualifier로 두어, 같은 사용자에 대한 여러 보고서가 동시에 써져도 서로 다른 셀을 건드리게 만들었다. 보고서 본문을 먼저 쓰고, 그 다음 완료 메타데이터를 기록해 미완성 리포트가 노출되지 않도록 했다.

런칭은 전 세계 동시 오픈이어서 사전 준비가 필요했다. compute pod와 database node를 미리 증설하고, 지역별 synthetic load test를 돌려 connection pool, cache, tablet assignment, block cache를 데운 뒤 실트래픽을 받았다. 이 방식으로 런칭 순간의 냉시작을 피했다.

품질 검증은 자동화된 평가 프레임워크로 진행했다. 생성된 리포트는 평가용 warehouse에 적재하고, 더 큰 모델을 judge로 사용해 accuracy, safety, tone, formatting 네 축으로 채점했다. 전체를 다 보지 않고 약 165,000개 샘플을 평가했으며, 이유를 먼저 쓰게 하는 방식이 일관성을 높였다.

문제가 발견되면 구조적으로 복구했다. 모델 평가와 인간 검토, SQL과 regex 기반 탐지를 결합해 유사 실패를 대량으로 찾아냈고, 배치 삭제와 가드레일 업데이트로 재발을 막았다. 예를 들어 Biggest Discovery Day에서 타임존 버그로 잘못된 날짜가 선택된 경우가 있었지만, 메타데이터 추적으로 원인을 찾고 대량 재생성까지 이어갈 수 있었다.

핵심 교훈은 분명했다. 프롬프팅은 평가 없이는 스케일하지 않고, 동시성 문제는 종종 데이터 모델링으로 풀리며, 진짜 난제는 LLM 호출 자체가 아니라 capacity planning, replay/recovery, 비용 통제, 안전 루프, 그리고 단 한 번의 대형 런칭 순간을 버티는 시스템 설계였다.