도입 전략
이 문서는 Spotify 안에서 Backstage의 성공에 핵심이었던 몇 가지 일반적인 모범 사례를 정리해요. 조직마다 달라서 이 학습 내용 중 일부는 회사에 적용되지 않을 수도 있어요. 이 문서가 살아 있는 문서가 되기를 바라며, 회사에서 Backstage를 도입하며 얻은 학습 내용을 적극적으로 기여해 주시길 강력히 권장해요.
출처: 문서
본문
이 문서는 Spotify 안에서 Backstage 성공에 핵심이었던 몇 가지 일반적인 모범 사례를 정리해요. 조직마다 달라서 이 학습 내용 중 일부는 회사에 적용되지 않을 수도 있어요. 이 문서가 살아 있는 문서가 되기를 바라며, 회사에서 Backstage를 도입하며 얻은 학습 내용을 기여해 주시길 강력히 권장해요.
조직 구성
Backstage의 진정한 가치는 회사에서 그것이 THE 개발자 포털이 되어야 비로소 드러나요. 따라서 Backstage 배포를 소유하고 제품처럼 다루는 중앙 팀이 필요하다는 점을 인지하는 것이 중요해요.
이 팀에는 네 가지 핵심 목표가 있어요.
- Backstage 배포를 유지·운영하기. 고객 지원, 인프라, CI/CD를 포함하며, Backstage 제품이 성장함에 따라 온콜(on-call) 지원도 포함돼요.
- 고객(회사 내 개발자)의 채택을 이끌어 내기.
- 시니어 기술 리더십 및 아키텍트와 협력해 조직의 소프트웨어 개발 모범 사례가 일련의 Software Templates에 담기도록 하기.
- 다른 인프라/플랫폼 팀을 상대로 Backstage를 중앙 플랫폼으로 전파(evangelize)하기.
내부 전파
마지막 목표는 가장 덜 명확하면서도 통합된 플랫폼을 성공적으로 만드는 데 가장 중요하기 때문에 더 주목할 필요가 있어요. 제대로 하면 Backstage는 인프라/플랫폼 팀과 최종 사용자 사이의 "플랫폼 중의 플랫폼" 또는 마켓플레이스 역할을 해요.
회사 누구나 플랫폼에 기여할 수 있지만, 작업의 대부분은 내부 엔지니어를 고객으로 둔 팀이 수행해요. 중앙 팀은 이런 기여 팀들도 플랫폼의 고객으로 대해야 해요.
이 팀들은 자율적으로 고객에게 직접 가치를 전달할 수 있어야 해요. 이는 주로 플러그인을 만들어 이루어져요. 기여 팀은 자신의 플러그인을 자체적으로 유지하는 제품 또는 제품의 일부로 여겨야 해요.
사례 연구: Spotify 안에는 CI 플랫폼을 소유한 팀이 있어요. 그들은 파이프라인과 빌드 서버를 유지할 뿐 아니라, 플러그인을 통해 Backstage에 제품을 노출해요. 자체 API도 유지하므로 API와 UI를 함께 반복해 제품을 개선할 수 있어요. 플러그인이 플랫폼 디자인 가이드라인을 따르기 때문에 그들의 고객은 플랫폼의 다른 도구와 일관된 CI 경험을 얻을 수 있어요(사용자가 Jenkins 전문가가 될 필요도 없어요).
전술
내부적으로 Backstage를 전파하기 위해 사용한 전술의 예시는 다음과 같아요.
- "Lunch & Learns"와 세미나 주최하기. Backstage 개발에 관심 있는 팀에 자주 세미나 참석을 제안해, 예를 들어 처음부터 플러그인을 만드는 방법을 보여 주세요.
- 임베딩(Embedding). 기여 팀이 첫 플러그인 개발을 시작할 때 중앙 팀에서 한 명이 와서 한두 스프린트 동안 "임베드"해 주면 매우 고마워하는 경우가 많아요.
- 핵 데이(Hack days). Backstage 중심의 핵커톤이나 핵 데이는 사람들을 플러그인 개발로 이끄는 재미있는 방법이에요.
- 쇼앤텔(Show & tell) 미팅. Backstage 주변에 내부 커뮤니티를 만들기 위해 분기별로 미팅을 열어 Backstage에서 작업하는 모든 사람이 작업 내용을 발표하도록 초대해요. 이는 초기 피드백을 얻는 좋은 방법일 뿐 아니라, 겹치는 경험을 만드는 팀 사이의 조정에도 도움이 돼요.
- 지표 제공. Backstage 배포에 계측(instrumentation)을 추가하고 기여 팀이 지표를 사용할 수 있게 하세요. Spotify에서는 개별 플러그인의 사용 지표 변화를 보여 주는 주간 다이제스트 이메일을 보낼 정도까지 나갔어요.
- 새 플러그인을 선제적으로 발굴하기. Backstage로 통합하는 것이 합리적이라고 생각하는 내부 사용자 인터페이스나 플랫폼을 소유한 팀에 먼저 연락하세요.
KPI와 지표
Backstage가 소프트웨어 개발 프로세스에 성공적인 영향을 미치고 있는지 검증하는 데 사용할 수 있는 지표는 다음과 같아요.
- 온보딩 시간 - 새 엔지니어가 생산적이 되기까지의 시간. Spotify에서는 직원이 10번째 PR을 머지할 때까지의 시간으로 측정해요 (이 지표는 Backstage 배포 2년 후 55% 감소했어요). 빠르게 엔지니어를 온보딩하지 않더라도, 이 지표는 생태계의 전반적 복잡성을 대변하는 좋은 대리 지표예요. 따라서 이를 줄이는 것은 신규 입사자뿐 아니라 엔지니어링 조직 전체에 도움이 돼요.
- 개발자 1인당 일일 머지 횟수 - 서로 다른 도구를 오가며 정보를 찾는 데 쓰는 시간이 줄면 코드를 배포하는 데 집중할 시간이 늘어나요. 기여를 도메인(서비스, 웹, 데이터 등)별로 분류하면 두 번째 수준의 병목도 식별할 수 있어요.
- 프로덕션 배포 - 위 지표와 비슷한 것으로, 엔지니어가 변경 사항을 프로덕션에 얼마나 자주 푸시하는지예요.
- MTTR - 마이크로서비스 생태계의 모든 구성 요소에 명확한 소유권이 있고 모든 도구가 한곳에 통합되어 있으면, Backstage는 팀이 장애의 근본 원인을 더 빨리 찾고 고치게 해줘요.
- 컨텍스트 스위칭 - 컨텍스트 스위칭을 줄이면 엔지니어가 "몰입 상태"를 유지하는 데 도움이 돼요. 특정 작업(예: 변경 사항 푸시, 프로덕션까지 추적, 뭔가 깨지지 않았는지 검증)을 수행하기 위해 엔지니어가 상호작용해야 하는 서로 다른 도구의 수를 측정해요.
- T자형(T-shapedness) - T자형 엔지니어는 엔지니어링의 여러 도메인에 기여할 수 있는 사람이에요. T자형 인력이 있는 팀은 병목이 적어 더 일관되게 전달할 수 있어요. Backstage는 도구와 인프라가 도메인 간에 일관되고 정보가 중앙에서 제공되므로 T자형이 되기 더 쉬워요.
- eNPS - 사람들이 얼마나 생산적이라고 느끼는지, 정보를 찾기 얼마나 쉬운지, 내부 도구에 대한 전반적 만족도를 묻는 설문이에요.
- 프래그멘테이션(Fragmentation, 실험적) - Backstage Software Templates는 소프트웨어 생태계의 표준화를 이끄는 데 도움이 돼요. 서로 다른 소프트웨어 구성 요소 간 기술의 분산(variance)을 측정하면 생태계의 전반적 프래그멘테이션을 가늠할 수 있어요. 예로는 프레임워크 버전, 언어, 배포 방식, 다양한 코드 품질 측정이 있을 수 있어요.
또한 다음 대리 지표를 사용해 Backstage가 플랫폼으로서 성공했는지 검증할 수 있어요.
- 플러그인을 하나 이상 기여한 팀 수 (현재 Spotify 내 63개 팀).
- 총 플러그인 수 (현재 Spotify 내 135개).
- 중앙 Backstage 팀 외부에서 온 기여 비율 (현재 Spotify 내 85%).
- 방문(MAU, DAU 등) 및 페이지 뷰 같은 전통적 지표. 현재 Spotifier의 약 50%가 월 단위로 Backstage를 사용하며, 엔지니어 비율은 50% 미만이에요. 실제로 대부분의 엔지니어는 매일 Backstage를 사용해요.
다시 말하지만 어떤 피드백이든 감사해요. 페이지 하단의 Edit 버튼을 사용해 제안해 주세요.
참고
Backstage 사용량과 "참여도"를 최적화하고 싶은 유혹이 있을 수 있어요. 모든 도구와 기술 문서를 Backstage로 통합하고 싶겠지만, Backstage에서 보내는 시간은 코드를 작성하지 않는 시간임을 기억하는 것이 중요해요 🙃