-
입금자명 파싱 다단계 분류와 정산 계좌 조회 엔드포인트 분리
입금자명 파싱, 정규식 한 줄로는 안 됨 문자 메시지에서 입금자명 뽑는 로직 손봤음. 처음엔 정규식 한 줄로 끝낼 수 있을 줄 알았는데, 실제 데이터 까보니 케이스가 너무 많았음. - 은행마다 메시지 포맷이 다름 (콜론 위치, 줄바꿈, 특수문자) - 영문/한글 이름 혼합 - 법인명 뒤에 담당자명 붙는 케이스 ((주)○○ 홍길동) - 광고 문구가 본문에
읽기 → -
파트너 입금 정산 자동화로 야간 누락 제로 달성
왜 자동화했나 파트너 입금 확인을 매번 손으로 처리하다 보니 누락이 생김. 메신저로 알림 와서 → 사람이 브라우저 열고 → 링크 타고 들어가서 → 내용 확인 → 다시 내부 시스템에 등록하는 패턴이 반복됐는데, 야간엔 처리가 늦어져서 정산이 밀림. "이거 왜 사람이 함?" 싶어서 파이프라인으로 묶음. 처리 흐름 | 단계 | 주체 | 역할 | |---
읽기 → -
송금 URL로 은행 자동 판별하는 구조 짜기
캡처된 송금 URL을 어떻게 받을지 고민함 스마트폰에서 연락처 송금을 누르면 은행 앱이 뜨는 게 일반적인데, 우리는 한 칸 앞에 끼어들어야 했음. 사용자가 송금 직전에 URL을 캡처해 넘겨주면, 그걸 보고 어느 은행인지 판별하고 후속 흐름을 잇는 구조. 문제는 은행마다 URL 포맷이 제각각이라는 점. 은행 판별을 어떻게 짰나 처음엔 정규식 한 줄
읽기 → -
쿠폰 매입 신청·정산 흐름을 상태머신으로 안정화
쿠폰 매입 신청 관리, 왜 필요했나 이커머스 파트너 정산 흐름에서 발행된 쿠폰 중 안 팔린 잔량을 다시 사들이는 절차가 필요했음. 기존엔 발행 이력만 시스템에 있었고 매입은 메일+엑셀로 수기 처리 중이었음. 운영팀이 월별 분량 늘면서 누락·중복 신청 사고 두 건 터지고 나서야 짬이 남. 설계 핵심 세 흐름으로 분리함: - 매입 신청 접수 (파트너
읽기 → -
결제 알림 오프라인 유실 없애고 자동수령 안정화
시작 오늘은 메신저 자동수령 안정화 작업을 한 바퀴 돌렸음. 단말에서 결제 알림을 잡아 백엔드로 흘려보내는 모듈인데, 네트워크 끊겼을 때 알림이 통째로 사라지는 게 오래된 골칫거리였음. 한 방에 잡으려고 세 갈래로 손댔음. 오프라인 큐잉 기존엔 알림 받자마자 바로 HTTP 호출. 지하철/엘리베이터에서 끊기면 그대로 소실됐음. 로컬 DB에 1차 적재
읽기 → -
정지 파트너 결제 메시지를 컨트롤러 입구에서 즉시 차단
정지 파트너인데 메시지가 계속 들어옴 이커머스 결제 플랫폼에서 파트너를 정지시켰는데, 결제대행사 쪽 모니터링 메시지가 계속 들어오는 문제가 발견됨. 정지 사유가 사기 의심이든 계약 해지든, 일단 정지 걸린 시점부터는 어떤 입금/결제 이벤트도 우리 시스템 안쪽으로 흘러들면 안 됐음. 문제는 컨트롤러에서 메시지를 받자마자 파싱 → 매칭 → 잔액 반영까지
읽기 → -
입금 큐 성공 후 주문 매칭이 자동으로 안 되던 문제 해결
큐가 끝났는데 주문은 안 잡히던 문제 큐 처리 결과가 SUCCESS로 떨어지는데, 정작 주문 매칭은 자동으로 안 돌던 케이스를 잡음. 결제대행사에서 입금 통지가 온 뒤 큐가 멀쩡히 처리되고 SUCCESS 상태까지 도달했는데, 그 다음 단계인 "어떤 주문에 이 입금을 붙일지" 매칭이 별도 스케줄러나 수동 호출에 의존하던 구조였음. 증상 - 입금 통지
읽기 → -
연락처 송금 결제수단 추가로 콜백과 매칭 로직 전면 재작성
연락처 송금이 결제수단으로 들어왔을 때 이커머스 결제 흐름에 새 결제수단이 하나 끼어들었음. 기존 카드/가상계좌/포인트 옆에 "연락처 송금"이 들어오는 작업. 처음엔 단순히 결제수단 enum 하나 늘리는 줄 알았는데, 까보니 매칭 로직이 본체였음. 매칭이 진짜 일이었음 연락처 기반이라 "보낸 사람 번호"와 "받을 사람 번호"가 정확히 매핑돼야 함
읽기 → -
결제 승인 거짓 성공으로 인한 정산 오류 수정
거짓 성공(false SUCCESS) 한 건이 부른 사고 결제대행사 두 곳의 응답 핸들러에서 **승인 실패인데 SUCCESS 로 찍히는 케이스**를 잡았음. 정산 다음 날 파트너 잔액이 비어있다는 문의로 발견. 회고 정리. 무엇이 문제였나 핸들러가 결제대행사의 raw 응답을 파싱할 때, 일부 에러 케이스에서 결과 코드가 비어 들어옴. 비어있으면 디
읽기 → -
연락처이체 자동화 오류 13건을 조건 대기와 이중 검증으로 해결
13개가 한꺼번에 터졌다 연락처이체 웹 자동화가 또 깨졌음. 은행별 페이지 구조가 미묘하게 달라서 한 곳 고치면 다른 데서 터지는 두더지잡기. 이번엔 분산해서 잡지 말고 13개 케이스 한꺼번에 모아서 정리함. 증상은 비슷했음: - "이체 성공"으로 찍혔는데 실제 거래는 미체결 - 페이지 전환 도중 다음 step 클릭해서 element not found
읽기 → -
은행별 입금 감시 오류 분류와 멱등성으로 이중 처리 방지
입금 감시 로직, 은행마다 다르게 터지는 게 문제였음 여러 은행 핸들러에서 입금 완료 감시 로직이 들쭉날쭉이라 정리한 회고. 같은 "입금 확인"인데 은행별로 응답 포맷, 타임아웃 패턴, 에러코드가 다 달라서 분기마다 한 번씩 장애가 났음. 무엇이 문제였나 기존 구조는 각 은행 핸들러가 자기 방식대로 예외를 던지고, 상위 스케줄러는 그걸 단순히 ca
읽기 → -
송금 수취인 계좌 오매칭을 파트너 식별자 조회로 해결
파트너 식별자 기반 계좌 조회로 갈아탄 이유 연락처 송금 흐름 손볼 때 가장 거슬렸던 게 수취인 계좌 매칭 로직임. 기존엔 입력값(연락처 + 이름) 조합으로 계좌를 끌어왔는데, 동명이인이거나 같은 번호를 공유하는 파트너가 끼면 엉뚱한 잔액 계좌로 꽂힐 위험이 있었음. 이번에 파트너 식별자(partnerSn)를 1차 키로 잡고 계좌를 조회하도록 갈아엎음.
읽기 → -
로그인 사용자 기반 상품 필터링 기능 추가
feat: 로그인 사용자 id 기반 상품 필터링 로직 추가 기능 구현.
읽기 → -
쿠폰 허용 결제수단 표시
feat: 쿠폰 허용 결제수단 표시 및 토글 UI 개선 기능 구현.
읽기 → -
JSP 뷰 기능 플래그 Boolean 조건 분기 오류 수정
fix: featureMap Boolean 타입 비교 오류 수정 (== 1 제거) — 버그 픽스.
읽기 → -
계좌 인증과 포인트 충전 페이지 신규 추가
feat: 계좌 인증 및 포인트 충전 페이지 추가 기능 구현.
읽기 → -
SLECS 로고를 WEAVERKIT으로 교체
fix: SLECS 로고 WEAVERKIT으로 변경 — 버그 픽스.
읽기 → -
결제 모니터 뷰 레이어 알림 중복 제거
refactor: /Users/slecs/dev/source/pay-monitor/app/build/outputs/apk/debug/ alert/Toast 중복 제거 및 SLECS.Modal.alert로 통합 리팩토링.
읽기 → -
Android 앱 아이콘이 PNG로 올바르게 표시되도록 수정
fix: mipmap-anydpi-v26 제거하여 PNG 아이콘 적용 — Android 앱 변경 커밋.
읽기 → -
금융 알림 수신 Android 앱 리브랜딩
앱 리브랜딩: SMS모니터링 + 아이콘 변경 + v1.0.0 — Android 앱 변경 커밋.
읽기 →