스포티파이가 7만 개 데이터셋을 AI에게 가르친 방법 컨텍스트 큐레이션의 힘

들어가며: 데이터 전문가의 고민, AI로 풀다

스포티파이에서 데이터 분석 요청은 전형적인 패턴을 따랐습니다. 관련 대시보드를 찾아보지만 없고, 슬랙으로 데이터 전문가에게 메시지를 보내고, 그들이 시간이 날 때까지 기다리는 식이었죠. 수천 개 팀이 빠르게 움직이는 환경에서 데이터 인사이트 수요는 개별 전문가가 감당할 수 있는 수준을 이미 넘어섰습니다.

이 문제를 해결하기 위해 AI 데이터 어시스턴트 개발에 착수했지만, 7만 개 이상의 데이터셋(페타바이트 규모)을 가진 환경에서 단순히 모든 스키마를 LLM에 넣는 방식은 통하지 않았습니다. 컨텍스트 윈도우는 아무리 커봐야 100만 토큰 정도인데, 데이터 웨어하우스 전체를 담기엔 턱없이 부족합니다. 게다가 스키마만으로는 모든 정보를 전달할 수 없습니다. 예를 들어 특정 컬럼이 INT64 타입이라고 해서 '100 미만은 레거시 테스트 데이터'라는 사실이나 '활성 사용자'의 정의 차이를 알 수는 없습니다.

스포티파이가 선택한 해결책은 '컨텍스트 레이어' 였습니다. 데이터 웨어하우스의 일부에서 실제로 중요한 정보만을 캡처하고, 그 데이터를 소유하고 이해하는 도메인 전문가가 관리하는 중간 계층을 두는 것이었죠. 이 접근법은 단순히 기술적인 문제를 넘어, 조직 내 데이터 거버넌스와 전문성 활용에 대한 깊은 통찰을 제공합니다.

이 글은 스포티파이 엔지니어링 블로그의 'Encoding Your Domain Expert' 아티클을 기반으로, 한국 개발자와 데이터 팀의 관점에서 분석하고 재구성했습니다. 원문은 여기에서 확인할 수 있습니다.

Vedder: 스포티파이의 AI 데이터 어시스턴트 아키텍처

Vedder(스포티파이 데이터 어시스턴트의 코드명)는 2025년 8월부터 운영되기 시작했습니다. 현재 2,100명 이상의 스포티파이 직원이 13,000회 이상의 대화와 60,000개 이상의 메시지를 주고받으며 사용 중이며, 광고, 팟캐스트, 음악, 오디오북, 재무, 크리에이터 도구 등 177개 클러스터(도메인)를 커버합니다. 놀라운 점은 사용자 중 4분의 1 이상이 SQL을 한 번도 작성해본 적 없는 사람들이라는 겁니다.

작동 방식

사용자가 질문을 입력하면 Vedder는 다음 과정을 거칩니다:

1. 적절한 컨텍스트(클러스터) 선택
2. SQL 쿼리 생성
3. 데이터 웨어하우스에 쿼리 실행
4. 쿼리와 출처와 함께 답변 반환

이는 ReAct(Reasoning and Acting) 루프를 따릅니다. 모델이 단계적으로 추론하고 행동하며, 각 도구 호출 결과에 따라 조정합니다. 사용자는 결과뿐만 아니라 결과가 어떻게 생성되었는지도 확인할 수 있어 투명성을 보장합니다.

인터페이스

Vedder는 사용자가 이미 작업 중인 표면에 내장되었습니다:

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

클러스터 모델: 도메인 지식의 캡슐화

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

이 큐레이션은 데이터 사이언티스트와 애널리틱스 엔지니어가 담당합니다. 그들은 자신의 도메인을 어떻게 클러스터로 나눌지, 어떤 테이블을 포함할지, 어떤 예시가 중요한지 결정합니다.

핵심 코드 예제: 클러스터 헬스 점수 계산

다음은 Vedder가 클러스터의 건강 상태를 모니터링하는 방식을 간단히 표현한 의사 코드입니다:

# 클러스터 헬스 점수 계산 예시 (의사 코드)

def calculate_cluster_health(cluster):
    """
    클러스터의 건강 점수를 계산합니다.
    여러 신호를 조합하여 종합 점수를 산출합니다.
    """
    signals = []
    
    # 1. 기반 데이터 건강도
    schema_freshness = check_schema_freshness(cluster.datasets)
    signals.append(schema_freshness * 0.3)
    
    # 2. 큐레이션된 페어의 유효성
    valid_pairs_ratio = 0
    for pair in cluster.curated_pairs:
        if is_pair_still_valid(pair, current_schema):
            valid_pairs_ratio += 1
    valid_pair_score = valid_pairs_ratio / len(cluster.curated_pairs)
    signals.append(valid_pair_score * 0.4)
    
    # 3. 사용자 질문 커버리지
    coverage = measure_question_coverage(cluster, recent_user_queries)
    signals.append(coverage * 0.2)
    
    # 4. 생성된 SQL 재현율
    reproducibility = measure_sql_reproducibility(cluster.generated_sql)
    signals.append(reproducibility * 0.1)
    
    total_score = sum(signals)
    return total_score

# 컬럼 이름 변경 시 페어 자동 무효화 예시
def is_pair_still_valid(pair, current_schema):
    """
    페어가 현재 스키마에서 여전히 유효한지 확인합니다.
    참조하는 모든 컬럼이 존재하고 타입이 일치해야 합니다.
    """
    for table_ref in pair.sql_parse.get_table_references():
        if table_ref not in current_schema:
            return False
        for column_ref in pair.sql_parse.get_column_references(table_ref):
            if column_ref not in current_schema[table_ref]['columns']:
                return False
    return True

인간의 판단이 필요한 이유: 87.5%의 노이즈

Vedder 개발 과정에서 가장 중요한 발견 중 하나는 자동 생성된 학습 데이터의 신뢰성 문제였습니다. 스포티파이 데이터 웨어하우스에는 모든 데이터 전문가의 쿼리 히스토리가 저장되어 있습니다. 여기서 질문-SQL 페어를 생성하는 것은 간단해 보입니다: 쿼리를 가져와 LLM이 해당 쿼리가 작성된 질문을 추론하게 한 후, 그 페어를 모델 학습에 사용하는 것이죠.

하지만 실제로 큐레이션 단계에서 도메인 전문가에게 제안된 페어 중 단 12.5%만이 승인되었습니다. 나머지 87.5%는:

• 임시 탐색(ad-hoc exploration) 쿼리
• 디버깅 세션
• 누구도 다시 묻지 않을 일회성 답변
• 잘못된 테이블을 사용한 쿼리
• 기술적으로는 맞지만 잘못된 패턴을 가르치는 쿼리

쿼리 히스토리는 풍부하지만, 대부분은 노이즈입니다. 그리고 신호는 스스로 레이블을 붙이지 않습니다.

국내 개발 생태계에서의 적용 맥락

한국 기업 환경에서 이 접근법을 적용할 때 고려할 점이 있습니다:

• SI/금융권 레거시: 많은 국내 기업이 수년간 축적된 데이터 웨어하우스를 보유하고 있지만, 체계적인 데이터 카탈로그나 도메인 전문가의 명확한 소유권이 없는 경우가 많습니다. 이 경우 클러스터 모델 도입 전에 데이터 거버넌스 체계를 먼저 정비하는 것이 선행되어야 합니다.
• 조직 문화: '내 데이터'에 대한 소유권 의식이 약한 조직에서는 큐레이션 참여를 유도하기 위한 인센티브 설계가 중요합니다. 스포티파이처럼 데이터 사이언티스트가 자신의 도메인을 돌보는 문화가 없다면, 최소한 전담 데이터 스튜어드 역할을 지정하는 것부터 시작하는 것이 좋습니다.
• 스타트업: 데이터 규모가 작은 스타트업은 오히려 이 모델을 더 쉽게 도입할 수 있습니다. 초기부터 데이터셋을 체계적으로 관리하고, 도메인별 큐레이션 프로세스를 구축하면 확장성 있는 AI 데이터 어시스턴트를 구축할 수 있습니다.

이 기술의 한계와 주의사항

Vedder의 아키텍처는 강력하지만, 몇 가지 한계가 있습니다:

1. 큐레이션 비용: 도메인 전문가의 시간 투자가 필요합니다. 스포티파이 규모에서는 감당할 수 있지만, 작은 팀에서는 부담이 될 수 있습니다.
2. 클러스터 경계 모호성: 도메인이 겹치거나 경계가 모호한 경우, 어떤 클러스터가 질문을 처리할지 결정하는 라우팅이 복잡해집니다.
3. 실시간 데이터: 클러스터 헬스 점수는 주기적으로 업데이트되지만, 스키마 변경이 실시간으로 반영되지 않으면 일시적으로 부정확한 답변이 생성될 수 있습니다.
4. 확장성 vs. 유연성: 사전 정의된 클러스터는 효율적이지만, 완전히 새로운 유형의 질문에는 대응하기 어렵습니다. 이 부분은 현재 스포티파이가 추가로 탐색 중인 영역입니다.

함께 보면 좋은 글

• CSS offset-path 완벽 가이드: SVG 경로 따라 움직이는 애니메이션 만들기
• 픽셀 퍼펙트는 이제 그만, 현대 웹 개발의 새로운 완벽함: 메타의 AI 에이전트 플랫폼이 보여주는 효율성 혁명

결론: 데이터 전문가의 역할을 재정의하다

스포티파이의 접근법이 주는 가장 큰 교훈은 AI가 데이터 전문가를 대체하는 것이 아니라, 그들의 전문성을 더 확장 가능한 방식으로 배포하는 것이라는 점입니다. 큐레이션을 통해 데이터 사이언티스트는 일회성 질문에 답변하는 시간을 줄이고, 수천 개의 질문에 답할 수 있는 지식 레이어를 구축하는 데 집중할 수 있게 되었습니다.

Vedder의 아키텍처는 스포티파이에 특화된 것이 아닙니다. 핵심 아이디어는 보편적입니다: 데이터 도메인을 가장 잘 이해하는 사람이 모델이 보는 컨텍스트를 큐레이션하는 것이 가장 효과적이다는 것입니다.

다음 단계 학습 방향

이 글을 통해 영감을 받았다면, 다음 주제를 탐구해보세요:

1. ReAct 패턴: LLM이 도구를 사용하여 추론하고 행동하는 패턴에 대해 더 깊이 이해하기 (원문 참고: arXiv:2210.03629)
2. RAG vs. 컨텍스트 큐레이션: 두 접근법의 차이점과 각각의 장단점 비교
3. 데이터 거버넌스 도구: Apache Atlas, DataHub, Amundsen 등 데이터 카탈로그 도구 학습
4. MCP(Model Context Protocol): AI 도구와 데이터 소스를 연결하는 표준 프로토콜 이해

데이터가 많아질수록, 그 데이터를 이해하는 '인간의 맥락'이 더 중요해집니다. 스포티파이의 사례는 기술과 인간 전문성의 조화가 어떻게 강력한 AI 시스템을 만드는지 잘 보여줍니다.