김희준
‘주문 결제를 만든다’는 요청은 개발 범위를 논의하기에 너무 큽니다. 이를 ‘데이터베이스 만들기’, ‘화면 만들기’, ‘결제 테스트하기’로 나누면 작업은 작아지지만, 어느 하나만으로는 고객이 상품을 살 수 없습니다.
더 나은 분할은 처음부터 끝까지 작동하는, 범위를 좁힌 구매 경로입니다. 공동 스크럼 계획 보드에서 작은 단위별 동작, 인수 조건 예시, 나중으로 미룰 작업을 비교하세요. 개발자가 구현 작업을 논의하는 동안에도 고객이 얻을 결과를 보이게 둡니다.
작아진 스토리인가, 기술 작업뿐인가?
Agile Alliance의 스토리 분할 정의는 나눈 각 스토리에도 비즈니스 가치를 남깁니다. 단위 하나가 완전한 상용 출시여야 한다는 뜻은 아닙니다. 기술 계층 하나의 완료가 아니라 유용한 행동의 변화를 보여줄 수 있어야 한다는 의미입니다.
사용자는 구매를 완료하거나 저장된 주문을 조회하거나 적용 가능한 할인을 사용할 수 있습니다. 그러나 주변 동작 없이 ‘데이터베이스 테이블’을 유용하게 사용할 수는 없습니다. 데이터베이스 변경, 인터페이스 작업, 테스트는 여전히 필요합니다. 독립적인 고객 성과라고 이름 붙이지 말고 스토리를 뒷받침하는 구현 작업으로 배치합니다.
수직 분할은 시스템의 필요한 부분을 통과하는 좁은 경로를 뜻합니다. 모든 스토리를 그림에서 세로 열로 그려야 한다는 뜻은 아닙니다. Humanizing Work의 스토리 분할 가이드는 이 차이와 유용한 동작을 유지하면서 범위를 줄이는 패턴을 설명합니다.
주문 결제 예시의 경계 정하기
고객이 재고 상품을 둘러보고 장바구니에 넣을 수 있는 상점을 가정해 보겠습니다. 이제 주문 결제가 필요합니다. 초기 요청에는 여러 결제 수단, 여러 배송 지역, 할인 코드, 저장된 주소, 비회원 구매가 들어 있습니다. 첫 구매 경로가 작동하는지 알아보는 데 모두 필요한 것은 아닙니다.
이 가상의 출시에서는 기존 가입 고객이 재고 상품을 구매하고 하나의 지원 지역으로 배송받는 범위를 선택합니다. 지원 결제 수단 하나와 기존 기본 배송 옵션을 제공합니다. 쿠폰, 새 주소 저장, 해외 배송은 아직 제공하지 않습니다.
첫 스토리는 ‘가입 고객은 지원하는 결제 수단으로 장바구니의 재고 상품을 구매하고 주문 확인을 받을 수 있다’입니다. 범위는 좁지만 고객은 여전히 구매를 완료합니다.
두 가지 분할 방식 비교하기
| 구성 요소별 분할 | 그것만으로 부족한 이유 | 고객 행동 중심의 단위 |
|---|---|---|
| 주문 데이터베이스를 만든다. | 고객이 주문할 곳이 없습니다. | 기본 구매를 완료하고 주문을 기록한다. |
| 결제 화면을 만든다. | 거래와 주문 동작이 없는 화면은 구매를 확인할 수 없습니다. | 첫 지원 수단으로 결제하고 승인 또는 거절 결과를 명확하게 받는다. |
| 할인 계산을 추가한다. | 계산만으로는 처음부터 끝까지 이어지는 할인 경험이 되지 않습니다. | 작동하는 주문 결제에 합의한 할인 규칙 하나를 적용한다. |
| 주소 테이블을 만든다. | 주소 저장만으로는 고객이 주소를 골라 배송 정보를 완성할 수 있는지 알 수 없습니다. | 작동하는 구매 과정에서 저장된 주소를 선택한다. |
오른쪽 항목들이 각각 별도의 출시를 뜻하는 것은 아닙니다. 팀이 논의하고 순서를 정할 후보입니다. 성공적인 구매에는 결제 처리가 포함되므로 첫 두 행은 같은 초기 스토리에 속할 수 있습니다. 카드를 늘리기 위해 억지로 나누지 마세요.
첫 단위를 테스트할 수 있게 만들기
‘충분히 작다’고 판단하기 전에 예시를 작성합니다. 정상 경로를 한 문장으로만 쓰면 동작을 실제로 사용 가능하게 만드는 작업이 숨을 수 있습니다.
| 상황 | 기대하는 동작 | 범위 결정 |
|---|---|---|
| 장바구니의 상품에 재고가 있고 고객이 지원되는 결제 수단의 유효한 정보를 입력한다. | 주문이 기록되고 확인 화면이 보이며 주문 번호로 해당 구매를 식별한다. | 첫 단위에 포함한다. |
| 결제가 거절된다. | 구매가 확정되지 않았음을 알리고 결제 정보를 수정해 다시 시도할 수 있다. | 포함한다. 실패 처리도 구매 경로의 일부다. |
| 첫 시도의 결과를 모르는 상태에서 다시 제출한다. | 동작을 반복했다는 이유만으로 중복 구매를 만들지 않는다. | 스토리를 수용하기 전에 필요한 동작을 개발팀과 결정한다. |
| 결제를 시도할 때 상품 재고가 없어졌다. | 잘못된 성공 메시지 대신 어떤 상품 때문에 완료할 수 없는지 알린다. | 포함한다. 적절한 시점에 재고를 확인해야 한다. |
| 고객이 지원하지 않는 결제 수단이나 배송 지역을 원한다. | 사용 가능한 선택지를 명확히 하고 사용할 수 없는 옵션을 작동하는 것처럼 표시하지 않는다. | 추가 수단과 지역은 이후 작업으로 남긴다. |
이 예시들은 원하는 동작을 설명하며 결제 구현 명세는 아닙니다. 팀의 기존 보안, 접근성, 개인정보 보호, 출시 요건은 그대로 적용됩니다. 필요한 보호 조치나 오류 처리를 없애는 것과 비즈니스 범위를 줄이는 것은 다릅니다.
해소할 불확실성을 기준으로 다음 단위 고르기
기본 구매가 작동하면 다음 선택지가 생깁니다. 다른 결제 수단은 결제할 수 있는 고객을 늘립니다. 할인 규칙은 가격 계산과 고객에게 보여줄 설명을 바꿉니다. 저장된 주소는 재방문 고객의 반복 입력을 줄입니다. 각각 다른 필요에 대응하므로 자동으로 다음 순서가 되는 항목은 없습니다.
어떤 고객 집단이 막혀 있으며 그 근거가 무엇인지 물어보세요. 지원 지역 안에 시범 이용 대상이 있다면 해외 배송보다 혼란스러운 주문 확인을 고치는 일이 더 급할 수 있습니다. 결제 수단이 그 대상을 배제한다면 첫 단위를 잘못 선택했을 수 있습니다.
탐색과 구현도 구분합니다. 익숙하지 않은 결제 제공업체를 짧게 조사하면 기술적 불확실성은 줄지만, 그 자체가 완료된 구매 스토리는 아닙니다. 명확한 질문과 필요한 근거를 정하세요. ‘사용자로서’로 문장을 시작했다고 고객 가치가 되는 것은 아닙니다.
Boardmix에서 분할 논의 정리하기
Boardmix 보드 맨 위에 큰 주문 결제 요청을 놓습니다. 아래에는 첫 사용 가능한 단위, 이후 선택지, 미해결 질문 영역을 만듭니다. 기술 작업은 별도의 사용자 스토리 목록처럼 두지 말고 그 작업이 가능하게 하는 단위 아래에 놓습니다.
첫 단위 카드 옆에 인수 조건 예시를 추가합니다. ‘중복 제출 동작’은 팀이 기대 결과에 합의할 때까지 질문 영역에 둡니다. 관련 스토리와 연결하면 해당 스토리를 논의할 때 불확실성을 볼 수 있습니다.
이 주문 결제 작업을 전체 쇼핑 여정 안에 놓고 싶다면 사용자 스토리 맵이 유용합니다. 분할 보드는 더 좁은 질문에 답합니다. 이 여정의 한 부분에서 만들 수 있는 가장 작은 유용한 변화는 무엇일까요?
선택한 스토리를 팀의 개발 관리 시스템에 옮기기 전에 결과와 예시를 함께 읽습니다. 보여줄 수 있는 결과가 기술 계층 하나의 존재뿐이라면 더 작은 처음부터 끝까지의 동작을 찾아보세요. Boardmix를 열어 분할 후보를 놓고 팀과 비교할 수 있습니다.
