스포티파이가 공개한 AI 코딩 기록 세 편, 에이전트는 파이프라인의 한 칸이었다

스포티파이가 2025년 11월부터 2026년 8월까지 사내 AI 코딩 도구를 어떻게 만들고 굴리는지 세 편의 글로 공개했다. 이 글은 그 세 편을 순서대로 소개한다. 첫 번째는 Spotify Engineering 블로그의 1,500+ PRs Later: Spotify's Journey with Our Background Coding Agent (Honk, Part 1)이고, 두 번째는 같은 블로그의 Coding Is No Longer the Constraint, 세 번째는 Spotify Portal의 What we've learned scaling AI coding agents at Spotify다.

세 편을 묶어 읽으면 한 가지 순서가 보인다. 스포티파이는 에이전트를 먼저 들여온 게 아니라, 2022년부터 쌓아 온 대량 변경 파이프라인의 한 칸을 에이전트로 바꿨다. 그 뒤에 에이전트가 늘어나자 세션과 지식을 관리하는 층을 하나 더 올렸다.

Honk Part 1: 마이그레이션 스크립트 자리에 에이전트를 넣었다

2025년 11월 6일에 나온 첫 글은 Max Charas와 Marc Bruggmann이 썼다. 글은 Fleet Management부터 설명한다. 수천 개 저장소에 같은 변경을 한 번에 적용하는 사내 시스템으로, 2024년 중반 이후 스포티파이 전체 PR의 약 절반을 이 시스템이 자동으로 만들어 왔다고 밝힌다. 다만 변경 하나를 자동화하려면 스크립트를 짜야 했고, 글이 예로 든 Maven 의존성 갱신 스크립트는 2만 줄이 넘었다.

Honk는 그 스크립트 자리를 프롬프트로 바꾼 것이다. 저자들은 대상 저장소 선정, PR 생성, 리뷰 요청, 머지까지의 주변 인프라를 그대로 두고, 코드를 바꾸는 단계만 에이전트에 맡겼다고 설명한다. 에이전트는 빌드와 테스트를 통과한 결과만 PR로 연다. 공개 시점까지 머지된 PR은 1,500건이 넘고, 손으로 짤 때보다 60~90% 시간을 아꼈다는 게 저자들의 계산이다.

글은 미해결 문제도 적었다. 에이전트가 결과를 내기까지 오래 걸리고 출력이 예측하기 어렵다는 점, 그래서 가드레일과 샌드박스가 필요하다는 점을 들었다. 생성된 diff를 LLM으로 다시 판정하는 방법을 언급하지만 판정 기준이나 오탐률은 쓰지 않았다. 저자들은 "아직 모든 답을 갖고 있지 않다"고 썼고, 컨텍스트 엔지니어링과 피드백 루프는 후속편(Part 2, 3)으로 넘겼다.

Coding Is No Longer the Constraint: 병목이 리뷰로 옮겨갔다

2026년 6월 3일 글은 Code with Claude 행사 발표를 정리한 것으로, Chief Architect인 Niklas Gustavsson의 말을 인용한다. 글이 먼저 내놓는 건 도입 수치다. 엔지니어의 99% 이상이 매주 AI 코딩 도구를 쓰고, 94%가 생산성이 올랐다고 답했으며, PR 빈도는 76% 늘었다. Opus 4.5 출시 뒤 사용량이 크게 뛰었다는 그래프도 실려 있다.

그다음 Fleet Management의 누적 성과를 적는다. 자동 유지보수 PR 250만 건 이상을 머지했고, 대부분 사람 개입 없이 자동 머지됐다. Honk는 Fleetshift가 대상 선정과 진행 추적을 맡고 코드 수정만 담당하는 구조이며, 가장 최근 백엔드 Java 마이그레이션은 사흘 걸렸다고 한다. 엔지니어는 Slack 대화 중에 Honk를 호출하고 완성된 PR을 받는다.

개발자 경험이 에이전트에게도 적용된다는 절이 이 글에서 가장 눈에 띈다. 글은 코드베이스가 일관될수록 Claude가 더 잘 작동하고, 조각난 코드베이스에서는 성능이 측정 가능하게 떨어졌다고 적는다. Backstage의 컴포넌트 카탈로그와 "golden state" 표준, 린트가 에이전트에게 즉시 피드백을 주고, 에이전트는 그 피드백으로 스스로 고친다는 설명이다. 약 100개 도구를 Backstage 하나로 합쳐 둔 것이 사람뿐 아니라 에이전트에게도 이득이었다는 게 글의 주장이다.

마지막 절의 제목이 곧 결론이다. 프로토타입이 며칠에서 몇 분으로 줄자, 제약은 코드를 쓰는 속도가 아니라 사람이 판단하고 리뷰하는 속도가 됐다. 늘어난 PR을 감당하려고 안전한 변경은 자동 머지하고 사람의 리뷰는 판단이 필요한 곳에 모은다고 글은 적는다.

Xirp: 에이전트가 늘자 세션과 지식을 관리하는 층이 필요해졌다

2026년 8월 10일 Spotify Portal에 Tyson Singer가 쓴 글은 Honk 이후의 문제를 다룬다. 엔지니어들이 한 세션이 아니라 여러 에이전트를 저장소와 브랜치를 넘나들며 병렬로 돌리기 시작했고, 한 사람이 50개 이상 세션을 굴리는 경우도 나왔다. 그러자 한 세션이 이미 푼 문제를 다른 세션이 다시 찾아 헤매는 낭비가 생겼다.

지식도 흩어져 있었다. 글은 CLAUDE.md 파일, 팀마다 다른 MCP 설정, 개인 프롬프트 모음에 노하우가 갇혀 있었다고 적는다. Xirp는 이 둘을 묶는 도구다. 세션을 한 화면에서 관리하고, 컨텍스트를 특정 에이전트나 하네스에서 떼어내 Claude Code·Codex·Gemini CLI와 자체 호스팅 오픈소스 모델 사이를 작업 중에 옮겨 다닐 수 있게 했다. 팀이 만든 스킬과 설정은 마켓플레이스에서 공유한다.

벤더 중립을 택한 이유로 글은 모델·에이전트·비용이 계속 바뀌는 환경을 든다. 새 모델이 나오면 갈아타고, 작업마다 가격 대비 성능이 좋은 쪽으로 보내겠다는 것이다. 사내에서 36,000 세션을 처리한 뒤 외부에 공개했고, 접근은 xirp.spotify.com에서 받는다. 오픈소스 여부는 글에 없다.

ZDL이 읽는 순서

세 편에서 스포티파이가 직접 말한 사실과 Zero Draft Lab의 해석을 나눠 적는다.

원문이 말한 사실은 이렇다. Fleet Management는 2022년부터 있었고 에이전트 이전에 이미 PR 절반을 자동화했다. Honk는 그 파이프라인의 코드 변경 단계만 대체했다. 코드베이스가 일관될수록 에이전트 성능이 올랐다. PR이 늘자 병목은 리뷰로 옮겨갔다. 에이전트 세션이 늘자 세션·지식 관리 층을 따로 만들었다.

ZDL의 해석은 순서에 있다. 스포티파이의 성과는 에이전트 모델의 성능보다, 에이전트가 들어올 자리를 미리 파 둔 파이프라인과 표준에서 나온 것으로 읽힌다. 도식의 아래 두 층이 없는 조직이 Honk만 따라 만들면, 에이전트가 만든 PR을 어디로 보내고 무엇으로 검증할지부터 다시 정해야 한다. 반대로 CI와 PR 흐름이 이미 있는 조직이라면, 새 시스템을 짓기보다 지금 흐름의 한 칸을 에이전트로 바꾸는 쪽이 이 기록에 가깝다.

둘째 해석은 자동 머지 정책이다. 6월 글은 안전한 변경을 자동 머지한다고만 적고, 무엇을 안전하다고 보는지는 쓰지 않았다. PR 76% 증가를 감당한 건 결국 그 기준이었을 텐데, 기준은 공개되지 않았다. 따라 하려는 조직은 이 빈칸을 스스로 채워야 한다.

주의점

모든 수치는 스포티파이 자체 발표다. 99%, 94%, 76%의 설문 방법과 기간, 60~90% 절감의 계산 근거는 원문에 없다. "12월 이후 엔지니어가 코드를 한 줄도 안 썼다"는 표현은 2차 매체의 요약이며 세 편의 원문에는 없다. Xirp 사용 엔지니어 수로 돌아다니는 1,300명이라는 숫자도 원문에는 "수천 명"으로만 적혀 있어 이 글에서는 쓰지 않았다.

Honk의 후속편 Part 2(컨텍스트 엔지니어링)와 Part 3(피드백 루프)은 이 글에서 다루지 않았다. 판정 기준과 오탐률처럼 Part 1이 비워 둔 내용이 거기에 있을 수 있다.