Duplicate
🎐

MVP 에서 배운 것들

이전 이야기

계획이 바뀌었다. 이전 이야기(그래서 나는 무엇을 만들고 있나)를 쓸 때까지만 해도 MVP 를 만들고, 초기 사용자를 모을 때의 이야기를 쓰려고 했다. 그런데 그 주제로 내용을 생각하다보니, 그건 그냥 순전히 나만을 위한 기록인데다가 어딘 가에는 남아있을 기록인지라, 읽는 사람의 시간이 아깝다는 생각이 들었다.
그래서 MVP 를 만들면서 배운 것들을 기록해야겠다.

MVP 란 무엇인가

MVP(Minimum Viable Product, 최소한의 쓸모를 갖춘 프로덕트)라는 말은 이미 스타트업 업계에서는 너무나 흔하다. 너무나 흔한 것들이 보통 그렇듯이, 제대로 이해하는 사람은 별로 없다. 사실 정리나 정의가 아닌지라 각자에게 다른 의미를 가질 수 있기 때문에 제대로 이해한다는 문장조차 틀렸다.
그럼에도 불구하고 MVP 의 뜻이 중요한 이유는, 모든 스타트업들의 첫 싸움판이기 때문이다(많은 스타트업들의 마지막 싸움판이 되기도 한다). 그 동안 일하면서 직접 뛰어들었던 싸움판과 옆에서 지켜본 싸움판, 그리고 건너건너 들은 싸움판만 생각해 보더라도... MVP 의 뜻은 중요하다.
MVP 하면 가장 많이 떠올리는 그림. 글 내용과 별 관계 없음. 그림 하나쯤 있어야지 해서 넣음.
삽질의 시간이 만든 나의 MVP 에 대한 정의는 "사용자는 이 프로덕트에서 ~~~을 할 수 있다"는 문장이다. 문장은 짧을 수록 좋고, 사용자 입장에서의 경험은 자세할 수록 좋다. 당연히 한 문장이 넘어서는 안 되고, 읽자마자 이해할 수 있을 수록 좋다. 의외로, 문장을 읽은 사람들이 "에게, 이게 뭐야"라고 말하는 것은 아무 상관이 없다.
예를 들면 이렇다.
"사용자는 이 서비스에서 원하는 웹페이지를 쉽고 빠르게 검색할 수 있다" - 구글
"사용자는 이 서비스에서 재학생들의 외모를 평가할 수 있다" - 페이스북
"사용자는 이 서비스에서 터치 몇 번으로 간편하게 송금할 수 있다" - 토스
"사용자는 이 서비스에서 주변 동네 사람들과 중고 거래를 할 수 있다" - 당근마켓
이것 만이 MVP다 라는 것이 아니라, 내가 잘 이해하고 내가 좋아하는 정의가 그렇다는 뜻이다. 정의는 알겠는데, 이게 왜 싸움판이 될 수 밖에 없는가는 언제나 설명하기가 어려웠다. 그러다 얼마 전에 읽은 식당, 생각을 깨야 이긴다 책에서 아이디어를 얻었다.

짜장면만 팔기

식당 창업을 프로덕트에 비유해 보면 재미있겠다는 생각이 들었다. 식당 창업자도, MVP 를 만드려는 사람도 모두 작은 자원으로 시작한다. 옛날부터 그랬듯이, 한정적 자원을 가장 효율적으로 쓰는 방법은 집중하는 것이다. 따라서 위 정의에 부합하는 MVP는 이런 식이어야 한다.
"고객은 이 식당에서 짜장면을 맛있게 먹을 수 있다"
저 문장이 결론이어야 한다. 그러니 싸울 수 밖에 없다. 짜장면만 팔아서 되겠냐, 지금 장사를 하겠다는 거냐, 옆동네 잘되는 중국집을 봐라, 요즘은 디저트가 트렌드다, 짜장면 싫어하는 손님은 어떻게 할거냐 등등. 재밌는 건 수많은 걱정과 노를 외치는 사람들이 정작 한가지 메뉴 식당이 맛집이라며 자주 추천하고 다닌다는 것이다.
MVP 에 대한 정의가 어려운 이유는, 한 문장으로 정리할 만큼 확실한 문제 정의가 없기 때문이다. 동시에 그 문제가 정말 풀만한 문제인 지 겁이 나기 때문인데, 이 때 해야할 것은 고객이 가진 문제를 어떻게든 일단 해결하기 위해 최선을 다해보는 것이지, 전선을 넓게 가져가는 일이 아니다.
"계란 후라이가 올라간 짜장면 파는 곳이 주변에 없다"는 문제를 제대로 파악했다면, 디저트가 없든 젓가락이 일회용이든 프로덕트는 팔린다. 나머지는 다 차차 좋아지게 하면 된다.

아니 그래도 짬뽕은 있어야지

아니 그래도 짬뽕은 있어야지라는 말은 이게 진짜 문제인지 모르겠다는 불안의 표현이요, 얼마 있지도 않은 자원이 낭비될 것이라는 나쁜 징조이며, 짜장면이 팔리지 않을 때 나는 책임을 피하겠다는 팀 파멸의 불씨이다.
간단한 목적을 가진 프로덕트가 가지는 장점은 수없이 많다. 사용자는 프로덕트를 사용할 때 깊은 고민이 필요없다. 고민없이 프로덕트를 사용하면, 그 문제가 생길 때마다 프로덕트가 자연스레 떠오른다. 사용자의 프로덕트에 대한 기대치를 파악하기 쉽고, 기대치를 맞추기 쉽다. 디테일에 집중함으로써 만족도를 더 쉽게 올릴 수 있다. 이렇게 쌓이는 디테일과 노하우가 경쟁력이 된다.
아니 그래도 짬뽕은 있어야지가 가진 가장 큰 문제는 집중의 분산이다. 짬뽕의 추가를 막는 것이 정말 정말 어려운 싸움이다. 일단 짬뽕이 추가되면, 탕수육도, 라조기도, 심지어 동파육의 추가를 막을 명분이 없다. 손님이 짜장면에 불만족을 느끼는 지, 인테리어에 불만족을 느끼는 지 알 겨를이 없다. 결국 게시판, 댓글, 팔로우, DM 등의 온갖 기능이 다 있지만, 모든 기능이 애매한 프로덕트는 한 두가지 메뉴를 늘려가다가 문을 닫는다.
프로덕트가 망하는건 한식, 중식, 양식에 통달하지 못한 요리사의 능력 부족때문이 아니다. 김밥천국식 메뉴가 유일한 전략이기 때문이다(물론 김밥천국식 메뉴가 유효한 전략일 때도 있다). 짜장면을 잘 팔 수 없는 식당은 다른 것도 못 판다.

내가 했던 실수

Oopy 의 MVP 정의는 이랬어야 했다. 사용자에게 가장 먼저, 가장 많이 전달하는 메시지도 이랬어야 했고, 더 많은 시간을 사용자들이 이 정의대로 행동하고 있는 지, 막히는 곳은 없는 지 알아보는데 썼어야 했다.
사용자는 Oopy 를 통해 노션 페이지에 주소를 연결할 수 있다.
짜장면 얘기하느라 정작 실수는 짧게 적는 느낌인데, 부끄러워서 그렇기도 하다. 한동안 만들고 싶은 기능을 많이 만들었다. 이것도 있으면 좋을 것 같고, 저것도 있으면 좋을 것 같은데라는 식으로. 그러면서 MVP 라는 단어 뒤에 숨어 완성도 떨어지는 기능들을 기능 목록에 추가하는 것으로 스스로를 달랬다.
정작 고객이 결제까지 이어지는 숫자를 가장 크게 높인 작업은, 기능을 추가하고 자랑하는 것이 아니라 '노션 페이지에 주소를 연결'하는 과정에서의 선택지를 없앤 일이었다. 이에 대한 더 자세한 이야기는 조만간 글 한편으로 정리 해야겠다.

다음 이야기

조금 다른 맥락으로, 누가 현재 Oopy 를 가장 잘 쓰고 있는지에 대해 써보면 재밌을 것 같다.