소프트웨어 공학 100 주제 시리즈의 17번째 글이다. (카테고리: 요구사항 공학)

한 줄 요약

MoSCoW 는 이번 기한 안에 무엇을 보장할지를 정하는 약속의 도구이고, Kano 모델은 어떤 기능이 고객 만족에 어떻게 작용하는지를 보는 진단 도구다. 둘은 질문이 다르다. Kano 로 기능의 성격을 알고, MoSCoW 로 이번 릴리스의 계약을 맺는다.

왜 필요한가

요구사항 분석 글에서 MoSCoW 의 네 칸을 소개했다. 실제로 써 보면 금세 이런 장면이 나온다.

  • 이해관계자 모두가 자기 요구를 Must 에 넣는다. 백로그의 80% 가 Must 다.
  • Must 를 다 끝냈는데 고객 반응이 미지근하다. 경쟁사의 사소한 기능 하나에 사용자가 열광한다.
  • 반대로 “아무도 요청하지 않았던” 영수증 기능을 뺐더니 불만이 폭주한다.

첫 번째는 MoSCoW 를 원래 규칙 없이 쓴 탓이고, 나머지 둘은 만족과 불만이 같은 축이 아니라는 사실을 놓친 탓이다. 앞의 것은 DSDM 원전이, 뒤의 것은 Kano 의 1984년 논문이 답한다.

핵심 개념

MoSCoW 의 원래 규칙

MoSCoW 는 DSDM(현재 Agile Business Consortium 이 관리하는 애자일 프로젝트 프레임워크)의 우선순위 기법이다. 공식 설명의 정의를 옮기면 이렇다.

범주 DSDM 의 정의 요지 판별 질문
Must Have 프로젝트가 인도를 보장하는 최소 사용 가능 부분집합. MUST 를 Minimum Usable SubseT 의 약자로도 읽는다 이게 없으면 이 릴리스를 내는 의미가 없는가?
Should Have 중요하지만 필수는 아니다. 빼면 아프지만 솔루션은 여전히 성립한다 우회 방법이 있는가?
Could Have 바라는 것이지만 덜 중요하다. 빼도 Should 보다 영향이 작다 시간이 남으면 할 것인가?
Won’t Have this time 이번 기간에는 하지 않기로 합의한 것 다음에 다시 볼 것인가?

이 정의에서 결정적인 단어는 보장이다. Must 는 “중요한 것” 이 아니라 “팀이 기한 안에 반드시 낸다고 약속하는 것” 이다. 그래서 DSDM 은 숫자 규칙을 둔다.

  • Must 에 드는 노력은 전체의 60% 를 넘지 않게 한다. 넘으면 추정이 정확하고, 접근법이 잘 이해되고, 팀이 잘 돌아가고, 위험이 낮은 환경이 아닌 한 실패 위험이 커진다.
  • Could 는 통상 약 20% 의 노력을 두어 우발 상황에 대비하는 완충으로 쓴다.
노력 배분(DSDM 권장)
|<──────── Must ≤ 60% ────────>|<── Should ──>|<─ Could ~20% ─>|
                                                ▲
                          일이 밀리면 여기부터 덜어 낸다 → Must 는 지켜진다

즉 MoSCoW 는 순위표가 아니라 위험 관리 장치다. Should 와 Could 가 완충이 되어 Must 를 지킨다. 모든 것이 Must 라면 완충이 없으니, 하나만 밀려도 약속이 깨진다.

또 하나: DSDM 은 우선순위를 여러 층위에 둔다. 프로젝트 전체, 프로젝트 증분, 타임박스마다 따로 MoSCoW 를 매긴다. 프로젝트 수준의 Should 가 이번 타임박스에서는 Must 일 수 있고, 타임박스 수준에서는 대부분의 요구가 “이번 타임박스에서는 Won’t” 다.

Kano 모델: 만족과 불만은 다른 축이다

狩野紀昭(Noriaki Kano) 등은 1984년 일본품질관리학회지 品質 14권 2호에 魅力的品質と当り前品質(매력적 품질과 당연한 품질)을 발표했다. 초록에 따르면 이 논문은 지금까지의 일차원적 인식(충족될수록 만족, 부족할수록 불만)을 이차원적 인식으로 바꿔야 한다고 제안하고, 품질 요소를 매력적·당연·일원적 품질 등으로 분류한 뒤, 텔레비전과 탁상시계에 대한 소비자 설문으로 이 이론의 실용성을 검토했다.

만족 ▲
     │                    ╱ 일원적(one-dimensional)
     │      매력(attractive)╱   충족할수록 만족, 부족할수록 불만
     │        ___________╱
     │    ___╱          ╱
─────┼───────────────────────────────▶ 충족 정도
     │              ╱  ____________
     │            ╱ __╱  당연(must-be)
     │          ╱ _╱     충족돼도 만족은 안 오르지만
     │        ╱ ╱        부족하면 불만이 급증
불만 ▼
범주 있을 때 없을 때 예(커피 주문 앱)
당연(must-be) 당연하게 여김 강한 불만 결제 영수증
일원적(one-dimensional) 만족 불만 주문 진행 실시간 표시
매력(attractive) 기쁨 아무렇지 않음 지난 주문 한 번에 다시 담기
무관심(indifferent) 무덤덤 무덤덤 앱 테마 색 바꾸기
역(reverse) 오히려 불만 오히려 만족 과도한 푸시 알림

당연 품질은 고객이 요청하지 않는다. 너무 당연해서 말할 생각을 못 한다. 그래서 인터뷰만으로 요구를 모으면 당연 품질이 빠지고, 빠진 것은 출시 후 불만으로 돌아온다. 앞의 “영수증 기능” 장면이 정확히 이것이다.

Kano 설문: 쌍으로 묻는다

Kano 분류는 한 기능에 대해 두 질문을 짝지어 묻는다.

  • 기능형: “이 기능이 있다면 어떻게 느끼십니까?”
  • 역기능형: “이 기능이 없다면 어떻게 느끼십니까?”

답은 각각 다섯 가지(좋다 / 당연하다 / 상관없다 / 참을 수 있다 / 싫다)이고, 두 답의 조합을 평가표로 범주에 대응시킨다. 이 평가표와 집계 방법은 Berger 등의 해설 논문(Center for Quality of Management Journal, 1993)으로 널리 퍼졌다.

                    없다면 →  좋다  당연  상관없음  참음  싫다
있다면 ↓ 좋다                  Q     A     A       A     O
        당연하다               R     I     I       I     M
        상관없다               R     I     I       I     M
        참을 수 있다           R     I     I       I     M
        싫다                   R     R     R       R     Q
A=매력 O=일원적 M=당연 I=무관심 R=역 Q=모순(질문 이해 실패)

실무 적용

설문을 집계하는 코드

응답자별 답 쌍을 평가표에 넣고, 가장 많은 범주를 고른다. 범주 비율로 “있으면 얼마나 좋아지나(better)”, “없으면 얼마나 나빠지나(worse)” 지표도 함께 본다.

from collections import Counter

# 답: 1=좋다 2=당연하다 3=상관없다 4=참을 수 있다 5=싫다
# 행 = 기능이 있을 때(기능형 질문), 열 = 없을 때(역기능형 질문)
TABLE = [
    # 없을때: 1    2    3    4    5
    ["Q", "A", "A", "A", "O"],  # 있을때 1 좋다
    ["R", "I", "I", "I", "M"],  # 2 당연하다
    ["R", "I", "I", "I", "M"],  # 3 상관없다
    ["R", "I", "I", "I", "M"],  # 4 참을 수 있다
    ["R", "R", "R", "R", "Q"],  # 5 싫다
]
NAMES = {"A": "매력", "O": "일원적", "M": "당연", "I": "무관심", "R": "역", "Q": "모순"}

def classify(answers):
    c = Counter(TABLE[f - 1][d - 1] for f, d in answers)
    a, o, m, i = (c[k] for k in "AOMI")
    n = a + o + m + i or 1
    better = (a + o) / n            # 있으면 만족이 오르는 정도
    worse = -(o + m) / n            # 없으면 불만이 커지는 정도
    top = c.most_common(1)[0][0]
    return NAMES[top], round(better, 2), round(worse, 2), dict(c)

survey = {   # 기능: [(기능형 답, 역기능형 답), ...] 응답자 10명 (가상 데이터)
    "결제 영수증 발행": [(2,5)]*6 + [(3,5)]*2 + [(1,5)]*2,
    "주문 진행 실시간 표시": [(1,5)]*5 + [(1,4)]*2 + [(2,5)]*3,
    "지난 주문 한 번에 다시 담기": [(1,3)]*6 + [(1,4)]*2 + [(3,3)]*2,
    "앱 테마 색 바꾸기": [(3,3)]*7 + [(1,3)]*2 + [(4,3)],
}
print(f"{'기능':<18}{'분류':<6}{'better':>8}{'worse':>8}")
for feat, ans in survey.items():
    cat, b, w, _ = classify(ans)
    print(f"{feat:<18}{cat:<6}{b:>8}{w:>8}")

기능                분류      better   worse
결제 영수증 발행         당연         0.2    -1.0
주문 진행 실시간 표시      일원적        0.7    -0.8
지난 주문 한 번에 다시 담기  매력         0.8     0.0
앱 테마 색 바꾸기        무관심        0.2     0.0

데이터는 설명용 가상값이다. 읽는 법이 중요하다. 영수증은 better 가 낮아 “있어도 칭찬받지 못하지만” worse 가 -1.0 이라 빼면 모두가 불만이다. 다시 담기는 반대로 없어도 아무도 불평하지 않지만 있으면 만족이 크게 오른다.

Kano 에서 MoSCoW 로

두 도구를 이어 붙이는 기본 규칙은 이렇다.

Kano 범주 MoSCoW 기본값 이유
당연 Must 없으면 불만. 최소 사용 가능 부분집합에 들어간다
일원적 Should (핵심 몇 개는 Must) 경쟁력의 본체. 수준을 조절할 수 있다
매력 Could (차별화 전략이면 Should) 없어도 불만은 없으니 완충으로 쓸 수 있다
무관심 Won’t this time 노력 대비 효과가 없다
역 Won’t, 또는 끌 수 있게 일부에게는 오히려 해롭다

그리고 마지막에 DSDM 규칙으로 검산한다. Must 의 노력 합이 60% 를 넘으면, Must 를 다시 들여다보거나 범위를 줄인다.

기타 기법과의 관계

MoSCoW 와 Kano 는 가치의 성격을 본다. 시간에 따른 가치 손실(지연 비용)이나 의존 관계는 따로 봐야 한다. 지연 비용 개념은 Donald G. Reinertsen, The Principles of Product Development Flow (Celeritas, 2009)가 원전이다. 일정 압박이 큰 팀이라면 “이 기능을 한 달 늦추면 무엇을 잃는가” 라는 질문을 추가한다.

흔한 오해와 함정

  • Must 인플레이션. 이해관계자가 각자 매긴 Must 를 그대로 합치면 Must 가 60% 를 넘는다. Must 는 “보장 약속” 이므로 팀이 함께 정하고, 노력 합으로 검산한다.
  • Won’t 를 “영원히 안 함” 으로 읽는다. 원래 뜻은 “이번 기간에는 안 함” 이다. 이 칸이 있어서 이해관계자가 덜 저항하고 합의할 수 있다.
  • Kano 범주가 고정돼 있다고 본다. 범주는 고객층과 시점에 따라 다르다. 몇 년 전의 매력 기능이 지금은 당연 기능일 수 있다. 정기적으로 다시 조사한다.
  • 응답자 집단을 섞는다. 신규 고객과 단골의 Kano 결과는 다를 수 있다. 세그먼트별로 따로 집계하지 않으면 범주가 희석된다.
  • 인터뷰에서 나온 것만 우선순위에 올린다. 당연 품질은 말로 나오지 않는다. 경쟁 제품 점검, 지원 문의 기록, 관찰로 보충해야 한다.

확인 문제

  1. DSDM 이 Must 노력을 60% 이하로 두라고 하는 이유는?
  2. “Won’t Have this time” 에서 “this time” 이 빠지면 어떤 문제가 생기는가?
  3. Kano 의 1984년 논문이 제안한 “이차원적 인식” 이란 무엇인가?
  4. 당연 품질이 인터뷰로 잘 도출되지 않는 이유는?
  5. 위 코드에서 “결제 영수증 발행” 이 better 0.2, worse -1.0 이 나온 것을 제품 관점에서 해석하라.

풀이

  1. Must 는 인도를 보장하는 약속이고, Should·Could 가 일정 변동을 흡수하는 완충 역할을 한다. Must 비중이 너무 크면 완충이 사라져 하나만 밀려도 약속이 깨진다.
  2. 이해관계자가 영구 탈락으로 받아들여 저항하거나, 반대로 “다음에 할 것” 목록이 관리되지 않아 같은 요구가 다시 불쑥 나타난다.
  3. 품질 요소의 충족 여부와 만족·불만의 관계를 하나의 직선으로 보지 않고, 충족·불충족 각각에 대한 반응을 따로 보아 매력·일원적·당연 등으로 분류하는 관점이다.
  4. 고객에게 너무 당연해서 말할 필요를 느끼지 못하기 때문이다. 없을 때에야 불만으로 드러난다.
  5. 있어도 칭찬받지 못하지만 없으면 거의 모든 응답자가 불만을 느끼는 당연 기능이다. 화려하게 만들 필요는 없지만 반드시 넣어야 하는 Must 다.

더 읽을거리 (References)