[에이전트 파트 1] Spotify의 백그라운드 코딩 에이전트 — 1,500개 PR 자동 생성까지의 과정
Spotify가 기존 마이그레이션 인프라의 결정론적 스크립트를 LLM 에이전트로 교체해, 자사 PR의 50%를 자동화하고 1,500개 이상 PR을 머지한 사례.
요약
Spotify가 Fleet Management 인프라(컨테이너 실행 + 자동 PR 생성)의 변환 스크립트를 LLM 에이전트로 교체. 자체 CLI로 MCP 포맷팅·린팅 연결, LLM 기반 diff 평가, MLflow 추적까지 묶어 상호작용·코딩·리뷰 세 에이전트로 분리 운용. Java 값 타입 → record 전환, Scio 메이저 업그레이드, Backstage UI 마이그레이션 등에 적용해 수작업 대비 60~90% 시간 절감, 2024년 중반 이후 PR의 50%가 자동화·1,500건+ 머지.
내용
대규모 코드베이스에서 언어 현대화, 라이브러리 업그레이드, 설정 변경 같은 마이그레이션은 패턴이 반복되지만 수작업이 많이 들어가는 일. Spotify는 이미 Fleet Management라는 사내 인프라를 운영 중 — 컨테이너에서 변환 스크립트를 돌리고 결과를 PR로 자동 생성하는 결정론적 source-to-source 파이프라인. 이 인프라는 컨테이너 격리·PR 생성·리뷰어 자동 지정 같은 주변 단계가 이미 갖춰져 있었던 게 출발점.
문제는 결정론적 스크립트로 표현하기 어려운 변환 — 의미 보존이 필요한 리팩터링, 문맥 의존 코드 수정 — 이 늘어난다는 점. 동시에 사내에는 Slack의 ADR 캡처, 비개발자가 던지는 코드 변경 제안 같은 ad-hoc 작업이 따로 흩어져 있어, 같은 에이전트 인프라를 공유시키면 표준화 효과를 얻을 수 있는 토대가 깔려 있음. 본문은 기성 코딩 에이전트 대신 자체 CLI를 짠 이유와 그 위에 만든 다중 에이전트 구조 설명.
해결 / 접근
Fleet Management 인프라 재활용 — 스크립트만 교체
- 컨테이너 실행, PR 자동 생성, 리뷰 요청 같은 주변 인프라는 그대로 둠
- 변환 단계의 결정론적 스크립트만 프롬프트 기반 LLM 에이전트로 대체
- "스크립트를 프롬프트로 바꾼다"는 갈아끼우기 형태로 도입 비용을 낮춤
자체 CLI를 만든 이유
- MCP로 포맷터·린터 연결 — 변경된 코드를 바로 검증
- LLM을 diff 평가 판사로 사용 — 모델이 자기 출력 또는 다른 모델 출력의 품질을 검증
- 로그·추적을 사내 도구(MLflow 등)로 수집해 디버깅·튜닝
- 기성 에이전트로는 이 통합 유연성을 확보하기 어려움
다중 에이전트 분리
- 상호작용 에이전트: Slack·GitHub에서 작업 정보·요구사항 수집
- 코딩 에이전트: 실제 변경을 만들고 PR 생성
- 리뷰 에이전트: 품질 검증, diff 평가
- 세 에이전트가 같은 인프라 위에서 동작해 마이그레이션과 ad-hoc 작업이 표준 흐름을 공유
실제 적용 사례
- Java 값 타입을 record로 전환
- Scio 데이터 파이프라인 메이저 버전 업그레이드
- Backstage UI 컴포넌트 마이그레이션
- 수작업 대비 60~90% 시간 절감
결과 / 참고
- 2024년 중반 이후 Spotify PR의 50%가 자동화
- 누적 1,500건 이상 PR 머지
- 시리즈: Part 1(개요·구조), Part 2(컨텍스트 엔지니어링 예정), Part 3(피드백 루프 예정)
- 출처: Spotify Engineering 블로그
- 적용 범위: 마이그레이션 + ad-hoc 코드 변경 제안(비개발자 출처 포함)·ADR 캡처까지 같은 에이전트 인프라