검증을 위해 만드는 MVP, 잘못 만들고 있지 않나요?

제대로 된 MVP 만드는 방법을 살피고 린 프로세스를 제품에 적용하기

Feb 11. 2025

MVP, 많이들 들어보셨지 않나요? 아마도 제품의 초기버전을 설명하는데 주로 사용될 텐데요.

그러나 MVP라 하면서 온갖 기능을 개발해야 하는 경우가 많죠. 이는 잘못된 접근입니다. MVP에서 M은 ‘최소’를 뜻하니까요. 지금 만들고 있는 MVP가 명확한 목표도 없고 딱 필요한 것만 개발하고 있다는 생각이 들지 않는다면 용어를 잘못 사용하고 있을 확률이 높습니다.

정확한 용어 사용은 제품 개발에서 상당히 중요합니다. 그렇지 않으면 오해를 사기 때문이죠. MVP라는 용어는 팀원 모두가 비즈니스 문제를 어떻게 제품으로 풀어낼 것인지에 관해 중추적인 역할을 합니다. 따라서 MVP라는 용어를 서로 다르게 이해하고 있다면 팀원 사이에 갈등이 생길 수 있습니다.

많은 사람들은 그저 첫 번째 버전의 제품을 만들고 MVP라고 부릅니다. 그러나 우리는 이런 분위기에 휩쓸리면 안 됩니다.

정말 MVP라고 부르고 싶다면 제품의 최종 형상을 계획하고 만들지 마세요. 한 예로 중요한 이해관계자들과 합의한 30개의 일감이 있다고 칩시다. 이 일감은 모두 이해관계자들의 머릿속 제품 형상을 그대로 구체화한 것에 그치기에 추가적인 발전 여지가 없습니다. (기업 클라이언트가 에이전시에 의뢰할 때 흔히 볼 수 있는 방식이죠.) 이런 제품 개발 방식은 PMF를 찾기보단 개발을 완료하고 출시하는 것이 더 중요합니다. 따라서 처음 30개 일감 중 10개를 개발하고 점진적으로 고도화해 나가는 것이 아니라면 이는 MVP가 아닙니다.

그렇다면 무엇이 MVP를 MVP 답게 할까요? 얼마나 과학적으로 접근했는지가 중요합니다. 제품을 출시하기 전 필수적으로 가설을 수립해야 하며 늘 실험하고 있다는 생각으로 임해야 합니다.

MVP는 반드시 웹사이트나 앱이어야 하는 것은 아니며 가설 검증만 가능하다면 종이에 끄적인 것이나 이메일, 인스타그램 일 수도 있습니다.

다음 질문에 답을 할 수 있다면 MVP입니다.

- 어떤 종류의 문제를 해결하려고 하나요?

- 어떤 가설을 검증하려 하나요?

- 어떤 데이터나 결과를 수집하려고 하나요?

반면 다음에 해당한다면 MVP라고 부르기 어렵습니다.

- 무엇을 구축해야 하는지 이미 결정되어 있고 고도화의 여지가 없음

- 의사 결정은 항상 실무자의 참여 없이 위에서 아래로 이루어짐

- 실패를 받아들이지 않는 문화 속에서 운영됨

- 과정에서 테스트를 진행하거나 학습하지 않고 단순히 구축에만 집중

- 고객이나 데이터 인사이트에 기반한 것이 아니라 개인적인 선호나 믿음에 의해 개발

- 개발 범위가 계속 확장되며, 명확한 이유 없는 새로운 기능 추가

- 애자일 혹은 린의 탈을 쓴, 여러 단계로 나뉜 워터폴 프로세스

- 가설 없이 짧은 기간 내에 구현할 수 있는 모든 것을 개발

제품 개발 프로세스를 개선하기 위해 우리는 뭘 해야 할까요?

1. 올바른 용어 사용

린 스타트업 방법론이 모든 상황에 적합한 것은 아닙니다. 어떨 때는 확실한 요구사항에 기반한 완결적인 기능개발이 필요할 수 있습니다. 이때는 MVP라는 용어대신 ‘알파 버전’, ‘PoC’, 파일럿’ 또는 단순히 ‘v1’이 될 수도 있습니다. 프로젝트를 정확히 정의하고 전달되도록 노력해 보세요.

2. 질문하기

무엇을 개발하는지 확실하지 않다면, 질문하세요. 왜 우리는 이 제품을 개발하고 있는지? 누가 이로부터 혜택을 받을지? 이 제품을 출시함으로써 어떤 목표를 달성하려고 하는지? 유효한 이유 없이 기능을 더 추가하는 것은 왜인지? 문제의 핵심 가치와 실제 문제의 원인을 찾을 때까지 계속해서 질문하세요.

이러한 질문을 통해 제품 비전, 비즈니스 결과, 그리고 고객을 탐색하게 되며 더 많은 실험 활동을 진행하게 됩니다. 가장 중요한 것은 이러한 질문들이 나의 작업에 의미를 부여한다는 것입니다. 그 가치를 진정으로 믿는다면 진행하는 프로젝트를 만들며 기쁨을 느낄 수 있을 것입니다.