오즈의 마법사 MVP

자동으로 돌아가는 기능은 만드는 값이 비쌉니다. 올린 문서를 알아서 요약해 주는 기능 하나에도 처리 흐름을 짜고 품질을 다듬는 데 두 달이 듭니다. 문제는 두 달을 쓰고 내보낸 뒤 아무도 쓰지 않는 경우가 드물지 않다는 점입니다. 그때는 기능이 별로였는지 애초에 그런 걸 원하지 않았는지조차 구분이 안 됩니다.

그래서 만들기 전에 물어보는 방법을 썼는데 잘 듣지 않았습니다. "문서를 올리면 자동으로 요약해 주는 기능이 있으면 쓰시겠어요" 라고 물으면 열 명 중 아홉이 쓴다고 답합니다. 돈도 시간도 들지 않는 질문에 아니라고 답할 이유가 없습니다. 정작 내보내면 초대한 100명 중 3명만 한 번 써 보고 돌아오지 않습니다. 회의에서 이 간극은 늘 같은 말로 정리됐습니다. 쓸 것 같냐고 물으면 다들 쓴다고 하지만 그 답으로 두 달을 걸 수는 없습니다.

오즈의 마법사 MVP는 만드는 대신 흉내를 냅니다. 사용자가 보는 화면은 자동으로 도는 제품과 똑같이 만들어 두고 실제 처리는 뒤에서 사람이 손으로 합니다. 사용자는 자동화된 제품을 쓴다고 믿은 채 행동하고, 만드는 쪽은 그 행동을 코드 없이 관찰합니다. 이름은 커튼 뒤에서 장치를 조작해 거대한 마법사처럼 보이던 소설 속 인물에서 왔습니다.

무엇을 확인할지 한 문장으로 못 박고, 그것을 확인할 겉면만 만듭니다. 순서는 여섯 단계입니다.

1. 검증할 가설을 한 문장으로 적습니다. 가설은 참인지 거짓인지 가릴 수 있게 쓴 추측입니다. "회의록을 올려 요약을 받은 사용자는 다음 주에 다시 올린다" 처럼 재는 방법이 문장 안에 들어 있어야 합니다.
2. 사용자가 보는 겉면만 만듭니다. 업로드 화면, 처리 중 표시, 결과 화면 셋이면 대개 충분합니다. 프로토타입과 달리 이것은 실제로 동작합니다. 결과가 진짜 오고 사용자가 그 결과를 일에 씁니다.
3. 뒤에서 처리할 사람과 약속할 시간을 정합니다. 운영 시간을 평일 10시부터 19시로 잡고 응답을 30분 안으로 약속하는 식입니다. 사람이 붙는 사실을 알리지 않는 만큼 이 약속은 지켜야 합니다.
4. 처리하는 사람이 쓸 작업 화면을 따로 둡니다. 들어온 요청 목록과 결과를 써 넣는 입력창이면 됩니다. 이걸 건너뛰고 데이터베이스를 직접 고치면 실수가 사용자 화면에 그대로 보입니다.
5. 들어오는 양을 막아 둡니다. 하루 30건으로 상한을 걸고 얼리어답터 40명만 초대합니다. 얼리어답터는 덜 다듬어진 것을 먼저 써 보는 층입니다. 상한이 없으면 사람 손이 먼저 무너집니다.
6. 재는 값을 미리 정해 두고 기록합니다. 몇 명이 두 번 이상 요청했는지, 올린 문서가 어떤 종류였는지를 남깁니다. 리텐션처럼 다시 돌아오는지 보는 값이 답에 가장 가깝습니다.

만드는 값은 비싼데 수요가 불확실할 때 가장 잘 듣습니다. 두 달이 드는 기능을 2주짜리 흉내로 확인하면 틀렸을 때 잃는 것이 두 달에서 2주로 줄어듭니다. 결과물의 품질이 가설의 핵심일 때도 맞습니다. 요약이 쓸 만하기만 하면 계속 쓸지를 알고 싶은 상황이라면, 사람이 쓴 요약으로 그 질문에 먼저 답할 수 있습니다.

맞지 않는 자리도 분명합니다. 응답이 1초 안에 와야 하는 기능은 사람이 뒤에 앉아도 못 맞춥니다. 개인정보나 계약서처럼 남이 읽으면 안 되는 내용도 안 됩니다. 사람이 읽는다는 사실을 알리지 않고 들여다보는 것은 약관 위반이고 신고 사유입니다. 규모 확인에도 못 씁니다. 하루 30건이 잘 돌아간다고 하루 3만 건이 돌아가지는 않습니다.

한계는 사람 손에서 옵니다. 처리량이 늘면 비용도 같은 비율로 늘어나 어느 선에서 반드시 무너집니다. 그래서 기간을 미리 끊어 두고 시작합니다. 2주나 4주를 정해 그 안에 답이 나오면 만들고 안 나오면 접습니다.

같은 갈래의 다른 방식은 알려 주는 것이 다릅니다. 컨시어지 MVP는 사람이 서비스한다는 사실을 사용자가 알아서 대화가 많이 남고, 랜딩 페이지 MVP는 소개 페이지만 띄워 관심까지만 잽니다. 자동화된 제품을 실제로 쓸 때의 행동을 보고 싶으면 이 방식을 고릅니다.

"이 기능은 일단 오즈의 마법사로 2주만 돌려 보고 결정하죠."

만들기 전에 겉면만 띄워 반응을 확인하자는 제안입니다.

"오즈의 마법사인데 응답을 20분으로 약속해도 될까요? 새벽에 들어온 요청은요?"

사람이 붙는 방식이라 운영 시간과 응답 약속을 먼저 정해야 한다는 지적입니다.

"오즈의 마법사로 받은 만족도 점수는 그대로 못 씁니다. 사람이 쓴 결과라서요."

사람이 낸 품질을 자동화가 그대로 낼 수 없다는 경고입니다.

페이지덱은 문서 자동 요약 기능을 이렇게 확인했습니다. 지현이 업로드 화면과 요약 중 표시, 결과 화면만 만들어 두고 사용자 40명을 초대했습니다. 문서를 올리면 20분 뒤 알림이 가는데, 그 20분 동안 지현과 인턴이 읽고 요약을 써 넣었습니다. 태오는 이 기간에 요약 코드를 한 줄도 쓰지 않았습니다.

2주 뒤 남은 기록이 방향을 바꿨습니다. 40명 중 26명이 두 번 이상 올렸으니 수요는 확인됐는데, 올라온 문서 대부분이 회의록이었습니다. 모든 문서를 요약하겠다는 계획이 회의록에 맞춘 기능으로 좁혀졌고 만드는 기간도 두 달에서 3주로 줄었습니다.

코드를 쓰지 않으니 가장 싼 방법이라고 읽는 경우가 많습니다. 자동화를 만들지 않는다는 점만 보면 그렇게 보입니다. 그런데 겉면과 처리용 작업 화면은 만들어야 하고, 무엇보다 매 건마다 사람이 붙습니다. 하루 30건이면 한 사람의 하루이고 4주면 한 사람의 한 달입니다. 이걸 계산에 넣지 않고 시작한 팀은 2주짜리 실험이 6주로 늘어나는 동안 담당자가 지쳐 답이 나오기 전에 멈춥니다.

여기서 나온 숫자를 그대로 미래 지표로 읽는 것도 흔합니다. 사람이 시간을 들여 쓴 요약은 대개 자동화가 처음 내는 결과보다 좋습니다. 만족도 4.5점을 받아 두고 자동화 뒤에도 그 점수를 기대하면 출시 후 3점대를 보고 원인을 엉뚱한 곳에서 찾습니다. 이 방식이 답하는 것은 수요가 있는지까지이고, 품질 목표는 자동화 뒤에 다시 잡습니다.