MVP 만들 때 도움 되는 꼼수 몇 가지
MVP가 무엇이고, 얼마나 중요한지 설명하는 글은 많다. 그런데 MVP를 만들 때 디자이너가 가져야 하는 태도에 대해서는 좋은 글을 찾기 힘들었다. 지난 1년 간 3개의 MVP를 만들면서 경험한 것을 글로 정리해 보고자 한다.
우리 이런 MVP 하지 말자.1. MVP의 작동 원리를 짚고 넘어가자.
MVP란 무엇인가? MVP는 Minimum Viable Product의 약자로, ⌜린 스타트업⌟의 저자 에릭 리스에 의해 제안된 개념이다. MVP는 극도로 불확실한 상황 속에서, 전에 없던 서비스나 제품을 시장에 내보내는 상황에 스타트업이 가능한 성공에 가까이 다가갈 수 있도록 하는 서비스 제작 방법론이다.
MVP는 과학적 방법론에 따라 작동한다. 과학적 방법론이란 가설과 테스트로 이루어진, 데이터를 활용하여 특정 현상을 이해하고자 하는 일련의 검증 방법이다. 이는 체계적으로 현상을 관찰하고, 수치를 기반으로 현상을 측정하며, 가설을 설정한 후 테스트를 통해 이를 검증하고, 그리고 검증 결과로 나온 데이터를 토대로 기존 가설을 끊임없이 개선하는 활동이다.
과학적 방법론의 작동 원리. MVP 검증 방법과 다르지 않다.여기에서 현상이란, 우리 서비스가 사용자들에게 인지되는 방식, 그리고 시장에서 제품이 자리를 잡는 행태를 말한다. 사실 프로덕트 디자이너는 새로운 종류의 과학자나 다름없다. 특히 사람과 사람 사이에 일어나는 현상과 사회적 변화를 연구하는 사회과학자로 봐도 무리가 없을 정도다!
과학적... 어쩌구가 딱딱하게 들릴지 모르겠지만 사실 별거 아니다.
프로덕트 디자이너로서 우리가 평소에 사용자를 관찰하고, 관찰 결과를 토대로 "아 이래서 그런가...?" 추측하고, 다음 버전에서 그걸 테스트하고, 개선됐는지 수치를 통해 알아보는 일련의 과정을 '조금' 더 엄밀하게 하는 것일 뿐이다. 엄청 쉽다.
과학적 방법론이란 거... 별거 아니다.여기서 엄밀하게 한다는 말은 다음과 같다. 프로토타입이나 서비스를 테스트하는 과정에서 어쩔 수 없이 또는 미숙함 때문에 데이터를 수집함에 있어 편견이 개입되는 경우가 있다. 이런 경우에 가능한 신뢰도가 높은 데이터를 위주로 잘 분별해서 받아들인다는 말이다. 이것도 별로 어렵거나 현실과 동떨어진 학문적 개념은 아니다.
"파란색 상자 좀 갖다 줘!"예를 들어 친구가 멀~리서 “파란색 상자 좀 갖다 줘!" 했는데, 파란색이라고 했는지 빨간색이라고 했는지 잘 못 들어서 헷갈린 채로 일단 아무거나 갖다 준다면 실패할 확률은 50%로 반반이다. 좀 더 똑똑한 사람이라면 전화나 메신저 앱으로 연락해서 확인한 뒤, 한 번에 맞는 색 상자를 가져다줄 수 있을 것이다. 통화 음질이나 인터넷 상태에 따라 조금 달라질지언정, 성공 확률은 100%에 훨씬 가까워진다.
엄밀한 리서치도 이와 비슷하다. 스타트업 정신으로 일단 행동 먼저 해보겠다면, 그것도 좋다. 하지만 실제로 행동하기 전에 가능한 실패로 향할 수 있는 선택지를 미리 줄이는 것도 영리한 선택이다.
하지만 아쉽게도 이렇게 엄밀한 과학적 방법론을 활용하기에 스타트업의 시간은 늘 충분하지 않다. 더 많은 시간을 소비하려는 시도는 회사의 경제적, 인적 자원이라는 허들에 부딪치게 된다. 이 모든 것이 MVP라는 테스트를 위해 소비되는 비용이기 때문에, 항상 100%의 엄밀성을 유지할 수 없는 것이 현실이다.
그래서 프로덕트 디자이너는 회사가 가진 시간과, 검증하고자 하는 가설의 정확성을 회사의 상황에 맞게 현실적으로 세심하게 조율하면서 MVP를 설계해야 한다. 특히 MVP를 시도하는 스타트업이라면 매우 초기일 가능성이 높고, 여러 가지 상황들이 불확실하고 위태로울 것이다. 좋은 프로덕트 디자이너는 불안한 CEO의 마음을 잘 달래고, 이해관계자들 간의 커뮤니케이션을 통해 방향성을 합치시키는 동시에 시장과 사용자를 읽고 성공에 가까운 서비스를 기획해야 한다.
사실 MVP의 목적과 방법, 그리고 효과에 대해 자세히 서술한 아티클은 많다. 더 알고 싶다면 에릭 리스 본인이 저술한 ⌜린 스타트업⌟을 직접 읽는 방법을 추천한다. 이렇게 좋은 텍스트가 많기 때문에 지금은 MVP 자체에 대해 이야기하기보다는, MVP를 실제로 만드는 과정에서 초기 스타트업과 프로덕트 디자이너가 겪을지 모르는 일들에 대해 이야기해보고자 한다.
2. 맹목적으로 MVP를 기획할 때 겪을 일들
앞서 MVP의 작동 원리를 설명한 이유는 다음과 같다.
많은 프로덕트 디자이너들이 MVP라는 개념은 많이 들어서 익숙한데, 그 목적과 원리는 이해하지 않고 무턱대고 만드는 경우가 많다. 특히 MVP를 처음 만드는 초기 스타트업이나 경험이 적은 프로덕트 디자이너일수록 그렇다. 나도 정말 마찬가지였다. MVP가 무엇인지 잘 모른 채 설계하면 다음과 같은 문제들이 발생하기 쉽다.
너무 많은 기능을 기획한다.
처음부터 충분한 인원의 개발자들과 함께 MVP를 작업하는 운 좋은 일은 거의 없다. 초기 스타트업이라면 개발자 인원이 부족한 게 당연하다. 너무 많은 기능을 설계하면 개발자들이 빠르게 만들어내기 어렵다. 또, 기능이 너무 많으면 이를 통해 검증하고자 했던 가설에 대해 어떠한 결론을 내기가 혼란스럽다. 가설 검증을 위해서 중요도가 낮은 변수를 제거하고, 가장 중요한 기능 위주로 단순하게 만드는 것이 모든 면에서 좋다.
명확한 가설을 설정하지 않는다.
가설이 불명확하면 결론도 불명확하다. 결국 MVP를 무엇을 위해 만들었는지 알 수 없게 되고, 의미 있는 사용자 데이터도 모을 수 없다. MVP를 만드는 것은 비용이 든다. 아지랑이 같은 가설로 MVP를 만드는 행위는 이 비용을 공중에 날려 버리는 것과 다름없다.
사용성 위주로 생각한다.
사용성은 사용자 경험에서 가장 중요한 특성 중 하나다. 대부분의 우리 디자이너들은 이게 왜 문제인지 분노할지도 모른다. 하지만 적어도 MVP에서 사용성은 1순위가 되면 안 된다. MVP의 1순위는 가설 검증이다. 사용성에 대한 고려는 가설을 더 잘 검증하기 위한 수단으로써 선택적으로 진행되어야 한다. 만약 사용성을 1순위로 고려하면 개발해야 할 기능의 양이 늘어나게 되면서 빠른 테스트와 빠른 학습이라는 MVP의 본래 시스템을 왜곡할 가능성이 커진다. MVP가 본래 가진 목적을 잊지 말고, 무엇이 가장 중요한 기능인지 끊임없이 고민해야 한다!
3. 아마도 여러분은 지금...
여러분이 초기 스타트업에서 MVP를 시도하고 있다면, 이런 문제들을 마주하고 있을 것이다.
1) 완전히 0에서부터 모든 걸 만들어야 할 것이다.
처음부터 워터폴이 아닌 애자일 방식으로 작업하려는 팀이 있다면 말리고 싶다. 잘못하면 대혼돈의 멀티버스가 되기 쉽다. 모든 것을 처음 시작하는 상황에서는 지표도 없고 데이터도 없으니, 첫 MVP는 정성적 인터뷰에 기획 근거의 대부분을 의지하게 된다. 때문에 디자인 파트에서 서비스를 먼저 빠르게 설계하고, 그 과정에서 가능한 많이 개발자와 소통하면서 단계적으로 핸드오프 하는 방법이 빠른 MVP를 위해 좋다. MVP 이후부터 스프린트를 돌면서 애자일하게 프로젝트를 진행할 수 있으니, 조바심 내지 않는 것이 좋다.
2) 팀원 간에 사소한 갈등이 발생하고 있을 수도 있다.
초반에는 특히 각종 문제가 발생할 수 있다. 이를 마찰을 발생시킨 팀원들의 잘못, 또는 미리 조율하지 못한 리더의 잘못이라고 할 수는 없다. 오히려 작은 마찰들을 묻어두고 "우리는 문제없는 좋은 팀이야~" 라며 이상론적 접근을 하는 것이 더 큰 독이 된다. 자잘한 마찰을 빠르게 인지하고 이를 컨트롤 하에 둔 채로 지속적으로 관리하는 것이 좋다. 꼭 기억했으면 좋겠다. 팀원 간의 마찰은 필연이다. 우연히 발생한 불운이 아니다. 그러니 열린 마음으로 갈등에 대처하자.
3) 개발자와 디자이너 간에 신뢰가 확립되지 않았을 것이다.
기획 내용을 개발자에게 넘겨준다고 기획자의 역할이 끝난 것이 아니다. 실제 개발을 진행하면서 분명히 시간 안에 개발이 어려운 기능들이 나중에 발견된다. 그때 열린 태도로 빠르게 개발자와 협업하면서 해당 이슈에 대처해야 한다. 개발이 쉬우면서 서비스적으로 유사한 다른 기능으로 대체하는 방법을 찾아보는 것은 기본이고, 필요하면 과감하게 해당 기능을 없애는 용기도 필요하다. 덜어낼수록 앱은 뾰족해질 것이기 때문에 오히려 좋다. 만약 매우 중요하지만 MVP에서 꼭 검증할 필요는 없는 기능이 있다면, MVP 출시 직후 개발하기로 플랜을 조정하는 것도 좋은 방법이다. 이 과정에서 개발자에게 신뢰감을 줄 수 있다.
4) 이해관계자들과 프로덕트의 방향성에 대해 의견을 더 조율해야 할 것이다.
좋은 가설을 세우고 군더더기 없는 프로덕트를 만드는 것이 프로덕트 디자이너의 역할이라면 맞다. 하지만 전부는 아니다. 이해관계자들, 특히 C레벨 인원들과 현재 MVP가 목표하고 검증하려는 가설을 지속적으로 공유하는 것이 매우 중요하다. 분명한 근거로 소통할 수 있어야 하며, 이것을 잘할수록 여러분의 업무 능력을 높게 평가받을 수 있다. 개발자들과도 이를 공유해야 한다. 우리가 MVP를 기획한 의도에 그들이 더 공감할수록, 더 완성도 높은 프로덕트가 만들어질 가능성이 높아진다. 개발자들에게 그들이 존중받고 있다는 느낌을 주기에도 좋다.
4. 앞으로 여러분은...
A) 많은 기능이 필요하다고? 그냥 잘라 내라.
기간 내에 개발할 수 없는 서비스를 기획했다면, 개발자와 이야기하면서 크게크게 잘라 내라. 너무 중요한 기능이 많아 아무것도 버릴 수 없다고 생각한다면 우선순위를 구분하는 우리의 능력이 부족한 것이니, 외부의 도움을 받도록 해라. 기획자에게 가장 중요한 능력 중 하나는 무엇이 더 중요한지 구분하는 능력이다. 회사 내 다른 기획자나 개발자에게 기획한 내용을 설명하면서 덜 중요한 것들을 덜어내는 미팅을 갖는 것도 추천한다.
B) 같은 기능이라면 하나만 남겨라.
개발하기 힘들다. 만약 여백을 눌러서 팝업을 끌 수 있으면서, 동시에 팝업에 X 버튼도 두고 싶다면 그건 욕심이다. 어떻게든 사용자가 팝업을 끌 수만 있다면 굳이 기능이 두 개일 필요는 없다. 기능을 1순위로 생각해라. 사용성은 적어도 MVP에서는 2순위다.
C) 새로운 멘탈 모델에 욕심내지 마라.
여러분이 획기적인 기능으로 사용성을 극대화시키고, 멘탈 모델을 개척하고 싶다면 그건 MVP 이후에 하는 것을 추천한다. MVP 기간에는 레퍼런스 자료들이 여러분의 가장 좋은 친구다. 다시 말하지만, 사용성은 2순위다.
D) 믿을 것은 동료뿐이다.
개발자는 기획에 있어 가장 좋은 전우다. 서비스를 설계하면서 논리적으로 막히는 부분이 있거나 구현하기 어려운 기능 아이디어가 있다면 개발자에게 도움을 청해라. 기획 챕터가 정보를 독점하지 마라. 그들에게 모든 것을 공유하고 고민을 털어놓으면 그들은 문제를 해결할 좋은 아이디어를 줄 것이다. 반면, 개발자가 반영하기 어려운 기능 아이디어를 제안한다면 이를 반박함에 있어 명확한 이유를 제시할 수 있어야 한다.
만약 개발자가 기간 안에 만들기 어려울 것 같다고 말하면, 기간이 촉박하고 우선순위가 높다는 이유로 그들을 압박하지 마라. 개발자는 도구가 아니다. 일단 개발 단에서 해당 기능을 구현하기 위한 리서치를 가볍게 진행하고, 그래도 방법이 없으면 기간을 조정하거나 비슷한 역할을 할 수 있는 다른 기능을 제안해라.
5. 마치며.
"왼팔의 이것이... 동료의 증표다!"주저리주저리 얘기했지만 가장 중요한 건 동료들의 의견을 듣는 것이다. 그것만 가능하면 어떤 어려움도 함께 헤쳐나갈 수 있다. 팀 외부적인 상황 때문에 동료의 의견을 무시하는 건 없어야 한다. 오히려 이를 잘 조율하는 게 기획자의 숙명이다. 체계가 없는 상황 속에서 의지할 데라곤 동료밖에 없고, 상황을 이길 수 없다면 적어도 동료에게 납득 갈 만한 설명을 할 수 있어야 한다. 설명할 수 없으면 그건 고집이다. 이를 납득할 수 있게 잘 설명하고, 커뮤니케이션을 통해 팀 외부와 내부 간의 싱크를 잘 맞출수록 능력 있는 기획자라고 할 수 있다.
