Spotify 최고 개발자가 12월부터 코드 0줄이다

출근길 슬랙에서 버그를 고친다

2026년 2월 10일, Spotify 4분기 실적 발표. 공동 CEO Gustav Soderstrom이 투자자들 앞에서 한 문장을 던졌다. "우리 최고 시니어 엔지니어들에게 물어보면, 그들은 12월부터 코드를 한 줄도 직접 쓰지 않았다고 말한다." 코드를 쓰지 않는 개발자라니, 형용 모순처럼 들린다. 하지만 Soderstrom의 설명은 구체적이었다.

"Spotify 엔지니어가 출근길에 핸드폰 슬랙에서 Claude에게 iOS 앱의 버그를 고치고 새 기능을 추가하라고 지시한다. 사무실에 도착하기 전에 새 버전의 앱이 슬랙으로 돌아온다." 코드를 쓰는 대신 코드를 생성하고 감독한다는 것이다. 이 시스템의 이름은 Honk. Spotify가 내부에서 만든 백그라운드 코딩 에이전트다.

7억 5,100만 월간 활성 사용자, 2억 9,000만 프리미엄 구독자, 전년 대비 13% 성장한 45억 유로 매출. 숫자만 보면 이 전략이 먹히고 있는 것처럼 보인다. 2025년 한 해 동안 음악 권리자에게 110억 유로를 분배했고, 7억 100만 유로의 영업이익을 기록했다. 하지만 실적 발표장의 투자자 반응과 인터넷의 개발자 반응은 완전히 달랐다. 전자는 박수를 쳤고, 후자는 경악했다. 같은 숫자를 두고 완전히 다른 반응이 나온 것이다.

Honk는 하루아침에 만든 게 아니다

Honk의 기반은 Spotify가 2022년부터 만들어온 Fleet Management라는 프레임워크다. 수백, 수천 개의 저장소에 코드 변경을 일괄 적용하는 시스템이다. 2024년 중반부터 이 시스템이 전체 PR의 약 50%를 자동화하고 있었다. Honk는 이 인프라 위에 Anthropic의 Claude Code와 Claude Agent SDK를 얹은 것이다.

기술 스택을 분해하면 이렇다. Claude Code가 에이전트의 두뇌 역할을 하고, Claude Agent SDK가 에이전틱 루프의 뼈대를 구성한다. MCP(Model Context Protocol)가 슬랙, GitHub Enterprise, 기타 내부 도구를 연결한다. 그리고 Backstage라는 오픈소스 개발자 포털이 컴포넌트 카탈로그와 소유권 정보를 제공한다.

Spotify 엔지니어링 블로그에 공개된 3부작 시리즈를 보면, 이 시스템이 시행착오의 산물이라는 것을 알 수 있다. 처음에는 Goose, Aider 같은 오픈소스 에이전트를 시도했다. 코드베이스를 탐색하고 프롬프트 기반으로 편집하는 수준은 됐지만, "병합 가능한 PR을 안정적으로 만들어내지 못했다." 그 다음에는 직접 에이전틱 루프를 만들었다. 세션당 10턴, 최대 3회 재시도라는 제한을 뒀지만, 복잡한 멀티파일 수정에서 "컨텍스트 윈도우가 차면 원래 작업을 잊어버리는" 문제가 있었다.

Claude Code로 전환하면서 상황이 달라졌다. "더 자연스러운 작업 지향적 프롬프트"가 가능해졌고, 투두 리스트 관리와 서브에이전트 생성 기능이 내장되어 있었다. 현재 Claude Code가 약 50건의 마이그레이션을 처리하고 있으며, 프로덕션에 머지된 백그라운드 에이전트 PR의 대다수를 차지한다.

주목할 점은 Honk에 도달하기까지의 여정이다. 2022년 Fleet Management 착수, 2024년 중반 PR 자동화 50% 달성, 2025년 7월 Claude Agent SDK 통합, 2025년 11월부터 12월까지 엔지니어링 블로그 3부작 공개, 그리고 2025년 12월부터 시니어 엔지니어의 수동 코딩 중단. 4년간의 인프라 투자가 있었기에 가능한 일이었다. Soderstrom의 발언만 떼어놓으면 마치 하루아침에 일어난 변화처럼 보이지만, 실상은 그 반대다.

1,500개 PR과 90%의 시간 절감

Honk의 숫자를 정리하면 이렇다.

항목	수치
머지된 AI 생성 PR	1,500건 이상
월간 에이전트 PR	650건 이상
코드 마이그레이션 시간 절감	60~90%
2025년 출시 기능	50개 이상
월간 활성 사용자	7억 5,100만 명
프리미엄 구독자	2억 9,000만 명

워크플로우는 단순하다. 엔지니어가 슬랙에서 자연어로 프롬프트를 보낸다. Claude가 코드베이스를 탐색하고, 코드를 수정하고, 포매터와 린터를 실행하고, 빌드와 테스트를 돌린다. 새 빌드가 슬랙으로 돌아온다. 엔지니어가 리뷰하고 프로덕션에 머지한다. 전체 과정이 샌드박스 컨테이너 안에서 제한된 권한으로 실행된다.

Spotify가 특히 신경 쓴 부분은 도구의 제한이다. 에이전트에게 무한한 자유를 주는 대신, MCP 도구를 세 가지로 한정했다. 포매터와 린터와 테스트를 실행하는 Verify 도구, 위험한 명령을 차단하는 제한된 Git 도구, ripgrep만 허용하는 Bash 도구. 엔지니어링 블로그의 표현을 빌리면, "도구가 많을수록 예측 불가능성의 차원이 늘어난다." 동적으로 정보를 가져오게 하는 대신, 필요한 컨텍스트를 프롬프트에 미리 넣는 방식을 택했다. 유연성을 버리고 신뢰성을 산 것이다.

프롬프트도 코드처럼 관리한다. 버전 관리되는 정적 프롬프트를 사용하고, 테스트와 평가가 가능한 형태로 유지한다. Spotify가 공개한 프롬프트 엔지니어링 원칙은 여섯 가지다. 에이전트의 능력에 맞춰 프롬프트를 조정할 것. 단계별 지시 대신 최종 상태를 기술할 것. 행동하지 말아야 할 조건을 명시할 것. 구체적인 코드 예시를 제공할 것. 관련된 변경이라도 별도의 프롬프트로 분리할 것. 그리고 에이전트에게 프롬프트 자체에 대한 피드백을 요청해 반복적으로 개선할 것. 이 모든 것이 "하루아침에 AI를 도입하면 된다"는 환상과 정반대의 이야기다.

"빠르다고 느꼈지만 실제로는 19% 느렸다"

Spotify의 발표를 곧이곧대로 받아들이기 어려운 이유가 있다. 2025년 7월, 비영리 AI 안전 연구 기관 METR이 발표한 연구가 그것이다. 대형 오픈소스 프로젝트에 평균 5년, 1,500커밋 이상의 경험을 가진 시니어 개발자 16명을 대상으로 한 실험이었다. 246개의 실제 이슈를 무작위로 배정해, AI 도구를 쓸 수 있는 그룹과 쓸 수 없는 그룹을 비교했다.

결과는 직관에 반했다. AI 도구를 사용한 그룹이 작업 완료에 19% 더 오래 걸렸다. 개발자들은 작업 전에 AI가 24% 시간을 줄여줄 것이라 예측했고, 작업 후에도 20% 줄었다고 체감했다. 실제로는 더 느려졌는데 더 빨라졌다고 느낀 것이다.

원인은 여러 가지가 있었다. AI가 생성한 코드를 검토하고 정리하는 데 상당한 시간이 들었다. 해당 코드베이스에 깊은 경험을 가진 개발자일수록 직접 쓰는 것이 빨랐다. METR 연구진은 이를 "분포 내(in-distribution) 작업에서 전문가의 속도를 AI가 따라잡기 어렵다"고 분석했다.

물론 반론도 가능하다. METR 연구는 2025년 초반 모델(Claude 3.5/3.7 Sonnet, Cursor Pro)을 사용했다. Spotify의 Honk는 Opus 4.5 기반이고, 사용 방식도 근본적으로 다르다. 개별 개발자가 IDE에서 AI를 보조 도구로 쓰는 것과, 조직 차원에서 인프라를 갖추고 에이전트를 배치하는 것은 다른 차원의 이야기다. METR 연구의 개발자들은 자기가 잘 아는 코드베이스에서 AI의 도움을 받았고, Spotify의 에이전트는 표준화된 환경에서 반복적인 마이그레이션 작업을 수행한다. 작업의 성격 자체가 다르다.

그럼에도 "시니어 개발자가 AI로 빨라진다"는 주장에 대해 유일하게 엄밀한 대조군 실험이 정반대 결과를 냈다는 사실은 무시하기 어렵다. Spotify의 "60~90% 시간 절감"이라는 수치는 내부 측정이다. 외부 검증을 거친 적이 없다. 자기 보고(self-report)의 신뢰성 문제를 METR 연구가 정확히 지적한 바 있다.

Klarna의 전례가 불편한 이유

AI로 인간을 대체하겠다고 선언한 뒤 후퇴한 전례가 있다. 핀테크 기업 Klarna가 2023년 AI 어시스턴트를 도입하며 고객 서비스 직원 700명을 대체했다고 발표했을 때, 업계는 환호했다. 전체 고객 문의의 3분의 2를 AI가 처리한다는 수치는 인상적이었다.

하지만 2025년 봄, Klarna는 조용히 인간 상담원을 다시 채용하기 시작했다. "우버 스타일"이라 부르는 유연 근무 모델로, 학생과 부모 등 원격 상담원을 모집했다. CEO Sebastian Siemiatkowski는 "효율성과 비용에 너무 집중했다. 결과는 낮은 품질이었고, 그건 지속 가능하지 않다"고 인정했다. 고객 만족도가 하락하고, 복잡한 문제에서 AI가 공감 능력과 뉘앙스를 처리하지 못한다는 불만이 쏟아졌다. AI가 기본 문의를 처리하고, 인간이 공감과 판단이 필요한 케이스를 맡는 하이브리드 모델로 전환한 것이다.

고객 서비스와 소프트웨어 개발은 다른 영역이다. 직접 비교는 성립하지 않는다. 하지만 패턴은 비슷하다. 화려한 숫자를 앞세운 선언, 초기의 성공 지표, 그리고 시간이 지나면서 드러나는 품질 문제. Klarna가 "700명 대체"에서 "다시 채용"까지 걸린 시간은 약 2년이었다. Spotify가 "코드 0줄"을 선언한 것은 아직 3개월도 되지 않았다.

Reddit r/technology에 올라온 Spotify 관련 게시물에는 14,275개의 업보트가 달렸다. 가장 많이 반복된 질문은 세 가지였다. 감독 부담은 누가 지는가. 시니어 엔지니어만 해당되는 것은 아닌가(선택 편향). 그리고 기술 부채는 어디에 쌓이고 있는가. 이 세 번째 질문이 가장 치명적이다. AI가 생성한 코드는 당장은 작동할 수 있다. 테스트를 통과하고, 린터도 넘기고, 빌드도 성공한다. 하지만 6개월 뒤, 1년 뒤 그 코드를 유지보수해야 할 때, 코드를 "쓰지 않은" 개발자가 코드를 "이해하고" 수정할 수 있을까. 아무도 답하지 않았다.

가격은 올리고, 코딩은 AI에 맡기고

Spotify의 타이밍이 미묘하다. 이 발표가 나오기 한 달 전인 2026년 1월, Spotify는 프리미엄 개인 요금을 월 12.99달러로 인상했다. "최고의 경험을 계속 제공하기 위해"라는 이유였다. 한 달 뒤, 그 경험을 만드는 개발자들이 코드를 직접 쓰지 않는다는 발표가 나왔다.

이 두 사실을 나란히 놓으면 불편한 그림이 그려진다. 개발 비용은 AI로 절감하면서, 구독료는 올린다. 그 사이에서 사용자가 받는 것은 무엇인가. 2025년에 출시된 50개 이상의 기능 중에는 AI 기반 Prompted Playlists, 오디오북용 Page Match, About This Song 등이 있다. 기능의 수는 늘었다. 하지만 Android Authority의 기사 제목은 "Spotify 업데이트에 불만이 있다면, 범인을 맞춰보라"였다.

앱의 "비대해진 느낌"에 대한 사용자 불만이 꾸준히 올라오고 있다. AI 기능의 급격한 확장이 사용자를 끌어당기기보다 플랫폼에서 밀어내고 있다는 지적이다. 심지어 인앱 서점(bookstore) 추가 계획까지 있다. 음악 앱에 서점이라니, 기능을 빠르게 만들 수 있다는 것이 기능을 만들어야 한다는 뜻은 아니다. 기능이 많아지는 것과 제품이 좋아지는 것은 같은 말이 아니다. 오히려 반대일 수 있다.

Soderstrom은 실적 발표에서 소프트웨어 회사들이 "엄청나게 더 많은" 결과물을 낼 것이고, 개발 속도가 빨라져서 "제한 요소가 엔지니어링 역량이 아니라 소비자가 감당할 수 있는 변화의 양"이 될 것이라고 예측했다. 이 문장에서 빠진 것이 하나 있다. 변화의 질에 대한 언급이다.

인프라가 없으면 따라 할 수 없다

Spotify의 사례를 보고 "우리도 AI 도입하면 된다"고 생각하는 기업이 있을 것이다. 하지만 Honk가 가능했던 전제 조건을 먼저 봐야 한다.

Fleet Management 프레임워크를 만드는 데 2022년부터 4년이 걸렸다. Backstage라는 개발자 포털을 오픈소스로 공개할 만큼 내부 도구 생태계가 성숙해 있었다. 수천 개 저장소에 걸쳐 표준화된 빌드 시스템과 포괄적인 테스트 스위트가 갖춰져 있었다. "Judge"라는 평가 시스템이 에이전트의 출력을 검증하는 피드백 루프를 형성하고 있었다.

이 인프라 없이 Claude Code만 도입하면 Spotify가 된다고 생각하는 것은 착각이다. Spotify 엔지니어링 블로그의 표현을 빌리면, "이해하지 못한 것을 안전하게 자동화할 수 없다." 자동화의 전제는 표준화고, 표준화의 전제는 깊은 이해다.

현재 Honk가 인정하는 한계도 있다. 프롬프트가 시행착오를 통해 진화하지만 체계적인 평가 방법이 없다는 것. 어떤 프롬프트나 모델이 최적인지 판단할 정량적 기준이 부족하다는 것. 머지된 PR이 원래 문제를 실제로 해결했는지 검증하는 방법이 아직 없다는 것. 엔지니어링 블로그 3부작의 마지막 편이 이 문제를 다루고 있지만, 완전한 답은 나오지 않았다.

여기에 2026년 1월 Anthropic이 발표한 연구도 무게를 더한다. AI 도구를 사용한 개발자가 코딩 이해도 테스트에서 17% 낮은 점수를 받았다는 결과다. 작업은 약간 빨리 끝냈지만, 코드에 대한 이해는 얕아졌다. 역설적이게도, 이 연구를 발표한 것은 Spotify가 사용하는 Claude를 만든 Anthropic 자신이다. 자기 제품의 한계를 스스로 입증한 셈이다.

코드를 쓰지 않는 개발자가 코드를 이해할 수 있는가. 이 질문은 Spotify만의 문제가 아니다. 2025년 1월의 또 다른 조사에서는 전문 개발자의 77%가 AI 에이전트와의 작업에 "만족" 또는 "매우 만족"한다고 응답했다. 만족도와 역량은 다른 문제라는 것을 METR 연구가 이미 보여줬음에도, 개발자들은 여전히 AI가 자신을 빠르게 만든다고 믿고 있다.

코드를 쓰지 않는 개발자는 개발자인가

Soderstrom의 발언에서 가장 의미심장한 부분은 "코드를 생성하고 감독한다"는 표현이다. 쓰는(write) 것이 아니라 생성하고(generate) 감독한다(supervise). 동사가 바뀌면 직업의 정의도 바뀐다.

이 변화를 긍정적으로 읽으면, 개발자의 역할이 코드를 타이핑하는 구현자에서 시스템을 설계하고 검증하는 아키텍트로 상향 이동한 것이다. CCC 프로젝트에서 Chris Lattner가 말한 것과 같은 맥락이다. "구현 비용이 0에 수렴하면, 어떤 시스템이 존재해야 하는지 결정하는 능력이 가장 가치 있어진다." 코드를 치는 손이 아니라 방향을 정하는 눈이 중요해진다는 뜻이다.

부정적으로 읽으면 이야기가 달라진다. Reddit에서 가장 많은 공감을 얻은 댓글이다. "코드를 직접 쓰지 않는 최고 개발자들이 지금 뭘 하고 있냐고? 이력서를 업데이트하고 있을 것이다." 비꼬는 말이지만 핵심을 찌른다. AI가 코드를 쓰고 인간이 감독만 한다면, 감독자의 수는 실행자의 수보다 훨씬 적어도 된다. 50개 기능을 더 빨리 출시할 수 있다면, 같은 인력으로 더 많은 일을 하는 것이 아니라, 더 적은 인력으로 같은 일을 하게 될 가능성이 높다.

Spotify는 아직 대규모 감원을 발표하지 않았다. 하지만 2023년 12월에 1,500명을 해고한 전력이 있다. 전체 인력의 17%였다. 그리고 "코드를 한 줄도 쓰지 않는다"는 발언이 실적 발표 자리에서, 투자자들 앞에서 나왔다는 사실을 기억해야 한다. 그 자리에서 "생산성이 올랐다"는 말은 "비용을 줄일 수 있다"는 말과 동의어다. 공동 CEO Alex Norstrom과 회장 Daniel Ek도 같은 자리에 있었다. 세 명의 경영진이 동시에 "개발자가 코드를 쓰지 않는다"는 메시지를 투자자에게 전달한 것이다. 개발자들이 그 문장을 어떻게 읽었을지는 상상에 맡긴다.

Spotify의 실험은 아직 3개월째다. 성공인지 실패인지 판단하기엔 이르다. Soderstrom 자신도 이것이 "시작일 뿐"이라고 말했다. 하지만 시작이 곧 결말을 보장하지는 않는다는 것을 Klarna가 이미 보여줬다.

확실한 것은 하나다. "코드를 쓰지 않는 개발자"라는 개념이 더 이상 SF가 아니라 분기 실적 보고서에 등장하는 현실이 되었다는 것이다. 7억 5,100만 사용자의 앱을 만드는 사람들이 코드를 쓰지 않는다. 그 앱의 구독료는 오르고 있다. 그리고 그 사실을 투자자들은 호재로, 개발자들은 위협으로 읽고 있다. 같은 문장, 정반대의 해석. 그 간극이 좁혀지기 전에, 키보드 앞에 앉아 있는 사람들이 먼저 답해야 할 질문이 있다. 코드를 쓰지 않아도 되는 세상에서, 코드를 쓰는 나의 가치는 정확히 어디에 있는가.

출처: