MVP · 최소기능제품
Minimum Viable Product
MVP이란?
- 핵심 가설 검증용 최소 실험으로서의 제품
- 랜딩페이지·수작업 서비스도 훌륭한 MVP
- 기준은 '적지만, 그 하나는 확실히'
MVP를 도입하면 회의실에서 오가는 질문이 바뀝니다. '이 기능까지 넣어야 팔리지 않겠느냐'가 아니라 '이 사업이 망한다면 어떤 가정이 틀렸기 때문일까'를 먼저 묻고, 그 가정 하나에만 예산과 일정을 붙이게 됩니다. 그래서 MVP를 제대로 쓰는 조직은 기획서의 단위가 기능 목록에서 가설 목록으로 바뀝니다. 보고의 성적표도 '일정대로 개발했는가'가 아니라 '얼마를 쓰고 무엇을 확실히 알게 됐는가'로 옮겨 갑니다.
실무에서 쓰는 형태는 대체로 네 갈래입니다. 제품 없이 소개 페이지만 열어 사전 신청률을 보는 랜딩페이지형, 담당자가 직접 손으로 서비스를 제공하는 컨시어지형, 겉은 자동화처럼 보이되 뒤에서 사람이 처리하는 오즈의 마법사형, 핵심 기능 하나만 남기는 단일기능형입니다. 인접 개념과의 경계도 분명합니다. PoC는 '기술적으로 되는가', 프로토타입은 '쓰기에 편한가', 파일럿은 '만든 것을 일부 현장에 적용하면 돌아가는가'를 묻지만 MVP가 묻는 것은 '돈을 낼 사람이 있는가'입니다. 그래서 실험을 시작하기 전에 합격선을 숫자로 못 박는 일이 설계의 절반입니다. '제안 20곳 중 유료 전환 3곳, 4주 안에'처럼 미달 시 접는 기준까지 적어야 실험이 성립합니다.
가장 흔한 오해는 MVP를 '싸게 빨리 만든 정식 출시'로 이해하는 것입니다. 기능은 반쪽인데 보도자료를 내고 영업팀이 기존 거래처에 정식 제품처럼 들고 가면, 검증은커녕 십수 년 쌓은 거래 신뢰가 먼저 깎입니다. B2B일수록 실험 대상을 소수의 우호 고객으로 한정하고 테스트 버전임을 명시해야 하는 이유입니다. 반대편 함정은 검증의 자기기만입니다. 친분 있는 담당자에게 '좋은데요, 나오면 쓸게요'를 듣고 수요가 확인됐다고 보고하는 경우인데, 결제나 계약서 서명이 없는 호의는 데이터가 아닙니다. 마지막은 조직의 문제로, 실패로 끝난 실험을 인사평가에서 감점 처리하면 담당자는 결과가 뻔한 가설만 골라 '성공한 MVP'를 연출하고 실험은 요식행위로 끝납니다.
2001년 프랭크 로빈슨이 처음 쓴 용어를 스티브 블랭크의 고객 개발 방법론을 거쳐 에릭 리스가 2011년 저서 『린 스타트업』에서 '만들기-측정-학습' 루프의 핵심 도구로 정식화하며 세계적으로 확산됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 320명, 연매출 780억 원 규모의 산업용 부품 제조사 A사가 '설비 고장 예지보전 구독 서비스'를 신사업으로 추진하던 상황입니다. 플랫폼 개발과 센서 구축에 6억 원, 기간 14개월짜리 품의가 경영회의 결재 직전까지 올라갔습니다. 그런데 정작 '어느 공장이 얼마를 낼 것인가'에 대한 답은 자료 어디에도 없었습니다.
- 신사업팀장은 결재 직전 회의에서 '센서 다는 건 우리도 합니다. 문제는 정비 예산을 쥔 공장장이 월 구독료를 결재해 주느냐'라며 개발 착수를 3개월만 미루자고 제안했습니다.
- 팀은 '제안한 20개 공장 중 3곳 이상이 월 150만 원에 유료 계약'을 합격선으로 걸고, 미달이면 사업을 접겠다는 조건까지 품의서에 적어 임원 승인을 받았습니다.
- 개발은 한 줄도 하지 않고, 고객사에서 받은 진동·전류 데이터를 생산기술 엔지니어 2명이 주 1회 엑셀로 분석해 PDF 리포트로 보내는 컨시어지형 MVP를 4주간 8개 공장에 돌렸습니다.
- 8곳 중 5곳의 반응은 '리포트 내용은 우리 정비반장이 이미 아는 것'이었고, 나머지 3곳은 '고장 시점보다 교체 부품 발주 리드타임을 알려 달라'며 전혀 다른 문제를 꺼냈습니다.
- 팀장은 예지보전 가설을 접고 '부품 수급 예측'으로 방향을 틀어 2주 만에 두 번째 리포트를 돌렸고, 이번에는 제안한 6곳 중 4곳이 월 90만 원 계약서에 서명했습니다.
- 6억 원 개발 예산은 집행되지 않았고 3개월 실험에 쓴 비용은 인건비 포함 2,400만 원이었습니다. A사는 검증된 수요를 근거로 1억 8,000만 원짜리 축소 개발에 착수해 연 4,320만 원 구독 매출로 출발했습니다.