사이드프로젝트 slecs

푸시 URL 누락과 카카오톡 노이즈 필터링 개선

목차

배경

v3.1에서 알림 처리 파이프라인 두 군데 손봤음. 하나는 푸시 페이로드에서 URL을 한 번에 못 잡는 케이스 재시도, 다른 하나는 카카오톡에서 들어오는 시스템 메시지 필터링. 둘 다 운영 데이터 보다가 "이거 왜 누락됐지?" 추적하다 발견함.

URL 재캡처 시도

기존에는 푸시 받자마자 한 번 파싱하고 끝냈는데, 페이로드가 잘려서 도착하는 경우가 꽤 있었음. 특히 본문 길이가 길거나 이모지/특수문자가 섞이면 URL 토큰이 잘림. 그래서 1차 파싱 실패 시 짧은 백오프 후 다시 가져오도록 변경함.

1 시도  실패  +1.5s  재시도  실패  +4s  마지막 시도
  • 재시도 횟수는 최대 3회로 제한 (배터리/데이터 고려)
  • 동일 알림 ID는 dedupe 셋으로 관리해서 중복 처리 방지
  • 마지막 시도까지 실패하면 로컬 큐에 적재, 다음 포그라운드 진입 시 일괄 재처리

처음에는 무한 재시도로 짰다가, 푸시 폭주하는 시간대에 디바이스가 발열하는 걸 보고 횟수 캡 걸었음. 운영 한 주 돌려보니 누락률이 약 6%대에서 0.7%대로 떨어짐.

카카오톡 노이즈 필터링

파서 입장에서 가장 짜증났던 게 시스템 메시지였음. "OOO님이 들어왔습니다", "메시지가 삭제되었습니다" 같은 게 본문에 섞여 들어오면서 URL/금액 추출 로직이 헛돌았음.

노이즈 유형 처리
입퇴장 안내 drop
삭제/가려진 메시지 drop
광고/공지 봇 발신자 화이트리스트 외 drop
첨부 메타데이터만 있는 행 drop

룰을 코드에 박지 않고 외부 설정으로 빼서, 새 패턴이 나오면 앱 재배포 없이 즉시 반영되도록 했음. 정규식은 가능하면 안 쓰고 prefix/suffix 매칭 위주로 갔는데, 백트래킹 비용 때문에 메인 스레드에서 깜빡 멈추는 케이스가 있었어서 그럼.

회고

  • "한 번 파싱"이라는 가정 자체가 모바일 푸시 환경에서는 너무 낙관적이었음
  • 노이즈 필터는 코드보다 데이터로 관리해야 운영하기 편함
  • 다음에는 재시도 전략을 서버 측에서도 보강할지 검토 예정

다음

댓글 0

첫 댓글 달아줘.