Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

Contents

MVP는 무엇인가 ?

애플리케이션에 대한 아이디어를 실현하는 가장 좋은 방법은 MVP(Minimum Viable Product)로 시작하는 것이다.

인터넷은 수백 수천개의 회사가 경쟁하는 열린 공간이다. 이 공간에서 성공하는 것은 쉽지 않다. 성공을 하기 위해서는 고객이 원하는 것이 무엇인지를 찾아서 가능한 빨리 시장에 내놓아야 한다.

MVP(Minimum Viable Product)는 2011년 Eric Ries가 도입한 린 스타트업방법론에서 시작된 개념이다. MVP의 정의는 다음과 같다.

최소 실행 가능 제품은 팀이 최소한의 노력으로 고객 요구와 선호에 대해 최대한 많이 배울 수 있도록 계획해서 만든 제품의 버전이다.

중요한 점은 팀이 시장에 실제 작동하는 제품을 배포한다는 것이다. 잘 설계된 MVP는 제품과 사용자의 상호작용을 관찰하여 검증된 정보를 수집할 수 있다. MVP 전에는 대상 고객에게 "대략 이러한 기능의 제품이 존재한다면, 어떻게 사용하시겠습니까"라는 식의 설문조사를 하는 방법을 많이 사용했는데, 앱은 훨씬 더 통찰력있는 정보를 제공 할 수 있다.

MVP를 사용하면 완전한 제품을 구축하기 위해서 많은 시간과 돈을 투자하지 않고도 제품의 아이디어를 검증할 수 있다.

MVP의 목적

MVP가 제공하는 비즈니스 가치는 아래와 같다.
  • 빠른 시장 출시 : 가능한 빨리 제품을 출시하여 다른 회사보다 경쟁 우위를 확보한다.
  • 비즈니스 아이디어의 테스트 : 큰 예산이 들어가는 본격적인 제품 개발에 앞서 실제 사용자로 부터의 피드백이 가능한 더 간단한 버전의 앱의 출시
  • 고객 선호에 대한 학습 : 목표시장에 맞는 것과 그렇지 않은 기능을 미리 파악하여 잠재적인 사용자의 기반을 확대한다.

제품 생존성과 미니멀리즘의 균형

MVP의 중요 요소들을 먼저 살펴보자.
  • 최소 : MVP는 사용자의 기본적인 요구사항을 충족하는 최소한의 기능만을 포함한다. 그 이상의 기능을 포함하여 프로젝트의 복잡도를 높이지 않도록 한다.
  • 실행 가능 : MVP는 실제 작동해야 한다.
  • 최소 + 실행 가능 : 즉 MVP는 사용자의 가장 중요한 요구사항(혹은 사용자에게 제공하고 싶은 핵심 요구사항)을 실행가능한 형태로 제공해야 한다.
제품의 미니멀리즘실행 가능성을 보장하는 것이 MVP 개발의 핵심이다. 따라서 MVP는 이 제품이 어떻게 작동하는지 보다 제품이 어떤 일을 하는지에 초점을 맞추는 것이 좋다.

그렇다고 해서 기능이 작동만 하는 수준으로 개발해야 하는 건 아니다. MVP는 PoC(Proof of Concept - 개념검층) 이나 프로토타이핑 처럼, 개념이 검증되면 버리고 새로 프러덕트를 개발하는 그런 것이 아니다. MVP는 엄연히 프러덕트이며 따라서 향후 확장 가능하도록 만들어야 한다. 예컨데, 기술 부채를 가질 수 있지만 기술 부채를 쉽게 갚아나갈 수 있는 모습으로 개발해야 한다.

MVP 출시 후 해야 할 것들

출시 후 MVP의 목표는 고객의 피드백을 수집하여 측정하는 것이다. 그리고 가치를 쌓아나갈 수 있도록 애플리케이션 기능을 계획하고 우선순위를 정해서 새로운 버전을 배포해야 한다.

MVP를 이용한 제품 출시에는 스프린트(Sprint)가 괜찮을 것 같다. 매 스프린트에 증분을 계획하고 우선순위를 정해서 가치를 쌓아나가는 방식이 MVP를 확장하는 것과 결이 잘 맞기 때문이다.

MVP가 비즈니스에 주는 것들

초기 사용자 피드백

MVP를 시장에 출시함으로써 기업은 제품에 대한 소비자의 관심을 확인하는 초기 데이터를 얻을 수 있다. 이를 통해서 제품의 전체 개발을 위해서 잘 못 지불될 수 있는 시간과 비용의 위험을 최소화 할 수 있다. 또한 사용자가 마음에 들어하는 기능과 부족한 점을 면밀히 검토 할 수 있기 때문에 효과적인 다음 버전 출시가 가능하다.

Google Play와 Apple App Store에 남겨진 댓글에서 사용자에 대한 많은 것들을 배울수 있다. 또한 애플리케이션을 통해서 고객 만족도 설문조사를 배포하거나 사용자 액션을 분석하는 기능을 넣어서 배포 할 수도 있다.

MVP는 개발 중간에 의사결정자에게 작동하는 애플리케이션을 보여줄 수 있다는 장점도 있다. 프리젠테이션과 작동하는 애플리케이션의 간극은 생각보다 크다.

시간과 돈의 절약

소수의 리소스를 투입하여 개발 할 수 있으므로 리소스(시간, 사람, 돈)을 절약하는데 도움이 된다. 사용자가 무엇을 필요로 하는지 모른채 본격적인 제품에 투자하는 것은 위험하다. 먼저 MVP를 구축하면 성공할 가능성이 있는 프로젝트에 투자하고 있는지 확인 할 수 있다.

투자 유치

프로젝트에 투자를 받을 확률이 더 높아진다. 이 투자는 외부의 투자 뿐만 아니라 내부의 투자(지원)도 포함된다. 이들의 지원을 받을 가장 확실한 방법은 작동하는 애플리케이션을 보여주는 것이다. 프리젠테이션은 투자자를 유치하는데 큰 도움을 주지만, 그것만 가지고는 투자자들의 결정을 얻어내기는 쉽지 않다.
  1. 그럴듯 하지만, 정말 고객에게 그럴듯하게 보일지 알 수 없다.
  2. 프리젠테이션만 가지고는 문서에 표현된 아이디어를 실제 구현 할 수 있을지 알 수 없다. 특히 요즘처럼 기술조직을 확보하기 힘든 때는 더욱 그렇다. MVP를 가지고 있다는 것은, 해당 조직이 아이디어를 구현할 기술 역량을 가지고 있다는 것을 증명한다.

MVP를 위한 적절한 계획과 설계란 무엇일까

"최소한의 기능을 가지고 빠르게 출시하지만, 출시 후 계속적으로 확장/성장 가능하도록 충분한 품질, 충분한 확장 능력을 가진 제품을 개발해야 한다." 너무 이상적으로 들린다. 이게 가능한가. 가능하게 하려면 어떻게 해야 하는가 ?

이러한 문제들 비즈니스 조직은 성공적으로 MVP를 만들고, 기술자산, 설계 및 개발노하우를 쌓기 위해서 숙련된 개발 에이전시와 협력하거나 개발 조직을 만들어야 한다.

  • 고객에게 어떤 가치를 제공 할 것인가. : 인터넷을 통한 자료 수집, 고객 층과의 직접적인 인터뷰 및 설문, 내부 아이디어 회의를 통해서 고객에게 제공할 가치를 식별한다. 가치는 매우 추상적이기 때문에 고객을 위해 해결하려는 문제를 식별하는 것은 가치를 구체화하는 좋은 방법이다.
  • 기존 경쟁사 분석 : 경쟁사를 분석하자. 경쟁사를 분류하고 그들이 어떤 문제를 해결 했는지, 어떤 문제를 해결하지 못했는지를 검토한다.
  • MVP 기능 목록을 만든 다음 최소한으로 좁힌다. 사용자가 제품을 사용 할 때의 수행 단계를 정의하고 각 단계에 필요한 기능을 나열한다. 그런 다음 제공하려는 가치를 기준으로 우선 순위를 설정한다.
  • 작업 범위를 정의하면 MVP 개발을 시작 할 수 있다.

고객의 해결해야 할 문제점을 MVP의 가치로 만든다.

결정하기 어려운 사건들은 안 좋은 법을 만든다.

IT 조직의 가장 중요한 목표는 고객에게 가치를 전달하는 애플리케이션을 개발 하는 것이다. 문제는 이 가치를 만드는 것이다. 고객이 원하는 것을 찾는 과정이 필요한데, 이게 쉽지 않다. 우리는 흔히 고객에게 감정을 이입해서, 고객의 입장이 되면 가치를 찾을 수 있을 거라 생각하지만 이게 쉽지 않기 때문이다. 고객도 자신들이 원하는 가치를 모르는 경우가 대부분이기 때문이며, 자기가 처한 상황에 따라서 가치의 범주가 크게 달라지기 때문에, 설문이든 인터뷰든 하고 나면 그래서 우리가 어떤 가치를 구현 할 건데 ?라는 결론에 다다를 확률이 높다. 결정하기가 쉽지 않다는 건데, 결정하기 어려운 문제는 결국 좋지 않은 기능으로 이어진다.

따라서 MVP에서는 어떤 문제를 해결하는게 좋을지라는 관점에서 접근하는게 가치를 찾는 좋은 방법론이 될 수 있다. 무엇이 문제인지 찾기 어렵다면, 좋은 기능을 만들기 위해서 훨씬 더 많은 시간, 비용, 능력을 투자해야 할 것이다.

MVP를 개발 할 때 주의해야 할 점

완전한 제품을 만들고자 하는 충동

우리는 MVP가 최종 제품이 되어서는 안된다는 것을 기억해야 한다. 하지만 조직은 사업적 관점에서 그리고 기술적 관점에서 완성된 제품을 만들고 싶어하는 욕망을 가지고 있으며, 이런 욕망 때문에 최소한의 기능으로 제한하고 이를 개발하는데 실패한다. 이들은 종종 앱 디자인에 많은 투자를 하여 나중에 개선할 여지를 거의 남기려고 하지 않는다. 사용자에게 좋은 인상을 주는 것도 중요하지만 제품이 실제 문제를 해결하는지를 모른채 사용자 경험에 많은 시간과 돈을 투자하는 것은 위험하다.

시장 조사를 진지하게 받아들이지 않음

시장에 대한 이해는 MVP의 성공 확률을 높인다. 사람들은 혁신적인 아이디어를 지나치게 믿는 경향이 있는데 물론 아이디어어를 믿어야 하겠지만 시장 조사를 무시하는 것은 엄청난 비용을 초래 할 수 있는 심각한 실수다. 따라서 연구를 수행하고 결론을 도출하고 구현해야 한다.

프로토타입 단계 건너뛰기

프로토타이핑은 MVP를 개발하는데 필수적인 단계다. 프로토타입은 아이디어를 실현하는 첫번째 단계로 전체 앱 개발 프로세스에 막대한 영향을 미친다. 여기에서 제품의 기본구조, 인터페이스, 아키텍처, UX에 대한 스케치를 구축할 수 있다. 또한 프로토타입을 통해서 기획자와 개발자는 우리가 무엇을 개발하는지를 정확하게 알 수 있게 된다. 이 단계를 건너뛰고 바로 개발에 뛰어들면 나중에 많은 혼란을 초래할 수 있다.

잘못 된 팀 세팅

경험이 부족한 개발팀은 실현 가능한 아이디어를 몰락시킬 수 있다. 그러므로 MVP를 제시간에 최상의 상태로 제공할 수 있는 믿을 만한 팀을 선택하는 것이 중요하다. 애플리케이션 개발 서비스를 제공하는 회사의 프로필과 리뷰를 참고하여 MVP 개발을 시작 할 수 있다. (대한민국의 경우 관련 서비스를 제공하는 전문회사가 있는지 살펴봐야 겠다.)

MVP 구축 방법

제품이 해결할 문제정의

MVP를 구축하기 위한 첫번째 단계는 앱이 해결할 정확한 문제를 식별하는 것이다. 이 문제가 무엇이며, 누가 겪고 있는지 알아야 한다.
  1. 내 앱이 해결 하는 문제는 무엇인가 ?
  2. 내 앱의 가장 중요한 목표는 무엇인가 ?
  3. 내 제품의 최종 사용자는 누구인가 ?
  4. 목표 고객에게 이 문제가 얼마나 중요한가
  5. 내 앱은 어떤 이점을 제공하는가 ?
  6. 내 입이 목표를 충족하는지 어떻게 측정 할 수 있는가 ?

제품 캔버스

제품 캔버스는 전체 제품의 비전을 하나의 페이지에 표현한 것으로 제품의 전략적 계획을 수립하기 위한 훌륭한 도구다. 이 캔버스는 아래의 요소들로 구성된다.
  1. 제품의 이름
  2. 제품의 목표 : 프로젝트의 가장 중요한 비즈니스 목표 (예: 시장에서 가장 빠른 차량 공유 앱 구축)
  3. 규모 : 시장규모
  4. 대상 그룹 : 앱의 최종 사용자와 그들의 고유 요구사항
  5. Big Picture : 제품의 사용자 경험(UX). 사용자 여정, 기능, 시각적 디자인 및 비 기능적 속성
  6. Next Big Thing : 다음 제품 반복(증분이라고 한다)마다 도달해야 하는 목표를 위한 기능항목.
제품 갠버스를 구축하는 시점은 경쟁자를 검토하기에 가장 좋은 순간이기도 하다. 시장에 유사한 앱이 있는지, 그들은 문제를 어떻게 해결하고 있는지, 이 문제를 해결하기 위한 접근 방식의 독창성을 검토 할 수 있다.

페르소나

다양한 유형의 잠재 사용자를 포착하는 가장 좋은 방법은 사용자 페르소나를 작성하는 것이다.

페르소나란 애플리케이션의 최종사용자를 나타내는 가상의 캐릭터다. 가상의 캐릭터의 행동, 목표, 욕구를 산정하여 이를 기반으로 아이디어를 만드는 것이다. 페르소나는 아래와 같이 만들 수 있다.
  1. 이름 : 사용자의 이름
  2. 나이 : 사용자의 나이
  3. 직업 : 사용자의 직업과 역할
  4. 목표 : 사용자가 당신의 앱을 이용해서 얻고자 하는 것
  5. 사용자 여정 : 사용자는 목표를 달성하기 위해서 무엇을 하고 있는가
  6. 느낌 : 여정의 과정에서 사용자는 언제 좌절 했는가, 언제 행복을 느꼈는가.

식별한 문제의 가장 쉬운 해결책 찾기

이 과정은 핵심 기능에 촛점을 맞추도록 도와주기 때문에 MVP 개발에서 중요한 단계다.

Alberto Brandolini 가 만든 Event Storming는 이용해서 복잡한 비즈니스 영역을 빠르게 탐색 할 수 있는 워크샵 형식의 프로그램이다. 이를 통해서 팀원들이 제품의 주요 목표와 비즈니스 목표에 대해서 이해를 공유할 수 있다. 또한 Event Storming를 사용하여 프로젝트의 잠재적 장애물을 식별하거나 개선사항 및 새로운 기능을 발견할 수 있다. Event storming를 이용해서 애플리케이션의 비즈니스 프로세스를 최적화 할 수 있다.

 Event storming

Event Storming은 넓은 벽과 무제한의 공간, 메모 할 수 있는 스티커, 같은 공간에 모인 비즈니스 및 기술 인력이 필요하다. 첫번째 단계에서는 도메인에서 발생 할 수 있는 일을 기록한다. 이러한 사건은 초기에는 서로 분절되어 있을 것이며, 특별한 시간순서도 가지지 않을 것이다.

그런 다음 각 이벤트의 발생 원인, 원인이 발생하는 조건과 제약을 파악한다. 이 과정에서 각 모듈을 묶을 수 있는 규칙을 찾을 수 있을 것이다. 결과적으로 파편화되었던 각 사건들이 서로 연결되고, 이 사건들이 범주화 되면서 도메인을 구성하는 핵심 기능과 역할을 식별 할 수 있게 된다. 여기에서 얻은 정보를 기반으로 설계를 수행한다. 분해, 연결, 범주화의 과정을 거친다고 보면 된다. Event Storming는 언젠가 따로 정리를 해야 겠다.

사용자 여정

사용자가 애플리케이션을 통해 이동하는 방법을 표시하는 사용자 여정 맵을 준비한다. UX/UI 형태로 표현이 된다. 이 지도는 Event Storming 워크숍에서 확인된 이벤트를 기반으로 한다.

사용자 여정 맵은 사용자의 흐름을 단계별로 시각화 한다. 개발자와 디자이너는 와이어프레임워크와 클릭가능한 애플리케이션 프로토타입을 만들 수 있는 툴을 사용한다.

 사용자 여정을 맵으로 표현하다

앱 기능의 우선순위 지정

이제 MVP에서 가장 중요한 기능을 결정해야 한다. 핵심 기능의 선택 조건은 아래와 같다.
  • 앱이 해결하는 문제
  • 애플리케이션의 일반적인 목표
MVP는 비전이 아니라 앱이 해결하려는 문제에 집착해야 한다. MVP를 만드는 주요 목적은 최종 사용자가 사용 할 수 있는 일련의 기능을 제공하며, 향후 개발을 위한 피드백을 전달하는 것이라는 걸 잊어서는 안된다. 우선순위차트를 만들면 도움이 될 것이다. 우선 순위 차트는 MUST, SHOULD, COULD의 단계를 가진다.

 핵심 기능에 집중

제품의 출시, 피드백 수집, 반복

제품이 출시되면, 사용자의 피드백을 수집하고 이를 분석해서 다음 이터레이션을 시작한다. 각 이터레이션마다 가치의 증분이 발생하면서 애플리케이션이 발전한다.

MVP를 개발하는 것은 최종 목표가 아니다. 이는 디지털 제품을 구축, 개선, 유지하는 장기 프로세스의 초기 시작점일 뿐이다.

MVP의 예

DropBox

회사의 공동 설립자인 Drew Houston이 자신의 제품에 대한 아이디어를 내놓았을 때, 제품의 초기 버전을 출시하지는 않았다. 대신 그들은 제품이 작동되는 방식을 설명하는 비디오를 제작해서 게시했다. 이 비디오만으로 하룻밤 사이에 베타가입이 5000에서 75000으로 늘었다.

에어비엔비

플랫 쉐어 플랫폼의 공동 설립자인 Joe Gebbia와 Brian Chesky는 샌프란시스코의 대형 로프트 아파트에 살았고 임대료를 지불하는 데 어려움을 겪었다. 그 때 그들은 도시에 오는 사람들에게 숙박 시설을 제공하는 아이디어를 생각해 냈다. 그들은 몇 장의 사진을 가지고 있는 간단한 웹 사이트를 제작하고 세명의 손님에게 서비스를 제공했다. 믿기 어렵겠지만 이것이 그들이 오늘날 연간 매출 26억 달러에 달하는 회사를 설립한 방법이다.

인스타그램

인스타그램의 MVP는 사진필터 기능이었다. 이 앱을 통해 사용자는 사진을 찍고, 필터 중 하나를 적용하고, 기기에 사진을 저장 할 수 있었다. 그러나 인스타그램이 즉각적인 성공을 거둔 이유는 다른 앱 사용자와 사진을 쉽게 공유 할 수 있는 옵션이었다. 이 요구사항은 고객으로 부터 나왔고, 인스타그램은 고객의 피드백을 받아들여서 이 기능을 추가함으로써 오늘날 우리가 알고 있는 인스타그램이 되었다.

프로토타입과의 차이

최종 제품을 출시하기 위한 가장 중요한 단계는 아이디어 검증이다. 이때 사용 할 수 있는 방법이 프로토타이핑과 MVP이다. 사람들이 종종 이 두가지를 혼동하기 때문에 설명이 필요할 것 같다.

제품 아이디어가 있을 때, 이것이 효과가 있을지 여부를 확인해야 한다. 프로토타입은 추가 개발전에 저렵하고 빠르게 선택할 수 있는 옵션이다. 프로토타입을 이용해서 미래의 제품이 어떻게 작동하고 어떻게 보일지 알 수 있다.

따라서 프로토타입은 미래 프로젝트의 기본적인 구현이다. 이것은 아이디어가 살아서 실행될 수 있음을 보여주기 위해 투자자에게 소개하는 스케치와 같다. 프로토타입은 기술 문서에 비해 투자자가 이해하기 쉽기 때문에 중요하다.

MVP 개발로 넘어가기 전에 다양한 범위의 프로토타입을 만들어야 할 수 있다. 프로토타이핑은 스타트업 제품에 대한 참신한 아이디어를 창출하는 데에도 효과적이다.

MVP는 초기 고객을 만족시키고 향후 제품 개발에 대한 피드백을 제공하기에 충분한 기능을 갖춘 제품이다.

제품과 서비스에 대한 아이디어가 있고, 이미 프로토타입을 제작한 경우에도 이 아이디어가 지출할 가치가 있는지 확인해야 한다. MVP는 시간과 돈의 낭비를 피하는데 도움이 된다. 추가로 확장 및 수정할 수 있는 기능적 제품을 구축하는 빠르고 효율적인 방법이다.

스케치 수준인 프로토타입과 달리 MVP는 시장에 출시할 준비가 된 거의 완전한 제품이다. MVP에 필요한 것은 대상 고객의 피드백과 MVP에 대한 검증 뿐이다. 프로토타입과 달리 MVP는 제품이 확장됨에 따라 기능이 추가될 수 있으므로 보다 심도 있는 기술 개발이 필요하다.

 Prototype 와 MVP

MVP와 클라우드

클라우드는 MVP를 구축하기 위한 좋은 플랫폼이다. 클라우드가 제공하는 관리형 서비스와 베스트 프랙티스를 이용해서 개발을 할 수 있다. 핵심 비즈니스 로직(코드)를 제외한 많은 부분들을 클라우드에 위임할 수 있기 때문에 기술부채를 최소화하면서 확장 가능한 기술을 적용 할 수 있다. 클라우드가 MVP에 적당한 이유는 아래와 같다.
  1. 인프라 선투자 및 미리 준비할 필요가 없다
  2. 트래픽에 따른 자동 확장 및 축소. 처음에는 작게 구축하고 서비스 중분이 발생하고 유저 요청이 늘어남에 따라 인프라를 확장 할 수 있다.
  3. 사용한 만큼 지불.
  4. 고 가용성 및 높은 보안성 제공. 클라우드는 가용성과 보안성을 내장하고 있어서 필요할 때 프러덕트 수준으로 가용성과 보안성을 강화 할 수 있다.
예를 들어 AWS Elastic Beanstalk를 이용하면, 개발환경에서 소프트웨어 업로드 배포까지를 완전히 자동화 할 수 있다. 이렇게 자동화된 환경을 구성하면, MVP 구축후 고객의 피드백을 빠르게 반영할 수 있다. 또한 데이터 수집, 데이터 측정, 분석 및 검증을 위한 서비스들도 제공을 하기 때문에, 사용자의 피드백을 효과적으로 분석 할 수 있다.

참고