Spotify의 Kong AI 게이트웨이 도입기: 생성형 AI 인프라 확장

Spotify가 7,000명 이상의 직원에게 생성형 AI를 제공하기 위해 Kong AI 게이트웨이를 도입한 과정을 다룬다. 각 팀이 OpenAI, Vertex AI, 자체 Hendrix 모델을 직접 통합하면서 인증, 비용 추적, 모니터링 중복 문제가 심화됐고, 중앙화된 AI 게이트웨이로 이를 해결했다. 현재 1,000개 이상의 내부 서비스가 연결되어 있고, 팀이 하루 만에 AI 기능을 프로덕션에 배포할 수 있게 됐다.

핵심 포인트

각 팀의 독립 LLM 통합 방식이 수백 개 소비자로 늘어나자 새 통합마다 수 주가 소요되는 병목으로 이어졌다.
Kong은 40ms 라우팅 오버헤드, 인스턴스당 1,000 RPS 이상 확장, 자체 호스팅(데이터가 Spotify 인프라 밖으로 나가지 않음)의 이점으로 선택됐다.
GKE에서 제어 평면(PostgreSQL 백업)과 데이터 평면(상태 비저장 프록시)을 분리하는 하이브리드 모드로 구성됐다.
decK 도구로 모든 게이트웨이 구성을 버전 관리되는 YAML로 정의하는 GitOps 워크플로우를 도입했다.
ai-guardrails 플러그인이 모든 프롬프트를 모델 도달 전 스캔하고, 제공자 장애 시 800개 이상 소비자의 코드 수정 없이 게이트웨이에서 재라우팅한다.

상세 정리

문제 정의: 각 팀이 LLM 제공자와 직접 통합하며 인증, 속도 제한, 비용 추적을 중복 구현하고, 중앙화된 모니터링과 일관된 오류 처리가 없어 신규 통합마다 수 주가 소요됐다.
AI vs 전통 API 차이: 전통 API는 지연 100ms 미만, 요청 크기 10KB 미만인 반면 LLM API는 지연이 초에서 분 단위, 요청 크기 1MB 이상, 연결 패턴이 스트리밍, 비용 모델이 토큰당이라 전용 처리 계층이 필요했다.
Kong 선택 기준: 약 40ms 라우팅 오버헤드와 인스턴스당 1,000 RPS 이상 확장 가능, 모든 데이터가 Spotify 인프라 내에 유지되는 자체 호스팅 방식이 핵심 기준이었다.
아키텍처 구성: GKE에서 제어 평면(Kong Manager + PostgreSQL)과 데이터 평면(상태 비저장 프록시)을 분리해 장애 격리와 독립 확장을 실현했다.
GitOps 도입: decK CLI로 Kong 구성을 YAML로 정의하고 PR 기반으로 변경하는 워크플로우를 구축해 변경 이력 추적과 롤백이 쉬워졌다.
플러그인 체인: ai-proxy-advanced(다중 제공자 라우팅, 인증, 변환) → Prometheus(HTTP 메트릭 + AI 특화 텔레메트리: 토큰 수, 제공자 지연) → OpenTelemetry(1% 샘플링 엔드투엔드 추적) 순으로 적용했다.
AI 특화 메트릭: kong_ai_llm_requests_total(모델별), kong_ai_llm_tokens_total(유형별), kong_ai_llm_provider_latency_ms(지연) 등 LLM 전용 Prometheus 메트릭을 별도 수집했다.
보안 구성: ai-guardrails 플러그인이 모든 프롬프트를 모든 모델 도달 전 스캔하고, 제공자 장애 시 800개 이상 소비자의 코드 수정 없이 게이트웨이 수준에서 재라우팅이 가능하다.
사용 사례: DJ 내레이션, 플레이리스트 분석, SOX 준수 챗봇, HR 챗봇 등 다양한 사용 사례에서 1,000개 이상의 내부 서비스와 개인이 온보딩됐다.
향후 계획: 이미지, 오디오, 비디오 생성 등 새 모달리티 지원, Confidence 플랫폼과 연계한 모델 A/B 테스트, 에이전틱 워크플로우를 위한 게이트웨이 수준 가드레일 강화를 계획 중이다.