앞 페이지에서 주문 생성과 결제 확인까지 연결했다면, 이제 구매 흐름을 사용자 관점에서 마무리해야 합니다. 이 단계에서 중요한 것은 성공 화면 하나를 보여주는 것이 아닙니다. 사용자가 주문이 정말 끝났는지 이해할 수 있어야 하고, 실패했을 때 무엇을 해야 하는지도 알아야 하며, 우리가 만든 흐름이 이후 변경으로 다시 깨지지 않도록 회귀 테스트 기준도 갖춰야 합니다.
이커머스 서비스는 성공 케이스만 있으면 완성되지 않습니다. 결제가 실패할 수도 있고, 인증이 만료될 수도 있고, 중복 요청이 들어올 수도 있고, 새 기능을 붙이다가 장바구니 합계나 주문 완료 전이가 다시 깨질 수도 있습니다. 따라서 이번 페이지에서는 주문 완료 UX, 실패 복구 UX, 핵심 회귀 테스트를 하나의 묶음으로 다뤄야 합니다.
즉 이번 장은 구매 워크플로를 "돌아가는 데모"에서 "닫힌 사용자 흐름"으로 바꾸는 단계입니다.
세 가지는 서로 떨어져 있지 않습니다.
완료 화면만 있고 실패 복구가 없으면 실제 서비스 흐름이 비고, 성공/실패 화면만 있고 테스트가 없으면 다음 변경에서 쉽게 망가집니다. לכן 이번 교재에서는 이 세 가지를 함께 정리하는 것이 맞습니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
주문 완료 화면은 단순히 "성공했습니다"를 보여주는 페이지가 아닙니다. 사용자는 최소한 아래를 이해할 수 있어야 합니다.
즉 완료 화면은 사용자에게 "방금 일어난 일"을 명확히 설명하는 요약 화면이어야 합니다.
이번 단계에서는 아래 정도 정보가 있으면 충분합니다.
다음 행동 버튼은 예를 들면 아래 중 하나일 수 있습니다.
중요한 것은 완료 이후 사용자가 길을 잃지 않는 것입니다.
이 부분도 명확해야 합니다. 일반적으로는 아래 기준이 필요합니다.
이 기준이 흐리면 created 상태인데도 성공처럼 보이거나, 실패했는데도 완료 화면이 열릴 수 있습니다. 따라서 이번 교재에서는 완료 화면을 여는 시점을 주문/결제 상태 전이와 연결해서 명확히 설명하는 것이 중요합니다.
결제 실패나 주문 실패를 단순 토스트 한 줄로 끝내면 사용자는 무엇이 실패했고 다음에 무엇을 해야 하는지 알기 어렵습니다. 최소한 아래는 분리해 보여주는 것이 좋습니다.
이 구분이 있어야 사용자도 복구 행동을 선택할 수 있고, 운영자도 어떤 문제가 났는지 추적하기 쉬워집니다.
실패 화면은 단순 실패 통지가 아니라, 복구를 위한 안내여야 합니다. 예를 들어 아래처럼 생각할 수 있습니다.
모든 실패에 같은 복구 버튼을 줄 필요는 없습니다. 중요한 것은 실패 원인에 맞는 다음 행동이 있어야 한다는 점입니다.
주문과 결제 흐름은 인증 의존도가 높으므로, 세션 만료를 반드시 생각해야 합니다. 이 경우에는 아래 반응이 자연스럽습니다.
이 기준이 있어야 결제 실패와 인증 실패가 같은 것으로 보이지 않습니다.
주문 완료나 결제 확인 단계에서는 중복 클릭이 자주 발생할 수 있습니다. 이때 아래를 먼저 정하는 것이 좋습니다.
즉 중복 요청은 예외가 아니라 실제 사용자 행동으로 보고 설계해야 합니다.
주문 완료 페이지도 URL 접근이므로 아래 상황을 고려해야 합니다.
이 경우 단순 빈 화면이 아니라, 접근 불가 또는 잘못된 요청 상태를 명확히 보여줘야 합니다.
이번 장은 구매 워크플로의 가장 핵심 부분이므로, 최소한 아래 회귀 시나리오는 남겨야 합니다.
이 다섯 가지가 있으면 이후 기능 추가 시 가장 위험한 회귀를 빨리 잡을 수 있습니다.
주문 완료 흐름은 이후 장의 운영자 화면, 알림, 챗봇, 주문 조회와 모두 연결됩니다. 지금 테스트를 남기지 않으면 다음 장에서 한 기능을 고치다가 주문 성공 흐름이 다시 깨져도 늦게 발견될 수 있습니다.
따라서 이번 교재에서는 "구매가 끝나는 지점"을 테스트 기준으로 고정하는 것이 중요합니다.
이번 장에서는 아래 층이 같이 있으면 좋습니다.
특히 이 장은 mutation과 workflow가 핵심이므로, 단순 타입 체크나 단일 API 호출만으로는 충분하지 않습니다. 최소한 흐름 기준의 검증이 있어야 합니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
즉 이제 사용자는 성공이든 실패든 "다음에 무엇을 해야 하는지"를 알 수 있어야 합니다.
이번 페이지를 코드와 검증 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
이 산출물이 있어야 다음 장의 운영자 기능과 AI 상담 챗봇이 실제 주문 흐름 위에 자연스럽게 올라갈 수 있습니다.
이 여섯 가지 실수는 이후 운영자 조회, 주문 추적, 알림 흐름을 바로 불안정하게 만듭니다.
이 페이지에서 우리는 주문 완료 화면, 실패 복구 UX, 회귀 테스트를 함께 묶어 구매 흐름을 사용자 관점에서 닫는 방법을 정리했습니다. 또한 이커머스 서비스는 성공 화면만으로 완성되지 않으며, 실패와 중복 요청과 인증 만료까지 포함해 닫힌 워크플로를 가져야 한다는 점도 확인했습니다.
다음 장에서는 이제 운영자 기능과 AI 상담 챗봇을 지금까지 만든 주문 흐름 위에 올려 서비스 전체를 더 실전적인 운영 형태로 확장합니다.