코딩이 더 이상 병목이 아닐 때 어떤 일이 일어날까요? Spotify에서는 내부 개발 플랫폼과 엔지니어링 모범 사례에 대한 장기적인 투자를 바탕으로, 팀과 에이전트 모두가 그 어느 때보다 빠르게 움직일 수 있는 AI 전환을 추진하고 있습니다.
코딩이 병목이 아니게 되면 무슨 일이 일어날까요? Spotify에서는 그 답을 조금씩 알아가기 시작했습니다.
Spotify의 Chief Architect이자 VP of Engineering인 Niklas Gustavsson은 최근 내부 개발 플랫폼과 엔지니어링 모범 사례에 대한 수년간의 투자가 어떻게 우리의 AI 전환을 이끌고 있는지 공유했습니다. 이 투자는 우리 팀과 에이전트 모두가 그 어느 때보다 빠르게 움직일 수 있게 하면서도, 앞으로 닥칠 새로운 과제를 해결할 기반도 제공하고 있습니다. 아래에서 Code with Claude 2026에서 진행한 그의 전체 발표를 확인해 보세요.
Video 3 계속 읽으면서 핵심 내용을 살펴보세요.
Spotify에서 AI 코딩 도구의 도입 속도는 우리가 이전에 본 어떤 것과도 달랐고, 지난해 말 Opus 4.5 출시와 함께 극적으로 가속되었습니다. 오늘날 우리 엔지니어의 99% 이상이 매주 AI 코딩 도구를 사용하고 있으며, 94%는 AI 덕분에 생산성이 더 높아졌다고 답했고, pull request 빈도는 76% 증가했습니다. 그리고 PR의 대다수는 AI 에이전트와 함께 작업하는 개발자가 작성하고 있습니다.
연휴 기간 동안 전반적으로 AI 도구 도입은 잠시 감소했지만, 주황색 급등 구간은 Opus 4.5와 함께 Claude Code 도입이 급상승했음을 보여줍니다.
몇 년 전, 우리는 프로덕션 코드베이스가 엔지니어 수보다 7배 더 빠르게 성장하고 있다는 점을 발견했습니다. 개발자들은 점점 더 많은 시간을 유지보수에 쓰고 있었습니다. 의존성 업그레이드, API 마이그레이션, 취약점 패치에 시간을 쓰느라 기능 개발에 쓰는 시간은 줄어들고 있었습니다. 마이그레이션은 개발자 불만의 가장 큰 원인이었습니다.
수백 개 팀에게 각자의 컴포넌트를 하나씩 수동으로 업데이트하라고 요청하는 대신, 우리는 다른 접근 방식을 상상했습니다. 수백 개, 심지어 수천 개의 소프트웨어 컴포넌트에 한 번에 변경을 적용할 수 있도록 자동화를 사용하면 어떨까? 이 아이디어는 Fleet Management가 되었고, 이를 실행하기 위해 우리가 구축한 기반 시스템의 이름은 Fleetshift입니다. Fleet Management는 이제 Spotify에서 수년간 운영되어 왔습니다. 지금까지 우리는 250만 건이 넘는 자동화된 유지보수 PR을 병합했으며, 그 대다수는 사람의 개입 없이 자동 병합되었습니다.
이 그래프는 Spotify에서 자동화된 PR의 전체 성장 추이를 보여주며, 초록색 구간은 자동 병합된 PR을 나타냅니다.
Fleet Management는 단순한 변경에는 훌륭하게 작동했지만, API 호출 교체나 사용 패턴 리팩터링 같은 복잡한 코드 수정은 우리의 결정론적 스크립트를 한계까지 밀어붙였습니다. 수백만 줄의 코드와 수천 개의 컴포넌트에 걸쳐 스크립트를 실행하면 모든 예외 상황을 마주하게 됩니다.
LLM이 성숙해지면서 우리는 기회를 보았습니다. 점점 더 복잡한 결정론적 스크립트를 작성하는 대신, 코드 수정을 처리하는 데 모델을 사용할 수 있다면 어떨까?
많은 반복 끝에 나온 결과가 바로 Honk, 우리의 백그라운드 코딩 에이전트입니다. 이름은 다소 장난스럽지만, 이 깃털 달린 코딩 친구는 일상 운영의 핵심 요소가 되었습니다. 내부적으로 Honk는 Agent SDK를 사용해 Claude를 실행하며, 우리가 만든 자체 harness 안에 감싸져 Kubernetes pod에 배포되어 클라우드 환경 전반에서 많은 세션을 동시에 스케줄링할 수 있습니다. 또한 신뢰할 수 있는 도구 세트에 접근할 수 있으며, 여기에는 여러 운영체제에서 CI 환경 안에서 빌드를 실행해 자신의 변경이 올바른지 검증하는 기능도 포함됩니다.
Honk는 우리의 Fleet Management 도구에 직접 통합됩니다. Fleetshift는 사람이 오케스트레이션을 관리하도록 돕습니다. 즉, 대상 식별, 변경 스케줄링, 진행 상황 추적을 담당하고, Honk는 그 중간에서 실제 코드 수정을 수행합니다. 마이그레이션을 실행하는 팀은 생성된 PR 수, 병합된 PR 수, 그리고 주의가 필요한 PR이 무엇인지 한눈에 볼 수 있습니다. 최근 우리 백엔드 서비스 전반에서 진행한 Java 마이그레이션은 3일이 걸렸습니다.
개발자들은 역시 개발자답게, 놀랄 만큼 유능하고 자급자족적인 우리의 백그라운드 코딩 에이전트를 활용할 새로운 방법을 빠르게 찾아냈습니다. 이제 Honk는 Slack에서도 사용할 수 있으며, 엔지니어들은 대화 도중 Honk를 멘션할 수 있습니다. 이는 자연스러운 맥락의 원천이 되고, Honk는 날아가 문제를 해결한 뒤 PR과 함께 돌아옵니다.
Goose Farm의 또 다른 평범한 하루: 우리의 내부 실시간 대시보드는 Spotify의 Fleet Management 시스템에서 현재 활동을 보여줍니다. 각 거위는 Honk가 구동하는 활성 백그라운드 코딩 세션 하나를 나타냅니다.
그리고 Honk v2와 함께 우리는 멀티플레이어 협업을 도입하고 있습니다. 공유 에이전트 세션, 팀 프로젝트, 그리고 Chirp를 통한 에이전트 오케스트레이션이 그것입니다. 우리는 에이전트가 터미널 앞의 한 사람뿐 아니라 여러 개발자와 여러 팀과 협업하는 세상을 기대하고 있습니다.
Spotify의 가장 오래된 엔지니어링 원칙 중 하나는 다음과 같습니다. “우리가 세계 최고 수준이어야 하는 기술의 수가 적을수록, 우리는 더 빨리 움직인다.”
이 아이디어는 Spotify에서 AI가 등장하기 훨씬 이전부터 존재해 왔습니다. 집중된 기술 집합으로 표준화함으로써 우리는 더 깊은 전문성을 구축하고, 팀에게 불필요한 의사결정을 줄여 주며, 엔지니어들이 코드베이스 전반에서 훨씬 쉽게 협업할 수 있게 만듭니다. Spotify의 전형적인 백엔드 서비스는 거의 모든 다른 백엔드 서비스와 매우 비슷합니다. 같은 기술 스택, 대체로 유사한 설계 패턴을 사용합니다.
이 원칙은 에이전트에게도 똑같이 중요하다는 것이 밝혀졌습니다. Claude가 참고할 수 있는 다른 코드가 많고 그 코드가 일관되어 있을 때, 성능이 현저히 더 좋아집니다. 우리는 이를 분명히 확인했습니다. 더 파편화된 코드베이스에서는 에이전트 성능이 눈에 띄게 더 나쁩니다.
이 일관성의 출발점은 Backstage입니다. Backstage는 우리의 오픈 소스 internal developer portal (IDP)입니다. Backstage 이전에 Spotify에는 대략 100개에 달하는 서로 다른 내부 도구가 있었습니다. 배포용 도구 하나, CI용 도구 하나, A/B 테스트용 도구 하나 식이었습니다. 이는 파편화되어 있었고 혼란스러웠습니다. Backstage는 이 모든 것을 소프트웨어 컴포넌트 카탈로그를 중심으로 구축된 단일 창으로 통합했습니다. 오늘날 개발자가 우리 컴포넌트 중 하나에 대해 해야 할 일은 무엇이든 Backstage에서 수행합니다.
팀과 에이전트 모두 Backstage Software Catalog에서 어떤 컴포넌트에 대해서든 알고 싶은 모든 것을 찾을 수 있습니다.
그리고 알고 보니 이것은 에이전트에게도 똑같이 유용합니다. 우리는 Backstage의 기능을 MCP와 command-line 도구로 노출하여, Claude가 어떤 컴포넌트의 소유자가 누구인지 조회하고, 문서를 읽고, 혹은 책임 팀에 Slack으로 ping을 보낼 수 있게 합니다.
우리는 또한 Soundcheck와 golden state라고 부르는 것을 통해 표준화를 추진하는 데 Backstage를 사용합니다. Golden state는 각 유형의 컴포넌트에 대해 권장되는 기술과 실천 방식을 정의합니다. Soundcheck는 팀이 자기 컴포넌트를 이러한 표준에 비추어 자체 평가할 수 있는 UI를 제공합니다. 정적 분석과 linting과 결합되면, 이러한 표준은 능동적인 가드레일이 됩니다. Claude가 우리의 코드베이스에서 작업하면서 우리의 인프라에 최적이 아니라고 이미 알고 있는 패턴을 사용하면, lint 시스템으로부터 즉각적인 피드백을 받고 스스로 수정합니다.
이 피드백 루프는 개발자와 에이전트 모두에게 작동하며, 우리가 대규모로 일관성을 끌어올리기 위해 찾은 가장 효과적인 방법 중 하나였습니다.
코딩 속도가 증가함에 따라 제약은 인간의 의사결정 쪽으로 이동합니다. Spotify에는 언제나 구현할 수 있는 역량보다 더 많은 아이디어가 있었지만, 이제는 누구나 우리의 client monorepo에서 Claude를 열고 며칠이 아니라 몇 분 만에 기능 아이디어를 프로토타이핑할 수 있습니다. 심지어 CEO도 이런 방식으로 프로토타입을 만들고 있습니다.
반대급부도 있습니다. 이제 우리는 리뷰해야 할 PR이 76% 더 많습니다. 우리는 어디에 인간의 판단을 적용해야 하는지 배우고 있습니다. 안전한 것은 자동 병합하고, 가장 중요한 곳에 리뷰를 집중하며, 병목이 코딩에서 의사결정으로 이동함에 따라 계획과 우선순위 설정 방식도 다시 생각하고 있습니다.
수년 전에 Fleet Management, Backstage, 그리고 엔지니어링 표준화에 투자한 덕분에 우리는 좋은 위치에 서게 되었습니다. 그리고 다음에 올 일들이 매우 기대됩니다.
Fleetshift와Honk는 Backstage용Spotify Portal의 일부로 제공됩니다. 복잡한 코드 변경을 대규모로 오케스트레이션하는 일이 여러분의 조직과 관련이 있다면, 맞춤형 안내를 위해 우리 플랫폼 팀에문의해 주세요.
