#sql
-
연락처 송금 계좌 로테이션·비회원 주문 매칭 버그 수정
연락처송금 계좌 로테이션 순서 수정 및 주문 매칭 PENDING 추가 2026-03-27에 연락처 송금 기능의 버그를 수정했음. 연락처 송금은 은행 앱 화면을 자동으로 조작해서 입금 처리를 완료하는 구조임. 각 은행별로 UI가 다르기 때문에 은행별 핸들러가 개별로 존재하고, Playwright로 브라우저를 제어함. 수정 포인트 - 은행 셀렉터 감
읽기 → -
결제 알림 앱 Android 호환성
APK 관리 로직 및 다운로드 기능 추가 Android 앱(최신버전) 관련 작업을 진행했음. 결제 알림 수신·처리용 앱인데, 알림 캡처 → 파싱 → 서버 전송 흐름으로 동작함. 이번 작업에서는 안정성과 Android 버전 호환성을 중점적으로 개선했음. 주요 변경 | 항목 | 내용 | |---|---| | Android 14/15 대응 | Medi
읽기 → -
연락처 송금 파싱 재시도·매칭 누락 버그 수정
연락처 송금 파싱 실패 재시도 sysId 필터 추가 2026-03-25에 연락처 송금 기능의 버그를 수정했음. 연락처 송금은 은행 앱 화면을 자동으로 조작해서 입금 처리를 완료하는 구조임. 각 은행별로 UI가 다르기 때문에 은행별 핸들러가 개별로 존재하고, Playwright로 브라우저를 제어함. 수정 포인트 - 은행 셀렉터 감지 로직 오류 -
읽기 → -
연락처 입금 상세에 주문·핀코드·입금 로그 매칭 추가
연락처 입금 상세에 매칭 주문/핀코드/입금 로그 추가 2026-03-25에 연락처 송금 관련 기능을 추가하거나 개선했음. 연락처 송금 흐름은 대략 이렇게 됨: 입금 알림 수신 (Android 앱) → 서버로 원본 메시지 전송 → 주문 매칭 (금액 + 발신자 + 시간) → 은행 핸들러 실행 (Playwright) → 로그인 → 수취
읽기 → -
계층별 수수료 정산 로직 검증 강화
일일 정산 Discord Embed 리포트 발송 2026-03-25에 수수료 계산 또는 정산 관련 로직을 작업했음. 수수료 구조는 유통 계층별로 요율이 다르게 설정되는 차등 모델임. 하위 계층이 상위 계층보다 높은 요율을 부담하고, 그 차액이 상위 계층의 수익이 되는 구조임. 수수료 계층 예시 | 계층 | 요율 | 비고 | |---|---|---
읽기 → -
수수료 정산 1원 오차, 반올림 정책 통일로 해결
수수료 계산이 또 1원씩 어긋남 수수료 정산 결과가 가맹점별로 1~3원씩 어긋난다는 신고가 또 올라옴. 횟수가 누적돼서 더는 미룰 수 없었음. 원인 파보니 단순 버그가 아니라 구조 문제였음. 원인: scale 제각각 BigDecimal scale이 레이어마다 다르게 박혀있었음. 중간에서 반올림이 두 번 일어나는 구조라 끝자리가 흔들림. | 레이어
읽기 → -
인터넷 은행 수동수령 건에 송금 상태와 파트너 푸시 알림 추가
배경 - 일부 인터넷 은행 계좌로 보낸 송금 건이 자동 수령이 안 되는 케이스가 누적됨 - 파트너가 앱에서 직접 받기 버튼을 눌러야 처리되는데, 시스템이 그 상태를 따로 인식 못 하고 있었음 - 입금 큐는 줄곧 SUCCESS/FAIL 이분법이라 "수동 개입 필요"가 끼어들 자리가 없었음 무엇을 고쳤는가 | 단계 | 이전 | 이후 | |---|---|
읽기 → -
관리자 화면에 알림 수신 탭·LLM 연동·통계 API 한번에 추가
오늘 관리자 화면에 알림 수신 탭을 새로 붙이고, 외부 LLM 연동 + 통계 집계 API까지 한 PR에 묶어서 밀어넣음. 세 덩어리라 부담스러웠는데, 결국 같은 운영자 워크플로우를 노리는 작업이라 쪼개는 게 더 어색했음. 알림 수신 탭 기존 관리자 화면은 거래·정산만 다뤘는데, 파트너 쪽에서 "왜 알림이 안 옴?" 문의가 늘면서 수신 이력 가시성이 필
읽기 → -
정산 주문 매칭 로직을 변경 축 기준으로 분리해 누락 추적 속도를 높임
매칭 로직을 다시 봐야 했던 이유 파트너별 정산 화면에서 주문 누락이 보고됐음. 입금 데이터를 받아 주문과 매칭하고, 그 결과로 파트너를 결정한 뒤 계좌를 조회하는 흐름인데, 단계마다 책임이 섞여 있어서 어느 단계에서 어긋난 건지 추적이 오래 걸림. 기존 컨트롤러는 다음을 한꺼번에 하고 있었음: - 입금 식별자 파싱 - 주문 후보 조회 - 매칭 우선
읽기 → -
파트너 송금 조회 쿼리 리팩터링으로 응답 속도 5배 개선
무엇을 줄였나 파트너 송금 조회 쿼리가 길었음. 같은 조인을 세 번 반복하고 인라인 뷰도 두 개나 끼어 있었음. 화면 하나에 결과 보여주는 게 전부인데 실행계획 떠보면 풀스캔이 두 번 찍혀서 손봐야 했음. 원본 구조를 거칠게 정리하면 이랬음: - 송금 본 테이블 + 파트너 정보 조인 - 같은 조건으로 수수료 합계 뽑는 서브쿼리 - 환불 차감용 또 다른
읽기 → -
파트너 대시보드에 송금·주문 통계 위젯 추가
파트너 대시보드에 송금·주문 통계 붙이기 기존 파트너 대시보드는 결제 흐름 위주로만 정보를 뿌려줬음. 그러다 보니 파트너가 송금 내역이나 주문 추이를 보려면 메뉴를 두세 번 더 타고 들어가야 했고, "한 화면에서 다 보고 싶다"는 피드백이 누적돼 있었음. 이번 작업으로 두 가지를 한 위젯 영역에 묶었음. - 연락처 송금 통계: 일/주/월 단위 송금
읽기 → -
결제 플랫폼에 근태관리 모듈 추가하고 메뉴얼 자동 생성 도입
배경 이커머스 결제 플랫폼에 근태관리 SaaS 모듈을 끼워 넣는 작업 시작. 파트너들이 "정산도 여기서 보는데 직원 출퇴근까지 한 화면에서 보면 안 되냐"라고 계속 요청해서 결국 사이드 모듈로 붙이기로 결정함. 테이블 구조 근태 도메인은 본업이 아니라서 최소한으로 잘랐음. 일단 5개만 만듬. | 테이블 | 용도 | | --- | --- | | 직
읽기 → -
정산 유니크 제약 누락으로 중복 적재되던 문제 수정
dump.rdb 가 또 올라왔음 로컬에서 캐시 띄워놓고 작업하다 보면 워킹 디렉토리에 dump.rdb 가 슬쩍 생김. 평소엔 잘 피해다녔는데 다른 변경이랑 같이 add 되면서 한번 커밋에 따라 들어간 적이 있었음. 수십 MB 바이너리가 히스토리에 박히면 클론할 때마다 짜증나고, 무엇보다 캐시 스냅샷에 뭐가 들었는지 모르니 보안적으로도 찜찜함. 그래서
읽기 → -
파트너 정산 이중 차감과 화면별 잔액 오차 수정
정산 중복 처리, 또 너냐 파트너 정산 화면에서 같은 건이 두 번 차감되는 이슈. 결제 플랫폼 쪽에선 흔한 패턴이긴 한데, 이번엔 정산·대시보드·파트너 어드민·파트너 화면 컨트롤러 4개를 동시에 손봐야 했음. 한 곳만 고치면 다른 화면에서 다시 어긋나서, 결국 합계 산식을 원장 수준에서 한 번에 정리함. 무엇이 문제였나 - 충전 수수료, 결제 수수
읽기 → -
파트너 정산 계좌 다건 등록과 승인 플로우 구축
파트너 계좌 다건 관리 작업 회고 기존엔 파트너 1명당 정산 계좌가 1개만 등록 가능한 구조였음. 그런데 운영 들어가보니 사업자 명의 분리, 분점 정산, 세무 분리 등 사유로 계좌를 여러 개 굴리고 싶어하는 파트너가 적지 않았음. 그래서 다건 등록 + 관리자 승인 플로우를 한 사이클에 묶어서 작업함. 데이터 모델 정리 기존 단일 컬럼 구조를 그대로
읽기 → -
결제대행사 연동 제거로 충전 로직 버그까지 발견 정리
결제대행사 연동 삭제와 충전 로직 손질 오늘 작업은 두 갈래였음. 더 이상 트래픽이 들어오지 않는 결제대행사 연동을 들어내는 것, 그리고 충전 흐름에 쌓여있던 잔버그를 정리하는 것. 왜 들어냈는가 - 해당 결제대행사로 유입되는 트래픽이 사실상 0에 수렴 - 그런데 유지보수 비용은 그대로 발생 (콜백 검증, 환불 분기, 예외 처리) - 다른 결제대행
읽기 → -
충전 수수료를 충전 트랜잭션 단위로 매칭해 회계 역추적 해결
충전 수수료 차감, 어느 시점 요율을 따라야 하나 결제 플랫폼에서 파트너가 잔액을 충전할 때 충전 수수료를 떼는 구조인데, 환불·취소 흐름에서 차감 기준이 애매했음. 충전 시점 요율을 박아두는 방식이었는데, 파트너 등급이 중간에 바뀌면 과거 충전건과 현재 차감액이 어긋남. 회계팀에서 "이 충전건이 그 차감인지 매칭이 안 된다"는 컴플레인이 들어와서 손을
읽기 → -
결제 수단 추가로 드러난 정산 쿼리 누락과 분기 구조 개선
새 결제 수단 붙이기 이커머스에서 결제대행사 한 곳을 추가함. 기존엔 카드/가상계좌만 받던 흐름에 새 수단이 끼어들면서, 결제 요청 분기에서 슬슬 균열이 보이기 시작함. 처음엔 그냥 if 한 줄 더 넣고 끝날 줄 알았는데, 실제로 붙여보니 응답 콜백 포맷이 달라서 파싱 단계부터 다시 짜야 했음. 단순 추가가 아니라 "이미 너무 비대해진 분기"를 건드리
읽기 → -
입금 웹훅 구조를 레지스트리 패턴으로 전환해 은행 추가 용이성 개선
배경 연락처 송금 기능에 입금 통보 받을 은행이 한 곳 더 늘어남. 기존엔 진입 컨트롤러에서 은행 코드별 if-else로 분기하던 구조라 추가할 때마다 같은 파일을 또 건드려야 했음. 이번에 인터넷전문은행 한 곳 더 붙이라는 요청 받았는데, 같은 자리를 또 손대기 싫어서 레지스트리 패턴으로 갈아엎기로 함. 무엇을 바꿨나 - 결제대행사 웹훅 수신 진입점
읽기 → -
결제대행사 회원 동기화를 비동기 큐로 전환해 정산 누락 해소
발단 이커머스 결제대행사 연동 작업 중 회원 정보 동기화 스펙 추가 요청 받았음. 신규 가입 시 결제대행사 쪽에 우리 회원 식별값을 함께 넘겨야 환불·정산 매칭이 깔끔해진다는 운영팀 피드백 때문이었음. 기존엔 결제 시점에 임시로 끼워 넣고 있어서 매칭 누락이 가끔 터졌음. 무엇을 추가했는가 가입/수정 흐름에 정식 필드를 박고, 변경 이벤트를 외부로
읽기 →