앞 페이지에서 storefront에 상품 목록과 상세를 붙였다면, 이제 사용자를 실제로 식별하는 흐름을 완성해야 합니다. 상품 탐색만 가능한 서비스는 데모로는 충분할 수 있지만, 이커머스 서비스로 이어지려면 결국 사용자가 누구인지 알아야 합니다. 장바구니, 주문, 결제, 주문 내역 조회는 모두 사용자 식별 위에 세워지기 때문입니다.
이번 페이지의 목적은 회원가입 화면과 로그인 화면을 만드는 것에 그치지 않습니다. 백엔드의 Identity API를 화면에 연결하고, 로그인 성공 후 세션을 어떻게 저장하고 복원할지, 인증 실패와 만료 상태를 어떻게 다룰지, 로그인 후 어떤 경로로 이동할지를 함께 정하는 것입니다.
즉 이번 장은 "폼 하나 더 만든다"가 아니라, storefront를 비회원 탐색 앱에서 인증 가능한 사용자 앱으로 바꾸는 단계입니다.
이번 교재의 사용자 여정은 아래 흐름으로 보는 것이 자연스럽습니다.
이 순서는 실제 사용자 경험에도 맞고, 학습 순서에도 맞습니다. 상품이 보이기 전에는 로그인의 이유가 약하고, 로그인 후 어디로 가야 할지도 불분명합니다. 반대로 카탈로그가 살아 있으면 인증은 "다음 행동을 여는 관문"으로 자연스럽게 이해됩니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
signup, login, me API를 어떻게 연결할 것인가아직 주문까지 가지 않더라도, storefront의 인증 흐름은 최소한 아래를 만족해야 합니다.
즉 이번 장의 목표는 "로그인 버튼이 있다"가 아니라, 실제로 인증 상태가 앱에 반영된다는 것입니다.
회원가입 화면은 단순한 입력 폼이 아닙니다. 새 사용자를 시스템에 등록하는 첫 관문이므로 아래 정도에 집중하는 것이 좋습니다.
초기 단계에서는 마케팅 수신 동의나 세부 프로필까지 넣을 필요는 없습니다. 다음 장의 흐름을 지탱할 최소 가입 정보가 우선입니다.
로그인 화면은 사용자에게 가장 자주 실패를 경험하게 하는 화면이기도 합니다. 따라서 아래 역할을 먼저 분명히 하는 것이 좋습니다.
이 화면은 예쁘게 보이는 것보다, 실패를 명확히 이해시키고 성공 후 자연스럽게 이동시키는 것이 더 중요합니다.
같은 인증 영역처럼 보여도 회원가입과 로그인은 목적이 다릅니다.
이 둘을 한 화면에 섞어도 되지만, 교재 기준으로는 책임을 분리해 설명하는 편이 낫습니다. 그래야 API도 명확해지고, 실패 상황도 अलग-अलग 다룰 수 있습니다. 또한 이후 운영자 인증과도 구분하기 쉬워집니다.
이번 장에서는 백엔드에서 이미 준비한 아래 API가 프론트 흐름으로 연결됩니다.
POST /auth/signupPOST /auth/loginGET /auth/me연결 순서는 아래처럼 보는 것이 자연스럽습니다.
signuploginme이 순서가 잡혀 있어야 세션 저장과 복원 흐름도 자연스럽게 이어집니다.
로그인 구현에서 자주 놓치는 것이 "성공 후 저장"만 생각하고 "다음 실행 시 복원"을 빼먹는 점입니다. 하지만 실제 사용자 경험에서는 아래 둘이 모두 필요합니다.
둘 중 하나라도 빠지면 보호 라우트와 사용자 표시가 쉽게 어긋납니다. 따라서 이번 교재에서는 세션 저장과 복원을 한 세트로 봐야 합니다.
세션 정보는 페이지 컴포넌트마다 따로 다루면 안 됩니다. 이번 교재에서는 앞서 정한 provider 구조를 유지하면서, 인증 상태는 앱 전역에서 읽을 수 있게 두는 편이 좋습니다.
예를 들어 아래 정도 상태가 필요합니다.
즉 세션은 한 화면의 상태가 아니라 앱 전역 흐름입니다.
me API는 왜 중요한가login만 있으면 인증이 끝난 것처럼 보이지만, 실제 앱은 현재 사용자 확인이 따로 필요합니다. GET /auth/me는 아래 역할을 합니다.
즉 me API는 세션 복원의 기준점입니다. 이 단계에서 빠지면 로그인은 되지만 앱 전체 인증 상태는 쉽게 불안정해집니다.
로그인 성공 후 이동은 단순히 홈으로 보내는 것으로 끝내면 안 됩니다. 사용자가 어디에서 로그인했는지가 중요할 수 있기 때문입니다.
예를 들어 다음 흐름을 생각할 수 있습니다.
이 기준이 있으면 다음 장에서 장바구니나 구매 전이도 자연스럽게 붙습니다.
인증 화면에서 실패는 크게 두 종류입니다.
예를 들어 아래처럼 다뤄야 합니다.
이 둘을 같은 메시지로 뭉개면 사용자는 무엇을 고쳐야 하는지 알기 어렵습니다.
인증 화면은 제출 직후 상태가 특히 중요합니다. 아래 정도는 최소한 보여야 합니다.
로그인 버튼을 여러 번 눌러 중복 요청이 나가는 경험은 기본적인 UX 결함이므로, 이 단계에서부터 막는 것이 좋습니다.
세션은 영원하지 않습니다. 따라서 다음 상황도 미리 생각해야 합니다.
me 요청 실패이번 교재에서는 최소한 아래 행동을 먼저 정하는 것이 좋습니다.
이 기준이 있어야 다음 장의 보호 라우트와 admin 접근 제어도 일관되게 붙습니다.
회원가입 성공 후에는 보통 두 가지 선택지가 있습니다.
이번 교재에서는 어느 방식을 택하든, 한 가지 기준으로 일관되게 설명하는 것이 중요합니다. 초기 학습 흐름상으로는 "회원가입 성공 -> 로그인 진입 또는 자동 인증 여부를 명확히 정의"하는 편이 좋습니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
me로 세션 복원이 된다즉 단순한 auth form이 아니라, 실제 사용자 식별 흐름이 앱에 연결된 상태여야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
signup, login, me API 연결이 산출물이 있어야 다음 페이지에서 admin 기본 조회와 접근 제어를 같은 인증 흐름 위에 올릴 수 있습니다.
me API 없이 저장된 토큰만 믿고 화면을 연다이 여섯 가지 실수는 이후 장의 보호 라우트와 주문 흐름을 바로 불안정하게 만듭니다.
이 페이지에서 우리는 회원가입, 로그인, 세션 복원을 포함한 실제 사용자 식별 흐름을 storefront에 연결하는 방법을 정리했습니다. 또한 인증 화면은 단순 폼이 아니라, signup, login, me API와 앱 전역 세션 상태, 로그인 후 전이, 실패 상태 UX까지 함께 설계해야 한다는 점을 확인했습니다.
다음 페이지에서는 이제 admin 기본 조회와 접근 제어를 붙여, customer와 admin 역할 차이가 실제 화면과 API 접근에서 어떻게 반영되는지 정리합니다.