#retry
-
푸시 URL 누락과 카카오톡 노이즈 필터링 개선
배경 v3.1에서 알림 처리 파이프라인 두 군데 손봤음. 하나는 푸시 페이로드에서 URL을 한 번에 못 잡는 케이스 재시도, 다른 하나는 카카오톡에서 들어오는 시스템 메시지 필터링. 둘 다 운영 데이터 보다가 "이거 왜 누락됐지?" 추적하다 발견함. URL 재캡처 시도 기존에는 푸시 받자마자 한 번 파싱하고 끝냈는데, 페이로드가 잘려서 도착하는 경우가
읽기 → -
송금 푸시 알림 미수신을 재시도 큐로 해결
문제 상황 연락처 기반 송금 기능에서 푸시 알림이 가끔 빠지는 이슈가 보고됨. 로그 까보니 푸시 발송 자체는 호출되는데 토큰 만료/네트워크 일시 단절 같은 케이스에서 그냥 한 번 던지고 끝나는 구조였음. 받는 쪽은 돈 들어왔는지 모르고 있다가 나중에 앱 켜서 알게 되는 흐름. 송금 UX에서 꽤 치명적임. 원인 정리 기존 코드는 단발성 호출. 실패
읽기 → -
입금 매칭 우선순위 정리로 결제 연동 모듈 구조 개선
무엇을 손봤나 특정 은행 입금 연동 모듈을 정리했음. 기존 코드는 UI 렌더링, 입금 콜백 파싱, 잔액 갱신이 한 클래스에 다 들어있어서 손대기 무서운 상태였음. 한 줄 바꾸면 어디서 터질지 모르는 전형적인 레거시. 이번엔 두 갈래로 쪼갰음. - **표시 레이어**: 파트너 화면에서 보여주는 입금 안내 / 계좌 표기 부분 - **처리 레이어**: 결
읽기 → -
크로스 오리진 iframe 비디오 감지율을 절반 이상 끌어올린 방법
iframe 안의 비디오, 왜 못 잡나 부모 document에서 querySelectorAll('video') 돌리면 같은 오리진 iframe 안의 비디오까지는 그래도 contentDocument로 파고 들어갈 수 있음. 근데 크로스 오리진 iframe은 브라우저가 막아놔서 접근 자체가 불가. 외부 임베드 페이지가 많은 사이트일수록 감지율이 뚝 떨어짐.
읽기 → -
결제 수수료 정산을 지연 차감 방식으로 전환해 환불 흐름 단순화
배경 결제 플랫폼에서 파트너에게 부과되는 수수료를 결제 즉시 차감하는 기존 로직이 있었음. 문제는 이커머스 특성상 결제 후에도 환불/취소가 빈번하게 일어난다는 점. 즉시 차감해버리면 환불이 들어왔을 때 수수료를 다시 환원해야 하는데, 이 역방향 흐름이 곳곳에서 깨지고 있었음. 흐름 재설계 결제대행사에서 정산 데이터가 넘어오는 시점을 기준으로 상태를
읽기 → -
입금 웹훅 구조를 레지스트리 패턴으로 전환해 은행 추가 용이성 개선
배경 연락처 송금 기능에 입금 통보 받을 은행이 한 곳 더 늘어남. 기존엔 진입 컨트롤러에서 은행 코드별 if-else로 분기하던 구조라 추가할 때마다 같은 파일을 또 건드려야 했음. 이번에 인터넷전문은행 한 곳 더 붙이라는 요청 받았는데, 같은 자리를 또 손대기 싫어서 레지스트리 패턴으로 갈아엎기로 함. 무엇을 바꿨나 - 결제대행사 웹훅 수신 진입점
읽기 → -
송금 수수료 홀딩 정책 도입과 파트너별 입금 통계 화면 추가
연락처 송금 수수료 관리, 그리고 파트너 입금 통계 오늘은 결제 플랫폼에 두 가지를 한 번에 밀어넣음. 하나는 연락처 송금 흐름에 수수료 정책을 붙이는 작업, 다른 하나는 파트너별로 입금 내역을 합산해서 운영팀이 볼 수 있게 만드는 통계 화면. 처음엔 두 작업이 별개라고 생각했는데, 막상 들여다보니 **잔액 계산 유틸리티**가 양쪽에서 똑같이 호출되고
읽기 → -
알림 파이프라인에서 발신자 표시명 분리 정규화로 채널별 오발송 해결
v3.1 릴리스 — senderDisplay 필드 추가하다 만난 알림 파이프라인 이슈 API 스펙 작은 변경 하나가 알림 파이프라인 전체를 흔드는 경험을 또 함. 파트너 쪽에서 "발신자 표시명을 별도로 받고 싶다"는 요청이 왔고, 기존 sender 외에 senderDisplay 를 추가했음. 처음엔 단순 nullable 문자열 추가라 30분이면 끝날
읽기 → -
안드로이드 절전 정책으로 끊기던 새벽 알림 수집 해결
24시간 돌려야 하는 수집기, 새벽마다 멈췄음 알림 수집 모듈을 백그라운드로 24시간 띄워놓는 구조였는데, 새벽 3~5시 사이에 수집이 끊기는 현상이 반복됐음. 처음엔 네트워크 이슈인 줄 알았는데 로그를 까보니 프로세스 자체가 잠들어 있었음. Doze 모드와 App Standby가 만든 합작품이었음. Doze가 뭘 죽이는지부터 정리 배터리 최적화
읽기 → -
이커머스 결제 앱 빌드 파이프라인 보안·성능 일괄 정비
v3.1 릴리스 정리: 보안·성능·배포 설정을 한 번에 손봄 이커머스 결제 플랫폼 모바일 빌드 v3.1 작업하면서 빌드 스크립트, 난독화 규칙, 버전 메타, gitignore 4종 세트를 같이 갈아엎었음. 한 번에 묶은 이유는 단순함 — 셋 중 하나만 건드리면 나머지가 무조건 어긋남. .gitignore 부터 정리 처음에 잡힌 추적 누락 파일들 보
읽기 → -
AI 분류로 자동입금 무한 재시도와 새벽 운영 알람을 잡다
문제 상황 자동입금 확정 단계에서 실패 메시지가 들어오면 무조건 재시도 큐에 다시 넣고 있었음. 그러다 보니 영구 실패(잘못된 계좌·만료된 거래)도 무한 재시도 대상이 됐고, 운영팀이 새벽에 알람 받고 수동으로 끄러 들어가는 일이 반복됨. 대표적으로 들어오는 메시지가 이런 식임. [입금알림] 거래종료 / 금액불일치 / 한도초과 / 일시오류 겉으
읽기 → -
결제 알림 신규 파트너 추가
배경 결제 알림을 메신저로 수신해서 내부에 반영하는 모듈이 있음. 이번 v3.1에서 두 가지를 손봤음. - 신규 파트너 은행을 수신 대상에 추가 - 채팅방 URL 검색 로직 개선 기존 로직이 prefix 매칭이라 신규 파트너의 URL 패턴을 못 잡고 빠지는 문제가 있었음. 알림이 들어와도 어느 파트너 채널인지 식별이 안 되니 그대로 드랍됨. 신규
읽기 → -
결제 입금 알림이 엉뚱한 채팅방으로 가던 오배송 문제 수정
채팅방 매칭이 어긋나던 문제 파트너가 결제대행사로부터 입금 알림을 받아 메신저 채팅방으로 푸시하는 흐름이 있었음. 그런데 같은 파트너가 여러 거래 은행을 동시에 쓰는 케이스가 늘면서, 알림이 엉뚱한 방으로 들어가는 사고가 잦아짐. 원인은 단순했음. 채팅방을 찾을 때 쓰던 키가 너무 헐거웠음. - 파트너 식별자 하나만 매칭 키로 사용 - 같은 파트너가
읽기 → -
결제 외부 연동 재시도 개선과 수령 ID 분리로 추적 안정화
v3.1 작업 회고 — 재시도 로직 갈아엎고 메시지 ID 분리 오랜만에 결제 플랫폼 외부 연동 모듈 손봤음. 외부 API 호출 실패율이 새벽 시간대에 튀는 문제랑, 수령 결과 응답에서 메시지 ID 구분이 안 돼서 추적 안 되던 이슈 두 개를 한 번에 처리. 재시도 로직, 뭐가 문제였나 기존 API 클라이언트의 재시도가 너무 단순했음. 고정 간격 3
읽기 → -
출금 실패 알림과 포인트 조회 오류 동시 수정
출금 실패 복구에 긴급 알림 붙임 결제대행사 webhook 처리 중 출금 실패가 났을 때, 자동 복구는 돌아가는데 운영자가 모르고 지나가는 사고가 있었음. 새벽에 터지면 다음날 아침에 발견해서 정산 마감 직전에 허둥대는 패턴이 반복됨. 복구 자체보다 **인지 지연**이 진짜 리스크라는 걸 늦게 깨달음. 알림 분기를 단순하게 잡았음. | 트리거 | 채
읽기 → -
송금 대사 배치로 원장·결제·큐 불일치 자동 감지
연락처 송금 대사 배치를 만들게 된 이유 운영 들어간 지 한 달쯤 됐을 때 파트너 한 곳에서 "어제 송금 건 합계가 안 맞는다"는 문의가 들어왔음. 큐에 쌓인 송금 요청, 결제대행사로 넘긴 실제 출금, 우리 원장 잔액 차감 — 이 셋이 따로 노는 순간이 가끔 있다는 걸 그제서야 발견함. 사람이 매일 아침 SQL 돌려서 맞추고 있었는데 이게 지속 가능하지
읽기 → -
파트너 충전 입금자명 미스매칭 건수 감소
버그 발견 파트너 충전 매칭 로직에서 입금자명 미스매칭이 늘고 있었음. 입금 알림 SMS 파싱 결과를 보니 입금자명 자리에 "잔액", "수수료", "농협" 같은 엉뚱한 토큰이 박혀 있었음. 매칭 실패 → 수동 처리 큐 적체 → CS 부담 증가의 깔끔한 도미노. 기존 로직 한계 파서가 "입금" 키워드 뒤 첫 토큰을 무조건 입금자명으로 가정하고 있었음
읽기 → -
정산 입금 알림 누락을 정규식·타임아웃 개선으로 해결
문제 상황 이커머스 정산 처리에서 메신저 봇으로 들어오는 입금 알림을 받아 링크를 추출하고 후속 작업을 트리거하는 모듈을 손봤음. 최근 며칠 "분명 알림은 들어왔는데 처리 안 된" 건이 늘어 원인 분석함. 추적해보니 두 가지였음. - 링크 캡처 정규식이 메신저측 포맷 변경에 못 따라감 - 외부 검증 호출 타임아웃이 너무 짧아 피크 시간대에 실패
읽기 → -
송금 폼 버그 6건을 이벤트 누락 하나로 한 번에 해결
송금 폼 6건 한 번에 잡은 날 특정 시중은행 연동 송금 폼에서 자잘한 버그 6건이 동시에 올라옴. 하나씩 보면 사소한데 모이니까 사용자가 1단계도 못 넘는 상황. 결제 플랫폼에서 "입력 안 됨"은 곧 이탈이라 우선순위 최상위로 올림. 증상 정리 올라온 리포트 그대로 옮기면: | 번호 | 증상 | 재현 조건 | |---|---|---| | 1 |
읽기 → -
파트너 정산 송금을 접근성 서비스로 자동화한 과정
송금 자동화 배경 파트너 정산 처리량이 늘면서 수기 송금 부담이 한계점 도달. 결제대행사 정산 사이클 밖의 즉시 송금 건은 사람이 직접 은행 앱을 두드려야 했음. 안드로이드 접근성 서비스로 은행 앱 폼을 자동으로 채우는 보조 수단을 도입함. 결제 플랫폼 본 흐름은 그대로 두고, 운영팀 손이 닿는 부분만 줄이는 게 목표였음. - 메신저 알림 수신 → 송
읽기 →