# P2P 시간 모델 (확정) 작성 2026-08-20 · 오너 판정 반영 이 문서가 P2P 구매 흐름의 **시간 규칙 정본**이다. 개별 상수·설정은 여기에 맞춘다. > **② 매칭 대기 구간의 상세 룰은 `P2P_MATCH_WAIT_RULES.md` 가 정본이다** (2026-09-02). > 이 문서는 ①~⑤ 전체 골격을 유지하고, ② 의 발동 조건·게이트·예외는 그쪽에서 다룬다. --- ## 원칙 — 구간마다 자기 시계, 전체 총량은 없다 ``` ① 링크 유효 링크 생성 → 사용(주문 생성) ② 매칭 구간 주문 생성 → 매칭 성립 ③ 이체 구간 매칭 성립 → 구매자 "입금확인" 클릭 ④ 확인 구간 입금확인 → 입금 확인 완료 ⑤ 분쟁 구간 분쟁 제기 → 판정 ``` 한 구간이 끝나면 그 시계는 관여하지 않는다. 앞 구간이 길어져도 뒤 구간이 깎이지 않는다. ## 확정 값 | 구간 | 마감 | 초과 시 | 비고 | |---|---|---|---| | ① 매칭 링크 | **60분** | 링크 EXPIRED | 사용되면 관여 끝 | | ① P2P 입금 링크 | **30분** | 링크 EXPIRED | 사용되면 관여 끝 | | ② 매칭 대기 | **없음(기본) / 5·10·15·20·25분** | LP(TORQ) 레그로 전환 | 링크·위젯 옵션 | | ③ 이체 | **15분** | **매칭 취소** | ← 30분에서 변경 | | ④ 입금 확인 | **10분** | **분쟁 진입** | ← 무기한에서 변경. 자동확인·수동 **양쪽 적용** | | ⑤ 분쟁 | 없음 | — | 관리자 판정. 자동 종결 없음 | --- ## 구간 경계 — ③과 ④를 가르는 것은 상태다 ``` CREATED 구매자가 아직 "입금확인"을 누르지 않음 → ③이 지배 (15분) BANK_PENDING 눌렀음, 확인 대기 → ④가 지배 (10분) ``` ### ⚠️ ③의 만료 대상은 `CREATED` 뿐이다 지금 `P2pMatchExpiryJob` 은 `CREATED` 와 `BANK_PENDING` 을 **함께** 수거하고, 그중 실효 수동만 예외로 뺀다. 이 구조를 그대로 두면 두 시계가 충돌한다. ``` t=0 매칭 성립 ③ 시작 (마감 t=15) t=14 구매자 "입금확인" → BANK_PENDING ④ 시작 (마감 t=24) t=15 ③ 만료 — 자동확인 회원이면 BANK_PENDING 이 FAILED 된다 ④가 아직 9분 남았는데 죽는다 ← 잘못된 동작 ``` **입금확인을 누르는 순간 ③은 끝난다.** `expires_at` 은 `CREATED` 에만 적용하고, `BANK_PENDING` 은 ④의 시계로만 판정한다. 지금 "실효 수동 BANK_PENDING 자동 FAIL 제외" 예외는 이 규칙의 **부분 구현**이었다 — 자동확인 회원에게도 같은 보호가 필요하다. --- ## 현재 → 확정 대조 ``` ③ 이체 30분 → 15분 지금은 명목값이었다. BANK_PENDING 실효 수동이 예외로 빠져 30분을 넘긴 P2P 레그 3건이 그대로 정산됐다 앞으로는 CREATED 에만 적용 = 실질 마감이 된다 ④ 입금 확인 무기한 → 10분 → 분쟁 지금은 10분에 회원 리마인더, 30분에 관리자 에스컬레이션 — 둘 다 알림만 하고 상태를 바꾸지 않는다 앞으로는 10분에 분쟁으로 상태 전이 30분 에스컬레이션은 분쟁 감시(⑤)가 흡수한다 ``` ## 실측 근거 (2026-08-20) ``` P2P 레그 SETTLED 39건 소요 분포 ≤5분 31 (79%) · ≤10분 2 · ≤20분 1 · ≤30분 2 · >30분 3 (8%) 구간 평균 ③ 1.0분 · 매칭→입금확인 3.9분 · 확인→정산 1.9분(최대 29.2) TORQ 레그 657건 평균 2.2분 — ③ 15분도 과분하다 수동 확인 8건 소요 0.2~0.6분 10분 리마인더·30분 에스컬레이션 발동 이력 0건 → 10분 분쟁 진입은 현 실적 기준 거의 발동하지 않는다 주문당 레그 수 1개 1,452 (98%) · 2개 22 · 3개 5 · 5개 1 · 7개 1 P2P 다중 레그 주문은 7건뿐 ``` **③ 15분은 실측을 충분히 덮는다** (79%가 5분 내). 30분을 넘겨 살아남던 8%는 이제 취소된다 — 의도한 변화다. --- ## 코드 영향 ### ⚠️ ③의 만료 주체는 잡이 **둘**이다 (2026-08-20 구현 중 발견) `P2pMatchExpiryJob` 만 고치면 아무것도 달라지지 않는다. `P2pDepositLinkExpiryJob` 이 **같은 `expires_at` 을 같은 30초 주기로** 보고 BANK_PENDING leg 를 `failExpiredMatch` 한다. 레그 `expires_at` 은 주문 것을 상속하므로 두 잡의 마감이 동일 시각이다. **두 잡 모두 `CREATED` 만 만료시켜야 한다.** ``` ③ P2pDepositService.EXPIRY_MINUTES 30 → 15 expires_at = (match_wait_until ?? now) + 15분 레그는 주문 expires_at 을 상속하므로 자동 반영 P2pMatchExpiryJob 수거 대상에서 BANK_PENDING 제외 ⚠️ 지금의 "실효 수동만 예외" 는 부분 구현 — 전체로 넓힌다 ⚠️ BANK_PENDING 최종 스크래핑 1회(N1 가드)는 ④로 옮길지 판단 필요 ④ 자동확인 회원과 실효 수동 회원 **모두** 10분 → 분쟁 (2026-08-20 확정) 기존 autoDisputeMatch 를 재사용한다 (입금자명 불일치 자동 분쟁이 이미 쓰는 경로) 자동확인 회원 P2pScrapingVerifyJob (5초) 조회 성공 + 입금 미발견 + 10분 경과 → 분쟁 실효 수동 회원 P2pManualConfirmReminderJob (60초) 10분 경과 → 분쟁 (지금은 알림만 — 상태 전이로 바꾼다) escalate-minutes(30분)은 폐기 — ⑤ 감시가 흡수 ``` ### ⚠️ ④의 필수 가드 — 스크래핑이 죽었을 때 분쟁을 만들지 마라 자동확인 회원에게 ④를 적용하면 **CODEF 장애 시 진행 중인 전건이 분쟁으로 쏟아진다.** 과거 CODEF 도메인 오류(`UnknownHostException`) 전력이 있다. `P2pScrapingVerifyJob` 은 이미 결과를 `CONFIRMED / DISPUTED / SKIPPED / **ERROR**` 로 구분한다. **분쟁은 "조회에 성공했는데 입금이 없다"일 때만** 만든다. ``` 조회 성공 + 미발견 + 10분 경과 → 분쟁 ← 진짜 미입금 조회 실패(ERROR) → 아무것도 안 함 ← 우리 문제다. 다음 사이클 ``` 판정을 스크래핑 잡 **안**에 두면 그 사이클의 결과를 그대로 쓸 수 있어 별도 컬럼이나 전역 서킷브레이커가 필요 없다. ## 미결 — UI/UX 이후로 미룸 **매칭별 개별 타이머**. 지금 ③의 15분은 **주문 전체 기준**이고 모든 레그가 같은 마감을 쓴다. 검토 중인 안은 "거래 1건당 5분 + 이체 확인 10분"으로 **카드마다 독립 시계**를 두는 것. ``` 현재 구조 위젯이 레그를 리스트로 나열, 마감 하나 검토 안 카드별 5분 — 순차라면 7레그 = 35분, 병렬이라면 5분 실측 레그 1개가 98% — 지금은 두 안의 차이가 거의 없다 ``` **UI/UX 개편이 선행**이다. 카드별 타이머는 화면 구조가 정해진 뒤에 판단한다. --- ## 미해결로 남는 것 ``` ⑤ 분쟁에 마감이 없다 자동 판정을 두지 않는 것은 의도된 설계(자금이 걸려 있다)지만, ④가 10분에 분쟁을 자동 생성하기 시작하면 ⑤의 무기한이 더 아파진다 → 분쟁 유입량을 보고 관리자 대기열 정책을 다시 볼 것 ```