이제부터는 구매자 흐름 위에 운영 관점의 화면을 본격적으로 올립니다. 07장까지에서 우리는 상품 탐색, 인증, 장바구니, 주문 생성, 결제 확인, 주문 완료 화면까지 구현했습니다. 하지만 실전 서비스는 구매자 화면만으로 끝나지 않습니다. 운영자는 현재 어떤 주문이 들어왔는지, 결제가 어디서 막혔는지, 어떤 고객이 어떤 상태에서 도움을 필요로 하는지 볼 수 있어야 합니다.
이번 페이지의 목적은 admin을 단순 관리자 로그인 앱에서 벗어나, 주문과 결제와 고객 지원 상태를 읽고 판단하는 운영 surface로 확장하는 것입니다. 여기서 중요한 것은 "기능이 많아 보이는 대시보드"가 아닙니다. 운영자가 지금 무엇을 먼저 봐야 하는지, 어떤 상태를 구분해야 하는지, 지원 맥락을 주문 흐름과 어떻게 연결해야 하는지를 정리하는 것입니다.
즉 이번 장은 구매가 끝난 뒤의 데이터를 운영자가 실제로 다룰 수 있는 첫 화면 체계를 만드는 단계입니다.
운영자 입장에서 이 세 가지는 분리된 모듈이 아닙니다.
이 셋을 따로 보면 맥락이 끊깁니다. 예를 들어 결제 실패만 보면 기술 문제처럼 보일 수 있지만, 고객 문의와 같이 보면 사용자 경험 문제라는 것을 바로 알 수 있습니다. 따라서 이번 교재에서는 운영 화면의 첫 묶음을 주문/결제/지원으로 같이 보는 것이 자연스럽습니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
이번 단계의 운영 화면은 모든 관리 기능을 다 넣는 것이 아닙니다. 우선은 아래 책임이 먼저 성립해야 합니다.
즉 운영 화면은 "편집 도구"보다 먼저 "판단 도구"로 작동해야 합니다.
운영자는 처음부터 주문 상세 한 건만 보지 않습니다. 보통은 전체 상황을 먼저 봅니다. 따라서 초기 운영 화면은 아래 질문에 답할 수 있어야 합니다.
이 질문에 답할 수 있는 최소 요약이 있어야 운영자가 어디를 먼저 봐야 하는지 판단할 수 있습니다.
이번 단계에서는 아래 정도면 충분합니다.
중요한 것은 카드 수를 늘리는 것이 아니라, 운영 우선순위를 보여주는 것입니다.
주문 목록은 운영자가 전체 흐름을 따라가는 기본 화면입니다. 따라서 아래 정보가 우선입니다.
이 여섯 가지가 있으면 운영자는 목록만 보고도 어떤 주문이 어디 단계에 있는지 대략 파악할 수 있습니다.
상세 화면은 목록에서 보이지 않는 맥락을 채워야 합니다. 이번 단계에서는 아래 정도가 필요합니다.
즉 상세 화면은 "이 주문이 왜 현재 상태인가"를 설명할 수 있어야 합니다.
운영자에게 결제 상태는 주문 상태와 비슷해 보여도 우선순위가 다를 수 있습니다. 예를 들어 주문은 payment_pending인데 결제는 failed라면, 운영자는 즉시 봐야 할 수 있습니다. 따라서 이번 교재에서는 결제 상태를 주문 상태 안에 묻지 않고, 별도 배지나 별도 컬럼으로 드러내는 편이 좋습니다.
운영자 화면에서 최소한 아래 구분은 명확해야 합니다.
이 세 가지가 바로 보이지 않으면 운영 우선순위가 흐려집니다.
상태 배지는 장식이 아닙니다. 운영자가 한눈에 현재 상태를 읽기 위한 압축 표현입니다. 따라서 이번 단계에서는 아래 원칙이 좋습니다.
즉 같은 failed인데 어떤 화면에서는 빨갛고 어떤 화면에서는 회색이면 안 됩니다.
이번 장은 아직 AI 챗봇 자체를 붙이는 장은 아니지만, 운영자 화면은 고객 지원 맥락이 들어올 자리를 먼저 가져야 합니다. 최소한 아래를 생각할 수 있어야 합니다.
이 정보가 바로 다 완성되지 않더라도, 주문 상세 화면 안에서 지원 맥락을 볼 수 있는 구조는 먼저 잡아 두는 편이 좋습니다.
초기 운영 화면에서는 목록에서 너무 많은 액션을 열기보다, 읽기와 이동 중심으로 두는 편이 좋습니다.
예를 들어 이번 단계에서는 아래 정도가 자연스럽습니다.
반대로 모든 상태 변경 버튼을 목록 행마다 다 두기 시작하면 운영 화면이 금방 복잡해집니다.
운영 화면도 사용자 화면만큼 상태 처리가 중요합니다.
특히 운영 화면에서는 empty 상태와 error 상태를 명확히 구분해야 합니다. 주문이 없는 것과 조회가 실패한 것은 완전히 다른 상황이기 때문입니다.
운영 화면은 이미 admin surface이므로, 권한 문제를 더 명확히 다뤄야 합니다.
이 셋은 각각 다른 상태입니다. 따라서 보호 라우트와 조회 오류를 한 화면으로 뭉개지 않는 것이 중요합니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
즉 운영자는 이제 실제 주문 흐름을 읽을 수 있어야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
이 산출물이 있어야 다음 페이지에서 상품 운영 도구를 붙여 운영 surface를 더 확장할 수 있습니다.
이 여섯 가지 실수는 다음 장의 운영 도구와 AI 상담 챗봇 연동을 바로 불안정하게 만듭니다.
이 페이지에서 우리는 운영자 surface를 주문과 결제와 고객 지원 상태를 읽는 화면으로 세우고, 대시보드와 목록과 상세가 각각 어떤 책임을 가져야 하는지 정리했습니다. 또한 운영자 화면은 단순 조회가 아니라, 어떤 주문을 먼저 보고 어떤 문제를 먼저 처리할지 판단할 수 있는 화면이어야 한다는 점도 확인했습니다.
다음 페이지에서는 이제 상품 운영과 관리자 도구를 붙여, 운영자가 조회를 넘어서 관리 작업까지 수행할 수 있는 surface로 확장합니다.