핵심 요약
- 주문은 생성부터 결제완료와 배송과 구매확정까지 직선처럼 보이지만 중간 분기가 많아요.
- 취소와 반품과 부분 취소는 같은 예외가 아니라 서로 다른 시점과 책임을 가져요.
- 상태별 허용 액션을 먼저 정해야 운영 화면과 자동화 규칙이 일관되게 맞아 떨어져요.
1주문은 직선이 아니라 분기가 많은 흐름이에요
주문 상태를 처음 설계할 때는 보통 주문 생성, 결제 대기, 결제 완료, 배송 준비, 배송 중, 구매 확정처럼 직선 흐름을 떠올려요. 발표 자료나 화면 설명에는 이 구조가 가장 깔끔해 보여요. 문제는 실제 운영이 그 선을 그대로 따라가지 않는다는 데 있어요. 결제 실패, 입금 대기, 재고 부족, 고객 요청, 묶음 주문 분리 같은 사건이 끼어들면서 주문은 여러 갈래로 갈라져요.
그래서 주문 설계의 핵심은 상태 수를 많이 만드는 일이 아니라 어디서 분기되는지 먼저 정하는 일이에요. 결제 전 분기와 배송 전 분기와 배송 후 분기를 한 줄로 이어 붙이면 운영자는 현재 주문이 왜 이 상태에 있는지 이해하기 어려워요. 직선형 설명은 교육용으로는 편하지만, 운영용으로는 충분하지 않아요.
2취소·반품·부분 취소는 같은 예외가 아니라 서로 다른 시점·책임이에요
취소와 반품과 부분 취소를 모두 예외 처리로 묶어 두면 처음에는 단순해 보여요. 하지만 이 셋은 발생 시점도 다르고, 누구 책임으로 처리되는지도 다르며, 금액 계산 방식도 달라요. 배송 전에 고객이 마음을 바꾼 취소와, 상품 수령 뒤 상태를 확인하고 되돌리는 반품은 같은 흐름으로 다룰 수 없어요. 여러 상품 중 일부만 취소하는 부분 취소는 더 복잡해요.
| 이벤트 | 시점 | 책임 주체 | 결제 측 처리 |
|---|---|---|---|
| 취소 | 배송 전 | 고객 요청 또는 운영 판단 | 승인 취소 중심 |
| 반품 | 수령 후 | 고객 요청 + 운영 검수 | 환급 처리 중심 |
| 부분 취소 | 결제 후 일부 품목 대상 | 고객 요청 + 운영 확인 | 금액 재계산 후 일부 복원 |
이 표가 없는 상태에서는 운영팀이 취소라고 말한 사건을 개발팀은 반품으로 처리하고, CS 는 부분 환불로 안내하는 일이 반복돼요. 예외를 한 단어로 뭉개지 말고 사건별로 나눠야 이후 화면과 자동화도 같이 정리돼요.
3상태별 허용 액션을 먼저 정해야 운영·자동화가 맞아떨어져요
주문 상태를 설계할 때 가장 실무적인 질문은 이름이 아니라 액션이에요. 결제 완료 상태에서는 무엇을 할 수 있는가, 배송 준비 상태에서는 무엇을 막아야 하는가, 배송 중 상태에서는 누가 어떤 버튼을 누를 수 있는가를 먼저 정해야 해요. 이 화이트리스트가 있어야 관리자 화면 권한도 정리되고, 자동 전이 규칙도 무리 없이 붙어요.
예를 들어 배송 시작 이후에는 단순 취소를 막고 반품 절차로 넘긴다는 기준이 있어야 해요. 마찬가지로 결제 완료 직후 일정 시간 안에는 고객이 직접 취소할 수 있고, 이후에는 운영 승인만 가능하게 두는 식의 분기점도 필요해요. 상태 정의 없이 버튼부터 만들면 권한 예외가 계속 늘어나고, 자동화는 늘 사람 검토를 요구하는 반자동 상태에 머물러요.
4상태 표준화는 용어·코드·화면 세 축을 함께 봐야 해요
상태 표준화가 실패하는 가장 흔한 이유는 세 축이 따로 움직이기 때문이에요. 개발팀은 짧은 코드값을 쓰고, 운영 화면은 이해하기 쉬운 이름을 붙이고, CS 문구는 고객 친화적으로 다시 풀어써요. 각각은 합리적이지만 같은 상태를 서로 다른 단어로 부르면 사고가 생겨요. 고객에게는 배송 준비라고 안내했는데 관리자 화면에는 출고 대기라고 뜨고, 내부 문서에는 또 다른 용어가 적히는 식이에요.
그래서 주문 상태는 용어집 하나로 끝내면 안 돼요. 코드값, 운영 화면 표기, 고객 안내 문구를 한 세트로 묶어 사전처럼 관리해야 해요. 세 축 중 하나라도 어긋나면 신규 멤버 온보딩이 늦어지고, 이슈가 생길 때마다 같은 설명을 반복하게 돼요. 상태 표준화는 개발 편의가 아니라 운영 커뮤니케이션 비용을 줄이는 작업이에요.