실현 가능성 리스크

만들기 전에 확인해야 할 것을 뭉뚱그려 리스크라고 부르던 시절이 있었습니다. 그러면 확인하는 방법을 고를 수 없습니다. 사람들이 쓸지 모르는 것과 우리가 만들 수 있는지 모르는 것은 확인하는 수단이 전혀 다르기 때문입니다.

그래서 만들기 전 위험을 네 갈래로 갈랐고, 그중 만들 수 있는지를 따로 떼어 낸 것이 이 말입니다. 회의에서 "이거 되나요" 라는 질문에 개발팀이 "해 봐야 압니다" 라고 답하고 넘어가는 자리가 바로 이 위험이 방치되는 지점입니다. 방치하면 대개 마지막 주에 드러납니다. 넉 달을 쓴 뒤에 알게 되는 사실을 첫 주에 알 수 있었던 경우가 많습니다.

이 위험은 답을 아는 사람이 개발팀 안에 있다는 점에서 다른 셋과 다릅니다. 고객에게 물어서는 알 수 없고, 만들 쪽에 물어야 합니다. 판단하는 순서는 셋입니다.

1. 무엇이 불확실한지 한 문장으로 좁힙니다. 결제 기능이 어려울 것 같다는 말은 확인할 수 없고, 외부 결제사가 정기 결제 실패를 어떤 형태로 알려 주는지 모른다는 말은 확인할 수 있습니다.
2. 크기를 매깁니다. 처음 쓰는 기술인지, 응답 속도나 정확도처럼 해 봐야 아는 값이 걸려 있는지, 우리 데이터 규모에서만 생기는 문제인지를 봅니다. 셋 중 둘 이상이면 큰 위험으로 다룹니다. 세 조건 모두 처음 해 보는 일이라는 공통점이 있습니다.
3. 가장 싼 방법으로 확인합니다. 하루면 문서를 읽어 답이 나오는 것도 있고, 2주를 들여 개념 증명으로 실제로 돌려 봐야 하는 것도 있습니다.

이 위험이 큰 항목은 계획 앞쪽에 둡니다. 뒤로 미루면 앞의 작업이 모두 그 결과에 얹혀 있어서, 안 된다는 답이 나올 때 버려야 하는 분량이 커집니다.

"이 건은 실현 가능성 리스크가 커요. 먼저 확인하고 일정 잡죠."

만들 수 있는지부터 확인한 다음에 약속하겠다는 뜻입니다.

"가치 리스크는 낮은데 실현 가능성이 걸립니다."

수요는 분명하지만 기술 쪽이 미지수라는 판단입니다.

"그건 실현 가능성이 아니라 사업 타당성 문제예요."

만들 수 있는지가 아니라 감당할 수 있는지의 문제라는 지적입니다.

페이지덱이 문서 안의 내용을 뜻으로 검색해 주는 기능을 검토할 때 이 판단이 앞에 왔습니다. 고객이 원한다는 것은 가치 리스크 쪽에서 이미 확인됐고, 화면도 단순해 사용성 리스크는 낮았습니다. 남은 것은 10만 건 규모에서 1초 안에 결과가 나오는지 하나였고, 태오가 2주를 써서 그것만 확인한 뒤에 분기 계획이 확정됐습니다.