Spotify가 2025 Wrapped를 위해 3억 5천만 사용자에게 14억 개의 개인화 AI 보고서를 사전 생성한 시스템을 다룬다. 핵심 교훈은 이 규모에서 진짜 어려운 부분은 모델 호출이 아니라 용량 계획, 복구 전략, 안전 루프, 고장 격리라는 것이다.
핵심 포인트- 사용자당 최대 5개씩 약 14억 개 보고서를 전 세계 동시 출시 직전에 완성해야 했고 0.1% 실패도 수백만 건의 손상 콘텐츠가 된다.
- 프론티어 모델로 14억 건을 돌리면 경제성이 무너져, 프론티어 출력으로 만든 금색 데이터셋과 DPO로 소형 모델을 증류해 품질을 지키며 비용을 낮췄다.
- 동시 쓰기 경합을 아키텍처로 없앴다. 행 키는 사용자 ID, 컬럼은 날짜별 셀이라 서로 다른 날짜 쓰기는 락 없이 독립적으로 처리된다.
- 리액티브 오토스케일이 동시 출시 스파이크를 못 따라가, 출시 몇 시간 전 사전 스케일링과 전 지역 합성 부하 테스트로 커넥션 풀·캐시·DB 노드를 미리 데웠다.
- 14억 건을 다 검토할 수 없어 약 16만 5천 개를 LLM-as-judge로 정확성·안전·톤·포맷 4차원 평가했다.
상세 정리- 특별한 날 감지: 우선순위 정렬 휴리스틱으로 최대 청취 분 같은 단순형과 노스탤지어 급증, 평소 취향 이탈, 생일이나 새해 같은 날짜 앵커 같은 복잡형을 뽑았다.
- 파이프라인: 분산 처리로 사용자별 후보일을 계산해 객체 스토리지에 저장하고 메시지 큐로 비동기 발행했다.
- 프롬프트 2계층: 시스템 프롬프트는 모든 통찰이 실제 청취 행동으로 추적 가능해야 한다는 창의 계약과 위트 있고 성실한 톤, 안전 정책을 담았다.
- 사용자 프롬프트: 상세 청취 로그에 더해 통계 블록을 따로 넣어 LLM의 계산 오류를 막고 이전 생성 보고서와 사용자 국가를 함께 제공했다.
- 프롬프트 교훈: 3개월 반복 끝에 지시를 많이 쌓을수록 창의성이 떨어진다는 less is more를 확인했다.
- 모델 증류: 프론티어 모델의 고품질 출력으로 엄격히 검증한 금색 데이터셋을 만들고 소형 프로덕션 모델을 파인튜닝한 뒤 인간 A/B 평가 기반 DPO를 더했다.
- 증류 결과: 선호 데이터셋은 작지만 정교해 프론티어 모델과 강한 선호 패리티를 달성했다.
- 실행 규모: 초당 수천 건 요청을 4일 연속 중단 없이 처리하며 실시간 대시보드로 진행률·안정성·완료 예측을 모니터링했다.
- 병렬 안전 모델: column-oriented key-value DB에서 행 키를 사용자 ID로, 컬럼 한정자를 20250315 같은 날짜로 두어 날짜별 셀이 겹치지 않게 했다.
- 쓰기 순서: 보고서 본문을 먼저 저장하고 완료 마킹용 경량 메타데이터를 나중에 써 미완성 보고서가 노출되지 않게 했다.
- 사전 스케일링: 출시 몇 시간 전에 컴퓨트와 모델 공급자 용량을 올리고 전 지역 합성 부하 테스트로 커넥션 풀·캐시·DB 노드 캐시를 워밍했다.
- 자동 평가: 하나의 거대 프롬프트 대신 여러 소형 규칙 기반 쿼리로 비결정성을 줄이고 judge가 점수 전에 추론을 먼저 내도록 해 일관성을 높였다.
- 구조적 치료: Biggest Discovery Day가 잘못된 아티스트 수를 축하한 사례를 발견해 SQL과 정규식으로 유사 실패를 코퍼스 전체에서 표면화했다.
- 근본 원인: 업스트림 파이프라인의 타임존 버그로 모델이 잘못된 데이터를 받은 것이라, 영향받은 보고서를 일괄 삭제하고 파이프라인 수정과 가드레일 업데이트 후 재생성했다.
왜 읽나대규모 생성형 AI 배치 시스템을 운영하는 엔지니어에게 증류, 동시성 데이터 모델링, 사전 용량 계획, 자동 품질 평가를 아우르는 실전 아키텍처를 준다.
Spotify Engineering·
인프런 (인프랩)·
네이버 D2·
Vercel Blog·