코딩은 더 이상 병목이 아니다, Spotify의 코딩 에이전트 Honk (feat. Code with Claude 2026)

9bow · 6월 17, 2026, 10:30오후

Spotify의 AI 전환 소개

코딩이 더 이상 소프트웨어 개발의 병목(bottleneck)이 아니게 된다면 무슨 일이 벌어질까요? Spotify의 엔지니어링 조직은 지금 그 질문에 대한 답을 실제로 마주하고 있습니다. Spotify의 수석 아키텍트이자 엔지니어링 부사장인 니클라스 구스타브손(Niklas Gustavsson)은 Code with Claude 2026 행사에서, 수년간 쌓아온 내부 개발 플랫폼과 엔지니어링 모범 사례에 대한 투자가 어떻게 회사의 AI 전환을 이끌고 있는지를 발표했습니다. 이 글은 그 발표의 핵심을 정리하고, 한국의 개발자 관점에서 의미를 덧붙인 것입니다.

이 이야기가 흥미로운 이유는 단순히 "우리도 AI 코딩 도구를 도입했다"는 사례 보고가 아니기 때문입니다. Spotify가 강조하는 핵심 메시지는, AI 에이전트가 폭발적으로 유용해진 지금의 변화가 하루아침에 도구 하나를 깔아서 얻어진 것이 아니라, 에이전트가 본격화되기 훨씬 전부터 진행해 온 코드베이스 표준화와 플랫폼 통합 투자 위에서 비로소 가능해졌다는 점입니다. 즉, "에이전트를 잘 쓰는 조직"이 되는 일은 모델을 고르는 문제가 아니라 개발자 경험(Developer Experience, DevEx) 을 어떻게 설계해 왔는가의 문제라는 것입니다.

이 글에서는 Spotify의 AI 도입 속도가 어떻게 "완전히 미쳐버렸는지", 에이전트 시대 이전부터 운영해 온 대규모 자동화 시스템인 플릿 관리(Fleet Management), 그 위에서 태어난 백그라운드 코딩 에이전트 Honk, 그리고 이 모든 것을 떠받치는 내부 개발자 포털 Backstage가 어떻게 사람과 에이전트 모두를 위한 일관된 환경을 만들어 내는지를 차례로 살펴봅니다. 마지막으로 코딩이 병목에서 벗어난 뒤 진짜 제약(constraint)이 어디로 이동했는지에 대한 Spotify의 통찰을 정리합니다.

"완전히 미쳐버렸다"고 표현한 도입 속도

Spotify에서 AI 코딩 도구의 도입 속도는 이전에 사내에서 경험한 그 어떤 도구와도 달랐습니다. 특히 작년 말 Claude Opus 4.5 출시와 함께 그 곡선이 극적으로 가팔라졌습니다. 오늘날 Spotify 엔지니어의 99% 이상이 매주 AI 코딩 도구를 사용하고, **94%**가 AI 덕분에 생산성이 높아졌다고 응답하며, 풀 리퀘스트(Pull Request) 빈도는 76% 증가했습니다. 그리고 이렇게 늘어난 PR의 대부분은 개발자가 AI 에이전트와 나란히 협업하며 작성한 것입니다.

위 그래프에서 보이듯 연말 휴가 시즌에는 업계 전반적으로 AI 도구 사용이 잠시 주춤했지만, 주황색으로 표시된 Claude Code 도입 곡선은 Opus 4.5와 함께 그야말로 수직 상승했습니다. 구스타브손은 이 현상을 다음과 같이 표현합니다.

"우리는 개발자의 생산성을 높이기 위해 늘 사내에 도구를 배포해 왔지만, AI 코딩 도구를 배포하면서 본 것과 같은 도입 속도는 한 번도 본 적이 없습니다."

"We roll out tools internally all the time to make our developers more productive, but we have never seen the rate of adoption that we've seen rolling out AI coding tools."

흥미로운 점은, 이런 도입이 "위에서 강제로 밀어붙인" 결과가 아니라 개발자들이 자발적으로 몰려든 결과였다는 것입니다. 도구가 충분히 좋아지자 사용을 막을 이유가 없어졌고, 모델의 역량이 어느 임계점을 넘은 순간 조직 전체의 작업 방식이 빠르게 재편되었습니다.

에이전트 이전부터 시작된 여정, Fleet Management와 Fleetshift

많은 사람들이 Spotify의 변화를 "AI 붐을 잘 탄 사례"로 읽지만, 정작 Spotify 자신은 이 여정이 에이전트가 등장하기 몇 년 전부터 시작되었다고 강조합니다. 몇 년 전 Spotify는 자사의 프로덕션 코드베이스가 엔지니어 수보다 7배 빠르게 증가하고 있다는 사실을 발견했습니다. 그 결과 개발자들은 점점 더 많은 시간을 유지보수에 쏟게 되었습니다. 의존성 업그레이드, API 마이그레이션(migration), 보안 취약점 패치 같은 일이 늘어나면서 정작 기능을 만드는 시간은 줄어들었고, 마이그레이션은 개발자 불만의 1순위 원인이 되었습니다.

수백 개의 팀에게 각자의 컴포넌트를 하나하나 수동으로 업데이트하라고 요구하는 대신, Spotify는 다른 접근을 상상했습니다. 자동화를 통해 수백, 심지어 수천 개의 소프트웨어 컴포넌트를 한 번에 변경할 수 있다면 어떨까요? 이 아이디어가 바로 플릿 관리(Fleet Management) 가 되었고, 이를 실행하기 위해 만든 기반 시스템이 Fleetshift입니다.

"컴포넌트 하나하나를 거의 수동으로 처리하는 대신, 우리가 가진 컴포넌트 전체를 하나의 플릿(fleet)으로 보고 한꺼번에 변형시킬 방법을 상상할 수 있지 않을까요?"

"Instead of doing this component per component and fairly manually, can we imagine a way where we do this as a way to mutate our entire fleet of components?"

플릿 관리는 Spotify에서 이미 수년째 운영되고 있습니다. 지금까지 250만 건 이상의 자동 유지보수 PR을 머지했으며, 그 대부분은 사람이 개입하지 않고 자동으로 머지되었습니다. 아래 그래프에서 초록색 영역이 바로 자동 머지된 PR의 비중을 나타냅니다.

여기서 주목할 점은, 이 단계의 자동화가 아직 결정론적(deterministic) 스크립트에 의존하고 있었다는 것입니다. 정해진 규칙대로 코드를 바꾸는 방식은 단순한 변경에는 잘 작동했지만, 곧 그 한계가 드러납니다.

백그라운드 코딩 에이전트, Honk를 만나다

플릿 관리는 단순한 변경에는 아름답게 작동했지만, API 호출을 교체하거나 사용 패턴을 리팩터링하는 복잡한 코드 수정에서는 결정론적 스크립트가 한계에 부딪혔습니다. 수백만 줄의 코드와 수천 개의 컴포넌트에 걸쳐 스크립트를 실행하면 상상할 수 있는 모든 예외 상황(corner case)을 만나게 됩니다. 점점 더 복잡해지는 스크립트를 작성하는 일은 그 자체로 새로운 유지보수 부담이 되었습니다.

대규모 언어 모델(LLM)이 성숙해지면서 Spotify는 기회를 포착했습니다. 점점 더 복잡한 결정론적 스크립트를 작성하는 대신, 모델이 직접 코드 수정을 처리하게 하면 어떨까 하는 발상이었습니다.

"우스꽝스러운 이름과 우스꽝스러운 아이콘을 가졌지만, 알고 보니 정말 유용한 도구입니다."

"It has a silly name and a silly icon, but it's a very useful tool, as it turns out."

수많은 반복(iteration) 끝에 탄생한 결과물이 바로 백그라운드 코딩 에이전트 Honk입니다. 이름은 우스꽝스럽지만(honk는 거위 울음소리입니다), 이 "깃털 달린 코딩 친구"는 Spotify의 일상 운영에서 빠질 수 없는 존재가 되었습니다. 내부적으로 Honk는 Claude Agent SDK를 사용해 Claude를 구동하며, Spotify 자체 하네스(harness)로 감싼 뒤 Kubernetes 파드(pod)에 배포되어 클라우드 환경 전반에서 여러 세션을 동시에 스케줄링할 수 있습니다. Honk는 신뢰할 수 있는 도구 집합에 접근하며, 여기에는 여러 운영체제에서 CI 환경의 빌드를 직접 실행해 자신의 변경이 올바른지 검증하는 능력도 포함됩니다.

여기서 에이전트가 스스로 검증한다는 점이 핵심입니다. 단순히 코드를 생성하는 데 그치지 않고, CI 빌드를 돌려 자신의 변경이 실제로 통과하는지 확인한 뒤 PR을 올리기 때문에, 사람의 개입 없이도 신뢰할 만한 자동 머지가 가능해집니다.

Honk는 플릿 관리 도구에 직접 통합됩니다. Fleetshift는 사람이 오케스트레이션(orchestration)을 관리하도록 돕습니다. 대상 컴포넌트를 식별하고, 변경을 스케줄링하고, 진행 상황을 추적하는 일을 담당하죠. 그 중간에서 Honk가 실제 코드 수정을 수행합니다. 마이그레이션을 진행하는 팀은 얼마나 많은 PR이 생성되었고, 몇 개가 머지되었으며, 어떤 것이 주의를 필요로 하는지를 한눈에 볼 수 있습니다. Spotify의 가장 최근 자바(Java) 마이그레이션은 백엔드 서비스 전반에 걸쳐 단 3일 만에 끝났습니다.

"예전에는 수백 개의 팀이 각자 컴포넌트를 마이그레이션하느라 몇 주, 몇 달이 걸리던 일을, 이제는 단 한 명의 엔지니어가 며칠 만에 해낼 수 있습니다."

"What used to be hundreds of teams doing migrations for their components, taking weeks and weeks or months, now can be done by a single engineer in a few days."

개발자들은 역시 개발자답게, 이 놀랍도록 유능하고 자기충족적인 백그라운드 에이전트를 활용하는 새로운 방법을 금세 찾아냈습니다. 이제 Honk는 Slack에서도 사용할 수 있어, 엔지니어가 대화 도중에 Honk를 멘션하면(대화 맥락은 그 자체로 훌륭한 컨텍스트가 됩니다) Honk가 날아가 문제를 처리하고 PR을 들고 돌아옵니다.

아래는 Spotify의 실시간 대시보드인 "구스 팜(Goose Farm)"으로, 플릿 관리 시스템에서 현재 진행 중인 활동을 보여줍니다. 각각의 거위 한 마리가 Honk로 구동되는 활성 백그라운드 코딩 세션 하나를 나타냅니다.

Goose Farm 실시간 대시보드

그리고 Honk v2와 함께 Spotify는 멀티플레이어 협업을 도입하고 있습니다. 공유 에이전트 세션, 팀 단위 프로젝트, 그리고 Chirp를 통한 에이전트 오케스트레이션이 그것입니다. Spotify는 한 사람이 터미널 앞에 앉아 에이전트 하나를 다루는 세계를 넘어, 여러 개발자와 팀이 에이전트와 함께 협업하는 세계를 그리고 있습니다.

이 변화의 더 자세한 데이터와 마이그레이션 사례는 Spotify가 별도로 공개한 백그라운드 코딩 에이전트 시리즈에서 확인할 수 있습니다.

Honk를 활용한 대규모 데이터셋 마이그레이션 사례에 관해서는 다음 글(Background coding agents for dataset migrations)을 참고해주세요:

개발자 경험은 에이전트를 위한 것이기도 하다

Spotify의 가장 오래된 엔지니어링 원칙 중 하나는 이것입니다. "우리가 세계 최고 수준으로 잘 다루는 기술의 종류가 적을수록, 우리는 더 빠르게 움직인다." 이는 Spotify에 AI가 등장하기 한참 전부터 있던 생각입니다.

집중된 소수의 기술 스택으로 표준화함으로써, Spotify는 더 깊은 전문성을 쌓고, 팀이 불필요한 의사결정을 내릴 필요를 없애며, 엔지니어들이 코드베이스 전반에서 훨씬 쉽게 협업할 수 있게 만들었습니다. Spotify의 전형적인 백엔드 서비스는 다른 모든 백엔드 서비스와 매우 비슷하게 생겼습니다. 같은 기술 스택, 거의 같은 디자인 패턴을 공유하죠.

흥미롭게도 이 원칙은 에이전트에게도 똑같이 중요한 것으로 밝혀졌습니다. Claude가 참고할 다른 코드가 많고 그 코드가 일관적일 때, 에이전트의 성능은 눈에 띄게 좋아집니다. Spotify는 이를 분명하게 관찰했습니다. 더 파편화된 코드베이스에서는 에이전트의 성능이 측정 가능할 만큼 더 나빴습니다.

"Claude가 참고할 다른 코드가 많고 그 코드가 대체로 일관적으로 보인다면, Claude는 더 나은 결과를 냅니다. 그게 우리가 보고 있는 현상입니다."

"If Claude has a lot of other code to look at, and that code looks roughly consistent, Claude will do a better job. That's what we're seeing."

이 일관성의 출발점이 바로 Spotify의 오픈소스 내부 개발자 포털(Internal Developer Portal, IDP)인 Backstage입니다. Backstage 이전의 Spotify에는 배포용 도구 따로, CI용 도구 따로, A/B 테스트용 도구 따로 등 대략 100여 개의 서로 다른 내부 도구가 있었습니다. 파편화되어 있고 혼란스러웠죠. Backstage는 이 모든 것을 소프트웨어 컴포넌트 카탈로그를 중심으로 한 단일 창구(single pane of glass) 로 통합했습니다. 오늘날 개발자가 어떤 컴포넌트로 무언가를 해야 한다면, 그 일은 Backstage 안에서 이루어집니다.

그리고 이는 에이전트에게도 똑같이 유용한 것으로 드러났습니다. Spotify는 Backstage의 기능을 MCP(Model Context Protocol)와 명령줄 도구로 노출하여, Claude가 어떤 컴포넌트의 소유자가 누구인지 조회하고, 문서를 읽고, 책임 팀에게 Slack으로 핑(ping)을 보낼 수 있도록 했습니다. 즉, 사람이 쓰던 개발자 포털이 그대로 에이전트의 컨텍스트 공급원이 된 것입니다.

가드레일이 된 표준, Soundcheck와 골든 스테이트

Spotify는 Backstage를 통해 Soundcheck와 골든 스테이트(Golden State) 라고 부르는 개념으로 표준화를 추진합니다. 골든 스테이트는 각 컴포넌트 유형에 대해 권장되는 기술과 관행을 정의합니다. Soundcheck는 팀이 자신의 컴포넌트를 그 표준에 비추어 스스로 평가할 수 있는 UI를 제공합니다.

여기에 정적 분석(static analysis)과 린팅(linting)이 결합되면, 이 표준들은 단순한 권고 문서를 넘어 능동적인 가드레일(active guardrail) 이 됩니다. Claude가 Spotify의 코드베이스에서 작업하다가 인프라에 최적이 아닌 패턴을 사용하면, 린트 시스템으로부터 즉각적인 피드백을 받고 스스로 수정합니다.

"Claude가 우리 코드베이스에서 작업할 때, 올바른 기술 집합과 올바른 디자인 패턴을 사용하고 있는지에 대해 즉각적인 피드백을 받게 됩니다."

"When Claude works in our codebase, it will get immediate feedback on if it's using the right set of technologies and right set of design patterns."

이 피드백 루프는 사람과 에이전트 모두에게 동일하게 작동합니다. Spotify는 이것이 대규모로 일관성을 끌어내는 가장 효과적인 방법 중 하나였다고 말합니다. 한국의 많은 조직이 AI 코딩 도구를 도입하면서 "에이전트가 우리 컨벤션을 안 지킨다"는 문제를 겪는데, Spotify의 답은 별도의 프롬프트 주입이 아니라 사람에게도 적용되던 린트와 표준을 그대로 에이전트에게 노출하는 것이었다는 점이 시사적입니다.

코딩은 더 이상 병목이 아니다

코딩 속도가 빨라지면서, 제약은 사람의 의사결정 쪽으로 옮겨갑니다. Spotify는 늘 만들 수 있는 역량보다 더 많은 아이디어를 가지고 있었지만, 이제는 누구나 클라이언트 모노레포(monorepo)에서 Claude를 열어 며칠이 아니라 몇 분 만에 기능 아이디어를 프로토타이핑할 수 있습니다. 심지어 Spotify의 CEO조차 이런 방식으로 프로토타입을 만들고 있다고 합니다.

"이로 인해 프로토타이핑이 며칠 혹은 몇 주가 걸리던 일에서 말 그대로 몇 분이면 되는 일로 바뀌었습니다."

"This has brought prototyping from something that could take days or weeks to literally taking minutes now."

물론 동전의 양면이 있습니다. 이제 Spotify는 검토해야 할 PR이 76% 더 많아졌습니다. 그래서 어디에 사람의 판단을 적용할지를 새롭게 배워가고 있습니다. 안전한 것은 자동으로 머지하고, 가장 중요한 곳에 리뷰를 집중하며, 병목이 코딩에서 의사결정으로 이동함에 따라 어떻게 계획하고 우선순위를 매길지를 다시 생각하고 있습니다.

Spotify가 수년 전에 플릿 관리, Backstage, 그리고 엔지니어링 표준화에 했던 투자는 지금의 변화에 그들을 유리한 위치에 올려놓았습니다. 이것이 이 사례에서 우리가 얻을 수 있는 가장 큰 교훈일 것입니다. AI 에이전트의 효과는 모델의 성능만으로 결정되지 않으며, 일관된 코드베이스, 단일화된 플랫폼, 기계가 읽을 수 있는 표준과 가드레일이라는 토대 위에서 비로소 증폭됩니다. 코딩이 병목에서 벗어난 시대에, 다음 경쟁력은 "에이전트가 일하기 좋은 환경을 얼마나 잘 설계해 두었는가"에 달려 있는 셈입니다.

Fleetshift와 Honk는 Backstage용 Spotify Portal의 일부로 제공됩니다. 대규모로 복잡한 코드 변경을 오케스트레이션하는 일이 조직에 필요하다면, Spotify 플랫폼 팀에 문의할 수 있습니다.

발표 영상

니클라스 구스타브손의 Code with Claude 2026 발표 전체 영상은 아래에서 볼 수 있습니다.

Coding Is No Longer the Constraint 소개 블로그

Coding is no longer the constraint, Scaling devex to teams and agents at Spotify

Backstage 홈페이지

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~