결제 입금 알림이 엉뚱한 채팅방으로 가던 오배송 문제 수정

채팅방 매칭이 어긋나던 문제

파트너가 결제대행사로부터 입금 알림을 받아 메신저 채팅방으로 푸시하는 흐름이 있었음. 그런데 같은 파트너가 여러 거래 은행을 동시에 쓰는 케이스가 늘면서, 알림이 엉뚱한 방으로 들어가는 사고가 잦아짐.

원인은 단순했음. 채팅방을 찾을 때 쓰던 키가 너무 헐거웠음.

• 파트너 식별자 하나만 매칭 키로 사용
• 같은 파트너가 A은행/B은행 채팅방을 둘 다 운영하면 먼저 잡힌 방으로 발사
• 운영자가 수동 분기를 만들어 두지 않으면 알림이 섞임

키를 늘리는 방향으로 정리

해법은 키 차원을 늘리는 것이었음. 알림 페이로드에 들어 있는 요청 은행 코드까지 매칭 조건에 포함시켜서, "파트너 + 은행" 조합으로만 채팅방을 찾도록 바꿈.

# 변경 전
room = findRoom(partnerId)

# 변경 후
room = findRoom(partnerId, bankCode)
   ?: fallbackRoom(partnerId)   # 은행 미지정 알림은 기본 방으로

폴백을 살려둔 이유는 과거 데이터 호환임. 은행 코드 없이 등록한 채팅방이 일부 남아 있어서, 새 키로 못 찾으면 예전 방식으로 한 번 더 조회하게 함. 이행 기간 끝나면 제거할 예정임.

수정 후 매칭 정확도

매칭 실패를 명시적으로 떨어뜨린 것도 의도였음. 이전에는 잘못 들어가도 운영자가 알림 자체는 받으니까 문제를 못 봤는데, 이제 안 맞으면 안 들어감. 대신 실패 로그를 남겨서 신규 은행 등록 누락을 빠르게 잡을 수 있게 함.

WARN [chat-match] no room matched
   partnerId=*** bankCode=088
   hint=파트너 채팅방에 신규 은행 등록 필요

운영팀이 이 로그만 보고도 어떤 채팅방이 비어 있는지 한 눈에 잡을 수 있게 메시지 포맷도 같이 정리함.

회고

작업하면서 다시 새긴 것 두 가지.

• 검색 키는 도메인이 커지는 방향으로 같이 커져야 함. "지금 충분"한 키는 곧 부족해짐
• 잘못된 매칭은 미매칭보다 훨씬 위험함. 차라리 못 찾고 시끄럽게 우는 쪽이 운영상 안전함

다음으로는 채팅방 매핑 자체를 운영자 화면에서 점검·수정할 수 있는 작은 도구를 붙일 차례임. 매칭 정책이 늘어날수록 코드보다 데이터로 푸는 비중이 커질 것 같음.

끝