Spotify — 스크립트로는 못 하던 전사 코드 마이그레이션을 백그라운드 에이전트에 맡기다

1. 왜 이 사례인가

코딩 에이전트 도입 사례는 대부분 개발자가 IDE 옆에 에이전트를 띄워 두고 대화하며 코드를 짜는 모습입니다. Spotify의 사례는 방향이 다릅니다. 사람이 지켜보지 않는 곳에서 에이전트가 수천 개 저장소를 돌며 코드를 고치고, 그 결과를 풀 리퀘스트(PR)로 올리는 백그라운드 코딩 에이전트입니다. 사내 코드명은 Honk입니다.

Spotify는 2022년부터 Fleet Management라는 사내 프레임워크로 수천 개 저장소에 코드 변경을 한꺼번에 적용해 왔습니다. Spotify 엔지니어링 블로그에 따르면 2024년 중반 이후 Spotify 전체 PR의 절반 정도가 이 시스템에서 자동으로 나옵니다. 다만 변환 규칙을 사람이 결정적 스크립트로 짜야 했기 때문에, 의미를 이해해야 하는 복잡한 마이그레이션은 여전히 손으로 처리해야 했습니다.

Spotify는 2025년 7월 Fleet Management에 Claude Agent SDK를 붙여, 자연어 프롬프트에서 병합된 PR까지 스스로 진행하는 에이전트를 운영하기 시작했습니다. Anthropic 고객 사례는 복잡한 코드 마이그레이션에서 엔지니어링 시간을 최대 90% 줄였고, 에이전트가 만든 PR이 매달 650건 이상 프로덕션에 병합된다고 밝힙니다.

이 사례를 고른 이유는 성과 수치보다 설계 방식에 있습니다. Spotify는 기존 파이프라인(대상 저장소 선정, PR 생성, 리뷰, 병합)을 그대로 두고 변환을 정의하는 한 단계만 에이전트로 바꿨습니다. 그리고 에이전트의 권한을 일부러 좁히고, 에이전트가 내부 동작을 모르는 검증기와 LLM 판정자로 결과를 걸러 냈습니다. 사람이 보지 않는 곳에서 돌아가는 에이전트를 어떻게 신뢰할 수 있게 만드는지 보여 주는 사례입니다.

2. Problem

Spotify의 코드베이스에는 손봐야 할 일이 끊임없이 생깁니다. 언어 버전 현대화, 프레임워크 업그레이드, 의존성 업데이트, 설정 변경이 수천 개 저장소에 걸쳐 계속 필요합니다. Anthropic 고객 사례는 AI 도구가 빠르게 퍼지면서 코드베이스가 이전보다 더 빨리 커지고 있다고 설명합니다.

Spotify는 이 규모를 다루기 위해 사내 개발자 포털 Backstage로 컴포넌트를 만드는 방식을 표준화하고 소유권을 명확히 해 두었습니다. 고객 사례는 이를 “이해하지 못하는 것은 안전하게 자동화할 수 없다”는 말로 요약합니다. 이 기반 위에서 나온 것이 Fleet Management입니다. 소스 코드를 수정하는 작은 코드 조각을 작성해 수천 개 컴포넌트에 적용하고, 변환 작업을 컨테이너 환경의 잡으로 돌린 뒤 대상 저장소에 PR을 자동으로 여는 방식입니다.

Fleet Management는 Maven POM 파일의 의존성 버전 올리기, 배포 매니페스트 같은 설정 파일 수정, 폐기된 메서드 호출 교체처럼 단순한 리팩터링에서 큰 효과를 냈습니다. 문제는 그다음 단계였습니다. 변환 규칙을 추상 구문 트리(AST) 조작이나 정규식으로 짜려면 전문 지식이 필요했습니다. 엔지니어링 블로그가 예로 든 Maven 의존성 자동 업데이트 도구는 핵심 기능이 단순한데도 예외 상황을 처리하다 보니 변환 스크립트가 2만 줄 넘게 불어났습니다. 그래서 자동화할 수 있는 변경은 대부분 단순한 작업에 머물렀고, 전체 코드베이스에 정교한 변환을 적용할 전문성과 시간을 갖춘 팀은 소수였습니다.

맥락을 이해하고 판단을 내려야 하는 의미 수준의 마이그레이션은 여전히 사람 손이 많이 드는 수작업으로 남아 있었습니다. Spotify에 필요했던 것은 코드의 겉 구조가 아니라 의미를 이해해야 하는 변환을 자동화하는 방법이었습니다.

확인된 사실: 수천 개 저장소에 걸친 유지보수 작업, Backstage 기반 표준화·소유권 관리, 2022년 Fleet Management 도입, 2024년 중반 이후 전체 PR의 절반가량이 Fleet Management에서 생성, AST·정규식 스크립트의 전문성 장벽, 2만 줄이 넘는 Maven 의존성 업데이트 스크립트, 복잡한 의미 수준 마이그레이션의 수작업 잔존.

3. Solution

3.1 변환 정의 단계만 에이전트로 바꾸다

Spotify는 2025년 2월부터 Fleet Management 안에서 AI 에이전트를 쓰는 방법을 조사했습니다. 목표는 엔지니어가 자연어로 전사 변경을 정의하고 실행하게 돕는 것이었습니다. 가장 먼저 손댄 곳은 지원이 가장 필요했던 부분, 즉 코드 변환 자체를 정의하는 단계였습니다. 결정적 마이그레이션 스크립트 자리에 프롬프트로 지시를 받는 에이전트를 넣었고, 대상 저장소 선정, PR 생성, 리뷰, 프로덕션 병합으로 이어지는 나머지 Fleet Management 인프라는 그대로 두었습니다.

2025년 7월에는 Claude Agent SDK를 Fleet Management에 통합해, 자연어 프롬프트부터 병합된 PR까지 스스로 진행하는 백그라운드 코딩 에이전트로 운영하기 시작했습니다. 두 출처가 든 대표 작업은 다음과 같습니다.

Java의 AutoValue 클래스나 값 타입을 Record로 바꾸는 언어 현대화
Scio 데이터 파이프라인 최신 버전 이전처럼 호환성이 깨지는 업그레이드
Backstage의 새 프런트엔드 시스템으로 옮기는 UI 컴포넌트 이전
스키마와 형식을 지키면서 YAML·JSON 파라미터를 고치는 설정 변경

3.2 에이전트를 감싸는 사내 CLI

Spotify는 기성 코딩 에이전트를 그대로 쓰지 않고 작은 사내 CLI를 만들었습니다. 이 CLI는 프롬프트 실행을 에이전트에 맡기고, 로컬 MCP(Model Context Protocol)로 사내 포매팅·린트 작업을 돌리며, LLM 판정자로 변경 diff를 평가하고, 로그를 Google Cloud Platform(GCP)에 올리며, 실행 기록(trace)을 MLflow에 남깁니다. 엔지니어링 블로그는 이 CLI 덕분에 에이전트와 LLM을 자유롭게 바꿔 끼울 수 있었고, 실제로 여러 번 교체했다고 설명합니다.

모델은 Claude를 택했습니다. Spotify 수석 아키텍트 겸 엔지니어링 VP인 Niklas Gustavsson은 고객 사례에서 대규모 코드 변환 작업 시 Claude가 꾸준히 가장 좋은 성능을 보여 지난 6개월 동안 기본 모델로 써 왔으며, 새 기본 모델로 Sonnet 4.5를 채택했다고 밝혔습니다. 팀이 Claude Code를 고른 이유로는 프롬프트를 작성하기 쉽고, 코드베이스를 잘 탐색하며, 기존 인프라에 붙이기 쉽다는 점을 들었습니다. 또한 Claude Code의 hooks 기능으로 에이전트 실행 전후에 결정적 동작을 넣어 기존 워크플로에 맞출 수 있었습니다.

3.3 두 가지 진입점: Git의 프롬프트와 Slack

대규모 마이그레이션에서는 프롬프트를 Git으로 버전 관리합니다. 사내 오케스트레이션이 이 프롬프트로 Claude Code 에이전트를 실행해 여러 저장소에 변환을 적용합니다. 개별 작업에서는 엔지니어가 사내 Slack 봇에 요청하면 에이전트가 백그라운드에서 작업을 시작합니다.

엔지니어링 블로그에 따르면 백그라운드 에이전트를 MCP로 노출해 Slack과 GitHub Enterprise 양쪽에서 작업을 걸 수 있게 했습니다. 사용자는 먼저 대화형 에이전트와 이야기하며 작업에 필요한 정보를 모으고, 그 결과로 만들어진 프롬프트가 코딩 에이전트에 넘어가 PR이 됩니다. Slack 스레드의 논의를 아키텍처 결정 기록(ADR)으로 남기거나, 제품 관리자가 저장소를 직접 내려받아 빌드하지 않고도 간단한 변경을 제안하는 방식으로 쓰이고 있습니다. 마이그레이션과 개별 작업이 같은 에이전트를 쓰기 때문에, 에이전트 설정이나 도구를 개선하면 모든 PR에 함께 반영됩니다. 커밋 태깅, LLM 사용량 관리, 실행 기록 수집도 한 방식으로 통일됩니다.

3.4 에이전트가 모르는 검증기와 LLM 판정자

엔지니어링 블로그 3편은 사람이 감독하지 않는 에이전트가 실패하는 방식을 세 가지로 나눕니다. PR을 아예 만들지 못하는 경우는 사소한 불편이고, PR이 CI에서 실패하는 경우는 엔지니어를 지치게 합니다. 가장 심각한 것은 CI는 통과했지만 기능적으로 틀린 PR입니다. 수천 개 컴포넌트에 걸친 변경이라 리뷰에서 잡아내기 어렵고, 병합되면 프로덕션 기능을 깨뜨릴 수 있기 때문입니다. 테스트 커버리지가 낮은 컴포넌트, 프롬프트 범위를 넘어 “창의적으로” 손대는 에이전트, 빌드와 테스트를 제대로 돌리지 못하는 에이전트가 원인으로 꼽힙니다.

Spotify는 이를 검증 루프로 풀었습니다. 검증기는 서로 독립적이며, 컴포넌트 내용에 따라 자동으로 켜집니다. 예를 들어 저장소 루트에 pom.xml이 있으면 Maven 검증기가 켜집니다. 에이전트는 MCP 도구로 검증을 호출할 수 있을 뿐, 검증기가 무엇을 어떻게 하는지는 알지 못합니다. 빌드 시스템 호출이나 테스트 결과 해석 같은 잡음을 검증기가 대신 처리하기 때문에 에이전트의 컨텍스트 창도 아낄 수 있습니다. 검증기 상당수는 정규식으로 실패 시 꼭 필요한 오류 메시지만 뽑아내고, 성공 시에는 아주 짧은 메시지만 돌려줍니다. PR을 열기 전에는 Claude Code의 stop hook으로 관련 검증기를 모두 돌리고, 하나라도 실패하면 PR을 열지 않고 사용자에게 오류를 보여 줍니다.

그 위에 LLM 판정자를 한 겹 더 두었습니다. 일부 에이전트가 코드를 리팩터링하거나 불안정한 테스트를 꺼 버리는 등 프롬프트에 없는 문제까지 풀려고 시도했기 때문입니다. 판정자는 제안된 변경의 diff와 원래 프롬프트를 LLM에 보내 평가하며, 다른 검증기가 모두 끝난 뒤에 실행됩니다. 수천 건의 에이전트 세션 가운데 판정자가 약 4분의 1을 거부했고, 거부된 경우 에이전트가 절반은 스스로 방향을 바로잡았습니다. 가장 흔한 거부 사유는 프롬프트 지시 범위를 벗어난 변경이었습니다.

에이전트 자체의 권한은 의도적으로 좁혔습니다. 에이전트는 관련 코드베이스를 확인하고, 파일을 고치는 도구와 검증기만 쓸 수 있습니다. 코드 푸시, Slack에서 사용자와 대화하기, 프롬프트 작성은 모두 바깥 인프라가 맡습니다. 에이전트는 권한이 제한되고 실행 파일이 거의 없으며 주변 시스템에 사실상 접근할 수 없는 컨테이너 안에서 돌아갑니다. Spotify는 유연성을 줄인 만큼 에이전트가 더 예측 가능해지고 보안에도 도움이 된다고 설명합니다.

확인된 사실: 2025년 2월 조사 시작, 2025년 7월 Claude Agent SDK 통합, 변환 정의 단계만 교체하고 나머지 파이프라인 유지, 에이전트·LLM을 바꿔 끼울 수 있는 사내 CLI(로컬 MCP 린트, LLM 판정, GCP 로그, MLflow 기록), Sonnet 4.5 기본 모델 채택, Git 버전 관리 프롬프트와 Slack 봇 진입점, MCP를 통한 Slack·GitHub Enterprise 연동, 세 가지 실패 유형, 자동 활성화 검증기와 stop hook 게이트, 판정자의 약 4분의 1 거부와 그중 절반의 자체 수정, 권한을 좁힌 샌드박스 컨테이너.

4. Impact

두 출처가 서로 다른 시점에 발표한 수치입니다.

지표	수치	출처·기준
복잡한 코드 마이그레이션의 엔지니어링 시간 절감	최대 90%	Anthropic 고객 사례 (게시일 미표기)
프로덕션에 병합된 에이전트 생성 PR	매달 650건 이상	Anthropic 고객 사례
병합된 AI 생성 PR 누적	1,500건 이상	Spotify Engineering, 2025-11-06
해당 마이그레이션의 수작업 대비 총 시간 절감	60~90%	Spotify Engineering, 2025-11-06
LLM 판정자의 세션 거부 비율	약 4분의 1 (그중 절반은 에이전트가 자체 수정)	Spotify Engineering, 2025-12-09

고객 사례에 따르면 수백 명의 엔지니어가 이 백그라운드 에이전트를 쓰고 있습니다. 플랫폼 팀은 이전에는 비용과 복잡도 때문에 엄두를 내지 못하던 프로젝트도 맡기 시작했습니다. 대표적인 예가 사내 모든 Java gRPC 서비스에 명시적 컨텍스트 전파를 강제하는 기술 표준화 작업입니다. 서비스마다 몇 시간씩 걸리고 gRPC를 깊이 알아야 하는, 호환성이 깨지는 변경인데, 지금은 구현의 대부분을 Claude가 자동으로 처리하고 엔지니어는 검토만 합니다.

Spotify 선임 스태프 엔지니어 Max Charas는 고객 사례에서 엔지니어들이 이전에는 불가능했던 속도로 전사 마이그레이션을 실행하고 있다고 말했습니다. 팀은 앞으로의 과제가 도구 자체보다 엔지니어가 좋은 프롬프트를 작성하는 역량을 기르는 데 있다고 보고 있습니다. 다음 단계로는 CI 인프라와의 더 깊은 통합, macOS·iOS 코드베이스로의 확장을 계획하고 있습니다.

확인된 사실: 위 표의 수치와 각 출처·기준일, 수백 명의 엔지니어 사용, Java gRPC 컨텍스트 전파 표준화 사례, CI 통합과 macOS·iOS 확장 계획. 고객 사례의 90%는 “최대” 수치이고, 엔지니어링 블로그의 60~90%는 블로그가 다룬 마이그레이션들에 대한 수치입니다.

5. Insight

에이전트는 부품 하나로 넣고, 파이프라인은 그대로 둡니다. Spotify는 대상 선정, PR 생성, 리뷰, 병합이라는 검증된 흐름을 바꾸지 않고 변환을 정의하는 단계만 에이전트로 교체했습니다. 엔지니어 입장에서는 PR이 들어오는 경로와 리뷰 방식이 그대로 유지되므로, 새 도구를 받아들이는 부담이 적습니다. 에이전트를 바꿔 끼울 수 있는 사내 CLI도 같은 접근 방식입니다. 모델이 빠르게 바뀌는 환경에서 교체 비용을 미리 낮춰 둔 셈입니다.

에이전트의 자유를 줄일수록 결과를 예측하기 쉬워집니다. 에이전트는 코드를 고치고 검증하는 작업만 맡고, 푸시·대화·프롬프트 작성은 바깥 인프라가 처리합니다. 사람이 지켜보지 않는 에이전트에게는 넓은 자율성보다 좁고 명확한 역할이 더 잘 맞는다는 판단입니다. 보안 측면에서도 이러한 선택이 안전합니다.

가장 위험한 실패는 CI를 통과한 틀린 PR입니다. 빌드와 테스트는 문법과 기존 동작을 확인할 뿐, 에이전트가 프롬프트 범위를 넘었는지는 잡아내지 못합니다. Spotify가 결정적 검증기 뒤에 diff와 프롬프트를 비교하는 판정자를 둔 이유가 여기에 있으며, 실제로 판정자가 거부한 사유 중 가장 흔한 것도 범위 이탈이었습니다.

검증기는 에이전트에게 감출수록 좋습니다. 에이전트는 “검증하라”는 도구만 호출할 뿐, 어떤 빌드 시스템을 어떻게 돌리는지는 알 필요가 없습니다. 검증기가 오류를 추려 간결하게 전달하므로 에이전트의 컨텍스트가 불필요한 잡음으로 채워지지 않습니다.

복제 조건과 한계. 이 방식은 Backstage로 표준화된 컴포넌트와 명확한 소유권, 2022년부터 쌓아 온 Fleet Management 인프라가 마련되어 있었기에 가능했습니다. 테스트 커버리지가 낮은 컴포넌트에서는 검증 루프의 효과가 떨어집니다. 검증기는 아직 Linux x86에서만 돌아가기 때문에 macOS가 필요한 iOS 앱이나 ARM64 기반 시스템에는 바로 적용할 수 없고, 판정자에 대한 체계적인 평가(eval)도 아직 없다고 Spotify는 밝힙니다. 고객 사례의 수치는 Anthropic이 게시한 자료이며 외부 검증을 거친 값은 아닙니다.

한 줄 요약: 사람 없이 돌아가는 코딩 에이전트는 권한을 좁히고, 에이전트가 모르는 검증기와 범위를 따지는 판정자를 거친 결과만 PR로 내보낼 때 수천 개 저장소 규모에서도 믿을 수 있게 됩니다.

6. 원문에 없는 추정 (구현 가설)

6.1 Git으로 관리하는 프롬프트의 단계적 적용

근거: 고객 사례는 대규모 마이그레이션의 프롬프트를 Git으로 버전 관리하고 사내 오케스트레이션이 여러 저장소에 에이전트를 실행한다고 설명합니다. 엔지니어링 블로그는 대상 저장소 선정부터 병합까지의 Fleet Management 인프라가 그대로 유지되며, 자동 변경의 투자 대비 효과가 적용 범위를 넓힐수록 커진다고 말합니다.

하나의 마이그레이션은 Git 저장소 안의 프롬프트 파일과 대상 컴포넌트 선택 조건을 묶은 설정 단위로 관리되었을 가능성이 높습니다. 대상 선택은 Backstage의 컴포넌트 메타데이터(언어, 빌드 시스템, 소유 팀)를 조회하는 방식으로 이뤄졌을 것입니다. 수천 개 저장소에 한 번에 PR을 뿌리면 잘못된 프롬프트 하나가 리뷰 부담을 한꺼번에 키우기 때문에, 먼저 소수의 저장소에 적용해 CI 통과율, 판정자 거부 비율, 병합률을 확인한 뒤 대상을 넓히는 단계적 적용을 택했을 것으로 보입니다. 결과가 나쁘면 프롬프트를 고친 새 커밋으로 다음 단계를 돌리고, 각 PR에는 어떤 프롬프트 버전에서 나왔는지 태그를 붙여 두었을 것입니다. 엔지니어링 블로그가 커밋 태깅 방식을 통일했다고 언급한 점을 보면, 이 태그로 프롬프트 버전별 성과를 추적하고 문제가 생긴 버전의 PR만 골라 닫는 운영이 가능했을 것으로 추정됩니다.

6.2 Slack 대화를 실행 가능한 프롬프트로 바꾸는 접수 단계

근거: 엔지니어링 블로그는 사용자가 먼저 대화형 에이전트와 이야기하며 작업 정보를 모으고, 그 결과로 만들어진 프롬프트가 코딩 에이전트에 넘어간다고 설명합니다. 또 프롬프트 작성과 Slack 대화는 코딩 에이전트가 아니라 바깥 인프라가 맡으며, 판정자가 거부하는 가장 흔한 사유는 프롬프트 범위를 벗어난 변경이라고 밝힙니다.

접수를 맡은 대화형 에이전트는 Slack 스레드의 요청을 받아, 코딩 에이전트가 사람 없이 끝까지 갈 수 있을 만큼 구체적인 프롬프트가 될 때까지 되물었을 것입니다. 대상 저장소는 Backstage 소유권 정보로 확인하고, 바꿀 범위와 바꾸면 안 되는 범위, 완료 조건을 프롬프트의 정해진 항목으로 채웠을 가능성이 높습니다. 범위를 프롬프트에 분명히 적어 두면 코딩 에이전트의 범위 이탈이 줄고, 판정자도 diff와 비교할 기준이 뚜렷해집니다. 완성된 프롬프트는 요청자의 확인을 거쳐 코딩 에이전트에 넘어가고, 생성된 PR 링크는 원래 Slack 스레드에 다시 달려 요청자가 곧바로 리뷰어가 되는 흐름이었을 것입니다. 팀별 LLM 사용량 관리도 이 접수 단계에서 요청자와 소속 팀을 기준으로 이뤄졌을 것으로 보입니다.

6.3 판정자 거부 뒤의 재시도와 에스컬레이션

근거: 엔지니어링 블로그는 판정자가 약 4분의 1의 세션을 거부하고 그중 절반은 에이전트가 스스로 방향을 바로잡는다고 밝힙니다. 검증기가 실패하면 PR을 열지 않고 사용자에게 오류를 보여 주며, PR을 만들지 못하는 실패는 수작업으로 처리하면 되는 사소한 문제로 봅니다. 실행 로그는 GCP에, 실행 기록은 MLflow에 남깁니다.

판정자가 거부하면 거부 사유가 같은 세션의 에이전트에게 피드백으로 되돌아가고, 에이전트는 범위를 벗어난 변경을 되돌린 뒤 다시 검증 루프를 거쳤을 것입니다. 무한히 반복하지 않도록 재시도 횟수에는 상한을 두고, 상한을 넘기면 PR을 열지 않은 채 세션을 끝냈을 가능성이 높습니다. 이때 요청자나 마이그레이션 담당자에게는 거부 사유와 함께 GCP 로그와 MLflow 실행 기록 링크가 전달되어, 사람이 이어서 고칠지 대상에서 뺄지를 판단했을 것입니다. 전사 마이그레이션에서는 반복해서 실패하는 저장소를 수작업 목록으로 따로 모으고, 프롬프트 버전별 거부 사유를 모아 다음 프롬프트 수정에 반영하는 식으로 6.1의 단계적 적용과 맞물려 돌아갔을 것으로 추정됩니다.

7. 출처

Claude by Anthropic — Spotify cuts migration time by 90% with Claude Agent SDK
https://claude.com/customers/spotify
게시일: 페이지 미표기 (큐 기록 2026-02), 확인일 2026-09-23
Spotify Engineering — 1,500+ PRs Later: Spotify’s Journey with Our Background Coding Agent (Honk, Part 1)
https://engineering.atspotify.com/2025/11/spotifys-background-coding-agent-part-1
발행일: 2025-11-06 (Max Charas, Marc Bruggmann)
Spotify Engineering — Background Coding Agents: Predictable Results Through Strong Feedback Loops (Honk, Part 3)
https://engineering.atspotify.com/2025/12/feedback-loops-background-coding-agents-part-3
발행일: 2025-12-09 (Max Charas, Marc Bruggmann)