#test
-
결제 정산 감사 로직의 멱등성
system-ledger 버그를 수정했음. (C) 백필 시드 명확화 + audit 멱등성 보강. 변경 파일: 내부 클래스 3개, SQL 매퍼 1개, SQL 파일 1개 문제 원인 기존 로직에서 엣지 케이스가 처리되지 않아 특정 상황에서 잘못된 결과를 반환하거나 오류가 발생하고 있었음. 수정 내용 - SQL 쿼리 조건/집계 수정 - 내부 클래스 로직
읽기 → -
정산 출금 가능 금액 산식 개선과 명세 투명화
결제 플랫폼의 정산 시스템에서 가맹점이 실제로 출금할 수 있는 금액을 계산하는 로직을 손봤다. "확정 출금 가능" 필드의 산식을 개선하고, UI에 세부 라인을 추가해서 투명성을 높이는 작업이었다. 정산 금액 산식, 왜 다시 봤나 이커머스 정산 시스템에서 가맹점이 언제 돈을 빼갈 수 있는지는 매우 예민한 부분이다. 단순히 "매출액 - 수수료"가 아니라,
읽기 → -
비회원 파트너 영수증 자동생성
pay/receipt 영역에 새 기능을 추가했음. 비회원 파트너 발급 영수증 자동생성 보강 + 과거건 백필. 변경 파일: 내부 클래스 2개, SQL 매퍼 2개, SQL 파일 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현 내용 - 영
읽기 → -
매출 대시보드에서 머천트 라이브 카드를 상단으로 복귀
매출 관리 대시보드의 머천트 카드 표시 방식을 다시 손봤다. 라이브 데이터를 메인으로 돌려놓는 작은 변경이지만, 운영 관점에서 꽤 의미 있는 결정이었다. 왜 이런 변경이 필요했나 결제 플랫폼 같은 시스템을 운영하다 보면, 머천트별 매출 현황을 실시간으로 파악해야 한다. 특히 관리자가 보는 시스템 전체 수익 요약(total-summary) 페이지에서는
읽기 → -
결제 수단 변경 이력 감사 로직 구현과 설계 고민
결제 주문의 결제 수단 변경을 감시하고 기록하는 감사 로직을 구현했다. 외부 영향이 크거나 민감한 부분인 만큼 어떤 배경과 고민이 있었는지 정리해본다. 결제 수단 변경, 왜 감시하는가 주문이 생성된 후 최종 결제 전까지 결제 수단이 변경되는 시나리오는 생각보다 자주 일어난다. 사용자가 마음을 바꿔서 카드를 바꾸거나, 결제 실패 후 다른 수단으로 재시도
읽기 → -
결제 플랫폼 관리자 로그인·2FA 화면 데이터 정합성 확보
admin-login 영역에 새 기능을 추가했음. 이커머스 PG 플랫폼 SaaS 톤 로그인 + 2FA 페이지 리디자인. 변경 파일: 뷰/스타일 2개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현 내용 - 관련 내부 클래스에 메서드 추가
읽기 → -
가맹점 출금 목록 정합성 분석 보고서 작성
분석 보고서를 작성했음. 주제: **20260427 1430 merchant withdrawal list**. 분석 배경 운영 중 특정 수치 불일치 혹은 잠재적 문제가 감지됐음. 단순 로그 확인으로는 전체 그림이 안 보여서 SQL로 직접 집계하고 결과를 HTML 보고서로 정리했음. 이런 보고서를 만드는 이유는 문제를 코드 수정으로 넘기기 전에 원인을
읽기 → -
결제 도메인 신규 기능을 쿼리부터 화면까지 정합성 있게 구현
responsive-ui 영역에 새 기능을 추가했음. 모바일 해상도 대응 CSS 추가 및 스타일 조정. 변경 파일: 뷰/스타일 6개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현 내용 - 관련 내부 클래스에 메서드 추가 - SQL 매퍼에
읽기 → -
Discord 등급 명령에 자동 원복과 결제 동기화 추가
Discord 봇 기능 작업. Discord /등급 명령 + 10분 자동 원복 + 결제대행사 동기화. 배경 Discord를 내부 운영 도구로 활용 중. 슬래시 커맨드로 특정 동작을 트리거하거나, 시스템 이벤트를 채널에 알림으로 보내는 용도. 개발팀 채널에 커밋/배포 알림을 자동으로 보내면 별도로 공유하는 수고를 덜 수 있음. 구현 내용 - /등급
읽기 → -
파트너 포털 갭 상세 모달에 미확인 정산 내역 누락 수정
partner-portal 버그를 수정했음. 갭 detail 모달에 PENDING_CONFIRM audit 행 노출. 변경 파일: SQL 매퍼 1개 문제 원인 기존 로직에서 엣지 케이스가 처리되지 않아 특정 상황에서 잘못된 결과를 반환하거나 오류가 발생하고 있었음. 수정 내용 - SQL 쿼리 조건/집계 수정 버그 수정 프로세스 단순히 증상만
읽기 → -
파트너 포탈에 결제 도메인 신규 기능 추가
partner-portal 영역에 새 기능을 추가했음. 대시보드 KPI 카드 가독성 개선 (폰트 대형화 + 정렬). 변경 파일: 뷰/스타일 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현 내용 - 포탈에 신규 메뉴/기능 추가 - 백엔
읽기 → -
파트너 포탈에 공급사 브랜드·상품 업로드·KPI 대시보드 기능 추가
partner-portal 영역에 새 기능을 추가했음. 공급사 브랜드 관리 + 상품 업로드 UX + 대시보드 KPI 확장. 변경 파일: 내부 클래스 4개, SQL 파일 1개, SQL 매퍼 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현
읽기 → -
거래명세서 정산 자동 발송과 충전·결제·수수료 통합 이력 추가
settlement-statement 영역에 새 기능을 추가했음. 거래명세서 메일 본문 충전/결제/수수료 3분류 통합 + 자동 발송 배치 + 발송 이력 화면. 변경 파일: 내부 클래스 5개, SQL 파일 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을
읽기 → -
전자계약서 알림 기능 전면 개편과 결제 데이터 정합성 확보
partner-contract 영역에 새 기능을 추가했음. 전자계약서 알림 이메일 HTML 템플릿 개편. 변경 파일: 내부 클래스 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현 내용 - 알림 생성 트리거 포인트 추가 - 뱃지 카운트
읽기 → -
순이익 공식 오류 수정
순이익 공식 수정 + 출금 자동승인 실패 시 잔액 복구 순이익 공식 수정 + 출금 자동승인 실패 시 잔액 복구 버그를 수정했음. 원인 분석 순이익 계산 공식이 실제 비즈니스 정의와 달랐음. 특정 항목이 빠지거나 잘못 포함됐음. 재현 조건 대시보드 순이익 카드의 값이 실제 계산과 달랐음. 수정 내용 java // 수정 전: 잘못된 공식 l
읽기 → -
시스템 파트너 롤백 SQL 추가로 운영 원복 즉시 대응
시스템 파트너 롤백 SQL 추가 (운영 반영 대기) 유지보수 및 정리 작업을 했음. 배경 기능 개발에 집중하다 보면 불필요한 코드, 오래된 설정, 중복 파일이 쌓임. 이런 기술 부채는 당장은 문제가 없어 보여도 점점 코드베이스를 읽기 어렵게 만듦. 작업 내용 - 운영 SQL 패치 파일 관리 - 롤백 SQL을 함께 작성해두어 문제 발생 시 즉시
읽기 → -
플랫폼 순귀속 정산에 레거시 타입 포함되던 집계 오류 수정
플랫폼 순귀속 계산에 레거시 COMMISSION_DISTRIBUTION 타입 포함 플랫폼 순귀속 계산에 레거시 COMMISSION_DISTRIBUTION 타입 포함 버그를 수정했음. 원인 분석 구 데이터 타입(COMMISSION_DISTRIBUTION 등)이 집계 쿼리에 포함되면서 현재 기준과 다른 결과가 나왔음. 재현 조건 대시보드 집계 숫
읽기 → -
결제·정산 데이터 정합성 감사로 불일치 조기 발견
20260413 2330 partner90 settlement 2026-04-13 기준 시스템 현황 분석 보고서를 작성했음. 분석 목적 서비스가 복잡해질수록 데이터 간 불일치가 쌓임. 특히 결제/정산처럼 여러 단계를 거치는 흐름은 중간 어딘가에서 엣지케이스가 터지기 쉬움. 주기적으로 전체 데이터를 돌아보면서 이상 징후를 조기에 발견하는 게 목적이었
읽기 → -
파트너 조회 중복 로직을 공통 메서드로 통합해 유지보수성 개선
partnerSn 조회 로직을 resolvePartnerSn 공통 메서드로 추출 리팩토링 작업을 완료했음. 리팩토링 이유 중복 코드가 여러 클래스에 흩어져 있었음. 수정이 필요할 때 모든 위치를 찾아야 하고, 누락 시 버그가 생김. 공통 메서드로 추출해서 단일 수정 포인트를 만들었음. 변경 전/후 java // 수정 전: 중복/복잡 로직 //
읽기 → -
결제·정산 데이터 정합성 감사로 불일치 항목 조기 발견
20260411 0337 partner portal verification 2026-04-11 기준 시스템 현황 분석 보고서를 작성했음. 분석 목적 서비스가 복잡해질수록 데이터 간 불일치가 쌓임. 특히 결제/정산처럼 여러 단계를 거치는 흐름은 중간 어딘가에서 엣지케이스가 터지기 쉬움. 주기적으로 전체 데이터를 돌아보면서 이상 징후를 조기에 발견하는
읽기 →