[번역] MVP는 끝났습니다. 이제는 MAP(Minimum Awesome Product) 입니다.

Jaewang Lee
8 min readDec 18, 2019

이 글은 Carlos Beneyto“The MVP is dead, long life to the MAP. (Minimum Awesome Product)” 를 번역한 글입니다. 모든 저작권과 권리는 Carlos Beneyto에게 있습니다.

직설적으로 말해서… MVP는 이제 끝났습니다. 시작하기에 앞서 MVP가 무엇인지 아는게 필요합니다. MVP는 무엇일까요?

MVP: Minimum Viable Product

MVP(Minimum Viable Product)는 초기 고객을 만족시키기에 충분한 기능을 갖추고 이후의 제품 개발을 위해 피드백을 받기 위한 제품입니다. 또한, 몇몇 전문가들은 MVP를 B2B 시장에서 시장성의 검증을 위해 사용하는 것을 추천하기도 합니다.

“팔리기 전까지의 제품은 MVP가 아니다. Viable 하다는 것은 해당 제품을 팔 수 있다는 것이다.”

위의 개념은 Wikipedia에 나오는 MVP의 정의입니다. 하지만 내 생각에 MVP에 대한 정확한 정의는 아래와 같습니다.

MVP는 가능한 최소 기능을 사용하여 제품을 출시 할 수 있도록하고, 제한된 기간동안 사용자의 행동과 관련된 정보를 몇몇 지표를 통해 학습하고 추출한 다음, 이를 기반으로 우리가 행동 할 수 있도록 하는 제품입니다.

아래의 이미지는 MVP를 설명하는 보편적인 방법입니다.

MVP의 예시 이미지 by Henrik Kniberg.

이 접근방식은 간단합니다.

차를 만들고 싶습니까? 좋습니다. 근데 어떻게 만들죠? 먼저 바퀴가 필요하겠고, 이것도 필요하고, 저것도 필요하고, 또 엔진도 필요하고… 흠… 원하는 차를 하나 만드는데 너무 오랜 시간이 걸릴 것 같군요. 그럼 해결책은? 먼저 스케이트보드를 만들어보고, 그 다음엔 자전거를 만들어보고, 이후엔 오토바이를 만들어보고, 마지막에 자동차를 만듭시다!

이 방식이 시간이 오래 걸릴 것 같아 보이지만, 앞선 방식에 비해 실행가능성이 높아보입니다.

이 포스팅은 MVP의 끝과 그에 대한 근거를 설명하기 위한 것이기 때문에 MVP에 대한 자세한 설명은 생략하겠습니다.

싸면서도 이쁘고 좋은 제품을 만드는 것은 어려운 일입니다. 그래서 MVP를 만들 때, 우선순위를 정해야 합니다. 예를들어 제품의 질보다 낮은비용을 우선순위로 두는 것입니다.

하지만, 과연 잠재 고객들이 실험제품이라고해서 제품의 질에 대한 기대치를 낮출까요?

이것이 내가 설명하고 싶은 가장 중요한 부분입니다. 시대가 바뀌면서 인터넷과 전자상거래 채팅앱은 더 이상 새로운 것이 아닙니다.

새로운 기술들의 등장으로 뜨거웠던 과거에, 잠재 고객들은 기업의 경영진이 아니라면 가질 생각하기조차 하기 힘들었던 인터넷과 스마트폰을 사용하기 시작했던 30대들 이었습니다. 하지만 모든 것들이 변했습니다.

12살인 내 이웃은 40년전에 NASA가 아폴로 11호에 필요로 했던 용량의 100,000배나 되는 스마트폰을 가지고 다닙니다.

기술 발전은 큰 걸음으로 나아가고 있으며 소비자들도 조금 느린 속도지만 발전하고 있습니다.

제가 14살 때는 페이스북, 인스타그램, 아마존, 왓츠앱 등이 존재하지 않았기 때문에 이들에 대해서 알지 못했습니다. 지금 전세계의 18~40세 사람들 중에서 앞선 서비스들을 모르는 사람이 있을까요? 거의 없을겁니다.

이런 상황들은 어떤 문제를 가지고 올까요?

사용자는 최소한의 품질에 익숙해졌으며 모든 신제품에 높은 품질을 기대합니다.

이것이 무엇을 의미할까요? 모든 사용자는 새로운 소셜앱이 페이스북, 인스타그램 등과 같은 다른 SNS와 해당 앱의 활동을 공유하기를 원합니다.

만약 새로운 소셜앱이 위와 같은 기능들을 갖추고 있지 않다면, 사람들은 이 서비스는 별로라고 생각할 것이며 사용하는 것을 고려하지 않을 것입니다.

따라서 저는 MVP는 죽었고 MAP가 새로 생겨났다고 생각합니다.

MAP: Minimum Awesome Product.

만약 여러분들이 지금 새로운 제품의 개발을 고려하고 있다면, 그것이 하드웨어든 웹이든 모바일 앱이든 상관없이 “이것이 내가 실현 가능한 최소한의 제품인가?” 라고 스스로에게 질문하지 마세요. 이런 질문은 처음에는 합당한 질문처럼 보이지만, 아래와 같은 질문이 더 좋을 것입니다.

“이것이 내가 실현 가능한 최소한의 끝내주는 제품인가?”

상황의 변화는 중요합니다. 과거에 우리는 출시될 제품이 ‘기능적으로 충분한가?’ 만을 고려했습니다. 사용자는 최소 2~3개의 기능들을 완벽하게 활용했었지만, 사용자들이 성장하면서 5~6개의 기능들을 이해하고 활용할 수 있게 되었습니다. 그래서 우리는 친숙한 느낌과 함께 사용자들을 놀라게 할 만한 더 많은 것들을 제공해야 합니다.

이 접근 방식의 예는 아래의 그림으로 설명할 수 있습니다.

구인구직 앱 디자인의 예시

위 2개 제품의 차이점은 무엇일까요? 2개의 제품 모두 같은 콘텐츠를 포함하고 있지만 MAP제품이 사용자들에게 더 믿을 만하고 매력적이게 보입니다.

이 테스트 앱의 주요 고객은 18~36살의 구인구직이 무엇인지 알고 Talent, LinkedIn, JobToday 등과 같은 다른 구인구직 서비스를 사용하고 있는 사람들입니다.

존재하는 구인구직 서비스

경쟁 업체가 수 년간 앞서가 있고 수십만 명의 고객이 이미 경쟁 업체의 서비스를 사용하고있을 때 평범한 제품으로 어떻게 경쟁 할 수 있을까요?

사용자들은 이미 “구인구직 앱은 어떠해야 한다” 라는 생각을 가지고 있기 때문에 기능과 속도, 유동성 뿐 아니라 제품의 디자인에서도 경쟁해야 한다는 점을 명심해야 합니다.

“진정한 경쟁은 제품에 더 나은 경험을 제공하는 것입니다.”

그리고 ‘더 나은 경험’ 이라는 것은 기능, 속도, 유동성, 디자인 등 모든 것을 포함합니다. 이것은 다른 서비스와 일대일로 경쟁하는 데 필수적입니다.

6~8년 전에는 “기준” 이 되는 디자인이나 디자인 패턴이 없었기 때문에 모든 것들이 발견되어야 했습니다.

MVP와 MAP가 무엇을 필요로 하는지에 대한 그래프

새로운 SNS 서비스로 예를 들면 여러분들은 검색 창, 메시징 시스템 및 즐겨 찾기 또는 좋아요 기능이없는 제품을 기대하시나요? 아닐 겁니다. 우리는 이미 머릿속에 SNS가 어떤 형태를 띄어야 하는지에 대한 생각을 가지고 있습니다.

그렇기 때문에 새로운 제품을 출시 할 때, 우리가 가지고 있는 자원 내에서 가능한 가장 빠르고, 실행 가능해야 하며, 경제적일 뿐 아니라 합리적인 가격을 가진 제품이 필요합니다. 우리는 고객들이 우리에게 기회를 줄만큼 충분한 경험을 할 수 있도록 노력해야 합니다.

“우리는 최소한의 기능을 가진 제품만이 아니라, 우리가 가진 자원 내에서 가능한 최고의 경험을 줄 수 있는 제품을 제공해야 합니다.”

또한, 여러분의 이해를 돕기 위해 Dave McClure Twitter 에서 이 포스팅에 대해 언급한 내용이 있습니다.

MAP는 목표 시장에서 경쟁 제품이 얼마나 “멋진가” 에 따라 크게 달라집니다. 경쟁제품이 없으면 MVP=MAP, 많다면 MAP>MVP 가 됩니다.

먼저, 나의 글에 코멘트를 달아준 Dave에게 깊은 감사를 표합니다. 이 아이디어에 대한 올바른 접근방식은 무엇 일까요? 간단합니다.

따라서, 다음에 MVP를 구상할 땐 경쟁제품이 없더라도 기능은 적지만 높은 완성도를 보이는 MAP를 고려하는 것이 좋습니다.

여러분들의 제품(MVP) 에 새로운 기능을 넣기 전에 그 기능이 정말 필요한지 생각해보세요. 그리고 정말 필요하다고 생각된다면, 그 기능이 완벽하게 보일 수 있게 (MVP) 만드세요.

“새로운 제품을 만들고자 한다면, 고객들의 기대치를 생각해보고 사용자들에게 가능한 한 최고의 경험을 줄 수 있도록 노력하세요.”

또 많은 분들이 MAP를 만드는 것은 MVP보다 더 많은 자원이 필요해 보이는데, MAP 제작을 위한 개발자들과 디자이너들을 어디서 찾을 수 있을까요? 라고 질문하시는데, 잘못된 질문입니다. MAP를 만드는 것은 개발자들과 디자이너들의 문제가 아니라 관리자의 문제입니다. MAP를 만드는 것은 단순히 몇 주나 몇 달안에 가능한 것이 아니기 때문에 여러분들은 기대치를 높이고, 동기를 부여하고, 이러한 모든 것들에 시간이 필요하다는 것을 알아야 합니다.

여러분들은 모든 것이 시간과 성숙함을 필요로 한다는 것을 받아들일 필요가 있습니다. 효율적인 관리는 좋은 MAP작성을 위한 솔루션 입니다.

--

--

Jaewang Lee

Dynamic backend developer and civil engineer, excelling in Spring and Node.js, fervently driven by GIS, computer vision, and satellite imagery