앞 페이지까지에서 우리는 storefront에서 상품 탐색과 사용자 인증 흐름을 연결했습니다. 이제 같은 백엔드를 바라보는 또 하나의 surface인 admin을 붙여야 합니다. 이 단계에서 중요한 것은 관리자 화면을 하나 더 만드는 것이 아닙니다. customer와 admin이 같은 시스템을 보되, 서로 다른 권한과 다른 목적을 가진다는 사실을 실제 화면과 API 접근에 반영하는 것입니다.
이커머스 서비스에서 운영자 화면은 구매자 화면의 복사본이 아닙니다. 구매자는 상품을 보고 로그인해 다음 행동으로 이동하지만, 운영자는 데이터를 조회하고 상태를 관리하며 시스템의 현재 상황을 파악해야 합니다. 따라서 admin은 같은 인증 체계를 공유하더라도, 다른 진입 흐름과 다른 보호 규칙을 가져야 합니다.
이번 페이지의 목적은 admin을 "일단 보이는 별도 앱"이 아니라, 기본 조회와 접근 제어가 실제로 동작하는 운영 surface로 만드는 것입니다.
이 장의 순서는 의도적입니다. 먼저 Catalog와 Identity를 백엔드에 붙이고, 그다음 storefront에서 상품과 사용자 흐름을 연결한 뒤, 이제 admin을 붙입니다. 이 순서가 맞는 이유는 아래와 같습니다.
Identity 바닥을 사용한다Catalog와 이후 주문 데이터를 읽게 된다즉 admin은 별도 세계가 아니라, 같은 시스템 안의 다른 역할 surface입니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
storefront와 어떻게 다른가customer 세션과 admin 세션은 어떻게 구분되는가이번 단계의 admin은 모든 운영 기능을 다 구현하지 않습니다. 하지만 최소한 아래 역할은 해야 합니다.
즉 이번 장의 목표는 "운영자 전용 surface가 실제로 분리되어 있다"는 것을 시스템 차원에서 보여주는 것입니다.
같은 Identity를 쓴다고 해서 운영자 로그인 경험까지 완전히 같아야 하는 것은 아닙니다. admin 로그인은 아래 점에서 더 명확해야 합니다.
따라서 이번 교재에서는 인증 로직은 공유할 수 있어도, admin은 별도 surface라는 점이 화면 구조와 전이에서 드러나야 합니다.
처음부터 모든 운영 지표를 넣을 필요는 없습니다. 이번 단계에서는 아래 정도가 자연스럽습니다.
즉 이 단계의 admin은 "운영 기능 전체"보다 "운영자만 들어올 수 있는 읽기 surface"를 먼저 만드는 것이 맞습니다.
접근 제어는 UI에서만 걸면 안 되고, API에서만 걸어도 부족합니다. 이번 교재에서는 최소한 아래 두 층이 함께 필요합니다.
프론트 보호 라우트만 있으면 URL 직접 접근이나 API 호출을 막지 못하고, 백엔드만 막으면 사용자 경험이 매끄럽지 않습니다. 따라서 이번 단계에서는 두 층이 함께 있어야 합니다.
admin의 보호 라우트는 단순 로그인 여부만 보면 안 됩니다. 최소한 아래를 확인해야 합니다.
admin인가이 세 가지를 나누지 않으면, 새로고침 순간에 관리자 화면이 잠깐 열리거나 반대로 정상 계정도 튕기는 문제가 생길 수 있습니다.
같은 인증 체계를 쓰더라도 역할 구분은 명확해야 합니다. 이번 단계에서는 아래 정도가 중요합니다.
admin 앱에서 customer 계정을 받았을 때 바로 차단하는가즉 세션은 "로그인 여부"만이 아니라, "어떤 역할의 로그인인가"까지 포함해야 합니다.
이번 단계에서는 아래 정도 조회면 충분합니다.
이 조회는 복잡한 운영 기능을 위한 것이 아니라, admin surface가 같은 백엔드를 보면서도 다른 권한 규칙을 따른다는 사실을 확인하기 위한 바닥입니다.
admin에서는 특히 이 구분이 중요합니다.
admin이 아님이 둘을 같은 오류로 뭉개면 사용자는 왜 접근이 안 되는지 알 수 없습니다. 따라서 이번 교재에서는 아래처럼 나누는 것이 좋습니다.
이 구분은 다음 장의 주문/결제 운영 기능에서도 그대로 이어집니다.
운영자 화면은 보호 라우트와 인증 복원이 들어가기 때문에 loading 상태가 특히 중요합니다. 예를 들어 아래 상황이 있습니다.
me 확인 중이때 loading 상태가 없으면, 보호 화면이 깜빡이거나 접근 불가와 복원 중 상태가 혼동됩니다. 따라서 이번 단계에서도 loading은 기본 UX입니다.
운영자 화면이라고 해서 실패를 거칠게 보여줘도 되는 것은 아닙니다. 최소한 아래는 구분되어야 합니다.
로그인 실패는 입력 수정으로 이어져야 하고, 권한 부족은 접근 자체가 안 되는 상황으로 보여야 하며, 조회 실패는 재시도 가능한 오류로 보이는 편이 자연스럽습니다.
이번 단계에서는 아래 정도 라우트면 충분합니다.
/login/dashboard/catalog 또는 기본 조회 페이지중요한 것은 이름보다 역할입니다. 로그인 전 화면과 로그인 후 보호 화면이 구조적으로 나뉘어 있어야 합니다.
권한 검사는 라우터에서 직접 문자열 비교만 하는 수준으로 끝내면 곧 흩어집니다. 이번 단계에서는 최소한 아래를 먼저 정하는 편이 좋습니다.
이 기준이 있어야 이후 운영 기능 API가 늘어나도 같은 규칙을 반복해서 적용할 수 있습니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
admin role 계정만 보호 화면에 들어갈 수 있다customer 계정은 차단된다즉 운영 기능 전체가 아니라, "운영자 전용 surface와 접근 제어 바닥"이 성립한 상태여야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
이 산출물이 있어야 다음 장에서 장바구니, 주문, 결제 흐름이 생겼을 때 운영자 조회와 관리 surface도 자연스럽게 확장할 수 있습니다.
storefront 로그인과 똑같이 취급한다customer와 admin 세션을 role 없이 같은 것으로 취급한다이 여섯 가지 실수는 다음 장의 주문/결제 운영 흐름을 붙일 때 바로 구조 비용으로 돌아옵니다.
이 페이지에서 우리는 admin을 같은 백엔드를 바라보는 별도 운영 surface로 세우고, 로그인, 보호 라우트, role 기반 세션 판별, 기본 조회, 접근 제어를 어떻게 함께 구성해야 하는지 정리했습니다. 또한 customer와 admin의 차이는 단순 화면 차이가 아니라, API 접근과 실패 처리까지 포함한 권한 차이로 구현되어야 한다는 점도 확인했습니다.
다음 장에서는 이제 장바구니, 주문, 결제의 본체 흐름을 만들면서, 지금까지 준비한 카탈로그, 인증, 접근 제어 바닥을 실제 구매 워크플로로 확장합니다.