💀 "이거 왜 가격이 달라요?"
"사장님, 지난주에도 이거 시켰는데 그땐 7,000원이었어요. 근데 오늘 7,500원이네?"
"네? 그럴 리가 없는데요… 잠시만요…"
📉 사장님의 표정이 굳어간다.
📉 POS 시스템을 켜고 주문 내역을 확인하는데…
📉 진짜 가격이 달라졌다.
이제 주방에서 바쁜 직원들이 웅성거리기 시작한다.
"이거 원래 얼마였지?"
"옵션 가격이 왜 없어졌지?"
"이거 누가 손댄 거야?"
개발자의 손이 덜덜 떨린다.
"아… 설마… 옵션 가격을 실시간으로 가져오게 했던 건가?"
🙃 이거… 내가 그렇게 만들었는데?
🚨 옵션 가격을 실시간으로 불러오면 벌어지는 일들
솔직히 말하면, 나도 처음에는 옵션 가격을 따로 저장할 필요 없다고 생각했다.
그래서 menu_options
테이블에서 실시간으로 불러오게 설계했다.
"그냥 조인해서 가져오면 되잖아?" 라고.
그리고…
미래의 내가 피눈물을 흘리게 되었다.
이 방식이 왜 위험한지 볼까?
1️⃣ 옵션 가격이 나중에 바뀌면?
- "오늘 Extra Cheese는 1,500원이었는데 다음 주엔 2,000원이래!"
- 근데 기존 주문 내역도 다 2,000원으로 바뀌어 있음.
- 과거 주문이 조작당하는 순간 🫠
2️⃣ 과거 주문 내역을 다시 보면?
- "1년 전 손님이 '내가 그때 얼마 냈는지 알려줘요'라고 하면?"
- …음… 우린 아무것도 알 수 없다.
- "그때 얼마였더라?" → 사라진 주문 히스토리
3️⃣ 환불이나 클레임 대응이 어려워진다
- "이거 원래 1,000원이었는데 왜 지금 보면 1,500원이에요?"
- 사장이 개발자한테 전화함.
- "너 이거 어떻게 만든 거야?"
- 미래의 나 → 과거의 나를 원망하는 중
🙅♂️ 이런 일 안 겪고 싶으면? 주문 당시의 가격을 저장해야 한다.
✅ 주문 당시 가격을 저장해야 한다
🎯 해결책: "메뉴 가격 + 옵션 가격을 따로 저장해라!"
주문 시점의 가격을 그대로 저장하면, 가격이 바뀌어도 과거 주문 내역은 그대로 남는다.
메뉴 가격 + 옵션 가격을 각각 저장하고, 조회할 때 합산하자!
📌 테이블 설계
✅ 주문 당시 가격을 저장하는 방법
주문번호 | 메뉴명 | 수량 | 메뉴 가격 | 옵션명 | 옵션 가격 | 총 가격 |
---|---|---|---|---|---|---|
101 | 터키 샌드위치 | 1 | 6.99 | 화이트 브레드 | 0 | 6.99 |
101 | 터키 샌드위치 | 1 | 6.99 | 치즈 추가 | 1.50 | 8.49 |
✅ order_items
테이블 (메뉴 가격 저장)
id | order_id | menu_id | quantity | price (메뉴 가격) |
---|---|---|---|---|
1 | 101 | A001 | 2 | 5.99 |
2 | 101 | B002 | 1 | 7.99 |
✅ order_item_options
테이블 (옵션 가격 저장)
id | order_item_id | option_id | option_price |
---|---|---|---|
1 | 1 | O001 | 1.50 |
2 | 1 | O002 | 2.00 |
3 | 2 | O003 | 1.00 |
🧠 가격을 실시간이 아니라 계산해서 가져오는 이유
이제, 주문 가격을 계산할 때 실시간으로 불러오는 게 아니라, 저장된 값들을 합산해서 조회하면 된다.
SELECT
SUM(order_items.price * order_items.quantity + COALESCE(SUM(order_item_options.option_price), 0)) AS total_price
FROM order_items
LEFT JOIN order_item_options ON order_items.id = order_item_options.order_item_id
WHERE order_items.order_id = 101;
✅ 과거 주문 내역이 정확하게 유지된다.
✅ 가격이 바뀌어도 문제없다.
✅ 환불, 고객 문의에도 정확한 데이터 제공 가능.
🚀 프론트엔드도 이런 고민을 해야 한다
솔직히 말해서, 처음엔 "옵션 가격? 조인해서 가져오면 되지!" 생각했다.
하지만 그게 미래의 나를 힘들게 만드는 지름길이었다.
💡 "프론트엔드 개발자가 이런 고민을 해야 해?"
👉 그렇다.
👉 백엔드 API가 어떤 데이터 구조를 반환하는지 이해해야 한다.
👉 잘못된 데이터 설계는 유지보수 지옥을 부른다.
🔥 결론: 주문 시스템 만들 땐 이걸 기억하자!
1️⃣ 주문 시점의 가격을 order_items
과 order_item_options
에 저장해야 한다.
2️⃣ 총 가격은 조회할 때 계산해야 한다.
3️⃣ 프론트엔드라도 데이터베이스 모델링을 이해해야 한다!
"사장님, 터키 샌드위치 하나, 화이트 브레드, 치즈 추가요!"
"네, 총 8,490원입니다. (당황하지 않음)"
이제야 비로소, 완벽한 테이블 오더 시스템이 완성되었다.
🚀 이 고민을 안 했다면?
🙃 나중에 터질 문제를 미래의 나에게 떠넘기는 중일 수도 있다.