이전 페이지에서는 운영자가 주문, 결제, 고객 지원 상태를 읽는 화면을 만들었습니다. 이번 페이지에서는 운영자가 상품을 관리하는 화면과 도구를 설계합니다. 이 단계부터 admin은 단순 조회 화면이 아니라, 서비스 운영자가 실제로 데이터를 조정하는 도구가 됩니다.
상품 운영은 생각보다 위험한 기능입니다. 상품명 하나를 잘못 바꾸면 storefront의 상품 카드와 상세 화면이 흔들리고, 가격을 잘못 바꾸면 주문 금액과 결제 금액의 신뢰가 깨질 수 있습니다. 따라서 이번 페이지에서는 "관리자가 수정할 수 있다"보다 "어떤 필드를 어떤 규칙으로 수정하게 할 것인가"를 먼저 정합니다.
즉 이번 장의 목표는 운영자에게 상품 운영 권한을 열되, 구매 흐름과 주문 snapshot이 깨지지 않도록 안전한 관리 도구를 만드는 것입니다.
상품 운영은 구매자 storefront의 시작점입니다. 하지만 개발 순서에서는 주문 운영 화면을 먼저 본 뒤 상품 운영을 붙이는 편이 자연스럽습니다.
따라서 상품 운영은 단순 CMS가 아니라, 이미 만들어진 구매 흐름 위에서 조심스럽게 여는 운영 도구로 다루는 것이 좋습니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
상품 운영 화면의 첫 책임은 상품을 많이 보여주는 것이 아닙니다. 운영자가 현재 판매 가능한 상품과 문제가 있는 상품을 빠르게 구분할 수 있어야 합니다.
초기 상품 운영 화면은 아래 질문에 답해야 합니다.
이 질문에 답할 수 있어야 상품 운영 화면이 실제 도구가 됩니다.
상품 목록은 운영자가 상품 상태를 빠르게 훑는 화면입니다. 최소한 아래 정보가 필요합니다.
여기서 중요한 것은 구매자 화면과 운영자 화면의 정보 밀도가 다르다는 점입니다. storefront는 구매 판단에 필요한 정보를 보여주고, admin은 운영 판단에 필요한 정보를 보여줘야 합니다.
상품 운영에서 자주 하는 실수는 판매 중과 화면 노출을 하나의 상태로 뭉개는 것입니다. 실전 서비스에서는 두 상태를 분리하는 편이 안전합니다.
예를 들어 운영자가 상품을 미리 등록해 두되 아직 노출하지 않을 수 있습니다. 반대로 기존 상품을 목록에서는 숨기지만, 과거 주문 상세에서는 계속 참조해야 할 수도 있습니다. 따라서 상품을 삭제 중심으로 관리하기보다 상태 중심으로 관리하는 것이 좋습니다.
재고는 단순 숫자처럼 보이지만 주문 흐름과 직접 연결됩니다. 이번 단계에서는 복잡한 재고 예약 시스템까지 만들 필요는 없지만, 최소한 아래 규칙은 정해야 합니다.
이 규칙을 먼저 세워야 프론트와 백엔드가 같은 기준으로 동작합니다.
가격은 상품 운영에서 가장 조심해야 하는 필드입니다. 상품 가격이 바뀌어도 이미 생성된 주문의 금액은 바뀌면 안 됩니다. 그래서 앞 장에서 주문 snapshot을 강조했습니다.
이번 단계의 규칙은 단순합니다.
Catalog의 책임이다Order snapshot에 저장한다이 원칙이 깨지면 운영자 화면에서 가격을 수정하는 순간 결제와 주문 신뢰가 흔들립니다.
처음부터 복잡한 편집기를 만들 필요는 없습니다. 하지만 상세 조회와 수정 책임은 분리하는 편이 좋습니다.
상품 상세 화면은 아래 정보를 보여줍니다.
상품 수정 화면은 아래 항목을 바꿀 수 있게 합니다.
중요한 것은 모든 필드를 한 번에 막 열지 않는 것입니다. 이미지 업로드, 옵션, 쿠폰, 카테고리, 다국어 설명은 후속 확장으로 남겨도 됩니다.
운영자 도구의 검색과 필터는 화면 장식이 아니라 업무 속도를 좌우합니다. 이번 단계에서는 아래 정도가 적절합니다.
검색과 필터는 백엔드 API 계약으로도 드러나야 합니다. 프론트에서만 필터링하면 데이터가 늘어났을 때 운영 화면이 금방 느려집니다.
상품 운영 API는 구매자용 상품 조회 API와 분리하는 편이 좋습니다.
구매자용 API는 공개 storefront 기준입니다.
관리자용 API는 운영 기준입니다.
같은 상품 데이터를 보더라도 API surface는 사용자의 목적에 맞게 나눠야 합니다.
MVP에서는 admin 하나의 역할만으로 시작해도 됩니다. 하지만 교재에서는 권한이 확장될 자리를 남겨야 합니다.
초기 권한은 아래처럼 단순하게 둡니다.
후속 확장에서는 아래처럼 나눌 수 있습니다.
처음부터 복잡한 권한 모델을 구현하지 않더라도, 코드 구조는 권한 검사가 들어갈 위치를 명확히 해야 합니다.
운영자가 상품 가격이나 상태를 바꾸면 나중에 원인을 추적할 수 있어야 합니다. 이번 MVP에서 완전한 audit log를 구현하지 않더라도, 최소한 아래 정보는 남길 수 있게 설계합니다.
처음 구현에서는 updated_at, updated_by 정도로 시작하고, 후속 확장에서 별도 audit log 테이블로 확장할 수 있습니다.
상품 운영 화면을 만들었다면 반드시 storefront에서 함께 확인해야 합니다.
이 확인을 하지 않으면 admin 화면은 동작하지만 실제 서비스 규칙은 깨질 수 있습니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
즉 운영자는 상품을 다룰 수 있고, 구매자 흐름은 상품 변경에 맞게 안전하게 반응해야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
이 산출물이 있어야 다음 페이지에서 AI 상담 챗봇이 참조할 상품 지식과 운영 데이터를 안정적으로 연결할 수 있습니다.
이 일곱 가지 실수는 운영 기능이 늘어날수록 장애로 이어지기 쉽습니다.
이번 페이지에서는 admin을 상품 운영 도구로 확장했습니다. 상품 목록, 상세, 수정 화면을 만들 때 어떤 필드를 보여주고 어떤 규칙으로 바꿔야 하는지 정리했고, 판매 상태와 노출 상태, 현재 가격과 주문 snapshot을 분리해야 하는 이유도 확인했습니다.
다음 페이지에서는 AI 상담 챗봇의 RAG와 백엔드 오케스트레이션을 설계하고, 상품과 주문 맥락을 챗봇이 안전하게 참조하는 구조로 확장합니다.