13장. 요구사항의 우선순위를 결정한다

가치·비용·위험·의존성을 근거로 우선순위를 토론하되 점수와 기법이 권한 있는 결정을 대신하지 않게 한다.

이번 장에서 해결할 질문

학습 목표

• “가치·긴급성·위험·노력을 섞지 않고 우선순위를 어떻게 결정하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

가치 있는 요구가 모두 같은 시점에 구현될 수는 없다. 일정과 예산이 제한된 상황에서 목소리의 크기나 단순 점수만으로 순서를 정하면, 필수 정책·위험·의존성이 뒤로 밀리거나 숫자가 근거 없는 권위를 갖게 된다. 우선순위는 계산 문제가 아니라 근거를 드러내는 의사결정 문제다.

이 장에서는 가치·비용·위험·의존성과 시간 민감성을 함께 비교하는 방법을 다룬다. MoSCoWMoSCoW요구를 Must·Should·Could·Won't로 나눠 우선순위 대화를 돕는 기법이다.와 상대 비교 같은 기법을 토론 도구로 사용하되 결정 권한과 가정을 기록하고, 수강신청 사례에서 구현 순서와 제품 범위를 구분해 판단한다.

1. 모든 요구사항이 중요한 것은 아니다

이해관계자가 말한 요구는 모두 존중해야 하지만 모두 같은 시점에 구현할 수는 없다. “전부 중요”라는 말은 갈등을 피하는 대신 자원 배분 결정을 개발 막바지로 미룬다. 결국 일정이 급해졌을 때 근거 없이 빠지거나, 기술적으로 쉬운 항목이 먼저 만들어진다. 우선순위 결정은 중요·보통·낮음 딱지를 붙이는 일이 아니라 정해진 범위와 시점에서 무엇을 먼저 실현할지 공통 기준으로 선택하는 일이다.

13장의 사례 후보는 네 묶음이다.

• 신청 핵심 흐름: FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다., UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자., DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다., IR-001IR-001 · 인터페이스 요구자격·운영 흐름.을 중심으로 판정·상태·사유·안전한 실패를 제공한다.
• 대기명단: 정원 부족 후 순서를 관리하고 빈자리가 생기면 다음 후보를 처리한다.
• 개인화 추천: 학생 특성과 이력에 따라 강좌 후보를 제안한다.
• 관리자 통계: 신청 현황과 원인별 문의·보류·재처리를 분석한다.

이 네 항목은 같은 크기와 추상 수준이 아니다. 핵심 흐름은 여러 요구의 묶음이고 통계는 기능 후보다. 비교 전에 비슷한 결정 단위로 분해하고, 대상 출시와 기간을 명시한다. “프로젝트 전체의 중요도”와 “첫 출시의 순서”는 다른 질문이다.

IIBA의 Business Analysis Standard는 요구사항 우선순위 결정, 변경 영향 평가, 승인과 요구사항 아키텍처를 연결된 생명주기 관리 활동으로 다룬다. 목록을 한 번 정렬하고 끝내는 것이 아니라 목표·관계·변경에 따라 순위를 다시 살펴야 한다는 실무 근거가 된다.

우선순위 회의 전에 결정 대상, 기간, 최소 출시 결과, 평가 기준, 점수 의미, 결정권자와 재검토 시점을 합의한다. 법률·안전·필수 정책처럼 선택 불가능한 제약과 가치 경쟁 항목도 구분한다. 필수 제약을 높은 점수로 이기는 항목으로 취급해서는 안 된다.

2. 가치

가치는 요구가 실현되었을 때 이해관계자와 조직이 얻는 유익이다. 선호도나 요청 횟수만으로 정하지 않는다. G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.과 BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.에 기여하는지, 문제의 규모가 줄어드는지, 공정성·접근성·정확성 같은 보호 가치가 나아지는지 증거로 판단한다.

수강신청 핵심 흐름의 가치는 학생이 결과와 이유를 알아 반복 제출을 줄이고, 운영자가 판정 이력으로 문의와 복구를 처리하며, 잘못된 자동 승인을 피하는 데 있다. 대기명단은 정원 부족 상황의 예측 가능성을 높일 수 있지만 정책이 명확해야 한다. 추천은 강좌 탐색을 돕지만 현재 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.과 직접 연결되는 근거가 약하다. 관리자 통계는 BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.의 측정과 개선에는 가치가 있으나 어떤 지표가 실제 결정을 지원하는지 확인해야 한다.

가치 기준표는 다음처럼 만든다.

숫자를 매기기 전에 단위와 근거를 맞춘다. 1–5점은 정밀한 측정값이 아니라 상대 비교를 위한 약속이다. “가치 5”에는 평가 이유와 출처를 붙이고, ASM-001ASM-001 · 가정결과를 알 수 없는 상태에서 발생하는 반복 제출이 수동 재처리 증가에 유의미하게 기여한다는 미확인 가정이다.에 기대는 평가는 신뢰도가 낮다고 표시한다. 가치가 높다는 말만으로 우선 실행이 결정되지는 않는다. 비용·위험·의존성과 긴급성을 함께 본다.

3. 비용

비용은 개발 공수만이 아니다. 분석, 정책 합의, 데이터 정비, 외부 연계, 보안·접근성 검토, 시험, 이행, 교육, 관측, 고객 지원과 장기 유지 비용을 포함한다. 낮은 최초 개발비가 높은 운영비를 만들 수 있고, 지금 미룬 항목이 나중에 구조 변경 비용을 키울 수 있다.

대기명단을 화면과 테이블 하나로 보면 저렴해 보인다. 실제로는 취소·증원·우선순위 변경 시 자동 승급, 응답 기한, 여러 강좌 대기 중복, 알림 실패, 이의 처리와 학기 종료가 필요할 수 있다. 개인화 추천도 알고리즘 개발뿐 아니라 입력 데이터의 적법한 목적, 품질, 편향 검토와 설명·운영 비용이 따른다. 관리자 통계는 기존 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다. 기록 구조가 먼저 갖춰지면 추가 비용이 낮아질 수 있다.

비용은 범위로 표현한다. 초기에는 단일 숫자보다 낙관/가장 가능/비관, 포함·제외 항목, 가정과 신뢰도를 기록한다. 외부 팀 일정이나 미확정 정책처럼 팀이 통제하지 못하는 비용 동인도 분리한다.

비용이 크다고 낮은 우선순위는 아니다. 필수 결과일 수 있고, 지금 기반을 만들지 않으면 다른 항목이 불가능할 수 있다. 비용은 가치를 포기할 이유가 아니라 가능한 대안과 순서를 비교할 정보다.

4. 위험

위험은 불확실한 사건이 목표에 주는 부정적 영향이다. 우선순위에서는 두 방향을 함께 본다. 요구를 구현하지 않을 위험과 요구를 구현하는 과정·결과의 위험이다. 전자만 보면 모든 요청이 긴급해지고, 후자만 보면 어려운 핵심 문제를 계속 미루게 된다.

핵심 흐름을 미루면 다음 학기에도 결과 불확실성과 수동 재처리가 남을 수 있다. 그러나 규칙과 정원 동시성을 충분히 이해하지 않고 서둘러 구현하면 잘못된 승인과 공정성 문제가 생긴다. 대기명단을 미루면 학생의 예측 가능성이 낮아질 수 있지만, 정책 미합의 상태에서 구현하면 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.을 더 복잡하게 만든다. 추천은 잘못된 제안·편향·데이터 사용 위험을 별도로 평가해야 한다.

위험 기반 순서에는 두 전략이 있다.

• 위험 감소를 먼저: 규칙 서비스 응답과 정원 동시성에 대한 실험, ASM-001ASM-001 · 가정결과를 알 수 없는 상태에서 발생하는 반복 제출이 수동 재처리 증가에 유의미하게 기여한다는 미확인 가정이다. 로그 검증처럼 큰 불확실성을 일찍 줄인다.
• 안전한 보호를 먼저: IR-001IR-001 · 인터페이스 요구자격·운영 흐름.의 자동 승인 금지, 판정 이력처럼 실패 영향의 상한을 낮춘다.

위험 점수는 가능성×영향의 단순 계산으로 끝내지 않는다. 근거, 영향을 받는 집단, 탐지 가능성, 회복 가능성, 책임자와 완화 조치를 함께 기록한다. 점수가 높다는 이유로 자동 개발하는 것이 아니라 조사·정책 결정·시제품·통제 구현 중 어떤 대응이 필요한지 정한다.

5. 의존성

12장12장. 요구사항을 구조화한다흩어진 요구를 목표·기능·규칙·데이터·품질과 관계로 어떻게 구조화하는가?페이지로 이동에서 만든 종속·선행관계는 우선순위 라벨을 실제 순서로 바꾼다. 가치가 높은 결과도 선행 조건이 준비되지 않으면 구현하거나 검증할 수 없다. 반대로 사용자에게 직접 보이지 않는 기반이 여러 고가치 요구를 가능하게 하면 먼저 해야 할 수 있다.

이 사례에서는 다음 관계가 중요하다.

Must가 Should에 의존하는 구조는 경고다. 선행 항목의 우선순위를 올리거나 Must 범위를 분해하거나, 다른 대안을 찾아야 한다. 하지만 모든 기술 기반을 무조건 최우선으로 올리지 않는다. 특정 구현 설계가 만든 의존성인지, 업무 결과가 정말 요구하는 의존성인지 분리한다.

의존성 검토 질문은 이 항목 없이 무엇이 막히는가, 완전히 필요한가 아니면 위험만 높이는가, 외부 결정의 약속 시점은 언제인가, 임시 대안이 있는가, 순환 관계를 어떤 결정으로 끊을 것인가이다. 순위표에는 항목 자체의 평가와 의존성으로 조정된 실행 순서를 모두 남긴다.

6. 긴급성

긴급성은 시간이 지날수록 가치가 사라지거나 피해·비용이 커지는 정도다. 목소리가 크거나 요청 날짜가 빠르다는 뜻이 아니다. 정해진 학기 시작, 법·정책 시행일, 외부 서비스 종료, 위험 노출 기간과 학습 창처럼 시간에 민감한 근거가 있어야 한다.

수강신청 핵심 흐름은 다음 학기 본 신청 전에 검증·전환되어야 하므로 시간창이 분명하다. 학기 중에는 실제 집중 부하를 재현하기 어렵고 잘못된 변경의 피해가 크므로 준비·리허설 시점도 거꾸로 계산해야 한다. 관리자 통계 중 BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자. 기준선 수집은 출시 후 만들 수 없다. 비교 가능한 과거·현재 데이터를 확보하려면 기능 전체보다 먼저 사건 정의와 계측을 정해야 한다.

긴급성을 다음처럼 구분한다.

• 고정 기한: 학기 일정, 규정 시행, 계약 종료
• 지연 비용: 매주 늘어나는 수동 처리·문의·위험 노출
• 기회 창: 특정 학기·모집 기간에만 가능한 관찰과 시험
• 학습 순서: 다음 결정을 위해 먼저 답해야 할 불확실성

“임원이 이번 달에 보고 싶어 한다”는 요청도 조직상 중요할 수 있으나 그 자체가 사용자 가치나 위험을 증명하지는 않는다. 결정권과 요청의 긴급성을 투명하게 기록하고 다른 기준과 함께 비교한다.

7. MoSCoW

MoSCoW는 특정 기간에 제공할 요구를 Must Have, Should Have, Could Have, Won’t Have this time으로 나누는 기법이다. Agile Business Consortium의 공식 설명은 Must를 그 요구가 없으면 프로젝트나 증분을 취소할 만큼 필수인 항목으로 보고, Won’t를 영구 폐기가 아니라 해당 기간에는 제공하지 않기로 합의한 항목으로 설명한다. 또한 프로젝트·증분·타임박스의 우선순위가 다를 수 있음을 강조한다.

첫 출시를 대상으로 한 예시를 만들어 보자. 이것은 사례 설명용 가안이며 승인 결과가 아니다.

모두 Must라고 주장하면 다음 질문을 한다. “이 항목이 없으면 정말 출시를 취소할 것인가?”, “고통스럽더라도 제한된 수동 대안이 있는가?”, “Must 목표와 직접 추적되는가?”, “하위 항목으로 나눌 수 있는가?” Must끼리의 선행관계도 맞아야 한다.

MoSCoW는 같은 범주 안 순서를 주지 않고 비용 대비 가치도 계산하지 않는다. Should와 Could의 경계는 팀마다 주관적으로 흐를 수 있다. 기간과 평가 규칙을 먼저 합의하고, 각 라벨에 근거·결정자·재검토 시점을 붙이며, 가치-노력이나 위험·의존성 분석으로 보완한다. 공식 DSDM 권고의 비율은 그 방법의 시간 고정·기능 조정 맥락에서 나온 것이므로 모든 프로젝트의 보편 법칙처럼 적용하지 않는다.

8. 가치 대 노력

가치 대 노력 매트릭스는 상대 가치와 구현 노력을 두 축으로 놓아 대화를 시작하는 도구다. 일반적으로 높은 가치·낮은 노력은 빠른 성과 후보, 높은 가치·높은 노력은 전략적 투자·분해 후보, 낮은 가치·낮은 노력은 여유가 있을 때의 후보, 낮은 가치·높은 노력은 보류·제외 후보로 본다.

위치는 사실 측정이 아니라 현재 증거에 따른 토론용 가설이다. 핵심 흐름을 얇게 잘라 빠른 성과로 보이게 하면서 안전한 보류·기록을 빼면 사용 가능한 최소 결과가 아니다. 노력 추정도 요구가 같은 크기로 분해되고 외부 의존성이 드러난 뒤에 해야 한다.

매트릭스의 한계는 시간 민감성, 위험, 의존성, 정책 필수를 한눈에 표현하지 못한다는 점이다. 낮은 가치처럼 보이는 감사 기록이 필수 통제이거나 다른 결과의 전제가 될 수 있다. 각 점 옆에 신뢰도와 관계를 붙이고, 사분면이 결정을 자동화하지 않게 한다.

9. WSJF

WSJF(Weighted Shortest Job First)는 경제적 이익을 높이도록 작업 순서를 정하는 상대적 모델이다. Scaled Agile의 공식 설명에서 SAFe의 WSJF는 상대적 지연 비용을 상대적 작업 기간으로 나눈 값이며, 지연 비용은 사용자·업무 가치, 시간 중요성, 위험 감소 또는 기회 활성화 요소를 사용한다. 이 방식은 SAFe의 흐름 기반 백로그 맥락에서 제시된 것이므로 모든 요구사항 승인 문제의 표준 공식으로 취급하지 않는다.

설명용으로 같은 크기 척도에서 가상 값을 매겨 보자.

관리자 측정 지표가 높게 나온 이유는 작은 크기와 학기 전에 계측을 준비해야 하는 시간 중요성 때문이다. 이것은 관리자 대시보드 전체를 먼저 만들라는 뜻이 아니다. BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자. 측정에 필요한 사건 정의와 최소 계측을 분해해 일찍 처리하라는 신호다. IR-001IR-001 · 인터페이스 요구자격·운영 흐름.도 위험 감소가 커서 핵심 흐름보다 먼저 기술 실험이나 상태 모델 결정을 할 수 있다.

점수는 같은 기준과 상대 척도로 팀이 함께 추정해야 한다. 숫자 정밀도를 과신하지 말고, 두 배 가까운 차이인지 근소한 차이인지 본다. 정책 필수, 하드 기한, 선행관계와 최소 사용 가능 집합은 공식 밖에서 별도로 확인한다. 입력값이나 작업 크기가 바뀌면 다시 계산하고 결정 기록에 당시 값을 남긴다.

10. 우선순위 충돌 해결

학생은 결과와 공정성을, 운영자는 복구와 관측을, 개발팀은 기술 위험 감소를, 경영진은 일정과 비용을 우선할 수 있다. 충돌은 누가 옳고 그른 문제가 아니라 서로 다른 가치와 증거를 같은 표에 올리지 않았다는 신호일 수 있다.

해결 절차는 다음과 같다.

1. 결정 범위를 고정한다. 어느 출시·기간·예산에서 어떤 단위를 순서화하는지 적는다.
2. 필수 제약을 분리한다. 법·안전·정책상 선택 불가능한 조건을 확인한다.
3. 기준과 척도를 합의한다. 가치·비용·위험·의존성·긴급성의 뜻과 증거를 정한다.
4. 개별 평가를 공개한다. 점수뿐 아니라 출처, 가정, 신뢰도를 보여 준다.
5. 차이의 원인을 찾는다. 목표 해석, 데이터, 범위, 이해관계 중 무엇이 다른지 확인한다.
6. 분해·대안을 만든다. 큰 항목의 필수 부분과 선택 부분, 위험 감소 실험을 나눈다.
7. 결정권자가 순서와 조건을 승인한다. 반대 의견과 재검토 사건도 기록한다.

사례의 임시 순서는 최소 계측과 핵심 정책 확인 → 안전한 보류·판정 기록을 포함한 신청 핵심 흐름 → 필요한 운영 통계 → 정책 합의 후 대기명단 → 개인화 추천 재검토가 될 수 있다. 이것은 현재 가정에 따른 분석 예시다. ASM-001ASM-001 · 가정결과를 알 수 없는 상태에서 발생하는 반복 제출이 수동 재처리 증가에 유의미하게 기여한다는 미확인 가정이다.이 틀리거나 대기명단이 반복 제출의 주요 원인이라는 데이터가 나오면 바뀐다.

우선순위 결정 기록에는 대상 기간, 결정 단위, 기준과 가중, 각 평가의 근거·신뢰도, 의존성 조정, 채택 순서, 제외 항목, 결정자, 날짜와 재검토 조건을 남긴다. 점수가 가장 높은 항목을 자동 선택하지 않으며, 목소리가 큰 사람의 Must도 그대로 받지 않는다.

이 장에서 정리한 결과는 우선순위 기준표, 가치-노력 보기, 설명용 WSJF 계산과 조건부 실행 순서다. 이 표는 충돌을 없애지 않는다. 오히려 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.의 공정성·우선 배정, 장애 지원, 서버 비용과 일정처럼 점수만으로 결론 내리면 안 되는 결정을 드러낸다. 다음 장에서는 각 요구가 보호하는 이해관계와 정책을 보존한 채 대안을 비교하고, 권한 있는 합의와 재검토 가능한 결정 기록으로 4부를 마무리한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로