외부 시스템(PG)과 연동할 때는 "성공/실패" 두 가지만 있는 게 아니라, "모르는상태(PENDING)"가 가장 다루기 어렵다는걸 체감했다.
타임아웃이 터지거나 서킷브레이커가 열리면 PG에서 실제로 결제가 됐는지 안 됐는지 알 수 없는데, 이때 섣불리 성공이나 실패로 처리하면 중복결제나 누락이 발생한다.
서킷브레이커는 예외(실패)만 카운트하면 부족하다는 것을 배웠다. Slow Call 감지를 별도로 설정해야 느린 응답도 장애로 인식할 수 있다.
이런 고민이 있었어요
PG 요청이 타임아웃으로 실패했는데, PG 쪽에서는 결제가 완료된 경우를 어떻게 처리할지 고민이 있었다.
즉시 getPaymetByOrderId() 로 PG 상태를 조회해서 복구를 시도하고, 그것도 실패하면 콜백을 기다리고, 콜백도 안 오면 스케줄러가 5분 주기로 PENDING 건을 일괄 동기화하는 3단계 복구 구조로 풀었다. 한 단계만으로는 커버할 수 없는 케이스가 반드시 존재하기 때문에 여러 겹의 안전망이 필요하다는 걸 느꼈다.
앞으로 실무에 써먹을 수 있을 것 같은 포인트
장애 대응 전략을 선택할때 "어디까지 막을 것인가" 보다 "어디까지 허용할 것인가" 를 먼저 판단해야 한다는 관점을 얻었다.
예를 들어 콜백 누락에 대비해 즉시 복구, 콜백 대기, 스케줄러 동기화 라는 3단계 안전망을 만들었는데, 각 단계를 추가할수록 구현 복잡도와 운영 비용이 올라간다. 모든 장애를 막으려 하면 시스템이 과하게 복잡해지고, 너무 적게 막으면 장애가 사용자에게 그대로 노출된다. 결국 "이 서비스에서 PENDING이 10분간 유지 되는건 허용 가능한가?"처럼 비즈니스 임팩트 기준으로 대응 수준을 결정하는 것이 핵심이라는 걸 느꼈다.
아쉬웠던 점 & 다음에 해보고 싶은 것
PENDING 자동 복구 스케줄러가 단일 인스턴스 기준으로 설계되어 있다. 다중 인스턴스 환경에서는 같은 PENDING 건을 여러 인스턴스가 동시에 동시에 PG에 조회하는 중복 호출이 발생할 수 있다. processPaymentResult() 가 멱등하므로 최종 상태는 정합하지만, PG API를 불필요하게 여러번 호출하는건 낭비여서 분산 락을 도입해서 스케줄러 실행을 한 인스턴스로 제한하는 걸 다음에 구현해보고싶다.
PG 조회에서 NOT_FOUND가 계속 반환되는 건(PG에도 기록이 없는 PENDING)의 최종 처리 정책은 아직 정하지 못했다. 지금은 그냥 PENDING으로 남아있는데, N회 이상 조회 실패 시 자동으로 FAILED 전환하고 알림을 보내는 정책을 만들어서 운영자가 일일히 찾아볼 필요가 없는 구조로 개선해보고 싶다.
