들어가며: "AI가 코드 짜면 품질 떨어지지 않나요?"
월간 활성 사용자 7억 7,700만 명, 초당 백엔드 요청 1,100~1,200만 건, 프로덕션 서비스 약 3,000개. Spotify 규모에서 품질은 늘 미해결 과제였어요. 그런데 AI 도입 이후 진짜 흥미로운 일이 벌어졌습니다.
AI slop(품질 낮은 AI 생성 코드) 때문이 아니었어요. 오히려 문제는 "변화의 속도" 그 자체였습니다. 코드를 만드는 능력이 검증하는 능력을 앞질러 버린 거죠.
이 글에서는 Spotify가 1년간 자사 데이터를 분석해 도출한 4가지 리스크 영역과, 그들이 실제로 무엇을 바꿨는지 실무 관점에서 뜯어봅니다.
💡 왜 이 글이 중요한가요? Google Cloud의 2025 DORA 리포트는 "AI 도입 → 처리량↑, 안정성↓"이라는 상관관계를 보여줬어요. 하지만 Spotify는 자사 데이터로는 그 트레이드오프가 보이지 않는다고 말합니다. 그 차이가 어디서 오는지가 핵심이에요.
근거자료: Spotify Engineering Blog
Spotify가 마주한 4가지 리스크 영역
1. 콘텐츠 처리 파이프라인: 조용한 실패(silent failure)
Spotify는 하루 50만 건 이상의 신규 곡/영상/팟캐스트/오디오북을 처리합니다. 여기서 두 가지 기존 약점이 드러났어요.
- 실패가 은폐됨: 처리 못 한 미디어 파일이 조용히 실패하고, 몇 시간 동안 아무도 모름 (페이지 알림이 안 감)
- 용량 부족: 트랜스코딩 용량이 소진되면 정상 영상 에피소드가 큐에서 대기하는데, 이걸 알려주는 알림이 없음
6월 24일 사고는 이 요인들이 겹쳤어요. 예약 배치 작업이 신규 에피소드와 경쟁 + 최근 품질 개선으로 에피소드당 연산량 증가 + 스케줄러 버그로 처리량 10% 감소. 결과적으로 몇 분이면 게시되던 에피소드가 몇 시간 지연됐습니다.
대응:
- E2E 모니터링 추가 (크리에이터보다 먼저 장애 인지)
- 스케줄러 버그 수정
- 배치 작업을 낮은 우선순위로 이동
- 용량 증설 + 서비스 티어링/워크로드 우선순위 재설계
# 개념적 워크로드 우선순위 예시
priority_classes:
- name: critical_services
weight: 100
- name: new_uploads
weight: 80
- name: bad_actor_episodes
weight: 5 # 억제 및 우선순위 대폭 하향
- name: batch_jobs
weight: 20 # 낮은 우선순위로 이동
2. 플릿 업데이트: 자동화가 만든 새로운 실패 모드
Spotify의 Fleet Management 프레임워크는 매일 대규모 변경을 자동 병합해요. 최근엔 Java 마이그레이션을 3일 만에 백엔드 서비스 전체에 완료**했다고 합니다. 그런데 자동화가 늘면 새로운 실패 모드도 생겨요.
사례: 자동 의존성 업그레이드가 검증은 통과했지만 프로덕션에서 실패 → 최종 사용자 영향
대응:
- 안전장치 강화
- 롤백 용량 확대
- 자동 변경을 소유 팀의 근무 시간에 스케줄링 ← 이거 실무에서 진짜 중요해요
3. 컴퓨트 부족: AI가 만든 간접적 품질 저하
업계 전반에서 AI 수요 급증 → CPU/GPU 공급 부족 → 예비 용량 감소. Spotify는 원래 "필요할 때 컴퓨트가 있다"는 전제로 운영했는데, 이제 그 전제가 깨졌어요.
지역 장애 시 다른 리전으로 트래픽을 넘기는 failover를 하는데, 예전엔 사소했던 문제가 용량 부족 상황에서는 사용자가 체감하게 됐습니다.
대응:
- 네트워크 엣지/티어링 재검토
- Failover 시 하위 티어 서비스는 용량이 없을 수 있음을 수용
- 5월 사고 후 예약 엣지 용량 2배 확보
- 서비스 메시 트래픽 수동 이동 → 엣지까지 확장 진행 중
4. 모바일 앱: 릴리스는 건강한데, 회귀는 누적된다
10년 넘게 반복된 사이클: 새 기능 빠르게 출시 → 품질 지표 악화 → 가드레일 강화 → 회복 → 새로운 이슈 등장 → 반복.
AI가 이 사이클의 주기를 짧게 만들었어요. 문제는 AI 코드가 나빠서가 아니라, 품질 측정 시스템이 빌드/배포 속도를 못 따라간 것입니다.
"개별 릴리스는 건강해 보이는데, 작은 회귀가 특정 폰에서 누적되거나, 우리가 안 보는 시그널에 숨어 있다."
대응: 품질 시그널 확대 + 장기 트렌드 지표 추가
데이터가 말해주는 것: 정말 품질-속도 트레이드오프인가?
Spotify는 매달 주요 장애 회고를 돌리면서 두 가지 질문을 추가했어요.
- AI가 작성한 코드가 이 장애에 직접 기여했나?
- 변경량 증가가 리뷰/테스트/롤아웃/관측성에 압박을 줬나?
결과
| 항목 | 발견 |
|---|---|
| AI 작성 코드의 직접 장애 기여 | ❌ 유의미한 증거 없음 |
| 변경량 증가의 검증 압박 | ✅ 관찰됨 |
| 병합된 PR 수 (8월 YoY) | 8,100 → 17,000 (2배 이상) |
| 품질/최적화 작업 비중 | 27% → 31% (절대량 2배 이상) |
| 유지보수/설정 비중 | 31% → 25% |
| 코드 churn | 상승 (FAROS 2026 리포트와 일치) |
| Rework rate | 상승 없음 ← 핵심 시그널 |
Churn vs Rework Rate, 뭐가 다른가요?
- Code churn: 추가된 코드 대비 삭제된 코드 비율
- Rework rate: 변경되는 코드의 **나이(age)**를 가중치로 반영 → 최근 작업이 잘 버티는지 더 정확히 측정
해석: 업계 전반에서 churn은 급증했지만, Spotify는 rework rate가 오르지 않았다 → AI로 인한 품질 부채가 누적되고 있지 않다는 신호.
⚠️ 주의: 두 가지 경고 신호
- 코드 복잡도 상승
- PR 크기 증가
AI 이전엔 이 둘 다 명확한 품질 우려였어요. 그런데 지금은 인간과 에이전트가 함께 더 큰 작업 단위를 안전하게 배포한 결과일 수도 있어요. Spotify는 두 가설 중 어느 쪽도 확신이 없어서, 임계값을 자기 위안용으로 조정하지 않고 계속 관찰한다고 밝혔습니다. 이게 진짜 성숙한 태도예요.
이 기술의 한계와 주의사항
- Spotify 규모의 데이터는 재현 불가: 3,000개 서비스, 초당 1,100만 요청 규모에서 관찰된 결과가 스타트업이나 중소 규모 팀에 그대로 적용되지 않아요.
- "직접 기여 없음"은 "무관함"이 아님: AI 코드가 장애의 직접 원인은 아니었지만, 변경량 자체를 늘려 간접적으로 검증 시스템에 부담을 준 것은 확인됐어요.
- DORA 리포트와 상충: DORA는 안정성 하락을, Spotify는 트레이드오프 없음을 주장 → 컨텍스트(팀 성숙도, 검증 자동화 수준)에 따라 결과가 달라진다는 게 정확한 해석입니다.
- 복잡도/PR 크기 임계값 재검토는 아직 미결: 지금 기준을 그대로 쓰는 것도, 바꾸는 것도 위험한 상황이에요.
한국 개발 생태계에 던지는 시사점
국내 SI/스타트업 환경에서는 이 부분이 특히 주의가 필요해요.
Spotify처럼 3,000개 서비스 규모가 아니더라도, **"변경량 > 검증 능력"**이 되는 순간은 누구에게나 옵니다. 특히:
- 리뷰 병목: AI로 PR 생성 속도만 올리면, 리뷰어가 병목이 돼요. Spotify가 PR 크기 증가를 경고 신호로 보는 이유입니다.
- 관측성 부족: 국내 많은 팀이 여전히 로그 기반 디버깅에 의존해요. Spotify가 E2E 모니터링을 최우선으로 꼽은 건 시사하는 바가 커요.
- 롤백 자동화: "롤백 용량 확대"라는 표현 자체가 낯선 팀이 많을 거예요. 배포만 자동화하고 롤백은 수동인 팀은 AI 도입 전에 이걸 먼저 정비해야 합니다.
다음 단계 학습 방향
- DORA 2025 리포트 원문 읽기 — AI 도입과 안정성의 상관관계 데이터
- FAROS 2026 리포트의 churn 분석 — 업계 전반 트렌드 파악
- Rework rate 직접 측정해보기 — 자사 리포지토리에서 코드 나이 기반 지표 뽑아보세요
- 워크로드 우선순위/티어링 설계 — 배치 작업과 크리티컬 서비스 분리
마무리: 결국 "검증 시스템"이 병목이다
Spotify의 결론은 명확해요.
"AI는 변화를 만들어내는 능력을 키웠다. 다음 제약은 그것을 검증하는 능력이었다."
AI가 짠 코드의 품질 논쟁은 부차적이에요. 진짜 싸움은 리뷰, 테스트, 롤아웃, 관측성, 롤백, failover, 품질 측정이 개발 속도와 같은 페이스로 움직이게 만드는 것입니다.