Spotify 앱 출시 과정: 내부 구조 들여다보기 (2부)

기존에는 Jira에 모든 정보가 흩어져 있어 Release Manager가 탭을 오가며 상태를 확인해야 했고, Slack 문의까지 처리하느라 놓치는 정보가 생기기 쉬웠다. 이를 해결하기 위해 Spotify는 출시 관련 정보를 한 화면에 모으는 Release Manager Dashboard를 만들었다.

대시보드는 Release Manager는 물론 기본적인 모바일 출시 흐름을 아는 사람이라면 누구나 빠르게 상황을 파악할 수 있도록 설계됐다. 목표는 다음 네 가지였다.

• 컨텍스트 전환 최소화
• 인지 부담 감소
• 빠르고 정확한 판단 지원
• 릴리스 진행 상황의 한눈 파악과 세부 드릴다운

Spotify는 플랫폼과 버전의 조합을 track으로 보고, Android, iOS, Desktop을 각각 독립적으로 관리한다. 화면에는 각 track의 출시 상태, 차단 버그, sign-off 상태, RC 빌드 성공 여부, Build Verification Test 통과 여부, App Store 업로드 여부, 그리고 crashes, ANRs, CPU exceptions per song, daily active users 같은 품질·사용성 지표가 함께 표시된다.

Track에 속하지 않는 정보도 중요하다. 버전이 없는 blocking bug와 priority가 없는 bug를 따로 보여주며, 내부 보고와 외부 alpha/beta 테스터 리포트까지 포함해 소유 팀을 찾아가는 작업을 지원한다.

구현은 Spotify의 내부 개발 포털인 Backstage 위에서 진행됐다. React와 TypeScript로 만든 plugin이며, Software Catalog를 통해 앱 빌드 배포를 구성하고, app builds와 crashes 같은 다른 Backstage plugin과도 연결된다.

백엔드는 약 10개 시스템의 데이터를 수집·통합하는 API gateway 역할을 한다. 초기에 재조회가 너무 많아 느리고 비쌌지만, 캐싱과 5분 단위 사전 집계를 넣은 뒤 로딩 시간을 8초로 줄였고, 비용도 크게 낮췄다.

화면 구성은 색으로 상태를 빠르게 읽게 한다.

• Green: 다음 단계로 진행 가능
• Yellow: 처리 대기 중인 항목 존재
• Red: 즉시 조치가 필요한 오류

상단의 Production 영역은 이미 프로덕션에 올라간 Android, iOS, Desktop 버전의 crash 지표와 최근 24시간 rolling daily active users를 보여준다. Current와 Upcoming은 아직 롤아웃 전인 버전을 다루며, Current 예시에서는 iOS 8.9.2가 release-blocking bug, 미완료 regression test, 임계치를 넘는 crash rate 때문에 아직 준비되지 않은 상태로 표시된다.

ITGC 섹션은 IT general controls 테스트를 통과해야만 전체 production rollout이 가능하다는 점을 보장하고, Release Status Ping은 Slack 메시지를 생성해 출시 상태를 공유하는 링크다. Upcoming은 Current와 같은 구조지만 아직 적용되지 않는 항목이 회색으로 비활성화된다.

데이터를 5분마다 저장하면서 시간 흐름을 분석할 수 있게 되자, 가장 큰 병목은 두 가지로 드러났다.

• blocking bug를 테스트하고 수정하는 시간
• App Store approval을 기다리는 시간

또 하나의 문제는 수동 단계 전환이 업무 시간 밖에 완료되면 다음 단계로 넘어가는 데 최대 12시간이 지연될 수 있다는 점이었다. 이를 해결하기 위해 Spotify는 다음 상태로의 이동을 자동화하는 Robot을 만들었다.

Robot은 조건이 충족되면 다음 액션을 실행하는 백엔드 서비스이며, 예를 들어 수동 테스트 sign-off 완료, open bug 없음, 최신 git commit 기준 자동 테스트 성공 같은 조건이 충족되면 review 제출 같은 동작을 수행한다. 전체 흐름은 release branched, final release candidate, submitted for review, roll out 1%, roll out 100%에 더해 rollout paused, release cancelled까지 포함하는 상태 머신으로 관리된다.

이 자동화 덕분에 평균 release cycle은 약 8시간 단축됐다. 지금은 주로 메인 Spotify 앱에 적용하고 있지만, 앞으로는 더 작은 앱들에도 확장하려고 하며, 이를 위해 더 모듈화된 구조로 진화시키고 있다.

Spotify가 자체 시스템을 유지하는 이유도 분명하다. Backstage component를 재사용할 수 있고, Software Catalog의 데이터 모델을 기반으로 다른 팀이 릴리스 데이터를 조회할 수 있으며, org data를 활용해 bug를 관련 팀에 자동 할당하고 critical ticket 진행 상황을 ping할 수 있다. 무엇보다 모든 개발자가 이미 Backstage를 쓰고 있어 도입 마찰이 낮다.