MVP 만들기 전에 꼭 하는 문제 검증 체크리스트 8가지

“일단 만들어보고 반응 보면 되지 않을까요?”

저는 이 말을 정말 자주 듣습니다.

그런데 솔직히, MVP 검증에서 제일 많이 망가지는 지점은 ‘만든 다음’이 아니라 ‘만들기 전’입니다.

기능이 부족해서 실패하는 경우도 있지만, 그보다 더 자주 보는 건 애초에 풀 문제가 흐릿했던 경우예요.

그래서 저는 MVP를 설계하기 전에 먼저 봅니다.
이 아이디어가 멋져 보이는지보다, 문제 검증이 됐는지를요.

오늘은 제가 실무에서 거의 습관처럼 확인하는 체크리스트 8가지를 정리해보겠습니다.
창업 초기에 하는 스타트업 아이디어 검증은 거창한 리서치가 아니라, 틀린 가정을 빨리 버리는 작업에 가깝습니다.

1. 이 문제가 정말 자주 발생하나요

가장 먼저 보는 건 빈도입니다.

문제가 아무리 불편해도 1년에 한 번 생기면, 사람은 대체로 참습니다.
반대로 매주, 매일, 심지어 하루에도 여러 번 생기면 얘기가 달라집니다.

예를 들어 누군가 “회의록 정리 너무 힘들어요”라고 말합니다.

여기서 끝내면 안 됩니다.
저는 꼭 묻습니다. 마지막으로 그 문제를 언제 겪었는지, 지난 2주 동안 몇 번 있었는지, 그때 어떻게 처리했는지를요.

미래의 의견보다 과거의 행동이 훨씬 정확합니다.
Rob Fitzpatrick의 The Mom Test가 말하는 핵심도 비슷합니다. 아이디어에 대한 칭찬을 듣지 말고, 실제 삶에서 반복된 행동을 보라는 거죠.

문제가 자주 생기지 않으면, 제품은 기억에서 먼저 밀립니다.
이건 생각보다 치명적입니다.

2. 사람들은 이미 자기 방식으로 해결하고 있나요

이건 제가 아주 중요하게 보는 신호입니다.

아무 대안이 없는 시장이 좋아 보일 때가 있는데, 초기에는 오히려 위험할 수 있습니다.
왜냐하면 대안이 없다는 건 문제가 작아서 아무도 굳이 해결하지 않는다는 뜻일 수도 있거든요.

좋은 문제는 보통 이미 ‘엉성한 대안’이 있습니다.

엑셀로 버티고 있거나, 카카오톡 단체방으로 굴리고 있거나, 담당자가 밤마다 수작업으로 붙잡고 있거나요.
불편하지만 어쨌든 해결은 하고 있는 상태 말입니다.

저는 이런 장면을 좋아합니다.
예를 들어 운영팀 한 명이 금요일 저녁 7시에 엑셀 필터를 세 번 바꾸고, 누락된 항목을 슬랙으로 다시 확인하고, 마지막엔 복붙하다가 서식 깨져서 한숨 쉬는 장면이요. 이런 건 진짜 문제일 가능성이 높습니다.

사람은 말보다 행동으로 예산과 시간을 씁니다.
이미 우회해서라도 해결 중이면, 거기엔 수요가 있습니다.

3. 불편한 문제인가요, 급한 문제인가요

여기서 많이 갈립니다.

불편함은 공감을 부르고, 급함은 결제를 부릅니다.

Michael Seibel은 MVP를 완성품이 아니라 학습 도구로 봐야 한다고 말합니다.
저도 이 관점에 동의합니다. 그런데 학습이 되려면, 사용자가 조악한 첫 버전에도 반응해야 하잖아요.

그 반응은 대개 “좋아 보이네요”에서 나오지 않습니다.
지금 해결해야 하는 압박에서 나옵니다.

그래서 저는 이렇게 나눠 봅니다.

“있으면 편한가?”보다 “없으면 오늘 일이 막히는가?”
“좋아 보이는가?”보다 “미루기 어려운가?”

상식을 조금만 비틀어보면, 초기 제품은 ‘만족’을 주는 것보다 ‘중단을 막는 것’이 더 중요합니다.
사람들이 사랑하는 제품보다, 당장 안 쓰면 곤란한 제품이 먼저 살아남는 경우를 저는 훨씬 많이 봤습니다.

4. 누가 가장 아픈지 한 문장으로 말할 수 있나요

“중소기업을 위한 협업툴” 같은 표현은 너무 넓습니다.
이렇게 시작하면 인터뷰는 많이 했는데, 배운 건 적은 상태가 되기 쉽습니다.

저는 오히려 더 좁히라고 말합니다.

예를 들면 이런 식입니다.
“채용 공고를 월 10건 이상 올리고, 지원자 정리와 면접 일정 조율을 한 사람이 동시에 맡는 20~80명 규모 스타트업의 HR 담당자”

길죠.
그런데 이 정도는 되어야 고객이 보입니다.

a16z에서 자주 이야기하는 초기 고객 정의도 결국 비슷한 방향입니다.
모두를 위한 제품은, 초기에 아무도 절실하게 원하지 않는 제품이 되기 쉽습니다.

누가 가장 아픈지 선명해지면 좋은 점이 두 가지 있습니다.
인터뷰 질문이 날카로워지고, 나중에 MVP 검증 기준도 훨씬 명확해집니다.

5. 고객은 돈이나 시간을 이미 쓰고 있나요

저는 지불 의향을 따로 떼어 보지 않습니다.
대개는 이미 쓰고 있는 돈과 시간 속에 숨어 있으니까요.

예를 들어 “이거 필요해요”라는 말보다 더 강한 신호는 이런 겁니다.

• 외주로 부분 해결 중이다
• 사람을 더 뽑아 메우고 있다
• 비싼 기존 솔루션을 억지로 쓰고 있다
• 팀장이 직접 야근으로 메우고 있다

이건 사실상 비용입니다.
현금만 비용이 아니거든요. 반복되는 수작업, 누락 리스크, 담당자 피로도도 다 비용입니다.

YC의 Kevin Hale 쪽 조언을 보면, 창업자들이 가격을 너무 낮게 잡는 경우가 많다고 합니다.
제 해석은 이렇습니다. 문제의 비용을 제대로 못 봤기 때문에, 솔루션의 가치도 작게 보는 겁니다.

사람들이 이미 어떤 형태로든 대가를 치르고 있다면, 그 문제는 꽤 진지합니다.
반대로 아무것도 안 쓰고 있다면, 시장이 아니라 무관심일 수도 있습니다. (이건 진짜 자주 헷갈립니다)

6. 인터뷰에서 칭찬 말고 증거를 얻고 있나요

초기 인터뷰가 위험한 이유는, 사람들이 대체로 친절하기 때문입니다.

“좋네요.”
“저 같아도 쓸 것 같아요.”
“나오면 알려주세요.”

이 말들은 기분은 좋지만, 데이터로는 약합니다.

저는 인터뷰 메모를 볼 때 칭찬 문장보다 행동 문장을 표시합니다.
마지막으로 언제 겪었는지, 그때 누구에게 보고했는지, 엑셀 파일 이름이 뭔지, 해결하는 데 몇 분이 들었는지 같은 것들이요.

디테일이 나올수록 진짜입니다.
반대로 표현이 추상적일수록, 아직 고통이 생활 속에 박혀 있지 않을 가능성이 큽니다.

좋은 인터뷰는 상대가 내 아이디어를 평가하는 자리가 아닙니다.
상대의 일상을 복원하는 자리에 가깝습니다.

7. 스케일 안 되는 방식으로라도 첫 고객을 만날 수 있나요

조금 역설적이지만, 초기엔 안 scalable한 방식이 오히려 맞습니다.

Paul Graham이 말한 “스케일 안 되는 일을 하라”는 조언이 저는 여기서 특히 유효하다고 봅니다.

문제 검증 단계에서 광고 자동화, 퍼널 최적화, 대규모 유입 같은 걸 먼저 고민하면 너무 빨리 멀어집니다.
지금 필요한 건 1,000명이 아니라 첫 10명입니다.

제가 보고 싶은 건 이런 장면입니다.
창업자가 직접 메시지를 보내고, 줌으로 30분 이야기하고, 필요하면 노션이나 스프레드시트로 수동 처리해주고, 그 과정에서 고객의 표현을 그대로 받아 적는 것.

이 과정을 귀찮아하면 안 됩니다.
왜냐하면 초기의 제품 통찰은 대개 자동화된 대시보드가 아니라, 이런 지저분한 접점에서 나오거든요.

재밌는 건, 많은 팀이 “이건 너무 수동적이라 제품 같지 않다”고 말하는 순간 오히려 배움을 놓칩니다.
초기 MVP는 종종 소프트웨어가 아니라 서비스 흉내를 낸 학습 장치에 더 가깝습니다.

8. 만들기 전에 이미 ‘작은 약속’을 받고 있나요

저는 최종적으로 이것을 봅니다.

사람들이 말이 아니라 작은 행동으로 약속하는지요.

예를 들면 이런 것들입니다.

• 다음 인터뷰 일정을 먼저 잡는다
• 팀 동료를 소개해준다
• 베타 테스트 대기 명단에 자발적으로 들어온다
• 파일, 샘플 데이터, 기존 업무 흐름을 보여준다
• 유료라도 검토하겠다고 구체 조건을 말한다

이건 꽤 강한 신호입니다.
사람은 관심 없는 제품에 자기 평판, 데이터, 시간을 잘 얹지 않습니다.

Rahul Vohra의 PMF 설문은 제품이 나온 뒤에 많이 쓰이지만, 그 전 단계에서도 힌트를 줍니다.
정말 아쉬워할 사람을 찾는 게 핵심이라는 점이요. 모두가 조금 좋아하는 제품보다, 일부가 크게 아쉬워하는 문제를 잡는 편이 훨씬 낫습니다.

그래서 저는 MVP를 만들기 전에 묻습니다.
“이 사람들이 정말 기다리고 있나?”
좋은 답은 칭찬이 아니라 선행 행동으로 옵니다.

문제 검증이 끝나면, 그때 MVP를 줄입니다

많은 분들이 MVP를 기능 축소라고 생각합니다.
저는 조금 다르게 봅니다.

MVP는 기능을 줄이는 작업이 아니라, 가장 위험한 가정 하나를 고르는 작업입니다.

문제가 진짜인지, 누가 가장 아픈지, 지금도 대가를 치르고 있는지, 첫 고객을 직접 만날 수 있는지.
이 네 가지가 흐리면 기능을 아무리 잘 잘라도 검증이 안 됩니다.

반대로 이 부분이 선명하면 첫 버전은 놀랄 만큼 작아도 됩니다.
랜딩페이지일 수도 있고, 수동 컨시어지일 수도 있고, 노코드 폼 하나일 수도 있어요. (이유는 간단합니다. 지금 필요한 건 제품 완성도가 아니라 학습 속도니까요.)

저는 창업 초기에 가장 아까운 낭비가 개발비라고 생각하지 않습니다.
잘못된 문제를 몇 달 동안 사랑해버리는 시간이 더 비쌉니다.

그래서 만들기 전에 먼저 확인합니다.
이 문제는 진짜인가, 지금인가, 누구에게인가.

그 답이 또렷해지면, MVP는 훨씬 쉽게 작아집니다.

혹시 지금 아이디어를 붙잡고 계신다면, 기능 목록부터 열지 마시고 이 8가지를 먼저 보시면 좋겠습니다.
그 다음에 만드는 MVP는 훨씬 덜 화려할 수 있어요. 대신 훨씬 덜 틀릴 겁니다.

참고한 문헌 링크

• Complete MVP Checklist for Startups & Tech Founders 2025
• Validate a Startup Idea Before Building an MVP
• 25 Proven Ways to Validate Your Startup Idea Before You Build
• The Ultimate Guide to MVP Development for Startups in 2025
• The Ultimate Startup Guide With Statistics (2024–2025)
• 아이디어 검증에 필수 MVP 테스트 제작 방법과 성공사례 모음
• 완벽 체크리스트: 개발자 없이 아이디어에서 MVP까지 (2025년판)