서론

Spotify의 VP of Engineering, Niklas Gustavsson의 인터뷰 영상이 공개되었습니다. 주제는 2,000만 행이 넘는 백엔드 monorepo(단일의 거대한 리포지토리에 모아 전사 코드를 관리하는 구성)에서 AI 에이전트를 어떻게 실운용에 통합하고 있는지에 대한 것입니다.

질문자는 Anthropic 측 담당자입니다. 약 26분간의 대화 속에서 이야기되는 것은 화려한 성공 사례라기보다는 "토대(foundation)에 대한 꾸준한 투자"에 관한 이야기였습니다. 에이전트를 빠르게 달리게 하려 할수록, 검증 (verification, 변경 사항이 올바른지 자동으로 체크하는 메커니즘)과 테스트 자동화에 대한 투자가 효과를 발휘합니다. 이 기사에서는 그 논지를 Spotify의 실제 사례에 따라 정리합니다.

IDE를 사용하지 않게 된, 30년 차 엔지니어

Gustavsson의 경력은 다소 독특합니다. 원래는 분자생물학 박사 과정이었으며, 게놈 서열이라는 "당시의 빅데이터"를 다루기 위해 프로그래밍을 배웠습니다. 사바티컬 (sabbatical, 연구자가 갖는 장기 휴가)로 시작한 프로그래밍이 어느덧 약 30년의 커리어가 되었다고 합니다.

그 30년 경력자에게 최근 가장 큰 변화가 일어났습니다. 질문자는 다음과 같이 회상합니다.

I actually remember talking to you back in September last year and you said something like, "Yeah, I don't think at the end of the year no one is going to be using an IDE." (...) And then 2 months later, I found myself not using an IDE anymore. And the way that I was working had completely changed. It changed that I had not seen in the 30 years that I've been doing this type of work.

"작년 9월에 '연말에는 아무도 IDE를 사용하지 않을 것'이라는 말을 들었을 때, 그런 일이 일어날 리 없다고 생각했다. 그런데 그 2개월 후, 나 자신이 IDE를 사용하지 않고 있었다. 이는 내가 이 일을 해온 30년 동안 보지 못했던 변화였다"라는 취지의 발언입니다. Gustavsson 자신도 "사내에서도 완전히 똑같은 일이 일어나고 있었다"라고 응답했습니다.

배경에는 Opus 4/5 세대의 모델이 있습니다. 그 이전에는 "모델에게 7~8할을 쓰게 하고, 마지막 마무리(last-mile editing)는 인간이 IDE 상에서 수정한다"는 운용이 주류였습니다. 이 "마무리 부분(last-mile editing)"이 불필요해진 것이 체감상의 전환점이었다고 말합니다.

Honk ― Spotify 사내 에이전트 기반

개인의 작업 스타일 변화뿐만 아니라, Spotify는 사내용 에이전트 기반을 보유하고 있습니다. 이름은 Honk입니다. 원래는 Claude 기반조차 아닌 짜깁기 도구였으나, 지금은 Claude Agent SDK(에이전트를 애플리케이션에 통합하기 위한 개발 키트)를 Kubernetes의 pod 위에서 실행하는 범용성 높은 기반으로 성장했습니다.

Honk의 설계에서 흥미로운 점은 "LLM-as-judge(LLM 스스로 결과물의 타당성을 심사하게 하는 메커니즘)"를 한때 도입했다가 이후 제거했다는 경위입니다.

The judge was very important in the first iterations of Honk. It made us go from, if I remember the numbers correctly, roughly like 20-30% success rate on PRs to like 80% success rate. (...) But then again, as we talked about, the models caught up and the agent harness caught up, so [we don't need judge anymore].

「judge 도입으로 PR 성공률이 20~30%에서 80%까지 개선되었다. 하지만 그 후 모델과 agent harness(에이전트 실행 기반) 자체가 똑똑해지면서, judge는 불필요해졌다」는 이야기입니다. 좋은 시스템을 도입하는 것으로 끝나는 것이 아니라, 모델의 진화에 맞춰 구성을 계속해서 재구축하고 있다는 점이 이 기반 운용의 특징이라고 할 수 있습니다.

Honk가 보유한 도구 중에서도 Gustavsson이 "가장 중요"하다고 꼽는 것은 검증 도구입니다. 에이전트는 CI 빌드(Continuous Integration의 빌드 및 테스트 실행)를 Linux와 macOS 양쪽 모두에서 스스로 실행할 수 있습니다. macOS 대응이 중요한 이유는 iOS 개발 때문인데, Figma 디자인에서 UI 구현으로의 변환이나, iOS 앱을 TV 앱으로 이식하는 작업에도 이 메커니즘이 사용되고 있다고 합니다.

결정론적 스크립트의 한계와 fleet management

지금까지 Honk의 "현재 모습"을 살펴보았지만, 시계열을 조금 되돌려 보겠습니다. Honk는 처음부터 에이전트 기반으로 태어난 것이 아니라, fleet management(수천 개의 리포지토리와 컴포넌트에 걸친 일제 코드 변경을 수행하는 사내 인프라)라는 시도의 연장선상에 있습니다. 여기서 말하는 「일제 코드 변경」이란, 「Java 버전을 올리기」, 「오래된 API를 새로운 API로 교체하기」와 같이 전사의 코드에 횡단적으로 영향을 미치는 유지보수 작업을 의미합니다.

fleet management를 할 수 있게 되기 전, 이러한 이관은 수작업으로 진행되었습니다. 이관 절차를 정리한 가이드를 만들어 각 팀에 배포하고, 수백 개의 팀이 각자 자신의 컴포넌트에 수동으로 적용하는 방식이었습니다. 동일한 작업을 수백 개의 팀이 반복하기 때문에, 한 건의 이관에 수개월이 걸렸고 연간 10건 정도가 한계였습니다. 5~6년 전, Spotify의 코드베이스 증가 속도는 엔지니어 수의 약 7배에 달했으며, 이러한 수작업 속도로는 따라잡을 수 없었다고 합니다.

그래서 만들어진 것이 fleet management입니다. 가이드를 배포하여 사람에게 시키는 대신, 결정론적 스크립트(동일한 코드 패턴에 대해 항상 동일한 재작성을 기계적으로 적용하는 프로그램. 영상 중에서는 static analysis(정적 분석)를 통한 코드 변환으로 표현됨)를 하나 작성하여, 이를 수천 개의 리포지토리에 일괄 적용하는 메커니즘입니다. 이 방식으로 실제로 수백만 건 규모의 PR을 머지(merge)할 수 있게 되었지만, 한계 또한 이른 단계에서 보였다고 Gustavsson은 회상합니다.

We found pretty early was code has an enormous API surface. So trying to make changes to code gets very complicated very quickly. (...) Even switching out the method and API becomes pretty complicated when you can call that in five different ways.

「코드의 API 서피스(API surface, 호출 패턴)는 매우 방대하다. 하나의 메서드나 API를 교체하는 것만으로도, 호출 방식이 5가지라면 순식간에 복잡해진다」는 지적입니다. 예를 들어, 어떤 API의 반환값을 일단 변수에 할당한 뒤 사용하는 코드의 경우, 스크립트 측에서도 해당 변수를 추적하여 「이것은 재작성 대상인 API다」라고 판정하는 처리(상태 추적)가 필요합니다. 이러한 호출 패턴의 변형을 사전에 모두 스크립트에 작성하려 시도한 결과, 스크립트 하나가 수천 줄로 불어났고, 복잡한 변경에는 대응할 수 없는 한계에 부딪혔습니다.

이 한계를 돌파하기 위한 수단으로 도입된 것이 LLM입니다. 초기 LLM이 등장하자마자 바로 시도했다고 하는데, 처음에는 코드를 그대로 모델에 전달하여 한 번에 재작성하게 하는 단순한 방식이었기에 성공적이지 못했습니다. 모델의 성능이 향상됨과 동시에, LLM-as-judge를 통한 출력 체크나 태스크를 단계별로 분해하는 등의 고안을 거듭하였고, 이러한 시행착오가 쌓여 지금의 Honk로 통합되었습니다. 초기 Honk는 Claude 기반조차 아닌 여러 도구를 모아놓은 형태였지만, 「이 종류의 문제는 풀 수 있다」는 첫 손맛을 느꼈다는 의미에서 Gustavsson은 이를 「터널 끝에서 보인 첫 번째 빛」이라고 표현하고 있습니다.

즉, Honk는 fleet management (플릿 관리)와 별개의 것으로 태어난 것이 아니라, fleet management와 동일한 작업(코드 변경을 자동화하고, 모든 리포지토리로 스케줄링 및 실행)을 결정론적 스크립트 (deterministic script) 대신 에이전트가 담당하는 형태로 시작되었습니다. 결정론적 스크립트가 "발생 가능한 재작성 패턴을 인간이 사전에 모두 작성하는" 방식이었던 것에 반해, 에이전트는 각 리포지토리의 코드를 그 자리에서 읽고 판단하며 재작성합니다. 에지 케이스 (edge case)를 스크립트에 사전에 작성하는 대신, 에이전트가 그때마다 생각하며 대응하는 방식으로의 대체입니다. 이 토대 위에 검증 메커니즘이 더해짐으로써, Honk는 fleet management의 틀을 넘어 더욱 범용적인 에이전트 기반으로 성장해 나갑니다.

검증에 대한 투자가 속도를 만든다 ― "가짜 트레이드오프 (false trade-off)"

이 영상의 가장 핵심은 검증이라는 테마 그 자체입니다. 청자가 "verification (검증)은 자주 화제가 되지만"이라고 운을 뗐을 때, Spotify 측의 답변은 명확했습니다. 인간이 개입하지 않는 클로즈드 루프 개발 (closed-loop development, 에이전트가 태스크를 분해하고 사람의 확인 없이 일련의 작업을 끝내는 개발 스타일)에 있어서, 검증 루프의 완성도야말로 유일하게 가장 중요한 요소라는 입장입니다. 실제로 많은 기업이 이 부분에 대한 투자를 과소평가하고 있다는 지적도 덧붙여졌습니다.

Spotify가 지난 몇 년간 강화해 온 것은 테스트 자동화입니다. 코드베이스를 수천 개의 컴포넌트로 분할하고, 각각에 명확한 소유 팀을 배치합니다. 이러한 꾸준한 표준화가 결과적으로 에이전트 운용의 토대가 되었다고 합니다.

나아가, "신뢰성·품질"과 "속도"는 대립하는 것이라는, 엔지니어링에서 흔히 이야기되는 전제 그 자체에 대해 Gustavsson은 이의를 제기합니다.

To me it feels kind of like a false dichotomy, because if you want to go faster, the thing that you need to do is you need to automate your quality practices so that it's better encoded. It's not in someone's head. It's actually like in a skill or in a CLAUDE.md or in some set of MCPs. It's something that Claude can do.

"이것은 가짜 이분법(false dichotomy)이다. 더 빠르게 나아가고 싶다면, 품질을 보장하는 실천 사항을 자동화하여 '코드화'하면 된다. 누군가의 머릿속에 있는 노하우로 남겨두지 말고, skill이나 CLAUDE.md, MCP (Model Context Protocol)와 같은 형태로 Claude가 직접 사용할 수 있는 상태로 만들어야 한다"라는 주장입니다. 품질 실천을 개인의 역량에 의존하게 둔 채 속도를 추구하는 것이 아니라, 실천 그 자체를 에이전트가 참조할 수 있는 형태로 구현함으로써 속도와 품질을 양립시킨다는 발상입니다.

표준화에 대해서도 유사한 논리가 언급되었습니다. 원래는 인간의 생산성을 위해 진행했던 "코드베이스의 일관성을 높이는" 노력이 그대로 에이전트의 지능과도 직결되었다는 것입니다. 작성 방식이 10가지나 되는 monorepo (모노레포)에서는 Claude도 참조할 예시를 찾는 데 어려움을 겪습니다. 일관성이 높을수록 에이전트는 올바른 동작을 더 쉽게 찾아낼 수 있다는 관계가 성립합니다.

숫자로 보는 효과

영상 내에서 언급된 정량적인 수치를 정리하면 다음과 같습니다.

지표	수치
백엔드 monorepo 규모	2,000만 행 초과
...

모두 (Spotify, 2026년 시점의 인터뷰 발언)에 따른 수치입니다.

We're seeing a 75% plus improvement in PR frequency, for example, that we can directly attribute to AI tooling. And I think by now 73-ish percent of PRs are directly attributed to being AI-authored.

이러한 수치들은 단독으로 해석하기보다, 「기반 투자 → 검증 루프 (verification loop)의 가속화 → PR 빈도 및 자동화율 향상」이라는 일련의 흐름의 결과로 파악할 때 그 위치를 더 쉽게 이해할 수 있습니다. ROI(투자 대비 효과) 측정에 대해서도, PR이나 배포(deploy)와 같은 엔지니어의 산출물을 「work item」이라는 단위에 연결하고, 이를 통해 A/B 테스트나 사용자 가치, 수익까지 연결하려는 노력이 진행 중이라고 합니다.

리더 및 엔지니어를 위한 시사점

인터뷰 종반에 인터뷰어는 "타사의 CTO나 VP of Engineering에게 어떤 조언을 해주고 싶은가"라고 질문합니다. Gustavsson의 답변은 이 기사 전체의 결론과도 맞닿아 있습니다.

What we've found is that these investments in foundational capabilities we talked about — test automation and verification — I'm going to say the same is true for another aspect that we've seen, which is standardization.

"테스트 자동화, 검증, 표준화라는 기반 능력에 대한 투자야말로 효과가 있다"는, 눈에 띄지는 않지만 일관된 답변입니다.

이 영상에서 언급된 또 다른 변화로는 프로토타이핑 (prototyping)의 민주화가 있습니다. Spotify에서는 자연어로 아이디어를 설명하는 것만으로 Claude가 작동하는 프로토타입을 1~2시간 만에 만들 수 있는 환경이 사내에 구축되고 있으며, 엔지니어가 아닌 직원들도 사내 app store에 자신의 프로토타입을 게시하고 있다고 합니다. 아이디어에서 실제 운영 환경 투입까지의 기간도 과거 몇 주에서 몇 개월이었으나, 조건이 갖춰지면 약 1시간까지 단축된 사례가 있다고 언급되었습니다.

이는 엔지니어의 업무 중심이 바뀌고 있음을 의미하기도 합니다. Gustavsson 자신도 업무 방식의 급격한 변화를 내심 걱정했으나, 구현 작업 그 자체보다는 "다음에 무엇을 만들 것인가", "고객과 무엇을 이야기할 것인가", "빠르게 시제품을 만들어 검증할 것인가"에 시간을 할애하는 방향으로의 전환은 기우로 끝났다고 회상합니다.

요약

Spotify의 사례가 보여주는 것은 화려한 자동화의 성과가 아니라, 검증, 테스트 자동화, 표준화라는 기반에 대한 꾸준한 투자가 결과적으로 에이전트의 속도와 신뢰성 모두를 끌어올린다는 구조입니다. 수동 작업을 자동화하기 위해 결정론적 스크립트(deterministic script)를 사용한 fleet management가 탄생했고, 그 스크립트가 복잡한 변경 사항에 대응하지 못해 한계에 부딪힌 지점에서 Honk이 성장했으며, judge와 같은 메커니즘은 필요한 기간 동안만 사용되고 역할을 다합니다. 일관되게 변하지 않는 것은, "클로즈드 루프 (closed-loop) 개발에서 검증 루프의 질이 유일하게 가장 중요하다"는 입장입니다.

자신의 리포지토리(repository)에서 에이전트를 활용할 때도 CLAUDE.md나 스킬, CI 정비와 같은 기반에 대한 투자를 뒤로 미루지 않는 것이, 멀리 돌아가는 것처럼 보여도 실제로는 가장 빠른 경로가 됩니다. Spotify의 사례는 그 구체적인 실감을 알려줍니다.

참고 링크

Discussion