Spotify의 백엔드 프로그래밍 AI 에이전트 구현 사례(1,500개 이상의 AI 생성 PR을 성공적으로 병합) 핵심 이슈 및 솔루션 Spotify의 Fleet Management 시스템은 간단한 작업을 자동화하는 데는 탁월하지만, 복잡한 코드 변경은 지속적으로 까다로운 것으로 나타났습니다. 기존 방식은 추상 구문 트리나 정규 표현식을 조작해야 하므로 높은 수준의 전문 지식이 필요합니다. 예를 들어, Maven 종속성 업데이트 스크립트는 2만 줄이 넘는 코드를 사용합니다. 팀의 핵심 아이디어는 Fleet Management의 모든 인프라(대상 저장소 선택, PR 개시, 검토 및 병합 프로세스는 완전히 변경되지 않음)를 유지하면서 결정적 마이그레이션 스크립트를 자연어로 정의된 지능형 에이전트로 대체하는 것입니다. 기술 진화 경로 1단계: 오픈소스 도구 탐색. 팀은 Goose와 Aider와 같은 오픈소스 도구를 시도해 보았지만, 대규모 마이그레이션 시나리오에서 병합 가능한 PR을 안정적으로 생성하는 데 어려움을 겪었습니다. 2단계: 자체 개발 루프. LLM API를 기반으로 "에이전트 루프"를 구축했습니다. 이 루프는 사용자 제공 프롬프트, 에이전트의 파일 편집 및 빌드 피드백 통합, 그리고 테스트 통과 또는 한계 도달 후 완료의 세 단계로 구성됩니다. 이 루프는 소규모 변경에는 적합하지만, 복잡한 다중 파일 변경을 처리할 때는 루프가 부족하거나 맥락을 놓치는 경우가 많습니다. 3단계: 클로드 코드 Claude Code는 약 50건의 마이그레이션과 대부분의 프로덕션 PR에 사용되어 가장 우수한 성능을 보이는 에이전트로 자리매김했습니다. 더욱 자연스러운 작업 중심 프롬프트를 지원하고, 할 일 목록을 관리하며, 하위 에이전트를 효율적으로 생성합니다. 프로젝트의 핵심 원칙 1. 에이전트 특성에 따른 조정 - 자체 개발한 에이전트는 엄격한 단계별 지침에 적합한 반면, 클로드 코드는 최종 상태를 설명하고 자율성을 허용하는 데 더 적합합니다. 2. 전제 조건 정의 – 에이전트는 종종 너무 성급하게 행동합니다. 조치를 취하지 않아야 할 때를 명확하게 정의하는 것이 필요합니다. 3. 구체적인 예를 사용하세요. 몇 가지 구체적인 코드 예만으로도 결과에 큰 영향을 미칠 수 있습니다. 4. 검증 가능한 목표를 정의하세요. 모호한 지침은 피하고 테스트 형태로 제시하는 것이 이상적입니다. 5. 한 번에 하나씩 변경하세요. 여러 변경 사항을 결합하면 맥락이 고갈되거나 부분적인 결과가 나올 가능성이 더 큽니다. 6. 상담원에게 피드백을 요청하세요. 대화가 끝난 후 상담원은 제안의 단점을 지적할 수 있습니다. 도구 및 컨텍스트 관리 Spotify는 예측 가능성을 유지하기 위해 보수적인 툴링 전략을 사용합니다. Spotify 에이전트는 다음에만 액세스할 수 있습니다. • 검증 도구: 포맷팅, 정적 분석 및 테스트를 실행합니다. • 제한된 Git 도구: Git 작업을 표준화하고, 원격 저장소에 대한 푸시 또는 수정을 금지합니다. • 허용 목록에 포함된 Bash 명령: ripgrep 등. 코드 검색이나 문서화 도구를 노출하는 대신, 사용자가 제안에 관련 맥락을 미리 포함하도록 요구합니다. 디자인 철학은 도구가 많을수록 예측 불가능한 차원이 더 커진다는 것입니다. 실제 적용 사례에서 입증된 바와 같이, 이 시스템은 다음을 포함한 복잡한 마이그레이션 작업을 처리했습니다. • 언어 현대화(예: Java 값 유형을 레코드로 마이그레이션) • 파괴적인 변경 사항이 포함된 업그레이드 • UI 구성 요소 마이그레이션 • 프로필 업데이트 이러한 마이그레이션을 통해 60~90%의 시간을 절약할 수 있었습니다. 더 중요한 것은 2024년 중반 이후 Spotify PR의 약 절반이 이 시스템을 통해 자동으로 생성되었다는 것입니다. 마이그레이션 이후 애플리케이션 팀은 MCP 프로토콜을 통해 에이전트를 Slack 및 GitHub Enterprise에 통합합니다. 워크플로는 다음과 같습니다. 대화형 에이전트는 먼저 작업 정보를 수집하고, 프롬프트를 생성한 다음, 실행 및 PR 생성을 위해 코딩 에이전트에게 전달합니다. 이를 통해 엔지니어는 Slack 스레드에서 아키텍처 결정 로그를 수집하거나, 제품 관리자가 로컬 빌드 없이 간단한 변경 사항을 제안할 수 있습니다. 해결해야 할 과제 Spotify 팀은 현재의 한계점을 솔직하게 지적했습니다. • 성능 및 예측 가능성 문제 • 구조화된 힌트/모델 평가 방법 부족 • PR이 실제로 원래 문제를 해결하는지 확인하는 데 어려움 • 힌트를 발전시키기 위해 여전히 주로 직관과 시행착오에 의존 1부: https://t.co/M5pJCeL5Ds 2부:
