🧩 PM으로 일하며 실제로 도움이 되었던 우선순위 정하기 기법들

👋 시작하며

서비스를 기획하다 보면 꼭 마주치는 순간이 있습니다.
기능 아이디어는 넘쳐나고, 모두 중요해 보이는데
막상 쓸 수 있는 리소스는 한정적일 때 말이죠.

특히 저처럼 TF 형태로 운영되는 조직에서
신규 서비스를 기획 중인 경우라면 더욱 그렇습니다.
정식 조직도 아니고, 인력도 넉넉하지 않다 보니
“무엇부터 해야 할까?”는 단순한 질문이 아니라,
전략의 시작점이 됩니다.

그래서 이번 글에서는
제가 실제로 참고해왔고 많은 도움이 되었던
좋은 PM이라면 꼭 알고 있어야 할 ‘우선순위 정하기 기법’들을 간단히 소개하고,

💬 TF 환경에서 어떤 방식이 효과적이었는지
기획자로서의 개인적인 경험과 함께 공유드리려 합니다.

 

---

 

📌 우리가 자주 듣고, 묻는 질문

“이 기능, 지금 꼭 넣어야 할까?”
“이건 지금이 아니라 다음에 해도 되지 않을까?”
“기획자로서 어디까지 결정하고, 어디서부터 조율해야 할까?”

여러 이해관계자들의 요청이 몰려들기 시작하면
이런 질문들이 머릿속에 차곡차곡 쌓이게 됩니다.
그리고 어느 순간, 기획의 중심이 흔들리기 시작하죠.

이럴 때일수록 중요한 건
‘판단의 기준’을 내 안에 갖고 있는 것이라고 생각합니다.

그 기준이 바로,
‘우선순위 정하기 기법’입니다.

 

---

 

🧭 1. MoSCoW 기법 – 나도 모르게 쓰고 있던 우선순위 기준

 

출처 : Freepik

 

✔️ Must / Should / Could / Won’t

MoSCoW는 기능을 네 가지 우선순위로 나눠 정리하는 방법입니다.

Must	이번 릴리즈에 반드시 포함돼야 하는 기능
Should	포함되면 좋지만 필수는 아닌 기능
Could	기회가 된다면 추가해도 좋은 기능
Won’t	이번에는 제외해도 무방한 기능

---

✍️ 현재 환경에서 어떻게 활용했나?

재미있게도 이 기법을 처음부터 알고 있었던 건 아닙니다.
신규 서비스의 기능을 정리하고 우선순위를 나누던 중,
“다른 조직은 어떻게 하지?” 하고 찾아보다가
MoSCoW 기법이라는 정리 방식을 알게 됐고,
그 내용이 제가 이미 사용하고 있던 기준과 거의 같았어요.

우리 팀도 당시 기능 리스트를 쭉 정리한 뒤,
"지금 이 기능이 빠지면 론칭이 가능한가?"라는 질문을 기준 삼아
Must 리스트만 따로 모아 MVP를 정의했거든요.

즉, MoSCoW라는 이름은 나중에 알았지만,
그 구조는 자연스럽게 실무에서 이미 활용하고 있었던 셈이었죠.

---

💡 이렇게 활용해보면 좋다고 생각했어요

• 빠르게 MVP를 정리해야 하는 초기 기획 단계
• 리소스가 부족한 TF 구조
• 복잡한 논의 없이 핵심 기능을 선별하고 싶은 상황

 

---

 

⚖️ 2. RICE 기법 – 정량화된 기준이 필요할 때

 

출처 : Google Image

 

✔️ Reach / Impact / Confidence / Effort

RICE는 각 기능이나 작업의 가치와 리소스 대비 효율을 정량적으로 평가할 수 있는 기법입니다.
각 항목에 점수를 매겨 RICE 점수를 계산하면, 우선순위를 보다 객관적으로 판단할 수 있다고 하네요.

Reach	얼마나 많은 사용자에게 영향을 줄 것인가
Impact	사용자 경험 또는 비즈니스에 얼마나 큰 임팩트를 줄 것인가
Confidence	이 추정치에 대한 확신은 얼마나 되는가
Effort	이를 구현하는 데 필요한 시간이나 리소스는 얼마나 드는가 (낮을수록 좋음)

• 공식 : RICE Score = (Reach × Impact × Confidence) / Effort

---

✍️ 현재 환경에서는 어떻게 생각했나?

솔직히 말하면, 저희 팀처럼 리소스가 제한적이고 일정이 타이트한 TF 환경에서는
RICE처럼 숫자를 하나하나 세팅해서 계산하는 건 실무에서 바로 적용하기엔 조금 무겁게 느껴졌어요.

하지만 중요한 기능 몇 가지를 놓고 우선순위가 헷갈릴 때,
각 항목에 대해 숫자가 아닌 상대적 평가 수준(높음/보통/낮음) 정도만 정리해봐도
결과적으로 “어디에 먼저 리소스를 써야 하는지”에 대한 논리적인 근거가 생기더라고요.

---

💡 이렇게 활용해보면 좋다고 생각했어요

• “이 기능이 정말 지금 필요한가?”라는 질문에 설득력 있는 근거가 필요할 때
• 팀 내에서 우선순위를 놓고 의견이 갈릴 때, 논의를 위한 프레임으로 활용
• 기획안을 설득하거나 리소스 요청 시 보다 논리적인 기준을 만들고 싶을 때

 

---

 

🦴 5. 워킹 스켈레톤 – ‘최소한의 구조’를 먼저 완성하기

출처 : famelee

✔️ 워킹 스켈레톤이란?

워킹 스켈레톤(Working Skeleton)은
전체 서비스의 기본 흐름을 최소한의 형태로 먼저 구현해보는 접근 방식입니다.
한마디로, 서비스의 '뼈대'를 빠르게 만들고, 그 위에 살을 붙여나가는 방식이죠.

핵심은 전체 사용자 여정을 먼저 설계하고,
각 구간에 기능을 얹어가는 형태로 기획을 진행한다는 점이에요.

이 방식은 단순히 UX 흐름만을 위한 것이 아니라,
기획, 디자인, 개발, QA 모두에게 초기 설계 기준점을 제공해준다는 데에 의미가 있어요.

---

✍️ 실제로 어떻게 활용했나?

제가 신규 서비스를 기획할 때,
수많은 기능 중 “무엇부터?”가 늘 고민이었거든요.

그래서 가장 먼저 했던 일은
“유저 여정을 기준으로 가장 기본적인 흐름을 먼저 그려보는 것이었습니다.
(관련 내용을 따로 포스팅해두었으니, 궁금하신 분들은 한 번 읽어보셔도 좋을 것 같아요)

예를 들어,

• 유저가 현장에 방문한다
• 위치를 인증한다
• 플레이를 한다
• 카드를 선택한다
• 수령한다

이런 핵심 흐름만 뽑아,
각 구간마다 최소 기능만 갖춘 화면을 먼저 설계하고 연결했습니다.
완벽한 기능은 아니지만, 서비스 전체를 이해하고 설계 논리를 맞춰가는 데 큰 도움이 되었어요.

---

💡 이렇게 활용해보면 좋다고 생각했어요

• 기능보다 흐름이 중요한 기획 단계에 있을 때
• 팀원 모두가 서비스 구조를 빠르게 이해해야 할 때
• ‘작게 만들고 빠르게 검증하고 싶은 팀’에서

워킹 스켈레톤은 좋은 출발점이 될 수 있다고 생각해요. 

 

---

 

❄️ 4. ICE 기법 – 직관을 구조화할 때

출처 : lineardesign

 

✔️ Impact / Confidence / Ease

ICE는 ‘빠르게 판단해야 하는 상황’에서 직관에 구조를 더해주는 기법입니다.
각 항목을 1~10점 스케일로 간단히 평가하고, 곱해서 우선순위를 도출해요.

Impact	해당 작업이 미치는 영향력은 얼마나 큰가?
Confidence	이 판단에 대한 신뢰도는 얼마나 되는가?
Ease	구현 또는 실행이 얼마나 쉬운가?

 

공식 : ICE Score = Impact × Confidence × Ease

---

✍️ 현재 환경에서는 어떻게 생각했나?

RICE보다 더 간단해서, 저희처럼 빠르게 움직여야 하는 환경에서는
우선순위를 빠르게 비교해보기 딱 좋은 구조라고 생각했어요.

특히, 막상 수치를 정확히 매기기 어려운 상황에서도
“이건 영향은 크지만 구현은 까다로워” 같은 식으로
가볍게 이야기하면서 팀원들과 의견을 나눌 수 있잖아요.

예를 들어, 제가 최근 기획 중인 화면 설계에서
‘CS 메일 노출 위치’와 ‘신규 기능 추가’ 요청이 동시에 있었을 때,
ICE 기법을 기반으로 생각해보니 의외로 작은 개선이 더 임팩트가 크다는 결론이 나오기도 했습니다.

---

💡 이렇게 활용해보면 좋다고 생각했어요

• 수치를 매기기 어려운 상황이나, 수치보단 감각적 판단이 우선인 단계에서
• “뭔가 중요한 것 같은데 뭐부터 하지?” 싶을 때
• 빠르게 비교·설득이 필요할 때 (ex. 스프린트 내 우선 작업 조율 등)

 

---

 

🌈 5. Kano 모델 – ‘고객 경험’ 관점에서 우선순위 판단하기

출처 : FineBI

 

✔️ 기본적 / 성능형 / 매력적 / 무관심 / 반감형 요소로 나누기

Kano 모델은 기능의 ‘고객 만족도’에 초점을 맞춥니다.
모든 기능이 사용자에게 같은 가치를 주는 건 아니니까요.

기본적 요소	없으면 불만, 있어도 티 안 남 (ex. 로그인 기능)
성능형 요소	있으면 만족, 없으면 불만 (ex. 속도, 정확도, 효율성 등)
매력적 요소	없으면 괜찮지만 있으면 WOW! (ex. 개인화 추천, 자동저장 등)
무관심 요소	있어도 없어도 상관 없음
반감형 요소	있으면 오히려 불편함 (ex. 과도한 알림, 복잡한 절차 등)

 

---

✍️ 현재 환경에서는 어떻게 생각했나?

Kano 모델은 단기 성과보다는 사용자 만족과 장기 가치를 중심으로 판단할 때 유용하다고 생각했어요.

저희 서비스처럼 초기 사용자 경험 설계가 중요한 단계에서는
모든 기능이 MVP에 들어갈 필요는 없고,
오히려 '기본적 요소'를 안정적으로 채우는 게 우선이라는 기준을 세울 수 있었어요.

예를 들어, 저희가 설계 중이던 포토카드 발급 화면에서
개인화된 문구 출력(매력적 요소)보다
‘카드를 선택하는 시점에 대한 안내’(기본적 요소)가 더 중요하다는 걸 확인하기도 했습니다.

---

💡 이렇게 활용해보면 좋다고 생각했어요

• 사용자 경험 중심의 기획을 하고 있을 때
• “이건 기능으로서 어떤 역할을 할까?”를 고민하고 싶을 때
• 개발 리소스를 ‘기대효과’가 아니라 ‘사용자 기대’ 기준으로 나누고 싶을 때

 

---

 

✅ 마무리하며 – 우선순위 판단, ‘기법’보다 중요한 건 ‘기준’입니다

서비스 기획자라면, PM이라면 누구나 경험해봤을 거예요.
무한한 아이디어와 제한된 리소스 사이에서,
무엇을 먼저 해야 할지 결정해야 하는 그 순간들을요.

오늘 공유한 MoSCoW, RICE, ICE, 그리고 Kano 모델은
그런 순간에 기획자에게 기준을 만들어주는 도구입니다.

하지만 중요한 건 ‘이 중에 어떤 기법이 최고냐’가 아니라
‘우리 팀과 나의 현재 상황에 가장 적합한 기준이 무엇이냐’라는 점이라는 걸 느꼈네요

 

🔍 저처럼  제한된 리소스 환경에서 신규 서비스를 기획하는 입장이라면…

• ✅ 빠른 MVP 판단이 필요할 땐 MoSCoW
• ✅ 팀 내부 설득과 논리가 필요할 땐 RICE
• ✅ 직관적인 비교가 우선일 땐 ICE
• ✅ 고객 경험이 핵심이라면 Kano 모델

이렇게 목적과 상황에 따라 가볍게 조합해서 쓰는 것도
충분히 좋은 전략이라는 생각이 들었습니다.

---

우선순위를 정한다는 건 결국 결정을 만드는 일이고,
그 결정이 모여 제품의 방향을 만들잖아요.

복잡한 상황에서 PM으로서 흔들리지 않으려면,
“어디에 먼저 리소스를 써야 할지”에 대한 나만의 기준부터 갖춰보는 것이 좋지 않을까요?

오늘 소개한 기법들이 그 기준을 만드는 데
작게나마 도움이 되었기를 바랍니다 :)