우리가 MVP를 정하기 어려운 이유

월터의 상상은 현실이 되지 않기도 한다..

MVP 가 뭐길래?

글 하나 없이 텅 빈 블로그를 보다 보면, 서둘러 글 하나라도 올리고 반응을 살펴야할 것 같다. 처음에는 가벼운 마음으로 키보드를 두드리기 시작하지만, 얼마 지나지 않아 생각보다 내가 원하는 느낌의 글을 작성하는 것이 어렵다는 것을 깨닫는다. 사람들이 좋아하는 글을 작성하기 위해서는 재미있는 짤방도, 위트 있는 말도 필요할 것 같은데, 태생이 재미없는 놈이라 유머있는 글을 쓰는게 참 어려운 일이기 때문이다. 첫 글이니까 내가 어떤 사람인지 소개해야하나? 혹은 전문성이 있는 글을 써내려가야 하나? 고민해도 아무도 답을 알려주지 않는다. 결국 블로그는 쓰다 만 임시 저장글만 서너개를 가진 유령 블로그가 되어버린다. 욕심이 많은 나같은 사람들은, 빈 게시판을 한 페이지도 채 넘기기 전에 지레 글쓰기에 질려버리고 만다.

그런데, 이런 일은 초보 개발자가 앱을 만들기 시작하면서도 마찬가지로 발생한다. 내가 앱을 처음 기획하고, 여러 가지 이유로 방황하면서 주위 사람들에게 조언을 구할 때, 항상 들어왔던 조언이 있었다.

“최소 기능 제품(Minimum Viable Product, MVP)을 구현하려고 노력하는게 중요해!”

도대체 MVP 라는게 뭐길래 다들 입모아 말하는 걸까. 까짓거 다듬고 다듬어서 처음부터 완벽한 앱을 낼 수도 있는거 아닌가? (아니니까 글을 쓰고있겠지 ㅋㅋㅋ. ) 아무튼, 오늘은 내가 몰입(Moleep)이라는 앱을 만들면서 겪은 여러가지 시행착오를 통해 왜 최소 기능 제품에 집중해야하는지 설명해볼까 한다.

상상에 피드백을 할 수는 없다

내가 만들고자 했던 몰입이라는 앱은 친구와 함께 공부할 수 있도록 도와주는 앱이었다. 그동안 나는 혼자 공부를 할 때마다 뽀모도로 공부법이라는 공부법을 활용해왔었다. 여기서 뽀모도로 공부법이란 25분의 공부시간과 5분의 휴식시간을 번갈아가며 공부하는 방법을 말한다. 하지만 친구와 함께 공부할 때 는 뽀모도로 공부법을 활용하는 것이 꽤 어려운 일이었다. 친구와 함께 공부/휴식 타이밍을 맞추기 위해선 반드시 한명이 공부시간이 끝날 때마다 다른 한명에게 시간이 끝났다고 알려줘야했다. 또는 둘이 동시에 타이머를 맞춰서 켜고 꺼야만 싱크를 맞출 수 있었다. 친구와 함께 공부하고 싶지만, 귀찮은 건 딱 질색이었던 나는 앱을 통해 이를 해결하고자 했다.

앱을 기획하고 얼마 지나지 않아, 나는 바로 부모님과 친구들에게 피드백을 요청했다. 비록 구현된 실물은 없었지만, 내 아이디어가 세상 그 어떤 아이디어보다 뛰어나다고 생각했을 정도로 자신감에 차있었기 때문이었다. 부모님과 친구들은 다양한 피드백을 해주었지만, 대부분의 피드백은 ‘함께 공부하는 경험’ 보단 ‘무엇을 더 넣을지’에 초점을 두고 있었다. 예를 들자면, 타이머가 끝났을 때 알림이 있으면 좋겠다든지, 타이머의 모양을 더 다양하게 수정할 수 있으면 좋겠다든지 하는 것이었다. 나는 받은 피드백을 바탕으로 앱을 개선하려 노력했고, 덕분에 내 To-Do 리스트에는 만들고 개선해야할 요소들이 빼곡하게 쌓여갔다. 이때부터가 문제의 시작이었다.

친구들의 피드백을 받아들이고 고쳐나가다보니, 난 어느 순간부터 ‘함께 공유하는 타이머’가 아닌 ‘예쁜 공부용 타이머’를 만드는데 더 집중하고 있었다. 실시간 공유 기능은 구현이 어려웠기 때문에 피드백받은 다른 요소들을 고치는 것에 더 몰두하고 있었던 것이었다. 결국 정신을 차려보니, 나는 너무 많은 To-Do 리스트에 질려있었고, 프로젝트 더 진행하기 어려울 정도로 싫증이 나 있었다.

왜 이런 문제가 발생했을까? 아마 다양한 이유가 있었겠지만, 피드백을 받을 때 원하는 종류의 MVP를 제공하지 못했던 것이 큰 이유 중 하나라고 생각한다. 우리가 원하는 사용자 경험을 줄 수 있는 최소한의 제품을 가지고 있지 않은 상태에서는, 유의미한 피드백을 기대하기가 어려운 것이 당연했다. 원하는 피드백을 얻기 위해서는, 적어도 ‘함께 공부하는 경험’을 도울 수 있는 최소한의 프로젝트를 만들어야 했고, 이를 바탕으로 피드백을 요청했다면, 내가 원하는 종류의 피드백으로 이어질 수 있었을 것이다.

월터의 상상은 현실이 된다고? 아니다.. 월터도 MVP 를 먼저 만들었어야 했다.

그러면 어떻게 MVP를 만들지?

그렇다면, 도대체 무엇까지가 MVP이고 무엇이 부차적인 기능이라고 할 수 있을까? 사람마다 다양한 답을 할 수 있겠지만, 나는 사용자 경험을 제공할 수 있는 최소한의 제품이 MVP라고 생각한다. 예를 들어, 내가 몰입이라는 앱을 만들기 전에, 이 앱이 다른 사용자에게도 훌륭한 경험을 제공할지 알아보고 싶다면 어떻게 해야할까? 아마 정말 최소한으로 경험을 테스트해보고 싶다면, 함께 공부하는 학생 두명을 섭외하고, 내가 앱처럼 공부시간, 휴식시간마다 알려줄 수 있을 것이다. 이처럼, 만약 내가 발로 뛰어 원하는 경험을 이끌어낼 수 있다면, 그것 또한 MVP 라고 할 수 있다고 생각한다.

하지만 몰입은 멀리 떨어진 친구와도 원격으로 함께 공부할 수 있는 경험을 중시했다. 이와 같은 경우, 나는 최소한의 기능을 가진 앱을 만들어 볼 수 있을 것이다. 예를 들어, 로그인도 없고(어차피 테스터 2명만 사용하므로), 시작 버튼과 멈춤 버튼, 그리고 남은 시간만을 보여주는 앱을 떠올려보자.

비록 정말 허접하고 볼품 없지만, 연동기능이 ‘돌아가기는’ 하는 타이머를 구현할 수 있다면, 우리는 충분히 핵심 경험을 사용자에게 선보일 수 있다. 즉, 우리의 핵심 경험이 사용자 입장에서도 ‘충분히 좋은 경험’인지 테스트해볼 수 있게 된다.

MVP를 통해 사용자 경험을 이끌어낸 결과 그 반응이 썩 좋지 않다면, 우리는 빠르게 기존의 기획을 포기하거나, 개선된 경험을 구현해낼 수 있을 것이다. 하지만, 만약 이와 같은 과정을 거치지 않고 무작정 머릿속의 완벽한 앱을 구현하려고 한다면 어떻게 될까? 시장에 내놓은 시점에서 반응이 좋다면야 천만 다행이지만, 반대의 경우 개발을 위해 들인 시간과 비용은 누구에게도 보상받을 수 없게된다.

결과적으로 위에서 보인 MVP를 베이스로, 몰입은 지속적으로 사용자의 피드백을 바탕으로 꾸준히 발전했다. 아주 간단했던 UI 역시, 사용자의 경험을 더 발전시킬 수 있도록 심플하고, 또 직관적인 UI로 발전했다. 자랑을 한 스푼 가미하자면, 몰입은 앱스토어 출시 2주에 앱스토어 메인 페이지에 추천을 받는 영광을 누릴 수 있었다. 앱스토어 화면에서 내 앱을 본 그날의 감격을 잊을 수가 없다…..

초보 개발자로서 앱을 기획하다 보면, 내 앱이 사람들에게 만족감을 주기 위해서 여러 기능이 필요하다는 생각이 들곤 한다. 하지만, 개발자가 아닌 사용자의 입장에서 한번 기억을 떠올려보자. 우리 역시 ‘정말 필요한 기능을 가진 앱’이라면, 그깟 커뮤니티 기능, 소셜 공유 기능 따위가 없더라도 흔쾌히 다운로드 버튼을 눌러오지 않았나? (아님 말고ㅎ)

그러니 겁먹지 말고 작은 성공을 거듭하자. 성공을 거듭하다보면, 언젠가 나도 앱스토어 인기 순위에 올라있는 날이 오지 않을까?