개념
품질 개선은 왜 늘 뒤로 밀리나
제품 백로그에는 신규 기능과 품질 개선이 섞여 있다. 신규 기능은 기획자가 "이걸 하면 매출이 오른다"고 설명한다. 품질 개선은 QA가 "이 결함은 심각도가 주요다"라고 설명한다. 두 설명이 다른 언어라서 비교가 안 되고, 비교가 안 되면 대개 신규 기능이 이긴다.
해결책은 품질 개선을 같은 저울 에 올리는 것이다. 이 레슨의 우선순위 기법들은 모두 신규 기능과 품질 개선에 똑같이 쓸 수 있다.
RICE — 정량 비교
RICE는 Intercom의 Sean McBride가 성장 팀에서 아이디어를 비교하려고 만든 방법이다.
RICE 점수 = (Reach × Impact × Confidence) ÷ Effort
| 요소 | 뜻 | 척도 |
|---|---|---|
| Reach(도달) | 일정 기간 영향을 받는 사람·사건 수 | 예: 분기당 사용자 수 |
| Impact(영향) | 한 사람에게 주는 영향 | 3(대단히 큼) · 2(큼) · 1(보통) · 0.5(작음) · 0.25(아주 작음) |
| Confidence(확신) | 추정치를 얼마나 믿는가 | 100% · 80% · 50% |
| Effort(노력) | 필요한 공수 | 인월(person-month) |
품질 개선에 적용하면 이렇다.
| 항목 | Reach(분기) | Impact | Confidence | Effort | RICE |
|---|---|---|---|---|---|
| 신규: 선물하기 기능 | 30,000 | 1 | 50% | 3 | 5,000 |
| 품질: 결제 앱 복귀 실패 수정 | 19,800 | 2 | 80% | 0.5 | 63,360 |
| 품질: 카드사 점검 시간 안내 | 8,000 | 1 | 80% | 0.3 | 21,333 |
| 신규: 추천 알고리즘 개선 | 120,000 | 0.5 | 50% | 4 | 7,500 |
결제 앱 복귀 실패 수정의 Reach 19,800은 레슨 4의 세분화 결과(주간 약 1,650건 × 12주)에서 나왔다. 데이터가 있는 품질 개선은 Confidence가 높고 Effort가 작은 경우가 많아 RICE에서 유리하다. 반대로 데이터 없이 "중요하다"고만 하면 Confidence가 50%로 떨어진다. 레슨 3·4의 분석이 곧 우선순위 경쟁력이다.
MoSCoW — 릴리스 범위 합의
RICE가 여러 항목을 줄 세운다면, MoSCoW는 이번 릴리스에 무엇을 넣을지 합의하는 데 쓴다.
| 구분 | 뜻 | 판단 질문 |
|---|---|---|
| Must | 없으면 릴리스가 의미 없거나 불법·위험 | "이게 빠지면 출시를 미루는가?" |
| Should | 중요하지만 없어도 출시는 가능 | "빠지면 아프지만 우회할 수 있는가?" |
| Could | 있으면 좋음 | "시간이 남으면" |
| Won't(this time) | 이번엔 안 함 | "다음 릴리스 후보로 명시" |
MoSCoW의 함정은 모든 것이 Must가 되는 것 이다. 흔한 규칙으로 Must는 전체 공수의 60%를 넘지 않게 한다. 나머지가 일정 위험의 완충이 된다. 품질 항목 중 보안·개인정보·금전 정확성에 닿는 것은 Must 후보다(모듈 44 레슨 2의 품질 원칙 P1).
Kano — 기능의 성격
Kano 모델은 기능이 만족도에 미치는 방식을 세 가지로 나눈다.
| 유형 | 있을 때 | 없을 때 | 예 |
|---|---|---|---|
| 당연 품질(Must-be) | 당연하게 여김(만족 증가 없음) | 크게 불만 | 결제가 정확함, 로그인 유지 |
| 일원 품질(Performance) | 좋을수록 만족 | 나쁠수록 불만 | 결제 속도, 검색 정확도 |
| 매력 품질(Attractive) | 기대 이상으로 만족 | 없어도 불만 없음 | 새로운 편의 기능 |
대부분의 품질 문제는 당연 품질 의 결함이다. 잘 되면 아무도 칭찬하지 않지만, 안 되면 사용자가 떠난다. 그래서 만족도 설문으로 우선순위를 정하면 품질 개선이 과소평가된다. "결제가 정확하면 만족하나요?"에 사용자는 "당연하죠"라고만 답한다. Kano 구분을 우선순위 논의에 넣으면 "이건 당연 품질이라 설문에 안 잡히지만 깨지면 이탈이 크다"고 설명할 수 있다.
지연 비용 — 시간의 가치
같은 가치라도 늦어질수록 잃는 것 이 다르다. 지연 비용(Cost of Delay)은 "이 항목을 한 주 늦추면 무엇을 잃는가"다.
| 항목 | 지연 비용의 모양 |
|---|---|
| 결제 앱 복귀 실패 | 매주 일정하게 손실(주간 결제 1,650건) — 빨리 할수록 좋음 |
| 추석 프로모션 기능 | 추석이 지나면 가치 0 — 마감 이후 의미 없음 |
| 규제 대응 | 시행일 이후 과징금 — 기한 전까지는 낮다가 급등 |
| 추천 알고리즘 개선 | 완만 — 늦어도 크게 잃지 않음 |
지연 비용을 공수로 나눈 값(CD3, Cost of Delay Divided by Duration)으로 순서를 정하면, 짧고 지연 비용이 큰 일이 앞에 온다. 매주 손실이 나는 품질 결함은 대부분 여기서 앞으로 온다.
네 기법을 함께 쓴다
| 질문 | 쓰는 기법 |
|---|---|
| 여러 후보 중 무엇이 가장 가치 있나 | RICE |
| 이번 릴리스에 무엇을 넣나 | MoSCoW |
| 이 항목은 어떤 종류의 가치인가 | Kano |
| 무엇을 먼저 하나(시간 가치) | 지연 비용(CD3) |
하나의 기법이 정답을 주지 않는다. 점수는 대화의 출발점이다. 점수가 나오면 "Impact를 2로 준 근거는?", "Confidence 80%의 근거 데이터는?"처럼 가정을 드러내고 논의한다.
개선안 쓰기
우선순위가 정해진 품질 개선은 개선안으로 제안한다. 구조는 문제·근거·선택지·기대 효과·측정 계획이다.
[개선안 — 결제 지연 시 사용자 안내]
문제 카드사 응답 5초 초과 시 "결제 실패" 표시. 실제로는 승인 완료된 경우가 있어 재결제·중복 승인 발생.
근거 결제 지연 관련 문의 월 121건, 중복 승인 환불 월 37건(레슨 3)
결제 승인 단계 전환율 iOS 5.8.0에서 10.7%p 하락(레슨 4)
선택지 A. 타임아웃을 15초로 늘림 — 공수 0.1인월, 대기 체감 악화
B. 5초 초과 시 "승인 확인 중" 상태 표시 + 서버 조회로 결과 확정 — 공수 0.5인월
C. B + 중복 결제 방지 멱등키 — 공수 0.8인월
권고 C. 중복 승인이 금전 정확성(당연 품질) 문제라 멱등키까지 포함
기대 효과 결제 지연 문의 월 121 → 30건 이하, 중복 승인 0건, 결제 승인 전환율 회복
RICE Reach 19,800 × Impact 2 × Confidence 80% ÷ 0.8 = 39,600
측정 계획 적용 전 4주 기준선 vs 적용 후 4주, 같은 요일·같은 결제 수단 구성 비교전후 효과 측정
개선안의 신뢰는 효과를 증명할 때 쌓인다. 전후 비교의 원칙은 레슨 4의 함정과 같다.
- 기준선을 미리 잰다 — 적용 전 최소 2~4주
- 같은 조건으로 비교한다 — 요일·계절·트래픽 구성
- 동시 변경을 기록한다 — 같은 기간에 바뀐 다른 것
- 가능하면 대조군을 둔다 — 단계적 배포로 일부 사용자만 먼저 적용
- 결과를 그대로 보고한다 — 효과가 없었으면 없었다고 쓴다
효과가 없었다는 보고도 가치가 있다. 가설이 틀렸다는 것을 알면 다음 개선안이 정확해진다.
실무에서 왜 필요한가
QA가 품질 개선을 우선순위 경쟁에서 이기지 못하는 가장 큰 이유는 언어의 차이다. RICE와 지연 비용으로 쓰면 품질 개선은 대개 짧고, 확실하고, 매주 손실을 막는 항목으로 드러난다. 그리고 전후 효과를 증명한 개선안이 한두 건 쌓이면, 다음 개선안부터는 설득이 훨씬 쉬워진다.
채용시장에서의 위치
PO·서비스 기획·제품 품질 공고는 "데이터 기반 우선순위 결정", "개선 효과 측정" 경험을 요구한다. 면접에서 RICE 표 한 장과 전후 비교 결과를 보여 주면, 품질 담당자가 아니라 제품 의사결정자 로 읽힌다.