데이터 정산 시스템 상태값 설계 기준: 예외 및 트랜잭션 대응

정산 시스템 핵심 상태값 정의 및 멀티 결제 연동 매핑 기준

정산 상태값을 설계할 때 가장 흔히 저지르는 실수는 PG사 콜백의 응답 코드를 그대로 내부 DB에 밀어 넣는 것이다. 신용카드 결제는 승인, 가상계좌는 입금대기, 카카오페이는 성공 — 표현이 제각각이면 운영자가 실시간 대시보드에서 "이 등록자 결제가 끝났는가?"를 한눈에 판단하지 못한다. 상태값은 단순한 라벨이 아니라 다음 액션을 결정하는 분기점이어야 한다.

핵심 상태 4종과 각 상태가 품은 운영 의미

정산 시스템의 뼈대는 네 가지 상태로 수렴한다.

부분 취소·환불·중복 요청 등 예외 상황을 처리하는 세부 상태 설계

결제 상태를 대기, 완료, 취소, 실패 네 가지만 두는 것은 실무에서 정산이 꼬이는 가장 흔한 원인입니다. 특히 멀티 공급사와 채널 매니저, PMS가 얽히는 여행·호텔 예약 커머스나, 신용카드와 계좌이체, 가상계좌 등 다양한 결제 수단이 현장에서 몰리는 오프라인 행사(MICE)에서는 더욱 그렇습니다. 단순 상태값은 결제가 성공했는지 여부만 알려줄 뿐, 그 이후에 벌어지는 복잡한 변수를 통제하지 못합니다.

가장 흔하게 발생하는 정산 오류는 결제 완료 이후의 처리 지연입니다. 예를 들어 가상계좌로 입금하거나 부분 취소가 발생했을 때, 시스템이 이 과정을 단순히 완료나 취소로 덮어버리면 정산 데이터에 즉시 구멍이 생깁니다. 따라서 현재 진행 중인 프로세스와 최종 결과값을 명확히 분리하는 세부 상태 설계가 필수적입니다.

대용량 배치 정산 실패 방지와 안전한 재처리(Reprocessing) 로직 흐름

행사 종료 직후, 정산 시스템이 가장 많이 흔들리는 순간은 수천 건의 결제·출결·평점 데이터가 한 번에 배치 처리될 때다. 이때 DB 락이나 타임아웃이 발생하면 결제는 승인됐는데 출결 기록은 누락된 참가자가 생긴다. e-Regi가 QR 스캔 3초 이내로 입장을 처리하며 중복 스캔을 방지하고 입·퇴장 시간을 자동 기록하는데, 이 데이터가 정산 배치에서 빠지면 보수교육 평점 인증에 직결된다.

재처리가 안전해지는 상태값 설계 기준

배치 실패 후 "처음부터 다시" 돌리면 이미 처리된 결제가 중복 반영될 수 있다. 멱등성을 보장하려면 다음 기준이 필요하다.

| 중복 방지 | INSERT 후 중복 여부를 나중에 확인 | 결제키 + 참가자ID 복합 유니크 키로 사

상태값 변경 이력(Audit Log) 추적과 관리자 모니터링 대시보드 구축

행사 현장에서 "결제는 완료됐다는데 QR 찍으니까 입장이 안 된다"는 참가자의 항의를 받으면, 사무국은 즉시 원인을 찾아 조치해야 합니다. 이때 정산 상태값이 어디서, 왜 꼬였는지 추적할 수 없다면 현장은 순식간에 혼란에 빠집니다.

이런 상황을 방어하려면 상태값이 변할 때마다 누가, 언제, 어떤 이유로 데이터를 바꿨는지 기록하는 감사 로그(Audit Log) 설계가 기본 전제가 되어야 합니다.

현장 개입을 위한 실시간 모니터링과 감사 로그

행사 중 결제 데이터와 QR 출결 데이터가 어긋나는 오류가 발생했을 때, 관리자는 화면을 통해 실시간 현황을 보고 즉각 개입해야 합니다. 단순히 로그를 쌓는 것을 넘어, 운영 대시보드와 연동되어야 실질적인 통제가 가능해집니다.

• 상태 변경 추적: 신용카드, 가상계좌, 간편결제 등 다양한 결제 수단 연동 시 자동으로 변경되는 상태값과, 관리자가 수동으로 처리한 이력을 구분하여 명확히 남깁니다.
• 실시간 대시보드 연동: 사무국 화면에서 참가 현황, 세션별 출결률, 결제 통계를 라이브로 모니터링하여 오류 건을 즉시 포착합니다.

| 항목 | 흔한 실수 | 권장 관리 기준