기획자가 알면 좋은 ‘우선순위 설정 프레임워크’

“하고 싶은 것은 많지만 늘 시간은 부족하다”

고객이 원하는 제품, 혹은 조직이 원하는 제품을 만들기 위해서는 기획부터 개발까지 수많은 사람의 노력이 필요하다. 모든 업무에 여유롭게 시간과 인력을 투자해 개발하고 싶지만, 대부분의 회사가 여유롭게 자원을 투자하기는 어렵다. 특히 스타트업이라면 당장 내일의 생존을 걱정해야 하는 경우가 많으며, 해야 할 일이 산더미지만 정작 업무를 진행할 리소스가 항상 부족한 게 현실이다.

그렇다면 스타트업에서 기획자는 단순히 고객 문제를 해결할 수 있는 기능을 고민하고 매번 새로운 기능 구현에만 몰두하는 게 맞을까? 그럴 수만 있으면 좋겠지만, 현실은 그렇지 않을 때가 대부분이다. 그래서 보통 스타트업의 기획자는 제품이 나아가고자 하는 방향과 고객이 느끼는 문제 등을 복합적으로 고려해 당장 우리 제품에 필요한 업무부터 선정해서 진행하는 능력을 갖춰야 한다. 이번 글에서는 업무 우선순위를 설정하는 방법과 이를 도와주는 좋은 프레임워크를 알아보겠다.

우선순위 설정이 왜 중요할까?

우선순위 설정이 왜 중요할까? 단순히 우리가 해야 할 일을 ‘백로그(Backlog, 개발해야 할 기능과 우선순위)’에 나열하고 순서대로 진행하는 것은 안 되는 것인가? 사실 앞서 이야기한 것처럼 인력과 시간이 차고 넘친다면 굳이 우선순위 설정이 크게 중요하지 않을 수도 있다.

다만 우리는 항상 시간과 인력이 제한적이고 업무에 투자할 리소스가 부족한 게 현실이다. 그렇기에 모든 아이디어와 의견들을 받아들여 우선순위 구분 없이 업무를 진행하는 것은 자원이 한정된 스타트업에서 위험한 업무 방식으로 작용될 수 있다.

즉, 부족한 리소스를 효율적으로 활용할 수 있도록 제품이 빠르게 시장에서 성장할 수 있고 생존할 수 있는 방법에 '선택과 집중'이 필요하다. 이를 통해 기획자는 여러 스토리의 우선순위를 결정하여 가장 중요한 것을 먼저 개발할 수 있어야 한다.

하지만 기획자가 리소스 투자 대비 효과, 개발 공수, 제품 방향성 등 여러 조건을 고려하여 우선순위를 설정하는 것이 말처럼 쉽지 않다. 누군가에게는 우선순위가 높은 업무일 수 있지만, 다른 구성원은 그렇게 생각하지 않는 경우도 있기 때문이다. 이때 객관적으로 우선순위 설정을 도와주는 프레임워크를 사용하면 구성원 간 이견 조율에 도움이 된다.

1. MoSCoW 프레임워크

MoSCoW는 백로그에 존재하는 업무를 네 가지로 구분하여 판단하는 매우 간단한 방법이다. 이는 단순히 업무에 관한 중요성을 직관적으로 구분하여 우선순위를 판별하는 방법으로, 별도 계산 공식 없이 빠르게 적용해볼 수 있다.

• Must have: 서비스 운영에서 이 기능을 빼고는 온전한 서비스라고 생각하기 어려운 기준을 말한다. 백로그 중에서 서비스 자체에 치명적인 영향을 끼치거나 시급성이 높아서 반드시 해결해야 할 기능을 뜻한다.
• Should have: 서비스를 운영할 때 당장 적용하지 않아도 서비스에 영향이 없는 기능 중 우선순위가 높은 기준이다. 해결할 필요성은 분명히 있지만, Must have에 비해 보통 시급성이 낮은 기능들을 말한다.
• Could have: 서비스를 운영할 때 전혀 영향이 없는 기능 중 우선순위가 낮은 기준이다. 만약 팀에 가용 가능한 리소스가 존재하고, 시간적 여유가 있을 때 개선해서 서비스를 더 좋게 만들 수 있는 기준을 말한다. 흔히 ‘있으면 좋고, 없어도 상관없는’ 기준으로 정리되곤 한다.
• Won’t have: 서비스를 운영하는 데 있어서 전혀 영향이 없으며, 우선순위가 가장 낮은 기준을 말한다. 중요도도 떨어지고, 적용했을 때 효과도 아주 미미한 수준의 기능을 말한다.

MoSCoW 장점

이 방법의 장점은 앞서 이야기한 것처럼 별도 계산 공식 필요 없이 백로그에 있는 업무를 4가지 기준에 따라 팀원과 중요도를 매우 빠르게 판단 및 설정할 수 있다. 또한 워낙 유명하고 자주 쓰이는 우선순위 설정 방법이라서 유용한 템플릿이 많기에 활용할 수 있는 범위 역시 매우 넓다.

MoSCoW 단점

MoSCoW의 단점은 빠르고 간단하게 설정할 수 있는 만큼 중요도를 판단하기 비교적 어렵다는 것이다. 구분 조건이 네 가지만 존재하여 제품에 관한 우선순위를 설정할 때 판단할 수 있는 조건이 많지 않다. 그래서 다른 우선순위 방법인 ‘Rice’나 ‘Kano’보다는 객관적인 판단 가능성이 떨어진다.

활용 방법

MoSCoW는 단 네 가지 기준으로만 우선순위를 구별하는 것이 장점이자 단점이다. 그래서 사전에 팀 내에서 사전에 M, S, C, W 등 선정 조건을 부여하여 개발 우선순위를 설정할 수 있다.

예를 들어 ‘개발 공수 높은 작업 = 3’, ‘개발 공수가 낮은 작업 = 2’, ‘개발 공수가 쉽고 빠르게 구현되어야 하는 작업 = 1’ 등으로 세부 항목을 추가하여 조건마다 포인트를 부여하고 점수에 따라 M, S, C, W 선정하면 그나마 객관적인 우선순위 설정이 가능하다.

2. Rice 프레임워크

Rice는 단어 뜻 그대로 진행해야 할 업무에 네 가지 항목을 적용하여 점수를 도출하고 우선순위를 설정하는 방식이다. 네 가지 항목은 ‘Reach’, ‘Impact’, ‘Confidence’, ‘Effort’이며, 이름인 ‘Rice’는 해당 단어들의 앞 글자를 따서 만들어졌다.

Rice는 앞서 설명한 MoSCoW보다 세부적인 설정 영역이 존재하기에 보편적으로 많이 사용된다.

• Reach: 얼마나 많은 수의 사용자에게 도달하며, 그들에게 영향이 미치는지에 대한 기준으로, 백로그를 통해 개발될 기능이 특정 기간 동안에 얼마나 많은 사용자가 사용할 수 있는지를 말한다. 서비스의 실질적인 지표인 일별 활성 사용자(DAU, Daily Active Users)나 월별 활성 사용자(MAU, Monthly Active Users) 같은 수치로 평가할 수 있다.
• Impact: 도달하게 될 사용자들이 해당 기능을 사용할 때 얼마나 큰 영향을 받게 되는지에 대한 기준을 말한다. Impact는 측정하기에 따라 매우 다르고, 명확한 기준을 수립할 수 없다. 다만 그 영향의 척도를 5단계 정도로 구분해서 상대적인 점수를 부여하는 것이 일반적이다. 예를 들어, ‘효과가 매우 큼’은 3점, ‘효과가 큼’은 2점, ‘효과가 중간’은 1점, ‘효과가 낮음’은 0.5점, ‘효과가 매우 낮음’은 0.25점을 주는 식으로 평가할 수 있다.
• Confidence: 개발하게 될 기능이 성공할지에 대해 얼마나 확신을 가지는지에 대한 기준을 뜻한다. PM/PO 또는 서비스 기획자로서 만들게 될 기능이 사용자에게 얼마나 만족스러운 가치를 전달하는지에 관한 사항이다. 크게 3단계로 구분해서 점수를 적용하며, ‘높은 신뢰도’의 경우 100%, ‘중간 신뢰도’의 경우 80%, ‘낮은 신뢰도’의 경우 50%를 적용해서 평가할 수 있다.
• Effort: 백로그를 개발하는 과정에서 시간이나 인력이 얼마나 소요되는지에 대한 기준을 말한다. 시간이나 인력 소요를 토대로 평가할 수도 있으나 계산이 용이하도록 보통 4단계 점수로 적용하는 편이다. ‘매우 큰 수준의 노력’은 4점, ‘큰 수준의 노력’은 3점, ‘중간 수준의 노력’은 2점, ‘적은 수준의 노력’은 1점을 적용해 평가한다.

Rice 장점

Rice는 보다 제품 관점에서 우선순위를 디테일하게 선정할 수 있는 것이 장점이다. 제품을 크게 네 가지 영역으로 지표화하여 총합을 산출한 뒤에 우선순위를 설정하기 때문에 비교적 정확하고 논리적으로 순서를 정할 수 있다.

Rice 단점

MoSCoW에 비해 영역마다 계산 공식이 존재하기에 빠르게 판단할 때 번거로울 수 있다. 또한 네 가지 평가 지표 중 기능에 관한 성공 확신 여부를 평가하는 ‘Confidence 영역’은 보통 PM이나 PO, 기획자가 주관적으로 판단하기 때문에 다소 편파적으로 측정될 위험이 있다.

활용 방법(계산 공식)

Rice의 계산 공식은 생각보다 간단하다. 백로그에 존재하는 업무를 네 가지 포인트로 수치화하여 위 사진처럼 계산 공식에 적용하면 된다.

Reach 계산 공식

• Project 1: 매달 500명의 고객이 가입 기간 중 이 시점에 도달하여 30%가 이 옵션을 선택합니다. 분기당 고객 수는 500 × 30% × 3 = 450명입니다
• Project 2: 분기마다 이 기능을 사용하는 모든 고객은 이 변경 사항을 확인할 수 있습니다. 분기마다 2,000명의 고객을 확보할 수 있습니다.
• Project 3: 이 기능은 800명의 기존 고객에게 일회성 영향을 미치지만 지속적인 영향은 없습니다. 분기당 800명의 고객을 확보할 수 있습니다.

Impact 계산 공식

• 매우 강력하다 = 3
• 높다 = 2
• 보통 = 1
• 작은 = 0.5x
• 최소한의 = 0.25x

Confidence 계산 공식

• 신뢰도 높음: 100%
• 신뢰도 중간: 80%
• 신뢰도 낮음: 50%

※ Confidence는 매우 객관적인 평가가 필요

Effort 계산 공식

개발 공수 기간 포인트화(단순 개발 공수 시간뿐만 아니라 설계부터 엔지니어링 소요 시간까지 검토하는 것을 권장)

(ex) 해당 작업에 약 1주일간의 계획, 1~2주간의 설계, 2~4주의 엔지니어링 시간 소요 = 2점

※ Effort 포인트 규칙은 조직에 따라 유동적으로 변경하는 걸 권장

위처럼 각 요소마다 계산하는 공식이 존재하고, 이를 토대로 점수를 계산해 우선순위 설정하면 된다. 단순히 기능에 대한 예상 가치와 Impact만을 고려하여 우선순위를 선정하지 않고, Effort를 통해 엔지니어의 공수까지 고려하여 우선순위를 설정할 수 있기에 팀 내 가장 이상적인 합의를 하는 프레임워크가 될 수 있다.

다만 Rice는 아직 출시하지 않은 제품에는 적용하기가 어렵다. 이유는 Reach나 Effort가 실제 제품 내에서 어느 정도 경험과 데이터가 존재해야 판단할 수 있는 영역이기 때문이다. 따라서 제품 없이 아무 경험과 데이터가 없으면 판단이 어려운 지표이다.

우선순위를 통해 얻게 될 가치

우선순위를 설정하는 프레임워크는 정말 다양하다. 하지만 이번 글에서는 ‘MoSCoW’와 ‘Rice’ 등 두 가지 방법만을 소개했다. 이유는 가장 보편적인 프레임워크로 실무에서 가장 많이 사용되고 있기 때문이다. 따라서 기획자로서 알고 있으면 우선순위 설정에 매우 유용하게 사용될 것으로 기대하고 소개했다.

사실 우선순위를 설정하는 방법은 명확한 정답이 존재하지 않는다. 대표적인 프레임워크가 존재하긴 해도 조직마다 사용하는 방법이 조금씩 다르고 기업 문화나 특징에 따라 아예 다른 방법으로 사용되는 경우도 존재한다. 그렇기에 가장 중요한 것은 ‘어떤 프레임워크를 사용할 것인가?’가 아닌 ‘백로그에 있는 업무 중 어떤 것이 우리 제품에 최소한의 리소스로 최대 효과를 낼 수 있느냐?’에 관한 정답을 끌어 내는 것이다.

팀 모두가 제품이 나아가고자 하는 방향을 토대로 객관적인 우선순위 설정을 통해 업무를 진행하면 그 어느 기업보다 빠르게 성장할 수 있는 가능성이 존재한다. 시간과 인력은 유한하지 않고 항상 부족한 것이 현실이다. 뛰어난 기획자는 제품 방향성을 토대로 선택과 집중을 통해 리소스를 최대한 활용하여 최고의 결과물을 창출하는 사람이란 걸 잊지 말자.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.