결제 플로우 수립

[wlgns12370]

배경

결제 도입이 확정되면서, 신청과 결제를 하나의 트랜잭션으로 결합할지, 두 단계로 분리할지 결정이 필요합니다.

전제가 되는 제약은 다음과 같습니다.

• 슬롯 선점은 방안 A(1 Row LOCKED, 비관적 락 — discussion.md) 채택 상태입니다. 즉 예약 트랜잭션은 BRANCH_TIME_SLOT 행 하나의 락을 잡고 지나갑니다.
• 결제는 stripe 라는 외부 시스템에서 일어나므로 MySQL 트랜잭션 안에 넣을 수 없습니다.
• 따라서 이 논의의 쟁점은 "어느 쪽이 정합성을 보장하느냐"가 아니라, "같은 오류가 터졌을 때 어느 쪽이 싸게 끝나느냐"입니다.

---

해결방안

방안 1: 결합 (신청 + 결제 단일 요청)

서버가 한 요청 안에서 슬롯 락 획득 → 재고 차감 → PG 승인 호출 → 응답에 따라 커밋 또는 롤백까지 수행합니다. 클라이언트는 요청을 한 번만 보내면 됩니다.

핵심 문제가 그림에 그대로 드러납니다 — 슬롯 비관락(discussion.md 방안 A)의 점유 구간 안에 외부 호출(PG)이 들어가면서, 락 점유 시간이 우리 코드가 아니라 PG 응답 속도에 종속됩니다. 즉 동시에 요청한 사용자가 다른 사용자가 결제할때까지 기다려야하는 상황이 발생할 수 있습니다.

방안 2: 분리 (선점 → TTL 내 결제)

결제를 하기 전에 자리가 먼저 선점되고, 자리를 반납하기 전에 돈의 상태를 먼저 확인하는 구조입니다. 락이 필요한 작업(①선점)과 외부 시스템이 개입하는 작업(②결제, ③승격)이 서로 다른 로컬 트랜잭션으로 분리되고, 그 사이의 유실은 하단의 워커·아웃박스 릴레이가 메웁니다.

---

오류 전파 비교 — 동일한 오류, 다른 결과

결제 오류의 발생 확률은 두 방안이 동일합니다. 달라지는 것은 오류가 터졌을 때의 결과와 복구 경로입니다.

오류 (발생 확률은 양쪽 동일)	방안 1: 결합	방안 2: 분리
카드 거절·잔액 부족	예약 전체 무효, 자리 뺏김, 처음부터 재경쟁	자리 유지한 채 TTL 내 재시도, 돈 안 움직임
승인 타임아웃 (상태 불명)	슬롯 락을 잡은 채 대기 → 해당 슬롯 예약 전면 정지 + 불명 상태	PENDING 유지, 락 없음 → 역조회로 판별
결제 성공 + 웹훅/응답 유실	돈 나감 + 예약 없음 → 환불 + CS	돈 나감 + 자리 잡혀 있음 → 역조회 후 승격
이중 결제 시도	멱등키 필요	동일하게 필요 (예약번호 = PG 주문번호 1:1)
환불 자체의 실패	재시도 큐 필요 (환불이 일상적 복구 경로)	동일하게 필요 (단, 환불이 희귀 사고로 감소)

---

방안별 장단점

관점	방안 1: 결합	방안 2: 분리
정상 경로 복잡도	✅ 요청 1번, 상태 적음, TTL 없음	❌ 2단계 플로우, PENDING_PAYMENT 상태 추가, TTL 2개(결제 5분 + 픽업 2시간)
최악 실패의 복구	❌ "돈 나감+예약 없음" → 환불이 기본 복구	✅ "돈 나감+자리 있음" → 승격이 기본 복구
DB 락과 외부 호출	❌ 슬롯 비관락을 잡은 채 PG 응답(1~30초)을 대기 → 락 점유 시간이 외부 지연에 종속	✅ 락 트랜잭션은 밀리초 로컬 작업, 결제는 락 밖
응답 시간 (NFR 평균 2초)	❌ PG 지연에 종속	✅ 선점 API는 로컬 TX만
결제 실패 시 UX	❌ 자리 소실, 재경쟁	✅ TTL 내 다른 카드로 재시도 가능
유령 선점 (결제 안 할 자리 점유)	✅ 원천 불가능	❌ 5분간 자리가 미결제자에게 잠김, 봇 악용 여지
국내 PG 플로우 호환	❌ 결제창 리다이렉트/앱 인증은 클라이언트-PG 상호작용이라 서버 호출 1번에 물리적으로 못 넣음	✅ 토스페이먼츠(주문 생성→결제창→승인 API)·Stripe(Intent→confirm→웹훅) 표준 연동과 동형
운영 부품	✅ 적음 (단, 사고 시 수동 CS)	❌ 역조회 워커·웹훅 dedupe 등 자동화 부품 필요
전환 퍼널	✅ 이탈 지점 1개	❌ 선점↔결제 사이 이탈 지점 1개 추가

정리하면 방안 1의 장점은 전부 "정상 경로가 단순하다"에 있고, 방안 2의 장점은 전부 "오류가 터졌을 때 싸게 끝난다"에 있습니다. 결제는 카드 거절만 몇 %에 이르는, 오류가 일상인 도메인입니다.

---

분리(방안 2)의 단점과 완화책

단점	완화책	비고
유령 선점·봇 점유	인증 유저만 선점 가능 + 동시 PENDING 1건 제한 + 짧은 TTL(5분)	노쇼 제재용 신뢰 인프라(USER_SANCTION)를 그대로 재사용
상태 머신 복잡화	모든 전이를 CAS(조건부 UPDATE)로 통일 — QR redeem에서 이미 쓰는 패턴 재사용	새 패턴 발명 없음
TTL 경합 엣지 (4분 59초 승인, 5분 30초 웹훅)	운영 규칙 2개로 봉인: ① 반납은 역조회보다 나중 ② 승인 호출 전 선점 유효성 확인	그래도 남는 크래시 틈은 일일 대사 + 최후의 환불 경로가 커버
운영 부품 증가	만료 워커 기존 노쇼 워커 확장, 아웃박스는 RESERVATION_EVENT 테이블 승격	순수 신규는 웹훅 컨슈머·대사 배치 2개
이탈 지점 추가	결제창에 잔여 TTL 카운트다운 노출로 완주 유도	티켓팅 UX 표준

---

의견 수립

우리팀은 아래와 같은 이유로 인해 방안 2를 채택했습니다.

1. 콘서트/항공권 예매와 유사한 사용자 흐름 → 학습 비용 낮음
2. 슬롯 경쟁(동시 선택 충돌)을 결제 이전, 선택 시점에 바로 걸러냄
3. 환율 lock을 슬롯 홀드 시점에 명확히 표시 가능 ("이 환율로 O분 안에 결제 완료 시 확정")
4. 결제 실패/타임아웃 시 되돌릴 금전 거래가 없음 (환불 프로세스 불필요)
5. 결제 실패 시(카드 거절·잔액 부족) 재 시도 가능

---

의견 요청

궁금한 점은 다음과 같습니다.

1. 선점 후 TTL 내 결제라는 분리 구조가 실무(커머스·티켓팅·여행 예약)의 표준적인 접근 방법이 맞는지 궁금합니다.
2. 유령 선점에 대한 완화책(인증 유저 한정, 동시 PENDING 1건, 5분 TTL)이 실무 관점에서 충분한지, 부족하다면 어떤 장치를 더 두는지 궁금합니다.
3. 역조회 워커의 주기, 일일 대사의 빈도·범위 등 정합성 안전망을 실무에서는 어느 수준까지 갖추는지 궁금합니다.
4. "정합성을 보수적으로 지킨다"는 방향과 4주 MVP 구현 비용 사이에서, 저희가 과소평가하거나 놓치고 있는 트레이드오프가 있는지 궁금합니다.