리파인먼트 질문 설계와 스토리 슬라이싱 — 모호함을 발견하고 자르는 기술

개념

리파인먼트에서 QA가 실제로 하는 일

모듈 7(레슨 8)에서 "백로그 리파인먼트에서 스토리의 모호함과 테스트 가능성을 지적한다"고 정리했다. 이 레슨은 그 한 줄을 절차 로 펼친다. 실제로 리파인먼트에서 QA가 하는 일은 세 단계다.

1. 캐묻기   이 스토리에서 아직 정해지지 않은 것은 무엇인가
2. 예시화   말로 합의한 규칙을 구체적인 숫자와 상황으로 바꾼다
3. 자르기   지금 크기로는 스프린트 안에 못 끝나는 것을 조각낸다

세 단계는 순서가 있다. 자르기를 먼저 하면 잘못된 선을 따라 자른다 — 모호함이 남아 있는 상태에서 쪼개면 조각마다 같은 모호함이 복제된다.

1단계 — 질문을 즉흥으로 던지지 않는다

모듈 2(레슨 3)에서 요구사항의 모호함과 공백을 찾는 법을 배웠다. 리파인먼트는 그 기법을 시간 제한 아래에서 쓰는 자리다. 스토리 하나에 쓸 수 있는 시간은 보통 10~20분이고, 그 안에 모든 질문을 던질 수는 없다. 그래서 위험 순으로 질문 세트를 미리 만들어 둔다 .

마지막 관측 질문은 QA가 아니면 아무도 하지 않는 질문이다. "이 기능이 망가진 걸 우리가 어떻게 알게 되나요? 사용자 문의로 알게 되나요?"

질문을 던지는 순서도 기술이다. 모든 질문을 한 번에 쏟으면 개발자와 PO가 방어적으로 변한다. 위험이 큰 카테고리 두세 개만 고르고, 나머지는 미해결 질문 목록 에 적어 비동기로 답을 받는다.

2단계 — 예제 매핑으로 25분 안에 정리하기

질문과 답이 대화로만 오가면 다음 날 기억이 갈린다. Matt Wynne이 제안한 예제 매핑(Example Mapping) 은 그 대화를 네 가지 색 카드로 눈에 보이게 만든다.

┌──────────────────────────────────────────────┐
│ 노랑 : 스토리      "장바구니 쿠폰 적용"       │  1장
└──────────────────────────────────────────────┘
   ┌───────────────┐  ┌───────────────┐  ┌───────────────┐
   │ 파랑: 규칙     │  │ 파랑: 규칙     │  │ 파랑: 규칙     │
   │ 쿠폰 1장만     │  │ 최소주문금액   │  │ 만료쿠폰 불가  │
   └───────────────┘  └───────────────┘  └───────────────┘
   ┌───────────────┐  ┌───────────────┐  ┌───────────────┐
   │ 초록: 예시     │  │ 초록: 예시     │  │ 초록: 예시     │
   │ 2장 담으면     │  │ 29,900원에    │  │ 어제 만료 →   │
   │ 두 번째 거부   │  │ 3만원 쿠폰 거부│  │ 목록에 안 보임 │
   └───────────────┘  └───────────────┘  └───────────────┘
              ┌─────────────────────────────┐
              │ 빨강: 미해결 질문            │
              │ 포인트와 중복 사용 가능한가? │
              └─────────────────────────────┘

운영 규칙은 단순하다.

• 한 번에 한 스토리, 25분 타임박스. 25분 안에 끝나지 않으면 그 자체가 신호다.
• 초록(예시)은 반드시 구체적인 값으로. "최소 주문 금액 미만이면 거부"는 규칙이지 예시가 아니다. "29,900원 장바구니에 3만 원 이상 쿠폰 → 적용 불가"가 예시다.
• 빨강이 쌓이면 멈춘다. 미해결 질문이 서너 장 넘으면 스토리를 스프린트에 넣지 않는다. 지금 답을 못 찾는 것을 스프린트 안에서 찾을 확률은 낮다.

세션이 끝나면 읽는 법 이 있다.

마지막 행이 중요하다. 예시를 못 만드는 규칙은 구현도 못 한다. 리파인먼트에서 이것 하나만 잡아도 스프린트 중반의 하루가 절약된다.

3단계 — 슬라이싱 패턴

이제 자른다. Mike Cohn의 SPIDR 은 다섯 개의 절단선을 제시한다.

각 절단선의 판정 기준은 하나다. 잘린 조각 하나만 릴리스해도 사용자에게 가치가 있는가. "프런트엔드만" "백엔드만"으로 자르는 것은 슬라이싱이 아니라 작업 분해(task breakdown)다. 그렇게 자르면 조각 하나로는 아무것도 못 하고, 결국 둘 다 끝나는 스프린트 마지막 날에 테스트가 몰린다(레슨 1의 몰림 지표).

나쁜 자르기 (레이어 분해)          좋은 자르기 (기능 슬라이스)
┌──────────────┐                   ┌──────────────┐
│ UI 작업      │ ← 혼자선 쓸모없음 │ 카드 결제    │ ← 이것만 나가도
├──────────────┤                   │ 취소 (전체)  │   사용자가 쓴다
│ API 작업     │                   ├──────────────┤
├──────────────┤                   │ 간편결제     │
│ DB 작업      │                   │ 취소 (전체)  │
└──────────────┘                   └──────────────┘

QA가 슬라이싱에서 내는 고유한 기여

슬라이싱은 보통 PO와 개발의 일로 여겨지지만, QA가 던질 수 있는 질문이 따로 있다.

1. "이 조각만 릴리스했을 때 테스트할 수 있나요?" — 테스트할 수 없는 조각은 완료를 판정할 수 없다.
2. "이 조각과 저 조각 사이에 반쪽 상태가 생기나요?" — 카드 취소만 있고 간편결제 취소가 없는 동안 사용자가 보는 화면은 어떻게 되는가. 그 중간 상태 자체가 테스트 대상이다.
3. "조각 순서를 바꾸면 위험이 줄어드나요?" — 가장 불확실한 조각을 먼저 하면 스프린트 후반의 놀람이 줄어든다.

세 번째가 특히 강력하다. 팀은 대개 쉬운 조각부터 하려 하지만, 위험 기반 사고(모듈 4 레슨 2)로 보면 불확실한 조각부터 해야 한다.

테스트 가능성 판정 — INVEST의 T

Bill Wake의 INVEST 기준 중 마지막 T가 Testable이다. 잘린 조각마다 이것만 확인한다.

네 개 중 하나라도 "아니오"면 리파인먼트에서 해결한다. 스프린트가 시작된 뒤에 발견하면 그 스토리는 늦는다.

실무에서 왜 필요한가

리파인먼트에서 발견한 모호함 하나의 가치는 시점으로 계산된다. 같은 모호함을 스프린트 중반에 발견하면 개발이 멈추고 되돌아가고, 릴리스 후에 발견하면 운영 데이터를 고쳐야 한다. 모듈 1에서 배운 "결함은 일찍 발견할수록 싸다"가 스크럼에서 가장 구체적으로 적용되는 자리가 리파인먼트다.

슬라이싱은 여기에 한 가지를 더 준다. 작은 조각은 테스트 시점을 앞당긴다. 스토리가 크면 개발이 끝나는 시점이 스프린트 후반일 수밖에 없고, 그러면 레슨 1에서 본 몰림이 구조적으로 생긴다. "테스트할 시간이 없다"의 진짜 원인이 스토리 크기인 경우가 대부분이다.

실습 과제

과제 1 — 예제 매핑 25분 세션 (25분)

다음 스토리로 예제 매핑을 진행한다. 혼자 한다면 포스트잇 대신 네 개의 표로 나눠 적는다.

스토리 — 회원은 장바구니에서 적립 포인트를 사용해 결제 금액을 줄일 수 있다. 알려진 것 — 1포인트 = 1원. 포인트는 결제 완료 시 차감된다.

파랑(규칙)·초록(예시)·빨강(질문)을 채운 뒤, 본문의 "지도 읽는 법" 표로 이 스토리의 상태를 판정하고 다음 조치를 적는다. 초록 카드는 반드시 구체적인 숫자를 포함해야 한다.

과제 2 — SPIDR로 자르기 (20분)

다음 스토리를 SPIDR의 다섯 절단선 중 최소 두 가지 로 각각 잘라 본다. 같은 스토리를 다른 선으로 자르면 조각이 어떻게 달라지는지 비교하는 것이 이 과제의 목적이다.

스토리 — 판매자는 자신의 상품 재고를 엑셀 파일로 일괄 업로드해 수정할 수 있다.

각 절단 방식에 대해 (1) 조각 목록, (2) 첫 번째 조각만 릴리스했을 때 사용자가 얻는 가치, (3) 조각 사이에 생기는 반쪽 상태를 적는다. 마지막으로 두 방식 중 어느 쪽을 고를지와 그 이유를 쓴다.

과제 3 — 질문 세트 개인화 (15분)

본문의 여덟 개 질문 카테고리를 자기 제품에 맞게 다시 쓴다. 최근 6개월간 운영에서 발생한 결함 세 건을 떠올려, 그 결함을 리파인먼트에서 잡을 수 있었을 질문이 세트에 있는지 확인한다. 없으면 카테고리를 추가하고, 세 번 이상 아무것도 잡지 못한 카테고리는 지운다.

자가 체크리스트

• 리파인먼트에서 캐묻기·예시화·자르기의 순서를 지켜야 하는 이유를 설명할 수 있다
• 위험 카테고리별 질문 세트를 만들고, 시간 제약 아래 우선순위를 정해 던질 수 있다
• 예제 매핑의 네 가지 카드를 구분하고 25분 세션을 진행할 수 있다
• 규칙과 예시의 차이를 말할 수 있고, 예시를 구체적인 값으로 쓸 수 있다
• 예제 매핑 결과의 모양을 보고 스토리의 상태를 판정할 수 있다
• SPIDR의 다섯 절단선을 설명하고 하나의 스토리를 두 가지 방식으로 자를 수 있다
• 레이어 분해와 기능 슬라이싱의 차이를 설명할 수 있다
• 잘린 조각의 테스트 가능성을 관측·제어·기대결과·격리 네 기준으로 판정할 수 있다

흔한 실수

• 모호함이 남은 채로 먼저 자른다. 조각마다 같은 모호함이 복제되고, 스프린트 중반에 세 번 되묻게 된다. 캐묻기 → 예시화 → 자르기 순서를 지킨다.
• 예시 없이 규칙만 합의한다. 말로는 다 동의했는데 구현이 다르게 나온다. 구체적인 숫자가 들어간 예시가 하나도 없는 규칙은 합의된 것이 아니다.
• 레이어로 자르고 슬라이싱했다고 한다. UI/API/DB 분해는 작업 분해다. 조각 하나만으로 사용자가 얻는 가치가 없으면 자른 것이 아니다.
• 쉬운 조각부터 한다. 불확실한 조각이 스프린트 후반으로 밀리면 그 스프린트는 후반에 놀란다. 위험이 큰 조각을 먼저 배치한다.
• 리파인먼트에서 모든 질문을 다 던진다. 팀이 방어적으로 변하고 회의가 길어진다. 위험 상위 두세 카테고리만 그 자리에서, 나머지는 비동기로.
• 미해결 질문이 남은 스토리를 스프린트에 넣는다. "하면서 정하죠"는 대개 스프린트 중반에 재작업으로 돌아온다. 빨강 카드가 세 장을 넘으면 스파이크로 돌린다.

참고 자료

• Example Mapping (Cucumber 공식 문서) — 네 가지 카드와 진행 절차
• Introducing Example Mapping — Matt Wynne — 기법의 원 출처와 25분 타임박스 근거
• SPIDR: Five Simple but Powerful Ways to Split User Stories — Mike Cohn — 슬라이싱 다섯 절단선
• Bill Wake, INVEST 기준(Independent, Negotiable, Valuable, Estimable, Small, Testable) — 원문 확인
• 레슨 s1-m02-l03 — 요구사항의 모호함과 공백 찾기
• 레슨 s2-m04-l02 — 위험 기반 테스팅 (조각 순서 결정의 근거)
• 레슨 s2-m48-l02 — 완료의 정의(DoD)
• 레슨 s2-m07-l08 — 애자일에서 QA가 실제로 하는 일