요즘 기획 직군에서 MVP라는 단어는 마치 공기처럼 자연스럽게 떠돌고 있습니다. 스타트업 피치덱에도, 사내 기획 리뷰에도, 취업을 준비하는 사람들의 포트폴리오에도 어김없이 등장합니다. 그런데 이상하게도, MVP를 입에 달고 사는 팀일수록 첫 번째 출시가 예상보다 훨씬 늦어지는 경우를 자주 봅니다. 도대체 왜 그럴까요?
MVP에 대한 가장 흔한 오해는 "원래 기획했던 기능 목록에서 몇 가지를 쳐내면 된다"는 생각입니다. 기획서에 빼곡히 적힌 20가지 기능 중 12가지를 지우고 8가지만 남기면 MVP가 완성됐다고 믿는 것이죠. 하지만 이 방식에는 치명적인 결함이 있습니다. 기능의 개수를 줄인 것이지, 서비스가 전제하고 있는 가정의 수를 줄인 게 아니기 때문입니다.
기능 8개짜리 서비스도 충분히 크고 복잡할 수 있습니다. 그 안에는 여전히 "유저가 이렇게 행동할 것이다", "이 문제가 충분히 크다", "우리의 해결책이 통할 것이다"라는 수십 개의 검증되지 않은 믿음이 숨어 있습니다. MVP의 V는 Viable, 즉 '이 제품이 시장에서 살아남을 수 있는가'를 묻는 것입니다. 그렇다면 최소화해야 할 것은 기능이 아니라 가설입니다.
앱테크 서비스를 기획한다고 가정해 보겠습니다. "유저는 포인트를 위해 매일 앱을 열 것이다", "미션이 많을수록 체류 시간이 늘어날 것이다"처럼 기획자는 자연스럽게 여러 가설을 동시에 품게 됩니다. 이것들을 한꺼번에 검증하려다 보면 출석 체크, 단계별 미션, 레벨 시스템을 동시에 만들어야 하고, 개발 일정은 늘어나고 화면은 복잡해집니다.
빗썸에서 혜택존을 기획할 때도 처음엔 수많은 앱테크 요소를 한꺼번에 쏟아내려 했습니다. 결과는 참담한 이탈이었습니다. 유저들은 혜택의 크기를 계산하기도 전에, 눈앞에 펼쳐진 미션들이 피곤한 숙제처럼 느껴져 도망친 것이었습니다. 진입 시점에 가장 허들이 낮은 미션 단 하나만 남기는 방향으로 구조를 뒤집자, 그제야 자발적인 참여가 의미 있게 올라오기 시작했습니다. 검증되지 않은 가설 위에 공들여 쌓은 기능들은, 가설이 틀렸을 때 함께 무너진다는 것을 그때 체감했습니다.
MVP를 작게 만드는 이유는 빠르게 성공하기 위해서가 아닙니다. 빠르게 틀리기 위해서입니다. 6개월을 쏟아 만든 제품이 시장에서 외면받는 것보다, 2주 만에 만든 프로토타입이 외면받는 쪽이 훨씬 낫습니다. 전자는 팀의 사기와 리소스를 함께 앗아가지만, 후자는 소중한 인사이트만 남겨줍니다.
이 관점에서 보면 MVP는 제품이 아니라 실험에 가깝습니다. 실험의 목적은 정답을 증명하는 것이 아니라, 오답을 빠르게 걸러내는 것입니다. 깔끔한 UI보다 날카로운 질문이 먼저입니다. 코드잇에서 부트캠프 커리큘럼을 기획할 때도, 기능을 만들기 전에 경쟁사 데이터를 크롤링하고 시각화해서 우리가 전제한 차별화 가설이 유효한지를 먼저 확인하는 과정을 거쳤습니다. 기능보다 가설이 먼저라는 순서 하나가 이후 방향 설정의 속도를 결정했습니다.
기능 목록을 앞에 두고 무엇을 뺄지 고민하기 전에, 먼저 이 질문을 스스로에게 던져보시길 권합니다. "이 서비스가 전제하고 있는 가설은 무엇인가? 그 중에서 지금 가장 불확실한 가설은 무엇인가? 그리고 그것을 확인하기 위한 최소한의 실험은 무엇인가." 이 세 가지 질문에 명확하게 답할 수 있을 때, 비로소 제대로 된 MVP를 설계하고 있다고 말할 수 있습니다.
기능을 빼는 것은 개발 리소스를 아끼기 위한 타협이 아닙니다. 가장 중요한 질문에 가장 빠르게 답을 얻기 위한 전략적 선택입니다. 기능을 빼는 것은 기술이고, 가설을 줄이는 것은 기획자의 본능입니다.