앞 페이지에서 Catalog와 Identity 백엔드 바닥을 준비했다면, 이제 그 결과를 사용자가 실제로 보는 화면에 연결해야 합니다. 이 단계에서 처음으로 storefront가 "틀만 있는 앱"에서 "상품을 탐색할 수 있는 앱"으로 바뀌기 시작합니다.
이번 페이지의 핵심은 단순히 상품 카드 몇 개를 그리는 것이 아닙니다. 상품 목록과 상세 화면을 어떤 흐름으로 만들고, 백엔드 조회 API를 어디에서 연결하고, loading/empty/error 상태를 어떻게 보여주며, 로그인 진입을 어느 시점에 노출할지를 함께 정하는 것입니다. 그래야 다음 페이지의 회원가입, 로그인, 세션 연동이 자연스럽게 이어집니다.
즉 이번 페이지는 Catalog를 첫 실제 사용자 경험으로 바꾸는 단계입니다.
이커머스 서비스에서 사용자가 가장 먼저 만나는 기능은 대개 상품 탐색입니다. 따라서 storefront의 첫 완성 흐름도 아래처럼 잡는 것이 자연스럽습니다.
이 흐름이 먼저 살아야 장바구니와 주문 기능도 의미 있게 붙습니다. 상품이 보이지 않는 상태에서 장바구니를 먼저 만드는 것은 학습 순서도, 사용자 경험 순서도 자연스럽지 않습니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
아직 장바구니와 주문이 없더라도, storefront는 최소한 아래를 보여줄 수 있어야 합니다.
즉 이번 장의 목표는 "상품을 둘러보는 경험"을 성립시키는 것입니다.
상품 목록 화면은 단순히 카드 나열이 아닙니다. 사용자가 현재 서비스에 어떤 상품이 있는지 빠르게 이해할 수 있어야 합니다. 따라서 이번 교재의 첫 목록 화면은 아래 정도에 집중하는 것이 좋습니다.
초기 단계에서는 정교한 필터와 정렬 UI까지 다 넣을 필요는 없지만, 목록 화면만 보고도 "무엇을 파는 서비스인지"가 보여야 합니다.
상품 상세 화면은 목록에서 보지 못한 정보를 채워주는 역할을 해야 합니다. 이 단계에서는 아래 정도면 충분합니다.
이후 장에서 장바구니 버튼이나 구매 버튼이 실제 기능으로 연결되겠지만, 지금 단계에서는 그 자리가 구조상 먼저 드러나는 것이 중요합니다.
목록과 상세는 서로 다른 화면이지만, 사용자 여정에서는 하나의 흐름입니다. 목록만 있으면 탐색은 되지만 결정이 안 되고, 상세만 있으면 진입 경로가 없습니다. 따라서 첫 카탈로그 구현은 두 화면을 함께 묶는 것이 맞습니다.
이 순서는 이후 장의 장바구니 기능과도 자연스럽게 연결됩니다.
즉 이 장은 두 화면을 개별 컴포넌트로만 보는 것이 아니라, 하나의 탐색 흐름으로 보는 것이 중요합니다.
가장 피해야 할 방식은 페이지 컴포넌트 안에 요청 로직과 응답 파싱을 다 밀어 넣는 것입니다. 이번 교재에서는 앞 장에서 정한 대로, 조회 API는 컴포넌트 바깥에서 해석할 자리를 두는 편이 좋습니다.
예를 들면 아래 흐름이 자연스럽습니다.
이렇게 해야 다음 장에서 인증 헤더나 오류 처리 규칙이 바뀌어도 화면 컴포넌트를 덜 건드릴 수 있습니다.
초기 학습 프로젝트에서 자주 빠지는 것이 loading 상태입니다. 하지만 실제 서비스에서는 요청이 즉시 끝나지 않습니다. 따라서 이번 단계부터 최소한 아래는 보여야 합니다.
이 상태가 없으면 화면이 멈춘 것처럼 보이거나, 빈 화면과 로딩 상태가 혼동됩니다. 따라서 loading은 장식이 아니라 기본 UX입니다.
초기에는 상품이 늘 있다고 가정하기 쉽지만, 실제 서비스에서는 빈 목록도 상태입니다. 예를 들어 시드 데이터가 없거나, 조건에 맞는 상품이 없을 수 있습니다.
이번 교재에서는 empty 상태를 아래처럼 생각하면 충분합니다.
empty 상태를 미리 준비해 두면, 나중에 검색이나 필터를 붙일 때도 재사용하기 쉽습니다.
상품 목록과 상세는 조회 기능이므로, 네트워크 실패나 서버 오류가 비교적 자주 눈에 띕니다. 이때 아래를 먼저 정하는 것이 좋습니다.
중요한 것은 오류 메시지를 그냥 콘솔에만 남기지 않고, 화면에서도 사용자가 이해할 수 있는 수준으로 표현하는 것입니다.
목록 카드에 너무 많은 정보를 넣으면 탐색성이 떨어지고, 너무 적게 넣으면 클릭 이유가 없어집니다. 초기 단계에서는 아래 정도가 적절합니다.
이 기준을 넘어서 상세 설명 전체나 과도한 메타데이터를 카드에 넣기 시작하면 목록의 역할이 흐려집니다.
이번 장에서는 아직 인증 연결을 완성하지 않더라도, 상세 화면은 곧 로그인과 다음 행동의 출발점이 됩니다. 예를 들어 다음 장에서는 아래 흐름이 자연스럽게 붙습니다.
따라서 이번 단계에서 상세 화면은 단순 정보 페이지가 아니라, 다음 행동을 위한 연결점으로 설계해야 합니다.
이번 단계에서는 최소한 아래 정도 라우트가 자연스럽습니다.
/products/products/:productId이미 앞 장에서 storefront 골격을 잡아두었으므로, 이 장에서는 그 라우트 자리에 실제 카탈로그 화면을 연결하는 셈입니다. 중요한 것은 라우트 이름과 API 이름, 화면 이름이 크게 어긋나지 않게 맞추는 것입니다.
화면에서 할 일과 데이터 레이어에서 할 일을 구분하는 것도 중요합니다.
즉 화면은 렌더링에 집중하고, 계약 해석은 컴포넌트 바깥에서 처리하는 편이 좋습니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
즉 장바구니가 아직 없어도, "탐색 경험"은 성립해야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
storefront 상품 목록 페이지storefront 상품 상세 페이지이 산출물이 있어야 다음 페이지에서 회원가입, 로그인, 세션 연동을 붙일 때 사용자 흐름이 자연스럽게 이어집니다.
이 여섯 가지 실수는 이후 로그인과 장바구니 흐름을 붙일 때 바로 구조 비용으로 돌아옵니다.
이 페이지에서 우리는 Catalog 백엔드를 storefront에 연결해 첫 실제 사용자 탐색 흐름을 만드는 방법을 정리했습니다. 상품 목록과 상세를 하나의 탐색 여정으로 보고, 조회 API 연결 위치, loading/empty/error 상태, 상세 화면의 다음 행동 진입 자리까지 함께 설계해야 한다는 점을 확인했습니다.
다음 페이지에서는 이제 회원가입, 로그인, 세션 연동을 붙여 storefront에서 사용자 식별 흐름을 실제로 완성합니다.