전부 만들려 하지 마세요, 가장 작은 첫 버전부터

만들고 싶은 것이 또렷해지고 나면, 그다음에 빠지기 쉬운 함정이 하나 있습니다. 떠오른 기능을 첫 버전에 전부 담으려는 것입니다. 로그인도 있어야 하고, 알림도 보내야 하고, 통계 화면도 있으면 좋겠고, 결제도 붙이고 싶고. 그렇게 목록이 길어질수록 시작은 멀어지고, 끝내 아무것도 내놓지 못한 채 흐지부지되는 일이 흔합니다.

이 함정을 빠져나오는 오래된 방법이 MVP입니다. 흔히 최소 기능 제품이라고 옮기는데, 이 이름 때문에 절반쯤 오해를 받습니다. 여기서는 MVP가 정확히 무엇이고 무엇이 아닌지 짚고, 잘 알려진 사례를 살펴본 다음, AI와 대화하며 첫 버전의 범위를 직접 좁히는 방법까지 정리해보겠습니다.

전부 만들려다 아무것도 못 끝냅니다

기능을 많이 넣을수록 좋은 제품이 될 것 같지만, 실제로는 반대인 경우가 많습니다. 기능이 하나 늘 때마다 만들 것이 늘고, 손볼 곳이 늘고, 출시는 그만큼 미뤄집니다. 그사이 정작 가장 중요한 질문, 사람들이 이걸 정말 쓸까에 대한 답은 한참 뒤로 밀립니다.

더 큰 문제는 다 만들고 나서야 그 답을 알게 된다는 점입니다. 몇 달을 들여 모든 기능을 완성했는데 막상 아무도 쓰지 않는다면, 그 몇 달은 통째로 사라집니다. 반대로 가장 중요한 한 가지만 빠르게 내놓아 보면, 방향이 맞는지 틀렸는지를 훨씬 적은 비용으로 일찍 알 수 있습니다.

MVP는 작은 제품이 아니라 빨리 배우는 방법입니다

MVP의 가장 널리 쓰이는 정의는 에릭 리스가 내린 것입니다. 최소한의 노력으로 고객에 대한 검증된 배움을 가장 많이 얻게 해주는, 새 제품의 한 버전이라는 것입니다. 문장이 조금 딱딱하지만, 무엇을 줄이고 무엇을 키우는지를 정확히 짚고 있습니다. 줄이는 것은 들이는 노력과 시간이고, 키우는 것은 배움입니다.

그래서 MVP에서 중요한 것은 크기가 아니라 목적입니다. 목적은 단 하나, 우리가 세운 가정이 맞는지를 가장 빨리 확인하는 것입니다. 사람들이 이 문제를 진짜 불편해하는지, 우리가 내놓은 해결책을 실제로 쓰는지, 돈을 낼 의향까지 있는지. 이런 질문에 대한 답을 가장 적은 비용으로 얻어내는 첫 버전이 MVP입니다.

리스 본인도 이 오해를 분명히 경계했습니다. 이름과 달리, MVP는 최소한의 제품을 만드는 일이 아니라고요.

이름과 달리, MVP는 최소한의 제품을 만드는 것에 관한 것이 아니다. (에릭 리스)

참고로 MVP라는 용어 자체는 2001년 프랭크 로빈슨이 처음 정의한 것으로 알려져 있고, 이후 스티브 블랭크와 에릭 리스가 널리 퍼뜨렸습니다. 블랭크는 한 글의 제목에서 핵심을 이렇게 못 박았습니다. MVP는 더 싼 제품이 아니라, 똑똑하게 배우는 것에 관한 일이라고요.

흔한 오해: 엉성한 제품은 MVP가 아닙니다

최소라는 말에만 꽂히면, MVP를 대충 만든 미완성품과 같은 것으로 여기기 쉽습니다. 하지만 이름의 무게중심은 최소가 아니라 쓸 만한에 있습니다. 영어 Viable은 그 자체로 제 역할을 하는, 살아서 굴러가는이라는 뜻입니다. 기능은 적어도 그 적은 기능만큼은 제대로 동작해서, 사용자가 실제로 한 바퀴를 돌 수 있어야 합니다.

이 점을 가장 잘 보여주는 그림이 있습니다. 애자일 코치 헨릭 크니베리가 정리한 것으로, 이동 수단을 만드는 두 가지 방식을 나란히 놓습니다. 한쪽은 바퀴를 먼저 만들고, 다음에 차체를 만들고, 마지막에야 완성차를 내놓습니다. 다른 한쪽은 스케이트보드를 먼저 내놓고, 킥보드, 자전거, 오토바이를 거쳐 자동차로 갑니다.

차이는 분명합니다. 바퀴만 있는 상태는 그 자체로는 쓸모가 없습니다. 사용자는 완성차가 나오기 전까지 아무 데도 갈 수 없고, 그동안 어떤 피드백도 나오지 않습니다. 반면 스케이트보드는 자동차에 한참 못 미치지만, 적어도 사람을 A에서 B로 옮겨줍니다. 고객이 진짜 원한 것은 자동차라는 형태가 아니라 이동이었으니까요. 핵심은 이것입니다. 매 단계가 비록 작더라도 처음부터 끝까지 제 기능을 하는 완결된 것이어야 한다는 점입니다.

최소를 원하는 고객은 거의 없지만, 대부분의 고객은 빠른 것을 원합니다. (헨릭 크니베리)

다만 이 비유를 글자 그대로 받아들일 필요는 없습니다. 스케이트보드가 실제로 자동차로 진화하지는 않으니까요. 크니베리 본인도 이건 어디까지나 비유라고 단서를 달았습니다. 가져갈 교훈은 하나입니다. 첫 버전이 작더라도, 그 작은 것만으로 사용자가 한 바퀴를 온전히 돌 수 있어야 한다는 것.

빨리 내놓아야 빨리 배웁니다

MVP가 빠른 배움을 위한 도구라면, 그 배움은 어떻게 일어날까요. 에릭 리스는 이를 만들기, 측정하기, 배우기의 반복으로 설명합니다. 아이디어를 작은 제품으로 만들고, 사람들이 어떻게 반응하는지 측정하고, 그 결과로부터 방향을 그대로 밀고 갈지 바꿀지를 배우는 것입니다. 이 한 바퀴를 빨리 돌릴수록 좋은 제품에 빨리 다가갑니다.

그래서 첫 버전은 완벽할 필요가 없습니다. 오히려 완벽을 기다리다가는 배움이 늦어집니다. 링크드인을 만든 리드 호프먼은 이 점을 자주 인용되는 한 문장으로 남겼습니다.

제품의 첫 버전이 부끄럽지 않다면, 너무 늦게 출시한 것이다. (리드 호프먼)

다만 이 말을 대충 만들어 아무렇게나 내놓으라는 뜻으로 오해하면 안 됩니다. 호프먼 자신이 분명히 못 박았습니다. 사용자가 등을 돌리거나 문제가 생길 만큼 일찍 내놓는 것은 너무 이른 것이라고요. 여기서 말하는 부끄러움은 나중에 보니 그때 좀 어설펐네 하는 가벼운 수준이지, 사용자를 실망시키는 수준이 아닙니다. 작더라도 제 역할은 하는 것, 다시 쓸 만한이라는 조건으로 돌아옵니다.

작게 시작해 크게 된 회사들

지금은 거대해진 서비스들도 첫 버전은 놀랄 만큼 단출했습니다. 공통점은 제품을 다 만들기 전에, 사람들이 정말 원하는지부터 가장 싼 방법으로 확인했다는 것입니다.

이들이 처음에 만든 것은 완성된 제품이 아니라 가장 싼 검증 장치였습니다. 영상 한 편, 사진 몇 장, 페이지 한 장. 공통된 질문은 같았습니다. 우리가 만들려는 것을 사람들이 진짜 원하는가. 그 답을 먼저 얻은 다음에야 제대로 만들기 시작했습니다.

어떻게 잘라야 할까: 세로로 자르세요

첫 버전을 작게 만들라고 하면, 흔히 기능을 층층이 나눠 아래쪽부터 만들려고 합니다. 데이터베이스부터 완성하고, 그다음 화면을 붙이고, 마지막에 둘을 잇는 식입니다. 이렇게 가로로 자르면 모든 층이 끝날 때까지 사용자는 아무것도 쓸 수 없습니다. 바퀴만 있는 자동차와 같은 상태입니다.

대신 세로로 잘라야 합니다. 하나의 기능을 골라, 화면부터 저장까지 처음부터 끝까지 동작하는 얇은 한 줄기로 만드는 것입니다. 기능은 단 하나뿐이어도, 그 하나는 사용자가 켜서 실제로 끝까지 해볼 수 있습니다. 스케이트보드가 바로 이 세로로 자른 한 줄기에 해당합니다.

그래서 첫 버전을 정할 때 던질 질문은 어떤 화면들이 필요할까가 아니라, 사용자가 끝까지 해내려는 단 하나의 일이 무엇인가입니다. 그 한 가지 일을 처음부터 끝까지 통과시키는 데 꼭 필요한 것만 남기고, 나머지는 전부 다음으로 미룹니다.

안 할 것을 먼저 정하세요

범위가 무한정 늘어나는 것을 막는 가장 좋은 습관은, 넣을 것을 고르는 동시에 안 할 것을 분명히 적어두는 것입니다. 기능을 떠올릴 때마다 좋은데라는 생각이 들지만, 좋은 것과 첫 버전에 꼭 필요한 것은 다릅니다. 다음 질문을 통과하지 못하는 기능은 일단 안 할 것으로 미뤄두세요.

• 이게 없으면 사용자가 핵심 한 가지 일을 끝까지 해낼 수 없는가. 아니라면 미룹니다.
• 이게 우리가 지금 확인하려는 가정과 직접 관련이 있는가. 아니라면 미룹니다.
• 이건 나중에 붙여도 늦지 않은가. 늦지 않다면 지금은 미룹니다.
• 있으면 좋지만 없어도 굴러가는가. 그렇다면 미룹니다.

안 할 것 목록은 포기가 아니라 순서입니다. 영영 안 한다는 뜻이 아니라, 첫 바퀴를 돌린 뒤에 본다는 뜻입니다. 이 목록이 있어야 대화 중에 기능이 슬금슬금 불어나는 것을 멈출 수 있습니다.

AI와 함께 MVP 범위를 잡는 법

여기까지가 개념입니다. 이제 실제로 내 아이디어를 첫 버전 범위로 좁힐 차례인데, 혼자 하면 자꾸 기능을 더 넣는 쪽으로 기웁니다. 이때 AI를 범위를 좁혀주는 코치로 쓰면 좋습니다. 핵심은 AI에게 만들어 달라고 하지 않고, 무엇을 빼야 하는지 같이 정하자고 부탁하는 것입니다.

아래 프롬프트를 클로드 같은 AI 채팅창에 그대로 붙여넣고, 마지막에 내 아이디어를 한두 줄 덧붙여 시작하세요. 한 번에 하나씩 묻게 하고, 기능을 늘리려 하면 말리게 하고, 마지막에 정해진 형식으로 정리하게 하는 장치가 들어 있습니다.

당신은 제품의 첫 버전을 가장 작게 좁혀주는 노련한 제품 코치입니다.
저에게는 만들고 싶은 아이디어가 있지만, 첫 버전에 무엇을 넣고
무엇을 뺄지 막막합니다. 당신의 목표는 제가 "가장 빨리 내놓고 가장 빨리
배울 수 있는 첫 버전(MVP)"의 범위를 함께 정하도록 돕는 것입니다.

[진행 규칙]
1. 한 번에 하나씩만 질문하세요. 제 답을 듣고 나서 다음 질문으로 넘어갑니다.
   여러 질문을 한꺼번에 쏟지 마세요.
2. 제가 기능을 늘리려 하면, 그게 첫 버전에 정말 꼭 필요한지 되물어
   저를 말려 주세요. 좋아 보인다는 이유만으로 통과시키지 마세요.
3. 듣기 좋은 말로 동의하지 마세요. 범위가 넓어 보이면 솔직하게 지적하고,
   더 줄일 수 있는 곳을 적극적으로 찾아 주세요.
4. 어려운 용어 대신 쉬운 말로 물어 주세요.

[1단계: 파악하기] 아래를 한 번에 하나씩, 차례로 물어 주세요.
- 누가, 어떤 불편 때문에 이걸 쓰나요?
- 그 사람이 이걸로 끝까지 해내려는 단 하나의 일은 무엇인가요?
- 그 한 가지 일을 처음부터 끝까지 해내는 데 꼭 있어야 하는
  화면이나 기능은 무엇인가요?
- 지금 없어도 되는, 나중으로 미뤄도 되는 것은 무엇인가요?
- 이 첫 버전이 성공인지 아닌지를 무엇을 보고 판단하나요?

[2단계: 정리하기] 파악이 끝나면 아래 형식으로 정리해 주세요.
- 핵심 사용자: (한 문장)
- 검증하려는 단 하나의 가정: (한 문장)
- 첫 버전에 반드시 넣을 기능: (3개 이내. 각 기능은 화면부터 저장까지
  처음부터 끝까지 동작하는 한 줄기가 되도록)
- 이번에는 절대 만들지 않을 것: (목록)
- 출시 후 무엇을 보고 다음을 정할지: (한두 가지 지표)

[3단계: 한 번 더 줄이기] 위 정리를 스스로 다시 검토해서, 빼도
핵심 한 가지 일이 돌아가는 기능이 있는지 찾아 주세요. 더 작게 줄일 수
있다면, 줄인 안을 제안하고 무엇을 왜 뺐는지 알려 주세요.

준비됐으면, 한 번에 하나씩 질문한다는 규칙을 지켜 첫 질문부터
시작해 주세요. 제 아이디어는 다음과 같습니다: (여기에 한두 줄로 적기)

이렇게 시작하면 AI가 곧바로 결과물을 쏟아내는 대신, 누가 쓰는지부터 하나씩 물어옵니다. 그 질문에 답하는 사이 머릿속 기능 목록이 자연스럽게 추려지고, 마지막에는 첫 버전에 넣을 것과 미룰 것이 형식에 맞춰 정리되어 나옵니다. 3단계에서 한 번 더 줄이게 한 덕분에, 보통 처음 생각보다 더 작은 안을 받게 됩니다.

이미 기능이 잔뜩 떠올랐다면

만들고 싶은 기능이 이미 길게 적혀 있는 경우도 많습니다. 그럴 때는 처음부터 좁히기보다, 적어둔 목록을 우선순위로 잘라내는 편이 빠릅니다. 아래 프롬프트는 흔히 모스코우라고 부르는 분류법을 씁니다. 모든 기능을 꼭 필요, 있으면 좋음, 나중에 고려, 이번엔 제외 네 칸으로 나누는 방식입니다.

아래는 제가 만들려는 제품에 넣고 싶은 기능 목록입니다.
첫 버전을 가장 작게 만들려고 하니, 함께 우선순위를 정해 주세요.

[규칙]
- 먼저 이 제품의 사용자가 끝까지 해내려는 단 하나의 핵심 일이
  무엇일지 한 문장으로 정리하고, 저에게 맞는지 확인받으세요.
- 그 핵심 일을 기준으로, 아래 기능을 네 칸으로 나눠 주세요.
  · 꼭 필요: 이게 없으면 핵심 일이 아예 안 돌아가는 것
  · 있으면 좋음: 핵심 일은 돌아가지만 더 나아지게 하는 것
  · 나중에 고려: 사용자가 늘어난 뒤에야 의미 있는 것
  · 이번엔 제외: 첫 버전과 상관없는 것
- "꼭 필요"는 최대한 적게 잡아 주세요. 3개를 넘기면, 왜 그게 다
  꼭 필요한지 저에게 따져 물어 주세요.
- 각 기능을 어느 칸에 왜 넣었는지 한 줄로 이유를 달아 주세요.
- 마지막에 "꼭 필요"에 든 기능만으로 사용자가 핵심 일을 처음부터
  끝까지 해낼 수 있는지 점검하고, 빠진 연결 고리가 있으면 알려 주세요.

제 기능 목록은 다음과 같습니다:
- (기능 1)
- (기능 2)
- (기능 3)
- ...

이 프롬프트의 핵심은 꼭 필요 칸을 일부러 좁게 잡게 한 데 있습니다. 사람은 거의 모든 기능을 꼭 필요라고 느끼기 때문에, AI가 그때마다 정말 그런지 따져 묻게 만들어야 목록이 실제로 줄어듭니다.

실제로 대화하면 이렇게 좁혀집니다

예를 들어 독서 모임의 출석과 진도를 관리하는 앱을 떠올렸다고 해봅시다. 처음 머릿속에는 기능이 한가득입니다. 회원 가입과 로그인, 모임 개설, 출석 체크, 읽은 분량 기록, 멤버별 통계, 다음 모임 알림, 채팅, 그리고 끝낸 책 자랑하는 게시판까지. 이대로 만들면 몇 달이 걸립니다.

앞의 프롬프트로 대화하면 질문이 이렇게 흘러갑니다. 누가 쓰나요. 모임을 이끄는 운영자입니다. 그가 끝까지 해내려는 단 하나의 일은. 이번 모임에 누가 어디까지 읽고 왔는지 한눈에 보는 것입니다. 그렇다면 그 한 가지에 꼭 필요한 것만 남기면, 목록은 놀랄 만큼 짧아집니다.

로그인조차 첫 버전에서는 빼볼 수 있습니다. 운영자 혼자 쓰는 화면이라면, 여러 사람의 계정을 관리하는 일은 핵심 한 가지와 관계가 없으니까요. 이렇게 세로로 한 줄기만 남기면, 몇 달짜리 계획이 며칠짜리 첫 버전으로 줄어듭니다. 그리고 그 며칠짜리를 운영자에게 보여주는 순간, 정말 필요한 다음 기능이 무엇인지가 상상이 아니라 실제 사용에서 드러납니다.

한 가지 주의, AI는 너무 쉽게 동의합니다

범위를 좁히는 대화에서도 한 가지 함정이 있습니다. AI는 사용자에게 듣기 좋은 말을 하려는 경향이 있어서, 내가 이 기능도 넣고 싶어라고 하면 좋은 생각이라고 맞장구치기 쉽습니다. 하지만 우리에게 필요한 코치는 순순히 동의하는 상대가 아니라, 그거 정말 첫 버전에 필요할까요라고 되묻는 상대입니다.

그래서 위 프롬프트에는 듣기 좋은 말로 동의하지 말고 솔직히 지적하라는 규칙을 일부러 넣었습니다. 대화 중에도 AI가 너무 쉽게 수긍한다 싶으면, 더 줄일 수 있는 곳을 다시 찾아봐 달라고 한 번 더 밀어붙이세요. 좋은 범위는 한 번에 나오지 않고, 빼고 또 빼는 과정에서 또렷해집니다.

정리하며

MVP는 제품을 대충 작게 만드는 일이 아닙니다. 가장 빨리 내놓아 가장 빨리 배우기 위해, 첫 버전을 핵심 한 줄기로 좁히는 일입니다. 무게중심은 최소가 아니라 쓸 만한에 있고, 그 작은 첫 버전만으로도 사용자는 한 바퀴를 온전히 돌 수 있어야 합니다.

만들고 싶은 것이 또렷해졌다면, 다음 질문은 그래서 이번에 무엇만 만들 것인가입니다. 떠오른 기능을 전부 끌어안기 전에, AI를 범위 코치로 삼아 가장 작은 한 줄기부터 정해보세요. 작게 시작한 첫 바퀴가, 다음에 무엇을 만들지를 가장 정확하게 알려줍니다.

참고한 글

• 에릭 리스 - MVP는 이름과 달리 최소 제품을 만드는 게 아니다 (Minimum Viable Product: a guide, 2009 / The Lean Startup, 2011)
• 프랭크 로빈슨 - MVP 용어를 처음 정의 (SyncDev, 2001년으로 알려짐)
• 스티브 블랭크 - MVP는 더 싼 제품이 아니라 똑똑한 배움이다 (steveblank.com, 2013)
• 헨릭 크니베리 - 스케이트보드에서 자동차로, MVP를 이해하기 (Making sense of MVP, 2016)
• 리드 호프먼 - 첫 버전이 부끄럽지 않다면 너무 늦은 것이다 (LinkedIn 에세이, 2017)
• 마티 케이건 - MVP는 제품이 아니라 프로토타입이어야 한다 (SVPG)
• 드류 휴스턴 - 드롭박스의 데모 영상으로 수요 검증하기 (Dropbox Startup Lessons Learned, 2009)
• 조엘 개스코인 - 랜딩 페이지로 7주 만에 유료 고객까지 (Buffer 블로그)