[Next Table Order #4] 테이블 오더 시스템에서 가격이 꼬이는 순간

2025. 2. 24.

[Next Table Order #4] 테이블 오더 시스템에서 가격이 꼬이는 순간

💀 "이거 왜 가격이 달라요?"

"사장님, 지난주에도 이거 시켰는데 그땐 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_itemsorder_item_options에 저장해야 한다.
2️⃣ 총 가격은 조회할 때 계산해야 한다.
3️⃣ 프론트엔드라도 데이터베이스 모델링을 이해해야 한다!


"사장님, 터키 샌드위치 하나, 화이트 브레드, 치즈 추가요!"
"네, 총 8,490원입니다. (당황하지 않음)"

이제야 비로소, 완벽한 테이블 오더 시스템이 완성되었다.

🚀 이 고민을 안 했다면?
🙃 나중에 터질 문제를 미래의 나에게 떠넘기는 중일 수도 있다.