개념
정책서와 시스템 사이의 번역
회사의 환불 정책서에는 이렇게 쓰여 있다. "상품 수령 후 7일 이내 단순 변심 반품이 가능하며, 이 경우 왕복 배송비는 고객이 부담한다. 단, 상품 하자의 경우 기간과 무관하게 전액 환불하며 배송비는 회사가 부담한다. 쿠폰 사용 주문의 부분 반품 시 쿠폰 할인액은 비례 차감한다."
사람은 이 문단을 읽고 대략 이해한다. 시스템은 대략 이해할 수 없다. "7일 이내"는 수령일을 포함하는가? "상품 하자"는 누가 판정하는가? 하자 판정 전에 반품이 접수되면 배송비는 누가 내는가? "비례 차감"은 원 단위에서 어떻게 반올림하는가? 쿠폰이 최소 주문 금액 조건이 있었는데 부분 반품 후 그 조건을 밑돌면?
이 질문들에 답을 붙여 모호함 없는 규칙 으로 만드는 것이 BA의 핵심 결과물이다. QA 시절 요구사항 리뷰에서 던지던 질문(모듈 2 레슨 3)을, BA는 규칙 카탈로그로 미리 답한다.
1단계 — 원자적 규칙으로 쪼갠다
비즈니스 규칙은 하나의 조건과 하나의 결과 로 쪼갤 때 검증 가능해진다. 쪼개는 요령은 "그리고", "단", "이 경우" 같은 접속어에서 끊는 것이다.
| ID | 규칙 | 유형 |
|---|---|---|
| BR-RF-01 | 단순 변심 반품은 수령일(D0) 다음 날부터 D+7 23:59까지 접수할 수 있다 | 제약 |
| BR-RF-02 | 단순 변심 반품의 왕복 배송비는 고객이 부담한다 | 계산 |
| BR-RF-03 | 상품 하자로 판정된 반품은 접수 기한이 없다 | 제약 |
| BR-RF-04 | 상품 하자 반품의 배송비는 회사가 부담한다 | 계산 |
| BR-RF-05 | 하자 여부는 검수 담당자가 판정하며, 판정 전에는 단순 변심 기준으로 접수한다 | 절차 |
| BR-RF-06 | 쿠폰 사용 주문의 부분 반품 시 쿠폰 할인액을 반품 상품 금액 비율로 차감한다(원 미만 절사) | 계산 |
| BR-RF-07 | 부분 반품 후 남은 주문이 쿠폰 최소 주문 금액 미만이 되어도 쿠폰 혜택은 회수하지 않는다 | 제약 |
규칙에는 유형을 붙인다. 제약(허용·금지), 계산(값 산출), 절차(순서·권한), 추론(조건에서 사실 도출). 유형에 따라 테스트 방법이 다르다 — 계산 규칙은 경계값과 반올림, 제약 규칙은 허용·금지 경계, 절차 규칙은 상태 전이.
BR-RF-05와 BR-RF-07은 원래 정책서에 없던 규칙이다. 쪼개는 과정에서 발견한 빈틈을 현업과 확인해 새로 만든 것이다. 이것이 규칙 카탈로그의 진짜 가치다.
2단계 — 규칙 카탈로그로 관리한다
규칙은 요구사항 문서 여기저기에 흩어지면 관리가 안 된다. 한 곳에 모은다.
| 항목 | 내용 |
|---|---|
| ID | BR-RF-06 |
| 규칙 | 쿠폰 사용 주문의 부분 반품 시 쿠폰 할인액을 반품 상품 금액 비율로 차감(원 미만 절사) |
| 출처 | 환불 정책 v3.2 4조, 재무팀 확인(2026-09-10) |
| 소유자 | 재무팀 |
| 적용 화면·기능 | 반품 신청, 환불 금액 계산 API, 정산 |
| 관련 테스트 | TC-RF-061 ~ TC-RF-068 |
| 변경 이력 | v1 반올림 → v2 절사(2026-09-10, 재무팀 요청) |
출처와 소유자 가 중요하다. 규칙이 왜 이렇게 정해졌고 바꾸려면 누구에게 물어야 하는지를 남긴다. 금융·의료처럼 규정이 근거인 도메인에서는 출처가 법 조문이나 감독 규정이 된다(모듈 41).
3단계 — 얽힌 규칙은 결정표로
조건이 여러 개 얽힌 규칙은 문장으로 쓰면 반드시 빈칸이 생긴다. 결정표(모듈 3 레슨 3)로 쓴다.
| 조건 / 규칙 | R1 | R2 | R3 | R4 | R5 |
|---|---|---|---|---|---|
| 반품 사유 | 변심 | 변심 | 하자 | 하자 | 판정 전 |
| 접수일 D+7 이내 | 예 | 아니오 | 예 | 아니오 | - |
| 결과: 접수 가능 | 예 | 아니오 | 예 | 예 | 예(변심 기준) |
| 결과: 배송비 부담 | 고객 | - | 회사 | 회사 | 고객(하자 판정 시 환급) |
R5의 "하자 판정 시 환급"은 결정표를 채우다 발견한 규칙이다. 판정 전에 고객이 배송비를 냈다가 하자로 판정되면 돌려줘야 한다. 이것이 없으면 시스템은 하자 반품에서 배송비를 받은 채로 끝난다.
결정표의 모든 열은 그대로 테스트 케이스 가 된다. BA가 결정표를 쓰면 QA는 설계 시간을 크게 줄일 수 있다.
4단계 — 상태가 바뀌는 규칙은 상태 전이로
반품처럼 여러 단계를 거치는 업무는 상태 전이로 그린다.
[반품 상태]
접수됨 → 회수 중 → 검수 중 → ┬ 하자 확정 → 환불 완료(전액, 배송비 환급)
└ 변심 확정 → 환불 완료(배송비 차감)
접수됨 → 취소됨 (회수 전 고객 취소)
검수 중 → 반려됨 (상품 훼손 등 반품 불가) → 재발송상태 전이 모델에서 확인할 질문: 모든 상태에서 나가는 길이 있는가? 허용되지 않는 전이(환불 완료 → 회수 중)는 막혀 있는가? 각 전이의 권한자는 누구인가?
5단계 — 예외를 체계적으로 찾는다
예외는 규칙보다 많다. 체계적으로 찾는 질문 목록을 쓴다.
| 관점 | 질문 |
|---|---|
| 경계 | 기한 당일·마감 1초 전·자정·휴일은? |
| 부분 | 여러 상품 중 일부만? 수량 중 일부만? |
| 순서 | 환불 처리 중에 교환 신청이 들어오면? |
| 동시성 | 고객 취소와 회수 기사 도착이 동시에? |
| 외부 | 결제 수단이 해지된 카드라면? 결제 대행사 장애 중이면? |
| 과거 데이터 | 정책 변경 전 주문의 반품은 어느 정책을 따르나? |
| 권한 | 고객센터가 기한을 넘겨 예외 승인할 수 있나? 누가? |
"과거 데이터" 질문이 가장 자주 빠진다. 정책이 바뀌면 이전 주문에 어떤 정책을 적용할지 정해야 한다.
6단계 — 사용자 스토리와 수용 기준으로
규칙과 예외가 정리되면 개발 팀이 쓰는 형태로 옮긴다.
[사용자 스토리]
고객으로서, 하자 상품을 기한과 무관하게 반품하고 싶다. 그래야 불량품 때문에 손해를 보지 않는다.
[수용 기준 — Given/When/Then]
AC1 (BR-RF-03) Given 수령 후 30일 지난 주문
When 반품 사유를 "상품 하자"로 신청하면
Then 접수가 허용되고 상태는 "접수됨"이 된다
AC2 (BR-RF-05) Given 하자 판정 전 반품
When 회수 배송비 결제를 요청하면
Then 고객 부담으로 결제되고, 하자 확정 시 환급 예정 안내가 표시된다
AC3 (BR-RF-05) Given 검수 결과 "하자 확정"
When 환불이 처리되면
Then 상품 금액 전액과 고객이 낸 배송비가 함께 환불된다수용 기준마다 규칙 ID를 붙인다. 이렇게 하면 규칙 → 수용 기준 → 테스트 케이스 가 1:1로 추적된다(모듈 2 레슨 5의 추적성). 규칙이 바뀌면 어떤 수용 기준과 테스트를 고쳐야 하는지 바로 보인다.
실무에서 왜 필요한가
정책과 시스템이 어긋나는 결함은 운영에서 발견되면 비싸다. 환불 금액이 1원씩 틀리면 수만 건의 주문에서 회계 차이가 나고, 규정과 다르게 동작하면 감독 기관의 지적을 받는다. 규칙 카탈로그와 결정표는 이런 결함을 요구사항 단계에서 없앤다. 또 규칙에 출처와 소유자가 있으면 정책이 바뀔 때 영향 범위를 빠르게 찾을 수 있다.
채용시장에서의 위치
BA·서비스 기획 면접에서 "정책서를 요구사항으로 어떻게 바꾸나요"는 핵심 질문이다. 정책 한 문단을 원자적 규칙으로 쪼개고, 결정표로 빈칸을 찾고, 새로 발견한 규칙을 현업과 확인했다는 이야기는 QA 출신 BA의 강점을 가장 잘 보여 준다.