최소한의 가치 있는 제품(Minimum Worthy Product)

ResumeGeni의 공개 화면을 다시 만들면서 저는 계속 같은 불편한 경계선과 마주칩니다. 기술적으로 동작하는 버전이 곧 구직자 앞에 내놓을 버전인 것은 아닙니다. 파서는 돌아갑니다. 결과물도 뜹니다. 흐름도 끝까지 이어집니다. 그런데도 그 경험 어딘가가 신뢰를 쌓는 대신 신뢰를 깎아먹습니다. 한 시간쯤 붙들고 앉아 화면을 다시 만들면 그 찜찜함은 사라지지만, 시계는 멈춰주지 않습니다.

이 긴장이 곧 이 글의 주제입니다. 두 가지 힘이 서로를 잡아당깁니다. 제품을 세상에 내놓을 만큼 빨리 출시하려는 힘과, 사용자의 믿음을 깎아먹는 제품은 내보내지 않겠다는 힘입니다. 만드는 사람 대부분은 한쪽 편을 골라 방어하는 식으로 이 긴장을 해소합니다. MVP 문화는 속도를 고릅니다. 완벽주의는 완성도를 고릅니다. 두 답 모두 실패합니다. 긴장 그 자체가 핵심이기 때문입니다.

최소한의 가치 있는 제품(Minimum Worthy Product)은 다른 기준입니다. 기능적이라고 변호할 수 있는 가장 작은 제품이 아니라, 신뢰를 얻어내는 가장 작은 제품을 내보내는 것입니다. ‘가치 있음’은 바닥이지 천장이 아닙니다. ‘최소’는 범위에 걸린 제약이지 품질 할인권이 아닙니다. MWP를 따르는 사람은 제품을 출시할 수 있을 때까지 기능을 잘라내고, 남은 모든 화면은 사용자가 체감할 수 있는 수준으로 붙듭니다. MVP를 따르는 사람은 너무 자주 그 반대로 합니다. 범위를 지키려고 품질을 잘라냅니다. 사용자가 데이터로 느끼는 것이 바로 이 뒤바뀜입니다.

핵심 요약

MVP는 원래 배움의 도구였습니다. 실제 사용자를 상대로 진짜 가설을 검증하는 가장 작은 산출물이었죠. 그런데 변질된 버전이 어설픈 결과물을 내보내도 된다는 면허가 되어버렸습니다. 최소한의 가치 있는 제품은 사라진 제약을 되살립니다. 값싸게 검증한 다음, 신뢰를 얻어내는 가장 작은 제품을 만드십시오. ‘최소’는 범위를 잘라냅니다. ‘가치 있음’은 남은 화면을 사용자가 체감할 수 있는 기준으로 붙듭니다.

---

MVP가 옳았던 부분

원래의 MVP 개념은 어설픈 결과물을 내보내도 된다고 허락한 적이 없습니다. 창업자가 엉뚱한 것을 만드느라 몇 달을 날리는 일을 멈추게 해주는 방법이었습니다.¹

에릭 리스가 린 스타트업을 쓴 이유는 특정한 실패 유형을 다루기 위해서였습니다. 존재하지도 않는 시장을 향해 정교한 제품을 만드는 엔지니어 말입니다. MVP는 배움을 위한 계측 도구였습니다. 특정 가설을 검증할 수 있는 가장 작은 산출물을 만들고, 실험을 돌리고, 무슨 일이 벌어졌는지 측정하고, 그 가설이 현실과 부딪혀 살아남았는지에 대한 이해를 갱신하는 것이죠. MVP에서 ‘최소’가 뜻하는 바는 배움을 위한 범위 축소였지, 출시를 위한 품질 붕괴가 아니었습니다.

원래의 틀은 지금도 유효합니다. 저도 씁니다. 제 스타트업 검증 순서(문제, 해법, 채널, 매출, 확장)는 리스에서 내려온 것입니다. 코드에 투자하기 전에 값싸게 검증할 수 있는 가정부터 시험해야 한다는 논리는, 검증 다음 단계에 MWP가 와야 한다는 논리와 같습니다. 각 단계의 계측 도구는 그 단계에 맞아야 합니다. 랜딩 페이지와 인터뷰는 수요성을 재는 MVP입니다. 프로토타입과 스파이크는 실현 가능성을 재는 MVP입니다. MWP는 검증 근거가 이미 손에 들어왔고, 실제 사용자가 신뢰를 맡길 첫 번째 진짜 물건을 만들 때 적용하는 기준입니다.

그러니 저는 MVP에 반대하는 것이 아닙니다. MVP가 현장에서 무엇으로 변해버렸는지에 반대하는 것입니다.

MVP 문화는 어디서 물러졌나

어느 시점엔가 “빨리 배워라”가 “뭐든 내보내라”로 바뀌었고, 그 뒤바뀜은 실제로 피해를 남겼습니다.

원래의 개념을 망가뜨린 세 가지 해석이 있습니다.

1. “제품의 첫 버전이 부끄럽지 않다면 너무 늦게 출시한 것이다”(리드 호프먼의 문장⁴)는 범위가 아니라 만듦새가 부끄러워도 된다는 면허가 되었습니다. 원래 주장은 기능 개수에 관한 것입니다. 훗날의 내가 “제품이 저것밖에 못 했다니” 하고 부끄러워할 만큼 기능을 적게 넣고 출시하라는 뜻이죠. 변질된 버전은 솜씨에 관한 이야기가 되었습니다. 훗날의 내가 “제품 꼴이 저랬다니” 하고 부끄러워할 만큼 거칠게 내보내라는 것입니다. 이 둘은 같은 문장이 아닙니다.

2. 측정 가능한 성과 지표의 자리에서 “빨리 배워라”를 “빨리 내보내라”가 밀어냈습니다. 배움은 느리고 성가신 과정이고 정성적인 통찰을 남깁니다. 출시는 빠르고 눈에 잘 띄는 과정이고 날짜가 찍힌 산출물을 남깁니다. 이 둘을 구분하지 못하면 산출물이 기본값으로 이깁니다. 팀이 배운 것을 아무도 측정하지 않으니, 매주 무언가를 내보내면서 배움은 완전히 멈춰버립니다.

3. 투자·성장·엑싯으로 이어지는 벤처 패턴은 제대로 내보내는 것보다 뭐라도 내보내는 것에 보상을 줍니다. 다음 투자 라운드에 추진력을 보여주는 게 일이라면, 물 탄 제품이라도 최소한 “우리는 출시했다”는 기준선은 넘깁니다. 반면 출시가 미뤄진 가치 있는 제품은, 바깥에서 보면 멈춰 선 팀과 구분되지 않습니다. 인센티브의 기울기가 아래를 향하는 것이죠.

이 변질 중 무엇도 원문 그대로의 MVP 탓은 아닙니다. 어설픈 출시를 변호할 명분이 필요했던 사람들의 입을 거치면서 MVP가 그렇게 된 것입니다.

사용자는 그 결과를 느낍니다. 여러분은 데이터에서 그것을 느낍니다. 온보딩은 끝나는데 두 번째 방문은 없습니다. 사용자가 가입 메일을 열어보고도 링크는 끝내 누르지 않습니다. 고객 문의가 제품이 처리한다고 내세운 바로 그 작업에 몰립니다. 이탈 곡선은 핵심 사용자층에서 평평해지는 대신 0을 향해 계속 무너집니다. 이런 결과는 예외적인 사례가 아닙니다. 사용자가 믿을 수 없는 기준으로 제품을 만들었을 때 치르는 핵심 비용입니다.

‘최소’는 ‘미완성’이 아닙니다

최소는 범위에 걸린 제약이지, 품질 할인권이 아닙니다.

실무적으로는 이렇습니다. 사용자를 정의하십시오. 제품이 전달하겠다고 내세우는 단 하나의 성과를 정의하십시오. 그 성과에 필요 없는 기능은 모두 걷어내십시오. 그런 다음 남은 화면은 온전한 품질 기준으로 붙드십시오. ‘최소’는 제품이 출시될 수 있을 때까지 범위를 잘라냅니다. ‘최소’는 제품을 더 빨리 내보내려고 기준을 잘라내지 않습니다.

두 기준을 나란히 놓으면 이렇습니다.

항목	MVP (현장 관행)	MWP
목표	움직이고 있음을 증명할 무언가를 출시	사용자의 믿음을 얻어내는 무언가를 출시
범위	기능적이라고 변호 가능한 가장 작은 산출물	검증된 약속을 전달하는 가장 작은 화면
품질 기준	돌아갈 만큼은 잘 동작함	사용자가 체감할 수 있는 기준
중단 규칙	“우리는 출시했다”	두 시험 모두 통과. 세 번의 재구축이 실패하면 기획서를 다시 씀
성공 신호	변경 로그에 찍힌 날짜	다섯 가지 신뢰 대리지표: 두 번째 성공률, D30/D1 비율, 코호트 곡선 모양, 자연 추천, 품질 마찰
실패 양상	약한 첫인상이 사용자 신뢰를 태워버림	다듬기가 숨는 행위로 변질됨

실제 사례를 보겠습니다. ResumeGeni의 약속은 지원자 추적 시스템을 깔끔하게 통과하고, 구직자가 채용 담당자에게 닿을 실질적인 기회를 얻게 해주는 ATS 대응 이력서입니다. 이 약속의 최소 버전에서 뺄 수 있는 것은 다음과 같습니다.

• 맞춤 템플릿
• 팀 협업
• 분석 대시보드
• LinkedIn, Indeed, 채용 사이트 연동
• 버전 기록
• 한 가지를 넘어서는 내보내기 형식

최소 버전에서 뺄 수 없는 것은 이렇습니다. 원본 이력서의 정확한 파싱, 부족한 부분에 대한 솔직한 진단, 채용 공고에 실제로 들어맞는 구체적인 문장 수정, Word에서 깨끗하게 열리는 파일 내보내기, 그리고 구직자가 안심할 수 있게 만드는 흐름입니다. 템플릿 없이도 출시할 수 있습니다. 하지만 두루뭉술한 조언, 망가진 내보내기, 취약한 처지의 사용자를 호구 취급하는 듯한 문구를 안고 출시할 수는 없습니다.

‘최소’는 제품 백로그에 대는 칼입니다. ‘가치 있음’은 그러고도 남은 화면에 대는 칼입니다.

‘가치 있음’은 바닥입니다

가치 있는 제품이 여러분이 상상한 모든 것을 담을 필요는 없습니다. 다만 담긴 모든 것은 사용자를 존중해야 합니다.

실무적인 의미에서 가치 있음이란, 사용자가 다음 상호작용까지 신뢰를 들고 갈 만큼 검증된 문제를 제대로 풀어준다는 뜻입니다. 사용자는 여러분이 무엇을 만들고 있었는지 알아보고, 앞으로 더 있으리라고 믿습니다. 첫 번째 방문이 견뎌내야 할 시련이기를 그치고, 두 번째 방문의 문을 여는 악수가 됩니다. 가치 있는 제품은 믿음을 쌓아 올립니다. 어중간한 제품은 믿음을 써버립니다.

신뢰는 흉내 낼 수 없습니다. 사용자가 이미 알고 있는 제품들이 여러분의 제품에 대한 기대치를 만듭니다.⁵ 여러분의 제품이 그 기대 아래에 있으면(눌러도 반응 없는 버튼, 얼버무리는 문구, 중간에 사용자를 내버려두는 흐름), 사용자는 말로 표현하기도 전에 그 간극을 알아챕니다. 그들은 떠나고, 돌아오지 않으며, 이미 마음속에서 접어버린 그 방문을 어떤 리텐션 메일도 되살리지 못합니다.

이것이 가치 있는가?라는 질문은 취향의 문제가 아닙니다. 신뢰의 문제입니다. 사용자의 대답은 행동으로 나타납니다.

검증이 먼저, 가치는 그다음

MWP에 대한 가장 강한 반론은, 가치 있음을 판단하는 주체는 만든 사람의 확신이 아니라 제품과 접촉한 사용자라는 것입니다. 맞는 말입니다. MWP는 사용자의 판단을 대신하지 않습니다. MWP는 첫 실사용자가 판단할 기회를 얻기도 전에 이미 확보한 신뢰를 태워버리는 일을 막아줍니다.

사용자와의 접촉은 검증 단계의 몫입니다. 만들기 전에, 문제가 진짜인지, 여러분이 제안한 해법이 그 문제를 다루는지, 사용자에게 닿을 수 있는지, 그들이 돈을 낼 것인지를 시험합니다. 근거는 랜딩 페이지, 인터뷰, 컨시어지 테스트, 프로토타입, 대기자 명단에서 나옵니다. 저는 그 순서에 대해 자세히 쓴 적이 있습니다. 이 관문들을 통과한 가설은 만들어질 자격을 얻은 것입니다.

MWP는 검증이 끝난 뒤에 시작됩니다. 검증은 그 약속을 원하는 사람이 있는지 묻습니다. MWP는 출시한 화면이 검증으로 이미 얻어둔 신뢰를 받을 자격이 있는지 묻습니다. 그 판단이 맞았는지는 리텐션, 추천, 품질 마찰 데이터가 결정합니다.

검증을 건너뛰고 결과물을 MWP라 부르면, 아무도 묻지 않은 질문에 대한 아름다운 답이 나옵니다. MWP를 건너뛰고 결과물을 린하다고 부르면, 검증으로 이미 얻어둔 신뢰를 대가로 치르는 물 탄 제품이 나옵니다.

올바른 순서는 이렇습니다. 실제 사용자를 상대로 값싸게 검증하고, 그다음에 검증된 약속에 맞는 가장 작은 가치 있는 제품을 만드십시오. 둘 다 하십시오. 어느 쪽도 건너뛰지 마십시오.

두 가지 시험: 지로와 스티브

제가 무언가를 다 됐다고 부르기 전에, 제품은 서로 다른 두 시험을 통과해야 합니다.

Jiro Test는 그 작업이 올바른지를 묻습니다. 제품이 동작한다는 증거. 제품이 예외 상황을 감당하는지. 눈에 보이지 않는 세부가 버텨주는지. 주장에는 구체적인 증거가 붙어 있는지. 얼버무림은 없습니다. 제 생각에는은 증거가 아닙니다. Jiro Test는 장인정신과 포부를 갈라놓습니다. 저는 지로 품질 철학에 대해 AI 에이전트에 적용되는 규율로서 쓴 적이 있는데, 같은 규율이 모든 제품 화면에 적용됩니다. 증거 관문은 제가 이 시험을 코드 리포트에서 실무로 굴리는 방식입니다.

Steve Test는 그 작업이 존재할 자격이 있는지를 묻습니다. 관점이 드러나는지. 제품 전체가 하나의 물건으로 맞아떨어지는지. 화면이 사용자의 존엄을 지켜주는지. 두루뭉술하게 넘기는 것이 아니라 읽는 사람이 딱 짚어낼 수 있는 즐거움이나 명료함의 장치가 있는지. Steve Test는 제품과 재고를 갈라놓습니다. 출시된 물건이 자동으로 가치 있는 물건이 되지는 않습니다. 기술적 체계로서의 안목에 대한 온전한 논증은 별도의 글에 있습니다. 이 글에서는 위의 실무적 정의가 무게를 감당합니다.

두 시험 모두 통과해야 합니다. Jiro Test가 실패하면 멈추고 고치십시오. Steve Test가 실패하면 다시 만드십시오. 둘 다 실패하면 문제는 더 위쪽, 기획서에 있습니다.

판단이 흔들릴 때 던지는 질문은 이 모든 것 중 가장 단순한 것입니다. 나는 여기에 움찔하지 않고 내 이름을 걸 수 있는가? 대답이 ‘아니오’라면, 그 작업은 아직 가치 있지 않습니다.

발밑의 증거: blakecrosley.com

지금 읽고 계신 이 페이지는 제 길 없는 전환 속의 작은 실험으로 시작했습니다. 동시에 이 글이 펴는 주장의 일부이기도 합니다.

React는 없습니다. Tailwind도 없습니다. webpack도, Vite도, 번들러도, 빌드 단계도 없습니다. FastAPI가 사이트 전체를 직접 서빙합니다. HTMX, Alpine.js, Jinja2, 그리고 순수한 CSS뿐, 그 사이에는 아무것도 없습니다. 2026년 4월 17일 빌드 기준으로 최초 페이지 전송량은 45~60KB이고, Lighthouse는 성능, 접근성, 모범 사례, SEO 네 항목 모두에서 100점 만점에 100점을 보고합니다.³ 이 사이트는 10개 언어로 돌아가고, 새 가이드와 블로그 글을 git push 한 번으로 끝까지 배포하며, 저장소 어디에도 node_modules/가 없습니다.

이 사이트의 MVP 버전이었다면 2026년의 기본값 조언을 따랐을 것입니다. Next.js, Tailwind, Vercel 말이죠. 주말 하나면 출시했을 것입니다. 그래도 괜찮았을 것입니다. 여러분은 여기에 도착했을 것이고, 페이지는 그럭저럭 봐줄 만한 속도로 떴을 것입니다. 차이는 할 수 있느냐 없느냐에서 오지 않았을 것입니다. 차이는 안목에서 왔을 것입니다. 저는 완벽한 Lighthouse 점수가 실제로 어떻게 만들어지는지에 대해 쓴 적이 있습니다. 짧게 말하면, 읽는 사람이 내려받지 않아도 되는 1KB 하나하나가 존중의 한 형태라는 것입니다.

MWP 버전은 더 오래 걸렸습니다. MWP 버전에서는 HTMX 패턴을 처음부터 직접 써야 했고, 타이포그래피를 손으로 다듬어야 했고, 폰트를 직접 호스팅해야 했고, i18n 파이프라인을 Cloudflare D1로 돌려야 했고, 빌드 도구가 없다는 사실 자체를 하나의 기능으로 다뤄야 했습니다. MWP 버전이 기본 스택보다 기술적으로 더 뛰어난 것은 아닙니다. MWP 버전은 더 의도적입니다. 그 의도는 읽는 사람이 알아챌 이음매가 더 적다는 형태로 드러납니다.

보이지 않는 장인정신입니다. 읽는 사람은 그 결정들을 보지 못합니다. 읽는 사람은 마찰이 없다는 것을 느낍니다. 마찰의 부재가 곧 그 장치입니다.

고객을 마주하는 증거: ResumeGeni

ResumeGeni는 기준을 더 높입니다. 사용자가 그냥 둘러보는 중이 아니기 때문입니다. 면접에 갈 수 있을지를 좌우할지도 모르는 문서를 고치려는 사람입니다.

ResumeGeni의 검증 결과는 깨끗했습니다. 랜딩 페이지, 대기자 명단, Reddit과 LinkedIn을 겨냥한 게시물, 2주 만에 이메일 가입 340건, 언제 출시하느냐고 직접 물어온 문의 12건, 그리고 얼리 액세스에 돈을 내겠다고 먼저 제안해 온 3건입니다.⁷ 검증 순서는 만들라고 말했습니다. 만든다는 결정은 쉬운 판단이었습니다. 어떤 모습으로 만들 것인가가 어려운 판단이었고, MWP가 실제로 일한 지점이 거기입니다.

두 종류의 삭감이 있었습니다. 첫 번째는 기능입니다. 템플릿, 협업, 분석, 수십 가지 내보내기 변형, 채용 사이트 연동. 전부 잘라냈습니다. 어느 것도 약속의 일부가 아니었습니다.

두 번째는 남은 것에 대해 제가 지키겠다고 마음먹은 기준입니다. 이 기준은 잘라내지 않습니다. 파서가 부실해서는 안 됩니다. 조언이 두루뭉술해서는 안 됩니다. 내보내기가 망가져서는 안 됩니다. 문구가 취약한 처지의 사용자를 전환율 지표로 취급해서는 안 됩니다. 제게 시간이 있었던 게 정상 경로뿐이라는 이유로, 흐름이 사용자를 중간에 내버려둬서는 안 됩니다.

MVP 버전이었다면 열 단계짜리 마법사, 일반론적인 결과물, 가장 좋은 순간에 튀어나오는 구독 결제 벽, 그리고 잘라낸 것들을 전부 약속하는 로드맵 페이지를 내보냈을 것입니다. 기능은 했을 것입니다. 사용자 몇 명은 한 번쯤 전환시켰을지도 모릅니다. 동시에 첫 사용자 집단에게 이 제품을 믿지 말라고 가르쳤을 것이고, 그 학습은 취약한 사용 맥락에서 나쁜 토대가 됩니다.

MWP 버전은 제가 원하는 것보다 작습니다. 제가 잘라낸 모든 기능은 언젠가 다시 넣고 싶어질 것입니다. 지켜야 할 선은, 사용자가 도착하는 그 제품이 그들을 존중한다는 것입니다. 그 토대가 제가 그 위에 무언가를 쌓을 줄 아는 유일한 토대입니다.

사용자가 실제로 알려주는 것

사용자가 이제 이 제품을 믿습니다라고 말해주는 일은 거의 없습니다. 하지만 그들의 행동은 흔적을 남깁니다.⁶

제가 지켜보는 다섯 가지 신호이며, 만드는 사람들을 독자로 상정해 보정한 값입니다.

1. 두 번째 성공률. 활성화된 사용자 중 자연스러운 사용 주기 안에 다시 돌아와 핵심 성과를 두 번째로 완수한 비율입니다. 신뢰는 첫 번째 성공이 아니라 두 번째 성공에서 쌓입니다. 반복 사용형 제품이라면 두 번째 성공률 30% 미만을 재구축 신호로 봅니다. 간헐적으로 쓰는 제품이라면 30일이라는 창을 억지로 씌우지 말고 다음 자연 사용 주기를 기준으로 재십시오.

2. 1일차 활성화 대비 30일차 리텐션. 재참여 메일은 리텐션 수치 자체를 부풀릴 수 있습니다. 비율은 조작할 수 없습니다. 주 단위 또는 월 단위로 쓰는 제품이라면, 이 비율이 활성화가 신뢰였는지 한 번의 호기심이었는지를 알려줍니다. 저는 0.25 미만을 경고로, 0.15 미만을 판결로 봅니다.

3. 코호트 리텐션 곡선의 모양. 가치 있는 제품은 초반 이탈 이후 곡선이 평평해집니다. 어설픈 제품은 계속 무너집니다. 곡선을 그려보십시오. 평균값이 감추는 이야기를 모양이 말해줍니다. 곡선이 끝내 평평해지지 않는다면, 그 제품을 실제로 믿는 핵심 사용자층이 없다는 뜻입니다.

4. 보상 없는 자연 추천 비중. 유료 채널도 아니고 추천 보상 프로그램의 미끼도 아닌, 직접 추천·결과물 공유·입소문으로 유입된 신규 활성 사용자의 비율입니다. 사용자는 가치 있는 제품에 대해 이야기합니다. 어설픈 제품은 잊습니다. 그 분야에 자연스러운 공유 순간이 있는데도 자연 추천이 신규 사용자 획득의 10% 미만에 머문다면, 그 제품은 추천받을 자격을 얻지 못한 것입니다.

5. 품질 마찰률. 환불, 분노 클릭, 고객 문의, 실패한 내보내기, 수동 교정을 활성 사용자 100명당 수치로, 코호트별로 추적하십시오. 이 수치는 제품이 돕겠다고 내세운 바로 그 사용자들에게 가하는 고통입니다. 제품이 성숙할수록 이 수치는 내려가야 합니다. 평평하거나 올라간다면, 문제는 고객 지원 절차가 아니라 제품입니다.

이 신호 중 어느 것도 허영 지표가 아닙니다. 하나하나가 꾸며내기 어렵습니다. 하나하나가 믿음을 얻어냈거나 얻어내지 못한 실제 사용자 경험으로 이어집니다. 특정 코호트의 다섯 가지 수치를 다 대지 못한다면, 여러분은 아직 자기 제품이 가치 있는지 모르는 것입니다.

MVP나 프로토타입이 여전히 맞는 선택일 때

MWP가 모든 산출물에 맞는 기준은 아닙니다.

MVP나 프로토타입의 논리가 여전히 옳은 세 가지 경우가 있습니다.

• 검증 이전. 랜딩 페이지, 인터뷰, 컨시어지 테스트, 클릭 가능한 프로토타입. 목표는 배움이지 장인정신이 아닙니다. 가설을 검증하는 못생긴 버전을 내보내십시오. 오늘 내보내십시오. 여기서 맞는 각본은 MWP가 아니라 검증 순서입니다.

• 실현 가능성 스파이크. 미지의 영역이 기술적일 때(내가 필요한 지연 시간 안에 모델이 이런 종류의 질의에 답할 수 있는가? API가 이 부하를 감당하는가? 파서가 실제 입력의 롱테일에서도 동작하는가?), 그 질문에 답하는 가장 작은 일회용 계측 도구를 만드십시오. 가치 있게 만들려 하지 마십시오. 정직하게 만드십시오.

• 네트워크 효과가 필요한 베타 화면. 마켓플레이스, 커뮤니티 제품, 네트워크 효과 기반 도구는 누구든 판단하기 전에 실제 사용자 기반이 필요합니다. 그래서 올바른 산출물은 코호트 계측이 붙은, 명확히 표기된 베타입니다. 베타를 내보내는 것은 가치 있는 버전의 대체재가 아닙니다. 베타를 내보내는 것은 여기서 ‘가치 있음’이 무엇인지 알아내는 유일한 방법입니다. 그 화면은 정직하게 베타라고 표기하십시오. v1인 척 꾸미지 마십시오.

MWP는 첫 번째 진짜 제품 화면을 위한 것입니다. 아직 그 화면 앞 단계(배우고, 시험하고, 발견하는 중)라면, 맞는 도구는 순서상 더 뒤쪽에 있습니다.

재구축 상한

중단 규칙이 없는 높은 기준은 회피가 됩니다.

제가 사소하지 않은 모든 작업에 적용하는 원칙에는 정직한 시도 세 번이라는 재구축 상한이 있습니다.² 정직한 시도란 실패한 축을 짚어내고, 구체적인 교정 조치를 명명하고, 접근 방식을 실질적으로 바꾸고, 두 시험 모두에 비추어 작업을 다시 평가했다는 뜻입니다. 같은 다듬기를 세 번 반복한 것은 세 번의 시도로 치지 않습니다. 그 반복은 한 번의 실패한 시도를 세 번 되풀이한 것으로 칩니다.

정직한 재구축 세 번이 가치 있는 제품을 만들어내지 못했다면, 문제는 솜씨가 아닙니다. 문제는 더 위쪽, 틀 짜기나 범위나 기획서나 팀에 있습니다. 화면을 다시 만들기를 멈추고 전제를 들여다보십시오. 어떤 때는 약속이 여러분이 현실적으로 기준을 지킬 수 있는 범위에 비해 너무 컸던 것입니다. 어떤 때는 검증이 생각보다 물렀던 것입니다. 어떤 때는 애초에 제품 문제가 아닙니다.

재구축 상한은 서로 반대되는 두 가지 실패를 해결합니다. 어설픈 작업에 도장을 찍어주기를 거부하고, 다듬기가 숨는 행위로 변질되는 것을 막습니다. 목표는 완벽이 아닙니다. 목표는 가치 있으면서 출시된 것입니다. 순수하되 영원히 미출시가 아닙니다.

완벽주의는 용기 없는 장인정신입니다. 같은 화면을 네 번째로 다시 만들고 있다면, 여러분은 제품 만들기를 그만두고 그 프로젝트를 숨을 곳으로 쓰기 시작한 것입니다.

핵심 정리

창업자와 1인 개발자에게: - 코드를 쓰기 전에 값싸게 검증하십시오. MWP는 검증이 시장 적합성을 확인한 다음에 적용됩니다. - 기능은 과감하게 잘라내십시오. 남은 화면은 온전한 품질 기준으로 붙드십시오. - 가치 있는 지점에서 출시하십시오. 재구축은 세 번으로 제한하십시오. 그 뒤에는 기획서 단계로 올려 보내십시오.

제품 리더와 PM에게: - 신뢰 대리지표를 직접 측정하십시오. 두 번째 성공률, 30일차 대 1일차 리텐션 비율, 코호트 곡선 모양, 자연 추천 비중, 사용자 100명당 품질 마찰률. - 범위 논의와 품질 논의를 분리하십시오. 범위 삭감은 협상 가능합니다. 품질 삭감은 아닙니다. - 첫 사용자 집단의 경험을 지키십시오. 취약한 사용자에게 남긴 나쁜 첫인상은 회복에 몇 년이 듭니다.

엔지니어링 리드에게: - 출시하는 모든 화면에 대해 지로 관문과 스티브 관문을 명시하십시오. 둘 다 통과해야 합니다. - 보이지 않는 장인정신에 예산을 배정하십시오. “동작한다”와 “가치 있다”의 차이는 대개 아무도 손가락으로 가리키지 않는 세부에 있습니다. - 완벽주의가 다듬기로 위장해 숨지 못하도록 재구축 상한을 프로세스에 넣으십시오.

디자이너에게: - 관점은 장식이 아닙니다. 제품을 알아볼 수 있게 만드는 장치입니다. - 가치 있는 화면은 눈에 보이게 무언가를 거절합니다. 팀이 아무것도 거절하지 않았다면 범위가 잘못된 것입니다. - 모호할 때 던지는 실전 시험은 이것입니다. 여러분은 그 결정에 움찔하지 않고 이름을 걸 수 있겠습니까?

맺으며: 믿음을 얻어냈을 때 출시하십시오

제품에서 중심이 되는 질문은 다 됐는가?가 아닙니다. 중심이 되는 질문은 이것이 존재할 자격이 있는가?입니다.

대답이 ‘예’라면 출시하십시오. 대답이 “아직 아니지만, 정직한 재구축 세 번 안에는 그렇게 될 것”이라면 계속 작업하십시오. 대답이 ‘아니오’이고, 세 번의 시도 뒤에도 계속 ‘아니오’라면, 화면이 아니라 기획서를 다시 만드십시오.

이 방식이 제가 제 이름을 거는 모든 제품을 만드는 방식입니다. MVP 사고방식은 사이클 수를 최적화합니다. MWP 사고방식은 하나의 작품 세계로 복리처럼 쌓입니다.

여러분이 존중할 수 있는 가장 작은 제품을 내보내십시오. 그 전에 내보내지 마십시오. 그 이후까지 기다리지도 마십시오. ‘최소’와 ‘가치 있음’은 동시에 붙들어야 하는 하나의 지시입니다.

---

자주 묻는 질문

최소한의 가치 있는 제품(Minimum Worthy Product)이란 무엇인가요?

최소한의 가치 있는 제품이란, 검증을 마친 제품의 가장 작은 공개 버전으로서 사용자의 믿음을 써버리는 대신 얻어내는 버전입니다. ‘최소’는 범위를 핵심 약속까지 잘라낸다는 뜻입니다. ‘가치 있음’은 남은 화면이 사용자가 체감할 수 있는 품질 기준을 충족한다는 뜻입니다. 실제 사용자가 마주하는 첫 번째 진짜 물건은 단지 동작하는 데 그치지 않고 그들의 신뢰를 받을 자격이 있어야 합니다.

MWP는 MVP와 어떻게 다른가요?

원문 그대로의 최소 기능 제품은 배움을 위한 계측 도구였습니다. 특정 가설을 검증하는 가장 작은 산출물이었죠. 그런데 현장에서 MVP는 어설픈 결과물을 내보내도 된다는 면허로 변질됐습니다. 최소한의 가치 있는 제품은 사라진 제약을 되살립니다. 검증은 그것을 원하는 사람이 있는지를 다룹니다(MVP, 랜딩 페이지, 인터뷰가 할 일입니다). MWP는 검증이 확인해준 것의 첫 번째 진짜 버전을 만들 때 지켜야 할 기준을 다룹니다.

팀은 언제 MWP 대신 MVP를 써야 하나요?

최소 기능 제품이나 프로토타입의 논리가 여전히 적용되는 경우는 세 가지입니다. 검증 이전(랜딩 페이지, 인터뷰, 컨시어지 테스트, 클릭 가능한 프로토타입), 실현 가능성 스파이크 중(지연 시간이나 품질을 시험하는 일회용 코드), 그리고 팀이 ‘가치 있음’을 정의하기 전에 실제 사용자가 필요한 네트워크 효과 제품의 경우(표기된 베타)입니다. MWP는 첫 번째 진짜 제품 화면에 적용되는 것이지, 그 앞 단계의 모든 산출물에 적용되는 것이 아닙니다.

제품이 가치 있는지는 어떻게 측정하나요?

허영 지표가 아니라 다섯 가지 행동 기반 신뢰 대리지표로 측정합니다. 두 번째 성공률(활성화된 사용자 중 핵심 성과를 두 번째로 완수한 비율), 1일차 활성화 대비 30일차 리텐션(절대값이 아니라 비율), 코호트 리텐션 곡선의 모양(평평한가 계속 무너지는가), 보상 없는 자연 추천 비중, 품질 마찰률(활성 사용자 100명당 환불·실패한 내보내기·고객 문의)입니다. 가치 있는 제품은 다섯 가지 모두에서 힘을 보여줍니다. 어설픈 제품은 최소한 하나에서, 대개는 전부에서 그것이 드러납니다.

---

가치 관문

이 틀을 여러분의 작업에 적용해보는 판단 도구입니다. 다섯 가지 입력값을 거친 다음, 세 가지 원칙 기준을 차례로 통과하십시오. 점수도 없고 게임처럼 꾸민 계기판도 없습니다. 어느 축이 문제인지와 다음 수를 짚어주는 판정만 있습니다.

---

참고 문헌