모든 것이 급해 보일 때 기능 우선순위를 정하는 법
← 전체 글 올바른 것을 만들기

모든 것이 급해 보일 때 기능 우선순위를 정하는 법

FabricLoop 팀 · 2026년 5월 · 6분 읽기

대부분의 제품 팀에서 백로그는 긴급함이 사라져 가는 곳입니다. 백로그에 들어온 모든 항목은 추가될 당시에는 급한 일이었습니다. 고객 불만, 영업팀의 요청, 경쟁사의 기능, 내부 아이디어 같은 것들이죠. 여섯 달이 지나도 전부 그대로 남아 있고, 여전히 모두 급해 보이며, 무엇부터 해야 할지 아무도 확실히 알지 못합니다.

문제는 도구가 부족하다는 것이 아닙니다. RICE, MoSCoW, 카노(Kano), ICE, 가중치 점수제 등 우선순위 프레임워크는 수십 가지나 됩니다. 문제는 대부분의 프레임워크가 일종의 거짓 정밀성, 즉 알 수 없는 것에 숫자를 매기는 일을 요구한다는 점입니다. 그래서 엄밀해 보이지만, 실제로는 직감을 스프레드시트에 통과시켜 그럴듯하게 포장하는 데 그칩니다.

실제로 효과가 있는 방법은 더 단순합니다. 두 가지 기준을 솔직하게 평가하고, 그 결과대로 실행하는 원칙입니다.

정말 중요한 기준은 단 두 가지

우선순위 정하기는 결국 두 가지 질문으로 압축됩니다. 첫째, 이 일이 우리가 중시하는 성과를 얼마나 개선하는가? (임팩트) 둘째, 이를 실현하는 데 비용이 얼마나 드는가? (공수) 나머지는 이 둘을 다듬는 것이거나 이 둘에서 주의를 흩뜨리는 것입니다.

확신도를 세 번째 기준으로 더하기도 합니다. "임팩트를 얼마나 확신하는가?"라는 질문이며, 염두에 둘 만합니다. 하지만 실제로 대부분의 팀은 자신이 추측하고 있을 때를 압니다. 중요한 것은 추측을 1~5점으로 점수화해 공식에 넣는 것이 아니라, 추측임을 솔직하게 표시하는 습관입니다.

임팩트 대 공수 우선순위 매트릭스
← 낮은 임팩트 · 높은 임팩트 →
낮은 공수높은 공수
높은 임팩트 · 낮은 공수
퀵 윈
가장 먼저 하세요. 비용 대비 가치가 압도적으로 큽니다. 너무 고민하지 말고 바로 출시하세요.
높은 임팩트 · 높은 공수
빅 베팅
해볼 만한 가치가 있지만 신중히 계획하세요. 가능하면 더 작은 단위로 나누고, 본격적으로 투자하기 전에 가설부터 검증하세요.
낮은 임팩트 · 낮은 공수
자투리 작업
여유 역량이 있을 때 하세요. 퀵 윈을 밀어내거나 빅 베팅을 지연시키지 않도록 주의하세요.
낮은 임팩트 · 높은 공수
시간 먹는 하마
과감히 거절하세요. 그에 걸맞은 성과 없이 역량만 소모합니다. 검토 대상에서 철저히 제외하세요.

어려운 부분은 매트릭스를 이해하는 것이 아니라, 채워 넣을 때 솔직해지는 것입니다. 어느 팀이나 "시간 먹는 하마"에 속하는데도 계속 "빅 베팅"으로 재분류되는, 만들고 싶은 기능이 있습니다. 이 프레임워크는 팀이 임팩트에 대해 솔직할 수 있을 때만 작동합니다.

거짓 정밀성 없이 임팩트 평가하기

임팩트는 팀이 평가하기 가장 어려워하는 기준입니다. 미래를 예측해야 하는 경우가 많기 때문입니다. 숫자로 점수를 매기고 과학적이라고 느끼고 싶은 유혹이 생기지만, 더 나은 접근법은 정성적이되 체계적으로 평가하는 것입니다.

검토 중인 각 기능에 대해 세 가지 질문을 던져 보세요.

"문제는 '이게 좋은 아이디어인가?'가 아닙니다. 백로그에 있는 거의 모든 것이 좋은 아이디어이니까요. 진짜 질문은 '지금 이것을 하지 않고 다른 일을 하는 것의 기회비용이 무엇인가?'입니다."

과소평가 없이 공수 평가하기

팀은 체계적으로 공수를 과소평가합니다. 이는 계획 오류(planning fallacy)와 낙관 편향에 관련된 것으로 잘 알려져 있으며, 여러 시스템에 걸치거나 팀 간 조율이 필요하거나 팀이 한 번도 만들어 본 적 없는 역량이 필요한 기능에서 특히 두드러집니다.

두 가지 방법이 도움이 됩니다. 첫째, 공수를 점수화하기 전에 항상 엔지니어링 팀에 먼저 물어보세요. 사후가 아니라 사전이어야 합니다. PM이 혼자 공수를 매기면 거의 언제나 과소평가합니다. 둘째, "unknown unknowns(우리가 모른다는 사실조차 모르는 것)"를 명시적인 공수 승수로 활용하세요. 코드베이스의 새로운 영역, 서드파티 API, 최근에 테스트하지 않은 사용자 플로우를 건드리는 기능에는 눈에 보이는 작업량으로 짐작한 것보다 1.5배 높은 공수 점수를 주는 것이 좋습니다.

스코프 크리프의 신호 기능을 세 번 추정했는데도 추정치가 계속 늘어난다면, 엔지니어링 추정이 서툴러서가 아니라 기능이 만들 만큼 충분히 정의되지 않았다는 신호입니다. 멈추고 다시 정의한 다음 재추정하세요.

긴급함의 착각

제품 백로그의 긴급함 대부분은 진짜 긴급함이 아니라 최신성(recency)입니다. 지난주에 고객이 불만을 제기했으니 그 요청이 시급해 보이고, 지난달에 경쟁사가 무언가를 출시했으니 따라잡는 것이 중요해 보입니다. 그러나 최신성은 중요성과 같지 않으며, 최신성에 반응하는 것은 정말 중요한 일을 놓치게 하는 가장 확실한 방법 중 하나입니다.

실용적인 테스트가 하나 있습니다. 이 소식을 지난주가 아니라 여섯 달 전에 들었더라도 여전히 급하다고 생각할지 자문해 보세요. 아니라면 전략적 우선순위가 아니라 최신성 편향이 작동한 것입니다. 기록해 두고, 매트릭스에 비추어 차분히 평가하고, 단지 따끈따끈하다는 이유로 우선 처리하려는 충동을 억누르세요.

목소리가 가장 큰 고객의 문제 특정 기능에 대해 이메일을 가장 많이 보내는 고객이 사용자 기반을 대표하는 경우는 드뭅니다. 문제를 제기한 사람의 끈질김이 아니라, 문제의 범위와 깊이를 기준으로 우선순위를 정하세요.

매트릭스가 동점을 낼 때

매트릭스가 항상 명쾌한 답을 주지는 않습니다. 두 항목이 비슷한 점수로 같은 사분면에 놓이는데도 하나를 골라야 할 때가 있습니다. 이럴 때는 두 가지 동점 해소 기준이 유용합니다. 전략적 정합성(18개월 뒤 우리가 원하는 위치에 어느 쪽이 더 가까이 데려다 주는가?)과 되돌릴 수 있는 정도(잘못되었을 때 어느 쪽이 되돌리기 더 어려운가?)입니다. 전략적으로 더 부합하고 되돌리기 쉬운 항목을 선택하세요.

FabricLoop이 우선순위 결정을 돕는 방법 우선순위 결정은 그 뒷받침이 되는 근거만큼만 좋아질 수 있습니다. FabricLoop은 고객 피드백, 리서치 노트, 팀 논의를 백로그와 함께 하나의 스레드에 모아 둡니다. 그래서 임팩트를 평가할 때 기억이 아니라 근거를 바탕으로 판단할 수 있습니다.

이 글에서 얻어갈 10가지

  1. 모든 것이 급하게 느껴진다면 긴급함은 의미를 잃은 것입니다. 급하다는 느낌은 우선순위의 좋은 신호가 아닙니다.
  2. 대부분의 우선순위 프레임워크는 직감을 스프레드시트에 통과시켜 포장합니다. 솔직한 정성적 판단이 가짜 숫자의 정밀성보다 낫습니다.
  3. 임팩트와 공수가 중요한 두 가지 기준입니다. 나머지는 이를 다듬는 것이거나 주의를 흩뜨리는 것입니다.
  4. 퀵 윈(높은 임팩트, 낮은 공수)은 거의 항상 가장 먼저 해야 합니다. 너무 고민하지 마세요.
  5. 시간 먹는 하마(낮은 임팩트, 높은 공수)는 미루지 말고 검토 대상에서 완전히 제외해야 합니다.
  6. 임팩트는 빈도 곱하기 강도입니다. 모두가 느끼는 가벼운 불편과 소수에게 닥친 심각한 장애물은 다릅니다.
  7. 팀은 체계적으로 공수를 과소평가합니다. 점수를 매기기 전에 항상 엔지니어링 추정을 받고, unknown unknowns를 위한 여유분을 더하세요.
  8. 백로그의 긴급함 대부분은 최신성 편향입니다. 이 소식을 여섯 달 전에 들었다면 여전히 급하게 느껴질지 자문해 보세요.
  9. 목소리가 가장 큰 고객이 가장 대표성 있는 고객인 경우는 드뭅니다. 문제의 범위와 깊이를 기준으로 우선순위를 정하세요.
  10. 두 항목이 동점이면 전략적으로 더 부합하고, 틀렸을 때 되돌리기 더 쉬운 쪽을 선택하세요.