MVP라는 단어에 속지 마세요

MVP(Minimum Viable Product). 최소한의 기능으로 시장 반응을 확인하자는 개념입니다. 스타트업 업계에서 거의 교과서처럼 쓰이는 단어인데, 현실에서는 이 단어 때문에 돈을 버리는 경우가 더 많습니다.

저희가 수년간 상담하면서 본 MVP 실패 패턴은 크게 두 가지입니다.

실패 패턴 1: 기능 20개짜리 MVP

"MVP로 만들고 싶어요"라고 하시는 분들의 기능 목록을 받아보면 20개가 넘는 경우가 많습니다. 회원 관리, 결제, 알림, 관리자 페이지, 통계 대시보드, 소셜 로그인, 채팅까지. 이건 MVP가 아니라 완성된 서비스입니다.

이런 경우 대부분 예산은 MVP 수준인데 기대는 완성품 수준입니다. 제대로 된 개발사라면 "이 예산으로 이 기능을 다 만들 수는 없습니다"라고 말합니다. 문제는 그냥 받아서 대충 만드는 개발사입니다. 기능은 다 들어가 있는데 하나도 제대로 동작하지 않는, MVP라는 이름의 아무도 쓰지 않는 서비스가 나옵니다.

MVP는 기능이 적은 게 아닙니다. 검증하려는 가설이 명확한 겁니다. "이 서비스에 수요가 있는가?"를 확인하는 데 기능 20개가 필요하진 않습니다.

실패 패턴 2: 개발사가 핵심까지 잘라버리는 MVP

이쪽이 더 위험합니다.

"이건 MVP니까 이 기능은 빼죠" — 이 말 자체는 맞을 수 있습니다. 문제는 핵심 기능까지 잘라버리는 경우입니다. 결제가 핵심인 서비스에서 결제를 빼고, 검색이 핵심인 서비스에서 검색을 빼놓고 "나중에 추가하면 됩니다"라고 합니다. 나중에 추가하려면 구조를 다시 짜야 하는 경우가 대부분인데, 그 이야기는 안 합니다.

전형적인 패턴이 있습니다:

• 상담 때 "MVP로 빠르게 시작하시죠"라며 작은 견적을 제시합니다
• 개발에 들어가면 기능을 하나씩 "다음 버전에 하죠"로 미룹니다
• 결과물이 나왔는데 실사용자에게 보여줄 수 있는 수준이 아닙니다
• "본개발은 별도 견적입니다" — 결국 처음부터 다시 만드는 비용이 발생합니다

기능을 빼는 이유가 서비스를 위한 것인지, 개발사의 공수를 줄이기 위한 것인지 구분해야 합니다. 근거 없이 "MVP니까요"만 반복하면 그건 조언이 아니라 공수 줄이기입니다.

나쁜 MVP를 구분하는 3가지 질문

개발사가 기능을 빼자고 할 때 이렇게 물어보세요.

1. "이 기능을 빼면 사용자가 이 서비스를 쓸 이유가 남나요?"

핵심 가치를 전달할 수 없는 MVP는 MVP가 아닙니다. 배달 앱에서 주문 기능을 빼면 아무 의미 없듯이, 서비스의 존재 이유가 되는 기능은 빠지면 안 됩니다.

2. "빼는 기능을 나중에 추가할 때, 지금 구조를 다시 뜯어야 하나요?"

완벽하게 설계해 놓는 건 불가능합니다. 실제로 개발에 들어가기 전에 모든 경우를 예측할 수는 없고, 나중에 기능을 추가하면 공수가 드는 건 마찬가지입니다. 다만 그걸 어느 정도 염두에 두고 만드는 것과, 아예 고려 없이 만드는 것은 차이가 큽니다.

3. "이 MVP로 정확히 뭘 검증할 수 있나요?"

이 질문에 한 문장으로 답할 수 없다면, 개발사도 클라이언트도 MVP의 목적을 모르는 겁니다. 목적 없는 MVP는 그냥 미완성 제품입니다.

그렇다면 MVP 전에 뭘 할 수 있을까

사실 시장 검증에 코드가 필요 없는 경우가 많습니다.

랜딩 페이지 + 사전 등록: 서비스 설명 페이지 하나와 이메일 수집 폼만으로 수요를 확인할 수 있습니다. 등록자가 모이면 수요가 있는 거고, 안 모이면 방향을 바꿔야 하는 겁니다. 개발비 0원입니다.

스몰 인터뷰: 가장 과소평가되지만 가장 효과적인 방법입니다. 예를 들어 미용 관련 서비스를 구상 중이라면, 이해관계 없는 미용실에 매일 다른 곳으로 드라이라도 하러 가면서 원장님이나 디자이너에게 물어보세요. "이런 서비스가 있으면 쓰실 것 같으세요?" 가 아니라 "지금 이런 불편함이 있으세요?", "이런 상황에서 어떻게 하세요?"를 물어야 합니다. 5~10명만 만나봐도 내 가설이 맞는지 틀리는지 감이 옵니다. 비용은 드라이 값뿐입니다.

Figma 프로토타입: 클릭 가능한 화면 목업을 만들어서 실사용자에게 보여주세요. 1~2주면 만들 수 있고, "이런 서비스 쓸 것 같나요?"가 아니라 "지금 바로 결제하시겠습니까?"를 물어야 진짜 수요를 알 수 있습니다.

수동 운영: 시스템을 만들기 전에 사람이 직접 서비스를 운영해 보는 방법입니다. 예약 시스템을 만들기 전에 카톡으로 예약을 받아보면, 진짜 필요한 기능이 무엇인지 명확해집니다.

저희의 방식

저희는 MVP 상담이 들어오면 클라이언트와 함께 이 서비스의 핵심 기능이 무엇인지 파악하는 데 가장 많은 시간을 씁니다. 클라이언트가 구상한 서비스를 듣고, 이 제품이 MVP 단계에서 실제로 사용자가 쓸 수 있으려면 어느 수준까지 만들어야 하는지 분석하고 제안합니다.

저희는 쓰지도 못할 MVP를 만드는 걸 권하지 않습니다. 이 제품으로 클라이언트가 실제로 시장에서 검증할 수 있어야 의미가 있다고 생각합니다.

그리고 솔직하게 말씀드립니다. 예산이 맞지 않으면 "이 예산으로는 제대로 된 결과물을 만들기 어렵습니다"라고 합니다. 억지로 맞추면 양쪽 다 불행해진다는 걸 경험으로 알고 있기 때문입니다.

MVP든 본개발이든, 결국 중요한 건 하나입니다. 이 서비스가 실제로 사용자에게 가치를 전달할 수 있느냐. MVP라는 단어에 끌려다니지 마시고, 내 서비스의 핵심이 무엇인지부터 정리하세요. 그게 돈을 아끼는 가장 확실한 방법입니다.