도메인 전문가 인코딩: Spotify 데이터 어시스턴트 뒤의 컨텍스트 레이어
Spotify에서는 데이터 문제들이 특정한 패턴을 따랐습니다. 관련 대시보드를 찾으려 하면 없었고, 해당 데이터 전문가에게 Slack으로 메시지를 보내면 그들이 시간이 날 때까지 기다려야 했습니다. 하지만 수천 개의 팀이 빠르게 움직이면서, 데이터 인사이트에 대한 수요는 어느 개인 전문가가 혼자 감당할 수 있는 수준을 조용히 넘어섰습니다.
이 문제를 해결하기 위해 AI 데이터 어시스턴트를 개발하기 시작했지만, Spotify에는 70,000개가 넘는 데이터셋과 페타바이트 규모의 데이터가 존재합니다. 모든 스키마를 LLM에 넣는다고 해도 이 규모에서는 효과가 없습니다.
**그림 1:** Spotify 데이터 플랫폼은 매일 1조 4천억 개의 데이터 포인트를 70,000개 이상의 데이터셋에서 처리합니다.
첫째, 컨텍스트 윈도우는 제한적이며, 비록 백만 토큰이라 하더라도 전체 데이터 웨어하우스를 담기에 부족합니다. 둘째, 스키마만으로는 모든 정보를 전달할 수 없습니다. 예를 들어 컬럼 타입이 INT64라고 해도, 100 미만의 값이 레거시 테스트 데이터이며 실제 데이터와 정의가 어떻게 다른지, “활성 사용자”가 무엇을 의미하는지는 알 수 없습니다. 같은 수의 테이블을 모델에 제공하면 모델은 잘못된 테이블을 자신 있게 선택하게 됩니다.
우리는 그 사이에 위치하는 무언가가 필요했습니다. 데이터 웨어하우스의 일부분에 대해 실제로 중요한 정보를 포착하고, 해당 도메인을 소유하고 이해하는 사람들이 관리하는 레이어가 필요했습니다.
**그림 2.** 우리 데이터 에이전트가 작동하는 모습.
우리 데이터 에이전트
Spotify의 데이터 어시스턴트는 이 문제를 해결하기 위해 구축되었습니다. 간단한 영어로 질문하면 몇 초 안에 신뢰할 수 있는 데이터를 얻을 수 있습니다. 2025년 8월부터 2,100명 이상의 스포티파이어가 13,000개 이상의 대화와 60,000개 이상의 메시지(광고, 팟캐스트, 음악, 오디오북, 금융, 크리에이터 도구 등 177개의 클러스터를 포함)에서 활발히 사용하고 있습니다. 이 사용자 중 4분의 1 이상은 SQL을 한 번도 작성해 본 적이 없습니다.
질문이 들어오면 에이전트는 적절한 컨텍스트를 선택하고, SQL 쿼리를 작성한 뒤 웨어하우스에 실행하여 답변과 함께 쿼리 및 출처를 반환합니다. 에이전트는 ReAct[1] 루프를 따라 단계별로 추론하고 행동하며, 각 도구 호출 결과에 따라 조정합니다. 결과가 어떻게 도출됐는지, 단순히 결과만이 아니라 과정을 모두 확인할 수 있습니다.
우리는 이미 사람들이 사용하고 있는 인터페이스에 통합했습니다. 스레드 채팅 중 빠른 질문을 위한 Slack 봇, IDE와 AI 도구를 위한 MCP 서버, 그리고 인터랙티브 탐색을 위한 전용 웹 UI가 그것입니다. 지식 베이스에 해당 주제가 없을 경우 데이터 에이전트는 이를 알려줍니다. 이러한 투명성이 답변을 신뢰할 수 있게 만드는 핵심 요소입니다.
하지만 흥미로운 부분은 모델 자체가 아니라 답변의 신뢰성을 어떻게 보장하느냐입니다. 이는 컨텍스트와 소유권에 달려 있습니다.
클러스터 모델
Spotify에서는 데이터 도메인을 클러스터라고 부릅니다. 이 도메인은 이니셔티브, 조직, 혹은 임시 관심사와 연결될 수 있습니다. 이러한 유연성 덕분에 어느 인사이트 팀이든 자신들의 주제에 맞는 클러스터를 만들 수 있으며, 동시에 해당 도메인이 이미 커버되고 있는지도 알 수 있습니다. 각 클러스터는 도메인 전문가 팀이 소유하며 다음 세 가지 요소로 구성됩니다:
-
데이터셋: 관련 있는 데이터 웨어하우스 테이블 전체 스키마와 프로파일링 정보를 포함합니다. 컬럼 카디널리티, 일반 값 샘플, 파티션 구조 등을 캡처합니다. 모델이
WHERE절을 생성할 때country컬럼에'US', 'GB', 'SE'와 같은 값이 존재한다는 정보를 알면 추측 없이 정확히 처리할 수 있습니다. -
페어: 검증된 질문‑SQL 예시. 이는 데이터 에이전트를 구동하는 few‑shot 메커니즘입니다. 도메인 전문가가 각 페어를 작성하거나 승인하며, 동료가 따라야 할 패턴을 가르치는 예시를 선택합니다. 이렇게 하면 LLM이 데이터를 어떻게 쿼리하고 의미를 해석해야 하는지를 학습합니다.
-
문서: 추가 비즈니스 컨텍스트. 용어 정의, 주의사항, 팀별 정의 차이, 사용해야 할 컬럼과 피해야 할 컬럼 등에 대한 정보를 담고 있습니다.
큐레이션은 데이터 모델링과 효율적인 쿼리 방법을 잘 아는 데이터 전문가, 데이터 과학자, 분석 엔지니어가 담당합니다. 이들은 도메인을 어떻게 클러스터로 나눌지, 어떤 테이블을 포함할지, 어떤 예시가 중요한지를 결정합니다.
인간 판단
가장 쉬운 지름길은 큐레이터를 생략하는 것이었습니다. 우리 데이터 웨어하우스에는 모든 데이터 전문가가 사용한 전체 쿼리 히스토리가 저장돼 있습니다. 여기서 질문‑SQL 페어를 생성하는 것은 간단합니다: 쿼리를 가져와 LLM에게 해당 쿼리가 어떤 질문에 대한 답변인지 추론하도록 요청하고, 그 페어를 모델 교육에 활용합니다. 이는 실제 사람들이 도메인 지식을 얻기 위해 작성한 진짜 쿼리이므로 규모를 확장하는 방법처럼 보였습니다.
하지만 여기서 신뢰 문제가 발생합니다. Spotify처럼 규모가 큰 환경에서는 과신한 잘못된 추측이 의사결정을 크게 흔들 수 있습니다. 우리는 데이터에 익숙한 사람들에 의해 검토되고 정식으로 지정된(캐노니컬) 예시만을 사용하고 싶었습니다.
그래서 실험을 진행했습니다. 큐레이션 단계에서 우리는 실제 데이터 과학자들이 도메인에 대해 실행한 쿼리의 질문과 SQL을 제공했고, 클러스터 큐레이터에게 어떤 것이 좋은 예시인지 선택하도록 요청했습니다.
그 결과 **12.5%**만이 채택되었습니다.
나머지 87.5%는 즉흥 탐색, 디버깅 세션, 일회성 답변(다시 묻지 않을 것) 등으로, 잘못된 테이블을 사용했거나 기술적으로는 맞지만 잘못된 패턴을 가르치는 경우가 대부분이었습니다. 쿼리 히스토리는 풍부하지만 대부분은 잡음이며, 신호는 스스로 라벨링되지 않습니다.
그래서 모든 예시는 전문가의 검증을 거칩니다. 모델은 컨텍스트를 기반으로 추론할 뿐, 데이터가 실제로 어떻게 되는지는 전문가가 판단합니다. 이는 데이터를 가장 잘 다루는 사람들을 대체하는 것이 아니라, 그들의 전문성을 더 확장 가능한 방식으로 제공하는 것입니다.
클러스터 건강 관리
데이터는 변하고, 비즈니스 로직도 바뀌며, 지난달에 정확했던 컨텍스트가 오늘은 틀릴 수 있습니다. 스키마가 진화하고, 컬럼이 이름이 바뀌며, 테이블이 폐기되고 대체됩니다. Vedder는 이러한 정보를 최신 상태로 유지해야 하며, 지속적인 수동 관리에 의존해서는 안 됩니다.
**그림 3.** 데이터셋 컨텍스트.
그래서 각 클러스터는 지속적으로 계산·모니터링되는 신호들로 구성된 헬스 스코어를 갖습니다. 클러스터에 사용되는 기본 데이터는 얼마나 건강한가? 최근 스키마 변경 후에도 여전히 유효한 큐레이션된 페어는 몇 개인가? 컬럼 이름이 바뀌면 해당 페어는 즉시 품질이 저하됩니다. 실제 사용자가 묻는 질문을 컨텍스트가 얼마나 잘 커버하고 있는가? 생성된 SQL은 재현 가능했는가? 등 여러 지표가 포함됩니다. 이 중 하나라도 악화되면 클러스터 헬스 스코어가 감소하고, 이에 대한 조치가 제안됩니다.
![클러스터 헬스](https://images.ctfassets.net/p762jor363g1/5HBYd0hcSYN58auNyOU1jq/585970580d89e8530afec94dec237457/image2.png