MVP란 무엇인가요? 최소 기능 제품으로 무엇을 검증하나요?

MVP는 무엇을 말하나요?

MVP는 Minimum Viable Product, 우리말로 최소 기능 제품입니다. 이 개념을 정리한 에릭 리스는 MVP를 "가장 적은 노력으로 고객에 대한 검증된 학습을 최대한 모을 수 있게 해 주는 새 제품의 버전"으로 정의했습니다. 무게가 '작다'가 아니라 '배운다'에 걸려 있습니다.

그래서 MVP는 완성품의 축소판이 아니라, 아직 확인되지 않은 가정을 실제 사용자에게 물어보기 위한 장치입니다. 만들기 전에 정해야 하는 것도 기능 목록이 아니라 "지금 우리가 모르고 있는 것이 무엇인가"입니다.

어떤 상황에서 쓰는 말인가요?

수요, 가격, 사용자의 행동 가운데 하나라도 확인되지 않은 신규 서비스에 쓰는 말입니다. 이미 수요가 분명하고 만들 범위가 확정된 사내 시스템 개편에는 이 표현을 붙이지 않아도 됩니다. 리스도 분명한 불편을 긁어 주려는 목적이라면 MVP는 필요하지 않다고 적었습니다. MVP는 배우기 위해 추가 부담을 떠안는 방식이기 때문입니다.

반대로 "사용자가 이 과정을 거치고 돈을 낼까"가 걸려 있다면 MVP가 맞습니다. 이때는 개발 기간만이 아니라 고객과 이야기하고 지표를 확인하는 시간까지 일정에 들어갑니다. 개발사에 일정을 물어볼 때도 출시일과 함께 결과를 확인할 기간을 같이 적어 두시는 편이 좋습니다.

꼭 개발부터 해야 하나요?

아닙니다. 확인하려는 질문이 "이런 서비스에 관심을 보일까"에 가깝다면, 광고와 한 장짜리 안내 페이지로 반응을 보는 것만으로도 답이 나올 때가 있습니다. 리스도 아무도 원하지 않은 기능을 2주 동안 만든 일을 돌아보며, 간단한 광고 반응 테스트만으로도 그 구상이 얼마나 나빴는지 훨씬 빨리 알 수 있었을 것이라고 적었습니다.

반대로 "실제로 이 절차대로 일이 돌아가는가"가 질문이라면 서비스 일부를 사람이 손으로 처리하면서 시작할 수 있습니다. 접수는 화면으로 받고 배정은 담당자가 직접 하는 방식이면 개발 범위를 크게 줄이면서도 같은 질문에 답할 수 있습니다. 어떤 방식이든 같은 조건이 붙습니다. 실제 사용자가 쓰고, 그 결과를 숫자로 확인할 수 있어야 합니다.

MVP는 무엇으로 구성되나요?

아래 네 가지가 함께 있어야 MVP로 작동합니다. 하나라도 비면 그냥 작게 만든 제품이 됩니다.

구성	적어 두는 내용	빠지면 생기는 일
검증할 가설	누가 어떤 상황에서 무엇을 해 주기를 기대하는지 한 문장	결과를 해석할 기준이 없어 반응이 애매하다로 끝납니다
핵심 흐름 하나	그 가설을 확인하는 데 꼭 필요한 한 줄기 동작	기능이 늘어 출시가 밀리고 무엇이 효과를 냈는지 가려집니다
측정 지점	흐름의 어디에서 무엇을 세는지(예약 완료, 재방문 등)	사용 여부를 감으로 판단하게 됩니다
다음 판단 기준	어떤 결과면 계속·수정·중단인지 미리 합의	숫자가 나와도 결정이 미뤄집니다

측정 지점은 화면 안에서 끝나는 숫자보다 사업 판단과 이어지는 지점을 고르시기 바랍니다. 방문자 수보다 예약을 마친 사람의 비율이 다음 결정에 쓰입니다.

예를 들어 방문 예약 서비스라면

상담 예약을 전화로만 받던 회사가 온라인 예약을 검토한다고 하겠습니다. 모르는 것은 "사람들이 전화 대신 직접 시간을 골라 예약하고, 그 약속을 지키는가"입니다.

이 경우 MVP는 예약 가능한 시간을 보여 주고 한 건을 접수해 담당자에게 알리는 흐름 하나입니다. 회원 등급, 결제, 리뷰, 통계 화면은 가설과 직접 관계가 없으니 다음 단계로 미룹니다. 2~3주 동안 접수된 예약 중 실제 방문으로 이어진 비율을 보면 다음 투자를 결정할 근거가 생깁니다. 예약 화면을 더 보기 좋게 만드는 작업은 이 질문에 답해 주지 않습니다.

자주 보이는 오해

첫째는 MVP를 기간이나 크기로 정하는 것입니다. 리스는 정의에 최대와 최소가 함께 들어 있어 공식처럼 쓸 수 없고 상황마다 판단이 필요하다고 했습니다. 그가 만든 IMVU의 첫 MVP는 시장에 내놓기까지 6개월이 걸렸고, 반대로 아무도 원하지 않은 기능에 쓴 2주는 너무 길었다고 적었습니다. 4주가 정답인 것도, 6개월이 실패인 것도 아닙니다.

둘째는 기능을 덜 넣는 대신 품질을 낮춰도 된다고 보는 것입니다. 사용자가 실제로 쓰는 흐름이라면 로그인이 끊기거나 접수가 누락되는 수준에서는 반응을 측정할 수 없습니다. 줄이는 대상은 기능의 개수이고, 선택한 하나의 흐름은 끝까지 동작해야 합니다.

셋째는 내부 시연용 화면을 MVP라고 부르는 것입니다. 실제 사용자에게 제공되고 그 반응을 측정한다는 점이 MVP의 조건입니다. 목적과 사용자가 다른 PoC, 프로토타입과는 구분해서 쓰시는 편이 개발사와의 대화에서 혼선을 줄입니다.

지금 확인할 한 가지

기능 목록을 열기 전에 "이번에 확인할 것은 ○○이고, ○○를 보면 알 수 있다"는 문장을 한 줄 적어 보시기 바랍니다. 이 문장이 비어 있으면 범위를 줄여도 결과를 해석할 수 없습니다. 문장이 채워졌다면 다음은 그 흐름의 비용과 기간을 바꾸는 조건을 확인하는 차례입니다.

가설과 핵심 흐름을 정리하는 단계부터 함께 보고 싶으시면, 지금의 업무 흐름과 확인하고 싶은 질문을 정리해 네오렉트에 보내 주시면 됩니다.