How Spotify Builds Products(스포티파이의 제품 개발 방법)

이 글은 “THE LEAN MINDSET” 에서 발췌한 글이다.

How Spotify Builds Products

Written and illustrated by Henrik Kniberg

제품 개발은 쉽지 않다. 사실 제품 개발은 대부분 실패로 끝난다. 그리고 가장 중요한 실패 원인은 부적절한 제품을 만들었기 때문이다.

스웨덴의 린 스타트업인 스포티파이는 멋진 제품을 제공하고 있다. 사용자와 아티스트들은 이들의 제품을 사랑하여, 제품은 바이럴 효과를 통해 퍼지고 있다. 활성 사용자는 2천만 명이 넘고, 그중 5백만명이 유료 사용자이며, 회사는 빠르게 성장하고 있다. 이미 기존 업체들이 많이 자리 잡은, 스포티파이 입장에서는 해외 시장인 미국에서도 서비스를 시작한지 1년이 채 되지 않아 가입자가 1백만명으로 증가했다.

제품은 쉽고 친근하고 재미있도록 설계된다. 그러나 역설적이게도 기업은 사람들이 좋아하는 제품을 제공하고 싶어 하지만, 제품을 내놓기 전까지는 사람들이 그 제품을 좋아할지 알 수 없다. 그렇다면 스포티파이는 이런 역설을 어떻게 해결하고 있을까? 이 절에서는 스포티파이의 제품 개발 방법에 대해 살펴본다.

요약

스포티파이의 핵심 철학은 다음과 같다.

• 조기에 저렴한 비용으로 프로토타입을 만들어 리스크를 관리하는 동시에 혁신적인 제품을 만든다.
• 출시 예정일이 아니라 품질을 기준으로 출시 여부를 판단한다.
• 출시 이후에도 계속 제품을 수정하여 훌륭한 제품이 더 훌륭하게 되도록 만든다.

모든 주요 제품 이니셔티브(initiative)는 생각(Think), 구축(build), 전달(ship), 수정(tweak)의 4단계를 거친다. 그림 4-3은 아이디어가 제품이 되기까지의 흐름과 각 단계의 결과물을 보여준다.

Figure 4-3 High-level view of product flow from idea to product

• Think It = 어떤 종류의 제품을 왜 구축할지 생각한다.
• Build It = 실제 사용자에게 공개할 만한 최소 존속 제품을 만든다.
• Ship It = 평가하고 개선하며넛 모든 사용자에게로 공개 범위를 점차 넓힌다.
• Tweak It = 제품을 계속 개선한다. 이것이 진짜 마지막 단계이다. 제품이 폐기되거나 다시 생각(Think It) 단계로 돌아가기 전까지 계속 수정 단계에 머무른다.

스포티파이에는 30개 이상의 스쿼드(Squads)와 많은 제품이 있기 때문에, 전체 상황을 파악하고 각각의 상황을 다른 부서에 시각적으로 보여주기 위해 제품 현황판을 이용한다. 이 제품 현황판은 각 제품이 어떤 단계에 있는지 알려준다. 그림 4-4는 제품 현황판의 개략적인 모습이다.

또한, 우리는 예측 메커니즘을 실험하고 있는데, 각 스쿼드는 자신의 제품이 언제 다음 단계에 도달할지 예상 날짜 범위(X일에서 Y일 사이)를 주기적으로 업데이트 한다.

왜 4단계인가?

가장 큰 리스크는 부적절한 제품, 즉 사용자를 기쁘게 하지 못하거나 사용자 확보, 사용자 유지 같은 핵심 사업 자료를 개선하지 못하는 제품을 만드는 것이다. 우리는 이것을 ‘제품 리스크’라고 부른다.

4단계 모델을 이용하면 효과적으로 리스크를 줄이고 제품을 빨리 출시할 수 있다. 그림 4-5는 각 단계마다 제품 리스크가 어떻게 줄어들고(실선), 비용은 얼마나 들어가는지(점선)보여준다.

Figure 4-4 Portfolio board

Figure 4-5 Risk-versus-cost curve for four-stage model of product development

여기서 볼 수 있듯이 생각 단계는 적은 비용으로 리스크를 크게 줄인다. 그리고 구축 단계를 가능한 단축시키려는 이유를 알 수 있을 것이다. 이 단계에서는 비용은 많이 들고 리스크는 거의 감소하지 않기 때문이다. 수정 단계에서 비용이 점차 줄어 드는 것은 시간이 지나면서 제품을 그다지 많이 업데이트할 필요가 없어지고 스쿼드가 다른 제품 개발로 옮겨갈 수 있는 점이 반영된 것이다.

각 단계의 길이는 다른 수 있다. 그림 4-5의 단계들의 길이 비율은 단지 예시일뿐이다. 전체 시간도 달라질 수 있다. 어떤 제품은 한두 달 만에 제품화 될수 있지만 다른 제품은 반년 이상 걸리기도 한다. 그러나 각 단계 안에서 릴리즈(내부 릴리즈일지다로)는 꽤 지속적으로 이루어진다.

그럼 각 단계를 좀 더 자세히 살펴보자.

생각단계

제품 아이디어는 항상 탄생하며 직원 누구가 제품 아이디어를 내놓을 수 있다. 아이디어 대부분은 기존 제품을 개선하는 것(수정)이며, 수정 아이디어는 스쿼드가 자체적으로 구현하고 릴리즈한다.

생각 단계는 누구나 완전히 새로운 제품 아이디어를 내놓거나 기존 제품을 새롭게 재탄생시키고자 하는 경우에 해당한다.

Figure 4-6 The Think It Stage

만약 경영진이 그 아이디어가 검토할 가치가 있다고 판단하면, 여러 기능이 포함된 소규모의 생각 스쿼드가 조직된다. 이 스쿼드는 보통 개발자 한명, 디자이너 한명, 제품 리더 한 명으로 구성된다. 이들의 힐은 제품을 정의하고 매력적인 프로토타입을 만드는 것이다.

제품 정의는 다음 질문에 답하는 짧은 문서로 표현된다.

• 왜 이 제품을 구축해야 하는가? 이 제품으로 어떻게 누가 혜택을 볼 것인가?
• 이 제품은 어떤 핵심지표를 개선할 것으로 예상되는가? 이 질문은 얼마나 많은 음악이 스트리밍으로 재생되는가? 얼마나 많이 다운로되는가? 얼마나 많이 로그인하는가? 등으로 측정할 수 있다.
• 어떤 가설이 뒷받침되어야 하는가? 이 제품이 성공적인지 어떻게 알 수 있는가?
• 이것은 ‘큰 변화‘(즉 관련지표를 2배 이상 개선할 것으로 예상되는 제품)인가? 예상되는 지표개선 폭이 작다면 이 제품을 구축할 다른 강력한 이유, 가령 전략적 이유 같은 것이 있어야 한다.

제품 정의는 요구사항 명세서나 프로젝트 기획서가 아니다. 제품 정의에는 특징 목록이나 예산, 자원 계획 같은 것이 없다. 이것은 데이터를 바탕으로 작성된 목적 기술서와 더 비슷하다. 제품 정의에서 가장 중요한 부분은 내러티브(narrative)다. 우리는 세상에 어떤 이야기를 하고 싶은가? 보도 자료는 어떤 내용이겠는가?

예를 들어, 다음은 스포티파이의 ‘디스커버’탭의 내러티브를 보여주는 짧은 동영상에서 발췌한 것이다.

음악을 발견하는 더 좋은 방법을 소개합니다.

보세요! 여러분이 좋아하는 아티스트가 지금 막 여러분과 음악을 공유했습니다. 아티스트와 팬들이 그 어느 때보다 가까워질 수 있어요. 좋아하는 아티스트가 있습니까? 그 아티스트를 팔로하세요. 그리고 여러분이 발견한 것을 친구들과 공유하세요.

여기서 중요한 것은 제품이 만들어지기 전에 내러티브가 작성된다는 점이다! 이렇게 하면 심지어 제품을 만들기 전에 제품이 매력적인지 확인할 수 있다.

게다가 생각 스쿼드는 이 제품의 룩앤필을 실험하기 위해 다양한 프로토타입을 많이 제작한다. 종이에 그려보기도 하고 실제 작동하는 프로토타입을 만들기도 한다. 어떤 프로토타입이 내러티브를 가장 잘 보여주는지 검토하여 몇몇 후보군으로 압축하는 데는 내부 포커스 그룹이 이용된다.

이것은 기한이 없는 반복 개선 프로세스이다. 제품은 매력적인 내러티브와 그 내러티브를 충족시키는 작동 가능한 프로토타입을 보여줄 수 있어야 구축할 가치가 있으며, 이것이 얼마나 오랫 기간이 걸릴지는 미리 결정할 수 없다.

리스크-비용 곡선에서 볼 수 있듯이 생각 단계는 비용 면에서 매우 효과적으로 제품 리스크를 감소시킨다. 우리는 단지 프로토타입을 만들고 실험할 뿐이다. 이렇게 하면 안전하고 낮은 비용으로 실패를 경험할 수 있으므로, 구축할 적절한 제품을 찾을 때까지 계속 시도해볼 수 있다.

생각 단계 완료의 기준: 생각 단계는 경영진과 스쿼드 모두 제품을 구축할 가치가 있다고 생각할 때(또는 제품을 구축할 가치가 없고 제품 아이디어가 폐기되어야 한다고 생각할 때) 끝난다.

이것은 정량적인 데이터를 바탕으로 하지 않는 주관적 판단이다. 정량적 데이터는 전달 단계에서 입수되므로 최대한 빨리 전달 단계에 도달하는 것이 좋다.

구축단계

이제 생각 스쿼드는 실제 제품을 만들고 테스트하고 전달하는 데 필요한 모든 기술을 갖춘 더 장기적인 스쿼드(때로는 여러 개의 스쿼드)로 확장된다. 이 스쿼드는 구축 단계 동안만이 아니라 더 오랫동안 제품을 담당한다.

구축 단계의 목표(그림4-7)는 외부 사용자에게 릴리즈하기 충분하고 제품에 대해 뭔가를 입증하기에 충분한 MVP(Minimum Viable Product)를 만드는 것이다. MVP는 스크럼, 칸반, XP(eXtreme Programming) 같은 애자일 방법론을 접목한 소프트웨어 개발 방법을 사용하여 반복 개선 방식으로 구축된다.

이 단계에서는 그림 4-8의 표현된 것처럼 균형점을 찾아야 한다.

Figure 4-7 The Build It Stage

Figure 4-8 Minimum viable product

한편으로는 완벽한 제품을 만들고 나서야 제품을 제공하는 것은 좋지 않는데, 그 이유는 그렇게 하면 학습 기회가 늦어지기 때문이다. 실제 소프트웨어를 실제 사용자에게 전달하기 전까지는 우리가 제대로 하고 있는지 확인할 수 없으므로 완벽한 제품을 만들려고 하지 말고 가능한 한 빨리 제품을 공개하는 것이 좋다. 다른 한편으로, 우리는 쓸모없는 당황스러운 제품을 제공하기를 원하지 않는다. 우리가 베타 버전 또는 알파 버전이라고 말해도 사람들은 스포티파이가 훌륭한 소프트웨어를 만들 것으로 기대하고 우리가 릴리즈한 것으로 우리를 판단한다.

그러므로 스쿼드는 기본적인 내러티브를 충족하고 사용자를 기쁘게 할 수 있는 최소한의 제품을 알아내야 한다. 특징 면에서 완전한 것이 아니라 내러티브 면에서 완전하게 만들어야 한다. 아마 최소 호감 제품(Minimum Lovable Product)이 더 적당한 표현일지도 모른다. 자전거는 더 좋은 교통 수단이 없는 사람에게는 사랑받고 유용한 제품이겠지만 더 발전된 제품인 오토바이와는 많은 차이가 있다. 우리는 기본적인 내러티브를 반드시 충족해야 한다. 그렇지 않으면 측정 결과를 잘못 해석할 수 있다. “우리가 바퀴를 출시 했지만 아무도 사용하지 않으니 제품은 실패작이고 자전거의 나머지 부분도 안 만드는게 좋겠어!”

생각과 구축 사이의 중요한 차이점은 생각 단계에서는 가능한 모든 지름길을 택하여 기술적인 품질에 대해서는 신경쓰지 않는다. 구축 단계에서는 제품 수준의 코드를 작성하고 품질을 확보하려 노력한다.

구축 단계 완료의 기준: 구축 단계는 경영진과 스쿼드 모두 제품이 기본 내러티브를 충족하고 실제 사용자에게 공개하기에 충분하다고 생각할 때 끝난다.

이제 진실의 순간을 맞을 준비가 되었다!

전달 단계

Figure 4-9 The Ship It Stage

전달 단계의 목적(그림4-9)은 실제로 제품이 약속을 충족하는지 측정하고 확인하면서 전체 사용자에게 제품을 점차 확산하는 것이다.

스쿼드는 우선 전체 사용자 중 일부(보통 1%~5%)에게 제품을 공개해서 데이터를 수집한다. 이런 사용자는 나머지 95~99%의 사용자와 비교할 때 어떻게 행동하는가?

생각 단계에서 제품에 대해 몇가지 가설을 세웠다는 것을 기억하라. 이제 우리는 드디어 이런 가설이 맞는지 테스트하고 필요하면 제품을 반복적으로 개선할 수 있다. 한번 만에 바로 만족스러운 결과를 얻는 경우는 거의 없으며, 이 모델의 장점 중 하나는 그렇게 할 필요도 없다는 것이다.

경영진과 스쿼드가 소규모 사용자 그룹이 제품이 의도한 가치를 느낀다는 데 동의하면, 측정과 개선 작업을 계속하면서 동시에 더 많은 사용자에게 제품을 서서히 확산한다. 이렇게 하면 하드웨어 용량, 모니터링, 배포 스크립트, 확장성 등 운영 측면의 요소를 다룰 시간을 확보할 수 있다.

전달 단계 완료의 기준: 전달 단계는 제품이 모든 사용자에게 공개하면 끝난다.

이 단계에서 제품은 아직 ‘특징이 완성’되지 않는다는데 주의하라. 전달 단계를 완료했다는 것은 단지 제품(최소 존속 제품 + 필요한 개선)이 모든 사용자에게 공개되었다는 의미이다. 특징은 완성될 수 없다. 제품은 전달 단계 이후에도 계속 개선되기 때문이다.

수정단계

Figure 4-10 The Tweak It Stage

수정단계(그림4-10)은 가장 중요한 단계이다. 왜냐하면, 모든 제품이 (여기까지 오는 동안 폐기되지 않았다면) 이 단계에서 끝나고 제품 주기에서 제품이 가장 오랜 시간 머무르는 단계이기 때문이다.

제품은 이제 만들어졌고 모든 사용자가 사용할 수 있다. 비록 전달 단계에서 어느 정도 입증되었지만, 개선의 여지는 항상 많이 있다. 스쿼드는 지표를 추적하면서 계속 실험하고 A/B 테스트를 하며 제품을 개선한다. 이 과정에서 소소한 수정뿐만 아니라 상당히 중요한 새로운 특징이 추가될 수도 있다.

그러나 언젠가는 제품의 수확 체감 지점에 도달한다. 이제 제품은 훌륭하고 가장 중요한 개선이 완료되었으며 새 특징을 개발하는 비용 대비 효과는 덜 매력적이다.  그리고 새 특징을 추가하고 개선해도 지표에 큰 변화가 없을 것으로 예상된다. 이는  제품이 ‘국지 극대(Local Maximum)’ 지점에 도달하고 있다는 의미이다.(그림 4-11 참조)

Figure 4-11 Local Maximum

이 시점에서 스쿼드와 경영진은 “이 언덕 정상에 있는 것으로 만족할 것인가 아니면 더 높은 봉우리를 찾을 것인가?”에 대해 토의한다. 전자의 경우라면 스쿼드는 점차 다른 제품으로 이동한다. 후자의 경우에는 스쿼드는 생각 단계로 다시 돌아가 이 제품에 대해 다시 생각해보고 전역 극대(Global maximum)를 찾게 된다(또는 적어도 현재보다 더 높은 봉우리를 찾는다.). (그림 4-12 참조)

Figure 4-12 Reimagining a product

이것의 한 예가 spotify.com 웹사이트이다. 이 웹사이트는 2012년 여름, 재구축하기로 결정하기 전까지 4년 동안 조금씩 수정되었다. 이제 이 웹사이트는 완전히 달라진 훨씬 더 효과적인 방법으로 스포티파이의 비전을 전달하고 있다.

마무리

만약 이 모델의 어떤 부분에 대해 “쯧쯧, 이미 알고 있는 내용이고 오랫동안 그렇게 해왔는데…”라는 생각이 든다면 아마 여러분의 생각이 옳을 것이다. 이 모델은 ‘새롭고 멋지다’라기보다는 ‘효과적으로 작동’한다. 오래된 모델이건 새로운 모델이건 그건 중요하지 않다. 내 경우에는 여러 기법을 결합한 이 모델이 매우 강력하고 고무적이었다. 여러분도 각자의 상황에서 여러분에게 도움이 되는 모델을 찾기 바란다.