[디자인 프로세스] MVP는 정말 빠르고 쉬울까요?
이전 글 보러가기
[디자인 프로세스] 성장하는 디자이너란? 디자이너와 프로세스
[디자인 프로세스] 디자인 방법론은 어떻게 사용하나요?
MVP의 비유
보통 MVP(Minimum Viable Product)라고 하면, 아래와 같은 자동차 이미지로 많이 알려져 있습니다. 자동차로 비유되는 이유는 ‘린 스타트업’이라는 책에서 에릭 리스가 운전을 비유하여 설명을 이어 나가기 때문인 듯합니다. 그렇다면 너도나도 만들고 싶어 하는 MVP는 과연 쉬운 방법일까요? 우리는 빠르게 MVP만 만들어 내면 될까요? 이번 글에서는 디자이너가 바라본 MVP에 관한 생각을 정리해 보았습니다.
자동차보다 얼굴을 보자
사실 위 이미지에서 먼저 봐야 하는 것은 보드나 만들어지는 자동차가 아니라, 바로 얼굴의 변화입니다. 이 얼굴을 ‘사용자 경험’이라고 가정해 보겠습니다.
얼굴을 사용자에게 좋은 경험을 주는 과정으로 보면, 서서히 개선해 나가는 과정이 좋지 않은 제품을 공급하다가 갑자기 좋아지는 것보다 더 좋은 방법으로 보입니다. MVP라는 개념의 매력적인 부분은 처음부터 사용자 경험이 좋지 않을 수 있다는 가정입니다. 사용자 경험이 0이나 1이 아니라 -1에서 시작합니다. ‘나쁨’에서 시작한다는 점이 인사이트입니다.
자세히 보면, A 방법을 써도 사용자는 결국 만족합니다.
지금은 사용자 경험과 프로토타입, 테스트, 피드백 같은 개념과 어휘, 정보와 지식이 풍부하지만, 린 스타트업의 배경이 되는 1990년대에는 생소한 개념이었습니다. 1998년에 경험 경제라는 말이 나왔고, 2007년 6월에 첫 아이폰이 출시되었습니다.
지금도 그렇지만 공장에서 생산되는 완성품과 달리 소프트웨어는 출시는 했지만, 잘 만들어지지 않은 채로 계속 사용자에게 노출되는 경우가 많았습니다. 소프트웨어는 어려운 것이 당연했습니다. 소프트웨어에 의견이나 불만을 제기하면, 편지나 전화의 속도로 전달되었습니다. 불편함은 당연했고 제품의 개선은 피드백보다 훨씬 느렸습니다.
그래서 스케이트보드와 스포츠카 역시 비유로 이해해야 합니다. 스케이트보드가 주는 가치와 스포츠카를 타는 가치의 크기로 보면, 전체 그림의 맥락이 맞아가기 시작합니다.
처음에 스케이트보드는 사용자를 만족시키지는 못하지만, 동작합니다. 부품이 아니라 동작하는 것을 보이는 것이 중요합니다. 그리고 기능이 완결되어 있습니다. 자동차의 구조에서 가장 근본적인 설명을 굴러가는 물건이라고 보면, 스케이트보드는 굴러가는 물건의 최소 기준을 충족하며, 사람이 사용할 수 있는 최소 기준도 충족합니다.
그런데 여기서 실제 소프트웨어 제작의 환경이 문제되기 시작합니다. 실제로 스케이트보드를 만들다가 자동차를 만들긴 매우 어려우며, 그 중간 단계가 자전거와 오토바이가 될 순 없습니다.
Educati를 운영하는 프레드도 비유의 엄밀함이 중요하다고 느낀 것 같습니다. 그래서 MVP에서 제품이 성장하는 과정에 더 집중한 비유를 만들었습니다.
방법론이 유명해지고, 설명하는 이미지의 메시지가 이해하기 쉬워질수록, 제작하는 사람의 모델에서는 점점 멀어집니다. 그래서 시장과 사용자의 트렌드에 맞게 개발 방향을 바꾸려는 움직임과 변경된 방향에 대한 리스크를 책임져야 하는 사람 간의 갈등이 일어나게 됩니다.
제작 방향이 급격하게 바뀌면, 디지털 프로덕트는 애매한 상태로 출시됩니다. 애매한 제품을 MVP라고 말할 수는 없습니다. 특히 시간과 돈이 부족한 환경에서는 “일단 내보자”가 MVP가 되어선 안 됩니다.
빨리 출시하는 제품과 가치를 검증하는 제품
“일단 출시해 보자!”는 린 스타트업에서 가장 피해야 하는 사례로 나옵니다. 가치가 검증된 제품을 사용자에게 전달하는 것과 ‘일단 출시해 보자!’의 제품에는 큰 차이가 있습니다. 출시에 집중하면 과정을 생략하게 되고, 과정을 회고할 수 없으면 경험에서 실력을 쌓을 수 없게 됩니다.
“일단 출시해 보자!”로 얻을 수 있는 것
- 부정확한 목표와 대상
- 너무 많은 목표
- 부족한 시간으로 완결되지 않은 기능
- 기획부터 디자인까지 모든 것에 대한 피드백
- 그래도 빨랐다는 기분
가치를 검증하는 제품을 만드는 것은 빠를 수도 있지만, 시간이 정말 많이 걸릴 수도 있습니다. 빠르게 MVP를 제작하자는 말은 그래서 매우 위험합니다. 최소한 MVP라는 말을 제거하고, 그냥 빨리 만드는 프로세스를 만드는 편이 낫습니다.
그냥 빨리 만들게 되면, 제품의 성공을 순수한 우연에 걸어야 합니다.
물론 우연에 기대지 않고, 한 걸음씩 회고하면서 진행되는 방식은 어렵습니다. 마법의 이미지 뒤에는 실제로 성공할 만한 노력이 필요합니다. MVP라는 용어가 너무 유연하게 쓰이기 때문에, MLT, MVT 등의 용어도 나오고 있습니다. MLT의 L은 Lovable, MVT의 Minimum Viable Testing입니다.
하지만 아무리 좋은 목적과 서술이 있어도, 제작 과정은 언제나 시간과 돈이 부족합니다. 엔지니어와 디자이너들은 10년 전이나 지금이나 창의적인 아이디어가 무섭습니다. 프로덕트는 되돌릴 수 있지만, 제작 능력을 성장시킬 수 있었던 시간과 에너지는 되돌아오지 않습니다.
빠른 출시와 업데이트는 MVP를 검증하고, 성장시키는 과정이지, 팀원을 번아웃 시키는 과정이 되어선 안 됩니다. 조금만 생각해 보면, MVP는 논리나 개념이 아니라 팀에서 시작됩니다. 가치를 검증하는 프로세스와 그에 맞춰서 최소한의 기능으로 목표를 만족시키려면, 숙련된 스킬과 충분한 경험이 필요합니다.
최소한 좌석과 핸들, 차대와 바퀴는 있어야 자동차가 되겠죠. 차에 집중한 비유를 다시 살펴보면, 1번 단계에서는 엔진이 없다는 것을 알 수 있습니다. 성공한 스타트업의 자세한 일화를 살펴보면, 처음부터 모든 것이 풍족했던 사례는 거의 없었습니다. 개발자나 디자이너가 없거나, 서버가 없거나, 프로그램이 없어서 실제로 사람이 움직이지 않으면 작동하지 않는 프로덕트나 서비스가 많았습니다. 가장 중요한 점은 계속해서 주변 상황과 사용자, 시장에 맞게 제품을 개선하면서 가치를 키웠다는 점입니다.
방법론에 대한 여러 가지 회의적인 시각도 있고 너무 가볍게 받아들이기도 하지만, 진짜 문제에 집중하게 되면 무엇을 해야 하고 얼마나 먼 길인지 더 명확하게 보이는 것 같습니다.
마치며
실제 전쟁에 참여한 병사가 한 유명한 말이 있습니다.
“좀 쉬워 보이는 길에는 언제나 지뢰가 깔려 있다.”
경험이 부족할수록 지식은 큰 힘이 되어 줍니다. 그러나 경험이 부족할수록 더 간결하게 알고 싶어집니다. 경험이 적을 때 얻은 지식은 강렬하고, 세부 사항 없이 얻은 지식은 쉽게 편견이 됩니다. 너무 쉽고 편리해 보이는 지식과 방법에는 항상 숨겨진 리스크가 있다는 점을 기억하면 좋겠습니다.
<원문>
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
