이제부터는 골격 위에 실제 기능을 얹기 시작합니다. 05장까지에서 우리는 백엔드와 프론트의 구조, API 계약 바닥, 첫 통합 실행 기준을 먼저 고정했습니다. 이제 그 위에서 가장 먼저 구현할 풀스택 기능은 Catalog와 Identity입니다.
이 순서가 중요한 이유는 분명합니다. 상품을 보여주는 기능과 사용자를 식별하는 기능이 먼저 안정되어야 이후 장의 장바구니, 주문, 결제, 운영자 조회가 제대로 이어질 수 있기 때문입니다. 상품이 없다면 구매 흐름을 설명할 수 없고, 사용자가 없다면 장바구니와 주문의 주인을 설명할 수 없습니다.
이번 페이지는 이 두 기능의 백엔드 바닥을 먼저 만드는 단계입니다. 여기서 말하는 구현은 단순 CRUD를 급하게 붙이는 것이 아닙니다. Catalog와 Identity를 각각 어떤 책임으로 나누고, 어떤 API와 도메인 규칙과 시드 데이터가 있어야 다음 페이지의 storefront 연결이 자연스럽게 되는지를 정리하는 것입니다.
풀스택 이커머스에서 처음 만들고 싶은 것은 보통 장바구니나 주문처럼 보이는 기능입니다. 하지만 그보다 먼저 안정되어야 하는 것은 아래 두 축입니다.
이 두 축이 먼저 있어야 다음 단계에서 아래 흐름이 성립합니다.
즉 Catalog와 Identity는 이후 모든 사용자 행동의 출발점입니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
Catalog 백엔드가 어떤 책임을 가지는가Identity 백엔드가 어떤 책임을 가지는가이번 단계의 Catalog는 아직 운영자 상품 관리 전체를 의미하지 않습니다. 우선은 구매자 화면과 초기 admin 조회를 뒷받침하는 읽기 중심 기능이 핵심입니다.
이번 교재의 초기 Catalog 책임은 아래 정도면 충분합니다.
중요한 것은 장바구니 이전 단계에서 "사용자가 무엇을 볼 수 있는가"를 안정적으로 제공하는 것입니다.
Identity도 처음부터 모든 인증 기능을 다 만드는 것이 아닙니다. 이번 단계에서는 최소한 아래 책임을 먼저 정리하는 것이 맞습니다.
이 단계에서 소셜 로그인, 비밀번호 재설정, 이메일 인증까지 다 넣을 필요는 없습니다. 골격 위에서 다음 장의 흐름을 지탱할 최소 인증 기능이 우선입니다.
이 둘은 서로 다른 컨텍스트지만, 학습 순서상 같이 여는 것이 자연스럽습니다. 이유는 아래와 같습니다.
storefront 첫 실사용 화면은 상품 목록이다즉 Catalog와 Identity는 구현 책임은 다르지만, 사용자 여정 시작점에서는 함께 움직입니다.
모든 상품 관련 API를 한 번에 만들 필요는 없습니다. 이번 장의 첫 구현 기준으로는 아래 정도면 충분합니다.
GET /productsGET /products/{product_id}각 endpoint는 최소한 아래를 만족해야 합니다.
즉 API 개수가 많기보다, 첫 화면을 안정적으로 받을 수 있는지가 중요합니다.
Identity도 초기 범위를 분명히 자르는 것이 좋습니다. 이번 장에서는 아래 정도가 자연스럽습니다.
POST /auth/signupPOST /auth/loginGET /auth/me이 세 endpoint가 있으면 다음 장의 storefront 로그인 연결과 이후 보호 라우트 흐름까지 이어갈 수 있습니다.
지금 단계의 Catalog는 읽기 중심이라 규칙이 약해 보일 수 있지만, 최소한 아래 기준은 먼저 있어야 합니다.
이 규칙이 있어야 프론트가 상품 카드와 상세 화면을 일관되게 구성할 수 있습니다.
인증은 초반부터 규칙이 중요합니다. 이번 단계에서는 아래 정도를 먼저 고정하는 것이 맞습니다.
이 네 가지가 없으면 뒤 장의 모든 인증 흐름이 흔들립니다.
이번 프로젝트에서 역할은 지나치게 복잡하게 시작할 필요가 없습니다. 초기에는 아래 정도면 충분합니다.
customeradmin중요한 것은 역할 종류를 많이 만드는 것이 아니라, 어떤 API와 어떤 화면이 어떤 역할을 전제로 하는지를 분명히 하는 것입니다. 이 단계에서는 운영자와 일반 사용자의 구분만 명확해도 이후 장의 접근 제어를 붙이기 쉽습니다.
Identity API는 단순 로그인 기능이 아닙니다. 로그인 응답 형식은 곧 프론트 상태 구조, 보호 라우트 로직, 이후 admin 접근 제어까지 영향을 줍니다.
따라서 이번 장에서는 최소한 아래를 먼저 정해야 합니다.
즉 인증 응답은 백엔드 내부 구현이 아니라, 이후 모든 프론트 흐름의 기준입니다.
이 단계에서 시드 데이터 없이 API만 만들면 다음 페이지에서 바로 막힙니다. storefront 화면은 결국 실제 상품이 있어야 의미 있게 보이고, admin 접근도 최소 테스트 계정이 있어야 흐름을 확인할 수 있습니다.
이번 장에서 필요한 최소 시드 데이터는 아래 정도입니다.
이 데이터가 있어야 목록/상세/로그인/역할 분기를 다음 단계에서 바로 검증할 수 있습니다.
지금까지 잡은 백엔드 구조를 유지하려면, 이 두 기능도 기존 경계를 따라 들어가야 합니다.
api: 라우터와 request/response schemaapplication: 상품 조회, 회원 가입, 로그인 같은 유스케이스 흐름domain: 상품, 사용자, 역할 규칙infra: 저장소 구현, 비밀번호 해시, DB 연결중요한 것은 기능이 생긴다고 해서 모든 로직이 라우터로 쏠리면 안 된다는 점입니다.
이번 단계에서는 모든 케이스를 다 테스트할 필요는 없지만, 최소한 아래는 바로 검증할 수 있어야 합니다.
auth/me가 인증 상태를 반영한다이 테스트가 있어야 다음 장의 프론트 연결에서 문제가 생겼을 때, 백엔드 규칙 문제인지 화면 연결 문제인지 빠르게 나눌 수 있습니다.
이번 장에서 "완료"라고 부를 수 있는 상태는 아래 정도입니다.
Catalog 목록/상세 API가 뜬다Identity 가입/로그인/현재 사용자 확인 API가 뜬다즉 실제 주문까지 되는 상태가 아니라, 다음 장의 프론트 연결을 안정적으로 받을 수 있는 백엔드가 준비된 상태입니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
products 목록/상세 라우터signup, login, me 라우터이 산출물이 있어야 다음 페이지에서 storefront를 실제 상품 목록과 로그인 흐름에 붙일 수 있습니다.
이 여섯 가지 실수는 다음 장의 화면 구현을 바로 불안정하게 만듭니다.
이 페이지에서 우리는 Catalog와 Identity를 이커머스 서비스의 첫 실제 백엔드 기능으로 왜 먼저 구현해야 하는지 정리했습니다. 또한 상품 목록/상세, 회원 가입/로그인/현재 사용자 확인 API를 어떤 책임과 규칙으로 세워야 하는지, 역할 구분과 시드 데이터가 왜 이 단계에서 함께 필요해지는지도 확인했습니다.
다음 페이지에서는 이제 이 Catalog와 Identity 백엔드를 storefront 화면에 연결해 상품 목록과 상세, 로그인 진입을 실제로 보이게 만듭니다.