본문 바로가기
  • Humble Agile Coaches
Agile

"스포티파이가 제품을 만드는 방법(How Spotify Builds Products)" 살펴보기

by Humble Agile Coach - 채드(유종현) 2020. 3. 12.

  피터 센게의 발명과 혁신의 정의를 빌어서 설명하자면 "스포티파이"를 애자일을 혁신한 기업으로 평가할수 있을 겁니다. 비행기를 라이트 형제가 발명했지만 혁신한 주체는 비행산업의 기업들인 것처럼요.

  애자일을 도입하려는 많은 기업들이 가장 먼저 고려하는 조직 모델이 스포티파이의 Tribe구조 라는 것을 떠올려보면 애자일 혁신의 주체로서 스포티파이를 표현하는 것이 틀린 것은 아닐겁니다..

  지금도 구글에서 애자일, 스포티파이로 검색을 해보시면 수많은 자료를 보실수 있을텐데요.

그중에서도 이 글에서는 "스포티파이가 제품을 만드는 법(How Spotify Builds Products")라는 아티클에 대해서 이야기를 나눠보고자 합니다.

  스티브 블랭크 / 에릭 리스 / 마티 케이건과 같은 같은 많은 기업가, 혁신가, 유명한 프로덕트 매니저들이 채택하는 제품개발방식은 린/애자일 사상에 바탕을 두고 있습니다. 린의 용어를 사용하든 그렇지 않든 말이죠.

  2013년 헨릭 크니버그가 소개한 "How Spotify Builds Products"라는 아티클을 보면 스포티파이가 선택한 제품 개발 방식 또한 그와 다르지 않다는 것을 알수 있네요. (지금 헨릭 크니버그는 마인크래프트로 유명한 Mojang에서 일하고 있답니다.)

 

  그 문서(https://blog.crisp.se/wp-content/uploads/2013/01/HowSpotifyBuildsProducts.pdf)의 내용을 살펴보도록 하죠. 벌써 7년전에 만들어진 문서이고 헨릭 크니버그가 말하는데로 개략적으로 표현한 것이며 스포티파이 내에서도 수많은 로컬베리에이션이 있다는 것을 감안해야겠습니다만 이문서에서 표현하고 있는 내용이 린/애자일 사상을 담고 있는 제품 개발 방식의 대한 훌륭한 실천법이라는 생각이 들어 공유합니다.

 

 


스포티파이의 제품 개발 철학


  먼저 당시 소개된 스포티파이의 제품 개발에 대한 철학을 소개합니다.

 

스포티파이의 제품 개발 철학

빠르고 저렴하게 프로토타입을 제작하여 리스크를 관리하면서 혁신적인 제품을 만든다.
일정에 따라 출시하는 것이 아니라 품질에 따라 출시한다.
출시 후 지속적인 수정을 통해 제품 출시 때의 우수한 제품에서 놀라운 제품으로 거듭날 수 있도록 노력한다.

 

 저에게 가장 눈에 띄는 것이 일정에 따라 출시하는 것이 아니라 품질에 따라 출시한다는 개념이네요. 많은 기업들이 일정 지키기를 목표의 가장 상위에 두고 일하고 있습니다. 일정에 맞추기 위해 때로는 품질을 포기(공식적으로는 아니지만 암암리에...)하기도 하는 많은 회사들이 있다는 것을 감안하면 스포티파이의 이 철학은 눈여겨 봐야 할 점 같습니다. 


  스포티파이의 제품 개발 철학을 보면 자사의 서비스를 만드는 회사 답게 프로젝트보다 프러덕트에 초점을 맞추고 있다는 생각이 듭니다. 일정 중심으로 프로젝트보다는 제품의 품질과 이익에 초점을 맞춘 것으로 보여집니다.

  이러한 철학을 바탕으로 스포트파이의 제품 개발은 4단계로 이루어집니다.

  각 단계를 거치면서 스포티파이는

  • 아이디어를 만들고
  • 가설 검증을 위한 MVP만들고
  • 점진적으로 제품을 만들고 측정하며 사용자 층을 넓히고
  • 마지막으로 성숙 단계

에 도달합니다.


스포티파이의 제품 개발 4단계

  스포티파이에서 말하는 제품 개발 4단계 각각을 간단히 표현하면 아래와 같습니다.

Think It : 우리가 어떤 종류의 제품을 만들고 있는지, 그 이유를 알아보자
Build It : 실제 사용자가 사용할수 있는 최소한의 실행 가능한 제품을 만들자
Ship It : 모든 사용자의 100%가 사용할수 있도록 점진적으로 개선 및 측정하며 출시한다.
Tweak It : 지속적으로 제품을 개선한다. 제품의 최종적인 상태이지만 제품을 계속 비틀며 개발은 종료되지 않고 계속된다.

스포티파이의 제품 개발 4단계, 헨릭 크니버그의 How Spotify Builds Products 에서 발췌

 

 

  스포티파이는 개발하고 있는 제품들의 단계를 매니지먼트 관점에서 가시화하기 위해서 칸바보드로 현황판을 만들어 공유합니다.  아래 처럼 말이죠.

(매니지먼트에서 칸반보드를 활용하여 제품 전체의 상태를 가시화하는 방식은 이제는 일반화되어 SAFe와 같은 Large Scaled Agile을 표방하는 많은 방법론에서 활용하고 있습니다.)

 

 

스포티파이의 매니지먼트 수준의 칸반 보드, 헨릭 크니버그의 How Spotify Builds Products 에서 발췌


   또한 스포티파이는 보드를 통해 제품의 현재 상태 뿐 아니라 과거의 기록들도 공유합니다. 각 단계마다의 업데이트 날짜와 기간 등을 공유하고 이를 통해서 보드를 보는 사람이 다음 단계에 도달할 시기나 다음 업데이트 상황을 예상해볼 수 있도록 합니다.


  추정은 약속이 아니라 예측이라는 마이크 콘의 주장을 그대로 보여주고 있는 느낌이네요 데이터를 바탕으로 향후 일정을 약속하는 것이 아닌 예측하도록 도와준다는 느낌으로요.



스포트파이가 제품 라이프사이크을 4단계로 나눈 이유.


  제품을 만들면서 가장 중요한 것은 실제로 사용되어질 제품을 만드는 것입니다. 

이에 반하는 것을 스포티파이에서는 "제품 위험(Product Risk)"라고 표현합니다.

 

Product Risk : 사용자를 만족시키지 못하고 사용자 확장, 보존 등과 같은 성공 지표를 개선하지 않는 제품


  스포티파이는 이러한 제품 리스크를 수용하면서 비용을 절감하기 위해서 제품 개발 단계를 나누고 있습니다.  중요한 것은 제품 리스크를 피할수 있는 방법은 없다는 것입니다. 따라서 제품 리스크을 받아들이면서도 최적의 비용으로 제품을 만들수 있는 방법을 찾아야 합니다.

 

 이를 위해서 스포티파이가 만들어 낸 것이 제품 개발 4단계라고 볼수 있겠네요. (그것이 개발 방법에서는 애자일이고요. 비즈니스에서는 린스타트업이 되겠죠.) 앞으로 살펴보겠지만 스포티파이의 제품 개발 4단계는 그 목적과 특성이 명확하게 나뉘는 것을 알수 있는데요.

 

  먼저 전체 단계별 운영 비용과 제품 위험의 상관 관계를 헨릭크니버그가 그려준 그래픽을 보면서 이해해보도록 하겠습니다.

 

 

스포티파이의 제품 개발 단계의 비영과 제품 위험, 헨릭 크니버그의 How Spotify Builds Products 에서 발췌


  먼저 그래프를 보시는 것처럼 Think It단계에서 제품 위험(Product Risk)가 높기 때문에 비용을 낮추는 것이 핵심입니다. 비용이 높은 다음 단계를 빠르게 진입하기 보다는 Product Risk를 최소화하기 위한 과정을 Think It 단계를 거칩니다.

 

  그리고 제품 위험이 충분히 낮아졌다고 판단이 될때 비용이 좀더 많이 투입되는 다음 단계로 진행합니다.

 

  이렇게 각 단계는 완료 목표와 핵심 태스크가 있는데요.
  그러면 이제 각 단계를 자세히 살펴보겠습니다.


아이데이션 (Think-It단계)

 

  스포티파이의 제품 개발 4단계 중 첫단계는 Think It 단계입니다.
  이 단계는 새로운 제품 아이디어를 만들거나 기존 제품의 새로운 상상력을 불어넣을때 사용하는 단계입니다.
  Think-IT단계의 시작은 최초 개인이 제안한 아이디어를 경영진이 동의하면서 시작됩니다. 그러면 소규모 크로스펑셔널 스쿼드(CrossFuntional Squad)가 만들어집니다. 이 스쿼드의 "Think-It" 단계의 목표는 제품 정의(Product Definition)를 작성하고 설득력있는 제품으로 정의하는 것입니다.

  여기서 제품 정의(Product Definition)라는 것은 제품이 갖추고 있어야 하는 다음 몇가지 질문을 답하는 짧은 문서입니다.

 

제품 정의(Product Definition)에는 담기는 답을 위한 질문들

이걸 왜 만들어야 할까? 누가, 어떻게 이득을 얻을까?
이 제품이 개선될 것으로 예상되는 주요 지표는?
가설은? 이 제품이 성공했는지 어떻게 알수 있는가?
"단계적 변화"가 발생하는가? 아니면 전략적 이유와 같은 다른 아유가 있는가?



  제품 정의(Product Definition)에서 가장 중요한 것은 내러티브를 표현하는 겁니다. 스포티파이가 세상에 어떤 스토리를 전달할 것인가? 이것이 바로 내러티브이고 "보도 자료가 있다면 어떤 것을 전달할까?" 와 같은 것들입니다.

 

  "How Spotify Buidls Products"라는 문서에는 그 예로 아래와 같은 내용을 소개하고 있네요.

 

음악을 발견하는 더 좋은 방법 소개할께.

이것 봐! 네가 가장 좋아하는 아티스트가 방금 너와 노래를 공유했어. 그 어느 때보다 아티스트와 팬을 더 가깝게 모을수 있을거야. 예술가처럼? 그냥 그들을 따라가서, 너가 발견한 것들을 친구들과 공유해봐~

 

  이 글만 본다면 어떤 느낌일지 잘 와닿지 않을수 있겠네요, 내러티브라고 하는 것은 사용자가 느낄수 있는 가치를 스토리텔링 방식으로 사용자에게 전달하는 방식으로 생각하면 쉽게 이해되실 것 같습니다.


  아무튼 Think-It 단계에서는 제품을 외관과 느낌을 실험하기 위해서 다양한 프로토타입을 끊임없이 만들어 냅니다. 로우파이 프로토타입과 하이파이 프로토타입을 만들어 내면서 내부 포커스 집단을 활용하여 검증합니다.
  그리고 몇가지 주요 후보들로 좁혀질때까지 프로토타입 만들기를 반복합니다.

 

헨릭 크니버그의 How Spotify Builds Products 에서 발췌


  매력적인 내러티브, 실행 가능한 프로토타입을 만들때까지 얼마나 걸릴지 알수 없죠. 이 단계에서는 프로토타입을 외부에 공개하지 않기 때문에 명확히 뒷받침할만한 자료를 만들어내지 못합니다.
따라서 완벽하게 제품위험(Product Risk)를 회피할수 있는 제품을 이 단계에서 만들어낼수는 없습니다. 그럼에도 이 단계가 가치 있는 것은 낮은 비용으로 위험을 낮추는 것이고 이를 위해 현재와 같은 방법을 활용합니다.

  그렇다면 Think-It 단계의 끝을 알수 있는 기준은 무엇일까요?

 

Think-It 단계 완료의 정의
Think-It 단계는 경영진과 팀원들이 공동으로 이 제품을 만들 가치가 있다고 생각하면 끝난다.


MVP 만들기(Build-It 단계)


  Think-It 단계를 무사히 마무리 했다면 이제 다음 단계인 Build-It 단계로 진입합니다.
이 단계에서 스쿼드는 이 제품을 소유하고 지속가능한 조직으로 만들어 집니다. 때에 따라서는 여러 스쿼드로 확장되기도 합니다.

  하지만 팀이 확장된 만큼 운영 비용이 올라가게 됩니다. Think It 단계에서 얼마나 옳은 판단을 했느냐에 따라서 이 운영비용의 가치가 판가름 나게 될 것입니다. 하지만 이 단계에서도 그 가치를 판단할 수 없습니다. 아직 고객을 만날 준비가 되지 않았기 때문이죠. 

  Build-It 단계의 목표는 외부 사용자에게 공개될수 있는 MVP를 만드는 겁니다. 그리고 그 MVP는 다음 단계에서 제품 정의(Product Definition)를 증명하는데 사용될 것입니다.
  하지만 여전히 Build-It 단계는 제품을 만드는데 집중해야 하며 여기서 제품이라 함은 내러티브를 갖춘 Minimal-Loveable Product라고 정의됩니다. 반복적으로 만들어지지만 내러티브를 완성할수 있는 제품이어야만 목표에 도달할수 있습니다.

헨릭 크니버그의 How Spotify Builds Products 에서 발췌


  스포티파이의 헨릭크니버그는 아래 그림처럼 그 수준을 표현하고 있는데요. 어려운 것은 제품의 균형을 찾는 것입니다.. 스포티파이의 명성에 해를 가하지 않으면서 가능한 빠르게 만들수 있는 제품이어야 합니다. 아래 그림의 오토바이처럼 비용이 많이 들어가면 안되고 하나의 바퀴처럼 고객에게 가치를 전달하지못하는 제품도 안됩니다.

 

헨릭 크니버그의 How Spotify Builds Products 에서 발췌


  Build-It 단계와 이전 단계와의 차이점은 Think It 단계는 가능한 빠르게 하기 위해 모든 지름길을 활용하고 기술적인 품질을 고려하지 않는다는 것입니다. Build It단계에서는 Built-In 개념으로 품질을 고려하며 제품을 만들어 냅니다.

 

Built-It 단계 완료의 정의
Built-It단게는 경영진과 스쿼드가 제품이 기본적인 내러티브를 만족하여 사용자에게 출시 될수 있을 정도로 충분하다고 판단하면 끝납니다.

 

  Build It단계가 무사히 마무리 되었다면 이제 MVP 만들어졌으니 제품 정의(Prodcut Definition)가 정말 맞는지 진실을 마주할 시간이 된 것입니다.


가설 검증과 확장 (Ship-It 단계)


  Ship-It 단계의 목적은 제품을 순차적으로 개발하며 측정하며 개선하는 겁니다. 
  점진적으로 개발하며 목표하고 있는 소수의 사용자에서 부터 시작하여 모든 타겟 사용자 100%에게 제품을 전달합니다.

헨릭 크니버그의 How Spotify Builds Products 에서 발췌

  스쿼드는 소수의 사용자에게 제품을 배포하면서 부터 학습을 시작합니다.
  "Think-It"단계에서 정의한 제품 정의(Product Definition)라는 가설이 사실인지 여부를 실험하고 반복적으로 제품을 만들어 갑니다.

  사용자 수를 늘리면서 제품 운영상의 스케일러빌리티를 고려하는 시간을 갖게 됩니다. 

Ship-It 단계 완료의 정의
모든 사용자가 제품을 사용할 수 있을때 Ship-It 단계는 종료된다.

  Ship-It 단계가 완료되어더라도 "기능 완료"를 의미하는 것은 아닙니다. 제품은 앞으로 진화를 계속할 것이기에 기능완료라는 개념은 없습니다.
 


프러덕트 비틀기(Tweak-It 단계)

  Ship-It단계가 마무리 된다는 것은 제품의 주요 기능이 모두 개발되었다는 것을 의미합니다. 제품이 개발중에 좌초하지 않고 기획된 것이 모두 개발된다면  결국 모든 제품은 Tweak It단계에 도달하게 됩니다. 많은 기업에서 운영이라고 표현하는 단계라고 보시면 됩니다.

헨릭 크니버그의 How Spotify Builds Products 에서 발췌


  주요 기능이 모두 개발되었지만 언제나 항상 개선요소들은 있기 마련이고 그렇기에 계속해서 실험은 끝나지 안핬스빈다. 사소한 수정에서 새로운 기능까지 Tweak-It 단계어서 해야 할일은 아직 남아 잇죠
Tweak-It단계에서 "개발비용 > 이익" 상황이 발행하면 스쿼드와 경영진에게 고민이 순간이 오게 된 것입니다.  
 
  제품을 비틀어서(Tweak) 새로운 시도를 할것인지 아니면 제품의 현재 위치에 만족하고 스쿼드를 새로운 제품에 투자할것인지 결정을 해야 하는 시기인 것이죠.  스포티파이의 헨릭크니버그는 현재 산정상에서 만족할 것인지 아니면 더 높은 산을 찾아 떠날것인지로 비유적으로 표현하고 있는데요.
 

헨릭 크니버그의 How Spotify Builds Products 에서 발췌


  정상을 향하는 메타포는 복잡계 과학에서 문제 해결하기를 표현할때 사용한다는 것을 생각해보면 결국 스포티파이의 제품 개발 4단계도 복잡계적 시각에서 출발했다는 것을 알수 있네요.

 

  (복잡계 과학에서는 복잡계를 수많은 산이 있는 지역으로 표현하고 소수로 구성된 수 많은 팀을 이 지역에 퍼뜨려 떨어뜨려 놓고 각 팀마다 그 곳에서 볼수 있는 가장 높은 산에 도달하는 하는 방식으로 문제를 해결하라고 이야기를 합니다. 그러면 그중 일부는 아마도 가장 높은 산에 올라가게 되고 나머지는 실패하게 되지만 가장 높은 산에 올라간 이들이 나머지 실패를 보상하게 됩니다.)


오버뷰 

  스포티파이의 제품 개발 4단계를 한그림으로 보면 아래와 같습니다. 모든 제품이 모든 단계를 밟을수 많은 없을 것입니다. 그리고 스포티파이가 원하는 것은 제품이 이러한 단계를 밟으면서 비용 절감과 제품 성공의 균형을 만드는 것이겠죠.

 

헨릭 크니버그의 How Spotify Builds Products 에서 발췌

 



마지막으로...

  헨릭 크니버그는 글을 마무리하면서 이런 말을 합니다.

여러분이 "음.., 난 이미 알고 있었어, 우리가 수십 년 동안 이렇게 해왔는 걸."라고 생각하게 되는 부분이 있다면, 여러분이 아마 맞을 것이다. 이 모델은 새롭고 놀라운 것이 아니다.

  사실 많은 스타트업들이 이 방식을 사용합니다. 자신도 모르고 이 방식을 쓰기도 하죠. 

중요한 것은 이 방식이 놀라운 것도 아니고 새로운 것도 아닐지라도 이러한 점진적이고 단계적으로 실험과 시도를 하는 방식이 복잡적응계로 묘사되는 시장 상황에서 강력한 효과를 발휘한다는 것일 겁니다. 그래서 많은 스타트업들이 자신도 모르게 아니면 명시적으로 이 방법을 선택하고 실행하죠.

 

  여기까지 2013년에 헨릭 크니버그가 공유한 "How Spotify Builds Products" 아티클의 내용을 살펴봤습니다.

 

  얼마전에 뵈었던 유명한 애자일코치 분께서 자신의 경험을 토대로 이런 말씀을 하셨습니다.

 

 "애자일 방식으로 개발이 혁신되면 비즈니스가 개발의 속도를 따라오지 못해 전체적인 속도가 나지 않는다."

 

  애자일을 도입할때에는 개발 프로세스의 혁신 뿐 아니라 비즈니싀 혁신도 따라와야 함을 일깨워 주는 말인데요. 애자일을 시도하고 있는 많은 기업들이 개발 방법과 비즈니스 방법 모두 혁신해서 통합적인 관점에서 효율적인 방식으로 제품을 만들고 개인의 삶을 혁신해주시길 바라면서 글을 마칩니다.