원화 입금 미처리 건을 전수조사하면서 krw_deposits 에 FAILED 표시가 있는 것을 다 뽑아 하나씩 처리했다. 나중에 다른 것을 보다가 실패 표시가 없는데도 끝나지 않은 건을 발견했다.
Table of contents
Open Table of contents
증상 — 완료인데 결과가 없는 건
status 는 COMPLETED 인데 ledger_entry_id 가 비어 있고 마지막 로그에 반대 거래 데이터가 필요하다고 적혀 있었다. DepositService 를 보니 승인 취소 중에 특정 조건을 만나면 나중에 상쇄될 것이라는 전제로 완료 처리하고 있었다.
그 전제가 성립하려면 은행에서 반대 거래가 오고 그 뒤에 다시 처리돼야 한다. COMPLETED 라는 표시는 처리가 끝났다는 뜻이 아니라 지금 더 할 것이 없다는 뜻이었다.
원인 — 오지 않은 나중
전제의 뒷부분을 담당하는 코드를 찾아보니 reversal_id 를 다시 조회하는 @Scheduled 배치가 없었다. 데이터가 와도 아무도 다시 보지 않고 안 오면 더 말할 것도 없었다.
그러면 그 건은 영구 대기 상태로 남는데 겉으로 붙은 상태값은 COMPLETED 다. 나중에 상쇄된다는 전제는 그 나중을 처리하는 코드가 있어야 성립한다.
검증 — 실패만 훑는 조사의 사각
내 조사 조건은 status = 'FAILED' 였고 이 건들에는 그 표시가 없었다. 상태가 COMPLETED 이므로 정상으로 분류되어 목록에 아예 오르지 않았다.
조건을 그렇게 짠 근거는 실패는 문제이고 완료는 안전하다는 가정이었다. 그 가정이 안 맞는 부류가 있으면 조사 자체가 그 부류를 구조적으로 못 본다.
판단 기준 — 상태가 아니라 결과물로 판정한다
두 가지 방법이 있었다. 조사 조건에 FAILED 말고 의심스러운 상태값을 더 나열하는 것과, 상태값 대신 ledger_entry_id IS NULL AND reversal_id IS NULL 처럼 결과물의 부재로 잡는 것이다. 뒤쪽을 골랐다. 이유는 상태값을 나열하면 이번에 모르는 부류가 또 빠져서다. 대신 조회가 ledger_entries 조인으로 무거워지는 것을 감수했다. 돌려 보니 여러 건이 나왔고 완료 시각이 전부 시스템 이관 전 시기에 몰려 있었다.
상태값은 그 시점의 판단이고 그 판단이 어떤 전제에 기대고 있을 수 있다. 판단의 근거가 사라져도 상태값은 그대로 남으므로 결과물의 존재로 확인하는 편이 확실하다.
기술 판단과 도메인 판단
이 건들을 어떻게 종결할지는 강제 종결과 별도 상태 이관과 그대로 두기 중에서 갈렸다. 회계 처리와 얽히고 이미 지난 회계 기간의 것이라 내가 정할 문제가 아니었다.
목록과 상황을 정리해 재무 담당에게 넘기고 기술 판단과 도메인 판단을 구분했다. 이 패턴이 한 은행 계좌만의 것인지 전체 공통인지는 확인하지 못했으므로 미확인으로 적어 두고 남겼다.
정리
- 상태가
COMPLETED여도ledger_entry_id가 없을 수 있다 - 완료가 처리 끝이 아니라 지금 더 할 것 없음을 뜻할 수 있다
- 나중에 상쇄된다는 전제는 그 나중을 처리하는 코드가 있어야 한다
FAILED만 훑는 조사는 완료로 위장된 미완결을 구조적으로 못 본다- 조사 조건에 깔린 가정을 먼저 적어 본다
- 판정은 상태값이 아니라 결과물의 존재로 한다
- 판단의 근거가 사라져도 상태값은 그대로 남는다
- 종결 방법이 도메인 판단이면 넘기고 미확인 범위는 적어 둔다