#api
-
AI 분류로 자동입금 무한 재시도와 새벽 운영 알람을 잡다
문제 상황 자동입금 확정 단계에서 실패 메시지가 들어오면 무조건 재시도 큐에 다시 넣고 있었음. 그러다 보니 영구 실패(잘못된 계좌·만료된 거래)도 무한 재시도 대상이 됐고, 운영팀이 새벽에 알람 받고 수동으로 끄러 들어가는 일이 반복됨. 대표적으로 들어오는 메시지가 이런 식임. [입금알림] 거래종료 / 금액불일치 / 한도초과 / 일시오류 겉으
읽기 → -
은행명 표기 불일치로 매일 누락되던 정산 30건 해결
은행명 매칭이 깨진 사연 결제대행사에서 내려주는 은행명 표기가 우리 내부 표준이랑 미묘하게 달라서 정산이 한 건씩 누락되던 이슈. 지역 농축협·새마을 계열에서 특히 자주 터졌음. 같은 은행인데 "새마을", "MG새마을", "새마을금고" 이렇게 세 가지 표기로 들어오는 게 발단. 문제의 코드 기존 매칭이 완전 일치 기반이라 한 글자라도 어긋나면 미매
읽기 → -
결제 알림 신규 파트너 추가
배경 결제 알림을 메신저로 수신해서 내부에 반영하는 모듈이 있음. 이번 v3.1에서 두 가지를 손봤음. - 신규 파트너 은행을 수신 대상에 추가 - 채팅방 URL 검색 로직 개선 기존 로직이 prefix 매칭이라 신규 파트너의 URL 패턴을 못 잡고 빠지는 문제가 있었음. 알림이 들어와도 어느 파트너 채널인지 식별이 안 되니 그대로 드랍됨. 신규
읽기 → -
결제 입금 알림이 엉뚱한 채팅방으로 가던 오배송 문제 수정
채팅방 매칭이 어긋나던 문제 파트너가 결제대행사로부터 입금 알림을 받아 메신저 채팅방으로 푸시하는 흐름이 있었음. 그런데 같은 파트너가 여러 거래 은행을 동시에 쓰는 케이스가 늘면서, 알림이 엉뚱한 방으로 들어가는 사고가 잦아짐. 원인은 단순했음. 채팅방을 찾을 때 쓰던 키가 너무 헐거웠음. - 파트너 식별자 하나만 매칭 키로 사용 - 같은 파트너가
읽기 → -
결제 외부 연동 재시도 개선과 수령 ID 분리로 추적 안정화
v3.1 작업 회고 — 재시도 로직 갈아엎고 메시지 ID 분리 오랜만에 결제 플랫폼 외부 연동 모듈 손봤음. 외부 API 호출 실패율이 새벽 시간대에 튀는 문제랑, 수령 결과 응답에서 메시지 ID 구분이 안 돼서 추적 안 되던 이슈 두 개를 한 번에 처리. 재시도 로직, 뭐가 문제였나 기존 API 클라이언트의 재시도가 너무 단순했음. 고정 간격 3
읽기 → -
송금 대사 배치로 원장·결제·큐 불일치 자동 감지
연락처 송금 대사 배치를 만들게 된 이유 운영 들어간 지 한 달쯤 됐을 때 파트너 한 곳에서 "어제 송금 건 합계가 안 맞는다"는 문의가 들어왔음. 큐에 쌓인 송금 요청, 결제대행사로 넘긴 실제 출금, 우리 원장 잔액 차감 — 이 셋이 따로 노는 순간이 가끔 있다는 걸 그제서야 발견함. 사람이 매일 아침 SQL 돌려서 맞추고 있었는데 이게 지속 가능하지
읽기 → -
파트너 충전 입금자명 미스매칭 건수 감소
버그 발견 파트너 충전 매칭 로직에서 입금자명 미스매칭이 늘고 있었음. 입금 알림 SMS 파싱 결과를 보니 입금자명 자리에 "잔액", "수수료", "농협" 같은 엉뚱한 토큰이 박혀 있었음. 매칭 실패 → 수동 처리 큐 적체 → CS 부담 증가의 깔끔한 도미노. 기존 로직 한계 파서가 "입금" 키워드 뒤 첫 토큰을 무조건 입금자명으로 가정하고 있었음
읽기 → -
정산 입금 알림 누락을 정규식·타임아웃 개선으로 해결
문제 상황 이커머스 정산 처리에서 메신저 봇으로 들어오는 입금 알림을 받아 링크를 추출하고 후속 작업을 트리거하는 모듈을 손봤음. 최근 며칠 "분명 알림은 들어왔는데 처리 안 된" 건이 늘어 원인 분석함. 추적해보니 두 가지였음. - 링크 캡처 정규식이 메신저측 포맷 변경에 못 따라감 - 외부 검증 호출 타임아웃이 너무 짧아 피크 시간대에 실패
읽기 → -
입금 크롤링을 HTTP 직접 호출로 교체해 응답 10배 빠르게
출발점 입금 내역 확인용 유틸이 헤드리스 브라우저로 은행 사이트를 띄워서 DOM 긁는 구조였음. 의존성 무겁고, 셀렉터 한 번 어긋나면 통째로 멈춤. 새벽에 알람 받고 일어난 적이 한두 번이 아니라서 진짜로 한 번 갈아엎고 싶었음. 무엇을 바꿨나 실제 동작을 패킷 캡처로 까보니 결국 로그인 토큰 받고 거래내역 조회 엔드포인트 두세 번 때리는 게 전부였
읽기 → -
송금 폼 버그 6건을 이벤트 누락 하나로 한 번에 해결
송금 폼 6건 한 번에 잡은 날 특정 시중은행 연동 송금 폼에서 자잘한 버그 6건이 동시에 올라옴. 하나씩 보면 사소한데 모이니까 사용자가 1단계도 못 넘는 상황. 결제 플랫폼에서 "입력 안 됨"은 곧 이탈이라 우선순위 최상위로 올림. 증상 정리 올라온 리포트 그대로 옮기면: | 번호 | 증상 | 재현 조건 | |---|---|---| | 1 |
읽기 → -
파트너 정산 송금을 접근성 서비스로 자동화한 과정
송금 자동화 배경 파트너 정산 처리량이 늘면서 수기 송금 부담이 한계점 도달. 결제대행사 정산 사이클 밖의 즉시 송금 건은 사람이 직접 은행 앱을 두드려야 했음. 안드로이드 접근성 서비스로 은행 앱 폼을 자동으로 채우는 보조 수단을 도입함. 결제 플랫폼 본 흐름은 그대로 두고, 운영팀 손이 닿는 부분만 줄이는 게 목표였음. - 메신저 알림 수신 → 송
읽기 → -
가상계좌 입금자명 매칭 실패를 알림 title 폴백으로 해결
입금자명, 왜 갑자기 title에서 빼야 했나 며칠 전부터 가상계좌 입금 매칭 실패율이 슬금슬금 올라감. 이상하다 싶어서 알림 원본 페이로드 까봤더니, 원인이 어이없었음. 카카오 쪽에서 내려주는 알림 본문(body) 포맷이 일부 케이스에서 바뀌어 있었음. 기존엔 본문에 홍길동님 1,000,000원 입금 식으로 깔끔하게 들어왔는데, 어느 순간부터는 본문에
읽기 → -
메신저 송금봉투 자동수령 누락 버그 수정
메신저 송금봉투 자동수령이 안 먹던 이유 파트너 정산 자동화 작업 중에 외부 메신저 송금봉투 알림이 들어와도 자동수령이 안 되는 케이스를 발견함. 알림 메시지는 분명히 들어왔는데 수령 처리가 안 되고 그대로 만료되는 상황. 이미 수동으로 처리하던 운영팀이 한참 쌓아둔 뒤에 알려줬음. 미안해서 바로 파봤음. 원인은 메시지 파서의 정규식 기존 파서는
읽기 → -
결제 파싱 오류를 LLM 교차검증으로 조기 포착한 정산 파이프라인 개선
파싱 데이터 신뢰도 문제 알림 페이로드에서 결제 정보를 뽑아 쓰는 파이프라인을 운영 중인데, 포맷이 자주 바뀜. 정규식으로 떠받치다가 한 글자 차이로 금액이 0원으로 들어가는 사고가 났음. 사후에 보면 "사람이 봤으면 다 보였을 텐데" 싶은 케이스가 대부분이라 LLM으로 한 번 더 훑게 했음. 왜 서버 프록시인가 클라이언트에서 직접 모델 호출하면
읽기 → -
입금 통보 파서에 AI 검증 얹어 정산 수기 보정 60% 줄임
배경 이커머스 결제 플랫폼에서 파트너별 입금 통보 메시지를 수신해 자동 매칭하는 기능이 있었음. 문제는 결제대행사·은행마다 포맷이 제각각이라 정규식이 폭발적으로 늘어났다는 것. 기존 파서는 새 포맷 하나 추가될 때마다 분기 로직이 누더기처럼 붙음. 입금자명 한 글자 누락되면 매칭 실패했고, 그게 누락 데이터로 쌓여서 운영팀이 매일 수기 보정함. 구
읽기 → -
로컬 DB 싱글턴화로 초기화 속도 개선하고 커밋 컨벤션 정리
커밋 컨벤션 정리하다가 메시지가 꼬임 오늘 작업은 분량으로 보면 가벼운데 시간을 의외로 잡아먹었음. 스킬/에이전트 가이드 문서 두 개, 진입점 화면 클래스 라이프사이클 한 군데, 로컬 DB 추상 레이어를 한 커밋에 묶다가 prefix 표기를 잘못 적어서 다시 정리함. 무엇이 문제였나 처음엔 그냥 feat: chage git 이라고 적었음. 보다시피
읽기 → -
브라우저 자동화 격리로 세션 충돌 없애고 확인 작업 속도 개선
심볼릭 링크에서 실제 파일로 agent-browser 스킬 추가하면서 같이 정리한 게 AGENTS.md 처리 방식임. 원래는 다른 문서를 참조하는 형태로 두고 있었는데, 도구가 그 참조를 따라가지 못하는 케이스가 자꾸 생겨서 그냥 실제 파일로 박아버림. 겉보기엔 똑같은데, 도구가 읽을 때 동작이 달라짐. | 구분 | 이전 | 변경 후 | |---|-
읽기 → -
폐업 사업자 정산 오류 막으려 진위확인 API와 알림 로그 관리 도입
사업자 진위확인 외부 API 붙이기 파트너 등록 화면에서 사업자번호 검증을 외부 API로 처리하기로 함. 기존엔 입력값을 그냥 믿고 저장했는데, 실제로 폐업·휴업 사업자 데이터가 섞여서 정산할 때 골치 아팠음. 검증 응답에서 챙긴 필드: | 필드 | 의미 | |---|---| | 상태코드 | 계속/휴업/폐업 | | 과세유형 | 일반/간이/면세 | |
읽기 → -
기기 교체 후 수신 메시지 복구를 위한 서버 동기화 구현기
왜 만들었나 - 기기 교체하면 이전 수신 내역이 통째로 날아갔음. 사용자 문의가 꾸준히 들어옴 - 로컬에만 쌓아둔 데이터라 복구 경로가 아예 없었음 - 서버에 보존돼 있는 원본을 끌어와 로컬과 병합하는 흐름이 필요했음 구조 잡기 | 레이어 | 역할 | |--|--| | 진입 화면 | 최초 진입 시 동기화 트리거 | | 설정 화면 | 수동 재동기화 +
읽기 → -
간편결제 입금 자동 매칭으로 파트너 정산 클레임 해소
왜 자동 감지가 필요했나 - 간편결제 송금으로 들어오는 입금 건은 그동안 운영팀이 화면 보면서 손으로 매칭했음 - 입금량이 늘면서 매칭 지연 → 파트너 정산 클레임 누적 - 정산 파이프라인 끝단이 수동이라 앞단 자동화 효과가 다 깎이고 있었음 두 가지 선택지를 두고 고민함 결제대행사 쪽 입금 알림 채널과 자체 폴링을 같이 검토했음. | 방식 | 장점
읽기 →