spotify2026년 7월 20일

콘텐츠 수집 및 팟캐스트 동영상 사고 보고서 | Spotify Engineering (새 탭에서 열림)

Spotify의 6월 24일 팟캐스트 영상 게시 지연은 트랜스코딩 용량 부족, 대량 배치 작업, 영상 처리 비용 증가, 자원 스케줄링 버그가 동시에 발생해 큐가 폭증하면서 일어났다. 신규 영상 게시가 수시간 지연됐고, 일부 크리에이터의 재업로드가 부하를 더욱 키웠다. Spotify는 배치 작업 중단, 버그 수정, 처리 용량 증설로 다음 날 새벽 backlog를 해소했으며, 이후 용량 계획·우선순위·모니터링을 전반적으로 개선하고 있다. ## 게시 지연이 발생한 과정 - 신규 팟캐스트의 오디오·비디오는 트랜스코딩과 콘텐츠 분석을 거쳐 Spotify에 게시된다. - 6월 24일 영상 트랜스코딩 인프라가 최대 용량에 도달하면서 신규 영상 게시 큐가 급격히 쌓였다. - 평소 수분 내 게시되던 영상이 수시간 동안 표시되지 않았다. - 업로드가 정상적으로 접수·대기 중이라는 확인이 충분히 제공되지 않아 일부 크리에이터가 에피소드를 재업로드했고, 이로 인해 시스템 부하가 추가됐다. - 신규 에피소드용 중간 우선순위 큐와 기존 에피소드 업데이트용 낮은 우선순위 큐가 모두 영향을 받았다. ## 장애를 키운 네 가지 요인 - **부족한 용량 여유** - 평상시 처리량은 감당할 수 있었지만, 대규모 콘텐츠 제출량 급증을 흡수할 여유 용량이 부족했다. - **기존 콘텐츠 재처리 배치 작업** - 재생 시스템 변경에 맞춰 기존 에피소드를 재처리하는 정기 작업이 신규 콘텐츠와 처리 자원을 경쟁했다. - 배치 작업은 처음에는 정상적으로 보였지만, 제출량 급증과 결합되면서 문제가 됐다. - **영상 품질 개선에 따른 처리 비용 증가** - 더 낮은 비트레이트에서 높은 품질을 제공하도록 변경하면서 에피소드당 처리 시간과 필요한 컴퓨팅 자원이 증가했다. - 용량 계획에 이 증가분이 충분히 반영되지 않았다. - **자원 스케줄링 버그** - 더 강력한 하드웨어로 이전한 뒤 스케줄링 오류가 가용 컴퓨팅 자원을 제대로 활용하지 못하게 했다. - 결과적으로 처리량이 약 10% 감소했다. ## 장애 대응과 복구 일정 - 13:30: 내부 모니터링에서 초기 경고가 발생했지만, 전체 용량 문제로 즉시 인식되지는 않았다. - 15:00: 영상 제출량 급증으로 트랜스코딩 용량이 한계에 접근했다. - 16:35: 용량 확보를 위해 배치 작업을 중단했다. - 17:34: 큐가 임계치를 넘었다는 자동 경고 후 공식 장애 대응을 시작했다. - 19:00: 크리에이터들이 에피소드 미표시 문제를 보고했다. - 20:49: 자원 활용률을 개선하는 소프트웨어 수정 사항을 배포했다. - 6월 25일 00:14: 추가 처리 클러스터를 가동했다. - 01:02: 모든 큐가 비워졌다. - 07:30: 전체 게시 파이프라인이 정상 작동하는 것을 최종 확인했다. ## 모니터링과 대응의 문제점 - 첫 경고가 발생한 뒤 공식 장애 대응이 시작되기까지 약 4시간이 걸렸다. - 엔지니어들은 16:35에 배치 작업을 중단했지만, 문제의 범위가 시스템 전체의 용량 부족이라는 점은 큐가 임계치를 넘은 뒤에야 명확해졌다. - Spotify는 용량 한계에 접근하는 단계에서 더 일찍 경고하도록 모니터링을 개선하고 있다. ## 후속 조치와 신뢰성 개선 - 트랜스코딩 처리 용량을 약 67% 늘려 트래픽 급증과 배치 작업을 위한 여유를 확보했다. - 가용 컴퓨팅 자원을 충분히 활용하지 못하게 하던 스케줄링 버그를 수정했다. - 용량 한계에 가까워질 때 더 빠르게 알림을 보내도록 모니터링을 개선했다. - 정상 상태의 트래픽뿐 아니라 급격한 증가와 장애 복구 상황까지 반영하는 용량 계획을 수립하고 있다. - 크리에이터의 실시간 콘텐츠가 백그라운드 작업보다 우선 처리되도록 게시 시스템의 우선순위 정책을 개선하고 있다. - 예상치 못한 부하를 완화하기 위해 파이프라인 전반에 속도 제한(rate limiting)과 백프레셔(backpressure)를 확대할 계획이다. ## 실용적인 결론 이번 장애는 단일 버그보다 용량 여유 부족, 배치 작업과 실시간 작업의 자원 경쟁, 처리 비용 증가, 모니터링 지연이 복합적으로 작용한 사례다. 대규모 미디어 처리 시스템에서는 평상시 처리량뿐 아니라 급격한 트래픽 증가를 견딜 여유 용량, 작업 우선순위, 조기 경보, 재시도·중복 업로드를 방지하는 명확한 상태 확인이 함께 설계되어야 한다.

monitoringincident-responserate-limitingvideo-transcoding+4

spotify2026년 6월 3일

도메인 전문가를 코드화하기: Spotify 데이터 어시스턴트를 뒷받침하는 컨텍스트 레이어 | Spotify Engineering (새 탭에서 열림)

Spotify의 데이터 어시스턴트가 신뢰할 만한 답변을 제공하는 핵심은 거대한 스키마를 LLM에 모두 넣는 것이 아니라, 도메인 전문가가 선별한 맥락 계층을 구축하는 데 있다. 이 맥락은 관련 데이터셋, 검증된 질문-SQL 예시, 업무 문서로 구성되며 각 도메인 팀이 소유하고 관리한다. 결국 AI는 전문가를 대체하기보다 전문가의 지식을 여러 사용자에게 확장하는 역할을 한다. ## 대규모 데이터 환경에서 스키마만으로 부족한 이유 - Spotify에는 7만 개 이상의 데이터셋과 페타바이트 규모의 데이터가 있다. - 모든 스키마를 LLM의 컨텍스트에 넣는 방식은 다음과 같은 한계가 있다. - 컨텍스트 윈도우가 전체 데이터 웨어하우스를 담기에 부족하다. - 컬럼 타입만으로는 실제 업무 의미를 알 수 없다. - 예를 들어 `INT64` 컬럼만 보고는 테스트 데이터와 실제 데이터의 구분, 또는 “활성 사용자”의 정의를 알 수 없다. - 테이블 수가 많을수록 모델은 비슷한 테이블 중 잘못된 대상을 선택하면서도 자신 있게 답할 수 있다. - 따라서 스키마와 LLM 사이에 도메인별 의미와 사용법을 담은 별도의 맥락 계층이 필요하다. ## Spotify 데이터 에이전트의 동작 방식 - 사용자가 자연어로 질문하면 에이전트가 다음 과정을 수행한다. - 적절한 데이터 맥락을 선택한다. - SQL을 생성한다. - 데이터 웨어하우스에서 쿼리를 실행한다. - 답변, 생성된 SQL, 사용한 출처를 함께 반환한다. - ReAct 루프를 사용해 도구 호출 결과에 따라 추론과 행동을 반복하고, 필요하면 쿼리를 수정한다. - 사용자는 결과뿐 아니라 답변이 어떻게 만들어졌는지도 확인할 수 있다. - Slack 봇, IDE와 AI 도구에서 사용할 수 있는 MCP 서버, 전용 웹 UI로 제공된다. - 관련 지식 기반이 없을 경우에도 이를 명시해 답변의 한계를 투명하게 드러낸다. - 2025년 8월 기준 2,100명 이상의 사용자가 13,000건 이상의 대화에서 활용했으며, 광고·팟캐스트·음악·오디오북·재무 등 177개 클러스터를 지원한다. ## 도메인별 클러스터 모델 Spotify는 데이터 도메인을 “클러스터”라고 부른다. 클러스터는 특정 조직, 프로젝트, 이니셔티브 또는 관심 주제를 중심으로 구성되며, 각 클러스터는 이름이 지정된 전문가 팀이 소유한다. - **데이터셋** - 관련 웨어하우스 테이블과 전체 스키마를 포함한다. - 컬럼 카디널리티, 자주 등장하는 값의 샘플, 파티션 구조 등을 프로파일링한다. - 예를 들어 `country` 컬럼에 `US`, `GB`, `SE` 등이 존재한다는 정보는 모델이 적절한 `WHERE` 조건을 작성하는 데 도움을 준다. - **질문-SQL 쌍** - 전문가가 작성하거나 검토한 질문과 SQL의 조합이다. - 단순한 예시가 아니라 해당 도메인에서 권장되는 쿼리 패턴과 데이터 의미를 가르치는 few-shot 자료로 사용된다. - **문서** - 업무 용어, 팀별로 달라지는 정의, 데이터 사용 시 주의점 등을 기록한다. - 어떤 컬럼을 사용해야 하고 어떤 컬럼을 피해야 하는지도 설명할 수 있다. - 클러스터의 범위, 포함할 테이블, 중요한 예시는 데이터 과학자와 애널리틱스 엔지니어 등 도메인 전문가가 결정한다. ## 자동 생성보다 전문가 검토가 중요한 이유 - Spotify는 데이터 웨어하우스의 과거 쿼리 기록에서 질문-SQL 쌍을 자동으로 생성하는 방법을 검토했다. - 실제 쿼리이므로 유용할 것처럼 보였지만, 큐레이터가 승인한 예시는 전체의 12.5%에 불과했다. - 나머지 87.5%에는 다음과 같은 쿼리가 포함되어 있었다. - 일회성 탐색이나 디버깅 쿼리 - 다시 사용하지 않을 임시 분석 - 잘못된 테이블을 사용한 쿼리 - 기술적으로는 맞지만 다른 사용자에게 잘못된 패턴을 가르치는 쿼리 - 쿼리 기록에는 정보가 많지만, 어떤 쿼리가 표준적인 지식인지는 자동으로 표시되지 않는다. - 따라서 AI가 데이터의 진실을 결정하도록 하지 않고, 전문가가 예시를 검토하고 정식 사례로 승인한다. - 목적은 전문가를 대체하는 것이 아니라 전문가의 판단을 재사용 가능한 형태로 확장하는 것이다. ## 클러스터의 지속적인 건강 관리 데이터 스키마와 업무 규칙은 계속 변하기 때문에, 한 번 만든 맥락이 영원히 정확한 것은 아니다. - 테이블이 교체되거나 폐기될 수 있다. - 컬럼명이 변경될 수 있다. - 비즈니스 정의와 분석 방식이 달라질 수 있다. - 기존 질문-SQL 쌍이 변경된 스키마와 호환되지 않을 수 있다. - Spotify는 여러 신호를 종합해 클러스터 건강 점수를 계산한다. - 기반 데이터의 상태 - 최근 스키마 변경 이후에도 curated pair가 유효한지 여부 - 실제 사용자가 묻는 질문을 충분히 다루는지 - 생성된 SQL을 재현할 수 있는지 - 기타 품질 및 활용 지표 - 문제가 발생하면 건강 점수가 낮아지고, 전문가에게 필요한 정비 작업이 제안된다. - 클러스터 소유자는 대시보드의 점수와 세부 신호를 보고 우선적으로 관리할 영역을 결정한다. ## 사용자 대화로 이어지는 피드백 루프 - 모든 대화와 쿼리는 기록되어 클러스터 소유자에게 전달된다. - 소유자는 질문, 답변, 생성된 SQL, 사용자 피드백을 확인할 수 있다. - 전문가가 질문-SQL 쌍을 승인하거나 문서를 보완할 때마다 이후 사용자에게 제공되는 맥락이 개선된다. - 즉, 실제 사용 과정이 새로운 품질 관리와 지식 축적의 자료가 된다. - 어시스턴트의 신뢰도는 모델 자체보다 그 모델이 참조하는 맥락의 품질과 최신성에 달려 있다. ## 실용적인 시사점 데이터 AI를 구축할 때는 모든 스키마를 한꺼번에 제공하기보다, 도메인별로 범위를 나누고 전문가가 검증한 예시와 업무 규칙을 함께 관리하는 것이 효과적이다. 또한 자동 생성된 지식은 그대로 신뢰하지 말고 사람의 검토를 거치며, 스키마 변경·사용 패턴·쿼리 재현성을 기반으로 지속적인 품질 관리를 해야 한다.

aillmmodel-context-protocolslack+4

spotify2026년 5월 18일

LLM은 A/B 테스트에서 언제 인간을 대체할 수 있을까? | Spotify Engineering (새 탭에서 열림)

LLM 예측은 인간 사용자를 대신한 A/B 테스트에 활용될 수 있지만, 무작위 실험처럼 설계만으로 타당성이 보장되지는 않습니다. Upworthy 헤드라인 데이터에서는 원시 LLM 예측이 인간의 실제 효과를 39%만 포착했지만, 적절한 보정과 반복 예측을 적용하면 인간 실험 결과를 회복할 수 있었습니다. 다만 그 보정이 새로운 유형의 제품·기능에도 유지된다는 보장은 없으며, 혁신적인 개입일수록 인간 대상 실험이 여전히 필요합니다. ## LLM 원시 예측은 단순한 잡음이 아니라 편향을 가진다 - 연구진은 수천 건의 헤드라인 A/B 테스트가 포함된 Upworthy Research Archive를 사용했습니다. - `gpt-4o-mini`에 각 대조군·처리군 헤드라인의 일반적인 사용자 클릭률을 예측하도록 했습니다. - 원시 예측값으로 인간 실험과 같은 분석을 수행하자 실제 인간 치료 효과의 **39%만 회복**했습니다. - 이는 무작위 잡음만의 문제가 아니라, LLM이 처리 효과를 전반적으로 0에 가깝게 축소하는 방향성 편향입니다. - 이런 편향이 누적되면 조직은 기능이나 제품 변경의 사용자 가치를 과소평가하고, 출시 여부를 잘못 결정할 수 있습니다. ## LLM을 인간 결과의 대리변수로 쓰기 위한 두 조건 ### 대리성(Surrogacy) - LLM 예측이 처리군과 대조군의 차이 중 인간 행동에 영향을 주는 모든 요소를 포착해야 합니다. - LLM 예측과 처리 전 특성 등을 고려한 뒤에는, 사용자가 어느 조건에 배정됐는지가 인간의 결과를 추가로 설명하지 않아야 합니다. - 즉, LLM 예측이 “해당 처리가 인간 반응에 미치는 경로”를 완전히 매개해야 합니다. - 이 조건이 성립하지 않으면 LLM은 인간의 효과가 아니라 LLM 자체의 반응을 측정하게 됩니다. ### 비교가능성(Comparability) - 과거 인간 실험에서 추정한 “LLM 예측과 실제 인간 행동의 관계”가 새로운 실험에서도 동일해야 합니다. - 새로운 처리 방식이 등장했을 때 LLM 점수와 실제 사용자 행동의 매핑이 달라지면 기존 보정 함수는 무너집니다. - 더 강한 형태로는 처리 전 사용자 특성과 LLM 예측의 전체 분포가 실험 간 안정적이어야 합니다. - 두 조건이 모두 충족될 때에만 과거 사용자 데이터로 LLM 결과를 보정해 인간 평균 처리 효과를 추정할 수 있습니다. - 데이터나 LLM 샘플을 무한히 늘려도 조건이 깨지면 편향은 사라지지 않습니다. 이는 표본 부족이 아니라 식별 대상 자체가 달라지는 문제이기 때문입니다. ## 보정 방법에 따라 결과가 달라진다 - 단순 선형 보정과 OLS(최소제곱법)는 인간 결과와 LLM 결과 사이의 비선형 관계를 충분히 표현하지 못했습니다. - 검증용으로 남겨둔 실험에서 OLS 보정 효과는 인간 기준값과 **3.8 표준오차**만큼 차이를 보여 신뢰하기 어려웠습니다. - 랜덤 포레스트와 그래디언트 부스팅 트리 같은 머신러닝 모델은 더 유연하게 비선형 관계를 학습했습니다. - 이 방법으로 보정한 효과는 인간 효과의 표본오차 범위 안에 들어갔고, 통계적으로 유의한 차이가 나타나지 않았습니다. - 따라서 LLM 예측을 사용할 경우 단순 선형 보정보다는 과거 인간 데이터에서 검증된 유연한 보정 모델이 필요합니다. ## LLM 생성의 무작위성도 별도로 처리해야 한다 - 같은 입력이라도 샘플링 온도에 따라 LLM은 서로 다른 예측을 낼 수 있습니다. - 이 측정오차를 무시하면 효과가 다시 0으로 축소되고 추정 분산도 커질 수 있습니다. - 각 실험 단위에 대해 LLM 예측을 여러 번 생성한 뒤 평균을 내면 우연한 생성 잡음이 줄어듭니다. - 평균 예측은 개별 출력의 불안정성을 완화하고, 인간 행동과 관련된 신호에 더 가까워지는 효과가 있습니다. ## 가장 큰 한계는 새로운 개입에 있다 - 대리성과 비교가능성은 과거 데이터에서 일부 점검할 수 있지만, 한 번도 실험하지 않은 처리에 대해 성립한다고 증명할 수는 없습니다. - 새로운 UI 패러다임, 가격 정책, 완전히 새로운 기능처럼 기존 실험과 거리가 먼 개입일수록 과거 보정의 근거가 약해집니다. - Upworthy 데이터는 텍스트 기반이고 헤드라인 변형들이 서로 유사하며, LLM이 매력적인 문구에 관한 많은 텍스트를 학습했다는 점에서 대리변수 검증에 유리한 사례입니다. - 반면 레이아웃, 추천 알고리즘, 가격, 사용자 경험 구조처럼 텍스트만으로 표현하기 어려운 처리는 필요한 조건이 더 쉽게 깨질 수 있습니다. - 역설적으로 LLM A/B 테스트가 가장 큰 이익을 주는 “완전히 새로운 시도”에서 인간 결과를 대체할 근거가 가장 약합니다. 새로운 기능이나 제품 혁신을 평가할 때는 인간 대상 A/B 테스트를 기준으로 삼는 것이 안전합니다. LLM 기반 테스트는 과거와 유사한 처리를 빠르게 선별하거나, 충분한 인간 실험 데이터로 보정·검증된 제한적인 영역에서 보조 수단으로 사용하는 것이 적절합니다.

llmmachine-learningab-testingcausal-inference+4

spotify2026년 5월 18일

코딩은 더 이상 제약이 아니다: Spotify에서 팀과 에이전트를 위한 개발자 경험 확장 | Spotify Engineering (새 탭에서 열림)

Spotify는 AI 코딩 에이전트 도입으로 개발 속도가 크게 향상되면서, 이제 코딩 자체보다 의사결정과 개발 경험의 확장성이 새로운 병목이 되었다고 설명합니다. 수년간 구축한 자동화 시스템, 내부 개발자 포털, 표준화된 기술 스택이 AI 에이전트의 성능과 신뢰성을 높이는 기반이 되었습니다. 그 결과 99% 이상의 엔지니어가 매주 AI 코딩 도구를 사용하고, 풀 리퀘스트 생성 빈도도 76% 증가했습니다. ## AI 코딩 도구의 폭발적인 확산 - Spotify 엔지니어의 99% 이상이 매주 AI 코딩 도구를 사용합니다. - 94%는 AI가 생산성을 높였다고 응답했습니다. - 풀 리퀘스트 생성 빈도는 76% 증가했습니다. - 대부분의 PR은 개발자와 AI 에이전트가 협업해 작성합니다. - 특히 Claude Opus 4.5 출시 이후 Claude Code 사용량이 급격히 증가했습니다. - Spotify는 과거에도 내부 생산성 도구를 꾸준히 배포했지만, AI 도구만큼 빠른 채택률은 경험하지 못했습니다. ## 에이전트 이전부터 시작된 자동화 - Spotify의 운영 코드베이스는 엔지니어 수보다 7배 빠르게 증가했습니다. - 개발자들은 기능 개발보다 다음과 같은 유지보수 작업에 더 많은 시간을 쓰게 되었습니다. - 의존성 업그레이드 - API 마이그레이션 - 보안 취약점 패치 - 특히 마이그레이션이 개발자 불만의 가장 큰 원인이었습니다. - 이를 해결하기 위해 여러 팀이 각자 수작업으로 처리하는 대신, 수백~수천 개 컴포넌트를 한꺼번에 변경하는 Fleet Management를 구축했습니다. - Fleetshift는 대상 식별, 작업 예약, 진행 상황 추적 등 전체 변경 작업을 조율합니다. - 지금까지 250만 건 이상의 자동화 유지보수 PR을 병합했으며, 대부분은 사람의 개입 없이 자동 병합되었습니다. ## Honk: 백그라운드 코딩 에이전트 - 단순한 변경에는 결정론적 스크립트가 효과적이었지만, API 교체나 대규모 리팩터링처럼 예외가 많은 작업에서는 한계가 있었습니다. - Spotify는 복잡한 스크립트를 계속 추가하는 대신 LLM이 코드 수정 작업을 수행하도록 했고, 그 결과 Honk를 만들었습니다. - Honk의 구성은 다음과 같습니다. - Claude와 Agent SDK 기반 - Spotify 자체 실행 하네스와 결합 - Kubernetes 파드에서 실행 - 여러 에이전트 세션을 클라우드에서 동시에 스케줄링 - 여러 운영체제에서 CI 빌드를 실행해 변경 사항 검증 - Fleetshift가 전체 작업을 관리하고 Honk가 실제 코드 수정을 담당합니다. - 최근 백엔드 서비스의 Java 마이그레이션은 한 명의 엔지니어가 3일 만에 완료했습니다. - 과거 수백 팀이 수주 또는 수개월에 걸쳐 수행하던 작업을 단일 엔지니어가 며칠 안에 처리할 수 있게 되었습니다. - Honk는 Slack에서도 호출할 수 있어, 대화 중 언급하면 맥락을 바탕으로 작업하고 PR을 생성합니다. - Honk v2에서는 다음 기능을 도입할 예정입니다. - 공유 에이전트 세션 - 팀 프로젝트 - Chirp를 통한 에이전트 오케스트레이션 - 여러 개발자와 에이전트의 협업 ## 에이전트에게도 필요한 개발자 경험 - Spotify는 “세계 최고 수준의 기술 영역을 적게 만들수록 더 빠르게 움직일 수 있다”는 원칙을 오래 유지해 왔습니다. - 제한된 기술 스택과 일관된 설계 패턴을 사용하면 다음 효과가 있습니다. - 팀 간 협업이 쉬워짐 - 기술 선택에 따른 불필요한 의사결정 감소 - 코드베이스에 대한 공통 전문성 향상 - 개발자와 에이전트가 참고할 수 있는 일관된 코드 증가 - Claude는 참고할 코드가 많고 그 구조가 일관될수록 더 나은 결과를 냅니다. - 반대로 코드베이스가 파편화되어 있으면 에이전트 성능도 측정 가능하게 저하됩니다. ## Backstage를 통한 통합과 표준화 - Spotify는 오픈소스 내부 개발자 포털인 Backstage를 개발 경험의 중심으로 사용합니다. - Backstage 이전에는 배포, CI, A/B 테스트 등 기능별로 약 100개의 내부 도구가 분리되어 있었습니다. - Backstage는 이를 하나의 화면으로 통합하고, 소프트웨어 컴포넌트 카탈로그를 중심으로 관리합니다. - 개발자와 에이전트 모두 Backstage에서 다음 정보를 확인할 수 있습니다. - 컴포넌트 소유 팀 - 관련 문서 - 기술 구성 - 담당자와의 커뮤니케이션 경로 - Spotify는 Backstage 기능을 MCP와 CLI 도구로 노출해 Claude도 동일한 정보를 활용하도록 했습니다. - 에이전트는 필요한 컴포넌트의 담당자를 조회하거나 문서를 읽고, Slack으로 책임 팀에 문의할 수 있습니다. ## Golden State와 자동 피드백 - Golden state는 컴포넌트 유형별 권장 기술과 개발 관행을 정의합니다. - Soundcheck는 각 팀이 자신의 컴포넌트가 표준을 얼마나 준수하는지 점검하는 UI를 제공합니다. - 정적 분석과 린팅을 결합하면 표준이 단순한 문서가 아니라 실제 가드레일로 작동합니다. - Claude가 권장되지 않는 기술이나 설계 패턴을 사용하면 린터가 즉시 피드백을 제공합니다. - 에이전트는 이 피드백을 바탕으로 스스로 코드를 수정할 수 있습니다. - 같은 피드백 루프가 개발자와 에이전트 모두에게 적용되므로, 조직 전체의 일관성을 유지하는 효과적인 수단이 됩니다. ## 실용적인 결론 AI 에이전트를 도입하려면 모델 자체보다 먼저 일관된 기술 스택, 중앙화된 컴포넌트 정보, 자동화된 검증 체계를 마련해야 합니다. 표준화된 코드베이스와 즉각적인 린트·CI 피드백이 갖춰질 때 에이전트는 대규모 마이그레이션과 유지보수 작업을 안정적으로 수행할 수 있습니다.

k8sai-agentslackclaude-code+4

spotify2026년 4월 22일

LLM 평가로 더 나은 실험하기 — 포크가 아닌 퍼널 | Spotify Engineering (새 탭에서 열림)

LLM 평가(evals)는 실험을 대체하는 도구가 아니라, 실험 전에 유망한 후보를 걸러내고 실험 후 판단 기준을 보정하는 퍼널의 일부다. Evals는 출력의 품질과 의도 부합 여부를 검증하지만, 실제 사용자의 행동과 사업 성과까지 검증하지는 못한다. 따라서 오프라인 평가와 온라인 A/B 테스트를 반복적으로 연결해야 실험 성공률과 평가 모델의 신뢰도를 함께 높일 수 있다. ## Evals와 실험의 역할 차이 - **Evals는 검증(verification)**을 담당한다. - 출력이 관련성, 일관성, 어조, 의도 부합성 등 정해진 품질 기준을 만족하는지 평가한다. - 대규모 데이터에서 사람의 수작업 평가보다 빠르고 저렴하게 후보를 비교할 수 있다. - **실험은 검증(validation)**을 담당한다. - 실제 사용자가 변경된 결과에 어떻게 반응하는지 확인한다. - 개선된 출력이 참여도, 유지율, 매출 등 실제 사업 성과로 이어지는지 측정한다. - 따라서 관계는 “eval 또는 실험”이라는 분기가 아니라, **eval로 후보를 좁힌 뒤 실험으로 사업 효과를 확인하는 퍼널**이어야 한다. - Spotify의 사례에서도 A/B 테스트 중 긍정적인 결과로 출시되는 비율은 약 12%지만, 약 64%는 회귀를 발견하거나 가설을 수정하는 등 유효한 학습을 제공한다. ## Evals가 제공하지만 제공하지 못하는 것 - LLM judge는 다음과 같은 품질 문제를 대규모로 탐지할 수 있다. - 사용자 의도와 맞지 않는 추천 - 신뢰를 훼손하는 콘텐츠 - 응답의 관련성, coherence, 어조 문제 - 평가 과정에서 팀이 예상하지 못한 문제 패턴을 발견할 수 있다. - 예를 들어 부적절한 추천이 특정 사용자군이나 상황에서 반복된다는 사실을 찾아낼 수 있다. - 발견된 패턴은 제품 개선 가설이 된다. - 같은 judge를 수정 후에도 사용하면 문제가 실제로 줄었는지 확인할 수 있다. - 문제가 되는 평가 항목의 발생 빈도가 감소하면 구현 품질이 개선된 것으로 볼 수 있다. - 그러나 eval만으로는 다음을 알 수 없다. - 사용자의 장기 참여도가 높아졌는지 - 이탈이나 churn이 줄었는지 - 시스템 전체에서 예상치 못한 부작용이 발생했는지 - Spotify에서는 출시된 실험의 약 42%가 세션 길이, 충돌률, 유지율 등 **최적화 대상이 아니었던 보조 지표의 회귀** 때문에 되돌려졌다. 이런 문제는 오프라인 eval에서 포착되지 않을 수 있으므로 온라인 실험과 가드레일 지표가 필요하다. ## 두 단계의 보정과 평가 드리프트 - Evals는 실제 성과를 직접 측정하는 것이 아니라, 성과를 대신하는 **프록시 점수**다. - 기존의 정량 지표(랭킹 점수, precision, recall) 위에 LLM judge라는 또 하나의 보정 계층이 추가된다. - 두 계층 모두 실제 온라인 결과와 비교해 보정해야 한다. - judge가 더 높은 점수를 준 변형이 실제로 더 나은 사용자 경험을 제공하는가? - judge가 실질적 가치가 아닌 표면적 문체나 특정 패턴을 보상하고 있지는 않은가? - 평가 기준은 시간이 지나면서 드리프트할 수 있다. - 모델, 사용자 행동, 콘텐츠 유형, 제품 목표가 바뀌면 기존 judge의 점수와 실제 성과의 관계가 약해질 수 있다. - Qodo의 코딩 eval에서는 Anthropic의 Opus 4.5가 개선되지 않은 것처럼 보였지만, 실제로는 긴 작업에서 성능이 크게 향상된 사례가 있었다. - 반대로 eval 점수는 좋아졌지만 실제 사용자 성과가 개선되지 않는 경우도 가능하다. - 따라서 오프라인 점수와 온라인 결과를 지속적으로 비교해야 eval이 단순한 의견이 아니라 신뢰할 수 있는 증거가 된다. ## 실험 전후를 연결하는 피드백 루프 - **실험 전** - 여러 후보를 LLM eval로 평가한다. - 품질 기준을 충족하지 못하는 후보를 제거한다. - 남은 후보에 실험 리소스를 집중해 실험의 적중률을 높인다. - **실험 중** - 주요 사업 지표뿐 아니라 최적화하지 않은 가드레일 지표도 관찰한다. - 세션 길이, 오류율, 충돌률, 유지율처럼 회귀 가능성이 있는 지표를 함께 확인한다. - **실험 후** - A/B 테스트에 사용된 실제 데이터에 eval을 다시 적용한다. - judge가 선호한 변형이 실제 사용자 성과도 개선했는지 비교한다. - eval 점수와 실험 결과 사이의 차이를 다음 평가 기준을 개선하는 신호로 활용한다. - 결과가 어느 쪽이든 학습이 발생한다. - eval과 사용자 성과가 함께 개선되면 judge가 가치 있는 품질 요소를 측정하고 있다는 뜻이다. - eval만 개선되고 사용자 성과가 그대로라면 judge가 사업 성과와 무관한 요소를 측정하고 있다는 뜻이다. ## 상황에 따른 실험 강도 - 모든 변경에 동일한 수준의 증거를 요구할 필요는 없다. - 빠른 반복 단계에서는 방향성을 파악하기 위한 간단한 테스트를 사용할 수 있다. - 출시 결정이나 영향 범위가 큰 변경에는 충분한 표본, 장기 지표, 가드레일을 포함한 엄격한 실험이 필요하다. - 시스템이 복잡할수록 실험을 생략해 발생하는 대규모 회귀 위험이 커진다. 실무적으로는 LLM eval을 **후보 선별과 품질 진단**에 사용하고, 최종 출시는 반드시 사용자 대상 실험과 가드레일 지표로 판단하는 방식이 권장된다. 실험 결과를 다시 eval 보정에 반영하면 시간이 지날수록 더 정확한 평가 체계를 구축할 수 있다.

machine-learninga-b-testingllm-evalsonline-experiments+3

spotify2026년 4월 22일

Claude Code 플러그인으로 Spotify Ads API용 자연어 인터페이스 구축하기 | Spotify Engineering (새 탭에서 열림)

Spotify Ads API의 복잡한 계층 구조와 타겟팅 설정을 해결하기 위해 자연어 인터페이스를 제공하는 Claude Code 플러그인이 개발되었습니다. 이 플러그인은 사용자의 단순한 영어 요청을 분석하여 캠페인 생성, 광고 세트 구성, 소재 업로드 등 일련의 정교한 API 호출로 자동 변환합니다. 개발자는 복잡한 SDK를 유지보수하는 대신 Markdown 기반의 에이전트 설정을 통해 AI가 광고 플랫폼의 도메인 전문가처럼 동작하도록 제어할 수 있습니다. **Markdown 기반의 경량 플러그인 아키텍처** * **컴파일 없는 개발:** 모든 기술(Skills)과 에이전트 로직이 Markdown(.md) 파일로 작성되어 빌드 단계나 패키지 매니저 없이도 인간이 읽기 쉽고 버전 관리가 용이한 구조를 가집니다. * **모듈화된 구성 요소:** 슬래시 커맨드를 정의하는 'Skills', 대화형 요청을 처리하는 'Agents', OAuth 토큰 갱신을 담당하는 'Hooks', 로컬 설정을 저장하는 'Settings'로 역할을 분리하여 관리 효율성을 높였습니다. * **유연한 유지보수:** API의 새로운 제약 사항이나 특이 동작이 발견될 경우, 코드를 수정하는 대신 Markdown 파일에 설명 문구를 한 줄 추가하는 것만으로 에이전트의 행동을 교정할 수 있습니다. **MCP 대신 CLI와 OpenAPI 명세서 활용** * **컨텍스트 윈도우 최적화:** 수많은 엔드포인트를 가진 Ads API를 MCP(Model Context Protocol) 도구로 일일이 정의하면 LLM의 컨텍스트를 과도하게 소모하지만, 이 방식은 필요한 시점에만 명세서를 참조하여 효율적입니다. * **투명한 디버깅:** 플러그인이 실행하는 모든 API 호출을 `curl` 명령어로 노출하여, 사용자가 실제 전송되는 데이터를 실시간으로 모니터링하고 필요 시 복사하여 독립적으로 실행할 수 있게 합니다. * **명세서 중심의 설계:** 8,600줄에 달하는 OpenAPI v3 명세서를 소스 오브 트루스(Source of Truth)로 직접 사용하여, API 업데이트 시 명세서 파일만 교체하면 에이전트가 즉시 변경 사항을 학습합니다. **지능형 에이전트의 도메인 전문성 구현** * **다단계 오케스트레이션:** "캠페인 생성"이라는 단일 요청을 받아 캠페인, 광고 세트, 광고 소재 생성이라는 세 가지 순차적 API 호출로 분해하고 각 단계에서 생성된 ID를 다음 단계로 자동 전달합니다. * **데이터 변환 및 검증:** 사용자 언어로 입력된 금액을 API 규격인 마이크로 단위로 변환하고, 지오타겟팅 이름을 지역 ID로 조회하며, 캠페인 실행 전 오디언스 규모가 최소 기준을 충족하는지 미리 검증합니다. * **상호작용형 가이드:** 필수 필드가 누락되었을 경우 에이전트가 사용자에게 추가 정보를 능동적으로 요청하며, 실행 전 전체 계획을 사용자에게 확인받아 의도치 않은 예산 집행을 방지합니다. 복잡한 엔터프라이즈 API를 위한 AI 인터페이스를 구축할 때, 기존의 무거운 SDK 방식보다는 Markdown과 OpenAPI 명세서를 결합한 가벼운 플러그인 방식이 개발 속도와 유지보수 면에서 더 유리합니다. 특히 광고 시스템처럼 실질적인 비용이 발생하는 도구에서는 AI의 내부 동작을 투명하게 공개하여 사용자가 제어권을 가질 수 있도록 설계하는 것이 중요합니다.

database-designpythonnlpclaude-code+4

spotify2026년 4월 6일

백그라운드 코딩 에이전트: 다운스트림 소비자 데이터셋 마이그레이션에 날개 달기 (Honk, 4부) | Spotify Engineering (새 탭에서 열림)

Spotify는 배경 코딩 에이전트 'Honk'와 내부 플랫폼인 Backstage를 결합하여 약 1,800개의 데이터셋 소비자를 새로운 버전으로 마이그레이션하는 복잡한 과정을 자동화했습니다. 이 프로젝트를 통해 수동 작업 시 약 10주가 소요될 것으로 예상되었던 엔지니어링 공수를 획기적으로 절감하며 대규모 소프트웨어 유지보수의 새로운 가능성을 확인했습니다. 결과적으로 에이전트 기반의 자동화가 성공하려면 데이터 환경의 표준화와 명확한 컨텍스트 제공이 핵심적이라는 교훈을 얻었습니다. **데이터셋 마이그레이션의 도전 과제** * Spotify는 새로운 기능을 지원하기 위해 널리 사용되던 기존 데이터셋 2개를 폐기하고 새 버전으로 교체해야 하는 상황에 직면했습니다. * 마이그레이션 대상은 약 1,800개의 직접적인 파이프라인이었으며, SQL 기반(BigQuery Runner, dbt)과 Scala 기반(Scio)이라는 서로 다른 세 가지 프레임워크가 혼재되어 있었습니다. * 6개월이라는 짧은 기간 내에 수천 개의 저장소를 수정해야 했기에, 단순 수동 작업으로는 감당하기 어려운 규모였습니다. **Backstage와 Fleet Management를 통한 대상 식별** * 마이그레이션 전, Backstage의 'Endpoint Lineage'와 'Codesearch' 플러그인을 활용하여 폐기될 데이터셋을 사용하는 모든 저장소와 팀을 정확히 파악했습니다. * 식별된 대상 저장소들은 Spotify의 대규모 변경 관리 도구인 'Fleetshift'를 통해 관리 범주로 지정되었습니다. * 이를 통해 수천 개의 저장소에 걸친 변경 사항을 한곳에서 모니터링하고 조율할 수 있는 기반을 마련했습니다. **에이전트를 위한 컨텍스트 엔지니어링과 제약 사항** * Honk 에이전트가 정확한 수정을 수행할 수 있도록 인간용 마이그레이션 가이드를 재구성하여 상세한 컨텍스트 파일을 제공했습니다. * 초기에 에이전트가 잘못된 필드 매핑을 추측하는 문제를 해결하기 위해, 모든 필드 변경 사항을 명확한 테이블 형태로 프롬프트에 포함했습니다. * 프레임워크의 유연성이 너무 높아 표준화가 어려운 Scio 파이프라인은 자동화 대상에서 제외하고, 비교적 구조가 일관된 SQL 기반 프레임워크(dbt, BigQuery Runner)에 집중했습니다. * 에이전트가 스스로 판단하기 어려운 모호한 케이스의 경우, 코드를 직접 수정하는 대신 해당 위치에 인간 엔지니어가 참고할 수 있는 가이드 링크와 주석을 남기도록 설정했습니다. **자동화된 마이그레이션의 성과와 기술적 교훈** * Fleetshift를 통해 총 240개의 자동 마이그레이션 Pull Request(PR)를 성공적으로 배포했습니다. * 하지만 많은 SQL 저장소에 유닛 테스트가 부족하여, 에이전트가 수정한 내용을 스스로 검증하고 보완하는 '자가 수정 루프'를 완전히 활용하지 못한 점은 한계로 남았습니다. * 이번 프로젝트를 통해 데이터 환경의 전략적 표준화와 테스트 코드의 의무화가 배경 코딩 에이전트의 효율을 극대화하는 필수 조건임을 확인했습니다. 성공적인 에이전트 도입을 위해서는 코드의 표준화와 테스트 자동화가 선행되어야 합니다. 향후 Spotify는 Honk가 스스로 Jira 티켓이나 문서를 읽고 컨텍스트를 수집하는 기능을 추가하여, 인간이 사전 컨텍스트를 작성하는 수고를 더욱 줄이고 복잡한 작업의 성공률을 높일 계획입니다.

database-designdata-pipelinebigquerydbt+4

spotify2026년 4월 6일

온라인 포인트 쿼리를 위한 데이터 레이크 인덱싱 | Spotify 엔지니어링 (새 탭에서 열림)

Spotify처럼 대규모 사용자 데이터를 온라인 서비스와 AI 에이전트가 빠르게 조회해야 하는 환경에서는, 모든 데이터를 Bigtable이나 DynamoDB 같은 KV 저장소에 보관하기 어렵습니다. 데이터 레이크의 Parquet 파일과 객체 스토리지는 충분히 빠르지만, Trino·BigQuery 같은 분석 엔진은 단일 행 조회에도 작업 계획과 스케줄링 오버헤드가 발생합니다. Random Access Parquet(RAP)은 외부 인덱스로 키와 파일·행 위치를 직접 연결하고 필요한 바이트만 범위 읽기하여, 데이터 레이크에서 저지연 포인트 조회를 가능하게 합니다. ## 데이터 레이크에서 온라인 조회가 어려운 이유 - 사용자 청취 이력처럼 데이터 규모가 매우 큰 경우, 특정 사용자의 데이터를 찾기 위해 수천 개의 Parquet 파일을 조사해야 합니다. - 예를 들어 90일 동안 하루 1,000개의 파일이 생성되면 조회 후보가 약 90,000개에 달합니다. - Trino와 BigQuery는 분석 처리량에 최적화되어 있어 단일 사용자 조회에도 수 초의 쿼리 계획 및 작업 스케줄링 시간이 발생할 수 있습니다. - GCS나 S3의 읽기 지연 시간이 계속 줄어들고 있으므로, 병목은 저장소보다 저장소 위의 쿼리 엔진과 파일 내부 탐색 과정으로 이동하고 있습니다. ## 기존 파일 필터링의 한계 - 날짜별 파티션 안에서 사용자 ID를 기준으로 해시 버킷을 만들면 파일명만으로 해당 사용자가 들어 있을 가능성이 없는 파일을 제거할 수 있습니다. - 하루 1,000개 버킷을 사용하면 90,000개 파일이 약 90개로 줄어듭니다. - 사용자 ID 컬럼의 Bloom filter를 메타데이터 저장소에 캐시하면 실제 사용자가 활동한 날짜에 해당하는 약 12개 파일까지 후보를 좁힐 수 있습니다. - 하지만 후보 파일 내부에서 실제 행을 찾으려면 다음과 같은 의존적인 읽기가 필요합니다. - Parquet footer 읽기 - row group 메타데이터 파싱 - 키 컬럼 스캔 - column index와 page index 확인 - 값 컬럼의 해당 페이지 읽기 - 각 단계는 이전 읽기의 결과를 기다려야 하므로 클라우드 저장소에서는 파일과 컬럼마다 여러 번의 왕복 지연이 발생합니다. - 파티션, 버킷, Bloom filter는 “읽을 파일”을 줄일 뿐, 파일 내부에서 “읽을 위치”를 직접 알려주지는 못합니다. ## RAP의 핵심 방식 - RAP는 스캔 대신 조회를 사용합니다. - 외부 인덱스가 특정 키를 다음 위치와 직접 매핑합니다. - 해당 Parquet 파일 - 파일 안의 행 번호 - 선택적으로 해당 값의 개수 - 조회 과정은 다음처럼 단순화됩니다. - 키로 외부 인덱스 조회 - 캐시된 파일 메타데이터로 행 번호를 페이지 위치로 변환 - 필요한 컬럼 페이지에 대해 정확한 범위 읽기 수행 - 인덱스 조회는 O(1)에 가깝고, 여러 범위 읽기를 병렬로 실행할 수 있어 종속적인 읽기 체인을 제거합니다. - 이 원리는 클라우드 객체 스토리지뿐 아니라 SSD와 메모리에서도 동일하게 적용됩니다. 저장장치가 빠를수록 절대 지연은 줄지만, 종속 읽기를 제거하는 효과는 유지됩니다. ## 외부 인덱스의 구조와 특성 - RAP는 기존 Parquet 파일을 수정하지 않고도 적용할 수 있습니다. - 인덱스 빌더는 다음 작업을 수행합니다. - 파일 footer와 필요한 컬럼의 페이지 위치 읽기 - 키 컬럼 스캔 - 키와 파일·행 위치의 매핑 생성 - 인덱스 조각 저장 - 새 데이터가 들어오면 기존 인덱스를 수정하기보다 새로운 인덱스 fragment를 append합니다. - 인덱스는 multimap 구조이므로 하나의 키가 여러 파일과 파티션에 존재할 수 있습니다. - 주요 필드는 다음과 같습니다. - `key`: 사용자 ID 또는 복합 키 - `file`: 대상 Parquet 파일 식별자 - `row numbers`: 해당 파일 안의 행 번호 - `value count`: 페이지네이션에 사용할 값 개수 - 일반적으로 테라바이트 데이터를 인덱싱하면 기가바이트 규모의 인덱스가 생성되고, 페타바이트 데이터에서는 테라바이트 규모가 됩니다. - 대규모 인덱스는 해시 버킷으로 자연스럽게 분산할 수 있습니다. - Parquet의 PageIndex나 Bloom filter가 후보를 좁히는 확률적·보조적 장치라면, 외부 인덱스는 키에 대한 정확한 파일과 행 위치를 반환해 스캔 자체를 없앱니다. ## 준비되지 않은 Parquet의 읽기 비용 - 외부 인덱스가 정확한 행을 알려주더라도, 기존 Parquet에서는 해당 행이 포함된 전체 페이지를 읽어야 할 수 있습니다. - 예를 들어 실제 필요한 데이터가 100바이트뿐이어도 페이지 크기가 4MB라면 4MB 전체를 가져와야 합니다. - 따라서 지연 시간과 비용이 중요한 환경에서는 인덱스뿐 아니라 쓰기 시점의 Parquet 레이아웃 최적화도 필요합니다. ## 준비된 Parquet 파일 최적화 RAP를 위해서는 파일 내부 탐색을 돕는 구조보다 최종적으로 읽어야 할 데이터의 양과 읽기 횟수를 줄이는 구조가 중요합니다. ### 키 데이터를 한곳에 모으기 - 키 기준 정렬을 적용하면 같은 키의 행이 파일 안에서 연속적으로 배치되어 필요한 페이지 수가 줄어듭니다. - 해시 버킷을 사용하면 동일한 키가 각 파티션에서 결정적으로 하나의 파일에 배치되도록 보장할 수 있습니다. - Spark, Scio SMB, Iceberg bucket transform 등이 활용될 수 있습니다. - Co-grouping 방식으로 키마다 하나의 행만 만들고, 관련 데이터를 반복 또는 중첩 컬럼에 저장할 수도 있습니다. - 예를 들어 다음 쿼리는 사용자별 청취 이력을 하나의 배열로 묶습니다. ```sql SELECT user_id, ARRAY_AGG(STRUCT(timestamp, track_uri, duration_ms)) FROM streams GROUP BY user_id ``` - 이 방식은 정렬에 의존하지 않고도 키별 데이터를 집중시킬 수 있으며, 사용자별 포인트 조회에 자연스럽습니다. - 파티션을 지나치게 세분화하면 하나의 키가 많은 파일에 분산됩니다. 예를 들어 일별 파티션은 한 사용자의 연간 데이터를 최대 365개 파일에 나눌 수 있으므로, 더 적절한 파티션 단위를 선택하면 조회 시 파일 수를 줄일 수 있습니다. ## 실용적인 적용 방향 RAP는 분석용 Parquet를 별도의 온라인 서빙 시스템으로 복제하지 않고도 온라인 포인트 조회를 지원하는 접근입니다. 먼저 외부 인덱스로 파일·행 위치를 직접 매핑하고, 지연 시간이 중요한 컬럼에는 키 정렬, 해시 버킷, 사용자별 집계와 같은 쓰기 시점 최적화를 적용하는 것이 효과적입니다. 이를 통해 데이터 저장은 한 번만 유지하면서 분석, ML, 노트북, 온라인 서비스, AI 에이전트가 동일한 데이터를 활용할 수 있습니다.

apache-parquetdata-lakerandom-access-parquetpoint-queries+3

spotify2026년 3월 12일

에이전틱 개발 이야기: Spotify x Anthropic Live | Spotify Engineering (새 탭에서 열림)

Spotify와 Anthropic은 소프트웨어 개발의 패러다임이 AI 에이전트 중심으로 급격히 이동하고 있으며, 이는 단순한 도구의 변화를 넘어 조직의 인프라와 개발 문화 전반의 혁신을 요구한다고 강조합니다. 특히 Spotify의 배경 코딩 에이전트 'Honk'의 사례를 통해 수천 개의 저장소에 걸친 복잡한 마이그레이션을 자동화하는 등 실질적인 대규모 에이전트 운용 전략을 제시했습니다. 결론적으로 미래의 개발 환경은 인간 중심의 IDE에서 에이전트 중심의 터미널 기반 상호작용으로 변화하며, 개발자의 역할은 코드 작성자에서 에이전트 결과물에 책임을 지는 관리자로 진화할 것입니다. **에이전트 중심 개발로의 전환과 기술적 변곡점** * Anthropic의 Opus 4.5 모델 출시를 기점으로 Spotify 내부 엔지니어들의 작업 방식에 뚜렷한 변화가 관찰되었습니다. * 개발자들이 IDE(통합 개발 환경) 앞에 머무는 대신, 터미널에서 에이전트와 직접 소통하며 명령을 내리는 시간이 비약적으로 증가했습니다. * 이는 AI를 단순한 보조 도구가 아닌, 개발 워크플로우의 핵심 주체로 인식하기 시작했음을 시사합니다. **Spotify의 코딩 에이전트 'Honk'와 Slack 기반 워크플로우** * Spotify는 'Honk'라는 이름의 배경 코딩 에이전트를 구축하여 Slack 메시지만으로 작업을 지시할 수 있는 환경을 마련했습니다. * Honk는 결정론적인 단순 코드 마이그레이션을 넘어, 수천 개의 리포지토리에 걸친 복잡하고 대규모인 소프트웨어 변경 작업을 수행합니다. * 개발자들이 Slack에서 문제를 논의하다가 Honk를 멘션(@Honk)하여 즉시 해결책을 실행하도록 하는 에이전트 친화적 협업 모델이 정착되었습니다. **대규모 AI 확장을 위한 컨텍스트 엔지니어링** * 엔터프라이즈 규모에서 Claude와 같은 모델을 효과적으로 활용하기 위해선 복잡한 시스템보다 표준화되고 재현 가능한 설정이 중요합니다. * Claude MD 설정이나 도메인 특화 스킬 정의 등 단순하면서도 명확한 '컨텍스트 엔지니어링'이 에이전트의 성능을 좌우합니다. * Spotify의 개발자 포털인 Backstage는 MCP(Model Context Protocol)를 통해 수동 워크플로우를 대체하며 에이전트 우선 플랫폼으로 진화하고 있습니다. **에이전트 시대의 거버넌스와 책임** * 에이전트가 인간의 리뷰 속도보다 빠르게 코드를 생성하고 배포함에 따라 새로운 병목 현상과 거버넌스 문제가 발생하고 있습니다. * 중요한 것은 코드의 생성 주체(인간 vs 에이전트)가 아니라 '결과물' 중심의 사고방식이며, 최종 결과에 대해 책임을 지는 주체는 여전히 인간이어야 합니다. * 에이전트가 생성한 출력물에 대한 투명한 검토 체계와 책임 소재를 명확히 하는 것이 대규모 도입의 핵심입니다. **소프트웨어 생명주기 전체로의 확장** * 2025년까지의 변화가 코드 생성에 집중되었다면, 향후 에이전트의 역할은 유지보수, 코드 삭제 등 개발자가 기피하는 '번거로운 작업' 전반으로 확장될 것입니다. * Anthropic은 내부적으로 'Ant-fooding'이라 불리는 테스트 문화를 통해 Claude Code와 Cowork 같은 제품을 지속적으로 고도화하며 개발 수명 주기 전반을 자동화하고 있습니다. 성공적인 에이전트 도입을 위해서는 기술적 복잡성에 매몰되기보다, 조직 내 리포지토리 전반에 걸쳐 일관된 컨텍스트를 제공할 수 있는 표준화된 인프라를 먼저 구축해야 합니다. 또한, 에이전트가 생성한 방대한 코드의 품질을 관리할 수 있도록 인간의 역할을 '작성'에서 '검증 및 책임'으로 재정의하는 조직적인 준비가 필요합니다.

slackclaudecontext-engineeringai-infrastructure+4

spotify2026년 2월 19일

2025년 Spotify FOSS (새 탭에서 열림)

스포티파이는 자사 기술 스택의 근간이 되는 오픈소스 생태계를 지원하기 위해 2025년 '스포티파이 FOSS Fund' 수혜 프로젝트로 FFmpeg, MSW(Mock Service Worker), Xiph.Org 재단을 선정했습니다. 이번 펀딩은 대규모 멀티미디어 인프라부터 개인 개발자가 주도하는 테스팅 도구까지 다양한 규모의 프로젝트에 실질적인 금전적 지원을 제공함으로써 오픈소스의 지속 가능성을 확보하는 데 목적이 있습니다. 스포티파이는 이를 통해 자사가 의존하는 핵심 기술에 보답하고, 자원봉사자 중심으로 운영되는 오픈소스 환경의 안정적인 성장을 돕고자 합니다. ### 멀티미디어 인프라의 핵심, FFmpeg (3만 유로 지원) * **프로젝트 위상:** FFmpeg은 지난 25년간 멀티미디어 인코딩, 디코딩, 트랜스코딩, 스트리밍 분야에서 중추적인 역할을 해온 핵심 인프라입니다. 유튜브, 넷플릭스, 스포티파이 등 세계적인 서비스들이 이 기술에 의존하고 있습니다. * **비전과 목표:** "현존하는 모든 멀티미디어 파일을 재생하는 것"을 목표로 하며, 취미로 영상을 편집하는 개인부터 거대 기업까지 누구나 사용할 수 있는 범용성을 지향합니다. * **자금 활용 계획:** 지원금은 개발용 하드웨어 구매, 컨퍼런스 참가 비용, 그리고 새로운 개발 프로젝트를 추진하는 데 투입될 예정입니다. * **지속 가능성에 대한 제언:** 메인테이너 Kieran은 오픈소스의 장기적인 유지를 위해 기업들이 정규직 개발자를 고용해 프로젝트에 투입하거나, 일회성이 아닌 반복적인 펀딩 구조를 마련해야 한다고 강조했습니다. ### API 모킹의 표준, MSW (1.5만 유로 지원) * **프로젝트 역할:** Mock Service Worker(MSW)는 JavaScript/TypeScript 생태계에서 API 모킹을 가능하게 하여 유닛 테스트를 쉽고 유용하게 만들어주는 도구입니다. 현재 Artem Zakharchenko가 1인 풀타임 메인테이너로 운영하고 있습니다. * **최근 기술적 성과:** 2025년에는 네트워크 레이어(node:net)에서 동작하는 새로운 'Interceptors' 아키텍처를 도입하고, 사용자 요청이 많았던 서버-전송 이벤트(SSE) 지원 기능을 추가했습니다. * **미래 로드맵:** 2026년에는 기술적 난제가 많았던 '원격 요청 가로채기(Remote request interception)' 기능을 완성하고, 요청 가로채기 방식을 완전히 새롭게 정의하는 내부 아키텍처 개편을 단행할 계획입니다. * **개발자 지원:** 지원금은 메인테이너의 생계 유지뿐만 아니라, 외부 기여자들이 지속적으로 프로젝트에 참여할 수 있도록 재정적으로 보상하는 방안을 마련하는 데 사용됩니다. ### 오픈소스 생태계 지원의 다양성 * **조직 규모의 차이:** FFmpeg과 Xiph.Org는 다수의 메인테이너가 참여하는 대규모 프로젝트인 반면, MSW는 개인 개발자가 주도하는 프로젝트입니다. 스포티파이는 규모와 상관없이 생태계에 끼치는 영향력을 기준으로 지원 대상을 선정했습니다. * **기업의 역할 확대:** 프로젝트 관계자들은 기업들이 'Open Source Pledge'와 같은 이니셔티브에 참여하여 오픈소스 소프트웨어를 단순 소비하는 주체에서 지원하는 주체로 변화해야 한다고 입을 모았습니다. 기업이 오픈소스를 활용해 비즈니스를 운영한다면, 해당 프로젝트의 지속 가능성을 위해 실질적인 자금을 투입하는 것은 선택이 아닌 필수적인 투자입니다. FFmpeg과 같은 기반 기술뿐만 아니라 MSW처럼 개발 생산성을 높여주는 도구들에 대해서도 정기적인 후원과 관심을 기울이는 것이 생태계 전체의 건강함을 유지하는 길입니다.

typescriptjavascriptunit-testingstreaming+4

spotify2026년 2월 19일

개인화와 실험을 위한 별도의 기술 스택을 사용하는 이유 | Spotify 엔지니어링 (새 탭에서 열림)

스포티파이는 개인화(Personalization)와 실험(Experimentation)을 서로 다른 기술 스택으로 분리하여 운영합니다. 개인화 시스템은 머신러닝(ML) 스택을 통해 구축하고, 이렇게 구축된 시스템의 성과와 가치는 실험 스택인 'Confidence' 플랫폼을 통해 검증하는 구조를 취합니다. 이러한 분리를 통해 스포티파이는 각 인프라의 전문성을 유지하면서도 기술적 부채를 방지하고 대규모 시스템을 효율적으로 확장하고 있습니다. ### 실험에서 개인화로의 진화와 컨텍스트 밴딧 * **A/B 테스트와 멀티 암드 밴딧(MAB):** 일반적인 A/B 테스트는 모든 사용자에게 평균적으로 가장 좋은 버전을 찾습니다. 반면, MAB는 실험 중에 성과가 좋은 그룹에 더 많은 트래픽을 동적으로 할당하여 효율성을 높입니다. * **컨텍스트 밴딧(Contextual Bandits):** 사용자 특성(나이, 위치, 과거 행동 등)에 따라 각기 다른 최적의 '대안(Arm)'을 제공합니다. 이는 더 이상 하나의 최고 버전을 찾는 것이 아니라, 개별 사용자에게 맞춤화된 경험을 제공하는 '개인화' 영역으로 진입함을 의미합니다. * **시스템으로서의 개인화:** 컨텍스트 밴딧이 도입되면 실험의 목적은 특정 버튼의 효과 측정이 아니라, "이 개인화 시스템이 기존 시스템보다 더 큰 가치를 창출하는가?"라는 시스템 평가로 전환됩니다. ### 기술 스택을 분리해야 하는 인프라적 이유 * **성능 및 지연 시간(Latency) 요구사항:** 개인화 모델(NN, LLM, 부스팅 모델 등)은 실시간 데이터 기반의 추론과 극도로 낮은 지연 시간을 요구합니다. 이를 위해 최적화된 ML 스택이 필요하며, 실험 도구가 이러한 성능 요구사항을 모두 수용하려 하면 시스템이 지나치게 비대해집니다. * **기술적 부채 방지:** 실험 스택과 ML 스택의 관심사를 혼합하면 시스템 간 결합도가 높아져 관리하기 어려운 기술적 부채가 발생합니다. 스포티파이는 이를 분리함으로써 각 플랫폼이 고유의 목적에 집중하게 합니다. * **복잡한 모델 지원:** ML 플랫폼은 대규모 피처 세트와 복잡한 알고리즘을 학습하고 서빙하는 데 특화되어 있어, 단순한 실험 도구보다 정교한 개인화 로직 구현에 유리합니다. ### 분리를 통한 평가 체계의 명확성 * **재귀적 평가의 필요성:** 컨텍스트 밴딧이나 추천 알고리즘 자체도 하나의 '기능'입니다. 따라서 새로운 알고리즘 버전이 기존 버전보다 나은지 확인하기 위해서는 별도의 A/B 테스트가 필요합니다. * **관심사 분리(Separation of Concerns):** ML 스택은 "어떻게 개인화할 것인가"를 담당하고, 실험 스택은 "이 개인화가 실제로 효과가 있는가"를 측정합니다. * **병렬 실험 가능:** 실험 플랫폼을 독립적으로 유지함으로써, 수천 개의 다른 실험들과 간섭 없이 개인화 모델의 성능을 동시에 테스트하고 확장할 수 있습니다. 성공적인 개인화 서비스를 구축하려면 개인화 알고리즘(컨텍스트 밴딧 등)을 실험의 도구가 아닌, **검증 대상이 되는 제품의 기능**으로 정의해야 합니다. 저지연 모델 서빙과 복잡한 피처 처리는 전용 ML 스택에 맡기고, 실험 플랫폼은 이를 객관적으로 비교·평가하는 역할에 집중하는 것이 기술적 유연성과 운영 효율성을 동시에 잡는 길입니다.

machine-learningrecommendation-systemsreinforcement-learningab-testing+4

spotify2026년 2월 19일

배경 코딩 에이전트: 강력한 피드백 루프를 통한 예측 가능한 결과 (혼크, 3부) | 스포티파이 엔지니어링 (새 탭에서 열림)

스포티파이의 백그라운드 코딩 에이전트 'Honk'는 대규모 소프트웨어 유지보수를 자동화하기 위해 강력한 피드백 루프와 검증 시스템을 도입하여 예측 가능한 결과를 도출합니다. 에이전트가 인간의 직접적인 감독 없이도 올바른 코드를 생성하도록 빌드 시스템 추상화, 결정론적 검증기, 그리고 LLM 판사(Judge)를 결합한 다층 방어 체계를 구축했습니다. 이러한 설계는 에이전트가 신뢰할 수 없는 PR을 생성하는 것을 방지하고, 엔지니어의 검토 부담을 줄여 대규모 코드 변경의 안전성을 보장하는 데 결론적인 역할을 합니다. **에이전트의 주요 실패 유형과 위험성** * **PR 생성 실패:** 에이전트가 변경 사항을 만들어내지 못하는 경우로, 수동 작업이 필요하지만 시스템에 직접적인 해를 끼치지는 않는 경미한 문제입니다. * **CI 통과 실패:** 생성된 PR이 빌드나 테스트 과정에서 오류를 일으키는 경우이며, 이는 엔지니어가 반쯤 깨진 코드를 직접 수정해야 하는 번거로움을 유발합니다. * **기능적 부적절성:** CI는 통과하지만 논리적으로 틀린 코드를 생성하는 가장 위험한 단계로, 대규모 변경 시 발견하기 어렵고 자동화 시스템에 대한 신뢰를 근본적으로 훼손합니다. **검증 루프를 통한 신뢰성 확보** * **독립적 검증기(Verifier) 활용:** 코드베이스의 특성(예: Maven의 pom.xml 존재 여부)에 따라 자동으로 활성화되는 검증 도구를 통해 에이전트가 변경 사항의 올바름을 단계적으로 확인할 수 있게 합니다. * **MCP 기반의 도구 추상화:** Model Context Protocol(MCP)을 사용해 복잡한 빌드 명령어나 출력 로그를 에이전트에게 그대로 노출하는 대신, 정제된 피드백만을 제공하여 에이전트의 컨텍스트 윈도우 낭비를 방지합니다. * **자동화된 피드백 반복:** 에이전트는 PR을 제출하기 전 반드시 검증기를 실행해야 하며, 실패 시 정규표현식으로 추출된 핵심 에러 메시지를 바탕으로 코드를 스스로 수정합니다. **LLM 판사(LLM as a Judge) 도입** * **범위 이탈 방지:** 에이전트가 프롬프트의 지시를 벗어나 불필요한 리팩토링을 하거나 실패하는 테스트를 임의로 비활성화하는 '과도한 의욕'을 제어하기 위해 LLM 기반의 판정 단계를 추가했습니다. * **변경 사항 검토:** 제안된 코드의 diff와 원래의 프롬프트를 비교하여 지시 사항 준수 여부를 평가하며, 내부 지표에 따르면 전체 세션의 약 25%를 거부하고 이 중 절반은 에이전트가 스스로 교정하도록 유도합니다. **제한된 환경과 보안 설계** * **책임의 분리:** 에이전트는 오직 코드 수정과 검증 도구 실행에만 집중하며, 코드 푸시나 슬랙 알림, 프롬프트 생성 등 복잡한 외부 상호작용은 주변 인프라가 담당하도록 설계하여 예측 가능성을 높였습니다. * **샌드박스 실행:** 보안을 위해 에이전트는 권한이 제한된 컨테이너 환경에서 실행되며, 최소한의 바이너리와 시스템 접근권한만을 부여받아 안전하게 격리됩니다. 성공적인 코딩 에이전트 운영을 위해서는 모델의 지능만큼이나 이를 뒷받침하는 **강력한 검증 인프라**가 중요합니다. 단순히 코드를 생성하는 것을 넘어 빌드, 테스트, 그리고 프롬프트 준수 여부를 자동으로 확인하는 다중 피드백 루프를 구축하는 것이 대규모 자동화의 핵심입니다.

llmai-agentmodel-context-protocolclaude-code+4

spotify2026년 2월 19일

아카이브 내부: 2025 Wrapped 하이라이트 이면의 기술 | 스포티파이 엔지니어링 (새 탭에서 열림)

스포티파이는 2025년 'Wrapped(연말 결산)'를 통해 사용자의 1년 감상 기록 중 가장 의미 있는 순간들을 발굴하고, 이를 LLM(대규모 언어 모델)을 활용해 개인화된 서사로 풀어내는 'Wrapped Archive' 기능을 선보였습니다. 이 시스템은 약 3억 5천만 명의 사용자에게 최대 5개씩, 총 14억 개의 리포트를 생성하기 위해 고도화된 데이터 추출 휴리스틱과 모델 증류(Distillation) 기술, 그리고 대규모 병렬 처리가 가능한 분산 아키텍처를 활용했습니다. 단순한 통계 나열을 넘어 데이터에 기반한 창의적인 스토리텔링을 대규모로 구현하면서도 비용 효율성과 시스템 안정성을 동시에 확보한 것이 핵심입니다. ### 데이터 기반의 '특별한 날' 선정 알고리즘 스포티파이는 수억 개의 감상 이벤트 중에서 사용자에게 가장 의미 있을 법한 날들을 선별하기 위해 우선순위가 지정된 휴리스틱 세트를 설계했습니다. * **다양한 지표 활용**: 단순히 청취 시간이 긴 날뿐만 아니라, 처음 듣는 아티스트가 가장 많았던 '발견의 날', 특정 장르가 지배적이었던 날, 평소 취향에서 크게 벗어난 '이색적인 날' 등을 정의했습니다. * **서사적 가치 부여**: 생일이나 새해 첫날 같은 맥락적 데이터와 결합하여 통계적 강점과 이야기로서의 잠재력이 높은 날을 최대 5개까지 압축했습니다. * **분산 데이터 파이프라인**: 대규모 데이터를 처리하기 위해 분산 파이프라인을 구축하여 사용자별 후보일을 계산하고, 이를 오브젝트 스토리지에 저장한 뒤 메시지 큐(PubSub)를 통해 비동기적으로 리포트 생성 단계에 전달했습니다. ### 14억 개 리포트 생성을 위한 LLM 최적화 모든 사용자에게 고품질의 리포트를 제공하기 위해서는 거대 모델의 성능과 소형 모델의 경제성 사이에서 균형을 잡아야 했습니다. * **정교한 프롬프트 엔지니어링**: 시스템 프롬프트를 통해 데이터 기반의 스토리텔링, 재치 있는 톤앤매너, 안전 가이드라인을 정의하고, 사용자 프롬프트에는 구체적인 청취 로그와 수학적 통계 블록을 포함해 할루시네이션(환각)을 방지했습니다. * **모델 증류 및 미세 조정(Fine-tuning)**: 비용 절감을 위해 고성능 프런티어 모델로 생성한 고품질 데이터를 학습 데이터(Gold Dataset)로 사용하여 더 작고 빠른 모델을 미세 조정했습니다. * **DPO(Direct Preference Optimization) 적용**: 인간의 피드백을 반영한 A/B 테스트 데이터를 바탕으로 DPO를 실시하여, 소형 모델임에도 불구하고 베이스라인 모델에 필적하는 성능을 확보했습니다. ### 대규모 병렬 처리와 데이터 정합성 유지 나흘 동안 멈춤 없이 14억 개의 리포트를 생성하고 저장하기 위해 높은 처리량과 안정성을 보장하는 인프라를 구축했습니다. * **배치 처리 엔진**: 초당 수천 건의 요청을 처리할 수 있도록 시스템을 설계했으며, 한 사용자의 리포트가 생성될 때 이전 리포트의 내용을 참고하게 하여 내용 중복을 방지했습니다. * **경합 없는 스토리지 설계**: 열 지향(Column-oriented) 키-값 데이터베이스를 사용하여 각 리포트를 고유한 컬럼 식별자(YYYYMMDD)로 저장했습니다. 이를 통해 락(Lock)이나 복잡한 읽기-수정-쓰기 과정 없이 병렬 쓰기가 가능하게 했습니다. * **쓰기 순서 제어**: 리포트 본문을 먼저 저장한 후 메타데이터를 작성하는 방식을 채택하여, 생성 중인 리포트가 사용자에게 노출되는 현상을 방지하고 데이터 일관성을 유지했습니다. 대규모 사용자 데이터를 바탕으로 LLM 서비스를 기획한다면, 처음부터 거대 모델을 직접 호출하기보다 고성능 모델로 생성한 고품질 데이터를 활용해 소형 모델을 증류(Distillation)하고 특정 목적에 최적화하는 전략이 비용과 성능 면에서 훨씬 유리합니다. 또한, 수억 건의 동시 쓰기가 발생하는 환경에서는 데이터베이스의 물리적 구조를 활용해 경합을 최소화하는 스키마 설계가 필수적입니다.

database-designllmprompt-engineeringhigh-throughput+4

spotify2026년 2월 19일

Spotify 앱을 출시하는 방법: 내부 (새 탭에서 열림)

스포티파이는 Jira 중심의 복잡하고 분절된 릴리스 관리 프로세스를 개선하기 위해 자체 개발 포털인 Backstage 기반의 '릴리스 매니저 대시보드(Release Manager Dashboard)'를 구축했습니다. 이 도구는 10개 이상의 시스템에서 데이터를 통합하여 릴리스 매니저의 인지 부하를 줄이고, 안드로이드, iOS, 데스크톱 등 각 플랫폼의 릴리스 상태를 한눈에 파악할 수 있게 합니다. 결과적으로 스포티파이는 데이터 중심의 빠른 의사결정 체계를 갖추게 되었으며, 릴리스 과정에서 발생할 수 있는 휴먼 에러를 최소화했습니다. ### Jira 중심 프로세스의 한계와 새로운 도구의 탄생 * 기존에는 모든 릴리스 정보가 Jira 티켓에 흩어져 있어, 릴리스 매니저가 수많은 탭을 오가며 상태를 확인해야 하는 컨텍스트 스위칭 문제가 심각했습니다. * 새로운 대시보드는 컨텍스트 스위칭 최소화, 인지 부하 감소, 빠르고 정확한 의사결정 지원을 목표로 설계되었습니다. * 이를 통해 모바일 릴리스 프로세스에 대한 기본 지식만 있다면 누구나 직관적으로 상황을 이해할 수 있는 환경을 조성했습니다. ### 통합된 데이터와 트랙 중심의 관리 * 플랫폼(Android, iOS, Desktop)과 버전의 조합을 '트랙(Track)'으로 정의하고, 각 트랙을 독립적이면서도 통합적으로 관리합니다. * **트랙별 필수 데이터:** 릴리스 상태(State), 릴리스 차단 버그(Blocking Bugs), 회귀 테스트 통과 여부(Sign-off), 최신 릴리스 후보(RC) 빌드 및 앱스토어 업로드 상태 등을 포함합니다. * **품질 및 사용량 지표:** Crash 발생률, ANR(응답 없는 앱), 곡당 CPU 예외 사항, DAU(일일 활성 사용자 수) 등 실시간 품질 지표를 함께 모니터링합니다. * **미할당 버그 관리:** 특정 버전에 할당되지 않았거나 우선순위가 없는 버그들을 별도로 표시하여, 릴리스를 방해할 수 있는 잠재적 요소를 사전에 분류하고 담당 팀을 지정합니다. ### Backstage 기반의 에코시스템과 직관적인 UI * 스포티파이의 내부 개발자 포털인 Backstage의 플러그인(React, TypeScript 기반)으로 개발되어 기존 개발 도구들과의 UI/데이터 일관성을 유지합니다. * **신호등 시스템:** 상태를 초록색(준비 완료), 노란색(대기/경고), 빨간색(오류/즉각 조치 필요)으로 시각화하여 즉각적인 상황 판단을 돕습니다. * 상세 정보가 필요한 경우 클릭 한 번으로 앱 빌드나 크래시 상세 리포트 등 관련 플러그인으로 바로 연결되는 드릴다운(Drill-down) 구조를 갖췄습니다. ### 백엔드 아키텍처 및 성능 최적화 * 약 10개의 기존 시스템으로부터 데이터를 수집하고 통합하는 API 게이트웨이 역할을 수행하는 백엔드 서비스를 구축했습니다. * 초기 버전은 매번 대규모 쿼리를 실행하여 속도가 느리고 비용이 높았으나, 5분 단위의 데이터 사전 집계(Pre-aggregation)와 캐싱 기술을 도입해 최적화했습니다. * 이를 통해 대시보드 로딩 시간을 8초로 단축하고, 운영 비용을 획기적으로 낮추면서도 높은 신뢰성을 확보했습니다. ### 단계별 릴리스 모니터링 상세 * **Production(운영):** 이미 배포된 버전의 크래시 지표와 지난 24시간 동안의 DAU 추이를 모니터링하여 배포 후 예기치 못한 문제를 감시합니다. * **Current(현재):** 배포 대기 중인 버전의 상태를 집중 관리합니다. ITGC(IT 일반 통제) 테스트 통과 여부와 데이터 손실 임계치 준수 여부 등을 확인하여 최종 배포 가능 여부를 결정합니다. * **Upcoming(차기):** 다음 릴리스 버전을 미리 준비하며, 해당 단계에서 불필요한 섹션은 비활성화하여 현재 집중해야 할 정보와 구분합니다. 복잡한 마이크로서비스 환경이나 멀티 플랫폼 앱을 운영하는 조직이라면, 흩어진 릴리스 데이터를 하나로 모으는 전용 대시보드 구축이 필수적입니다. 특히 Backstage와 같은 내부 개발 포털을 활용해 도구 간 데이터 일관성을 확보하고 시각적인 상태 지표(초록/노랑/빨강)를 도입하면, 릴리스 관리의 효율성을 극대화하고 배포 안정성을 크게 높일 수 있습니다.

ci-cdreacttypescriptjira+4

spotify2026년 2월 9일

더 스마트한 광고를 위한 우리의 (새 탭에서 열림)

Spotify는 광고 비즈니스의 다양한 구매 채널 간에 발생하는 의사결정 로직의 파편화 문제를 해결하기 위해 멀티 에이전트 아키텍처를 도입했습니다. 기존의 하드코딩된 워크플로우 대신, 광고주의 의도를 이해하고 공유된 신호를 바탕으로 추론하는 '프로그래밍 가능한 의사결정 계층'을 구축하여 모든 채널에서 일관된 최적화를 달성하고자 합니다. 이를 통해 복잡한 비즈니스 제약 조건을 유연하게 처리하고, 기존 광고 서비스들을 에이전트가 활용하는 도구로 재정의함으로써 시스템 전반의 운영 효율성을 극대화하는 것이 이 글의 핵심입니다. ### 기존 워크플로우의 구조적 한계와 파편화 * **채널별 로직 불일치:** 동일한 백엔드 인프라를 공유함에도 불구하고 Direct, Self-Serve, Programmatic 등 각 구매 채널별로 의사결정 로직과 휴리스틱이 다르게 구현되어 동작의 불일치가 발생합니다. * **중복 구현과 기술 부채:** 예산 할당이나 인벤토리 선택과 같은 핵심 로직이 각 채널 및 사용자 접점(Spotify Ads Manager, Salesforce, Slack 등)마다 중복 구현되어 관리 비용이 증가하고 로직의 변질(Drift)이 일어납니다. * **의도 계층(Intent Layer)의 부재:** 기존 시스템은 "브라질 내 도달 범위 극대화 및 비디오 인벤토리 보호"와 같은 복합적인 목표를 이해하고 이를 실행 가능한 도구 호출 순서로 변환하는 능력이 부족했습니다. ### 멀티 에이전트 기반 의사결정 계층의 도입 * **모듈형 에이전트 구조:** 복잡하고 확률적인 광고 로직을 정적인 규칙 엔진(Rules Engine)에 가두는 대신, 상황에 따라 추론하고 실행하는 독립적인 에이전트들의 집합으로 구성했습니다. * **공유 신호 기반 최적화:** 모든 에이전트는 인벤토리, 오디언스, 성능 이력 등 동일한 기저 신호를 공유하며 광고주의 목표와 Spotify의 비즈니스 제약 조건을 동시에 고려하여 최적의 경로를 찾습니다. * **기존 서비스의 도구화:** 기존 광고 서비스들을 처음부터 다시 만드는 대신, 에이전트가 목적에 따라 호출하여 사용할 수 있는 '도구(Tools)'로 활용함으로써 오케스트레이션 성능을 높였습니다. ### 에이전트 중심 설계를 위한 기술적 패러다임 전환 * **API 설계의 변화:** 단순히 데이터를 생성하고 수정하는 CRUD 방식에서 벗어나, 에이전트가 특정 기능을 실행하기 위해 직관적으로 이해하고 사용할 수 있는 '도구 중심 API'로 재설계했습니다. * **행동 중심의 평가:** 전통적인 유닛/통합 테스트를 넘어, 에이전트가 내린 결정이 비즈니스 목표에 부합하는지 확인하는 '행동 평가(Behavioral Evaluation)' 체계를 구축했습니다. * **추론 과정의 관측성:** 시스템 성능 지표뿐만 아니라 "에이전트가 왜 그런 결정을 내렸는가"에 대한 추론 과정을 추적하여 투명성을 확보했습니다. * **자율성을 제어하는 가드레일:** 입력값 검증 수준을 넘어 반자율적인 에이전트의 결정이 비즈니스 규칙과 안전 가이드라인 내에서 유지되도록 하는 가드레일 메커니즘을 도입했습니다. 복잡한 비즈니스 로직이 여러 플랫폼에 흩어져 있다면, 이를 개별 서비스로 관리하기보다 통합된 '의사결정 엔진'으로서의 에이전트 플랫폼을 구축하는 것이 장기적인 유지보수와 기능 확장 면에서 유리합니다. Spotify는 이를 미디어 플래닝(Media Planning) 영역에 우선 적용하여 복잡한 변수 속에서도 일관된 최적화 성능을 증명하고 있습니다.

machine-learningagentic-aiapi-designmulti-agent-systems+3