앞 페이지에서 Cart 도메인과 금액 계산 규칙을 백엔드에 세웠다면, 이제 그 결과를 사용자가 실제로 조작하는 화면에 붙여야 합니다. 이 단계에서 storefront는 단순 탐색 앱에서 벗어나, 사용자가 "구매를 준비하는 상태"를 직접 조작하는 앱으로 넘어갑니다.
이번 페이지의 핵심은 장바구니 목록을 한 번 보여주는 데서 끝나지 않습니다. 상품 담기, 수량 변경, 항목 제거, 합계 갱신, checkout 진입, 주문 직전 확인까지 하나의 흐름으로 연결해야 합니다. 그래야 다음 페이지의 주문 생성과 결제 확인이 자연스럽게 이어집니다.
즉 이번 장은 Cart 백엔드를 storefront의 첫 본격적인 상태 변경 UX로 바꾸는 단계입니다.
장바구니와 checkout은 서로 다른 화면이지만, 사용자 입장에서는 거의 하나의 흐름입니다.
장바구니만 있고 checkout이 없으면 다음 행동이 비고, checkout만 있으면 어떤 상태를 확인하는지 맥락이 없습니다. 따라서 이번 교재에서는 두 화면을 함께 설명하는 것이 자연스럽습니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
이번 단계의 storefront는 최소한 아래 상태까지 와 있어야 합니다.
즉 장바구니가 단순 데이터 뷰가 아니라, 사용자가 실제로 조작하는 구매 준비 화면이어야 합니다.
장바구니 화면은 "무엇이 담겨 있는가"와 "지금 수정할 수 있는가"를 동시에 보여줘야 합니다. 따라서 초기 장바구니 화면은 아래 정도에 집중하는 것이 좋습니다.
중요한 것은 장바구니 화면이 단순 요약이 아니라, 수정 가능한 작업 화면이라는 점입니다.
장바구니에서 가장 자주 일어나는 상호작용은 수량 변경입니다. 이 UX가 거칠면 바로 사용자 경험이 무너집니다.
이번 교재에서는 최소한 아래를 먼저 정하는 것이 좋습니다.
이 흐름이 자연스러워야 사용자는 장바구니를 "수정 가능한 상태"로 인식합니다.
항목 제거도 단순 삭제 버튼 하나로 끝나지 않습니다. 아래 질문에 답할 수 있어야 합니다.
이 세 가지가 맞지 않으면 장바구니는 금방 불안정하게 보입니다.
탐색 화면의 empty 상태와 장바구니의 empty 상태는 의미가 다릅니다. 장바구니가 비어 있다는 것은 "다음 행동으로 갈 수 없다"는 뜻이기도 하기 때문입니다.
이번 단계에서는 empty 상태가 아래 역할을 해야 합니다.
즉 empty 상태는 단순한 안내 문구가 아니라, 구매 흐름의 분기점입니다.
장바구니 UX에서 합계는 사용자의 신뢰와 직결됩니다. 따라서 합계는 아래 순간마다 일관되게 갱신되어야 합니다.
중요한 것은 프론트가 합계를 추측하지 않고, 서버 기준 계산과 같은 결과를 보여줘야 한다는 점입니다.
프론트는 장바구니 금액을 표현할 수는 있지만, 최종 기준은 서버가 가져야 합니다. 이번 단계에서는 아래처럼 구분하는 것이 좋습니다.
즉 화면은 빠른 피드백을 줄 수 있지만, 최종 계산 진실은 서버에 있어야 합니다.
checkout 화면은 아직 결제를 실행하는 장이 아니더라도, 아래 역할을 먼저 해야 합니다.
즉 checkout은 cart의 복사본이 아니라, "이제 이 내용으로 주문을 만들겠다"는 확인 단계입니다.
두 화면이 완전히 같아 보이면 역할이 분리되지 않습니다.
이 차이가 있어야 사용자는 두 화면을 각각 다른 목적의 단계로 이해합니다.
checkout은 언제나 열리게 두면 안 됩니다. 최소한 아래 상황에서는 막거나 안내가 필요합니다.
이 기준이 있어야 다음 페이지의 주문 생성 API가 불필요한 실패를 덜 겪습니다.
이번 교재에서는 cart API가 인증 기반이므로, 장바구니와 checkout은 로그인 상태와 직접 연결됩니다. 따라서 아래를 먼저 생각해야 합니다.
이 흐름이 자연스러워야 장바구니가 실제 구매 준비 단계로 기능합니다.
이번 단계에서 최소한 아래 오류는 구분되어 보여야 합니다.
조회 실패는 화면 전체 상태일 수 있고, 수량 변경 실패는 항목 단위 메시지일 수 있습니다. 즉 모든 오류를 같은 박스로 뭉개면 UX가 거칠어집니다.
아직 주문 생성은 다음 장이지만, checkout 단계에서 최소한 아래는 확인할 수 있어야 합니다.
이 정보가 있어야 다음 페이지에서 주문 생성 버튼이 의미를 갖습니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
즉 실제 결제는 없어도, 구매 준비 화면은 성립해야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
storefront cart 페이지storefront checkout 요약 페이지이 산출물이 있어야 다음 페이지에서 order 생성과 payment 확인을 실제 백엔드 워크플로로 연결할 수 있습니다.
이 여섯 가지 실수는 다음 장의 주문 생성과 결제 흐름을 바로 불안정하게 만듭니다.
이 페이지에서 우리는 Cart 백엔드를 storefront 장바구니 화면과 checkout 요약 UI에 연결해, 사용자가 실제로 구매 준비 상태를 조작하는 흐름을 만드는 방법을 정리했습니다. 또한 장바구니와 checkout은 하나의 흐름이지만 서로 다른 역할을 가진 화면이며, 합계 갱신과 인증 상태와 주문 직전 검증이 함께 맞물려야 한다는 점도 확인했습니다.
다음 페이지에서는 이제 order 생성과 payment 확인을 백엔드 워크플로와 연결해 실제 주문 생성을 완성합니다.