네 가지 리스크

기획서를 놓고 도는 회의에서 가장 자주 나오는 질문은 오랫동안 하나였습니다. "이거 만들 수 있어요?" 개발팀이 된다고 하면 일정이 잡히고, 디자인이 화면을 그리고, 석 달 뒤에 기능이 나갔습니다. 그리고 한 달이 지나면 쓰는 사람이 전체의 2퍼센트라는 숫자가 돌아왔습니다.

회고에서 왜 아무도 몰랐느냐고 물으면 대답이 묘하게 다 맞았습니다. 개발은 만들 수 있다고 확인했고, 디자인은 화면이 막히지 않는지 봤고, 영업은 고객이 물어본 적이 있다고 했습니다. 각자 자기 앞의 질문에는 답을 했는데 "굳이 돈 내고 쓸 사람이 있나" 를 확인한 사람만 없었습니다. 다 같이 빠진 것이 없다고 믿은 이유는 확인 목록이 애초에 없었기 때문입니다.

네 가지 리스크는 그 목록을 네 칸으로 못 박은 것입니다. 새로운 조사 방법을 들여온 것이 아니라, 원래 하던 확인을 네 갈래로 이름 붙여 세워 둔 쪽에 가깝습니다. 칸이 생기고 나면 "이번에는 어디를 안 봤나" 라는 질문이 처음으로 대답 가능한 질문이 됩니다.

기능 하나를 놓고 서로 다른 질문 넷을 따로 던지고, 질문마다 답이 실제로 있는지 확인합니다. 하나라도 답이 비어 있으면 그 칸이 이번 기능의 약한 고리입니다.

1. 가치 리스크 — 사람들이 이걸 원하는가. 고객이 굳이 돈이나 시간을 들여 쓰지 않을 위험입니다. 쓰는 모습을 직접 보고 묻는 사용자 리서치로 확인하거나, 아직 만들지 않은 기능의 버튼만 먼저 달아 두고 누르는 사람 수를 셉니다.
2. 사용성 리스크 — 쓸 줄 아는가. 원하기는 하는데 화면 앞에서 막힐 위험입니다. 화면만 그려 둔 프로토타입을 다섯 명에게 주고 실제 과업을 시켜 보면 대개 막히는 지점 서넛이 같은 자리에서 나옵니다.
3. 실현 가능성 리스크 — 만들 수 있는가. 기술이나 일정으로 감당하지 못할 위험입니다. 개발자가 가장 의심스러운 조각 하나만 이틀 동안 먼저 만들어 보는 식으로 확인합니다.
4. 사업 타당성 리스크 — 회사가 감당할 만한가. 만들 수도 있고 고객도 원하는데 회사 쪽이 걸리는 위험입니다. 단가가 수익보다 높거나, 개인정보를 다루는 방식이 법규에 걸리거나, 영업팀이 기존 계약과 충돌해 팔 수 없는 경우입니다.

순서가 정해져 있지는 않지만 실무에서는 가치부터 봅니다. 나머지 셋은 가치가 있을 때만 값을 합니다. 쓰기 편하고 기술 난이도도 낮고 단가까지 맞는데 아무도 원하지 않는 기능은, 고칠 데가 없어서 쓰기 불편한 기능보다 손대기 어렵습니다.

확인 비용도 칸마다 다릅니다. 사용성은 다섯 명에게 하루면 답이 나오고 실현 가능성은 개발자 한 명의 이틀이면 윤곽이 잡히는데, 사업 타당성은 법무나 재무처럼 팀 밖 사람을 끌어들여야 해서 가장 늦게 붙습니다. 그래서 이 칸은 다 만든 뒤에 터지는 일이 잦고, 그때는 되돌릴 것이 많습니다.

가장 흔한 자리는 만들기로 결정하기 직전의 기획서 리뷰입니다. 네 칸을 그려 놓고 칸마다 "무엇으로 확인했는지" 를 한 줄씩 적게 하면 빈칸이 남은 기능은 그 자리에서 멈춥니다. 회의가 취향 다툼으로 흐르는 것도 막아 줍니다. 좋다 나쁘다가 아니라 어느 칸이 비었느냐로 말이 바뀌기 때문입니다.

확인하는 사람도 칸마다 다릅니다. 가치와 사업 타당성은 프로덕트 매니저가, 사용성은 디자이너가, 실현 가능성은 개발자가 끌고 가는 것이 보통입니다. 한 사람이 넷을 다 보겠다고 하면 대개 자기가 편한 칸만 깊게 보고 나머지는 형식으로 채웁니다.

가설을 적을 때도 이 네 칸이 기준이 됩니다. 어느 리스크를 줄이려는 실험인지 먼저 정하면 설계가 달라집니다. 가치를 보려면 관심 없는 사람을 모아 반응을 봐야 하고, 사용성을 보려면 이미 관심 있는 사람에게 과업을 시켜야 합니다.

늘 네 칸을 다 채울 이유는 없습니다. 버튼 문구를 바꾸는 정도의 되돌리기 쉬운 변경까지 네 칸을 돌리면 2주면 끝날 일이 6주가 됩니다. 되돌리기 어렵고 여러 팀이 걸리는 결정일수록 칸을 성실히 채웁니다.

"실현 가능성만 확인하신 거죠? 가치 리스크는 누가 봤어요?"

만들 수 있다는 것만 확인하고 원하는 사람이 있는지는 안 봤다는 지적입니다.

"사업 타당성 쪽이 제일 큰데 법무 검토를 아직 안 걸었어요."

기술이나 고객이 아니라 회사 내부 조건이 이번 기능의 약한 고리라는 뜻입니다.

"네 개 중에 사용성만 남았으니 프로토타입 다섯 명 돌리고 넘어가죠."

남은 칸이 하나뿐이고 그것도 가장 싸게 확인할 수 있으니 여기서 길게 끌지 말자는 제안입니다.

페이지덱에서는 분기 계획을 짜는 자리에서 이 네 칸이 표로 올라갑니다. 지현이 후보 기능마다 네 줄을 적어 오면, 태오가 실현 가능성 칸에 "이 부분은 외부 서비스 응답이 느려서 이틀 재 봐야 안다" 를 채우고, 민서가 사용성 칸에 지난주 프로토타입에서 세 명이 같은 버튼을 못 찾았다고 적습니다. 가치 칸이 비어 있는 기능은 그 회의에서 일정이 잡히지 않고 다음 주기로 넘어갑니다.

사업 타당성 칸은 규원이 직접 봅니다. 기업 고객용 기능이 기존 계약 조건과 부딪히지 않는지, 보관 기간을 늘리면 서버 비용이 요금제보다 커지지 않는지를 확인하고 나서야 채워집니다. 이 칸 때문에 멈춘 기능이 분기마다 한둘 나오는데, 다 만든 뒤에 멈추는 것보다 훨씬 쌉니다.

네 가지를 순서대로 한 번씩 통과하는 관문으로 읽는 경우가 가장 많습니다. 번호가 붙어 있고 넷이 나란히 놓여 있으니 1번부터 도장을 받아 4번까지 가는 그림이 자연스럽게 떠오릅니다. 실제로는 같은 주에 네 칸을 조금씩 채웠다가, 프로토타입 하나를 보여 주고 나면 가치 칸과 사용성 칸이 같이 흔들려 둘 다 다시 적는 식으로 돕니다. 관문으로 운영하면 가치 칸에 도장을 받느라 몇 주를 쓰는 동안 개발팀은 손을 놓고 기다리고, 뒤늦게 4번에서 걸리면 앞의 세 칸을 처음부터 다시 돌게 됩니다.

네 칸을 채운 것을 성공의 보증으로 읽는 것도 흔합니다. 이 틀이 하는 일은 실패 확률을 없애는 것이 아니라 아직 안 본 곳을 드러내는 것입니다. 네 칸을 다 채우고도 실패하는 기능은 있고, 다만 그때는 무엇을 잘못 봤는지가 기록으로 남습니다.