제품 개발 방법론 시리즈(1) - MVP

Intro

[그림 1-1 : 개인적으로 MVP를 제일 잘 설명했다고 생각하는 그림]

MVP, Lean Start-up, Agile 등 개발 방법론에 대해서 평소에도 관심은 많았지만 자세히 볼 일이 없었기에 이번 기회를 통해 학습과 적용을 한번에 해보려고 한다.

MVP(Minimum Value Product)

MVP를 이용한 개발 방법의 포인트는 그림1-1처럼 자동차를 원하는 사람에게 자동차 전체가 만들어지는 과정을 보여주는 것이 아니라 “다른 곳으로 편리하게 이동한다” 라는 가치를 최소한으로 만족시킬 수 있는 제품을 고객에게 제공하고 적절한 피드백을 통해서 점점 사용자가 원하는 제품으로 발전해 나가야 한다는 것이다.
여기서 꼭 기억해야 하는 몇가지가 있다.

1. MVP 는 빠르지 않다!

기존의 방식, 그러니까 ‘자동차’ 라는 결과물을 처음부터 설계하고 제작을 하는 방식(1-1의 위쪽)이 자동차를 빨리 만들어서 고객에게 제공할 수 있다.
반면, MVP 를 중심으로 한 개발(1-1의 아래쪽)에서는 1 -> 2 단계를 제외하면 프로젝트를 완전히 엎고 다시 만들었다. 당연히 훨씬 오랜 시간을 투자해야 자동차라는 결과물을 만들 수 있을 것이다. 기존 방식의 프로세스가 견고하다면 시간적 차이는 더욱 벌어질 것이다.

2. 그럼 이걸 왜 하는거지?

다행히도 그림1-1에서는 고객이 원하는 조건을 90%정도 구현을 했다. 하지만 실제 시장에서는 아래와 같은 일들이 많이 발생한다.

[그림 1-2 : 짤은 언제나 큰 도움이 된다]

그림2-1에서 제일 큰 문제는 고객이 완성품을 받아보기 전까지 문제를 바로잡아줄 사람이 없다는 것이다. 속도는 빠르겠지만 빠른 속도로 잘못되고 있는 것이다.
MVP는 이런 문제를 해결하는 좋은 방법중 하나이다. 비록 고객이 처음 받아볼 제품은 원하는 수준에는 전혀 미치지 못할 테지만 당장은 고객의 문제를 해결할 수 있다. 이부분이 중요하다.

"MVP는 Minimum Value 를 반드시 구현해야 한다."

3. Minimum Value

모든 서비스는 고객의 어떠한 문제를 해결하기 위해서 존재한다(설령 고객이 그걸 문제라고 생각하지 않더라도!). 그림 1-1의 경우, 고객은 "원하는 곳으로 편하게 이동하지 못하는" 문제를 가지고 있다. 우리의 MVP인 ‘바퀴가 달린 판때기’는 최소한 걷는것 보다는 편하게 이동한다는 Minimum Value 를 제공하게 된다. 근데 저게 정말 걷는 것보다 편할까?

여기서 중요한것은 고객의 문제가 무엇인지 잘 파악하는 것이다.

그림 2-1 첫번째 칸에서 고객은 자신이 무엇을 원하는지 잘 설명하지 못했다. 예상하건대, 이렇게 이야기 했을 것이다.

고객 : “나무에 두꺼운 밧줄을 걸고, 판자로 연결해서 앉을 수 있으면 좋겠어요!”

여기서 매니저는 ”고객이 이걸 왜 필요로하지?”, ”이걸로 어떤 가치를 얻기를 원하는거지?” 같은 질문을 하지 않고
“나무, 두꺼운 밧줄, 판자, 연결하고, 앉을 수 있음” 같은 기능(Function)에만 집중해서 기획서를 쓰게 된다. 그 결과가 2번째 칸이다.

이 경우는 원하는 제품 자체가 워낙 심플해서 MVP를 만들기 힘들지만, 억지로 만들어보자.

우선, 고객과 프로젝트 매니저 사이에선 이런 대화들이 오가야 할 것이다.

매니저: “왜 나무에 밧줄을 걸기를 원하시죠”?,
고객: ”그래야 앞뒤로 왔다갔다 하죠!”
매니저: “앞뒤로 왔다갔다 하면 어떤 점이 좋은건가요?”
고객: “재밌잖아요!”
매니저: “그렇군요! 그렇다면 연결은 왜 해야 하는거죠?”
고객: “그래야 연결한 부분에 몸을 의지해서 공중에 매달릴 수 있죠!”
(이런 식으로 계속…)

엄청 바보같아 보이지만 이부분을 충실히 수행하면서 고객이 이 제품을 통해서 얻기 원하는 가치가 공중에 매달린 상태로 앞뒤로 왔다갔다 하면서 얻는 재미라는 것을 알 수 있게 되었다.
이 가치를 제공해 줄 수 있는 최소한(Minimum Value)을 생각해보면.

[그림 1-3 : 아! 아/ 아\ ~~]
이 그림 정도가 될 수 있을 것이다. 물론 힘도 많이들고, 앉을 수도 없으며 밧줄이 두껍지도 않고, 판자로 연결되어 있지도 않지만, 고객이 가장 원하는 공중에 매달린 상태로 앞뒤로 왔다갔다는 할 수 있다.
반나절 만에 밧줄을 나무에 묶어놓고 고객을 부른다. 당연히 아직 제품이 완전 초기 버전이고 많이 부족할 것이라는 정보는 주었다.

매니저 : “매달려보시죠!”
(매달려서 몇번 왔다갔다 한다)
매니저 : “어떤 부분이 불편하신가요?”
고객 : “우선 팔이 너무 아프네요. 앉을 수 있으면 좋겠어요. 그리고 밧줄이 너무 얇아서 불안하네요.... (블라블라)”
이런 식으로 피드백을 받으면서 제품을 발전시켜 나간다.

만약에 이렇게 안하고 프로젝트 매니저가 생각한대로 제품을 만들었다고 해보자.
당연히 MVP를 만들었을 때 보다는 많은 시간이 걸릴 것이다. 제품을 완성한 후에 야심차게 고객을 불러서 제품을 보여준다면 과연 고객은 만족할까? 매니저가 생각한 제품이 100프로 구현이 되었다고 해도 분명 MVP보다도 만족도가 현저히 낮을 것이다.

Warning: Not TODO

그림 1-1의 상황에서 많은 경우 이렇게 접근한다.

“우리는 앞으로 여기있는 기획을 따라 자동차를 만들거야! 근데, 요즘 MVP라는게 유행이라지? 그럼 이 기획안에서 1달 안에 최소한으로 구현할 수 있는 기능이 어떤거야?!”
이 문장 자체가 총체적인 난국이지만, 문제점을 2개만 뽑아보자.

1. 이미 기획이 완성되어 있다
   • 최종 목적지가 정해져있기 때문에 고객의 요청사항을 적극적으로 반영할 수 없다. 솔직히 그렇고 싶지도 않아진다!
2. “최소한으로 구현할 수 있는 기능이 어떤거야?!”
   • 위에서도 말했지만 우리가 구현해야 하는 Minimum 은 Value 이지 Function 이 아니다!
   • 완성된 자동차 제작 기획에서 Function 을 최소화 하면 당연히 타이어 한짝 밖에 안나온다.
   • 타이어 한짝을 MVP라고 만들어서 고객에게 제공하면 고객은 타이어를 들고 이동을 해야한다. 풀고자 했던 문제가 더 심각해진 것이다.

할 말은 더 있지만 결론을 말하자면,
이렇게 하면 모두가 힘들어진다.

덧붙이자면...

그림 1-1, 1-2 에서 확인 할 수 있는 것 처럼 MVP는 속도보다는 방향에 초점이 맞춰진 개발 방법이다. 그리고 제대로만 하면 고객 입장에서도 당장 해결하길 원하는 문제의 해법을 빠르게 제시한다는 점에서 속도의 이점도 가지고 있다. 완벽하게 기획이 완성되지 않았기 때문에 자연스럽게 짧은 호흡으로 제품을 개선시켜야 하고 이는 Agile, Lean Start-up등과 좋은 호환성을 보인다.