스프린트 플래닝. PO가 "이 기능 며칠 걸려요?"라고 묻자 개발자 A는 "3일", B는 "일주일"이라 답합니다. 같은 작업인데 추정이 두 배 넘게 벌어집니다. 한편 백로그엔 하고 싶은 일이 50개. 무엇부터 할지 회의가 한 시간째 평행선입니다. "이게 더 중요해요" "아니 저게 먼저죠"의 반복. 추정과 우선순위는 감이 아니라 방법이 필요합니다 — 그래야 논쟁이 결정으로 바뀝니다.
- 1스토리 포인트가 "절대 시간"이 아니라 "상대 크기"인 이유를 설명할 수 있다
- 2RICE로 백로그 항목의 우선순위를 점수화할 수 있다
- 3MoSCoW로 릴리스 범위의 필수/선택을 가를 수 있다
- 4우선순위 논의에 운영 비용(TCO)을 포함시킬 수 있다
추정 — 왜 '시간'이 아니라 '크기'인가
상대 추정: 사람마다 다른 속도 문제를 우회한다
"며칠 걸려요?"가 빗나가는 이유는 사람마다 속도가 다르고, 같은 사람도 컨디션·방해 요소에 따라 다르기 때문입니다. 절대 시간은 본질적으로 불안정합니다.
스토리 포인트는 작업의 상대적 크기/복잡도/불확실성을 숫자로 매깁니다(보통 피보나치: 1,2,3,5,8,13). "이 작업은 기준 작업(2점)보다 두 배쯤 복잡 → 5점"처럼 비교합니다.
기준 잡기: "회원 이메일 검증" = 2점 (팀이 합의한 기준 작업)
비교: "소셜 로그인 연동" = 5점 (외부 의존·예외 많음 → 더 큼)
"오타 수정" = 1점
여기에 팀의 **속도(velocity, 스프린트당 완료 포인트)**를 결합하면 "이 백로그(40점)는 우리 속도(20점/스프린트)로 약 2스프린트"라는 예측이 나옵니다. 단, 포인트를 시간으로 1:1 환산하는 순간(5점=5일) 상대 추정의 장점이 사라지니 주의합니다.
우선순위 — 논쟁을 점수로
RICE와 MoSCoW: 주관을 비교 가능하게
"이게 더 중요해"의 반복을 끝내려면 공통 기준이 필요합니다.
RICE = (Reach × Impact × Confidence) / Effort
- Reach: 일정 기간 얼마나 많은 사용자에게 닿나
- Impact: 닿은 사용자당 영향 크기(3=큼,2=중,1=소,0.5=미미)
- Confidence: 위 추정에 대한 확신(%) — 데이터 있으면 높게
- Effort: 필요한 노력(사람·스프린트)
기능 A: Reach 5000 × Impact 2 × Confidence 0.8 / Effort 3 = 2667
기능 B: Reach 800 × Impact 3 × Confidence 1.0 / Effort 1 = 2400
→ A가 약간 우위. 숫자로 비교 가능 → 논쟁이 검증으로.
MoSCoW — 릴리스 범위 가르기:
- Must: 없으면 출시 무의미(소수여야 정상)
- Should: 중요하나 빠져도 출시 가능
- Could: 있으면 좋음(여유 시)
- Won't(this time): 이번엔 안 함(= Out of Scope)
RICE는 '무엇이 가성비 좋은가', MoSCoW는 '이번 릴리스에 무엇이 필수인가'를 가립니다. 둘은 함께 씁니다.
우선순위에 운영 비용 넣기 — 직접 점검
인프라/SRE 관점에서 가장 흔한 누락은 Effort에 '구현'만 넣고 '운영'을 빼는 것입니다. 총소유비용으로 다시 계산합니다.
기능: "실시간 추천 배너"
잘못된 Effort: 구현 3 (개발만)
올바른 Effort: 구현 3 + 운영 4 = 7
운영 항목: 추천 연산 서버 상시 가동, 모니터링·알람 추가,
트래픽 스파이크 스케일링, A/B 실험 인프라
RICE 재계산:
Before) 5000×2×0.8 / 3 = 2667 (운영비 누락 → 과대평가)
After) 5000×2×0.8 / 7 = 1143 (현실적 가성비)
→ 순위가 내려갈 수 있음. 운영비를 빼면 '싸 보이는' 기능에 속는다.
echo '구현공수 + 운영공수 = 총 Effort'- Effort에 운영 항목(모니터링·스케일·온콜·기술부채)이 포함됐는지 확인 — 구현만 들어갔으면 가성비가 부풀려진 것. 인프라가 운영 공수를 더한다
- Must로 분류된 항목이 전체의 절반을 넘으면 → 우선순위를 못 가린 것. 진짜 Must는 소수. 다시 Should로 내릴 것을 찾는다
- Confidence가 낮은(0.5 이하) 항목이 상위에 있으면 → 추정 근거가 약함. 점수를 키우기 전 데이터/프로토타입으로 확신을 먼저 올린다
- velocity(완료 포인트)가 스프린트마다 출렁이면 예측 신뢰도 낮음 → 추정 기준 작업을 재합의하거나 작업을 더 작게 쪼갠다
상황: 매 분기 RICE로 '구현 공수 작고 임팩트 큰' 기능을 우선했는데, 반년 뒤 운영팀이 모니터링 사각·수동 스케일·누적 기술부채로 장애와 야근에 시달립니다.
원인: Effort에 운영 비용을 넣지 않아 '싸 보이는' 기능이 계속 상위로 올라왔습니다. 각 기능의 운영 꼬리(모니터링·확장·유지보수)가 누적되며 보이지 않는 부채가 됐습니다.
진단 — 우선순위 점검:
□ Effort에 운영 공수(모니터링·스케일·온콜)가 포함됐나?
□ '기술부채 상환' 항목이 백로그에 주기적으로 들어가나?
□ 새 기능의 NFR(가용성·확장성)이 인프라 설계로 이어졌나?
해결: RICE의 Effort를 '총소유비용'으로 정의하고, 운영 항목을 인프라/SRE가 더합니다. 그리고 매 스프린트 일정 비율(예: 20%)을 기술부채·운영개선에 고정 배정합니다([[tech-debt-refactoring]] 참고). 단기 가성비만으로 줄 세우면 미래의 운영팀이 비용을 대신 치릅니다.
PM은 RICE·MoSCoW로 이해관계자 간 우선순위 논쟁을 '비교 가능한 결정'으로 바꿉니다. 인프라/SRE는 이 논의에서 결정적 역할을 합니다 — 각 기능의 운영 비용을 가시화해, "구현 3일이지만 운영은 영원히"라는 진실을 숫자로 드러냅니다. 또한 추정 회의(플래닝 포커 등)에서 외부 의존·데이터 마이그레이션·롤백 난이도 같은 '인프라 복잡도'를 포인트에 반영하도록 목소리를 냅니다. 추정과 우선순위는 단순한 PM 업무가 아니라, 조직이 무엇에 시간을 쓸지 정하는 가장 중요한 협업입니다.
다음 모듈에서는 이렇게 정한 우선순위를 시간 축에 배치하는 로드맵과, 일을 추적하는 이슈 트래킹을 다룹니다.