앞 페이지에서 storefront 장바구니와 checkout 요약 화면을 만들었다면, 이제 사용자가 실제로 주문을 생성하고 결제 확인까지 진행할 수 있어야 합니다. 이 단계에서 비로소 이커머스 서비스는 단순 탐색과 준비를 넘어서, 실제 구매 워크플로를 갖게 됩니다.
이번 페이지의 핵심은 버튼 하나로 주문을 만들어내는 것이 아닙니다. 장바구니 내용을 주문 시점의 snapshot으로 고정하고, 주문 상태와 결제 상태가 어떤 순서로 바뀌는지, mock payment 확인이 어떤 역할을 하는지, 실패나 중복 확인은 어떻게 처리하는지까지 하나의 서버 워크플로로 정리하는 것입니다.
즉 이번 장은 Cart를 Order로 바꾸고, 그 Order를 Payment 결과와 연결하는 단계입니다.
주문과 결제는 분리된 개념이지만, 사용자 경험과 서버 상태에서는 거의 하나의 흐름입니다.
주문만 만들고 결제 확인이 없으면 구매가 완료되지 않고, 결제 확인만 따로 설명하면 어떤 주문을 확정하는지 맥락이 약해집니다. 따라서 이번 교재에서는 둘을 하나의 워크플로로 같이 설명하는 것이 자연스럽습니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
이번 단계의 Order는 최소한 아래 책임을 가져야 합니다.
중요한 것은 주문이 장바구니의 실시간 뷰가 아니라, "그 시점에 무엇을 얼마로 주문했는가"를 고정하는 기록이라는 점입니다.
장바구니는 계속 바뀌는 상태입니다. 하지만 주문은 바뀌는 상태가 아니어야 합니다. 예를 들어 snapshot이 없으면 아래 문제가 생깁니다.
따라서 이번 교재에서는 주문 생성 시 장바구니 항목과 금액 정보를 snapshot으로 고정하는 것이 핵심입니다.
주문 생성은 아무 상태에서나 되면 안 됩니다. 최소한 아래 조건을 먼저 확인해야 합니다.
이 검증이 먼저 있어야 이후 결제 확인과 주문 완료 처리도 자연스러워집니다.
이번 단계에서 주문 snapshot에는 아래 정도가 들어가면 충분합니다.
중요한 것은 장바구니를 그대로 참조하는 것이 아니라, 주문 시점의 데이터를 독립적으로 보존하는 것입니다.
주문은 상태 전이가 매우 중요합니다. 상태 이름을 늦게 정하면 프론트, 백엔드, admin 화면이 모두 어긋납니다. 이번 단계에서는 최소한 아래 정도를 먼저 정리하는 것이 좋습니다.
createdpayment_pendingpaidpayment_failedcancelled상태 이름은 프로젝트마다 조금 다를 수 있지만, 중요한 것은 어떤 사건이 어떤 상태 변화를 일으키는지 명확해야 한다는 점입니다.
주문과 결제는 서로 연결되지만, 완전히 같은 것은 아닙니다. 예를 들어 결제는 아래처럼 생각할 수 있습니다.
readyconfirmedfailed주문은 상품 구매 워크플로 전체를 보고, 결제는 금액 정산 시도 자체를 봅니다. 따라서 이번 교재에서는 두 상태를 분리해서 설명하는 편이 좋습니다.
실제 PG를 처음부터 붙이지 않아도, 결제 확인 단계는 꼭 있어야 합니다. 이유는 아래와 같습니다.
즉 mock payment는 단순 대체재가 아니라, 결제 워크플로 자체를 학습하기 위한 핵심 장치입니다.
이번 단계에서는 아래 정도 API면 충분합니다.
POST /ordersGET /orders/{order_id}POST /payments/{order_id}/confirm 또는 동등한 확인 endpoint이 세 endpoint가 있으면 주문 생성, 주문 조회, 결제 결과 확정 흐름을 다음 화면과 admin surface까지 연결할 수 있습니다.
주문 생성 API는 단순 성공 여부만 주면 부족합니다. 다음 단계가 결제 확인과 완료 화면이기 때문입니다. 따라서 최소한 아래 정보는 반환하는 편이 좋습니다.
이 정보가 있어야 프론트는 바로 다음 단계로 이어질 수 있습니다.
mock payment 확인 API는 아래 역할을 수행해야 합니다.
즉 결제 확인은 단순 플래그 변경이 아니라, 주문과 결제 상태를 함께 전이시키는 작업입니다.
주문과 결제 흐름에서는 실패가 여러 층에서 발생할 수 있습니다.
이 실패를 모두 같은 오류로 처리하면 디버깅도 어렵고, 사용자 메시지도 거칠어집니다. 따라서 이번 교재에서는 최소한 아래를 나눠 생각해야 합니다.
결제 확인은 네트워크 재시도나 사용자 중복 클릭 때문에 여러 번 들어올 수 있습니다. 따라서 이번 단계에서 아래를 먼저 생각해야 합니다.
paid 상태인 주문을 다시 확인하면 어떻게 할 것인가이 기준이 없으면 결제 워크플로가 쉽게 불안정해집니다.
이 부분도 미리 정해두는 편이 좋습니다. 보통 아래 중 하나입니다.
어느 방식을 택하든 한 가지 기준으로 일관되게 가야 합니다. 이번 교재에서는 주문과 결제 흐름 설명을 명확히 하기 위해, 어느 시점에 cart를 정리할지 명시적으로 정하는 것이 중요합니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
즉 아직 완료 UX를 다듬지 않았더라도, 구매 워크플로의 서버 본체는 동작해야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
이 산출물이 있어야 다음 페이지에서 주문 완료 UX와 회귀 테스트를 실제 사용자 흐름 기준으로 정리할 수 있습니다.
이 여섯 가지 실수는 주문 완료 화면과 운영자 조회를 바로 불안정하게 만듭니다.
이 페이지에서 우리는 장바구니를 기준으로 주문을 생성하고, 결제 확인 결과에 따라 주문과 결제 상태를 함께 전이시키는 워크플로를 정리했습니다. 또한 Order는 cart의 실시간 뷰가 아니라 snapshot 기록이어야 하며, mock payment 확인은 실제 결제 워크플로와 동일한 상태 전이와 실패 처리를 학습하기 위한 핵심 장치라는 점도 확인했습니다.
다음 페이지에서는 이제 주문 완료 화면과 실패 화면, 회귀 테스트 기준을 정리해 구매 흐름을 사용자 관점에서 마무리합니다.