-
수수료·쿠폰·정산 배치를 한 PR로 묶어 잔액 정합성 확보
수수료·정산·쿠폰 한 번에 묶은 날 오늘 만진 건 네 덩어리. 수수료 조회, 결제대행사 설정, 정산 배치, 쿠폰 상태 API. 하나하나 떼면 작은데 묶어 보니 결국 "파트너가 돈을 내고 받는 흐름" 전체가 한 줄로 이어짐. 정산 도메인은 이렇게 한 번에 손대는 게 정신 건강에 좋다. 부분만 고치면 나중에 숫자 안 맞을 때 어디서 깨진지 못 찾음. 바
읽기 → -
파트너 쿠폰 링크 오작동과 일별 충전 한도 정산 오류 수정
쿠폰 공유 링크가 엉뚱한 곳으로 가고 있었음 파트너 화면에서 쿠폰을 공유하면 링크가 다른 도메인으로 붙는 이슈가 있었음. 운영 환경마다 호스트가 다른데 베이스 URL이 한쪽 값으로 굳어 있던 게 원인. 보고 한숨 나옴. - 로컬에서는 정상으로 보였는데 운영 도메인에서는 잘못된 경로로 리다이렉트 - QR 찍으면 404 뜨는 케이스가 여러 건 - 파트너가
읽기 → -
푸시 URL 누락과 카카오톡 노이즈 필터링 개선
배경 v3.1에서 알림 처리 파이프라인 두 군데 손봤음. 하나는 푸시 페이로드에서 URL을 한 번에 못 잡는 케이스 재시도, 다른 하나는 카카오톡에서 들어오는 시스템 메시지 필터링. 둘 다 운영 데이터 보다가 "이거 왜 누락됐지?" 추적하다 발견함. URL 재캡처 시도 기존에는 푸시 받자마자 한 번 파싱하고 끝냈는데, 페이로드가 잘려서 도착하는 경우가
읽기 → -
송금 푸시 알림 미수신을 재시도 큐로 해결
문제 상황 연락처 기반 송금 기능에서 푸시 알림이 가끔 빠지는 이슈가 보고됨. 로그 까보니 푸시 발송 자체는 호출되는데 토큰 만료/네트워크 일시 단절 같은 케이스에서 그냥 한 번 던지고 끝나는 구조였음. 받는 쪽은 돈 들어왔는지 모르고 있다가 나중에 앱 켜서 알게 되는 흐름. 송금 UX에서 꽤 치명적임. 원인 정리 기존 코드는 단발성 호출. 실패
읽기 → -
정산 메시지 19% 누락을 일으킨 발신자명 스킵 로직 수정
무의식적 스킵의 함정 메시지 파서에서 발신자명이 "No Name"이면 통째로 스킵하던 로직이 있었음. 처음 짤 때는 "이름 없는 메시지는 어차피 쓰레기"라고 단정했음. 이번에 파트너 정산 데이터를 다시 훑다가, **발신자명만 비어있고 본문에는 실제 이름·금액·계좌가 멀쩡히 들어있는 케이스**를 발견함. 원인은 단순함. 발신처 시스템마다 헤더 구성이 다
읽기 → -
입금 알림 파싱 오류와 오매칭 정산 버그 수정
또 파싱이 깨졌다 은행 앱에서 메신저 알림으로 쏴주는 입금 메시지를 받아 파트너 잔액에 반영하는 로직이 있음. 알림 포맷이 어느 날 슬쩍 바뀌면서 파싱이 통째로 실패. 입금은 들어왔는데 시스템엔 아무 일도 안 일어남. 운영팀이 수동으로 메우다 빵 터졌고, 이번에 두 개를 한꺼번에 잡았음. - 새 포맷의 줄바꿈/공백 차이로 정규식이 못 잡던 케이스 -
읽기 → -
채팅 placeholder 노이즈를 서버에서 차단해 검색 품질 개선
채팅 노이즈, 클라이언트만 막아선 안 됨 상담 채팅 로그를 훑다가 "사진을 보냈습니다", "동영상을 보냈습니다", "파일을 보냈습니다" 같은 placeholder 문자열이 그대로 검색 인덱스에 박혀 있는 걸 발견함. 클라이언트에서 미리 필터링하니 괜찮을 줄 알았는데, 외부 채팅 위젯이나 구버전 앱에서 들어오는 메시지는 서버까지 그대로 뚫고 들어왔음. 결
읽기 → -
재설치 후 통계 복원·자동 수령 깜빡임 해소·접근성 음성 안내 추가
v1.0.3 릴리즈 정리 이번 릴리즈는 세 갈래로 나뉨. 통계 동기화, 자동 수령 흐름 개선, 접근성 알림. 하나씩 정리. 서버 통계 동기화 - 그동안 로컬 카운터만 보고 화면에 그렸음. 디바이스 재설치하면 숫자가 0 으로 리셋되는 게 거슬렸음 - 이번엔 진입 시점에 서버에서 누적치를 한 번 받아오고, 이벤트 발생할 때마다 증분만 보내는 구조로 바
읽기 → -
SMS 수신 추적과 자체 점유인증으로 알림 사각지대 제거
알림 수신 통계 — 보낸 것보다 받은 게 더 중요했음 이커머스 운영하면서 결제·배송 알림을 SMS로 쏴왔는데, 그동안 로그에는 "발송했음"만 남기고 있었음. 근데 진짜 봐야 할 건 **수신자가 실제로 받았느냐**였음. 통신사 리포트랑 우리 발송 카운트가 종종 어긋났고, 파트너 CS로 "고객이 못 받았다" 컴플레인이 들어오면 추적이 어려웠음. 이번에 회
읽기 → -
관리자 화면에 알림 수신 탭·LLM 연동·통계 API 한번에 추가
오늘 관리자 화면에 알림 수신 탭을 새로 붙이고, 외부 LLM 연동 + 통계 집계 API까지 한 PR에 묶어서 밀어넣음. 세 덩어리라 부담스러웠는데, 결국 같은 운영자 워크플로우를 노리는 작업이라 쪼개는 게 더 어색했음. 알림 수신 탭 기존 관리자 화면은 거래·정산만 다뤘는데, 파트너 쪽에서 "왜 알림이 안 옴?" 문의가 늘면서 수신 이력 가시성이 필
읽기 → -
입금 매칭 라우팅 개선으로 은행 통보 미매칭 70% 복구
배경: 은행 통보 메시지 라우팅이 자꾸 어긋남 파트너 입금 매칭 파이프라인은 SMS/푸시로 들어온 은행 통보를 파싱해 은행별 핸들러로 보내는 구조임. 그런데 한 시중은행이 발신 번호 포맷을 살짝 바꿨는지, 그 시점부터 매칭률이 슬금슬금 떨어지기 시작함. 룰이 헤더 패턴 한 줄에만 의존하고 있어서, 통신사가 표기 방식을 손대거나 은행이 캠페인 문구를 끼우
읽기 → -
정산 추적 위해 원본 페이로드 저장 방식으로 전환
v1.0.2 정리 이번 릴리즈에서 세 가지를 손봤음. payload 필드 추가, 일부 보안 검사 한시 비활성화, 배포 설정 업데이트. 따로 보면 잡일인데 묶어 보면 "왜 이렇게 흘러갔는지" 가 보여서 짧게 정리. payload 필드 추가 이커머스 측 외부 알림을 수신해서 내부 큐로 넘기는 흐름이 있는데, 후속 정산 검증에서 원본 payload 전체
읽기 → -
송금 매칭 쿼리에 파트너 식별자 누락으로 인한 오정산 수정
송금 주문 매칭에서 새어나간 필터 이커머스 결제 플랫폼에서 연락처 기반 송금 기능을 만지다가 매칭 로직에 구멍 발견함. 입금 통보가 들어오면 미체결 송금 주문을 찾아 매칭하는데, 파트너 식별자를 조건에 안 넣고 있었음. 다른 파트너의 동일 금액·동일 계좌 주문이 우연히 먼저 잡히면 엉뚱한 곳으로 정산이 흘러가는 시나리오였음. 발견한 순간 등에 식은땀.
읽기 → -
관리자 OTP 재발송 폭주를 레이트 리밋으로 차단해 발송량 40% 절감
관리자 2FA 재발송 폭주 막기 관리자 로그인 흐름을 다시 들여다봤음. 진입할 때 OTP 발송하는 구간이 있는데, 사용자가 "재발송" 버튼을 연타하면 그대로 발송 API가 비례해서 호출됨. 비용도 비용이지만, 수신자 입장에서도 같은 코드가 반복으로 도착해서 어떤 게 유효한지 헷갈림. 기존 동작의 문제 - 발송 직후 즉시 재발송 가능 — 1초 안에
읽기 → -
은행 입금 동의 누락·알림 실패 건 자동 재처리로 개선
무엇을 바꿨나 은행 파트너 입금 처리 흐름에서 두 가지를 손봤음. - 개인정보 동의 처리 로직을 분리함: 기존엔 신청 폼에서 동의 체크박스만 받고 끝났는데, 은행 측 검증 시점에 동의 이력이 함께 넘어가야 정상 처리됨. 이게 안 맞아서 일부 건이 미처리로 빠지고 있었음. - 미처리 알림 재처리 큐를 추가함: 알림 전송이 실패하거나 누락된 건을 자동 재
읽기 → -
결제 송금 알림 메시지 빌더를 분리해 가독성 개선
왜 손댔나 연락처 송금 메시지 유틸이 너무 비대해졌음. 결제 플랫폼에서 파트너끼리 잔액을 옮길 때 알림 문구를 만드는 부분인데, 한 메서드 안에 분기가 켜켜이 쌓여 있었음. - 송금 성공/실패/대기/취소 4종 - 파트너 등급별 호칭 표기 차이 - 결제대행사 결과코드에 따른 문구 분기 - 다국어 금액 포맷 분기 새 메시지 한 줄 추가하려고 200라인짜
읽기 → -
연락처 송금 자동 매칭 누락으로 쌓이던 PENDING 건 해소
연락처 송금 매칭, 왜 다시 손댔나 연락처 기반 송금 흐름에서 입금자명/금액으로 자동 매칭하는 로직이 돌고 있는데, 큐에 들어온 건이 실제로 수령됐는지 확인하는 단계가 비어있었음. 매칭은 됐는데 수령 확인이 누락돼서 PENDING으로 남아있는 건들이 쌓였고, 운영팀이 손으로 정리하고 있던 상태. 원인은 두 가지였음. - 매칭 유틸이 입금 레코드 상태만
읽기 → -
파트너 정산 은행 자동화 UI 감지 로직 개선과 에러 분류
은행 자동화에서 만난 함정 파트너 정산 자동화 손볼 일이 있어서 특정 은행 웹 자동화 핸들러를 다시 깠음. 단순 셀렉터 교체겠거니 했는데, 막상 들어가보니 UI 감지 로직 자체가 깨져있었음. 문제 상황 기존 코드는 페이지 진입 후 고정 selector 하나로 "직접받기" 버튼을 찾고 있었음. 그런데 상대 사이트가 UI 를 살짝 바꾸면서 버튼이 여러 형
읽기 → -
직접받기 콜백 분기 지옥을 정규화 단계 분리로 해소
문제 상황 금융 파트너 쪽 "직접받기" 버튼 처리 로직이 누더기였음. 콜백으로 들어오는 응답 코드 케이스가 계속 늘었고, 분기가 6단 깊이까지 박혀 있었음. 새 케이스 하나 붙이려면 어느 가지에 끼워야 할지 5분씩 노려보고 있어야 했음. 무엇이 꼬여 있었나 - 외부 응답 상태와 내부 판정 결과가 같은 변수에 섞여 흘러다님 - 성공/실패 분기가 try
읽기 → -
입금 매칭 우선순위 정리로 결제 연동 모듈 구조 개선
무엇을 손봤나 특정 은행 입금 연동 모듈을 정리했음. 기존 코드는 UI 렌더링, 입금 콜백 파싱, 잔액 갱신이 한 클래스에 다 들어있어서 손대기 무서운 상태였음. 한 줄 바꾸면 어디서 터질지 모르는 전형적인 레거시. 이번엔 두 갈래로 쪼갰음. - **표시 레이어**: 파트너 화면에서 보여주는 입금 안내 / 계좌 표기 부분 - **처리 레이어**: 결
읽기 →