백엔드 개발자정용상입니다.

원장은 한 건인데, 왜 초과 차감이 가능한가?

주문 A의 차감과 취소가 모두 기록된 상태에서, 취소 멱등키만 만료되면 기존 코드는 같은 취소를 새 요청처럼 처리합니다. Redis에서 재고를 먼저 늘리고 RDB에 취소 이력을 넣으려다 UNIQUE 충돌을 확인하는 순서입니다. 문제는 이 두 작업 사이에 다른 주문이 들어올 수 있다는 점입니다.

UNIQUE는 취소 이력의 중복 INSERT를 막았습니다. 그러나 이미 성공한 다른 주문의 차감까지 취소하지는 않습니다. 최종 캐시와 원장 합이 일치하더라도, 둘 다 음수 재고로 수렴할 수 있으므로 성공 응답 수와 재고의 하한을 함께 검증해야 합니다.

같은 주문의 취소만 직렬화

1. 존재하는 원 차감 이력에 잠금

   해당 주문의 DEDUCT 원장 행을 SELECT FOR UPDATE로 조회합니다. 아직 없는 ROLLBACK 행을 잠그려 하지 않고, 같은 주문의 취소들이 공유하는 기존 행을 직렬화 지점으로 사용합니다.

2. 완료 여부와 요청 내용 확인

   잠금을 획득한 뒤 ROLLBACK 원장을 확인합니다. 이미 완료됐다면 주문·드롭·구매자·수량을 대조하고 Redis 재고를 다시 늘리지 않습니다.

3. 최초 취소만 복원·기록

   완료 이력이 없을 때만 Redis 복원과 원장 기록을 수행합니다. 같은 주문의 후속 취소는 잠금 해제 후 완료 원장을 다시 확인합니다. 다른 주문의 정상 차감은 이 원장 행을 잠그지 않고 기존 Lua 경로로 진행합니다.

TTL 연장의 한계

유한한 멱등키 보존 시간을 늘려도, 만료 뒤 재시도의 완료 여부는 영구 원장으로 확인해야 합니다.

사전 조회만으로 부족한 이유

최초 취소 둘이 모두 미완료 원장을 읽고, 처리 도중 Redis 멱등키까지 유실되면 두 요청이 복원할 수 있습니다. 사전 조회와 실행 사이를 같은 주문의 DB 잠금으로 연결합니다.

트랜잭션 경계

rollback의 외부 트랜잭션이 DEDUCT 행 잠금을 유지하고, StockHistoryRecorder는 REQUIRES_NEW로 취소 이력을 독립 커밋합니다. 기록 충돌이 외부 트랜잭션에 rollback-only를 전파하지 않도록 분리한 구조입니다.

감수한 비용

같은 주문의 취소는 대기하고, 독립 원장 기록에는 추가 DB 연결이 필요합니다. 커넥션 풀과 대기 시간을 고려해야 하지만, 같은 드롭의 모든 구매를 하나의 재고 행에 줄 세우지는 않습니다.

PostgreSQL·Redis 전후 경합 검증

2026.09 추가 검증에서 기존 롤백 순서와 후속 보강 코드를 같은 기반에 놓고 비교했습니다. 기존 방식은 Redis 재복원 직후, 개선 방식은 완료 원장 확인 뒤에 취소 재시도를 잠시 멈췄습니다. 그 사이 다른 주문 두 건의 차감과 실제 원장 커밋을 먼저 끝낸 뒤 재시도를 재개했습니다.

환경·방법

PostgreSQL 16.14 · Redis 7.4.9 · Java 21.0.11. 실제 Spring 서비스·트랜잭션 프록시와 테스트 컨테이너를 사용하며, spy는 실행 순서와 호출 횟수만 제어합니다.

만료 조건

합성 주문의 취소 키를 30ms TTL로 만들고 50ms 후 부재를 확인합니다. 서비스의 1시간 설정은 바꾸지 않고, 만료 뒤 상태를 빠르게 재현했습니다.

추가 경합

완료 취소와 신규 차감 8건의 경합, 최초 취소 두 건 사이의 멱등키 유실·교차 차감을 검증했습니다. 같은 주문의 후속 취소는 잠금을 기다리고, 다른 주문의 차감은 진행되는지 함께 확인했습니다.

검증 범위

상품 서비스의 재고 차감 승인과 원장 커밋까지의 결과입니다. 주문·결제 전체 완료 수나 운영 TPS를 측정한 결과는 아닙니다.

남은 실패 경계

이번 보강은 완료 취소의 재실행과 동일 주문의 중복 취소 경쟁을 다룹니다. 최초 복원 뒤 DB·프로세스 장애나 진행 중 재워밍까지 원자적으로 처리하는 분산 트랜잭션은 아닙니다.

구현·검증 근거

세미에서 만든 상품 도메인의 후속 보강(2026.08)입니다. 기존 세미 기간과 구분하고, 아래 커밋의 서비스·잠금·실제 DB/Redis 테스트를 기준으로 검증했습니다. 비교용 기존 방식은 같은 코드 기반에서 롤백 경로만 c979876의 순서로 복원했습니다.

완료된 조회 결과가 사라진 위치

주문 통계와 회원 현황은 서로 독립적인 조회입니다. 기존 구현도 두 조회를 병렬로 실행했지만, Future를 기다리는 루프 바깥에서 시간 초과를 처리했습니다. 첫 조회가 지연되면 공통 catch가 전체 수집을 끝내므로, 뒤쪽 Future가 이미 정상 완료됐어도 그 값은 반환되지 않았습니다.

입력 순서대로 결과를 수집하는 것 자체가 문제는 아닙니다. 개선본도 원래 식별자와 순서를 유지합니다. 바꾼 것은 조회 하나의 시간 초과를 요청 전체 실패로 해석하던 경계와, 결과마다 새로 부여하던 대기 시간입니다.

공통 시간 제한 안에서 항목별 상태 수집

1. 조회 묶음의 시간 예산을 한 번 계산

   단계 제한과 전체 요청의 남은 시간 중 작은 값을 사용합니다. invokeAll에 이 시간을 적용하므로 여러 미완료 Future에 각각 새 대기 시간을 부여하지 않습니다.

2. 완료와 실패를 같은 목록에 보존

   완료된 작업은 원래 결과를 사용하고, 취소·실패한 작업은 같은 binding ID의 FAILED 항목으로 바꿉니다. 실패 facts는 null과 사유를 남겨, 확인하지 못한 주문 수가 정상적인 0건으로 바뀌지 않게 합니다.

3. 최종 추론까지 정보의 의미 유지

   정상 facts의 값·범위·관측 시각과 실패 항목을 EvidenceSegment로 함께 전달합니다. 모델이 어떤 정보를 확인했고 무엇을 확인하지 못했는지 구분할 수 있도록 실행 계층이 근거를 소유합니다.

단계 시간 초과

전체 요청에 시간이 남아 있다면 미완료 조회를 FAILED로 기록하고 정상 형제 결과는 보존합니다. 빠른 결과를 즉시 스트리밍하는 방식은 아니며, 같은 조회 묶음의 수집이 끝난 뒤 전달합니다.

전체 요청 기한

요청의 잔여 시간이 먼저 끝났다면 TIMEOUT으로 종료합니다. 정상 근거가 일부 있다는 이유로 기한을 연장하거나 정상 완료로 바꾸지 않습니다.

사용자 취소·포화

중단은 CANCELLED, 실행기 포화는 BUSY로 구분합니다. 실행되지 않은 요청에 정상 결과나 부분 성공을 만들어 붙이지 않습니다.

취소의 실제 범위

미완료 Future에 취소 신호를 전달하고 협조적인 작업의 interrupt 수신을 확인했습니다. 이것만으로 모든 HTTP·JDBC 작업이 즉시 물리적으로 중단된다고 보장할 수는 없으며, 외부 I/O의 timeout도 별도로 필요합니다.

완료 여부·값·상태를 함께 검증

2026.09 추가 재현에서는 실제 Java executor와 PlanFactory·ResultMapper·실행 어댑터를 사용했습니다. 데이터 포트에 합성 회원 현황과 주문 조회 지연을 주입하고, 정상 회원 현황이 먼저 완료됐다는 기록을 확인한 뒤 수집 결과를 비교했습니다.

요청 마감·호출자 중단·실행기 포화도 별도 조건으로 실행해 TIMEOUT·CANCELLED·BUSY를 확인했습니다. 단순히 예외가 없어졌는지가 아니라, 정상 빈 결과와 부분 결과·실패의 의미가 섞이지 않는지도 검사했습니다.

실제 Spring AI 클라이언트에서 최종 요청까지 확인

로컬 OpenAI 호환 HTTP 응답 서버를 연결해 routing → binding → 실제 실행 어댑터 → orchestrator → 최종 답변 요청을 통과시켰습니다. 느린 주문 조회와 잘못된 dataset 항목은 실패로 남기고, 정상 회원 현황은 최종 요청의 verified-evidence JSON까지 전달되는지 대조했습니다.

실행 결과

FAILED · FAILED · SUCCESS. 정상 회원 42명, MEMBERSHIP/MEMBER_CURRENT, 관측 시각 2026-07-31T12:15:00+09:00를 포함한 모든 근거 필드의 일치 확인.

HTTP·종료

routing 1회 · binding 1회 · answer 1회. 단일 done 이벤트 확인. 이 통합 검증의 단계 제한은 3초로, 위 500ms 전후 비교와 구분합니다.

검증 범위

모델 응답과 조회 데이터는 통제된 fixture입니다. 실제 HTTP 클라이언트·파서·실행 계층·근거 전달 계약을 확인한 것이며, 실제 모델의 최종 답변 정확도나 DB 성능을 측정한 결과는 아닙니다.