스포티파이는 사내 엔지니어 99% 이상이 매주 AI 코딩 도구를 쓰고, PR(코드 변경 요청)이 76% 늘었습니다. 그런데 일이 줄어든 게 아니라, 병목이 다른 곳으로 옮겨갔습니다.
스포티파이의 수석 아키텍트이자 엔지니어링 부사장인 니클라스 구스타프손이 Code with Claude 2026에서 회사의 AI 전환 과정을 공유했습니다. 핵심은 두 가지입니다. 코딩 속도가 빨라지자 진짜 병목은 ‘코드를 쓰는 일’이 아니라 ‘사람이 무엇을 만들지 결정하고 검토하는 일’로 이동했다는 것. 그리고 수년 전부터 쌓아온 내부 개발 플랫폼이 사람뿐 아니라 AI 에이전트의 생산성까지 끌어올리는 토대가 되었다는 것입니다.
출처: Coding Is No Longer the Constraint – Spotify Engineering
코딩이 빨라지면 일이 줄어들까
스포티파이의 AI 코딩 도구 채택 속도는 회사가 경험한 어떤 사내 도구보다 빨랐습니다. 작년 말 Opus 4.5가 나오면서 특히 가팔라졌죠. 지금은 엔지니어의 99% 이상이 매주 AI 도구를 쓰고, 94%가 생산성이 올랐다고 답했으며, PR 빈도는 76% 늘었습니다. 대부분의 PR이 개발자와 AI 에이전트가 함께 만든 결과물입니다.
흥미로운 건 그다음입니다. PR이 76% 늘었다는 건 검토해야 할 코드도 76% 늘었다는 뜻입니다. 코드를 만드는 비용이 떨어지자, 부담은 사라진 게 아니라 ‘무엇을 통과시키고 무엇을 막을지’ 판단하는 쪽으로 옮겨갔습니다. 스포티파이는 안전한 변경은 자동 병합하고, 정말 중요한 곳에 사람의 판단을 집중하는 방식으로 적응하는 중이라고 말합니다. 시니어 엔지니어의 일이 ‘코드 작성’에서 ‘코드 검토와 결정’으로 무게중심을 옮기고 있는 셈입니다.
Honk, 뒤에서 알아서 일하는 코딩 에이전트
이 변화의 배경에는 수년에 걸친 준비가 있습니다. 몇 년 전 스포티파이는 프로덕션 코드베이스가 엔지니어 수보다 7배 빠르게 늘고 있다는 걸 발견했습니다. 개발자들은 점점 더 많은 시간을 유지보수에 썼습니다. 의존성 업그레이드, API 마이그레이션, 취약점 패치 같은 일이었죠. 마이그레이션은 개발자 불만 1순위였습니다.
수백 개 팀이 각자 컴포넌트를 하나씩 수동으로 고치는 대신, 스포티파이는 자동화로 수천 개를 한 번에 바꾸는 방식을 상상했습니다. 그렇게 나온 것이 Fleet Management이고, 지금까지 250만 건이 넘는 자동 유지보수 PR을 병합했습니다. 대부분 사람 손을 거치지 않고 자동 병합됐죠.
문제는 단순 변경에는 잘 작동하던 결정형 스크립트가 복잡한 코드 수정 앞에서 무너졌다는 점입니다. 수백만 줄, 수천 개 컴포넌트에 스크립트를 돌리면 온갖 예외 상황을 다 만나게 됩니다. 그래서 스포티파이는 점점 더 복잡한 스크립트를 짜는 대신 LLM에게 코드 수정을 맡기기로 했고, 그 결과물이 백그라운드 코딩 에이전트 Honk입니다. Honk는 다음과 같이 작동합니다.
- Fleetshift가 변경 대상을 식별하고 작업을 예약하며 진행 상황을 추적합니다.
- Honk가 그 사이에서 실제 코드 수정을 담당합니다. 내부적으로는 Agent SDK 위에서 Claude를 돌립니다.
- 수정한 코드는 여러 운영체제에서 CI 빌드를 직접 돌려 정상 작동하는지 검증합니다.
- 검증을 통과하면 PR을 만들어 올립니다.
이 방식으로 가장 최근 자바 마이그레이션을 사흘 만에 끝냈습니다. 예전이라면 수백 개 팀이 각자 몇 주에서 몇 달씩 매달렸을 일을, 이제 엔지니어 한 명이 며칠 만에 처리합니다. Honk는 슬랙에서도 부를 수 있어서, 대화 도중 멘션하면 문제를 받아 작업한 뒤 PR을 들고 돌아옵니다.
‘에이전트를 위한 개발자 경험’이라는 발상
이 글에서 개인 개발자가 가장 가져갈 만한 통찰이 여기 있습니다. 스포티파이의 오래된 원칙 중 하나는 “세계 최고 수준으로 잘하는 기술이 적을수록 더 빨리 간다”는 것입니다. 기술 스택을 좁게 표준화하면 전문성이 깊어지고 불필요한 선택이 사라진다는 생각이죠. 스포티파이의 백엔드 서비스는 대부분 서로 비슷하게 생겼습니다. 같은 기술 스택, 비슷한 설계 패턴.
이 원칙이 AI 시대에 예상치 못한 효과를 냈습니다. 참고할 코드가 많고 그 코드가 일관될 때, Claude가 눈에 띄게 더 잘 작동한다는 것입니다. 반대로 파편화된 코드베이스에서는 에이전트 성능이 측정 가능할 정도로 나빴습니다. 사람에게 좋은 일관성이 에이전트에게도 똑같이 좋았던 셈입니다.
스포티파이는 여기서 한 걸음 더 나아갑니다. 내부 개발자 포털인 Backstage의 기능을 MCP와 명령줄 도구로 노출해, Claude가 컴포넌트 소유자를 찾거나 문서를 읽거나 담당 팀에게 슬랙으로 연락할 수 있게 했습니다. 또 코드 표준에 어긋나는 패턴을 쓰면 린트 시스템이 즉시 피드백을 주고, Claude가 스스로 고칩니다. 사람을 위한 가드레일이 그대로 에이전트의 가드레일이 된 것입니다.
코딩 비용이 0에 가까워질 때
스포티파이의 결론은 단순합니다. 코딩 속도가 올라가자 제약은 인간의 의사결정 쪽으로 옮겨갔습니다. 이제 누구나 Claude를 열어 클라이언트 모노레포에서 며칠 걸리던 프로토타입을 몇 분 만에 만듭니다. CEO조차 이런 식으로 프로토타입을 만든다고 하죠.
여기서 읽어낼 수 있는 건, AI가 코드 작성을 대신해줄수록 ‘무엇을 만들지, 무엇을 통과시킬지’를 가르는 인간의 판단이 더 희소한 자원이 된다는 점입니다. 그리고 그 판단을 빠르고 안전하게 내릴 수 있는지는, 결국 코드베이스가 얼마나 일관되고 잘 정리되어 있는지에 크게 좌우됩니다. 거창한 AI 도구를 들이는 것보다, 에이전트가 일하기 좋은 환경을 먼저 만드는 쪽이 더 본질적인 투자일 수 있다는 이야기입니다. Honk의 구체적인 구현이나 자바 마이그레이션 사례의 세부 데이터가 궁금하다면 원문을 참고하시기 바랍니다.
답글 남기기