정산 메시지 19% 누락을 일으킨 발신자명 스킵 로직 수정
목차
무의식적 스킵의 함정
메시지 파서에서 발신자명이 "No Name"이면 통째로 스킵하던 로직이 있었음. 처음 짤 때는 "이름 없는 메시지는 어차피 쓰레기"라고 단정했음. 이번에 파트너 정산 데이터를 다시 훑다가, 발신자명만 비어있고 본문에는 실제 이름·금액·계좌가 멀쩡히 들어있는 케이스를 발견함.
원인은 단순함. 발신처 시스템마다 헤더 구성이 다름. 어떤 채널은 발신자 필드를 채워주고, 어떤 채널은 본문에 다 박아넣고 헤더는 비워둠.
무엇을 바꿨나
- 발신자명 == "No Name" 조기 return 제거
- 본문 raw_message 파싱은 발신자 유무와 무관하게 항상 수행
- 파싱 실패 케이스만 별도 분기로 빠지게 정리
변경 전: senderName == "No Name" → skip → 데이터 손실
변경 후: senderName 무시 → raw_message 파싱 → 이름 추출 시 정상 처리
손실 규모 추정
데이터를 빠르게 까봤음. 한 달치 샘플 기준 대략 이런 분포였음.
| 케이스 | 비율 | 기존 처리 | 영향 |
|---|---|---|---|
| 발신자명 정상 | 약 78% | 정상 처리 | 없음 |
| "No Name" + 본문 이름 있음 | 약 19% | 스킵됨 | 누락 |
| "No Name" + 본문도 비정형 | 약 3% | 스킵됨 | 정상 |
19%가 그냥 사라지고 있었음. 정산 측면에서는 작지 않은 숫자임. 다행히 raw_message는 원본을 보존하고 있어서 백필도 가능함.
회고 포인트
- "이건 어차피 쓰레기"라는 가정은 거의 틀림. 적어도 한 번은 raw 데이터를 직접 까봐야 함
- 헤더와 본문은 다른 시스템에서 채워지는 경우가 많아서, 한쪽만 보고 분기치면 손해 봄
- 파서는 "버리는 기준"을 보수적으로, "파싱 시도 기준"은 공격적으로 잡는 게 맞다는 걸 또 학습함
- 같은 류의 조기 return이 다른 유틸에도 있을 가능성 높음. 다음 사이클에 grep으로 한 번 훑어볼 예정
조기 최적화로 데이터를 버리는 게 가장 비싼 버그라는 걸 다시 확인함. 다음
댓글 0
첫 댓글 달아줘.