#queue
-
출금 실패 알림과 포인트 조회 오류 동시 수정
출금 실패 복구에 긴급 알림 붙임 결제대행사 webhook 처리 중 출금 실패가 났을 때, 자동 복구는 돌아가는데 운영자가 모르고 지나가는 사고가 있었음. 새벽에 터지면 다음날 아침에 발견해서 정산 마감 직전에 허둥대는 패턴이 반복됨. 복구 자체보다 **인지 지연**이 진짜 리스크라는 걸 늦게 깨달음. 알림 분기를 단순하게 잡았음. | 트리거 | 채
읽기 → -
결제 외부 연동 재시도 개선과 수령 ID 분리로 추적 안정화
v3.1 작업 회고 — 재시도 로직 갈아엎고 메시지 ID 분리 오랜만에 결제 플랫폼 외부 연동 모듈 손봤음. 외부 API 호출 실패율이 새벽 시간대에 튀는 문제랑, 수령 결과 응답에서 메시지 ID 구분이 안 돼서 추적 안 되던 이슈 두 개를 한 번에 처리. 재시도 로직, 뭐가 문제였나 기존 API 클라이언트의 재시도가 너무 단순했음. 고정 간격 3
읽기 → -
결제 큐에서 재시도 초과 건이 무한 반복되던 문제 해결
무한 재시도 지옥에서 빠져나옴 큐에서 작업 꺼내올 때 retry_count 조건이 빠져있었음. max_retry 도달한 작업도 계속 다시 집어가는 구조였음. 결제대행사 응답 지연으로 한 번 실패한 건이 영원히 큐를 떠다녔던 거. 어떻게 발견했는지 파트너 정산 모니터링 보다가 실패 누적이 비정상적으로 많은 걸 발견함. 같은 트랜잭션 ID가 로그에 수
읽기 → -
송금 대사 배치로 원장·결제·큐 불일치 자동 감지
연락처 송금 대사 배치를 만들게 된 이유 운영 들어간 지 한 달쯤 됐을 때 파트너 한 곳에서 "어제 송금 건 합계가 안 맞는다"는 문의가 들어왔음. 큐에 쌓인 송금 요청, 결제대행사로 넘긴 실제 출금, 우리 원장 잔액 차감 — 이 셋이 따로 노는 순간이 가끔 있다는 걸 그제서야 발견함. 사람이 매일 아침 SQL 돌려서 맞추고 있었는데 이게 지속 가능하지
읽기 → -
파트너 충전 입금자명 미스매칭 건수 감소
버그 발견 파트너 충전 매칭 로직에서 입금자명 미스매칭이 늘고 있었음. 입금 알림 SMS 파싱 결과를 보니 입금자명 자리에 "잔액", "수수료", "농협" 같은 엉뚱한 토큰이 박혀 있었음. 매칭 실패 → 수동 처리 큐 적체 → CS 부담 증가의 깔끔한 도미노. 기존 로직 한계 파서가 "입금" 키워드 뒤 첫 토큰을 무조건 입금자명으로 가정하고 있었음
읽기 → -
정산 입금 알림 누락을 정규식·타임아웃 개선으로 해결
문제 상황 이커머스 정산 처리에서 메신저 봇으로 들어오는 입금 알림을 받아 링크를 추출하고 후속 작업을 트리거하는 모듈을 손봤음. 최근 며칠 "분명 알림은 들어왔는데 처리 안 된" 건이 늘어 원인 분석함. 추적해보니 두 가지였음. - 링크 캡처 정규식이 메신저측 포맷 변경에 못 따라감 - 외부 검증 호출 타임아웃이 너무 짧아 피크 시간대에 실패
읽기 → -
송금 폼 버그 6건을 이벤트 누락 하나로 한 번에 해결
송금 폼 6건 한 번에 잡은 날 특정 시중은행 연동 송금 폼에서 자잘한 버그 6건이 동시에 올라옴. 하나씩 보면 사소한데 모이니까 사용자가 1단계도 못 넘는 상황. 결제 플랫폼에서 "입력 안 됨"은 곧 이탈이라 우선순위 최상위로 올림. 증상 정리 올라온 리포트 그대로 옮기면: | 번호 | 증상 | 재현 조건 | |---|---|---| | 1 |
읽기 → -
파트너 정산 송금을 접근성 서비스로 자동화한 과정
송금 자동화 배경 파트너 정산 처리량이 늘면서 수기 송금 부담이 한계점 도달. 결제대행사 정산 사이클 밖의 즉시 송금 건은 사람이 직접 은행 앱을 두드려야 했음. 안드로이드 접근성 서비스로 은행 앱 폼을 자동으로 채우는 보조 수단을 도입함. 결제 플랫폼 본 흐름은 그대로 두고, 운영팀 손이 닿는 부분만 줄이는 게 목표였음. - 메신저 알림 수신 → 송
읽기 → -
가상계좌 입금자명 매칭 실패를 알림 title 폴백으로 해결
입금자명, 왜 갑자기 title에서 빼야 했나 며칠 전부터 가상계좌 입금 매칭 실패율이 슬금슬금 올라감. 이상하다 싶어서 알림 원본 페이로드 까봤더니, 원인이 어이없었음. 카카오 쪽에서 내려주는 알림 본문(body) 포맷이 일부 케이스에서 바뀌어 있었음. 기존엔 본문에 홍길동님 1,000,000원 입금 식으로 깔끔하게 들어왔는데, 어느 순간부터는 본문에
읽기 → -
메신저 송금봉투 자동수령 누락 버그 수정
메신저 송금봉투 자동수령이 안 먹던 이유 파트너 정산 자동화 작업 중에 외부 메신저 송금봉투 알림이 들어와도 자동수령이 안 되는 케이스를 발견함. 알림 메시지는 분명히 들어왔는데 수령 처리가 안 되고 그대로 만료되는 상황. 이미 수동으로 처리하던 운영팀이 한참 쌓아둔 뒤에 알려줬음. 미안해서 바로 파봤음. 원인은 메시지 파서의 정규식 기존 파서는
읽기 → -
결제 파싱 오류를 LLM 교차검증으로 조기 포착한 정산 파이프라인 개선
파싱 데이터 신뢰도 문제 알림 페이로드에서 결제 정보를 뽑아 쓰는 파이프라인을 운영 중인데, 포맷이 자주 바뀜. 정규식으로 떠받치다가 한 글자 차이로 금액이 0원으로 들어가는 사고가 났음. 사후에 보면 "사람이 봤으면 다 보였을 텐데" 싶은 케이스가 대부분이라 LLM으로 한 번 더 훑게 했음. 왜 서버 프록시인가 클라이언트에서 직접 모델 호출하면
읽기 → -
로컬 DB 싱글턴화로 초기화 속도 개선하고 커밋 컨벤션 정리
커밋 컨벤션 정리하다가 메시지가 꼬임 오늘 작업은 분량으로 보면 가벼운데 시간을 의외로 잡아먹었음. 스킬/에이전트 가이드 문서 두 개, 진입점 화면 클래스 라이프사이클 한 군데, 로컬 DB 추상 레이어를 한 커밋에 묶다가 prefix 표기를 잘못 적어서 다시 정리함. 무엇이 문제였나 처음엔 그냥 feat: chage git 이라고 적었음. 보다시피
읽기 → -
기기 교체 후 수신 메시지 복구를 위한 서버 동기화 구현기
왜 만들었나 - 기기 교체하면 이전 수신 내역이 통째로 날아갔음. 사용자 문의가 꾸준히 들어옴 - 로컬에만 쌓아둔 데이터라 복구 경로가 아예 없었음 - 서버에 보존돼 있는 원본을 끌어와 로컬과 병합하는 흐름이 필요했음 구조 잡기 | 레이어 | 역할 | |--|--| | 진입 화면 | 최초 진입 시 동기화 트리거 | | 설정 화면 | 수동 재동기화 +
읽기 → -
간편결제 입금 자동 매칭으로 파트너 정산 클레임 해소
왜 자동 감지가 필요했나 - 간편결제 송금으로 들어오는 입금 건은 그동안 운영팀이 화면 보면서 손으로 매칭했음 - 입금량이 늘면서 매칭 지연 → 파트너 정산 클레임 누적 - 정산 파이프라인 끝단이 수동이라 앞단 자동화 효과가 다 깎이고 있었음 두 가지 선택지를 두고 고민함 결제대행사 쪽 입금 알림 채널과 자체 폴링을 같이 검토했음. | 방식 | 장점
읽기 → -
파트너 정산 은행 도메인 누락으로 송금 인증 실패하던 문제 수정
채팅 메시지 속 은행 링크를 못 찾았음 파트너 정산 채널에서 송금 인증 캡처 대신 메시지 앱 링크를 그대로 붙여넣는 케이스가 점점 늘었음. 메시지 본문에서 은행 도메인을 뽑아 송금 사실을 검증하는 로직이 있는데, CS팀에서 "특정 은행만 매번 인증 실패가 난다"는 리포트가 연달아 들어옴. 원인: 도메인 화이트리스트 노후화 은행 URL 추출기는 정규
읽기 → -
가상계좌 입금 알림을 다중 은행 채널로 확장해 누락 해소
은행 알림에서 가상계좌 입금 URL을 자동으로 받아오는 경로에 손댔음. 기존엔 메신저 푸시 한 채널만 후킹해서 처리했는데, 일부 은행은 자체 푸시/SMS로만 결과를 쏴주니 누수가 생김. 파트너 화면에서 "입금됐는데 왜 반영 안 됨?" 문의가 한 주에 두어 건씩 올라왔음. 무엇을 바꿨나 주요 시중은행 두 곳(A, B) 알림을 별도 경로로 캡처하도록 텄음
읽기 → -
파트너 입금 정산 자동화로 야간 누락 제로 달성
왜 자동화했나 파트너 입금 확인을 매번 손으로 처리하다 보니 누락이 생김. 메신저로 알림 와서 → 사람이 브라우저 열고 → 링크 타고 들어가서 → 내용 확인 → 다시 내부 시스템에 등록하는 패턴이 반복됐는데, 야간엔 처리가 늦어져서 정산이 밀림. "이거 왜 사람이 함?" 싶어서 파이프라인으로 묶음. 처리 흐름 | 단계 | 주체 | 역할 | |---
읽기 → -
송금 URL로 은행 자동 판별하는 구조 짜기
캡처된 송금 URL을 어떻게 받을지 고민함 스마트폰에서 연락처 송금을 누르면 은행 앱이 뜨는 게 일반적인데, 우리는 한 칸 앞에 끼어들어야 했음. 사용자가 송금 직전에 URL을 캡처해 넘겨주면, 그걸 보고 어느 은행인지 판별하고 후속 흐름을 잇는 구조. 문제는 은행마다 URL 포맷이 제각각이라는 점. 은행 판별을 어떻게 짰나 처음엔 정규식 한 줄
읽기 → -
결제 알림 오프라인 유실 없애고 자동수령 안정화
시작 오늘은 메신저 자동수령 안정화 작업을 한 바퀴 돌렸음. 단말에서 결제 알림을 잡아 백엔드로 흘려보내는 모듈인데, 네트워크 끊겼을 때 알림이 통째로 사라지는 게 오래된 골칫거리였음. 한 방에 잡으려고 세 갈래로 손댔음. 오프라인 큐잉 기존엔 알림 받자마자 바로 HTTP 호출. 지하철/엘리베이터에서 끊기면 그대로 소실됐음. 로컬 DB에 1차 적재
읽기 → -
입금 큐 성공 후 주문 매칭이 자동으로 안 되던 문제 해결
큐가 끝났는데 주문은 안 잡히던 문제 큐 처리 결과가 SUCCESS로 떨어지는데, 정작 주문 매칭은 자동으로 안 돌던 케이스를 잡음. 결제대행사에서 입금 통지가 온 뒤 큐가 멀쩡히 처리되고 SUCCESS 상태까지 도달했는데, 그 다음 단계인 "어떤 주문에 이 입금을 붙일지" 매칭이 별도 스케줄러나 수동 호출에 의존하던 구조였음. 증상 - 입금 통지
읽기 →