메신저 송금봉투 자동수령 누락 버그 수정

파트너 정산 자동화를 만지던 중에 운영팀 슬랙이 왔다. 송금봉투가 며칠째 자동수령이 안 된다는 거였다. 알림은 분명 들어왔는데 수령 처리 없이 그대로 만료된다고. 한참 쌓아놨다가 알려줬다는 말에 건수를 세보니 적지 않았다. 미안해서 바로 파봤다.

외부 메신저 송금 연동을 처음 붙일 때부터 알고 있던 리스크가 있다. 메시지 포맷이 언제든 바뀔 수 있다는 것. 메신저 앱 쪽에서 디자인 업데이트나 기능 추가를 하면 알림 본문 포맷이 슬쩍 달라지는데, 파싱하는 쪽은 변경 전 포맷에 맞춰진 채 남아있게 된다. 이번 건은 그 고전적인 케이스였고, 거기에 더해 모니터링에서도 안 잡히는 조합이었다.

원인: 파서가 봉투 포맷을 처음부터 몰랐다

기존 파서는 일반 송금 알림 하나만 매칭하고 있었다. "○○님이 ₩30,000을 보냈습니다" 패턴. 처음 연동 당시엔 이게 전부였으니까 틀린 건 아니었다. 문제는 그 이후 송금봉투라는 기능이 생기면서 메시지 본문 패턴이 추가됐는데, 파서는 그걸 반영 안 한 채 방치됐다는 거다. 누락이 아니라 미구현이었다.

분류해보면 이렇다.

더치페이는 원래 자동수령 대상이 아니라서 제외가 맞는데, 봉투는 처음부터 케이스 자체를 안 넣은 거였다. 알림 수집기 단에서 패턴 미일치 → 그냥 드롭하고 있었고, 드롭된 알림은 아무런 에러 없이 조용히 만료됐다.

이게 운영팀이 늦게 발견한 이유이기도 하다. 시스템은 에러 로그 하나 안 남겼다. 수집기 입장에선 "모르는 포맷이니 무시"가 정상 동작이었으니까. UNKNOWN을 드롭해도 아무 표시가 없으면 외부에서 볼 때는 알림이 안 온 것과 구분이 안 된다. 모니터링에서 안 잡히는 버그의 고전적인 형태다.

고친 부분과 정규식 순서 문제

파서에 봉투 패턴 두 개를 추가했고, 알림 수집기에서 봉투 종류일 때 자동수령 큐로 보내는 분기를 넣었다. 그 다음 자동수령 서비스에서 봉투 금액을 뽑는 로직도 보강했는데, 봉투 본문은 일반 송금보다 금액 표기 변형이 더 많았다.

# 들어오는 알림 예시
"용돈 봉투 50,000원이 도착했어요"
"○○님이 봉투를 보냈습니다 (₩120,000)"

# 파싱 결과
amount = 50000
kind   = ENVELOPE
→ enqueue auto-receive

천단위 콤마, 원/₩ 혼용, 조사 위치 차이까지 케이스가 생각보다 많았다. 정규식 하나로 전부 커버하려다가 욕심이 과했다. 결국 금액 추출 정규식을 여러 개 두고 일치하는 첫 번째 결과를 쓰는 방식으로 정리했다.

파싱 레이어 흐름으로 보면 이렇게 됐다.

[알림 수신]
  → 메시지 분류기 (kind 판단: TRANSFER / ENVELOPE / DUTCHPAY / UNKNOWN)
      → UNKNOWN이면 드롭 + 경고 로그  ← 이번에 추가
  → kind별 금액 추출기 호출
  → 자동수령 큐 enqueue (ENVELOPE / TRANSFER만)

수정하면서 한 번 사고를 쳤다. 봉투 매칭 패턴을 먼저 두니까 일반 송금 알림이 봉투로 잡혔고, 순서를 바꾸니 그 반대가 됐다. 결국 가장 구체적인 패턴을 먼저 매칭하는 원칙으로 정리했다. 문자열이 길고 조건이 많은 패턴 → 짧고 단순한 패턴 순서. 이 우선순위를 파일 상단 주석에 테이블로 박아뒀다. 다음에 패턴 추가할 사람이 순서 실수 안 내게.

정규식 여러 개를 관리할 때 흔히 놓치는 게 이 우선순위 문제다. 패턴이 두세 개일 때는 머릿속에서 관리가 되는데, 다섯 개 넘어가면 어떤 패턴이 어떤 입력을 먼저 먹는지 추적이 안 된다. 테이블로 정리해서 코드 옆에 붙여두는 게 나중 유지보수에서 훨씬 편하다.

단위 테스트 12개, 그리고 픽스처 얘기

수정하면서 단위 테스트 12개 추가했다. 기존 일반 송금 케이스가 안 깨지는지, 봉투 포맷 두 종류가 모두 잡히는지, 금액 표기 변형들이 커버되는지. 회귀 테스트를 짜면서 깨달은 게 있다.

파싱 로직 테스트는 입력을 실제 알림 원문으로 써야 한다. "보냈습니다" 같은 가상 문자열로 짜면 나중에 실제 알림 본문이 미묘하게 달라져도 테스트가 통과해버린다. 실제 수신된 알림 원문을 픽스처로 쓰는 게 낫다. 이번에 12개 중에 8개는 운영팀한테 받은 실제 실패 케이스 원문으로 채웠다. 덕분에 엣지 케이스 두어 개를 추가로 잡았다.

• "용돈 봉투 50,000원이 도착했어요" - 기본 케이스
• "○○님이 봉투를 보냈습니다 (₩120,000)" - ₩ + 괄호 표기
• "봉투 도착! 10000원" - 콤마 없는 금액

이런 식으로 실제 원문이 픽스처가 되니까 다음에 포맷이 또 바뀌었을 때 어떤 테스트가 깨지는지 바로 보인다.

경고 로그 추가 얘기도 해야겠다. UNKNOWN 분류가 나왔을 때 그냥 드롭하던 걸 이번에 경고 로그로 바꿨다. 다음에 메신저 쪽에서 또 포맷이 추가되면 모니터링에서 바로 잡힌다. 이게 이번 버그에서 가장 중요한 수정이었을 수도 있다. 기능 버그는 고쳤는데 같은 구조적 이유로 다음 버그가 또 조용히 쌓이면 의미가 없으니까.

돌아보면 이번 버그는 세 가지가 겹쳐서 늦게 발견됐다. 에러 없이 드롭하는 구조, 포맷 변형 추적 체계 없음, 그리고 운영팀 신호를 빨리 안 올린 것.

외부 메신저 연동은 처음 붙일 때 잡은 포맷이 전부라고 생각하는 경향이 있는데 실제로는 아니다. 기능이 붙을수록 알림 본문 포맷이 따라서 늘어난다. 연동 유지보수 아이템에 "포맷 변형 주기적 검토"를 넣어두지 않으면 이번처럼 몇 달씩 조용히 누락되다가 뒤늦게 발견된다.

운영팀 얘기를 안 할 수가 없다. "이거 가끔 안 되는 것 같은데요"라고 흘리듯 한 말이 한참 전에 있었다. 그때 우선순위를 바로 올렸어야 했다. 외부 연동 쪽에서 "가끔 이상해요"는 거의 항상 진짜 버그다. 일시적 오류면 재시도가 되거나 에러 로그에 흔적이 남는다. 조용히 반복되는 이상함은 대부분 파싱 분기 누락이다. 다음엔 이 신호를 더 빨리 잡아야겠다.