개발 slecs

인터넷 은행 수동수령 건에 송금 상태와 파트너 푸시 알림 추가

목차

배경

  • 일부 인터넷 은행 계좌로 보낸 송금 건이 자동 수령이 안 되는 케이스가 누적됨
  • 파트너가 앱에서 직접 받기 버튼을 눌러야 처리되는데, 시스템이 그 상태를 따로 인식 못 하고 있었음
  • 입금 큐는 줄곧 SUCCESS/FAIL 이분법이라 "수동 개입 필요"가 끼어들 자리가 없었음

무엇을 고쳤는가

단계 이전 이후
송금 시도 결과 SUCCESS / FAIL 2종 SUCCESS / FAIL / MANUAL_REQUIRED 3종
큐 적재 실패만 따로 분리 수동수령 건도 별도 상태로 적재
푸시 알림 실패 시 운영팀에만 파트너 단말로 "직접 받아주세요" 발송
디바이스 토큰 조회 사용자 단위 일괄 활성 디바이스 dedupe 후 발송

코드 흐름은 대충 이런 모양으로 정리됨.

송금 응답 → 결제대행사 코드 매핑
  ├─ 정상 입금: SUCCESS
  ├─ 일부 인터넷 은행 + 수동수령 필요: MANUAL_REQUIRED → 큐 적재 + 푸시
  └─ 그 외 오류: FAIL → 재시도 큐

삽질 포인트

  • 처음엔 그냥 FAIL로 떨궈서 운영팀이 수기로 보정하게 하려고 함. 근데 운영팀 입장에서 "이게 자동 실패인지 수동수령 대기인지" 구분이 안 돼서 매번 묻고 있었음. 상태 하나 더 두는 게 결국 더 쌈
  • 푸시 보낼 때 토큰을 사용자 단위로만 묶어 보냈더니 한 명이 폰 두 대 쓰면 두 번 받음. dedupe 한 줄 추가하니 CS 한 건 줄어듦
  • 큐 상태 enum 늘리는 거라 마이그레이션 영향 범위가 의외로 넓었음. 큐 컨슈머 쪽에서 "모르는 상태는 무시"로 막아둔 덕에 배포 순서는 좀 자유로웠던 게 운이 좋았던 듯

배운 점

  • "성공/실패" 이분법으로 모델을 잡으면 시간이 지날수록 회색지대가 새로 생김. 처음부터 "그 외" 자리를 한 칸 비워두는 게 낫겠다 싶었음
  • 알림 품질은 메시지 다듬는 것보다 보낼 사람을 줄이는 쿼리가 더 크게 결정함. 결제대행사 응답코드를 그대로 받아 쓰지 말고 자체 상태로 한 번 추상화한 게 이번에도 잘 먹힘
  • 운영팀이 "어떤 건지 모르겠다"고 말하는 순간이 보통 신규 상태 하나 추가할 시점임

다음

댓글 0

첫 댓글 달아줘.