백오피스 화면설계 심화 (6)

백오피스 주문 관리 화면 설계 정리

1. 주문 관리의 본질

주문 관리는 단순히
“주문 목록을 보여주는 화면”이 아니다.

백오피스에서 주문 관리는 다음 역할을 동시에 수행한다.

• 결제 상태 관리
• 배송 상태 관리
• CS(취소·교환·반품) 처리
• 고객 정보 확인
• 상품 정보 확인
• 외부 시스템(TMS 등) 연동 허브

즉, 주문 관리는 여러 메뉴를 연결하는 ‘중앙 관제판’에 가깝다.

 

2. 주문 관리가 복잡해지는 첫 번째 이유: 상태값(State)

주문 관리에서 가장 중요한 개념은 상태값 관리다.

주문은 단일 상태가 아니라
시간 흐름에 따라 상태가 계속 변한다.

2.1 대표적인 주문 상태 흐름

일반적인 상품 주문 기준 예시는 다음과 같다.

• 입금 전
• 결제 완료
• 배송 준비 중
• 배송 중
• 배송 완료
• 취소
• 교환
• 반품

관리자는 이 상태값을 기준으로
무엇을 지금 처리해야 하는지를 판단한다.

 

2.2 상태값이 중요한 이유

• 처리 우선순위 판단
• 일괄 처리 가능 여부 판단
• CS 대응 가능 여부 판단
• 배송 연동 여부 판단

👉 그래서 주문 관리 화면에서는
상태값을 한눈에 보고, 빠르게 조작할 수 있어야 한다.

 

해당 상품을 선택해서 바로 주문 처리를 할 수 있게끔 구조가 만들어져야 한다는 거죠.
지금 이건 다 주문 처리가 돼서 지금 안 나오지만, 만약에 입금 전이나 배송 준비 전 상태가 있었으면
선택 후에 배송 중 처리라든지 선택 후에 일괄 처리 같은 기능들이 같이 있지 않으면
엄청나게 불편한 시스템이 되다 보니까
주문 관리에서는 이 상태값 관리를 일괄적으로 해줄 수 있는 것이 굉장히 중요한 거죠.

 

 

CS 처리를 하기 위해서 주문 상세 페이지로 들어가서 해당 정보를 확인하고 고객 정보까지 확인할 수 있겠죠.
지금 신청하신 분이 어떤 계좌로 입금하신 게 맞아요라고 확인한 다음에
거기에 대한 주문 처리를 교환을 할 건지 주문 취소를 할 건지
이런 부분들을 결정해서 어떤 CS 처리가 가능하게끔 만들어줘야 된다는 거죠.

 

 

회원 정보 상세 보기 같은 걸 누르게 되면 아까 우리가 봤던 회원 정보 상세 페이지로 이동시켜서
같이 볼 수 있게끔 만드는 것도 주문 관리의 특성인 거죠.

3. 주문 목록(조회) 페이지 설계

3.1 주문 조회 조건

주문 관리의 조회 조건은 회원 관리와 비슷하거나 그 이상으로 많다.

일반적인 조회 조건 예시는 다음과 같다.

• 주문번호
• 회원명 / 회원 아이디
• 결제 수단
• 주문 상태
• 배송 상태
• 주문일
• 결제일

이는 CS 대응과 직결된다.

“주문번호 몇 번인데요…”
→ 바로 조회 가능해야 한다.

 

3.2 주문 목록 데이터 테이블

주문 목록에서는
처리 판단에 필요한 핵심 정보만 노출한다.

 

예시

• 주문번호
• 주문일
• 주문자
• 결제 상태
• 배송 상태
• 결제 금액

상세 판단은 주문 상세 페이지에서 진행한다.

 

4. 주문 일괄 처리 기능의 중요성

주문 관리에서
일괄 처리 기능은 필수다.

4.1 왜 필요한가

• 입금 전 주문 다수 존재
• 배송 준비 완료 주문 다수 존재
• 동일 상태 주문 반복 처리

이때 다음 기능이 없으면 관리자는 극심한 피로를 느낀다.

• 선택 후 배송 처리
• 선택 후 상태 변경
• 선택 후 취소 처리

👉 주문 관리 화면에서는
상태 기반 일괄 처리 버튼이 반드시 필요하다.

 

5. 주문 상세 페이지의 역할

5.1 CS 처리의 중심

주문 상세 페이지는 CS 대응의 출발점이다.

 

예:

• “받은 상품이 불량이에요”
• “취소하고 싶어요”
• “배송이 안 와요”

관리자는 주문 상세 페이지에서 다음을 동시에 확인한다.

• 주문 정보
• 결제 정보
• 배송 정보
• 고객 정보

 

5.2 주문 상세에서 가능한 처리

주문 상세 페이지에서는 다음 처리가 가능해야 한다.

• 취소 처리
• 교환 처리
• 반품 처리
• 상태 변경
• 관리자 메모 작성

이 모든 처리는
상태값과 연동되어야 한다.

 

6. 배송 관리와 외부 시스템 연동

실물 상품을 판매하는 경우
배송 관리는 주문 관리의 핵심이다.

6.1 배송 상태 확인의 중요성

• 아직 배송 전인데 반품 처리 ❌
• 고객은 수령 못 했는데 배송 완료 처리 ❌

이를 방지하기 위해
TMS(Transport Management System) 같은 배송 관리 시스템과 연동한다.

 

관리자는

• 현재 배송 위치
• 배송 완료 여부

를 확인한 후 CS 처리를 진행한다.

 

7. 주문 관리의 연결 구조 (핵심 포인트)

주문 관리의 가장 중요한 특성은 다른 메뉴로의 연결 허브 역할이다.

 

주문 관리 화면에서는

• 회원 정보 상세 페이지로 이동 가능
• 상품 상세 페이지로 이동 가능
• 결제/배송 시스템과 연동 가능

즉,

주문 = 회원 + 상품 + 결제 + 배송의 교차점

 

 

8. 단순화된 주문 관리 샘플 구조

공유된 주문 관리 샘플은
카페24보다 훨씬 단순하지만
핵심 구조는 동일하다.

8.1 주문 목록

• 주문 목록 제공
• 예약번호 = 주문번호 역할
• 상태값 표시

 

8.2 주문 상세

• 선택 시 상세 정보 제공
• 필요한 처리 기능만 제공

서비스 특성상

• 복잡한 배송 관리 ❌
• 단순 예약/결제 흐름 ⭕️

👉 요구사항에 맞게 축소된 구조다.

 

9. 공통 코드 관리와의 관계

질문에서 언급된

• 지역
• 유형
• 법인

과 같은 값들은 상품이 아니라 ‘공통 데이터’다.

 

따라서

• 상품 관리에서 직접 추가 ❌
• 공통 코드 관리에서 관리 ⭕️

공통 코드 관리는:

• 여러 화면에서 재사용
• 데이터 정합성 유지
• 정책 변경 대응

을 위해 분리된다.

 

카페24 분류 관리 방식

카페24는

• 상품 관리 화면에서도 분류 추가 가능
• 기능적으로 매우 강력함

하지만 실제 프로젝트 기준으로 보면

• 구현 공수 큼
• 유지보수 부담 큼

👉 일반적인 프로젝트에서는

• 분류 추가 → 분류 관리 메뉴
• 상품 관리에서는 “선택만”

하는 방식이 더 효율적이다.

 

상품은 이 카테고리의 종속적으로 움직이게 되어 있어요.
현재 카페 24는 그래서 만약에 이걸 다른 카테고리로 옮기게 되면 얘는 거기서만 볼 수가 있어요.
일단 이거는 문제는 없어요. 정책적으로 문제는 없습니다.

정책을 정한 거죠. 이렇게 상품을 이동했을 때 카테고리가 이동한 곳을 따라간다가 정책이죠.
근데 카페 24는 이걸 보완하기 위해서 하나의 상품이 두 개 이상의 카테고리를 지닐 수 있게 만들어 놨어요.
그러니까 꼭 상품이 이 안에만 있는 것이 아니라
멀티로 되어 있는 카테고리를 지닐 수 있게 되어서 이 부분이 이거죠.

 

10. 상품과 카테고리 이동 정책

질문에서 나온 핵심 쟁점:

“상품이 카테고리를 따라 이동해도 괜찮은가?”

 

정답은

• ❌ 문제 아님
• ⭕️ 정책의 문제

 

10.1 일반적인 정책 두 가지

1. 단일 카테고리 정책
   • 상품은 하나의 카테고리만 소속
   • 이동 시 기존 카테고리에서 제거
2. 다중 카테고리 정책 (카페24 방식)
   • 상품은 여러 카테고리에 소속 가능
   • 하나를 변경해도 다른 카테고리에 남음

카페24는 2번 방식을 채택했다.

 

어떤 게 더 맞는가?

정답은 없다.

• 서비스 성격
• 운영 방식
• 관리 난이도

에 따라 선택한다.

 

중요한 건 정책을 명확히 정하고 설계에 반영하는 것이다.

주문 관리 설계 핵심 요약

• 주문 관리는 상태값이 생명이다
• 일괄 처리는 필수다
• CS 대응 중심으로 설계해야 한다
• 주문은 여러 메뉴를 연결하는 허브다
• 정책(카테고리/상태)은 설계 전에 확정해야 한다

 

기획자 유의사항

주문 관리 화면은
“보는 화면”이 아니라
“지금 무엇을 처리해야 하는지 바로 알 수 있는 화면”이어야 한다.

이 기준으로 설계하면
주문 관리 파트는 현업에서 바로 통과된다.