#MVP#스타트업창업#제품기획#린스타트업#B2B SaaS

MVP를 만들기 전에 먼저 써야 하는 것

초기 스타트업의 MVP는 기능 묶음이 아니라, 고객과 다음 대화를 이어가게 만드는 학습용 문서에 더 가깝습니다

Draftie·2026년 5월 4일

MVP를 이야기하면 거의 자동으로 기능 목록이 따라옵니다. 로그인은 넣을지, 결제는 붙일지, 대시보드는 어느 수준까지 만들지 같은 얘기죠.

그런데 저는 초기에 더 자주 틀리는 지점이 기능 수가 아니라 질문의 부재라고 봅니다. 무엇을 확인하려는지 안 적은 채 제품부터 만들면, 그 MVP는 제품이 아니라 그냥 작은 완성품이 됩니다.

보통 MVP를 최소 기능 제품으로 번역하면서 오해가 시작됩니다. 저는 오히려 다음 대화를 여는 문서라고 생각합니다. 누구와, 어떤 가설을 들고, 무엇을 확인한 뒤, 어떤 질문으로 다시 돌아올지 적어둔 문서 말입니다.

(이 표현이 좀 낯설 수 있는데, 실제로 초기 팀들 미팅을 보면 코드보다 메모가 더 많은 날이 있습니다. 이상하게 그날이 제일 많이 배웁니다.)

MVP가 왜 자꾸 기능표가 되어버릴까요

한 번 이렇게 물어보면 금방 드러납니다. 지금 만들려는 MVP에서 실패하면, 무엇이 틀렸다는 뜻인가요?

이 질문에 바로 답이 안 나오면 대개 기능부터 쌓고 있는 겁니다. 반대로 “회계팀장이 이 엑셀 작업을 매주 2시간 이상 하고 있고, 자동화되면 파일 업로드 방식이라도 일단 써볼 것이다”처럼 답이 나오면, 그때부터 MVP는 훨씬 선명해집니다.

여기서 상식이 한 번 뒤집힙니다. 많은 분이 MVP는 제품을 빨리 내놓는 방식이라고 생각합니다. 저는 오히려 무엇을 만들지 늦게 결정하기 위한 장치에 가깝다고 봅니다.

초기에는 만드는 속도보다 버리는 정확도가 더 중요하거든요. 잘못된 문제를 향해 3주 빠르게 달리는 것보다, 올바른 질문으로 3일 멈추는 편이 훨씬 싸게 먹힙니다.

제가 본 실패한 MVP는 대개 이런 순서로 시작됐습니다

예를 들어 4명짜리 B2B SaaS 팀이 있었습니다. 대표는 전직 운영팀장, 개발자 2명, 디자이너 1명. 이 팀은 “중소기업용 계약 관리 툴”을 만들겠다고 7주를 썼습니다.

1주 차에는 와이어프레임, 2주 차에는 권한 체계, 3주 차에는 알림 설정, 4주 차에는 전자서명 연동 검토, 5주 차에는 관리자 페이지, 6주 차에는 대시보드, 7주 차에는 랜딩페이지까지 붙였죠. 보기에는 꽤 그럴듯했습니다.

그런데 막상 12개 회사에 데모를 돌리니 반응이 묘했습니다. 법무팀은 “우리는 이미 로펌이 관리해요”라고 했고, 20인 이하 스타트업은 “계약서보다 채용이 더 급해요”라고 했습니다. 유일하게 오래 얘기한 사람은 직원 80명 규모 제조업체의 경영지원 매니저였는데, 그분은 계약서 보관보다 “갱신일 놓쳐서 벌금 나는 것”을 더 아파했습니다.

이 팀이 처음부터 틀린 건 개발 실력이 아니었습니다. 문제 문장을 너무 넓게 잡은 것이었습니다. 계약 관리라는 말은 맞아 보이지만, 누가 왜 지금 당장 불편한지가 빠져 있었죠.

그 뒤에 이 팀은 제품을 줄였습니다. 대시보드도 뺐고, 권한도 2단계로 줄였고, 전자서명도 미뤘습니다. 대신 “갱신일 30일 전 알림 + 담당자 확인 로그 + 엑셀 업로드 대행”만 남겼습니다.

그러자 3주 안에 9개 인터뷰, 4개 파일럿, 2개 유료 전환이 나왔습니다. 월 39만 원짜리였고, 첫 설정은 대표가 직접 해줬습니다. 스케일은 안 났지만 학습은 엄청 빨랐습니다.

Paul Graham이 초기에 스케일되지 않는 일을 하라고 한 이유도 바로 여기에 있다고 봅니다. 초기에는 자동화보다 학습 속도가 더 중요합니다.

문제 검증에서 MVP가 해야 하는 일은 딱 세 가지입니다

첫째, 누가 아픈지를 좁혀야 합니다.

“중소기업 인사팀”은 너무 넓습니다. 직원 30~100명, 채용 담당자가 따로 없고, 대표 승인 때문에 채용 공고가 자주 늦어지는 회사처럼 적어야 인터뷰도 선명해집니다. a16z가 자주 강조하는 것도 결국 최고 고객의 공통점을 좁히라는 얘기죠.

둘째, 지금 이미 어떻게 버티는지를 알아야 합니다.

Rob Fitzpatrick의 The Mom Test가 좋은 이유가 여기 있습니다. “이거 쓰실 건가요?”를 묻지 말고, “마지막으로 이 문제를 처리한 게 언제였고, 누가, 몇 시간 걸렸나요?”를 물으라는 거예요. 미래에 대한 의견보다 과거 행동이 훨씬 냉정하고, 그만큼 더 정확합니다.

셋째, 다음 대화의 질문을 남겨야 합니다.

MVP를 보여준 뒤 “괜찮네요”가 나오면 사실 별로 얻은 게 없습니다. 대신 “이건 좋은데 우리 팀은 승인자가 둘이라 로그가 남아야 해요” 같은 반응이 나와야 합니다. 그 말이 다음 버전의 우선순위를 정해주거든요.

저는 그래서 MVP 문서에 기능보다 질문을 먼저 적는 편입니다. 예를 들면 이렇게요. “회계팀장은 카드 정산보다 증빙 누락 추적을 더 싫어하는가”, “첫 세팅을 수동으로 해줘도 유료 전환이 되는가”, “엑셀 업로드만으로도 첫 주 사용이 시작되는가.”

이 세 줄이 없으면, 기능이 12개여도 배움은 얕습니다. 반대로 이 세 줄이 선명하면, 제품이 없어도 인터뷰와 수동 운영만으로 꽤 많은 걸 확인할 수 있습니다.

좋은 고객 인터뷰는 제품 설명회가 아닙니다

가끔 인터뷰라고 해놓고 30분 중 20분을 데모에 쓰는 경우가 있습니다. 저는 그럴 때 거의 항상 같은 일이 벌어진다고 봅니다. 상대는 예의를 지키고, 팀은 희망을 얻고, 실제 데이터는 남지 않습니다.

좋은 인터뷰는 더 투박합니다. 지난달 마지막으로 이 문제를 처리한 날짜, 그때 쓴 도구, 결재를 누가 막았는지, 엑셀 파일 이름이 뭔지, 누가 밤 11시에 다시 열었는지 같은 얘기가 나옵니다. 듣다 보면 좀 민망할 정도로 현실적이죠. 그런데 바로 그 디테일에서 돈을 내는 이유가 나옵니다.

(저도 예전엔 인터뷰 전에 화면을 너무 예쁘게 다듬었습니다. 그런데 정작 전환된 건 예쁜 화면이 아니라 “지금은 어떻게 하고 계세요?”라는 지루한 질문이었어요.)

MVP 문서에는 기능표 대신 이런 항목이 들어가야 합니다

문서라고 해서 거창할 필요는 없습니다. 노션 한 페이지여도 충분합니다. 다만 항목은 꽤 구체적이어야 합니다.

고객 정의에는 “누구”만 쓰지 말고, 직무와 회사 규모, 문제 발생 빈도를 적습니다. 예를 들면 “직원 50~200명 회사의 경영지원 매니저, 계약 갱신 누락을 분기마다 1회 이상 겪음” 정도는 나와야 합니다.

가장 위험한 가정도 한 줄로 적어야 합니다. YC의 Michael Seibel이 말해온 방향도 비슷합니다. MVP는 가장 위험한 가정을 테스트하는 최소한의 것이어야 한다는 거죠. 원하는가, 지금 불편한가, 돈 낼까 중 무엇이 가장 불확실한지 먼저 써야 합니다.

관찰할 행동은 더 중요합니다. “좋아 보인다”가 아니라 “인터뷰 후 48시간 안에 실제 파일을 보내준다”, “대표가 아닌 실무자가 동료를 다음 미팅에 초대한다”, “수동 세팅 제안을 거절하지 않는다”처럼 행동으로 적어야 합니다.

버릴 기능도 반드시 적어둡니다. 로그인, 통계 대시보드, 관리자 권한, 예쁜 검색 필터. 다 좋아 보이지만 첫 학습과 무관하면 빼야 합니다. 이걸 안 적으면 팀은 늘 다시 넣고 싶어집니다. 너무 자연스러운 유혹이거든요.

랜딩페이지, 수동 운영, PDF 목업도 다 MVP가 될 수 있습니다

이 말이 여전히 어색한 분이 많습니다. “아니, 제품이 없는데 무슨 MVP냐” 하고요.

그런데 실제로는 제품이 없어도 검증할 수 있는 게 꽤 많습니다. Dropbox가 초기에 짧은 영상으로 반응을 확인했던 사례가 자주 언급되는 것도 그래서입니다. 만들 수 있느냐보다 먼저, 사람들이 이 문제를 진짜로 원하느냐를 보려는 접근이었죠.

예를 들어 월 15만 원짜리 콘텐츠 승인 워크플로우 툴을 만들려는 3인 팀이라면, 첫 주에는 피그마 클릭 목업과 구글폼만으로 8명 인터뷰를 잡을 수 있습니다. 둘째 주에는 슬랙으로 파일을 받아 수동으로 승인 로그를 정리해주고, 셋째 주에는 그 과정에서 반복되는 단계만 간단히 자동화하면 됩니다.

이 순서가 좋은 이유는 명확합니다. 인터뷰에서 나온 말과 실제 사용 행동 사이의 간극을 빨리 볼 수 있기 때문입니다. “필요해요”라고 말한 8명 중 실제 파일을 보내는 사람이 2명뿐이라면, 문제 강도나 타이밍부터 다시 봐야 합니다.

MVP의 단위는 코드 양이 아니라 학습량입니다.

그래서 저는 초기 팀이 “이번 스프린트에 뭘 만들까”보다 “이번 2주에 어떤 가설을 죽일까”를 먼저 말할 때 더 안심됩니다. 제품팀 같으면서도, 동시에 창업팀 같거든요.

문서로 시작하면 고객 인터뷰도 훨씬 덜 흔들립니다

인터뷰가 흔들리는 가장 큰 이유는 질문이 많아서가 아닙니다. 무엇을 배우고 싶은지가 흐리기 때문입니다.

문서가 있으면 인터뷰도 정리됩니다. 첫 10분은 최근 행동을 묻고, 다음 10분은 현재 대안을 파고들고, 마지막 10분은 수동 해결안이라도 받아들일지 확인하는 식으로요. 그러면 인터뷰마다 비교가 가능해집니다. 누가 더 아픈지, 누가 더 빨리 움직이는지, 누가 실제 파일을 보내는지 같은 차이가 보입니다.

반대로 문서 없이 들어가면 매번 다른 얘기를 듣고도 다 맞는 것처럼 느껴집니다. 어떤 사람은 자동화를 원하고, 어떤 사람은 리포트를 원하고, 어떤 사람은 모바일을 원하죠. 그걸 다 주워 담으면 로드맵은 풍선처럼 부풀고, 문제 정의는 점점 사라집니다.

저는 MVP를 만들기 전에 팀 안에서 딱 한 문장만 합의해도 많이 달라진다고 봅니다. “이번 버전은 고객이 우리 제품을 좋아하는지 보려는 게 아니라, 이 문제가 오늘 일정표를 밀어낼 만큼 급한지 확인하려는 것이다.”

그 문장이 있으면 기능 논쟁도 줄어듭니다. 무엇을 더 넣을지보다, 무엇이 검증과 상관없는지가 보이기 때문입니다.

처음 써야 하는 건 PRD가 아니라 질문지에 가까운 문서입니다

초기 창업팀의 문서는 예쁘지 않아도 됩니다. 대신 살아 있어야 합니다. 이번 주 인터뷰 6건에서 무엇이 확인됐고, 무엇이 틀렸고, 다음 주엔 무엇을 물어볼지 남아 있어야 하죠.

저는 좋은 MVP를 보면 기능 수보다 메모가 먼저 보입니다. 고객이 마지막으로 문제를 겪은 날짜, 지금 쓰는 우회 방법, 파일 하나 보내준 시간, 유료 전환을 망설인 이유 같은 것들요. 그 기록이 쌓여야 제품이 만들어지고, 기록이 없으면 기능만 남습니다.

그래서 MVP를 시작할 때 제가 먼저 쓰는 문장은 늘 비슷합니다. “우리는 이번 2주 동안 무엇을 만들 것인가”가 아니라, “어떤 질문에 예 아니오를 받을 것인가.” 그 문장이 다음 대화를 열고, 그 대화가 결국 제품으로 이어집니다.

지금 MVP를 준비 중이라면 기능 목록보다 먼저 고객 5명 이름과 확인할 가설 3개를 한 페이지에 적어보셔도 좋겠습니다. 그 문서가 제대로 써지면, 무엇을 만들지보다 무엇을 아직 만들지 말아야 하는지가 먼저 보일 겁니다.

참고한 문헌 링크

투자/지원사업 제출 전 전략 점검

드래프티로 전략의 빈틈을 미리 확인하세요

투자자와 심사위원이 가장 먼저 질문할 가정을 제출 전에 점검할 수 있습니다.

무료로 시작하기 →

← 블로그 목록으로