들어가며: 데이터 전문가의 병목을 넘어서

스포티파이는 수천 개의 팀이 빠르게 움직이는 환경에서 데이터 인사이트 수요가 전문가의 처리 능력을 이미 초과했다는 문제를 직면했습니다. '데이터가 필요하면 관련 대시보드를 찾거나, 해당 도메인의 전문가에게 Slack으로 메시지를 보내고 기다리는' 전통적인 방식은 더 이상 스케일되지 않았죠.

이를 해결하기 위해 AI 데이터 어시스턴트를 개발했지만, 7만 개 이상의 데이터셋(페타바이트 규모)을 단순히 LLM에 집어넣는 방식은 통하지 않았습니다. 컨텍스트 윈도우의 한계도 문제였지만, 더 근본적인 이유는 스키마만으로는 데이터의 의미를 전달할 수 없기 때문입니다.

예를 들어, INT64 타입의 컬럼이 있다고 칩시다. 그 값 중 100 미만은 레거시 테스트 데이터라는 사실, '활성 사용자'의 정의가 팀마다 어떻게 다른지, 스키마는 절대 알려주지 않습니다.

스포티파이가 선택한 해결책은 '컨텍스트 레이어(Context Layer)' 였습니다. 데이터 웨어하우스 전체가 아니라, 실제로 중요한 조각들을 해당 도메인을 가장 잘 이해하는 사람이 큐레이션하는 중간 계층을 만든 것이죠. 이 아키텍처는 스포티파이 앱 릴리스의 뒷모습 대시보드 설계와 자동화의 교훈에서 다룬 자동화 철학과도 맥을 같이 합니다.

Spotify data assistant architecture diagram showing cluster model with datasets, pairs, and docs Dev Environment Setup

Vedder: 스포티파이의 데이터 어시스턴트

스포티파이는 이 데이터 어시스턴트를 Vedder라고 명명했습니다. 2025년 8월부터 실제 운영에 들어갔고, 현재 2,100명 이상의 스포티파이 직원이 13,000회 이상의 대화, 60,000개 이상의 메시지를 주고받으며 사용 중입니다. 놀라운 점은 사용자 중 4분의 1 이상이 SQL을 한 번도 작성해본 적 없는 사람들이라는 겁니다.

작동 방식

  1. 사용자가 자연어로 질문을 입력합니다.
  2. 에이전트가 적절한 컨텍스트(클러스터)를 선택합니다.
  3. SQL 쿼리를 생성하고, 웨어하우스에 실행합니다.
  4. 결과와 함께 쿼리, 출처를 반환합니다.

Vedder는 ReAct(Reasoning + Acting) 루프를 따릅니다. 한 단계씩 추론하고 행동하며, 각 도구 호출 결과에 따라 조정합니다. 사용자는 결과뿐만 아니라 그 결과가 어떻게 만들어졌는지 투명하게 볼 수 있습니다.

인터페이스

  • Slack 봇: 스레드에서 빠른 질문
  • MCP 서버: IDE 및 AI 도구 연동
  • 전용 웹 UI: 대화형 탐색

만약 어떤 주제를 다루는 지식 베이스가 없으면, 데이터 어시스턴트는 그 사실을 사용자에게 알려줍니다. 이 투명성이 답변의 신뢰성을 높이는 핵심입니다.

Developer using AI data assistant Slack bot for SQL query generation from natural language Software Concept Art

핵심 아키텍처: 클러스터 모델

스포티파이는 데이터 도메인을 클러스터(Cluster) 라고 부릅니다. 각 클러스터는 특정 이니셔티브, 조직, 또는 애드혹 관심사에 연결될 수 있으며, 다음 세 가지 구성 요소로 이루어집니다.

1. 데이터셋 (Datasets)

관련 데이터 웨어하우스 테이블의 전체 스키마와 프로파일링 정보를 포함합니다. 단순한 컬럼명과 타입을 넘어, 카디널리티(고유값 수), 샘플 값, 파티션 구조까지 캡처합니다. 예를 들어 country 컬럼에 'US', 'GB', 'SE' 같은 값이 들어있다는 사실을 모델이 알면, WHERE 절을 더 정확하게 생성할 수 있습니다.

2. 페어 (Pairs)

검증된 질문-SQL 쌍입니다. 이것이 데이터 어시스턴트의 퓨샷(Few-shot) 메커니즘입니다. 도메인 전문가가 각 페어를 승인하거나 직접 작성하며, 동료가 따라야 할 패턴을 가르칩니다. 이 페어들은 LLM에게 '이 데이터를 어떻게 질의하고, 의미를 해석해야 하는지'를 알려주는 교과서 역할을 합니다.

3. 문서 (Docs)

추가적인 비즈니스 컨텍스트입니다. 용어 정의, 주의사항(Gotchas), 팀별로 다른 정의, 사용해야 할 컬럼과 피해야 할 컬럼 등이 포함됩니다. 예를 들어 '활성 사용자'의 정의가 A팀과 B팀에서 다르다면, 그 차이를 문서화합니다.

큐레이션의 중요성: 12.5% 법칙

스포티파이는 한 가지 실험을 했습니다. 데이터 웨어하우스에 저장된 전체 쿼리 히스토리에서 질문-SQL 페어를 자동 생성하고, 클러스터 큐레이터에게 '이 중 좋은 예시를 골라달라'고 요청했습니다.

결과는 충격적이었습니다. 단 12.5%만이 승인되었습니다.

나머지 87.5%는:

  • 일회성 탐색 쿼리
  • 디버깅 세션
  • 잘못된 테이블을 사용한 쿼리
  • 기술적으로는 맞지만, 잘못된 패턴을 가르치는 쿼리

쿼리 히스토리는 대부분 노이즈(Noise)입니다. 신호(Signal)는 스스로 레이블을 붙이지 않습니다. 그래서 모든 예시는 반드시 전문가의 검토를 거쳐야 합니다. 모델은 컨텍스트 위에서 추론할 뿐, 데이터에 대해 '무엇이 진실인지' 결정하지 않습니다. 그 역할은 도메인 전문가의 몫입니다.

이 방식은 전문가를 대체하는 것이 아닙니다. 그들의 전문성을 더 확장 가능한 방식으로 제공하는 것입니다.

Data expert curating context layer for AI assistant with health score dashboard

클러스터 건강 관리: 헬스 스코어

데이터는 변하고, 비즈니스 로직은 바뀌며, 지난달에 정확했던 컨텍스트가 오늘은 틀릴 수 있습니다. 스키마가 진화하고, 컬럼이 이름을 바꾸고, 테이블이 폐기됩니다. Vedder가 지속적으로 정확한 정보를 제공하려면 상시 모니터링이 필요합니다.

각 클러스터는 헬스 스코어(Health Score) 로 관리됩니다. 헬스 스코어는 다음과 같은 신호를 종합하여 계산합니다:

  • 기반 데이터 건강도: 클러스터가 참조하는 데이터의 품질
  • 페어 유효성: 최근 스키마 변경 후에도 큐레이션된 페어가 여전히 유효한가?
  • 커버리지: 컨텍스트가 사용자들이 실제로 묻는 질문을 잘 커버하는가?
  • 재현성: 생성된 SQL이 재현 가능한가?

헬스 스코어가 낮아지면 대시보드에 신호가 표시되고, 큐레이터에게 개선 액션이 제안됩니다.

피드백 루프: 닫힌 순환

모든 Vedder 대화는 시스템으로 피드백됩니다. Vedder는 모든 대화와 쿼리를 로깅하고, 질문, 답변, 생성된 SQL, 사용자 피드백을 클러스터 소유자에게 보여줍니다. 이는 데이터 과학자의 지식을 스케일링하는 방법입니다. 그들이 승인한 모든 질문-SQL 페어, 명확히 한 모든 문서는 다음 사용자가 더 정확한 인사이트를 얻는 데 기여합니다.

국내 SI 환경에서의 적용 맥락

이 아키텍처는 데이터 레이크나 웨어하우스가 잘 정비된 조직에 특히 적합합니다. 국내 SI 환경에서는 다음과 같은 점을 고려해야 합니다:

  • 데이터 카탈로그의 성숙도: 스포티파이처럼 잘 정리된 데이터 카탈로그가 없다면, 클러스터 구축 자체가 더 큰 노력이 필요합니다.
  • 도메인 전문가의 역할: 데이터 분석가/엔지니어가 단순히 쿼리를 작성하는 것을 넘어, 컨텍스트 큐레이터로서의 역할을 수용할 수 있는 조직 문화가 선행되어야 합니다.
  • 초기 투자: 클러스터를 처음 구축할 때 큐레이션에 드는 시간이 상당하지만, 이후 자동화와 피드백 루프를 통해 ROI가 급격히 증가합니다.

이 기술의 한계 또는 주의사항

  • 컨텍스트 큐레이션의 병목: 여전히 인간 전문가의 시간이 필요합니다. 자동 생성된 페어의 87.5%가 노이즈라는 사실은, 완전 자동화가 어렵다는 것을 의미합니다.
  • 스키마 외부 지식: 현재 아키텍처는 주로 스키마와 정형화된 문서에 의존합니다. 조직 내 프로세스 정의나 비정형 문서에 있는 지식은 아직 완전히 커버하지 못합니다. 스포티파이도 이 부분을 다음 과제로 삼고 있습니다.
  • 확장성 vs 정확성 트레이드오프: 클러스터가 너무 많아지면 관리 부담이 커집니다. 적절한 클러스터 분할 전략이 중요합니다.

다음 단계 학습 방향

  1. ReAct 패턴에 대해 더 알아보기: arXiv 논문 Reasoning and Acting in Language Models은 Vedder의 핵심 루프를 이해하는 데 필수적입니다.
  2. 퓨샷 프롬프팅과 컨텍스트 윈도우 최적화 전략을 학습해보세요. LLM이 컨텍스트를 효과적으로 활용하는 방법을 이해하면, 유사한 시스템을 직접 구축할 수 있습니다.
  3. 데이터 카탈로그 도구(예: Apache Atlas, Amundsen)와 데이터 품질 모니터링 도구를 함께 살펴보면, 클러스터 모델을 실제로 구현하는 데 도움이 됩니다.

스포티파이의 접근법이 주는 교훈은 분명합니다: AI의 신뢰성은 모델 자체가 아니라, 그 모델이 보는 컨텍스트의 품질에 달려 있다. 데이터 전문가를 대체하는 것이 아니라, 그들의 전문성을 더 스마트하게 확장하는 방법을 고민해야 할 때입니다.

이 아키텍처를 더 깊이 이해하고 싶다면, FunctionGemma, TPU로 10분 만에 파인튜닝하기 (Tunix + Colab 실습 가이드)에서 다루는 모델 파인튜닝 기법과 결합하면 더 강력한 데이터 어시스턴트를 구축할 수 있을 것입니다.

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.