MVP

만들 것을 처음에 전부 정하고 다 만든 뒤에 내보내던 시절이 있었습니다. 기획서에 기능 마흔 개를 적고, 열여덟 달 동안 그것을 하나씩 구현하고, 마지막에 한꺼번에 세상에 내놓습니다. 이 순서에서 무엇이 잘못됐는지는 마지막 날에만 알 수 있습니다. 쓸모가 없는 제품이었다는 사실을 확인하려고 열여덟 달과 그동안의 인건비를 전부 써 버린 뒤입니다.

실제로는 이런 장면이 반복됐습니다. 출시일에 맞춰 밤을 새워 마흔 개를 다 붙여 내보냈는데 3주 동안 가입이 마흔 명, 그중 두 번 이상 들어온 사람이 넷입니다. 회고 자리에서 나오는 말은 대체로 같습니다. "이걸 아무도 안 쓴다는 걸 알아내는 데 열여덟 달이 걸렸네요." 마흔 개 가운데 서른일곱 개는 만들지 않아도 됐던 것이고, 만들기 전에 알 방법이 없었던 것이 아니라 알아볼 생각을 하지 않았던 것입니다.

작게 만들어 배우며 사업을 키우자는 린 스타트업이 이 순서를 뒤집었습니다. 스타트업이 하는 일을 제품 생산이 아니라 실험으로 다시 정의한 것이 이 방법론의 출발점입니다. 실험이라면 확인하려는 가설이 먼저 있어야 하고, 만드는 것은 그 가설을 확인할 도구가 됩니다. 만들고 재고 배우는 순환인 빌드-측정-학습에서 MVP는 첫 번째 칸에 놓이는 물건입니다. 한 바퀴를 도는 데 걸리는 시간을 줄이는 것이 목표라서, 여기서 만드는 것은 작을수록 좋습니다.

여기서 최소라는 말이 자주 오해를 부릅니다. 기능 개수가 적다는 뜻이 아니라, 지금 확인하려는 가설 하나에 답하는 데 필요한 만큼이라는 뜻입니다. 같은 제품이라도 가설이 무엇이냐에 따라 만들 것이 달라집니다. 사람들이 이 문제를 돈 내고 해결하려 하는지가 궁금하다면 소개 페이지와 결제 버튼만 있으면 되고, 우리 방식이 실제로 시간을 줄여 주는지가 궁금하다면 그 절차만 끝까지 돌아가야 합니다. 두 번째 낱말인 'viable' 도 마찬가지입니다. 최소한 사용자가 겪는 문제 하나는 실제로 해결해 줘야 한다는 조건이라, 눌러도 아무 일이 일어나지 않는 화면은 여기에 들지 못합니다.

그래서 무엇을 만들지는 가설을 문장으로 적어 놓은 다음에 정해집니다. 실무에서는 대체로 이런 모양으로 적습니다. 누가 어떤 상황에서 무엇을 하려고 하는데, 우리가 이것을 해 주면 어떤 행동을 할 것이다, 그리고 그 행동이 몇 퍼센트 넘게 나오면 맞은 것으로 본다는 식입니다. 마지막 조각인 판정 기준이 빠지면 결과를 보고도 맞았는지 틀렸는지를 두고 다시 다투게 됩니다. 스무 명 중 셋이 신청했을 때 그것을 성공으로 볼지 실패로 볼지는 내보내기 전에 정해 둬야 합니다.

제품 축에서 완성 전에 작게 만들어 보는 갈래에는 넷이 있고, MVP는 그중 실제 사용자 앞에 내놓는 쪽입니다. 프로토타입은 반응만 보려고 임시로 꾸민 것이고, 개념 증명은 기술적으로 되는지만 확인하는 시도이며, 파일럿은 다 만든 것을 고객 몇 곳에 먼저 여는 시험 도입입니다. 넷의 차이는 크기가 아니라 무엇을 알아내려 하느냐에 있습니다.

MVP 아래 묶인 용어는 두 갈래입니다. 가설을 확인하려고 무엇을 만들어 내보이는지(유형), 그리고 최소라는 기준선을 어느 쪽으로 옮긴 것인지(변형)입니다.

유형은 만드는 양을 줄이는 방법을 가른 갈래입니다. 셋이 있고, 뒤에서 사람이 얼마나 일하느냐와 앞에 무엇을 내보이느냐로 갈립니다.

1. 컨시어지 MVP — 자동화를 만들지 않고 사람이 직접 서비스를 해 줍니다. 식단을 짜 주는 제품을 구상한다면 프로그램을 짜는 대신 열 명에게 직접 물어보고 손으로 식단을 써서 보내는 식입니다. 사용자는 제품이 아니라 사람에게 서비스를 받는다는 사실을 알고 있습니다. 만드는 시간이 0에 가깝고 대화가 남으니 무엇을 자동화해야 하는지가 가장 빠르게 드러납니다. 대신 스무 명을 넘기면 사람 손으로 감당이 안 되니 이 방식으로 규모를 재지는 못합니다.
2. 오즈의 마법사 MVP — 겉보기에는 자동으로 도는 제품인데 뒤에서는 사람이 처리합니다. 사용자가 문서를 올리면 30초 뒤 요약이 뜨는 화면을 만들어 두고, 그 30초 동안 뒤에서 담당자가 읽고 요약을 써 넣는 식입니다. 컨시어지와 다른 점은 사용자가 사람의 개입을 모른다는 것이고, 그래서 자동화된 제품을 실제로 쓸 때의 반응을 그대로 볼 수 있습니다. 사람 손이 붙는다는 사실을 알리지 않는 만큼 품질과 응답 시간을 약속한 대로 지켜야 합니다.
3. 랜딩 페이지 MVP — 제품을 아예 만들지 않고 소개 페이지만 띄워 수요를 잽니다. 무엇을 해 주는 제품인지와 가격을 적어 두고 신청 버튼을 답니다. 방문자 1000명 중 몇 명이 눌렀는지가 답이고, 누른 사람에게는 아직 준비 중이라고 안내하며 연락처를 받습니다. 셋 중 가장 싸지만 알 수 있는 것도 가장 좁습니다. 사람들이 이 설명에 관심을 보이는지까지만 알려 주고, 실제로 쓰면서 계속 쓸지는 알려 주지 않습니다.

변형은 최소라는 기준선을 옮긴 갈래입니다. 둘 다 MVP 가 실무에서 잘못 쓰이는 장면에 대한 반응으로 나왔습니다.

1. MLP — 최소한이되 사랑받을 만한 완성도까지는 갖추자는 쪽입니다. 배우는 것이 목적이라는 말을 방패 삼아 쓰기 불편한 것을 내보내면, 사용자가 등을 돌린 이유가 아이디어 때문인지 조잡함 때문인지 구분되지 않습니다. 기능 개수는 그대로 두되 남는 하나를 제대로 만들자는 제안입니다.
2. MMP — 돈을 받고 팔 수 있는 최소 구성입니다. 배우려고 내보내는 것과 매출을 일으키려고 내보내는 것은 갖춰야 할 것이 다릅니다. 결제와 환불, 문의 대응, 약관처럼 배움에는 필요 없지만 파는 데는 빠질 수 없는 것들이 여기서 들어옵니다.

두 갈래는 시간 순서로 이어집니다. 유형은 가설을 확인하는 단계에서 고르는 수단이고, 변형은 확인이 끝나 이것을 진짜 제품으로 키우기로 한 다음에 넘는 문턱입니다. 컨시어지로 열 명에게 손수 해 주며 수요를 확인하고, 그다음에 제대로 만들어 붙이고, 그다음에 값을 받는 순서가 됩니다. 순서를 건너뛰면 아무도 원하지 않는 것을 잘 만드는 데 여섯 달을 씁니다. 다섯 용어를 고르는 기준도 여기서 나옵니다. 아직 수요가 있는지조차 모르면 유형 쪽에서 가장 싼 것을 고르고, 수요는 확인됐는데 사람들이 금방 떠나면 변형 쪽으로 넘어갈 때입니다.

"이번엔 MVP로 갑시다. 3주 안에 초대 화면 하나만 열고 반응 보고 정하죠."

전체를 만들기 전에 판단 근거부터 만들자는 제안이고, 3주라는 기한은 확인에 쓸 비용의 상한입니다.

"이게 MVP인가요, 그냥 기능 덜 만든 건가요? 뭘 확인하려는지가 안 적혀 있는데요."

확인하려는 가설이 없으면 작게 만든 것일 뿐 MVP가 아니라는 지적입니다.

"MVP는 컨시어지로 갑시다. 자동화는 수요 확인되면 그때 붙여요."

제품을 만들지 않고 사람이 직접 해 주는 방식으로 먼저 확인하자는 뜻입니다.

페이지덱에서 문서 안의 코멘트를 그대로 할 일로 바꿔 주는 기능을 검토한 적이 있습니다. 지현이 세운 가설은 하나였습니다. 사람들이 코멘트에 적힌 요청을 따로 할 일 도구에 옮겨 적는 수고를 실제로 겪고 있고, 그것을 대신해 주면 계속 쓴다는 것입니다. 태오가 잡은 개발 기간은 일곱 주였습니다.

대신 지현은 먼저 컨시어지로 갔습니다. 유료 팀 여덟 곳에 물어 동의를 받고, 2주 동안 각 팀의 문서에 달린 코멘트를 지현이 직접 읽어 매일 아침 할 일 목록을 만들어 보냈습니다. 만든 것은 신청 양식 하나뿐이었습니다. 2주 뒤에 드러난 것은 가설의 절반이 틀렸다는 사실이었습니다. 여덟 팀 중 여섯 팀이 목록을 열어 봤지만, 그들이 원한 것은 코멘트를 할 일로 바꾸는 일이 아니라 누가 답을 안 하고 있는지 알려 주는 일이었습니다. 일곱 주짜리 개발을 시작하지 않은 채 방향을 바꿀 수 있었고, 실제로 만든 것은 답 없는 코멘트를 모아 주는 훨씬 작은 기능이었습니다. 2주 동안 지현이 쓴 시간은 하루 40분 남짓이었습니다. 같은 것을 코드로 알아내려 했다면 일곱 주와 태오의 시간을 먼저 써야 했고, 틀렸다는 사실은 그 뒤에 알게 됐을 것입니다.

가장 흔한 오해는 MVP를 기능을 덜 넣은 싼 버전으로 읽는 것입니다. 이름에 최소가 들어 있고 실제로 작게 만드니 그렇게 읽힐 만합니다. 그러나 줄이는 대상은 완성도가 아니라 범위입니다. 하나만 남기되 그 하나는 사용자가 실제로 쓸 수 있을 만큼 돌아가야 합니다. 이 구분이 없으면 팀은 열 가지 기능을 전부 절반씩 만든 것을 내보내고, 사용자가 떠난 이유가 아이디어가 틀려서인지 쓰기 불편해서인지 알 수 없게 됩니다. 실험 결과가 남지 않았으니 다음 결정은 다시 감으로 하게 되고, 작게 만든 이득도 사라집니다.

두 번째는 MVP를 한 번 내보내고 끝나는 단계로 읽는 것입니다. 첫 출시를 부르는 말처럼 쓰이는 일이 많아서 그렇습니다. 실제로는 순환의 한 칸이라 결과를 보고 다음 판단을 하려고 만든 것입니다. 앞서 본 페이지덱의 예처럼 2주 뒤에 가설이 틀렸다고 나오면 그 방향을 접고 다른 가설로 옮겨 가는 것이 정상적인 결말입니다. 끝나는 단계로 읽은 팀에서는 반대 결과가 나와도 이미 내보낸 것을 계속 키웁니다. 여섯 달 뒤에는 처음 3주와 같은 숫자를 보면서 기능만 열 개 늘어난 제품이 남습니다. 결과가 나쁘게 나온 실험을 접는 것은 실패가 아니라 그 실험이 제 몫을 한 것인데, 첫 출시라는 이름이 붙는 순간 접기가 어려워집니다.