은행별 입금 감시 오류 분류와 멱등성으로 이중 처리 방지

입금 감시 로직, 은행마다 다르게 터지는 게 문제였음

여러 은행 핸들러에서 입금 완료 감시 로직이 들쭉날쭉이라 정리한 회고. 같은 "입금 확인"인데 은행별로 응답 포맷, 타임아웃 패턴, 에러코드가 다 달라서 분기마다 한 번씩 장애가 났음.

기존 구조는 각 은행 핸들러가 자기 방식대로 예외를 던지고, 상위 스케줄러는 그걸 단순히 catch만 하고 있었음. 결과적으로 이런 문제가 누적됨.

폴링 주기는 짧은데 멱등성 보장이 약해서, 같은 입금 건이 두 번 처리되는 사고도 한 번 있었음.

네 개 핸들러를 모두 손대면서 가장 먼저 한 건 에러를 세 가지로 명확히 분류한 것.

응답수신 → 파싱 → 카테고리 판정
   ├─ RETRYABLE → 백오프 큐
   ├─ PENDING   → 다음 틱
   └─ FATAL     → 알림 + 상태확정

은행별로 같은 문구가 다른 의미로 쓰이는 게 까다로웠음. 어떤 은행은 "처리중"이 PENDING이고, 다른 은행은 사실상 RETRYABLE에 가까웠음. 핸들러 안에 매핑 테이블을 두고 외부에는 통일된 enum만 노출.

같은 거래 두 번 처리되는 사고를 막기 위해 입금 감시 단계에서도 멱등키를 강제. 거래 식별자 + 은행코드 + 사이클 시각을 조합해 키를 만들고, 처리 직전에 캐시로 락을 걸었음. 락 TTL은 폴링 주기의 두 배로 잡아서 사이클이 겹쳐도 안전하게.

추적 ID는 핸들러 진입 시점에 발급해서 로그·알림·후속 정산 레코드에 모두 심었음. 장애 났을 때 ID 하나로 전 구간을 따라갈 수 있어야 새벽에 깨도 사람이 살 수 있음.

운영팀이 거래 조회할 때 화면마다 달력 위젯 동작이 미묘하게 달라서, 어제/오늘/이번주 같은 기본 프리셋과 시작-종료일 검증을 하나의 JSP 조각으로 통일. 화면별로 복붙됐던 자바스크립트 다섯 군데가 한 곳으로 모임.