주문/결제

개요

B2B 구매 전체 프로세스를 담당하는 핵심 기능. 장바구니 → 주문(SO) → 공급사별 발주(PO) → 결제(PG/여신) → 배송까지의 흐름을 SO/PO 이중 구조로 설계했다.

하나의 주문에 여러 공급사 상품이 포함될 수 있으므로, 공급사별 배송·정산을 독립적으로 관리한다.

---

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

B2B 전용몰에서 마주친 3가지 핵심 난제 — 단일 SO 모델·애플리케이션 레벨 트랜잭션으로는 해결 불가능했다.

이 3가지를 동시에 해결하기 위해 SO/PO 이중 구조 + DB 프로시저 + SELECT FOR UPDATE 행 잠금 의 조합으로 결정했다.

---

테이블 설계 — SO/PO 이중 구조

검토했던 대안들 (Analyze)

ERD (핵심 관계)

테이블별 설계 의도

주문 상태 머신 (13개):

---

핵심 설계 결정

1. 주문 생성 프로시저 — 트랜잭션 정합성 + 동시성 제어

검토했던 6가지 대안 (Analyze)

“여러 테이블 동시 INSERT + 여신 차감”의 트랜잭션 정합성과 동시성을 보장할 6가지 방법을 비교했다.

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

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

주문 생성 시 상품 N개, 공급사 M개 기준으로 다수의 독립 쿼리가 발생한다.

// 애플리케이션 레벨 구현(가정) — 라인마다 쿼리를 반복하면
장바구니 조회  // 1회
주문 헤더 저장 + 주문번호 채번  // 2회
for 장바구니 라인: 주문 라인 저장  // N회
for 공급사: 발주 저장, for 라인: 발주 라인 저장  // M + N회
결제 저장  // 1회
if 여신 결제: 여신 조회 + 차감  // 2~3회
for 장바구니 라인: 장바구니 삭제  // N회
// 골격만도 3N + 2M + 6 ≈ 42회 (상품 10 · 공급사 3). 라인별 가격 재검증 · 재고 잠금까지 넣으면 더 많다

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

주문 생성 프로시저 1회 CALL로 SO측 다중행(헤더 + 라인 N + 배송지 + 이력 + 장바구니 정리)을 원자적으로 처리한다. 여신 차감·PO·결제는 포함하지 않는다(앱 계층·발주 생성 프로시저 담당).

-- 주문 생성 프로시저 — SO 쪽 다중행 처리만 1 CALL 로
BEGIN
    -- 1. 정합성 검증 (배송지 · 결제수단 · 주문불가 상품)
    -- 2. 주문 헤더 INSERT (주문요청대기 재사용 또는 신규) + 주문번호 채번
    -- 3. 배송지 스냅샷 INSERT
    -- 4. 커서로 장바구니 라인 순회: 상품 SELECT ... FOR UPDATE (재고) → 카트가 vs 현재가 재검증 → 주문 라인 INSERT → 재고 차감
    -- 5. 헤더 금액 집계 + 이력 + (결재선) + 장바구니 정리
END;
-- 여신 차감 · PO · 결제는 하지 않는다 (Spring @Transactional 서비스가 담당)

성능 비교 (주문 1건 · 장바구니 20라인 기준)

// k6 — 동시 주문 부하 + 이중차감 검증 (요지)
import http from 'k6/http';
import { check } from 'k6';
export const options = { scenarios: { burst: {
  executor: 'shared-iterations', vus: 120, iterations: 120, maxDuration: '120s' } } };
export default function () {
  const res = http.post(__ENV.URL, PAYLOAD, { headers: H });
  check(res, { created: (r) => r.status === 200 });
}
// 종료 후: SELECT 여신잔액 — 음수면 이중차감(락 미적용), 0 이상이면 차단 성공(프로시저)

프로시저 처리 순서:

2. 스냅샷 전략 — 3개 원본 → 3개 대상 복사

3개 원본(상품 · 사용자 · 기업)에서 3개 대상(주문 헤더 · 주문 라인 · 발주)으로 주문 시점 데이터를 스냅샷 복사한다.

이후 상품 가격·사용자 정보가 변경되어도 기존 주문에 영향 0건 — 가격 변동에 의한 정산 분쟁을 원천 차단한다.

3. 이중 상태 머신 — SO 13개 + 발주 라인 독립 상태

SO 전체가 “배송중”이더라도, 개별 발주 라인은 공급사별로 다른 배송 상태를 가질 수 있다.

SO 13개 상태 전이 + 발주 라인 별도 배송 상태 → 공급사별 독립 추적으로 복합 주문의 부분 배송·부분 취소를 정확히 표현한다.

4. 결제 이중 경로

• PG 결제: PG 결제창 → 승인 → 결제 키로 서버 확인(결제 승인 API) → 발주 생성
• 여신/예산: 앱 계층에서 기업 여신 행 FOR UPDATE 잠금 + 차감 → 발주 생성 → 즉시 완료
• 여신/예산 4단계 출처(사용자·조직·계정조직 예산 + 기업 여신): 자동 폴백이 아니라 권한 위계 순으로 제시 → 사용자 선택. 예산사용 기업은 예산 필수, 비예산 기업은 기업 여신 직접 차감

5. 결제 멱등성 — 중복 승인 차단

6. 실패·보상 처리

7. 여신 동시성 — 단일 직렬화 지점

---

설계가 만든 결과 (Result)

실험 설계

결과 — 초과차감 0건

재측정 — 매퍼 가드 제거 후에도 초과차감 0건 (2026-08-30)

부하 중 발견한 실제 결함 — 동시 주문 데드락

핵심만 요약하면 — 이 부하에서 난 교착의 원인은 ① 상품 ↔ 채번 카운터 잠금 순서 역전, ② 주문번호 임시값 ‘TEMP’ 의 유니크 인덱스 충돌, ③ 채번 루틴 내부의 S→X 승격 세 가지다. 메커니즘이 서로 달라 하나만 고치면 개선이 안 나거나 교착이 다른 자원으로 옮겨간다.

부수 확인 — §6 실패·보상 처리가 실증되었다

이 측정이 말하지 않는 것