기능 우선순위 프레임워크 비교, 1인 프로젝트에 ICE·RICE·Kano 적용해보기

 

기능 우선순위를 정하는 방법은 예전부터 많이 읽어왔는데, 막상 혼자 작은 서비스를 만들어보려니 어디에 어떻게 써야 할지 감이 오지 않았어요.
읽을 때는 다 이해한 것 같은데, 내 기능 목록 앞에 앉으면 결국 "이것도 필요할 것 같고 저것도 필요할 것 같고"로 끝나더라고요.
그래서 이번에는 대표적인 세 가지 방법(ICE, RICE, Kano)을 같은 기능 목록에 하나씩 적용해보고, 어떤 차이가 나는지 정리해봤습니다.

 

예시로 쓸 서비스는 실제로 만들고 있는 것이 아니라, 연습을 위해 가정한 것입니다.
동네 독서모임 운영자가 모임 일정을 정할 때 단체 대화방에서 날짜를 일일이 묻는 게 번거롭다고 가정해볼게요.
그래서 일정 후보를 올리면 참석자들이 투표하고, 가장 많이 가능한 날짜가 자동으로 정리되는 작은 웹서비스를 만든다고 해봅니다.

기능 후보는 이렇게 여섯 개를 뽑았습니다.
일정 후보 투표, 투표 마감 알림, 모임 장소 지도 표시, 회비 정산 기능, 지난 모임 기록 남기기, 간편 로그인입니다.
혼자 만든다고 가정하면 한 달에 쓸 수 있는 시간이 한정되어 있어서, 여섯 개를 다 만들 수는 없고 앞의 두세 개만 고르는 상황입니다.

 

 

ICE, 가장 가볍게 점수 매기기

 

ICE는 Impact(영향), Confidence(확신), Ease(쉬움) 세 가지를 1~10점으로 매겨 곱하거나 평균을 내는 방법입니다.
장점은 정말 빠르다는 점이에요.
여섯 개 기능에 점수를 매기는 데 10분도 안 걸렸습니다.

예를 들어 일정 후보 투표는 영향 9, 확신 8, 쉬움 6이라고 적었습니다.
회비 정산은 영향은 7 정도로 봤지만 확신이 4였고, 구현도 어려워서 쉬움이 3이었어요.
곱해보니 투표가 432, 정산이 84로 차이가 크게 났습니다.

그런데 쓰다 보니 약점이 바로 보였습니다.
점수가 전부 제 느낌이라서, 마음속에 이미 정해둔 답이 있으면 그 답이 나오도록 숫자를 조금씩 올리게 되더라고요.
확신 점수를 매길 때 "이 정도면 7이지"라고 하면서 사실은 근거가 하나도 없는 경우가 많았습니다.

 

 

RICE, 도달 범위를 넣어 숫자를 붙들기

 

RICE는 Reach(도달), Impact, Confidence, Effort(노력)를 쓰고, (R × I × C) ÷ E로 계산하는 방법입니다.
ICE와 다른 점은 "몇 명에게 영향을 주는가"를 따로 떼어서 묻는다는 것, 그리고 노력을 사람/월 같은 단위로 적는다는 것이에요.

같은 가정으로 해보면 이런 식입니다.
모임 하나에 참석자가 평균 8명이라고 가정하면, 일정 투표는 모임마다 8명 모두에게 도달하고 지도 표시는 처음 오는 사람 정도에게만 도달합니다.
회비 정산은 회비를 걷는 모임에만 해당하니 도달 범위가 더 좁아져요.
이렇게 적고 나니 "나는 이 기능을 쓰는 사람이 정말 많다고 생각했나?"를 숫자로 되묻게 됩니다.

다만 이 숫자들도 결국 추정치입니다.
서비스를 아직 내놓지 않은 상태라 도달 범위의 근거가 없어서, 제가 아는 지인 모임 몇 곳을 떠올려 대충 잡은 숫자입니다.
그래서 RICE는 "정답을 내는 도구"라기보다 "내가 어떤 가정을 하고 있는지 드러내는 도구"에 가깝다고 느꼈어요.

 

 

Kano, 점수 대신 기능의 성격 나누기

 

Kano 모델은 점수를 매기는 방법이 아니라 기능을 성격별로 나누는 관점입니다.
없으면 화가 나는 기본 기능, 좋아질수록 만족이 늘어나는 성능 기능, 있으면 감동하지만 없어도 모르는 매력 기능, 있든 없든 상관없는 무관심 기능 등으로 나눕니다.

여섯 개를 이렇게 분류해보니 생각이 달라졌어요.
일정 투표는 기본 기능이라서 없으면 서비스가 성립하지 않습니다.
투표 마감 알림은 성능 기능에 가깝고, 지도 표시나 지난 모임 기록은 있으면 좋은 매력 기능으로 보였습니다.
간편 로그인은 사용자가 별로 칭찬하지 않지만 없으면 이탈할 것 같은 기본 기능이었고요.

ICE나 RICE로는 로그인 점수가 낮게 나왔는데, Kano로 보니 "점수는 낮아도 빼면 안 되는 기능"이라는 점이 드러났습니다.
점수 계산이 놓치는 부분을 Kano가 채워준다는 걸 이때 알았어요.
다만 Kano의 분류도 원래는 사용자에게 설문으로 물어서 정하는 게 정석이라, 혼자 분류하면 역시 제 추측입니다.

 

 

 

세 가지를 다 해보고 나서 가장 크게 느낀 건, 혼자 할 때는 설득할 상대가 없다는 점이 오히려 문제라는 거예요.
팀이라면 누군가 "이 점수는 왜 이래요?" 하고 물어서 근거를 말하게 되는데, 혼자서는 아무도 묻지 않으니 자기합리화가 너무 쉽습니다.
제가 만들고 싶은 기능(지도 표시가 괜히 재미있어 보였어요)에 점수를 넉넉하게 주고 있는 걸 몇 번이나 발견했습니다.

그래서 나름대로 몇 가지 장치를 만들어봤습니다.
점수를 매길 때 반드시 한 줄 근거를 같이 적고, 일주일 뒤에 다시 보면서 근거가 약한 점수는 낮춥니다.
그리고 "이 기능을 쓸 사람 한 명의 이름을 댈 수 있는가"를 물어봅니다.
이름이 안 떠오르면 확신 점수를 3 이하로 둡니다.

 

정리하면, 아이디어가 많고 빨리 걸러야 할 때는 ICE, 도달 범위를 따져볼 필요가 있을 때는 RICE, 기능의 성격을 이해하고 싶을 때는 Kano가 맞았습니다.
셋 중 하나만 쓰기보다는 ICE로 대충 거르고, Kano로 빼면 안 될 기능을 확인하는 식으로 섞어 쓰는 게 지금은 가장 현실적이었어요.

가장 중요한 건 프레임워크 자체보다, 점수 뒤에 적어둔 가정이라고 생각합니다.

나중에 서비스를 내놓고 나서 "그때 이렇게 가정했는데 틀렸네"를 확인할 수 있어야 우선순위가 학습으로 이어지니까요.
다음에는 같은 목록으로 실제 사용자 인터뷰를 해보고 점수가 얼마나 바뀌는지 비교해보고 싶습니다.