MVP(최소 기능 제품)이란

성장하는 기획자가 되기 위해 매일 아침 팀원들과 아티클을 읽고 토론하는 '아티클 카타' 시간을 갖고 있다... 라고 새삼 적어본다!

오늘은 서비스 기획의 핵심이자 가장 많은 오해가 발생하는 개념인 MVP(Minimum Viable Product, 최소 기능 제품)에 대해 심도 있게 다루었다. 아티클을 통해 배운 내용과, 그 지식을 우리 팀의 관점으로 해석하며 나눈 고민들을 정리해 보았다.

나눈 아티클:

기획자로서 알아야 하는 MVP 개발 방법론 | 요즘IT

MVP 개발 방법론, 어디까지가 MVP인가? ( MVP 뜻, MVP 약자, 핵심요소)

08화 좋은 PM을 위한 MVP 프라이머

MVP 기획과 검증 | 서비스 기획 (PM) | 프라임 커리어

 

19화 MVP는 최적화가 아닌 학습을 위해 존재한다

린 스타트업 방식으로 빠르게 실패하기

 

아티클에서 제시하는 MVP의 정의와 원칙

학습한 아티클들은 공통적으로 MVP가 단순한 '미완성 제품'이 아님을 강조한다. 아티클에서 정의하는 MVP의 핵심은 다음과 같다.

학습을 위한 도구

MVP의 본질은가설을 빠르게 데모로 만들어 실제 사용자의 피드백을 얻고 학습하는 구조를 구축하는 데 있다. 요구사항 정리와 개발, 내부 검수(QA)에 과도한 시간을 쏟기보다는 실제 사용자의 목소리와 데이터를 통해 근거를 찾는 과정이 우선되어야 한다.

최소한(Minimum)과 실행 가능성(Viable)의 균형

'최소한'이란 단순히 기능을 줄이는 것이 아니다. 성공 여부를 확인할 수 있는 가장 빠른 방식을 의미한다. 또한 '실행 가능성'은 기술적 구현(Feasible)을 넘어 사용자가 매력을 느끼는지(Desirable)에 대한 테스트가 포함되어야 한다. 비즈니스 모델(BM) 자체를 검증하고 수정하기 위한 도구로서 MVP가 존재해야 한다는 점이 인상적이다.

가장 위험한 가설부터 테스트하라

제품의 생존을 결정지을 수 있는 가장 핵심적이고 위험한 가정부터 확인해야 한다. 아티클은 드롭박스가 소스 코드 하나 없이 서비스 설명 영상만으로 수만 명의 대기자를 모았고, 에어비앤비가 아파트에 에어 매트리스를 놓는 단순한 실험으로 시작했다는 사례를 소개해줬다. 배달의민족 역시 초기에는 주문이나 결제 기능 없이 지역 전단지를 디지털화하는 기능만으로 수요를 확인했다.

리멤버도 직원들이 일일이 명함 정보를 입력했다고 한다. (아마 '그 작업이 감당할 수 없는 정도가 되었을 때 = 우리 서비스의 니즈가 검증되었을 때 = 진짜로 명함 등록 자동화 기술이 출시되어야 할 때' 로 가정했을 듯.)

MVP에 대한 오개념

MVP에 대한 오개념이 많고, 서로의 이해가 달라 문제가 발생하기도 한다.

내가 읽은 아티클에선 다음 그림을 가지고 설명을 해주었는데, 해연님이 읽으신 아티클에선 이 그림을 비판하고 있어서 좀더 글들을 다각적으로 읽는 데에 도움이 되었다.

많은 곳에서 인용되지만, 이 다이어그램은 MVP의 본질을 왜곡한다.

1. 사용자/마켓의 불일치: 자동차 사용자(20대 이상, 고가 마켓)와 스케이트보드 사용자(10대, 저가 마켓)는 타겟이 완전히 다름
2. 요구사항의 불일치: 킥보드 사용자에게 얻은 피드백(예: 발 브레이크 개선)은 자동차 설계에 반영될 수 없음
3. 피드백의 무의미함: 자전거 사이클리스트에 대한 연구는 면허와 보험이 필수인 자동차 운전자에 대해 아무것도 알려주지 않음
4. 기술/경험 축적의 부재: 자전거 제조 기술이 자동차 제조 기술로 이어지는 기여도는 매우 낮음

올바른 방향: 최종 형태가 자동차라면, MVP 역시 자동차의 핵심 가치를 담은 단순화된 자동차 형태여야 함

다음의 좌측 다이어그램은 우측처럼 세분화하여 개선이 필요:

인사이트

아티클의 내용을 바탕으로 우리 팀원들은 각자의 직무와 경험에 비추어 인사이트를 공유했다.

종호님: MVP는 최적화가 아닌 학습을 위해 존재한다

• IT 업계에서는 창의력이 가장 중요할 것이라 생각했지만, MVP 프로세스를 보며 오히려 현재 놓인 문제점을 정확히 찾는 관찰력이 성공의 핵심임을 깨달음
• '탁상공론을 멈추고 오피스 밖으로 나가라' -> 사용자 소통의 중요성 느낌

미라님 & 유주님:
MVP 개발 방법론, 어디까지가 MVP인가?, 
기획자로서 알아야 하는 MVP 개발 방법론

기획자로서 겪는 '욕심'과 '불안'
미라님은 "이 기능 없이도 제품이 작동하는가?"라는 질문을 통해 필수적이지 않은 기능을 과감히 쳐내는 결단력이 필요함을 크게 느끼심.
유주님은 실패에 대한 두려움 때문에 부가 기능에 집착하게 된다는 대목에서 크게 공감. 진짜 기획자는 "이 서비스가 왜 망할까?"를 먼저 고민하고 그 부분을 정면으로 검증해야 한다는 점을 배웠다고하심

해연님: 좋은 PM을 위한 MVP 프라이머

MVP를 막연히 작은 제품으로만 이해하던 시각에서 벗어나, 그것이 하나의 검증 방식이자 경험의 축적이라는 점을 깨달았다고 하심
(기능, 안정성, 편의성, 디자인이 균형을 이루는 '역삼각형 모델'로 가치를 전달해야 한다는 점)

나: MVP 기획과 검증, 린 스타트업 방식으로 빠르게 실패하기

[아티클 스터디/2개] MVP 출시 과정과 실사례

나는 유수의 대기업들이 초라하게 시작했다는 사실을 새삼 깨달았다. 애플이 창고에서 시작하고 배민이 전단지 수집부터 시작했듯, IT의 MVP도 결국 실행력의 문제라는 생각이 들었다. 그리고 IT에서 MVP라고 불러서 그렇지, 오프라인 기업에서도 MVP는 항상 실행되어 왔다는 것도 느낀 것 같다.

배민의 핵심 기능이 초기엔 중개가 아닌 메뉴판의 디지털화였다는 점은 기획자가 정의하는 핵심 기능이 실제 시장의 니즈와 다를 수 있음을 시사해주었다.

궁금증들

아티클 학습을 통해 기초를 다졌지만, 실제 현장에 적용하기 위해 풀어야 할 숙제들도 명확해졌다. 우리 팀은 다음과 같은 질문들을 던지며 다음 스텝을 고민하고 있다.

실무적 경계의 모호함

실무에서 MVP와 POC(개념 증명)를 구분하는 명확한 기준은 무엇이며, 어느 정도의 사용자 반응이 있어야 다음 단계로 넘어갈 수 있는가?

품질의 하한선

기능은 최소화하더라도 디자인이나 UX가 너무 떨어질 경우, 아이디어가 아닌 '불편함' 때문에 외면받을 위험이 있다. 가설 검증을 방해하지 않는 최소한의 UX 퀄리티를 어떻게 설정할 것인가?

초기 고객에 대한 대우

서비스가 성장한 뒤, MVP 단계에서 기여도가 높았던 초기 고객들이 소외감을 느끼지 않게 관리하는 방법은 무엇인가? (나의 개인적인 경험에서 든 궁금증) 서비스 고도화가 기존 사용자를 밀어내는 결과로 이어지지 않게 하는 전략이 궁금하다.

정리하며

MVP는 "실패를 통해 무엇을 학습할 것인가"를 결정하는 전략적 선택이다. 이번 아티클 카타를 통해 우리 팀은 무거운 기획을 내려놓고 가설과 실행력을 기반으로 움직이는 법을 배웠다! 결국 '어떻게 실패할 것인지', '무엇을 실패할 것인지', '실패를 무엇으로 가정할 것인지' 가 중요하고, 그것이 '가설'인 것 같다. 같은 내용을 배우고 배워도 매일 이해도가 달라지는 것 같아서 신기함!

진행할 MVP 프로젝트에서도 "지금 우리가 검증하려는 단 하나의 가설은 무엇인가?"라는 질문을 끊임없이 던지려 한다. 매일 이렇게 기록하고 토론하며 쌓아가는 시간이 결국 단단한 프로덕트를 만드는 밑거름이 될 것이라 확신한다. (역기획 다듬을 때도 해보자. 사실 개인 과제에서도 느낀 지점)

다음 스텝으로, 우리 팀이 설정한 핵심 가설을 검증하기 위한 구체적인 지표(Metric) 설정법에 대해 더 조사해볼까 함.