제품을 기획할 때 가장 큰 고민 중 하나는 "어떤 기능을 먼저 개발해야 할까?"이다. 자원이 무한하다면 모든 아이디어를 다 시도해볼 수 있지만, 현실은 그렇지 않다.
따라서 PM과 팀원들은 제한된 리소스 안에서 최대 효과를 낼 수 있는 기능에 집중해야 한다.
이번 글에서는 현업에서 많이 쓰이는 기능 우선순위 설정 기법 5가지에 대해 알아보도록 하자.
🔹MoSCow 기법
MoSCoW 기법은 애자일에서 자주 사용되는 문제 우선순위 지정방법이다. 애자일 방식에 대한 자세한 설명은 이전에 포스팅 했던 프로젝트 관리 방법론을 참고하길 바란다.
⭐ MoSCow = Must have/Should have/Could have/Won't have
한 스프린트(또는 릴리스) 안에서 "무엇을 반드시 하고, 무엇을 미뤄도 되는가"를 팀이 한눈에 합의하도록 돕는 분류 기법이다.
MoSCoW는 숫자 점수 없이도 빠르게 협의가 가능하므로 직관적인 방법이다.
🔻 MoSCoW 요소
여기서 각각의 의미를 알아보자
- Must have: 절대적으로 출시해야만 하는 기본 기능
- Should have: 포함하는 것이 더 나을 것이지만, 그것들이 없어도 안되지는 않은 기능
- Could have: 항목을 포함하는 것이 좋지만, 성공에 필요하지는 않은 기능
- Won't have: 갖지 않아도 될 기능
이러한 구분을 통해 이해관계자와 불필요한 오해를 줄일 수 있으며, 팀과 경영진이 즉시 이해하고 실행으로 옮기기 좋다.
네 가지 버킷을 자세히 알아보자.
- Must have(이번 라운드에서 반드시 필요)
이번 목표 달성에 결핍 시 릴리스 불가, 법적/보안/리스크 관점에서 필수적이다.
→ 가드레일: 팀 총 용량의 50~60% 이내로 제한 - Should have(권장하지만 지연 가능성)
가치/리스크 면에서 중요하지만 Must만큼은 아님. 다음 패치로 미뤄도 제품 가치는 유지 - Could have(있으면 좋고, 실험/차별화)
여유가 있을 때 넣을 수 있는 기능. 고객 만족도 상승, 차별화에 포인트를 두고 있음
→ 가드레일: 10~20% 이하 배정. - Won't have(이번 라운드에서 하지 않음)
확실히 이번에는 하지 않음. 이유와 재검포 시점을 함께 기록
→ "Never"의 의미가 아닌 "Not now"이다. 재검토 일자 명시
🔻 MoSCoW 장단점
👍장점
- 직관적이고 간단함
: Must/Should/Could/Won't 분류만 있으면 누구나 이해할 수 있음- 스코프 관리에 탁월함
: 프로젝트 초기에 이번에 하지 않을 것을 명확히 함으로써 스코프 크리프를 방지한다.- 이해관계자 커뮤니케이션 강화
- 애자일/스프린트 계획과 궁합이 좋다.
⚠️단점
- 주관성이 강함
: Must/Should 판단이 데이터보다 사람의 의견에 좌우되기 쉽고, 팀마다 기준이 달라질 수 있음- Must 인플레이션 문제
: 모든 팀원이 자기 기능을 Must로 주장 → 결과적으로 Must가 너무 많아질 수 있음- 세부 우선순위 결정 어려움
: Must 안에서 "무엇부터 할까?"를 구체적으로 정하기 어려움
🔹 RICE 방법
RICE 방법은 우선 순위를 설정하기 위해 등급 점수 모델이라는 방법을 사용한다.
RICE = Reach x Impact x Confidence / Effort
제품의 새로운 아이디어나 기능을 얼마나 가칭 있는지와 얼마나 비용이 드는지를 수치로 비교해 우선순위를 정하는 프레임워크이다.
🔻 RICE 요소
1. Reach(도달 범위)
: 일정 기간 동안 기능이 영향을 주는 사용자나 거래 수
즉, 이 기능으로 인해 혜택이나 영향을 받는 사용자의 (추정)수를 나타낸다. 도달 범위가 넓을수록 기능의 영향력이 커진다. 도달 범위는 타겟 사용자의 규모 또는 여향을 받을 사용자 수와 같은 데이터를 사용하여 추정할 수 있다.
2. Impact(영향력)
: 기능이 사용자 경험이나 핵심 지표에 주는 효과
영향도 또는 영향력이라 불리는 Impact는 사용자 또는 비지니스에 미치는 영향의 정도를 나타낸다. 사용자 만족도, 사용자 참여도, 매출 증가 또는 비용 절감과 같은 요소가 포함될 수 있다. 영향도 점수를 부여할 때는 규모뿐만 아니라 지속 기간도 고려해야 한다.
점수화
- 3 = 엄청난 영향
- 2 = 큰 영향
- 1 = 중간
- 0.5 = 작은 영향
- 0.25 = 미미한 영향
3. Confidence(확신도)
: 위 추정치(Reach, Impact)가 얼마나 확실한가?
점수화 기준
- 100% = 확실한 데이터 기반
- 80% = 데이터 + 가설 혼합
- 50% = 아이디어 단계, 불확실
ex. 사용자 리서치와 일부 A/B 테스트 결과가 있다면 Confidence = 80%
4. Effort(노력)
: 기능 구현에 필요한 리소스 (보통 인주/인월 단위)
ex. 개발자 2명 + 디자이너 1명, 총 2주 → Effort = 6인주
→ 점수가 높을수록 "적은 노력으로 더 많은 사용자에게 더 큰 가치를 줄 수 있는 기능"이다.
🔻 RICE 장단점
👍장점
- 정량화된 비교 가능
: 감에 의존하지 않고 점수 기반으로 기능 비교 가능- 이해관계자 설득 효과적
: 정량적인 수치가 나오기 때문에 경영진과 팀원 설득이 쉽다.- 가치와 비용 균형
: Impact, Reach 같은 가치 요소와 Effort라는 비용 요소를 동시에 고려
⚠️단점
- 추정치의 불확실성
: Reach, Impact는 실제 데이터보다 가정에 의존하는 경우가 많음.- Effort 추정 어려움
: 개발 난이도 예측이 빗나가면 점수도 왜곡됨.- 숫자에 대한 과도한 신뢰
: 수치가 있어 보이지만 결국 추정치이다.- 고객 만족 요소 미반영
🔹 ICE
ICE 점수 기법은 "영향(Impact), 확신도(Confidence), 구현 용이성(Ease)" 세 가지 요소만으로 빠르게 점수를 매겨, 초기 단계에서 효율적으로 아이디어 우선순위를 정할 수 있는 방법이다.
ICE = Impact x Confidence x Ease
제품 기능이나 아이디어를 세 가지 요소로 점수화하여 우선순위를 정하는 프레임워크이다.
ICE 점수 기법은 RICE보다 계산이 단순해서 스타트업이나 초기 제품 단계에서 자주 사용된다.
🔻 ICE 요소
1. Impact(영향도)
: 기능이 사용자 경험, 핵심 지표, 비지니스 성과에 얼마나 큰 영향을 주는가?
- 점수화 기준: 보통 1~10점 척도
2. Confidence(확신도)
: Impact 평가가 얼마나 확실한가?
- 점수화 기준: 0~100% 혹은 1~10점
3. Ease(용이성)
: 해당 기능을 구현하는 것이 얼마나 쉬운가? (노력/리소스 반대로 생각)
- 점수화 기준: 1~10점 (높을수록 구현이 쉬움)
→ 점수가 높을수록 쉽게 구현하면서도 높은 가치를 줄 수 있는 기능, 단순 합이라 빠른 비교 가능
🔻 ICE 장단점
👍장점
- 간단함
: 계산이 직관적이고 빠름 → 초기 기획, 아이디어 필터링에 최적- Effort 대신 Ease 사용
: "쉬움"을 직접 반영해 직관적이다.- 빠른 합의 가능
: 정량적 데이터가 부족한 초기 단계에서 의사결정 도구로 유용함.
⚠️단점
- 주관성 강함
: 점수 매기는 기준이 팀마다 다름.- 데이터 기반 부족
: RICE처럼 Reach를 고려하지 않아 실제 시장 크기를 반영하기 어려움- 큰 프로젝트 구분 한계
: 전략적 가치나 장기적인 영향은 잘 반영되지 않음.
🔹 Kano 모델
kano 모델은 1980년대에 일본의 품질관리 학자 Noriaki Kano가 제안한 방법으로, 제품의 기능을 고객 만족도와 불만족도 관점에서 분류해 우선 순위를 정하는 프레임워크이다.
🔻 Kano 모델 요소
1. 필수 품질
: 고객이 기대하고 당연하게 여기는 요구사항이다.
잘 구현되면 고객은 그저 중립적인 태도를 취하지만, 제대로 구현되지 않으면 매우 불만족스러워 하는 요구사항으로 필수 요거(Must-be)라고 불린다.
2. 일차원적 품질
: 충족되면 만족을, 충족되지 않으면 불만족을 초래한다.
이러한 속성은 말로 표현되는 속성이며, 기업들이 경쟁하는 영역이기도 하다. 예를 들어, 같은 가격에 우유 함량이 10% 더 높다고 적힌 우유 포장은 고객 만족을 가져오지만, 6%만 들어 있다면 고객은 오해를 하고 불만족으로 이어진다.
3. 매력적인 품질
: 완전히 달성되었을 때 만족감을 주지만, 충족되지 않았을 때는 불만족을 유발하지 않는다.
일반적으로 기대되지 않는 속성으로, 예를 들어 우유 포장에 부착된 온도계가 우유의 온도를 표시하는 것과 같다. 이러한 유형의 품질은 예상치 못한 방식으로 고객을 기쁘게 하기 때문에 말로 표현되지 않을 때도 있다.
4. 무관심한 품질
: 좋거나 나쁘다고 할 수 없는 측면을 의미하며, 고객 만족이나 불만족으로 이어지지 않는다. 예를들어, 우유팩의 왁스 코팅 두께는 우유팩의 디자인과 제조에 중요한 요소일 수 있지만, 소비자는 그 차이를 인지하지 못한다. 제품에서 이러한 속성을 파악하여 억제하고 생산 비용을 절감하는 것이 유익하다.
5. 역품질
: 높은 수준의 성취로 인한 불만족과 모든 고객이 동일하지 않다는 사실을 나타낸다. 어떤 고객은 첨단 제품을 선호하는 반면, 어떤 고객은 제품의 기본 모델을 선호하며 제품에 너무 많은 추가 기능이 있으면 불만족하게 된다.
🔻 적용 방법
1. 기능 후보 수집
- 제품/서비스에서 고려 중인 모든 기능, 개선 아이디어, 요구사항을 정리한다.
- 로그인 방식, 배송 옵션, 추천 알고리즘, 다크모드, 푸시 알림 등
2. 고객 설문/인터뷰 설계
Kano 모델의 핵심은 “기능이 있을 때 vs 없을 때 고객 반응”을 묻는 것.
- 긍정 질문: “이 기능이 있으면 어떻게 느끼시나요?”
- 부정 질문: “이 기능이 없다면 어떻게 느끼시나요?”
- 답변 예시: 매우 좋다 / 좋다 / 상관없다 / 불편하다 / 매우 불편하다
3. 응답 분류 → Kano 요소 매핑
- 설문 응답 패턴에 따라 각 기능을 필수·일차원·매력·무관심·역품질 중 하나로 분류한다.
- 예시:
“로그인 기능 없음 → 매우 불편” → 필수 품질
“배송 속도 빨라짐 → 만족 / 느려짐 → 불만족” → 일차원적 품질
“앱 테마 자동 변경 → 만족 / 없어도 상관없음” → 매력적 품질
4. 우선순위 결정
- 필수 품질: 반드시 충족 (없으면 큰 불만)
- 일차원적 품질: 경쟁 우위를 위해 강화
- 매력적 품질: 전략적으로 일부 추가 → wow factor 확보
- 무관심/역품질: 자원 낭비/불편 초래 → 과감히 배제
5. 정기적 재평가
- 고객 기대치는 변한다.
- 과거엔 무료 배송이 “매력적 품질”이었지만, 지금은 “필수 품질”로 변함.
- 따라서 주기적으로 Kano 분석을 업데이트해야 한다.
🔻 Kano 모델 장단점
👍장점
- 고객중심
: 사용자 만족을 직접 반영해서 고객 경험 향상에 직결- 차별화 기회 포착
: 매력형 기능을 통해 경쟁사 대비 wow factor 제공- 불필요한 기능 제거
: 무관심형/역효과형 기능을 걸러내 효율적 자원 배분
⚠️단점
- 조사 비용
: 설문/인터뷰 등 고객 조사 과정이 필요하여 시간, 비용 소모- 분석 복잡성
: 응답 패턴을 해석해야 해서 단순 계산식보다 어려움- 시대/시장 변화 민감
🔹 Walking Skeleton
Walking Skeleton(워킹 스켈레톤)은 제품 개발 초기에 전체 시스템의 최소한의 뼈대를 먼저 구현하고, 이후 점진적으로 기능을 확장해 나가는 접근 방식이다.
Alistair Cockburn(애자일 방법론 전문가)이 제안한 개념으로, 제품의 End-to-End 플로우가 단순하게라도 "실제로 작동"하는 상태를 빠르게 확보하는 것을 목표로 한다.
🔻 Walking Skeleton 특징
1. 사용자 스토리에 초점을 맞춘 우선순위
- 단순히 기능 목록을 나열하는 것이 아니라, 가장 중요한 사용자 스토리를 중심으로 개발 순서를 정한다.
- “사용자가 상품을 검색하고 결제할 수 있다” → 이 스토리가 먼저 구현 대상
2. 핵심 기능이 완전히 동작해야 함
- 일부만 구현된 데모가 아니라, 주요 기능이 처음부터 끝까지 연결되어 동작하는 형태여야 한다.
- 회원가입 → 로그인 → 데이터 저장 → 화면 표시 → 로그 기록, 이 전체 플로우가 최소한으로라도 완성 필요
3. 비즈니스 가치를 보여주는 형태
- 기술적으로 제약이 있어도, 핵심 비즈니스 가치를 전달할 수 있는 뼈대를 보여줘야 한다.
- 스토리 맵을 정리하고, Deliver → Deploy까지 전체 과정을 포함한다.
따라서 Walking Skeleton에는 단순 기능 구현뿐 아니라 테스트와 배포 과정까지 포함된다.
🔻 Walking Skeleton 장단점
👍장점
- 리스크 조기 발견 가능
: 아키텍처, 시스템 통합 문제를 초기에 드러낼 수 있다.- 빠른 피드백
: 단순하지만 실제로 작동하는 제품을 보여주어 고객, 이해관계자의 피드백 확보 가능- 학습효과
: 팀이 도메인과 기술 스택을 빠르게 학습 가능- 비지니스 가치 중심 개발
: 핵심 사용자 스토리에 집중하므로 자원이 분산되지 않음
⚠️단점
- 완성도 부족
: 단순한 초기 버전이라 stakeholder에게 아직 부족하다는 인상을 줄 수 있음- 초기 준비 부담
: 뼈대를 잡는 과정에서 아키텍처, 테스트, 배포까지 신경써야 해서 시간이 필요하다.- 단기 PoC에는 비효율
: 한 번 보여주고 끝나는 실험 프로젝트에서는 굳이 불필요
👀 My thoughts
- 이번 글에서는 우리가 제품을 기획하거나 프로젝트를 진행할 때 활용할 수 있는 다양한 우선순위 결정 방법에 대해 살펴보았다.
생각해보면, 우선순위를 정하는 일은 장기 프로젝트에서 가장 중요한 과정 중 하나라고 할 수 있다. 프로젝트를 진행하다 보면 종종 방향성을 잃거나, 상대적으로 중요하지 않은 일에 시간을 과도하게 쓰게 되는 경우가 많다.
그렇기 때문에 우선순위를 명확히 결정하는 것이야말로 프로젝트 성공의 핵심이라는 생각이 들었다.- PM 공부를 하면서 흥미로웠던 점은, 우리가 프로젝트를 진행할 때 무의식적으로 해오던 판단들에도 사실은 이론적 기반과 체계적인 방법론이 존재한다는 것이었다. 실제 현업에서 엄청난 금액의 자금이 오가는 만큼 단순히 '중요하다/덜 중요하다/필요없다'로만 나누는 것이 아니라, 더 정교하고 구조화된 방식으로 우선순위를 설정하는 것이 정말 중요하다는 것을 깨달을 수 있었다.
