#스포티파이 #개발프로세스 #SaaS개발 #성공방정식 #애자일팀 #크로스펑셔널 #애자일 #협업툴
필자는 SaaS 제품으로 어느 정도의 성공을 거둔 창업자들에게 다음과 같은 질문을 해본 적이 있다. 그리고 그들로부터 돌아온 대답들은 늘 한결같았다.
'성공을 위해 무엇이든지 했다.'
'사용자 많이 만나고 피드백 듣고 반영했다.'
'제품만 보고 일했다.'
공통적으로 3~5년간 프로덕트 마켓 핏(Product market fit)을 찾기 위해 얼마나 많은 노력을 했는지 쉽게 유추할 수 있는 대답들이다. 그들의 대답처럼 SaaS 제품의 성공은 너무나 어렵다. 통계적으로 보면 아이디어 단계부터 제품을 개발하여 상업적으로 제품이 성공할 확률은 전체의 1/3000 정도밖에 안 된다. 그럼에도 불구하고, 혼신의 힘을 다해 오늘도 이에 도전하는 분들을 위해 '무엇이든지 열심히' 라는 추상적인 말 대신에 함께 고민할 이야기를 본 글에서 구체적으로 제시해보려고 한다. 개발할 제품의 산업적 위치와, 제품 특성 및 상황에 따라 조금씩 접근하는 방법은 달라져야 하겠지만, 이제부터 설명할 방식은 성공한 많은 회사들이 해 온 방식이다. 세계 최고의 음원 스트리밍 회사 '스포티파이'도 모바일 게임의 일인자였던 '캔디 크러쉬 사가'도 아래의 일하는 방법으로 탄생했다.
이 방식은 헨리크닉버그(Henrik Kniberg)라는 애자일 전문 컨설턴트가 스포티파이 프로젝트 시 정리한 내용이다. '스포티파이 문화'라는 말로 정리되었고, 애자일이 중심이 되었기에 프로세스의 모든 단계에는 이터레이션이 중심이다. 다섯 가지의 단계가 있지만 단계마다 모두 피드백을 반영하는 체계가 기본이다. 단계마다 집중하는 목표와 리소스 투입의 질과 양이 다를 수 있다.
#1 제품 아이디어 단계(Product idea)
제품 아이디어 단계의 목표는 제품에 대한 새로운 아이디어를 가지고 스폰서십을 받는 것이다. 크게 (1)고객을 정의하고, (2)인터뷰를 통해 고객의 문제를 찾으며, (3)인터뷰에서 나온 인사이트를 정리하고, (4)우리의 아이디어로 고객의 실제 문제를 해결하는지 테스트하고 학습하는 과정을 거친다. 이 단계에서도 실제로 무언가를 만든다. 다만 다음 단계들의 결과물과 비교할 때 이 단계의 모든 활동은 다른 단계에 비해 훨씬 단순하다. 어떻게 '이 아이디어를 당신의 현실에 적용하면, 문제가 해결될까요?'라는 질문의 답을 듣는 정도가 될 것이다. 그리고 가장 소수의 인원만 모인다. 아이디어 발제자 한 명 또는 마음 맞는 두 명 정도가 필요하다. 그리고 아이디어를 만들고 경영진의 스폰서십을 얻은 뒤 다음 단계로 나아간다.
#2 아이디어 검증 단계(Think it)
아이디어 검증 단계는 이전 단계인 제품 아이디어 단계에서 정의한 아이디어를 의미 있는 사용자 시나리오로 옮겨 실 사용자에게 테스트하는 단계이다. 여기에서 사용자 시나리오란, 사용자가 시스템을 활용하여 업무 수행을 시작하고 종료하기까지의 업무 흐름 의미한다. 아이디어 검증 시에는 가장 단순한 형태로 업무 시나리오를 만드는 것이 중요하다. 가장 단순한 형태여야 사용자에게 테스트할 때 명확하게 사용자의 문제가 해결되었는지 확인하기 쉽기 때문이다. 그렇기 때문에 시나리오의 주 흐름 외에 대안 흐름이나 예외 흐름은 고려하지 않는다. 여러 가지 방식으로 아이디어를 검증할 수 있지만, 일반적으로 디자인 프로토타입을 활용한다. 디자인 프로토타입을 보여주고, 질문을 통해 실제 문제가 해결되는지 질문하거나, 디자인 프로토타입을 클릭할 수 있게 만들어 검증할 수도 있다.
사용자는 한 가지 시나리오에 정확한 타깃으로 정의된 사용자 5~6명 정도가 검증하는 것이 적당하다. 로라 클레인(Laura Klein)이 집필한 린 스타트업 실전UX라는 책을 보면, 한 시나리오를 대상으로 5명 정도의 인원으로 검증한다면 정규 분포 사용자의 90% 정도의 케이스들을 커버할 수 있다고 언급되어 있다. 이 단계에서는 빠르게 변화하는 것이 중요하다. 사용자들이 시나리오를 경험한 뒤 정의한 문제에 대한 솔루션이 되기에 부족하다는 반응을 보이면 재빠르게 시나리오를 수정해야 한다. 이를 피벗(Pivot)이라 한다. 그리고 다시 한번 수정된 시나리오로 테스트한다. 자연스럽게 아이디어 검증 단계에서는 지속적으로 보완한 시나리오를 테스트하기 위해 많은 사용자들을 만나게 되고, 이를 통해 시나리오를 검증하는 일이 발생한다.
아이디어 검증 단계에는 2가지 정도의 역할이 필요하다. 최초로 아이디어를 만든 사람을 프로덕트 매니저와 사용자 테스트와 프로토타입을 빠르게 제작할 수 있는 디자이너이다. 물론 초기부터 기술적인 역량이 많이 필요한 제품의 경우 개발자가 포함되기도 한다. 커뮤니케이션의 복잡화는 팀 전체의 속도를 늦추기 때문에 일반적으로 2~4명 정도가 이 단계의 팀원으로 참여한다. (물론 규모와 하는 일의 종류에 따라 변화한다.)
#3 동작하는 MVP 개발단계(Build it)
아이디어 검증 단계를 거쳐 MVP 개발 단계로 가기 위한 스폰서십을 얻은 뒤, 가장 먼저 해야 할 일은 실제 시스템으로 구축할 개발 인력을 채용하는 것이다. 이때 채용하는 개발자는 작성한 시나리오를 처음부터 끝까지 개발할 수 있는 역량이 있어야 한다. 때문에 클라이언트, 서버, 데브옵스(Devops) 환경 개발 등의 역할 구분을 하지 않아도 되는 풀 스택 개발자를 참여시키는 것이 가장 이상적이다. 하지만 풀 스택 개발자를 참여시키는 것은 매우 어려운 일이기에 각각의 전문성을 가지고 있으면서도 다른 분야의 전문 개발자들과 늘 협업할 수 있는 태도를 가진 인력을 채용하는 것도 가능하다. 다만, 최소한의 인원을 모아야 기존 팀에 존재하던 2~4명의 프로덕트 매니저와 디자이너들이 기존의 하던 업무를 온전히 수행하면서, 개발자들에게 지식을 전달하는 일 또한 잘 해낼 수 있다. 일반적으로 4명 정도의 인력을 최초 투입하고, 추후 개발자를 늘려야 한다면 3~4주 후 추가로 2명 정도를 투입하는 것이 좋다.
MVP 개발 단계에서는 가능하다면 인력을 많이 늘리지 않는 것이 좋다. 왜냐하면 구축 단계의 가장 큰 목적은 실제 동작하는 제품을 사용자들에게 써 보게 했을 때, 사용자들의 문제를 온전히 해결하는지를 확인하는 것이기 때문이다. 지속적으로 사용자들의 피드백을 받고 제품에 반영하는 과정에서 팀 인원이 8명 이상이 될 경우에는 많은 커뮤니케이션 낭비가 발생한다.
개발자들이 도착하면 이전 단계에서 검증된 시나리오 및 디자인 프로토타입을 공유하고, 그 디자인 프로토타입과 연관된 기능을 공유하고 바로 개발에 착수할 수 있도록 한다. 구축 단계에서 사용자에게 제품을 사용하게 하는 방법은 아이디어 검증 단계와는 다르다. 구축 단계에서 구현된 제품의 사용성을 테스트할 때는 실제 사용자에게 개략적 설명만 한 뒤, 써 보라고 맡긴다. 그리고 그들이 사용하는 패턴을 녹화하고 잘 분석하여 어느 부분에서 사용성이 막히는지, 개선할 부분이 어디인지 찾는 것이다. 이를 개선하여 올바른 문제에 대해 올바르게 동작하는 솔루션을 찾고 이를 통해 스폰서십을 얻는다. 구축 단계까지는 일반적으로 품질을 크게 신경 쓰지 않는다. 사용자에게 온전히 테스트할 수 있는 단계라면 많은 부분의 결함을 잡거나 예외 흐름 등을 고려하지 않는다. 낭비를 최소화하고 동작하는 제품을 통한 시나리오 활용이 사용자에게 의미를 갖도록 만든다.
#4 제품화 단계(Ship it)
제품화 단계는 실제 고객에게 제품을 전달하기 전 '제품화'하는 것을 의미한다. 그리고 제품화와 검증된 시나리오를 중심으로 필요한 기능들을 함께 추가된다. 예를 들자면 '시스템 관리자'를 위한 일부 기능이나 '사용자 등록' 등의 기능들이다. 타깃 고객이 이 제품을 활용할 때 발생할 법적 정책적 문제 또한 이 단계에서 고려하여 기능을 추가한다. 일반적으로 이 단계에서 팀 규모를 늘린다. 앞의 세 단계의 공정으로 아이디어에 대한 검증이 완료되었기 때문에, 이제는 정해진 방향대로 뛰어갈 수 있다. 팀 규모를 늘릴 때는 올바른 비율을 유지하는 것이 중요하다. 프로덕트 매니저, 디자이너, 개발자의 비율을 1:1:4 정도로 유지하면서 팀을 키우고, 팀원이 12명 이상이 될 경우 팀을 둘로 나누는 일을 반복하며 팀을 확대한다. 그러면 속도의 하락을 최소로 유지하면서 개발할 수 있다. 이때 가장 중요한 것은 제품의 품질을 높이는 일이다. 제품화 단계부터는 깨끗한 코드를 짜고, 대안 흐름, 예외 흐름 등 발생하는 버그들을 잡아야 한다. 운영 중에 일어날 수 있는 문제점도 사전에 고민하는 것이 좋다. 이전 단계까지는 데브옵스 환경(로컬 - 개발 - 테스트 - 프로덕션의 단계별 환경)이 의미가 없었을 수도 있지만, 제품화 단계부터는 이 환경이 필수적이다.
자동으로 빌드가 일어나고, 자동으로 코드를 통해 테스트되며, 단계별 원 버튼 (한 번의 버튼 클릭으로 다음 버전 제품이 반영되는) 릴리즈가 가능해야 한다. 테스트 활동의 중요성 또한 높아진다. 이를 통해 결함 0을 지향하는 제품을 만들어야 하기 때문이다. 그리고 고객에게 피드백을 받을 수 있는 체계 또한 중요하다. 에러가 났을 때 고객이 시스템 관리자와 소통할 수 있는 창구와 개선사항에 대해 소통할 수 있는 채널이 존재해야 한다. 사용자의 사용 패턴을 분석할 수 있는 툴을 도입하여 실제 활용 시 어느 곳에서 병목이 일어나는지도 함께 조사할 수 있도록 준비해야 한다.
#5 지속적인 개선 단계(Tweak it)
앞의 모든 과정이 끝나면, 이제부터 진짜 고행의 길이 시작된다. Product market fit을 찾기 위해, 제품이 릴리즈 되고 나서는 팀은 끊임없이 피드백을 받고, 이를 개선하는 체계를 운영해야 한다. 이 과정은 일반적으로 3년 이상 걸리며, 어느 날은 좋았다가 어느 날은 힘들었다가 하는 일이 계속해서 반복된다. 이 과정에서 팀원들은 서로를 믿고 계속 앞으로 나아가는 것이 중요하다.
화이트보드 기반 온라인 협업툴 마림바도 단계 명칭은 자체적으로 변경했으나 스포티파이의 방식과 동일한 과정을 거쳐 발전되었다. 지속적인 개선 단계 이전에는 1년에 걸쳐 추가 투자를 받았다. 그 시점으로 구분하면 거의 그대로 활용되었다. 그리고 현재도 '지속적인 개선' 단계를 거치면서 더 많은 사용자들의 '문제'를 해결하기 위한 '솔루션'으로 발전하고 있다.