프로토타입

만들 것을 글로만 합의하면 각자 다른 그림을 머리에 그린 채 회의가 끝납니다. 문서에 적힌 문장은 같은데, 기획한 사람은 오른쪽에 패널이 열리는 화면을 떠올리고 디자이너는 별도 페이지를 떠올리고 개발자는 목록 아래에 줄이 하나 붙는 모습을 떠올립니다. 셋 다 문서를 제대로 읽었는데도 그렇습니다. 글은 화면의 배치와 순서를 담지 못하기 때문입니다.

이 어긋남은 다 만든 뒤에야 드러납니다. 페이지덱에서 지현이 문서 안에서 곧바로 할 일을 만드는 기능을 요구사항 문서로 정리했고, 태오가 6주에 걸쳐 만들었습니다. 출시하고 2주 뒤에 확인한 숫자는 기능을 한 번이라도 쓴 사람이 전체의 7퍼센트였습니다. 무엇이 문제였는지 물어보니 답은 기능이 나쁘다는 쪽이 아니었습니다. 할 일을 만드는 버튼이 문서 맨 아래 도구 모음 안에 들어가 있어 아무도 그게 거기 있는 줄 몰랐던 겁니다. 배치 하나를 확인하는 데 6주와 개발자 한 명의 시간이 들어갔습니다.

고치는 값이 단계마다 뛴다는 점이 이 문제를 키웁니다. 종이에 그린 화면에서 버튼 자리를 옮기는 데는 5분이 들고, 디자인 파일에서는 반나절, 개발이 절반쯤 진행된 뒤에는 며칠이 듭니다. 이미 내보낸 뒤에는 시간 문제가 아니게 됩니다. 쓰던 사람들이 그 자리에 익숙해져 있어서 옮기는 것 자체가 새로운 불만을 만들고, 공지와 안내 문구를 따로 준비해야 합니다. 같은 결정을 언제 내리느냐에 따라 값이 백 배 넘게 벌어지는 셈입니다.

이 시간을 앞으로 당기려고 만든 것이 프로토타입입니다. 핵심은 안을 비워 두는 데 있습니다. 데이터베이스도 없고 저장도 안 되고 로그인도 안 되지만, 보는 사람 입장에서는 화면이 있고 눌리고 다음 화면으로 넘어갑니다. 사람이 헤매는지 아닌지를 확인하는 데는 그 정도면 충분합니다. 만드는 데 반나절이 걸리고 아니라는 답이 나오면 그대로 버립니다. 버리는 것이 아깝지 않은 정도로만 만든다는 점이 이 물건의 성격입니다.

제품 축에서 이 갈래가 따로 서 있는 이유도 같습니다. 완성품을 내기 전에 작게 만들어 보는 것이 넷 있는데, MVP는 실제 사용자에게 내보내 가설을 확인하는 최소한의 제품이고, 개념 증명은 기술적으로 가능한지만 작게 확인하는 시도이고, 파일럿은 다 만든 것을 고객 몇 곳에만 먼저 열어 운영해 보는 시험 도입입니다. 프로토타입은 넷 가운데 유일하게 안이 비어 있어도 되는 물건입니다.

이 이름 아래 묶인 용어는 한 갈래로 나뉩니다. 얼마나 진짜에 가깝게 만드느냐, 즉 충실도입니다. 넷이 있고 뒤로 갈수록 만드는 품과 확인할 수 있는 것이 함께 늘어납니다.

1. 페이퍼 프로토타입 — 종이에 손으로 그린 화면을 늘어놓고 손가락으로 눌러 가며 흐름을 확인합니다. 만드는 데 30분이면 되고, 그리는 사람이 옆에서 다음 장을 넘겨 줍니다. 순서가 말이 되는지, 단계가 너무 많지는 않은지를 보는 데 씁니다. 종이라는 점이 오히려 장점인데, 대충 그린 그림에는 사람들이 거리낌 없이 이상하다고 말합니다.
2. 로우 파이 프로토타입 — 색과 글꼴과 이미지를 생략하고 상자와 선으로 구조만 담습니다. 무엇이 어디에 놓이고 무엇이 더 커야 하는지를 봅니다. 와이어프레임과 생김새가 거의 같은데, 와이어프레임은 정지한 도면이고 이쪽은 눌러서 넘어갈 수 있다는 점이 다릅니다.
3. 클릭 더미 — 화면 전환만 진짜처럼 동작하는 껍데기입니다. 버튼을 누르면 다음 화면이 뜨지만 입력한 글자는 저장되지 않고 목록의 숫자는 늘 같습니다. 정해진 길로만 갈 수 있어서 시나리오 하나를 끝까지 따라가 보는 데 씁니다. 충실도의 축이라기보다 동작의 축을 가르는 말이라, 로우 파이로도 하이 파이로도 만들 수 있습니다.
4. 하이 파이 프로토타입 — 실제 화면과 구분이 잘 안 될 만큼 색과 문구와 간격까지 넣어 만듭니다. 만드는 데 하루에서 며칠이 걸리는 대신 문구가 헷갈리는지, 버튼이 눈에 띄는지처럼 겉모습에 달린 것까지 확인할 수 있습니다. 투자자나 고객사에 보여 주는 자리에도 이쪽을 씁니다.

어느 충실도를 고를지는 취향이 아니라 확인하려는 질문이 정합니다. 흐름이 말이 되는지 보려면 종이로 충분하고, 문구 세 개 가운데 어느 쪽이 덜 헷갈리는지 보려면 하이 파이여야 합니다. 질문보다 높은 충실도로 만들면 시간만 더 드는 게 아니라 답이 흐려집니다. 색까지 다 들어간 화면을 보여 주면 사람들은 순서가 이상하다는 말 대신 파란색이 낫겠다는 말을 합니다. 물어보려던 것이 순서였다면 그 회의는 헛돈 셈입니다.

순서는 대체로 낮은 쪽에서 높은 쪽으로 올라갑니다. 종이로 흐름을 정하고, 구조가 잡히면 로우 파이로 옮기고, 시나리오 하나를 끝까지 따라가 봐야 할 때 클릭 더미로 만들고, 문구와 색까지 정해야 하는 단계에서 하이 파이로 갑니다. 다만 매번 네 단계를 다 밟지는 않습니다. 이미 있는 화면에 버튼 하나를 더하는 일이라면 종이도 로우 파이도 건너뛰고 클릭 더미부터 시작하는 편이 빠릅니다. 단계를 다 밟느냐가 아니라 확인하려는 질문이 남아 있느냐가 기준입니다.

만드는 일 자체보다 무엇을 물을지 정하는 일이 앞섭니다. 이 화면에서 사람이 헤매지 않는지를 물을 것인지, 이 기능이 있으면 쓸 것인지를 물을 것인지에 따라 만들 화면 수가 달라집니다. 앞쪽은 화면 두어 개면 되고, 뒤쪽은 그 기능에 닿기까지의 경로 전체가 필요합니다. 질문을 안 정하고 만들면 대개 화면 수가 계속 늘어나고, 그러다 보면 확인해 보려던 시점보다 만드는 데 시간이 더 들어갑니다.

쓰이는 자리는 크게 셋입니다. 첫째는 사용자에게 보여 주고 지켜보는 자리입니다. 다섯 명쯤에게 같은 과제를 주고 어디서 멈추는지만 봐도 큰 문제는 대개 드러납니다. 둘째는 팀 안에서 같은 그림을 맞추는 자리로, 요구사항 문서에 화면 링크를 붙여 두면 앞서 말한 세 사람이 서로 다른 그림을 그리는 일이 줄어듭니다. 셋째는 닷새 안에 문제 정의부터 검증까지 끝내는 집중 워크숍인 디자인 스프린트입니다. 나흘째에 프로토타입을 만들고 닷새째에 사용자 다섯 명에게 보여 주는 것이 이 워크숍의 뼈대라, 여기서는 만드는 것 자체가 일정에 박혀 있습니다.

"이건 프로토타입이라 저장은 안 돼요. 눌러만 보세요."

화면은 진짜처럼 보이지만 안에서는 아무 일도 일어나지 않는다는 안내입니다.

"요구사항 문서 쓰기 전에 클릭 더미로 다섯 명만 돌려 보고 정하죠."

글로 합의하기 전에 실제 반응으로 방향을 먼저 좁히자는 제안입니다.

"여기서 하이 파이까지 갈 필요는 없어요. 순서만 보면 되니까 종이로 충분합니다."

확인하려는 질문에 비해 만드는 품이 과하다는 지적입니다.

앞서 7퍼센트가 나온 기능을 고칠 때 페이지덱은 순서를 뒤집었습니다. 민서가 하루 만에 클릭 더미를 만들었습니다. 버튼 위치만 바꾼 화면 세 벌이었고, 각각 도구 모음 안, 문장 옆에 뜨는 작은 표시, 문서 오른쪽 패널에 버튼을 두었습니다. 태오는 이 단계에서 아무것도 만들지 않았습니다.

지현이 사내에서 다섯 명을 불러 같은 과제를 줬습니다. 이 문단을 할 일로 만들어 보라는 과제였습니다. 도구 모음 안에 둔 화면에서는 다섯 명 가운데 넷이 버튼을 못 찾고 문서 위쪽을 헤맸고, 문장 옆에 표시를 띄운 화면에서는 다섯 명 모두가 3초 안에 찾았습니다. 오른쪽 패널은 찾기는 쉬웠지만 문서가 좁아진다는 말이 세 번 나왔습니다. 결정은 그 자리에서 났고, 태오가 다시 만든 기간은 나흘이었습니다. 6주를 들여 알아낸 것과 하루를 들여 알아낸 것이 같은 종류의 답이었습니다.

개발의 첫 버전이라고 보는 경우가 가장 많습니다. 화면이 있고 눌리니까 여기에 이어 붙이면 제품이 된다고 생각하기 쉽습니다. 실제로는 처음부터 버릴 것을 전제로 만든 물건입니다. 안에 로직이 없고, 데이터는 화면마다 손으로 적어 넣은 값이고, 예외 상황은 아예 없습니다. 이걸 그대로 제품 코드로 옮기면 임시로 얽어 둔 구조가 제품 한복판에 남고, 몇 달 뒤 그 부분만 손대기 어려워집니다. 도구도 다른 경우가 많아서 디자인 도구에서 만든 화면은 애초에 옮길 코드가 없습니다.

충실도가 높을수록 좋다고 보는 오해도 자주 나옵니다. 진짜에 가까울수록 반응도 정확할 것 같아서 그렇습니다. 그런데 완성도가 올라가면 두 가지가 같이 따라옵니다. 보는 사람은 구조 대신 색과 문구를 말하기 시작하고, 만든 사람은 이틀을 들인 화면을 버리기 아까워집니다. 두 번째가 더 나쁩니다. 고칠 수 있는 유일한 시점에 고치자는 말이 안 나오게 만들기 때문입니다. 종이에 그린 화면을 버리자는 말은 아무렇지 않게 나오지만, 며칠을 들인 화면 앞에서는 같은 말이 잘 안 나옵니다. 그래서 충실도는 답을 얻는 데 필요한 만큼만 올립니다.

높은 충실도가 바깥으로 나갈 때 생기는 문제도 있습니다. 실제 화면과 구분이 안 되는 화면을 고객사나 투자자에게 보여 주면 상대는 그것을 이미 있는 기능으로 받아들입니다. 영업 자리에서 한 번 보여 준 화면이 몇 주 뒤 계약 조건에 들어가 있는 일이 여기서 나옵니다. 보여 줄 때 이건 아직 안 만든 것이라고 한 문장을 붙이는 회사가 많은 것도 그래서입니다. 안쪽 회의에서는 굳이 말하지 않아도 되지만 밖으로 나가는 자리에서는 이 한 문장이 빠지면 나중에 되돌리기 어렵습니다.