[에이전트 파트 1] Spotify의 백그라운드 코딩 에이전트 — 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 캡처까지 같은 에이전트 인프라