🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

스포티파이는 방대한 데이터 웨어하우스를 LLM에 그대로 넣는 대신, 도메인 전문가가 큐레이션한 ‘컨텍스트 레이어’를 통해 신뢰 가능한 데이터 어시스턴트를 구축했다.

📌 핵심 요약

• 스포티파이의 데이터 문제는 적절한 대시보드를 찾지 못하고, 결국 슬랙으로 도메인 전문가에게 질문한 뒤 답변을 기다리는 방식으로 반복되어 왔다.
• 70,000개 이상의 데이터셋과 페타바이트 규모의 데이터에서는 전체 스키마를 LLM에 넣는 방식이 작동하지 않으며, 스키마만으로는 실제 비즈니스 의미와 예외를 충분히 설명할 수 없다.
• 스포티파이의 데이터 어시스턴트 Vedder는 사용자의 자연어 질문을 받아 적절한 컨텍스트를 고르고, SQL을 작성·실행한 뒤 답변과 쿼리, 출처를 함께 제공한다.
• 핵심은 모델 자체가 아니라 도메인 전문가가 관리하는 클러스터 구조이며, 각 클러스터는 관련 데이터셋, 검증된 질문-SQL 예시, 추가 비즈니스 문서로 구성된다.
• 스포티파이는 쿼리 히스토리를 자동으로 예시화하는 방식도 시험했지만, 전문가들이 실제로 채택한 것은 12.5%뿐이었고, 나머지는 탐색·디버깅·일회성 답변·잘못된 패턴 등 신뢰하기 어려운 노이즈였다.

🧩 주요 포인트

1. 스포티파이의 데이터 문제는 적절한 대시보드를 찾지 못하고, 결국 슬랙으로 도메인 전문가에게 질문한 뒤 답변을 기다리는 방식으로 반복되어 왔다.
2. 70,000개 이상의 데이터셋과 페타바이트 규모의 데이터에서는 전체 스키마를 LLM에 넣는 방식이 작동하지 않으며, 스키마만으로는 실제 비즈니스 의미와 예외를 충분히 설명할 수 없다.
3. 스포티파이의 데이터 어시스턴트 Vedder는 사용자의 자연어 질문을 받아 적절한 컨텍스트를 고르고, SQL을 작성·실행한 뒤 답변과 쿼리, 출처를 함께 제공한다.
4. 핵심은 모델 자체가 아니라 도메인 전문가가 관리하는 클러스터 구조이며, 각 클러스터는 관련 데이터셋, 검증된 질문-SQL 예시, 추가 비즈니스 문서로 구성된다.
5. 스포티파이는 쿼리 히스토리를 자동으로 예시화하는 방식도 시험했지만, 전문가들이 실제로 채택한 것은 12.5%뿐이었고, 나머지는 탐색·디버깅·일회성 답변·잘못된 패턴 등 신뢰하기 어려운 노이즈였다.

🧠 상세 정리

1. 데이터 수요가 전문가 개인의 처리 능력을 넘어선 배경

스포티파이에서 데이터 문제는 대체로 비슷한 흐름으로 발생했다. 사용자는 먼저 관련 대시보드를 찾지만 없는 경우가 많았고, 결국 해당 데이터를 잘 아는 전문가에게 슬랙으로 질문한 뒤 시간이 날 때까지 기다려야 했다. 조직 내 수천 개 팀이 빠르게 움직이면서 데이터 인사이트에 대한 수요는 조용히 커졌고, 특정 개인이나 소수 전문가가 감당할 수 있는 수준을 넘어섰다. 이 문제를 해결하기 위해 스포티파이는 AI 데이터 어시스턴트를 개발하기 시작했지만, 회사에는 70,000개 이상의 데이터셋과 페타바이트 규모의 데이터가 있었기 때문에 어느 한 사람이 전체를 이해한다고 말할 수 없는 상황이었다.

2. 스키마만으로는 부족한 이유와 컨텍스트 레이어의 필요성

스포티파이는 단순히 모든 스키마를 LLM에 넣는 방식이 대규모 데이터 환경에서는 작동하지 않는다고 설명한다. 컨텍스트 윈도우가 백만 토큰 수준으로 커지더라도 전체 데이터 웨어하우스를 담기에는 부족하고, 더 근본적으로 스키마는 데이터의 의미를 충분히 전달하지 못한다. 예를 들어 어떤 컬럼이 INT64 타입이라는 사실만으로는 100 미만 값이 레거시 테스트 데이터인지, 실제 데이터와 어떻게 정의가 다른지, ‘활성 사용자’가 무엇을 의미하는지 알 수 없다. 같은 수의 테이블을 모델에 제공하면 모델은 자신 있게 잘못된 테이블을 고를 수 있기 때문에, 스포티파이는 데이터의 중요한 의미를 담고 도메인을 이해하는 사람이 소유하는 중간 계층이 필요하다고 판단했다.

3. Vedder의 작동 방식과 사용자 접점

스포티파이의 데이터 어시스턴트 Vedder는 사용자가 간단한 영어로 질문하면 몇 초 안에 신뢰 가능한 데이터를 얻도록 설계되었다. 2025년 8월부터 실제로 사용되었고, 2,100명 이상의 스포티파이 직원이 13,000개 이상의 대화와 60,000개 이상의 메시지에서 활용했으며, 광고·팟캐스트·음악·오디오북·재무·크리에이터 도구 등 다양한 영역을 포괄하는 177개 클러스터를 사용했다. 사용자 중 4분의 1 이상은 SQL을 작성해 본 적이 없었다. 질문이 들어오면 에이전트는 적절한 컨텍스트를 선택하고 SQL 쿼리를 작성한 뒤 웨어하우스에서 실행하며, 답변과 함께 쿼리와 출처를 반환한다. 또한 ReAct 루프를 따라 단계적으로 추론하고 도구 호출 결과에 따라 조정하므로, 사용자는 결과뿐 아니라 그 결과가 어떻게 만들어졌는지도 확인할 수 있다.

4. 클러스터 모델: 도메인 지식을 구조화하는 방식

스포티파이는 데이터 도메인을 ‘클러스터’라고 부르며, 이 클러스터는 특정 이니셔티브, 조직, 또는 임시 관심사와 연결될 수 있다. 이러한 유연성 덕분에 인사이트 팀은 자신들의 주제에 맞춰 클러스터를 만들 수 있고, 이미 해당 도메인이 다뤄지고 있는지도 알 수 있다. 각 클러스터는 이름이 지정된 도메인 전문가 팀이 소유하며, 관련 데이터셋, 검증된 질문-SQL 쌍, 추가 문서라는 세 가지 요소로 구성된다. 데이터셋에는 전체 스키마와 프로파일링 정보가 포함되며, 컬럼 카디널리티, 자주 등장하는 값의 샘플, 파티션 구조도 함께 담긴다. 예를 들어 WHERE 절을 만들 때 country 컬럼에 'US', 'GB', 'SE' 같은 값이 있다는 사실을 아는 것은 모델이 추측하는 것보다 훨씬 안전하다.

5. 전문가 판단이 필요한 이유: 쿼리 히스토리는 대부분 노이즈였다

스포티파이가 검토한 쉬운 우회로는 큐레이터를 생략하고 기존 쿼리 히스토리를 활용하는 방식이었다. 데이터 웨어하우스에는 데이터 전문가들이 실제로 작성한 쿼리 이력이 있고, 각 쿼리에 대해 LLM이 원래 질문을 추론하게 하면 질문-SQL 예시를 대량으로 만들 수 있다. 겉으로는 도메인 지식을 확장하는 방법처럼 보였지만, 문제는 신뢰였다. 스포티파이 규모에서는 확신에 찬 잘못된 답변이 의사결정을 잘못된 방향으로 이끌 수 있기 때문이다. 실제 큐레이션 단계에서 도메인 전문가들에게 실제 쿼리 기반 질문-SQL 후보를 고르게 했을 때 채택률은 12.5%에 그쳤고, 나머지 87.5%는 임시 탐색, 디버깅, 일회성 답변, 잘못된 테이블 사용, 기술적으로는 맞지만 나쁜 패턴을 가르치는 사례였다.

6. 클러스터 건강도와 피드백 루프로 유지되는 신뢰성

데이터는 계속 바뀌고 비즈니스 로직도 이동하기 때문에, 지난달에는 정확했던 컨텍스트가 오늘은 틀릴 수 있다. 스키마가 진화하고 컬럼명이 바뀌며 테이블이 폐기되거나 대체되면, 클러스터도 그 변화를 반영해야 한다. 이를 위해 각 클러스터에는 지속적으로 계산·모니터링되는 여러 신호로 구성된 건강 점수가 있다. underlying data의 상태, 최근 스키마 변경 이후 큐레이션된 질문-SQL 쌍이 여전히 유효한지, 실제 사용자 질문을 컨텍스트가 얼마나 잘 포괄하는지, 생성된 SQL이 얼마나 재현 가능한지 등이 반영된다. Vedder는 모든 대화와 쿼리, 질문, 답변, 생성 SQL, 사용자 피드백을 기록해 클러스터 소유자에게 보여주며, 전문가들은 이를 바탕으로 어디에 큐레이션 시간을 쓸지 결정한다.

7. 스포티파이 밖에서도 적용 가능한 핵심 원칙

스포티파이는 잘 관리된 데이터셋, 데이터 카탈로그, 도메인을 중요하게 여기는 데이터 과학자라는 강한 기반이 있었기 때문에 Vedder를 만들 수 있었다고 설명한다. 그러나 이 아키텍처의 핵심 아이디어는 스포티파이에만 한정되지 않는다. 특정 데이터 도메인을 가장 잘 이해하는 사람들이 모델이 보게 될 컨텍스트를 큐레이션해야 한다는 원칙은 다른 조직에도 적용될 수 있다. 원시 스키마만으로는 사람과 LLM 모두 이해에 한계가 있으며, 실제 인사이트를 확장하려면 의미와 맥락이 필요하다. 이 접근은 데이터 전문가가 일회성 질문에 답하는 시간을 줄이고, 수천 개의 질문에 답할 수 있는 지식 계층을 설계하는 더 전략적인 역할을 맡게 만든다.

🧾 핵심 주장 / 시사점

• LLM 기반 데이터 도구의 신뢰성은 모델 크기보다 어떤 컨텍스트를 누가 관리하느냐에 더 크게 좌우된다.
• 실제 쿼리 히스토리는 풍부한 자료처럼 보이지만, 전문가 검증 없이는 잘못된 패턴을 학습시킬 위험이 크다.
• 데이터 어시스턴트를 운영 가능한 시스템으로 만들려면 초기 구축보다 컨텍스트의 지속적 건강도 관리와 피드백 루프가 핵심이다.

✅ 액션 아이템

• Vedder처럼 LLM 데이터 어시스턴트를 만들 때 원시 스키마 대신 도메인 전문가가 관리하는 컨텍스트 레이어를 어디에 둘지 설계한다.
• 질문-SQL 예시를 자동으로 가져오기 전에 실제 쿼리 히스토리의 탐색·디버깅·일회성 노이즈를 걸러낼 큐레이션 기준을 만든다.
• 데이터셋, 검증된 질문-SQL 쌍, 비즈니스 문서로 구성된 클러스터 단위를 정하고 각 클러스터의 소유자와 유지보수 책임을 지정한다.
• 컨텍스트 건강도, 사용자 피드백, 생성 SQL 재현성, 스키마 변경 이후 유효성을 측정하는 운영 지표를 대시보드화한다.

❓ 열린 질문

• 데이터 어시스턴트가 잘못된 SQL을 자신 있게 생성하지 않도록, Spotify의 클러스터 방식 외에 어떤 검증 계층이 추가로 필요할까?
• 전문가가 채택한 자동 생성 질문-SQL 후보가 12.5%에 그쳤다는 사실은 기업 데이터 AI 도입에서 어떤 비용 구조를 의미할까?
• 70,000개 이상의 데이터셋과 페타바이트 규모 웨어하우스에서는 LLM 컨텍스트 윈도우 확대보다 도메인 분할과 검색 전략이 더 중요해질까?
• Vedder의 ReAct 루프와 출처 반환 방식은 finance, legal, audit처럼 오류 비용이 큰 데이터 도메인에도 그대로 적용될 수 있을까?