[쇼핑몰 개발] 주문 처리 & 정산 시스템 설계 가이드

단순한 주문 저장은 끝났습니다. 이제는 정산, 상태 변경, 통계까지 잡아야 운영이 됩니다.

안녕하세요! 이제 드디어 쇼핑몰 시스템의 핵심 중의 핵심인 “주문 → 상태 변경 → 정산” 흐름을 다뤄볼 차례입니다. 이 부분은 단순한 DB 저장만으로는 부족하고, 상태 흐름 관리, 정산 테이블 설계, 대시보드 통계까지 고려해야 “운영 가능한” 시스템이 됩니다. 이번 글에서는 Laravel + MySQL 구조를 기반으로 1) 주문 저장 구조 2) 상태 변경 흐름 3) 정산 데이터 누적 방식 4) 관리자 통계 대시보드 구성 이 4단계를 상세하게 풀어보겠습니다. 실제 프로젝트에서 바로 적용해도 문제없는 구조니까, 꼭 끝까지 따라와주세요!

목차

주문 테이블 스키마 설계 주문 상태 흐름 관리 구조 정산 데이터 구조 및 집계 방식 관리자 대시보드 통계 구성 지연 작업 처리 (취소, 자동확정) 운영자 기준 설계 Best Practice

주문 테이블 스키마 설계

주문 데이터는 기본적으로 orders와 order_items 두 개의 테이블로 분리 설계합니다. 이는 다중 상품, 다중 옵션, 쿠폰/배송비 적용 등을 효율적으로 처리하기 위한 구조입니다.

테이블명	핵심 필드	비고
orders	user_id, total_price, status, paid_at	주문 전체 정보
order_items	product_id, option_set_id, qty, price	상품별 상세 내역

이렇게 나누면 이후 정산, 환불, 리뷰, 배송조회 등 모든 후속 기능이 매우 편해집니다.

주문 상태 흐름 관리 구조

주문 상태는 단순히 문자열 컬럼이 아니라, 상태 흐름을 엄격하게 관리하는 Enum 기반 구조를 추천합니다. Laravel 9 이상에서는 PHP 자체 Enum 기능을 사용해도 좋습니다.

• pending (결제 전)
• paid (결제 완료)
• shipping (배송 중)
• delivered (배송 완료)
• canceled (주문 취소)
• confirmed (구매 확정)

각 상태는 상태 변경 시점에 따라 status_logs에 기록하고, 관리자 대시보드에서는 해당 흐름을 기반으로 일별 통계, 현황을 추적할 수 있어야 합니다.

정산 데이터 구조 및 집계 방식

정산 시스템의 핵심은 “확정된 주문의 총액”을 판매자 / 마켓 관리자 / 제휴 파트너 기준으로 분배할 수 있도록 구조화된 데이터를 쌓는 것입니다. 이를 위해 별도의 settlements 테이블을 설계합니다.

필드명	설명	예시
order_id	주문 고유 번호	10234
amount	총 정산 금액	55000
status	정산 상태 (ready, paid 등)	ready
paid_at	정산 완료 일시	2024-03-10

정산은 보통 주문 확정 후 N일 또는 취소/환불 처리 완료 후에 확정됩니다. Laravel에서는 Schedule + Job을 이용해 일 단위로 집계 스케줄링도 가능하죠.

관리자 대시보드 통계 구성

대시보드는 운영자가 하루에도 수십 번 보는 핵심 페이지입니다. orders와 settlements 데이터를 기반으로 아래와 같은 지표를 시각화하면 효과적입니다.

• 일별 주문 건수 / 매출 / 취소율
• 결제 상태별 주문 현황
• 주문별 배송상태, 리뷰 미작성 비율
• 이번 달 정산 예정 총액

시각화 도구로는 Vue + Chart.js, ApexCharts 등을 추천합니다. Laravel의 쿼리빌더 또는 Eloquent 기반 집계 쿼리와 함께 사용하면 매우 빠릅니다.

지연 작업 처리 (취소, 자동확정)

정산 시스템에서 중요한 또 하나는 자동 상태 변경입니다. 예를 들어, 배송 완료 후 7일이 지나면 자동 구매확정이 되어야 정산이 가능하죠.

• Laravel Schedule로 매일 Job 실행
• 배송 완료 + 7일 → status: confirmed 로 자동 업데이트
• 주문 취소 요청 후 3일간 미응답 → 자동 취소 처리

이런 기능은 php artisan schedule:run 명령으로 주기적으로 실행되며, Queue + Delay Job를 통해 주문 상태 전환도 매우 유연하게 처리할 수 있습니다.

운영자 기준 설계 Best Practice

• 상태 흐름은 Enum + status_log 로 추적 가능하게 설계
• 정산은 구매확정 기준으로만 집계 → 환불 제외 처리
• 관리자 화면에서는 날짜 기준 필터 + 통계 요약 제공
• 대량 작업 (정산 확정, 엑셀 다운로드 등)은 Job 처리

실제로 이 구조를 도입한 이후, 하루 수백 건의 주문도 지연 없이 처리 가능했고, 운영팀에서도 정산 자료를 별도 계산 없이 바로 내려받아 사용할 수 있었습니다.

 

쇼핑몰은 단순히 상품만 잘 올려서는 운영이 되지 않습니다. 정말 중요한 건 “주문 처리 → 상태 흐름 → 정산 흐름 → 운영 UI”까지 설계되어 있어야 진짜 돈이 들어오고, 사람이 움직이고, 고객 만족도도 올라갑니다. 이번 글에서는 Laravel + MySQL 조합으로 주문 저장, 상태 변경, 자동화, 정산, 통계 UI까지 모두 연결해봤습니다. 실제로 제가 운영했던 시스템도 이 구조를 기반으로 매출 수억 원 이상을 안정적으로 처리했어요. 이제 정말 운영 가능한 쇼핑몰 백엔드 아키텍처의 기초는 완성됐습니다. 다음 편에서는 리뷰 시스템, 포인트/쿠폰, 회원 등급과 같은 부가 기능도 확장해볼 예정입니다. 질문은 언제든 댓글로 남겨주세요! 읽어주셔서 감사합니다 🙏