장바구니

개요

B2B 전용몰 장바구니 기능. 단순 상품 담기가 아닌, 기업별 계약가·재고·행사를 실시간 반영하는 동적 장바구니를 설계했다.

장바구니 진입 시 DB 프로시저가 모든 상품의 가격/재고를 일괄 갱신하여, 사용자에게 항상 최신 정보를 보여준다.

---

왜 이 설계가 필요했는가 (Problem)

B2C 장바구니와 다른 B2B의 3가지 핵심 난제 — 단순 FK 참조 모델·애플리케이션 갱신으로는 해결 불가능했다.

이 3가지를 동시에 해결하기 위해 DB 프로시저 + 장바구니 스냅샷 컬럼 의 조합으로 결정했다.

---

테이블 설계

설계 배경 — 왜 5개 컬럼으로는 부족했나

초기 장바구니 테이블은 단순한 FK 참조 테이블이었다.

-- 초기 설계: 단순 FK 참조
장바구니(장바구니 ID, 기업, 사용자, 상품, 수량)

B2B 전용몰의 장바구니는 B2C와 다른 요구사항이 있었다.

이 요구사항들을 반영하면서 5개 컬럼짜리 참조 테이블이 가격 · 상품 · 공급사 스냅샷을 담는 수십 개 컬럼으로 확장되었다.

장바구니 최종 구조

왜 스냅샷 컬럼이 필요했나

스냅샷 컬럼 없이도 기능 자체는 구현할 수 있다. 장바구니 조회 시 상품 · 기업별 상품(계약가) · 기업 테이블을 매번 JOIN하거나, 주문 생성 시 그 시점에 직접 상품/가격을 조회하면 된다.

그러나 스냅샷 컬럼과 프로시저는 세트다.

인덱스 설계

---

핵심 설계 결정 — 장바구니 갱신 프로시저

검토했던 대안들 (Analyze)

“장바구니 진입 시 모든 상품의 최신 가격·재고 동기화”를 위한 5가지 방법을 비교했다.

비교: 애플리케이션 레벨 vs DB 프로시저

❌ 애플리케이션 레벨로 구현했다면

장바구니 아이템 N개를 순회하며 상품당 3회 쿼리(상품 조회 → 계약가 조회 → UPDATE)가 발생한다.

// 애플리케이션 레벨로 갱신한다면 (가정한 의사코드)
장바구니 = 사용자 · 기업의 장바구니 조회  // 1회
for 항목 in 장바구니:  // N개 순회
    상품 = 상품 최신 정보 조회(항목)  // N회
    if 상품 없음 또는 판매중지: 항목 삭제 표시, 다음 항목으로
    계약가 = 기업별 계약가 조회(항목, 기업)  // N회
    할인가 = 할인 계산(정가, 할인율)  // 메모리에서 계산
    수량 = 재고 · 최대 주문수량에 맞춰 조정
    장바구니 스냅샷 갱신(할인가, 계약가, 수량)  // N회
// 총 쿼리: 1 + 3N (상품 20개 → 61회)

✅ DB 프로시저로 구현한 결과

단 1회 CALL로 DB 내부에서 커서 기반 일괄 처리한다.

-- 장바구니 갱신 프로시저 (요지)
FOR 항목 IN (사용자 · 기업의 장바구니) LOOP  -- 커서로 DB 안에서 순회
    상품 정보 조회 · 판매 가능 검증  -- DB 내부 호출, 네트워크 왕복 없음
    기업별 계약가 조회
    할인가 = FLOOR(정가 × (1 − 할인율 / 100))
    수량 = 재고 · 최대 주문수량에 맞춰 조정
    UPDATE 장바구니 SET 판매단가 · 할인가 · 계약가 · 수량 …
END LOOP

성능 비교 (장바구니 상품 20개 기준)

프로시저 동작 흐름

프로시저 핵심 로직

---

설계가 만든 결과 (Result)

측정 조건

실측 결과

장바구니 20개의 가격·기업계약가·재고를 1회 CALL 로 갱신하는 데 p95 78ms.

병목은 프로시저가 아니라 커넥션 풀이었다

부하 구간의 서버측 지표가 병목 위치를 특정했다.

트랙 순도 가드 검증

재측정 — 풀 크기만 바꿔 A/B (2026-08-30)

이 재측정이 말하지 않는 것

이 측정이 말하지 않는 것