AI Changed How Spotify Builds. What We Learned (and Fixed) About Quality at Higher Velocity

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Spotify는 AI 도입 후 변경 속도가 검증 통제의 적응 속도를 앞선 것을 품질 과제로 진단하고, AI 작성 코드의 뚜렷한 직접 장애 기여는 확인하지 못한 가운데 모니터링·배포·롤백·용량 관리·품질 측정을 강화하고 있다.

📌 핵심 요약

• Spotify는 월간 활성 사용자 7억 7,700만 명, 2,000종 이상의 지원 기기, 약 1억 개의 동시 접속 클라이언트를 지원하며, 초당 1,100만~1,200만 건의 백엔드 요청과 약 3,000개의 프로덕션 서비스를 운영한다.
• 매일 50만 건 이상의 신규 콘텐츠를 처리하는 과정에서 실패 알림과 용량 관리의 기존 취약점이 드러났다. 6월 24일에는 배치 작업과 신규 에피소드의 자원 경쟁, 에피소드당 연산량 증가, 처리량을 약 10% 낮춘 스케줄링 버그가 겹쳐 게시가 수 시간 지연됐으며, 이후 모니터링·스케줄러·우선순위·용량을 개선했다.
• Fleet Management를 통한 자동 변경은 백엔드 서비스의 Java 마이그레이션을 3일 만에 완료할 만큼 빨라졌지만, 안전 검사를 통과한 의존성 업그레이드가 실제 운영 환경에서 실패하기도 했다. Spotify는 안전장치와 롤백 역량을 강화하고 자동 변경을 담당 팀의 근무 시간에 진행하도록 대응하고 있다.
• AI 수요 증가에 따른 업계 CPU·GPU 용량 부족은 리전 장애 전환의 영향을 키웠다. Spotify는 5월 사고 이후 예약 엣지 용량을 두 배로 늘렸으며, 모바일 앱에서는 개별 릴리스 점검이 놓칠 수 있는 누적 품질 저하를 포착하도록 품질 신호와 장기 추세를 확대했다.
• 현재까지 검토한 사고에서 AI 작성 코드의 중대한 직접 기여는 확인되지 않았지만, 변경량은 일부 검증 통제의 적응 속도보다 빠르게 증가했다. 8월 병합 변경은 전년 약 8,100건에서 17,000건으로 늘고 품질·최적화 작업 비중은 27%에서 31%로 상승했으며, 재작업률의 상응하는 상승은 관찰되지 않았다. 코드 복잡도와 PR 크기는 증가하고 있어 기존 임계값을 유지하며 관찰 중이다.

🧩 주요 포인트

1. 콘텐츠 처리·Fleet Management·리전 장애 전환에서 서로 다른 취약점이 드러남 → 실패 탐지, 자원 우선순위, 자동 변경 안전장치와 복구 역량을 함께 강화할 필요가 있다.
2. 병합 변경량과 품질·최적화 작업이 함께 증가하고 재작업률은 상응해 상승하지 않음 → Spotify는 속도 향상을 단순한 코드 품질 희생으로 해석하지 않지만, 사고 검토에서 드러난 검증 통제의 지연은 별도로 해결하고 있다.
3. 모바일 앱의 누적 품질 저하와 코드 복잡도·PR 크기 증가가 관찰됨 → 개별 릴리스의 정상 여부를 넘어 장기 추세를 살피고, 검증되지 않은 가설을 근거로 품질 임계값을 완화하지 않는다.

🧠 상세 정리

1. 규모가 큰 시스템에서 변화 속도가 만든 압력

Spotify는 서로 연결된 마이크로서비스와 데이터 파이프라인을 통해 월간 활성 사용자 7억 7,700만 명에게 서비스를 제공하며, 지원 기기는 2,000종을 넘는다. 어느 순간이든 약 1억 개의 클라이언트가 동시에 접속하고, 백엔드는 초당 1,100만~1,200만 건의 요청을 처리하며, 프로덕션 서비스는 약 3,000개에 이른다. 이 규모에서는 AI 도입 이전에도 시스템 한 부분의 약점이 청취자와 창작자에게 빠르게 영향을 줄 수 있었으므로, 품질은 이미 해결된 문제가 아니었다. 글은 최근 콘텐츠 처리, 자동화된 대규모 변경, 연산 자원 부족, 모바일 앱 경험이라는 네 영역이 동시에 시험대에 올랐다고 설명한다. Spotify가 핵심 원인으로 지목한 것은 저품질 AI 산출물 자체가 아니라 회사 내부와 업계 전반에서 빨라진 변화의 속도이며, 이에 맞춰 품질 유지 방식을 조정해야 했다는 점이다.

2. 콘텐츠 게시 지연의 원인과 처리 체계 개선

Spotify는 매일 50만 건 이상의 새 음악·동영상·팟캐스트·오디오북을 처리하며, 빠르게 늘어나는 콘텐츠를 신속하고 안정적으로 공개하는 일이 창작자에게 중요하다고 설명한다. 기존 처리 체계에는 미디어 처리 실패가 담당자를 호출하는 알림 없이 묻혀 게시 영향을 수 시간 동안 알아채지 못하는 문제와, 동영상 변환 용량이 소진되면 정상 에피소드도 알림 없이 대기하는 문제가 있었다. 6월 24일에는 예약 배치 작업이 신규 에피소드와 자원을 두고 경쟁하고, 최근 품질 개선으로 에피소드당 연산량이 늘어난 데다 스케줄링 버그가 처리량을 약 10% 줄이면서 통상 수 분이던 게시 시간이 수 시간으로 길어졌다. 이후 Spotify는 전체 처리 경로의 모니터링을 추가하고 스케줄러를 수정했으며, 배치 작업의 우선순위를 낮추고 용량을 확대했다. 서비스 등급과 작업 우선순위도 재정비해 중요한 서비스와 신규 업로드를 우선 처리하고, 악의적 행위자의 에피소드를 억제하고 우선순위를 낮춰 부하와 자원 경쟁을 줄였다. AI는 개선 작업을 더 빨리 제공하는 데 도움이 됐지만, 원인 해결에는 여전히 엔지니어의 판단과 전체 흐름을 보는 관점 및 역량이 필요했다.

3. Fleet Management의 가속과 자동 변경의 실패 위험

Spotify의 자체 Fleet Management 프레임워크는 수년간 서비스 전반에 매일 대규모 변경을 적용해 왔으며, 대부분의 변경은 안전 검사를 통과하면 자동으로 병합된다. 최근 1년 넘게는 에이전트가 수행하는 더 복잡한 변경까지 지원 범위를 넓혔고, 백엔드 서비스 전반의 Java 마이그레이션을 3일 만에 완료한 사례도 있었다. 이런 가속은 엔지니어가 반복적이고 단조로운 업무에 쓰는 부담을 더 줄였지만, 자동화 규모의 확대는 새로운 실패 양상도 만들었다. 올해 발생한 자동 의존성 업그레이드는 기존 검사를 통과했음에도 프로덕션에서 실패해 최종 사용자에게 영향을 줬다. Spotify는 이에 대응해 안전장치를 강화하고 롤백 역량을 확대하며, 자동 변경을 해당 서비스 담당 팀의 근무 시간에 진행하도록 조정하고 있다.

4. 연산 자원 부족이 리전 장애 전환에 미친 간접 영향

글은 업계 전반의 AI 활용 증가가 CPU와 GPU 수요를 급격히 늘렸지만 공급은 그만큼 확대되지 않아 여유 용량이 줄었다고 설명한다. Spotify는 오랫동안 필요할 때 연산 자원을 확보할 수 있는 환경에서 운영해 왔으나, 이제는 한 리전의 장애로 다른 리전에 트래픽을 넘길 때 수용 용량을 예측하기 어려워졌다. 올해 리전 장애 전환에서는 자원 부족이 과거에는 사소하고 눈에 띄지 않던 문제를 증폭시켜 사용자에게 영향을 줬으며, 회사는 이를 AI가 서비스 품질에 미친 간접 영향으로 구분한다. 이에 네트워크 엣지와 서비스 등급별 처리 방식을 재검토하고, 장애 전환 시 하위 등급 서비스에 충분한 용량이 없을 가능성을 받아들이는 동시에 프로덕션 서비스의 복원력을 강화하고 있다. 5월 사고 뒤 예약 엣지 용량을 두 배로 늘렸고, 현재 내부 서비스 메시 트래픽 일부는 수동으로 전환할 수 있지만 이 제어를 엣지 트래픽으로 확대하는 작업과 리전 간 부하 분산 시험은 진행 중이다. 목표는 수신 리전이 추가 부하를 안정적으로 감당할 수 있는지 확인하면서 트래픽을 점진적으로 이동하는 것이다.

5. 모바일 앱에서 개별 릴리스 점검을 넘어선 품질 관찰

Spotify는 10년 넘게 모바일 앱에서 새 기능을 빠르게 출시하려는 집중과 경험 품질의 회복 사이를 오가는 흐름을 경험했다고 설명한다. 품질 악화 신호가 쌓이면 인력과 유인을 품질 개선으로 돌리고 보호 지표를 확장해 회복하지만, 시간이 지나면 기존 지표가 포착하지 못하는 새로운 문제가 생겨 같은 과정이 반복됐다. AI는 변경 속도를 높여 이 주기를 더 짧게 만들고 측정의 빈틈을 더 빨리 드러냈으며, 회사는 이를 AI 지원 코드가 본질적으로 낮은 품질이라는 문제와 구분한다. 기존 출시 과정에도 프로덕션 배포 전의 명시적 점검 단계가 있었지만, 개별 릴리스가 정상으로 보여도 작은 품질 저하가 누적되거나 특정 휴대전화에 집중되거나 관찰 대상 밖에 남을 수 있었다. Spotify는 이런 악화를 더 일찍 찾아내도록 품질 신호의 범위를 넓히고, 출시 관련 판단에 장기 추세도 반영하기 시작했다.

6. 외부 연구의 문제 제기와 내부 사고 데이터의 구분

Google Cloud의 2025 DORA 연구는 AI 도입이 높은 전달 처리량 및 제품 성과와 연관되는 동시에 소프트웨어 전달 안정성 저하와도 연관된다고 보고했다. Spotify는 회사마다 상황이 다르다는 점에서 자체 데이터를 살펴보기로 했고, 품질의 궁극적 측정 대상으로 프로덕션 사고를 우선 검토했다. 매월 주요 사고를 회고하는 기존 절차에 AI 작성 코드가 사고에 직접 기여했는지, 늘어난 변경량이 검토·테스트·출시·관측 가능성에 추가 압력을 가했는지라는 두 질문을 더했다. 현재까지 검토한 사고에서는 AI 작성 코드가 중대한 직접 기여 요인이라는 근거를 확인하지 못했지만, 변경량이 일부 검증 통제의 적응 속도보다 빠르게 늘어난 위험은 관찰했다. 따라서 대응의 초점은 검토, 테스트, 출시, 관측 가능성, 롤백을 포함하는 전달 체계 전체를 강화하는 데 놓여 있으며, 이 결과는 검토된 사고 범위에서의 관찰로 제시된다.

7. 변경 구성과 재작업률이 보여 준 품질 투자

Spotify는 병합된 PR을 기능, 코드 품질·최적화, 유지보수, 문서화 등의 작업 내용으로 분류해 개발 과정에서도 속도와 품질의 교환 관계가 나타나는지 살폈다. 8월 전체 병합 변경은 전년 약 8,100건에서 17,000건으로 두 배 이상 늘었고, 품질·최적화 작업의 비중은 27%에서 31%로 상승해 해당 작업의 절대량도 두 배 이상 증가했다. 기능 작업 역시 늘어난 반면 유지보수·설정 작업 비중은 31%에서 25%로 줄었으며, 회사는 품질·최적화 투자의 절대적·상대적 증가를 단순한 품질 희생으로 볼 수 없는 근거 중 하나로 제시한다. 또한 실제 재작업을 신규 작업 및 레거시 리팩터링과 구분하도록 재작업률 지표를 다시 구성하고, 추가된 코드 대비 삭제된 코드의 양을 보는 코드 변동량과 달리 수정 대상 코드의 나이를 가중해 최근 작업이 얼마나 유지되는지 살폈다. FAROS 2026 보고서는 업계 전반의 코드 변동량이 급증했다고 밝혔지만 Spotify에서는 이에 상응하는 재작업률 상승이 없었으며, 회사는 이를 AI로 인한 품질 부채가 쌓이지 않는다는 뚜렷한 신호로 해석했다.

8. 남은 경고 신호와 검증 역량이라는 다음 제약

Spotify가 계속 주시하는 경고 신호는 서서히 증가하는 코드 복잡도와 PR 크기이며, AI 도입 전에는 둘 다 분명한 품질 우려로 간주됐다. 회사는 이제 큰 PR이 사람과 에이전트가 함께 추론해 더 큰 작업 단위를 안전하게 완성했다는 뜻일 수 있고, 한 사람이 머릿속에 담을 수 있는 범위를 기준으로 정한 복잡도 임계값도 그대로 적용되지 않을 수 있다는 가설을 제시한다. 다만 어느 가설에도 확신이 없으므로 안심하기 위해 임계값을 바꾸지는 않으며, 이 지표들이 실제 선행 위험 신호인지 계속 관찰할 방침이다. 올해 일부 영역에서 자체 품질 기준에 미치지 못했다는 점을 인정하면서도, 조사한 데이터에서는 AI 작성 코드만의 뚜렷한 직접 실패 양상이 나타나지 않았다고 설명한다. 글의 결론은 AI가 변경을 생산하는 역량을 늘린 뒤 그 변경을 검증하는 역량이 다음 제약이 됐다는 것으로, 자동 안전장치·롤백·관측 가능성·장애 전환·품질 측정이 개발 속도에 맞춰 작동하도록 지속적으로 개선해야 한다는 것이다.

🧾 핵심 주장 / 시사점

• AI 작성 코드의 직접 장애 기여와 AI가 늘린 변경량의 운영 부담은 구분해서 평가할 필요가 있다. Spotify의 사고 검토에서는 전자보다 검증 통제가 변화 속도를 따라가지 못하는 후자가 확인됐다.
• 품질·최적화 작업량 증가와 재작업률 안정은 코드 품질 투자에 관한 긍정적 신호지만, 콘텐츠 처리 용량이나 리전 장애 전환의 안정성까지 대신 설명하지는 않는다.
• 개별 릴리스 점검과 장기 추세 관찰은 서로 다른 문제를 포착한다. Spotify는 누적 품질 저하를 측정 범위에 추가하면서도 코드 복잡도와 PR 크기에 대한 불확실성을 이유로 기존 임계값을 완화하지 않았다.

✅ 액션 아이템

• 콘텐츠 처리와 Fleet Management에서 드러난 취약점을 바탕으로 실패 탐지, 자원 우선순위, 자동 변경 안전장치와 롤백 역량 강화 지속.
• 모바일 앱의 누적 품질 저하를 포착하도록 개별 릴리스 점검과 장기 추세를 함께 검토.
• 코드 복잡도와 PR 크기는 기존 임계값을 유지하며 관찰하고, 재작업률과 품질·최적화 작업 변화도 함께 평가.

❓ 열린 질문

• 병합 변경이 약 8,100건에서 17,000건으로 늘어난 상황에서 검증 통제가 변경 속도를 따라잡았는지는 어떻게 판단할 수 있는가?
• 코드 복잡도와 PR 크기 증가는 향후 품질 저하를 예고하는 신호인가?
• 예약 엣지 용량을 두 배로 늘린 조치가 CPU·GPU 용량 부족 상황에서 리전 장애 전환의 사용자 영향을 얼마나 줄일 수 있는가?