MLP

MVP, 즉 가설을 검증할 수 있는 최소한의 제품이라는 말이 널리 퍼지면서 뜻이 한쪽으로 기울었습니다. 원래 문장에는 최소라는 조건과 쓸 만하다는 조건이 같이 들어 있었는데, 실무에서는 앞의 조건만 남았습니다. 일정이 밀릴 때마다 "이건 MVP 니까" 라는 말이 붙었고, 그 말은 대개 덜 만들어도 된다는 뜻으로 쓰였습니다.

그렇게 내보낸 것들이 비슷한 결과를 냈습니다. 가입한 사람의 절반이 첫 화면에서 막히고, 저장 버튼이 어디 있는지 몰라 나가고, 오류가 나도 무엇이 잘못됐는지 알려 주지 않으니 다시 들어오지 않습니다. 2주 뒤 남은 사용자가 8퍼센트뿐인 결과를 놓고 팀은 회의를 엽니다.

여기서 답이 안 나옵니다. 사람들이 떠난 이유가 아이디어가 틀려서인지, 만든 것이 쓰기 불편해서인지 구분할 방법이 없기 때문입니다. 민서가 "이건 아이디어 문제가 아니라 저장이 안 된다는 걸 아무도 몰라서 그런 거예요" 라고 말하면 지현은 그 말이 맞는지 아닌지 판단할 근거가 없습니다. 배우려고 내보냈는데 정작 배운 것이 없는 상태가 됩니다.

MLP 는 그 지점에 대한 반응입니다. 만드는 양을 늘리자는 말이 아니라, 줄이는 방향을 바꾸자는 말입니다. 기능의 가짓수는 그대로 최소로 두되 남긴 하나는 사람이 기분 좋게 쓸 만큼 마무리하자는 제안입니다. 그래야 사용자가 떠났을 때 그것이 아이디어에 대한 대답이 됩니다.

줄이는 축을 둘로 나누는 데서 출발합니다. 하나는 기능의 가짓수이고 다른 하나는 각 기능의 완성도입니다. MVP 라는 말이 실무에서 두 축을 한꺼번에 내리는 쪽으로 쓰였다면, MLP 는 첫 번째 축만 내리고 두 번째 축은 지킵니다.

실제 작업은 네 단계로 돕니다.

1. 기능 목록을 한 줄로 줄입니다. 사용자가 이 제품을 쓰는 이유 하나를 고르고 나머지를 전부 뺍니다. 협업 문서 툴이라면 같이 쓰는 문서 하나를 만들고 편집하는 것까지만 남기고, 댓글과 검색과 권한 설정은 다음으로 미룹니다.
2. 남긴 하나가 걸리는 지점을 전부 찾아냅니다. 사용성 테스트, 즉 실제 사람에게 과업을 시켜 보며 막히는 자리를 보는 방법을 다섯 명에게 돌립니다. 같은 자리에서 세 명이 멈추면 그 자리가 고칠 목록에 오릅니다.
3. 처음 5분을 따로 다룹니다. 온보딩은 새 사용자가 제품에 자리 잡도록 돕는 과정인데, 기능이 하나뿐인 제품에서는 이 5분이 제품의 절반입니다. 빈 화면에 무엇을 하라고 적어 둘지, 첫 문서를 대신 만들어 줄지를 여기서 정합니다.
4. 실패하는 순간의 화면을 만듭니다. 저장이 안 될 때, 인터넷이 끊겼을 때, 권한이 없을 때 무엇이 보이는지를 정해 둡니다. 여기서 갈리는 인상이 가장 큽니다.

이 네 가지를 하는 데 드는 시간은 대개 2주에서 4주입니다. 그 시간을 확보하는 방법은 기간을 늘리는 것이 아니라 1번에서 더 자르는 것입니다. 4주가 없으면 기능을 하나 더 빼고 2주로 맞춥니다.

이 말이 실제로 힘을 쓰는 자리는 이미 비슷한 제품이 여럿 있는 시장입니다. 사용자가 처음 보는 종류의 제품이라면 조금 불편해도 궁금해서 써 보지만, 쓰던 것이 있는 사람은 새 제품이 한 번 거슬리면 그냥 원래 쓰던 것으로 돌아갑니다. 협업 문서 툴이 그런 시장입니다.

개인이 스스로 골라 쓰는 제품에서도 자주 나옵니다. 회사가 정해 준 도구는 불편해도 쓰지만, 개인이 고르는 제품은 첫인상에서 결정됩니다. 그래서 회사에 파는 제품보다 개인에게 파는 제품에서 이 기준이 더 자주 언급됩니다.

반대로 이 말이 어울리지 않는 자리도 분명합니다. 수요가 있는지조차 모르는 단계라면 완성도에 4주를 쓰기 전에 더 싼 방법으로 먼저 물어보는 쪽이 맞습니다. 소개 페이지만 띄워 신청 버튼이 눌리는지 보는 랜딩 페이지 MVP 같은 방법으로 일주일이면 알 수 있는 것을, 한 달 들여 잘 만든 뒤에 알게 되면 그 한 달이 통째로 낭비입니다.

파는 준비와도 구분해야 합니다. 옆에 있는 MMP는 돈을 받고 팔 수 있는 최소 구성을 가리키는데, 사랑받을 만한 완성도와 팔 수 있는 상태는 다른 목록입니다. 결제와 환불 처리, 문의 대응, 약관은 사용자가 감탄할 부분이 아니지만 값을 받으려면 없을 수 없습니다.

"이번 건 MVP 말고 MLP 로 갑시다. 기능은 하나만 하되 그 하나는 제대로요."

가짓수는 줄이고 마감은 올리자는 제안입니다.

"이대로 내면 사람들이 아이디어를 싫어한 건지 우리가 못 만든 건지 모르게 돼요."

완성도가 낮으면 실험 결과를 읽을 수 없다는 지적입니다.

"MLP 기준으로 보면 빈 화면이랑 오류 메시지가 아직 안 됐어요."

기능이 아니라 가장자리 상황이 남았다는 뜻입니다.

페이지덱이 문서 공유 기능을 처음 낼 때 이 말이 회의에 올라왔습니다. 초안에는 공유 링크, 권한 단계 네 가지, 만료 기간 설정, 공유 기록 보기가 들어 있었고 일정은 3주였습니다. 민서는 그 일정으로는 네 가지 중 무엇도 제대로 안 된다고 봤습니다.

그래서 권한을 보기와 편집 둘로 줄이고 나머지 두 가지를 다음으로 미룬 다음, 남은 시간을 링크를 받은 사람이 처음 보는 화면과 권한이 없을 때 뜨는 화면에 썼습니다. 지현은 이 결정을 기록해 두었습니다. 기능을 뺀 것이 아니라 뒤로 미룬 것이고, 미룬 이유가 시간이 아니라 순서였다는 것을 다음 분기에 다시 꺼내 보기 위해서입니다.

MLP 를 MVP 보다 크게 만들라는 말로 읽는 경우가 가장 많습니다. 사랑받을 만한 완성도라는 표현이 더 많은 것을 요구하는 것처럼 들리니 그렇게 읽힙니다. 실제로는 반대 방향입니다. 완성도에 쓸 시간을 만들려면 기능을 더 잘라야 하니, 제대로 한 MLP 는 같은 팀이 만든 MVP 보다 기능이 적습니다. 이 오해를 그대로 두면 일정이 두 배가 되고, 그러면 빨리 배우려고 시작한 일이 반년짜리 개발로 바뀝니다.

디자인을 예쁘게 하라는 말로 읽는 것도 흔합니다. 사랑이라는 단어가 취향처럼 들리기 때문입니다. 하지만 실제로 사람을 붙잡는 것은 화면의 색이 아니라 막히지 않는 경험입니다. 저장이 됐는지 알려 주는 표시, 실수를 되돌리는 방법, 오류가 났을 때 무엇을 하면 되는지 적힌 한 줄이 먼저입니다. 겉만 다듬고 이쪽을 비워 두면 첫인상만 좋고 둘째 날 이탈하는 제품이 나옵니다.