앞 장까지 우리는 서비스의 비전, 사용자 시나리오, MVP 범위, DDD 경계를 정리했습니다. 이제 그것을 실제 화면 구조로 번역해야 합니다. 여기서 가장 먼저 해야 할 일은 개별 화면의 UI를 그리는 것이 아니라, 서비스 전체의 정보 구조를 고정하는 것입니다.
화면 기획에서 가장 흔한 실패는 화면을 예쁘게 그리는 데 집중하다가, 사용자가 어디서 들어와 어디로 이동하고 어디서 끝나는지가 흐려지는 것입니다. 이커머스는 특히 그렇습니다. 상품 목록, 상세, 장바구니, 주문, 결제, 마이페이지, 운영자 대시보드, 챗봇까지 모두 존재하므로, 정보 구조를 먼저 잡지 않으면 구현 단계에서 라우트와 상태가 금방 뒤엉킵니다.
이 페이지의 목적은 세 가지입니다. 첫째, 구매자와 운영자의 화면 공간을 분리합니다. 둘째, 핵심 사용자 여정을 라우트 흐름으로 바꿉니다. 셋째, AI 상담 챗봇이 서비스 어디에 붙고 어떤 진입점을 가져야 하는지 정합니다.
프론트엔드 구현은 보통 컴포넌트부터 시작하고 싶어집니다. 하지만 컴포넌트보다 먼저 정해야 하는 것이 있습니다.
이 질문에 답하지 않은 채 구현을 시작하면 이런 문제가 생깁니다.
/cart에 비회원이 바로 들어갔을 때 어떻게 할지 뒤늦게 고민한다즉 IA는 보기 좋은 사이트맵이 아니라, 구현과 상태 관리의 기준선입니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
이 문서가 정리되면 다음 페이지에서 storefront 화면 설계로 자연스럽게 내려갈 수 있습니다.
이번 교재의 화면 구조는 하나의 웹앱처럼 보이더라도, 실제로는 세 가지 공간으로 나눠 생각하는 편이 맞습니다.
storefrontadminassistant surface구매자와 비회원 방문자가 쓰는 공간입니다.
운영자가 쓰는 공간입니다.
챗봇은 별도 제품처럼 보일 수도 있지만, 이번 교재에서는 독립 앱보다 서비스에 부착된 상담 surface로 다룹니다.
IA를 짤 때는 화면 수를 기준으로 하지 않고, 사용자 목표를 기준으로 생각해야 합니다.
이번 교재에서는 아래 네 가지 목표가 화면 구조의 기준입니다.
이 네 목표로부터 자연스럽게 상위 메뉴와 라우트가 나옵니다.
구매자 중심의 정보 구조는 다음처럼 잡는 것이 자연스럽습니다.
이번 교재에서는 블로그나 브랜드 스토리 같은 부가 섹션보다, 구매 흐름을 끝까지 통과하는 구조가 우선입니다.
| 메뉴/영역 | 역할 |
|---|---|
| 홈 | 카탈로그 진입점, 추천 진입점 역할 |
| 상품 | 상품 목록 탐색 |
| 장바구니 | 구매 전 임시 상태 확인 |
| 내 주문 | 주문 상태 확인 |
| 로그인 | 인증 진입 |
중요한 점은 상품 -> 상세 -> 장바구니 -> 주문 흐름이 한 줄로 이어져야 한다는 것입니다.
이번 교재에서 최소한 아래 경로는 명확히 설계해야 합니다.
//products/products/:productId/login/signup비회원도 상품 탐색은 가능해야 하므로 카탈로그 관련 경로는 공개 경로로 두는 것이 자연스럽습니다.
/cart/checkout/orders/orders/:orderId이 경로는 사용자 상태와 주문 상태를 다루므로 인증이 필요합니다.
/ 또는 /products/products/:productId/login/cart/checkout/orders/:orderId이 흐름이 storefront MVP의 뼈대입니다.
운영자 공간은 storefront와 질문 자체가 다릅니다. 따라서 메뉴 이름도 달라져야 합니다.
이번 MVP에서는 운영 기능을 넓게 잡지 않으므로, 사용자 관리, 권한 관리, 정산, 프로모션 같은 메뉴는 넣지 않아도 됩니다.
| 메뉴/영역 | 역할 |
|---|---|
| 대시보드 | 핵심 운영 지표 확인 |
| 주문 | 주문 상태별 목록과 상세 확인 |
| 상품 | 상품 현황 확인 |
| 로그인 | 운영자 진입 |
/admin/login/admin/admin/orders/admin/orders/:orderId/admin/products핵심은 /admin 이하의 공간을 storefront와 분리하는 것입니다. 그래야 권한과 레이아웃과 라우트 가드가 깔끔해집니다.
챗봇은 별도 탭으로 빼기보다, 사용자가 막히는 지점에 가까이 붙이는 편이 좋습니다.
이번 교재에서 자연스러운 위치는 아래와 같습니다.
반대로 모든 화면에서 강한 떠다니는 패널을 강제로 띄우는 것은 좋지 않을 수 있습니다. 특히 운영자 화면에는 기본적으로 챗봇을 같은 수준으로 붙일 필요가 없습니다.
좋은 화면 구조는 좋은 도메인 경계를 반영합니다.
예를 들어:
/products와 /products/:id는 Catalog/cart는 Cart/checkout, /orders/:id는 Order와 Payment/admin/orders는 AdminSupport Assistant이 매핑이 자연스럽게 보이면, 프론트 구조와 백엔드 경계가 잘 맞고 있는 것입니다.
라우트는 단순 URL이 아니라, 각 화면이 어떤 책임을 가지는지 보여 줍니다.
| 라우트 | 주 책임 | 주요 컨텍스트 |
|---|---|---|
/products |
상품 탐색 | Catalog |
/products/:productId |
상품 이해와 구매 진입 | Catalog |
/cart |
임시 구매 상태 확인/수정 | Cart |
/checkout |
주문 생성과 결제 시작 | Order, Payment |
/orders/:orderId |
주문 상태 확인 | Order |
/admin |
운영 요약 확인 | Admin |
/admin/orders |
주문 모니터링 | Admin |
이 표는 뒤에서 프론트 페이지 단위와 API 연결 단위를 나눌 때 바로 도움이 됩니다.
처음 설계에서 너무 많은 하위 메뉴와 중간 단계를 넣으면 구현 복잡도만 올라갑니다.
이번 MVP에서는 아래 원칙을 지키는 편이 좋습니다.
이 교재의 목표는 메뉴가 많은 서비스가 아니라, 끝까지 흐름이 이어지는 서비스입니다.
이번 교재를 따라 하는 학습자는 아래 수준으로 먼저 정리해 두면 충분합니다.
이 다섯 가지 실수는 구현 단계에서 레이아웃, 인증, 상태 관리 문제로 곧바로 번집니다.
이 페이지에서 우리는 이커머스 MVP의 화면 공간을 storefront, admin, assistant surface로 나누고, 각 공간의 IA와 메뉴 구조와 라우트 맵을 정리했습니다. 이제 화면 구조의 뼈대가 생겼습니다. 다음 페이지에서는 이 뼈대 위에서 구매자 storefront 화면을 더 구체적으로 설계합니다.
다음 페이지에서는 상품 목록, 상세, 장바구니, 주문, 주문 확인까지 이어지는 구매자 storefront 화면을 더 구체적으로 기획합니다.