우선순위 결정

Prioritization

방법

만들 것이 만들 시간보다 늘 많은 조건에서 무엇을 먼저 하고 무엇을 미룰지 근거를 세워 정하는 일입니다.

등장 배경

만들 후보를 모아 두기 시작하면 목록은 한 방향으로만 자랍니다. 고객 요청이 들어오고, 영업이 계약을 따내려면 필요하다는 기능을 적어 두고, 개발팀이 손봐야 할 곳을 올리고, 대표가 경쟁사에서 본 것을 얹습니다. 지우는 사람은 없습니다. 반년이면 마흔 건이 쌓이고, 한 분기에 만들 수 있는 것은 여섯 건입니다.

순서를 정하는 규칙이 없으면 그 자리를 다른 것이 채웁니다. 대개 목소리 크기와 요청이 들어온 시각입니다. 회의에서 수아가 "이거 없으면 이번 계약 놓칩니다" 라고 말하면 그 기능이 맨 위로 올라가고, 다음 주에 규원이 다른 회사 제품을 보고 와서 비슷한 말을 하면 그것이 다시 맨 위로 올라갑니다. 지난주에 맨 위였던 것은 두 번째로 내려가고, 그 주에 절반쯤 만들어 둔 코드는 그대로 멈춥니다.

이런 팀의 분기 말 상태는 비슷합니다. 완성된 기능은 둘인데 절반쯤 만들다 만 것이 넷입니다. 각각을 시작할 때는 다 그럴 만한 이유가 있었고, 멈춘 이유도 다 그럴 만했습니다. 문제는 여섯 건에 들어간 시간의 합이 완성된 두 건의 값어치보다 훨씬 크다는 것입니다.

더 곤란한 자리는 미룬 것을 설명해야 할 때입니다. 마흔 건 중 여섯 건을 고르면 서른네 건은 누군가가 요청했던 것이고, 그 누군가는 왜 자기 것이 빠졌는지 묻습니다. "다음에 하겠습니다" 는 답이 되지 않습니다. 다음 분기에도 같은 일이 벌어질 것을 서로 알기 때문입니다. 근거가 없는 순서는 정하는 데 걸리는 시간보다 설명하는 데 걸리는 시간이 더 깁니다.

서른네 건이 다 같은 종류도 아닙니다. 어떤 것은 없으면 고객이 떠나고, 어떤 것은 있으면 계약 한 건이 더 들어오고, 어떤 것은 지금 안 고치면 6개월 뒤에 비용이 세 배가 됩니다. 이 셋을 같은 목록에 나란히 놓고 위에서부터 읽으면 무엇을 기준으로 견줘야 할지부터 막힙니다. 순서를 정하기 전에 무엇을 보고 견줄지부터 정해야 한다는 뜻입니다.

우선순위 결정은 그 근거를 밖으로 꺼내 놓으려고 만들어진 일입니다. 무엇을 보고 골랐는지를 몇 개 축으로 적어 두면 두 가지가 달라집니다. 같은 기준을 다음 분기에도 쓸 수 있고, 빠진 사람에게 무엇이 모자랐는지를 숫자로 보여 줄 수 있습니다. 판단이 사라지는 것은 아닙니다. 판단하는 자리가 회의실 공기에서 표의 칸으로 옮겨 올 뿐입니다.

분야 구성

우선순위 결정 아래 묶인 용어는 두 갈래입니다. 순서를 매기는 데 쓰는 틀(프레임워크)과, 그 틀의 칸에 값으로 들어가는 개념(개념)입니다.

어느 틀을 쓰든 진행 순서는 크게 다르지 않습니다.

  1. 후보를 한 목록에 모읍니다. 흩어진 채로는 비교가 안 되므로 제품 백로그처럼 한곳에 쌓아 두는 자리가 먼저 있어야 합니다.
  2. 비교 단위를 맞춥니다. 버튼 문구 수정과 결제 시스템 교체를 같은 표에 올리면 어떤 틀을 써도 결과가 이상해집니다. 며칠짜리와 몇 달짜리는 표를 나눠 각각 매깁니다.
  3. 축을 고릅니다. 이 단계에서 아래 일곱 가지 중 하나를 택합니다. 팀이 이미 쓰던 것이 있으면 그대로 쓰는 편이 낫습니다. 틀을 바꾸면 지난 분기에 매긴 점수와 이번 점수를 나란히 놓을 수 없게 됩니다.
  4. 후보마다 값을 매깁니다. 혼자 매기지 않고 최소한 제품·개발·영업이 같이 앉습니다. 노력 값은 만드는 사람이, 도달 범위는 데이터를 볼 수 있는 사람이 냅니다.
  5. 나온 순서를 그대로 쓰지 않고 한 번 걸러 냅니다. 점수와 무관하게 앞으로 당겨야 하는 것이 늘 있습니다. 계약서에 날짜가 적힌 것, 법에 걸리는 것, 다른 작업이 끝나야 시작할 수 있는 것입니다.
  6. 미룬 것을 기록으로 남깁니다. 왜 이번에 안 하는지를 한 줄씩 적어 두면 다음 분기에 같은 논의를 처음부터 하지 않습니다.

프레임워크는 무엇을 축으로 삼느냐로 갈리고 일곱 자리가 있습니다.

  1. RICE — 도달 범위와 영향과 확신을 곱하고 노력으로 나눕니다. 분기에 2,000명이 쓰고 영향이 보통이며 근거가 꽤 있고 3인월이 드는 후보라면 2,000에 영향 2와 확신 0.8을 곱한 뒤 3으로 나눠 1,067이 나옵니다. 숫자 자체에는 뜻이 없고, 같은 방식으로 매긴 옆 후보가 240이라는 사실만 뜻이 있습니다. 네 축을 다 매겨야 해서 손이 가장 많이 가는 대신, 왜 그 순서인지를 축 단위로 따질 수 있습니다.
  2. ICE — 영향·확신·용이성 세 축에 1부터 10까지를 매겨 곱합니다. RICE 에서 도달 범위를 빼고 노력을 용이성으로 뒤집은 가벼운 판이라, 후보가 열 건쯤일 때 30분 만에 끝낼 수 있습니다. 눈금이 사람마다 다르다는 약점이 있어 같은 사람들이 이어서 매길 때 쓸 만합니다.
  3. MoSCoW — 점수 대신 필수·권장·선택·제외 네 등급으로 나눕니다. 순서가 아니라 경계를 긋는 방식이라, 출시일이 이미 고정된 프로젝트에서 그 날짜까지 반드시 있어야 하는 것을 가려낼 때 맞습니다. 필수가 전체의 절반을 넘으면 등급을 잘못 매긴 것입니다.
  4. 가치-노력 매트릭스 — 가로를 노력, 세로를 가치로 두고 후보를 사분면에 붙입니다. 계산이 없어 화이트보드 한 장과 포스트잇으로 30분이면 끝나고, 가치가 높고 노력이 적은 칸에 무엇이 모여 있는지가 바로 보입니다. 정밀하지는 않아서 큰 덩어리를 먼저 걸러 내는 1차 통과에 씁니다.
  5. WSJF — 지연 비용을 작업 크기로 나눕니다. 짧고 값비싼 것을 앞으로 당기는 성질이 있어 여러 팀이 걸린 큰 프로그램의 순서를 잡을 때 씁니다.
  6. 카노 모델 — 기능을 당연 품질·성능 품질·매력 품질로 나눠 만족도와의 관계를 봅니다. 자동 저장처럼 있어도 티가 안 나지만 없으면 불만이 터지는 것과, 있으면 반가운 것을 구분해 줍니다. 앞의 것을 빼먹으면 다른 축에서 아무리 점수가 높아도 제품이 무너집니다.
  7. 기회 점수 — 사용자에게 무엇이 얼마나 중요한지와 지금 얼마나 만족하는지를 따로 묻고, 중요도는 높은데 만족도가 낮은 영역을 찾습니다. 위의 여섯이 이미 나온 후보를 줄 세우는 도구라면 이쪽은 후보 목록에 무엇이 빠졌는지를 알려 줍니다.

개념은 틀의 칸에 들어갈 값을 다루는 갈래이고 지금은 한 자리입니다. 지연 비용은 이 일을 한 달 늦게 시작하면 얼마를 잃는지를 돈으로 환산한 값입니다. 경쟁사가 먼저 내면 놓치는 계약, 수동으로 처리하느라 매달 나가는 인건비 같은 것이 재료입니다. 값을 정확히 맞히기는 어렵지만 후보끼리의 크기 차이만 잡혀도 순서는 갈립니다. 한 건은 늦어져도 매달 80만 원어치 손해에 그치고 다른 건은 분기마다 계약 두 건이 걸려 있다면, 두 값의 자릿수가 다르다는 것만으로 앞뒤가 정해집니다. 갈래에 자리가 하나뿐인 이유는 나머지 값이 대개 제품 지표나 재무 쪽에서 이미 정의된 말을 빌려 오기 때문입니다.

두 갈래를 다 써도 남는 것이 있습니다. 틀은 점수를 뱉을 뿐이고 무엇을 만들지는 사람이 정합니다. 점수가 비슷한 두 건이 나오면 그때는 어느 쪽이 회사가 가려는 방향에 가까운지로 정합니다. 이렇게 정해진 순서를 시간 축에 올려 언제쯤 무엇을 낼지 보여 주는 것이 제품 로드맵이고, 순서가 자주 뒤집히는 팀의 로드맵은 그리는 즉시 낡습니다.

실무 용례

"이번 분기 RICE 점수 상위 여섯 건입니다. 7위부터는 왜 잘렸는지도 같이 적어 뒀어요."

고른 것보다 미룬 것을 설명하는 데 더 공들였다는 뜻입니다.

"노력 점수는 개발팀이 매겨 주세요. 저희가 매기면 늘 실제보다 작게 나옵니다."

만드는 사람이 아닌 사람이 비용을 추정하면 한쪽으로 치우친다는 것을 알고 미리 막는 말입니다.

"점수는 3위인데 이건 위로 올립니다. 계약서에 다음 달까지로 적혀 있어요."

틀이 낸 순서를 사람이 뒤집는 자리이고, 뒤집는 이유를 밝히는 자리이기도 합니다.

페이지덱의 분기 계획 회의가 이 순서로 흘러갑니다. 지현이 백로그에 쌓인 마흔한 건 중 하루 안에 끝나는 잔손질을 먼저 빼내 따로 묶습니다. 남은 스물세 건을 RICE 표에 올리고 도달 범위는 지현이, 노력은 태오가, 계약에 걸린 건의 무게는 수아가 채웁니다. 표가 채워지면 점수 순으로 줄이 서고, 거기서부터 대화가 시작됩니다.

지난 분기에는 상위 여섯 건 중 둘이 같은 결제 모듈을 건드린다는 것을 태오가 짚어 한 건을 다음 분기로 내렸습니다. 규원은 8위에 있던 항목을 위로 올렸는데, 기업 고객과 맺은 계약서에 완료 날짜가 박혀 있었기 때문입니다. 지현이 그 두 번의 조정을 회의록에 한 줄씩 적었습니다. 점수를 뒤집은 기록이 남아 있어야 다음 분기에 같은 항목을 다시 설명하지 않아도 됩니다.

잘린 열일곱 건은 버리지 않고 사유를 한 줄씩 붙여 백로그에 그대로 두었습니다. 요청한 사람에게는 이번 분기에 자리가 없었다는 말과 무엇이 앞섰는지를 함께 알렸습니다. 다음 분기에 그중 몇 건은 점수가 오르고 몇 건은 요청한 쪽에서 먼저 필요 없어졌다고 알려 옵니다. 후자가 생기는 것도 미룬 것을 기록해 둔 덕입니다.

흔한 오해

점수가 높은 것부터 차례로 만들면 된다고 여기는 경우가 가장 많습니다. 숫자가 나왔으니 그대로 따르는 것이 공정해 보입니다. 그러나 틀이 계산에 넣지 않는 것이 여럿 있습니다. 어떤 작업은 다른 작업이 끝나야 시작할 수 있고, 어떤 작업은 날짜가 계약서에 적혀 있고, 어떤 작업은 혼자서는 값이 작지만 뒤에 올 세 건의 값을 크게 만듭니다. 점수 순서를 그대로 집행하면 데이터 구조를 바꾸는 작업이 늘 하위에 머물고, 그 위에 얹으려던 기능 세 건이 반년 뒤에 다 같이 막힙니다. 점수는 회의를 여는 자료이고 닫는 결론이 아닙니다. 틀이 낸 순서를 사람이 몇 건 뒤집었는지는 오히려 그 팀이 틀을 제대로 쓰고 있다는 표시에 가깝습니다.

우선순위 결정을 할 일을 고르는 작업으로 읽는 것도 흔합니다. 고른 여섯 건이 눈에 보이는 결과물이니 그쪽에 시선이 갑니다. 하지만 실제로 힘이 드는 쪽은 서른네 건을 안 하겠다고 말하는 일입니다. 미룬 것을 말하지 않으면 요청한 사람은 자기 것이 아직 살아 있다고 여기고, 두 달 뒤에 진행 상황을 묻습니다. 그 질문이 쌓이면 팀은 목록에 없던 일을 몰래 끼워 넣기 시작하고, 분기 말에 계획과 실제가 따로 놉니다. 안 하기로 한 것을 그때그때 이름을 붙여 알리는 팀은 이 질문을 덜 받습니다. 목록에서 빠진 것이 죽은 것이 아니라 이번 분기에 자리가 없었다는 사실만 분명해도 대화는 훨씬 짧아집니다.

같이 보면 좋은 페이지

  • 제품

    우선순위 결정이 전략과 정의·문서 사이 어디에 놓인 일인지 한 단계 위에서 봅니다

  • RICE

    일곱 틀 중 가장 널리 쓰이고 축이 뚜렷해 먼저 익히기 좋습니다

  • 자원 배분

    같은 판단을 기능 단위가 아니라 사람과 예산 단위로 하면 이 일이 됩니다

하위 용어

연관 용어

마지막 업데이트 2026-09-16