입금 큐 성공 후 주문 매칭이 자동으로 안 되던 문제 해결

큐가 끝났는데 주문은 안 잡히던 문제

큐 처리 결과가 SUCCESS로 떨어지는데, 정작 주문 매칭은 자동으로 안 돌던 케이스를 잡음. 결제대행사에서 입금 통지가 온 뒤 큐가 멀쩡히 처리되고 SUCCESS 상태까지 도달했는데, 그 다음 단계인 "어떤 주문에 이 입금을 붙일지" 매칭이 별도 스케줄러나 수동 호출에 의존하던 구조였음.

증상

• 입금 통지는 정상 수신
• 큐 row 상태 SUCCESS
• 그런데 파트너 화면에는 "미매칭"으로 떠 있음
• 결국 운영팀이 수동으로 매칭 버튼을 누르고 있었음

고친 방향

큐 처리 유틸의 SUCCESS 분기 끝에 자동매칭 호출을 끼워 넣음. 다만 그냥 끼워 넣으면 트랜잭션 안에서 매칭까지 묶여버려 락 시간이 길어지는 문제가 있어서, 큐 상태 커밋이 끝난 뒤에 매칭이 돌도록 경계를 분리했음.

// 의사 코드
markQueueSuccess(queueId)   // 트랜잭션 A
publishMatchEvent(queueId)  // A 커밋 후 호출
matchOrder(queueId)         // 트랜잭션 B

매칭 로직 자체는 기존에 있던 걸 재사용하고 진입점만 자동화함. 매칭이 실패해도 큐 SUCCESS는 살아있어야 하니, 매칭 호출은 try/catch로 감싸 예외는 로깅만 하고 흘려보냄. 매칭 누락분은 기존 감시 잡이 다시 주워가도록 그대로 둠.

회고 포인트

• "큐가 끝났다"와 "비즈니스가 끝났다"는 다른 사건임. SUCCESS 마킹은 인프라 관점, 매칭은 도메인 관점. 둘을 같은 트랜잭션에 묶어두면 한쪽 실패가 반대편까지 깨먹음.
• 트랜잭션 경계를 SUCCESS 직후에 끊고, 후속 작업은 이벤트로 던지는 패턴이 안전했음. 동기 호출을 유지하더라도 예외 격리는 필수.
• 이런 누락은 보통 운영팀의 수동 패턴을 보면 드러남. "왜 매번 같은 버튼을 누르고 있지?"가 가장 확실한 신호였음. 코드만 보면 안 보이는 갭이라, 운영 행동 관찰을 정기적으로 해야 한다는 걸 다시 느낌.

남은 숙제

• 자동매칭 실패율 메트릭을 따로 빼서 알람 걸기
• 매칭 실패 케이스의 사유 코드 표준화 (현재는 메시지가 자유 텍스트)
• 큐 SUCCESS 후 후속 작업이 더 늘어날 가능성을 대비해, 단발 호출 대신 이벤트 디스패처로 정리하는 리팩터 검토

다음.