결제대행사 회원 동기화를 비동기 큐로 전환해 정산 누락 해소

발단

이커머스 결제대행사 연동 작업 중 회원 정보 동기화 스펙 추가 요청 받았음. 신규 가입 시 결제대행사 쪽에 우리 회원 식별값을 함께 넘겨야 환불·정산 매칭이 깔끔해진다는 운영팀 피드백 때문이었음. 기존엔 결제 시점에 임시로 끼워 넣고 있어서 매칭 누락이 가끔 터졌음.

무엇을 추가했는가

가입/수정 흐름에 정식 필드를 박고, 변경 이벤트를 외부로 흘려보내는 통로를 새로 깔았음.

• 회원 DTO에 결제대행사 매핑 ID 필드 추가
• 회원 정보 수정 시 변경 이벤트 발행 → 동기화 워커가 비동기 업데이트
• 동기화 실패용 재시도 큐 + 운영 대시보드에 미동기화 회원 노출

[회원 가입/수정] → [이벤트 발행] → [재시도 큐] → [결제대행사 API]
                                       ↑
                              [결제 직전 보장 호출]

삽질 포인트

처음엔 가입 트랜잭션 안에서 동기 호출로 짰음. 결제대행사 API가 일시적으로 느려질 때 가입 자체가 타임아웃 나는 사고 직전까지 갔음. 비동기 + 큐로 다시 갈아엎었더니, 이번엔 "가입 직후 결제하는 회원이 미동기화 상태" 케이스가 새로 터짐. 비동기는 공짜가 아니라 일관성 구멍이 어디 생기는지 반드시 다시 그려야 함.

결제 직전에 한 번 더 동기화 여부 체크하고, 안 됐으면 즉시 호출하는 fallback 한 줄 추가로 구멍을 막았음. 큐가 밀려도 결제 흐름은 자기 책임 하에 강제 동기화하는 구조.

배운 것

• 외부 결제대행사 호출은 절대 가입 동기 흐름에 묶지 말 것. 한 번 데이면 다음부턴 본능적으로 큐부터 그리게 됨
• 비동기로 뺐을 때 "그 사이에 일어나는 후속 액션" 을 시나리오별로 시뮬레이션해보는 게 결국 빠름. 큐 지연 + 즉시 결제는 거의 항상 발생함
• 운영팀 피드백 → 스펙 정리 → 사고 시뮬 → 설계 순서로 한 바퀴 더 돌리는 게 재작업 비용보다 쌈
• 동기화 결과를 운영팀이 직접 볼 수 있게 만들면 CS 문의가 절반으로 줆. 데이터는 결국 사람이 봐야 신뢰됨

다음