#test
-
출금 검증 로직 추가
20260329 withdraw verification 2026-03-29에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 - SQL 쿼리 작성 및
읽기 → -
머천트 잔액 조회 화면 QA
20260329 0130 merchant balance qa 2026-03-29에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 - SQL 쿼리 작성
읽기 → -
파트너 신청 기능 운영 안정성 개선
20260329 0010 partner-apply-fix 2026-03-29에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 - SQL 쿼리 작성 및
읽기 → -
판매자 잔액 조회 기능 추가
20260329 0045 merchant balance feature 2026-03-28에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 - SQL
읽기 → -
파트너 주문 입금 처리 안정성 개선
20260328 1925 partner-order-deposit-upgrade 2026-03-28에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 -
읽기 → -
계층형 수수료 차액 분배 로직과 정산 검증 강화
계층형 차액 분배 로직 추가 및 수수료율 관리 개선 2026-03-27에 수수료 계산 또는 정산 관련 로직을 작업했음. 수수료 구조는 유통 계층별로 요율이 다르게 설정되는 차등 모델임. 하위 계층이 상위 계층보다 높은 요율을 부담하고, 그 차액이 상위 계층의 수익이 되는 구조임. 수수료 계층 예시 | 계층 | 요율 | 비고 | |---|---|-
읽기 → -
셀렉터 자가학습 버그 수정과 Rate Limit
셀렉터 자가학습 Codex 검증 피드백 반영 2026-03-25에 버그를 수정했음. 수정 대상 파일: 내부 클래스 작은 수정처럼 보여도 운영 중 발생하는 문제들은 빠르게 잡는 게 중요함. 이번 수정도 재현 → 원인 파악 → 최소 범위 수정 → 배포 순서로 처리했음. 자주 나오는 버그 패턴 | 패턴 | 증상 | |---|---| | null 체크
읽기 → -
연락처 송금 핸들러 자가학습
연락처 송금 비즈니스 로직 동기화 (404_pjt → pg-solution) 2026-03-25에 연락처 송금 관련 기능을 추가하거나 개선했음. 연락처 송금 흐름은 대략 이렇게 됨: 입금 알림 수신 (Android 앱) → 서버로 원본 메시지 전송 → 주문 매칭 (금액 + 발신자 + 시간) → 은행 핸들러 실행 (Playwright)
읽기 → -
크롤링 차단 자동화와 브라우저 풀 타임아웃 안정성 개선
Playwright 안정성 개선 (page.close + semaphore 타임아웃) 2026-03-25에 버그를 수정했음. 수정 대상 파일: PlaywrightBrowserPool.java, 내부 클래스 작은 수정처럼 보여도 운영 중 발생하는 문제들은 빠르게 잡는 게 중요함. 이번 수정도 재현 → 원인 파악 → 최소 범위 수정 → 배포 순서로 처리
읽기 → -
QR 스캔으로 파트너 친구추가·송금 연결 구현
파트너 QR 친구추가 기능 만들기 이커머스 결제 플랫폼에서 파트너끼리 서로를 빠르게 등록하고 곧장 송금 화면까지 연결되는 흐름이 필요했음. 기존엔 파트너 식별값 입력 → 검색 → 등록 3단계라 모바일에서 손이 많이 갔음. QR 한 번 찍으면 끝나도록 갈아엎음. 화면 흐름 - 내정보 페이지에서 본인 식별값을 인코딩한 QR 노출 - 상대 파트너가 카메라
읽기 → -
정산 추적 위해 원본 페이로드 저장 방식으로 전환
v1.0.2 정리 이번 릴리즈에서 세 가지를 손봤음. payload 필드 추가, 일부 보안 검사 한시 비활성화, 배포 설정 업데이트. 따로 보면 잡일인데 묶어 보면 "왜 이렇게 흘러갔는지" 가 보여서 짧게 정리. payload 필드 추가 이커머스 측 외부 알림을 수신해서 내부 큐로 넘기는 흐름이 있는데, 후속 정산 검증에서 원본 payload 전체
읽기 → -
결제 송금 알림 메시지 빌더를 분리해 가독성 개선
왜 손댔나 연락처 송금 메시지 유틸이 너무 비대해졌음. 결제 플랫폼에서 파트너끼리 잔액을 옮길 때 알림 문구를 만드는 부분인데, 한 메서드 안에 분기가 켜켜이 쌓여 있었음. - 송금 성공/실패/대기/취소 4종 - 파트너 등급별 호칭 표기 차이 - 결제대행사 결과코드에 따른 문구 분기 - 다국어 금액 포맷 분기 새 메시지 한 줄 추가하려고 200라인짜
읽기 → -
결제 매칭과 파트너 귀속 로직을 단계별로 분리해 동명이인 버그 해결
시작점 주문 매칭과 파트너 결정 로직이 한 유틸 안에 뒤엉켜 있었음. 입금 들어오면 어떤 주문에 매칭할지, 그 주문이 어떤 파트너 소속인지, 수수료를 누가 부담하는지 한 메서드 안에서 다 처리했음. 이번 리팩토링은 이걸 떼어내는 작업. 기존 흐름에서 가장 골치 아팠던 부분: - 매칭 후보가 여러 개일 때 우선순위 결정 분기가 6단계 넘게 중첩 - 파
읽기 → -
무통장 입금 미매칭을 주문번호 기준으로 자동 보정
배경 무통장 입금 매칭에서 파트너를 잘못 잡거나 계좌 정보가 비어있는 케이스가 누적됨. 운영팀이 손으로 일일이 보정하던 흐름을 주문 데이터 기준으로 자동화함. 결제 플랫폼 쪽 미매칭 건이 월말마다 쌓여서 더 미룰 수 없었음. 무엇을 바꿨나 - 주문번호를 키로 파트너 ID 역추적 - 입금자명·금액 일치 외에 주문 메타데이터로 보강 - 관리자 화면에서 미
읽기 → -
결제 웹훅 중복 수신 막고 정산 추적 로그 정비
웹훅 개선하면서 깨달은 것 결제대행사 쪽에서 들어오는 웹훅이 가끔 누락되거나 중복으로 찍히는 이슈가 있었음. 처음엔 "재시도 정책이려니" 하고 넘겼는데, 정산 데이터 검수하다가 같은 거래에 대해 콜백이 3번 들어온 케이스를 발견했음. 더는 못 미루겠다 싶어서 손댐. 무엇을 바꿨나 핵심은 두 가지. **웹훅 수신부 자체의 멱등성 보장**과 **로그를
읽기 → -
가맹점 계좌 승인 알림 누락과 사이드바 메뉴 미노출 수정
계좌 승인 알림이 사라진 이유 파트너 포탈에서 신규 가맹점 계좌 등록 후 관리자 승인 알림이 안 떴음. 가맹점은 등록했다고 알고 있는데 정작 관리자는 모름. 결과적으로 "왜 며칠째 승인이 안 나냐"는 문의가 누적됨. 원인은 두 군데였음. - 관리자 컨트롤러에서 알림 큐 적재 로직이 빠져있었음 (예전 리팩터링 때 누락 추정) - 파트너 포탈 사이드바에서
읽기 → -
이커머스 파트너 가입 시 중복확인과 SMS 인증을 단일 동선으로 통합
사업자 회원가입 플로우 정리 이커머스 파트너 회원가입 화면을 손봤음. 기존엔 휴대폰 입력란 옆에 "중복확인" 버튼이 따로 있고, 그 아래 SMS 인증 영역이 또 따로 있었음. 사용자가 두 번 눌러야 가입 진행이 됐고, 동선이 꼬여서 이탈이 많이 났음. 무엇이 문제였나 - 중복확인 통과 후 SMS 인증 단계로 안 넘어가는 케이스가 많았음 - 중복확인
읽기 → -
결제 기능 토글 엣지 케이스 보강으로 배치 잡 차단 해소
배경 이커머스 결제 플랫폼에서 기능 토글 관련 두 컴포넌트(코드 해석기 / 활성 판별기)가 엣지 케이스를 못 잡고 있었음. 파트너별로 활성 정책이 다르고, 한 곳에서 기능 코드를 해석한 뒤 다른 곳이 활성 여부를 판별하는 2단계 구조라 둘 다 보강 필요했음. 어떤 문제였나 - 해석기 쪽은 입력이 null/공백이면 그냥 false 반환. 호출부에서는
읽기 → -
결제 수수료 정산을 지연 차감 방식으로 전환해 환불 흐름 단순화
배경 결제 플랫폼에서 파트너에게 부과되는 수수료를 결제 즉시 차감하는 기존 로직이 있었음. 문제는 이커머스 특성상 결제 후에도 환불/취소가 빈번하게 일어난다는 점. 즉시 차감해버리면 환불이 들어왔을 때 수수료를 다시 환원해야 하는데, 이 역방향 흐름이 곳곳에서 깨지고 있었음. 흐름 재설계 결제대행사에서 정산 데이터가 넘어오는 시점을 기준으로 상태를
읽기 → -
충전 수수료를 충전 트랜잭션 단위로 매칭해 회계 역추적 해결
충전 수수료 차감, 어느 시점 요율을 따라야 하나 결제 플랫폼에서 파트너가 잔액을 충전할 때 충전 수수료를 떼는 구조인데, 환불·취소 흐름에서 차감 기준이 애매했음. 충전 시점 요율을 박아두는 방식이었는데, 파트너 등급이 중간에 바뀌면 과거 충전건과 현재 차감액이 어긋남. 회계팀에서 "이 충전건이 그 차감인지 매칭이 안 된다"는 컴플레인이 들어와서 손을
읽기 →