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 피드백이 갖춰질 때 에이전트는 대규모 마이그레이션과 유지보수 작업을 안정적으로 수행할 수 있습니다.

backstagek8sai-agentslack+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 티켓이나 문서를 읽고 컨텍스트를 수집하는 기능을 추가하여, 인간이 사전 컨텍스트를 작성하는 수고를 더욱 줄이고 복잡한 작업의 성공률을 높일 계획입니다.

backstagedatabase-designdata-pipelinebigquery+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와 같은 내부 개발 포털을 활용해 도구 간 데이터 일관성을 확보하고 시각적인 상태 지표(초록/노랑/빨강)를 도입하면, 릴리스 관리의 효율성을 극대화하고 배포 안정성을 크게 높일 수 있습니다.

backstageci-cdreacttypescript+4