-
결제 정산 원장의 컬럼 매핑 버그와 멱등성 오류 수정
system-ledger 버그를 수정했음. audit source_history_sn 매핑 + 멱등성 키 정정. 변경 파일: 내부 클래스 1개, SQL 매퍼 1개 문제 원인 컬럼 매핑이 잘못 연결돼 있어 값이 엉뚱한 필드에 들어가거나 누락되고 있었음. 수정 내용 - SQL 쿼리 조건/집계 수정 - 내부 클래스 로직 수정 버그 수정 프로세스
읽기 → -
정산 원장에 결제 발생 즉시 PENDING 미러
정산 원장에 PENDING 상태 미러 로직을 추가하고 취소 시 동기화를 구현했음. 배경 결제가 발생하는 시점과 정산이 확정되는 시점 사이에 시간 차이가 존재함 (가상계좌: 2시간, 카드: 3일). 이 기간 동안 원장에 상태가 반영되지 않으면 운영자가 실제 재무 상황을 실시간으로 파악하기 어려움. PENDING → CONFIRMED 흐름 결제 발
읽기 → -
정산 감사 이력 테이블 신설로 변동 추적 가능
감사 이력 테이블을 신설하고 관련 로직을 구현했음. [단계] 수익 카드 audit SUM 기반 교체 + 검증 비교 섹션. 왜 감사 이력이 필요한가 잔액이나 정산 관련 데이터는 "언제, 누가, 무엇을, 얼마나 변경했는가"를 추적할 수 있어야 함. 이슈가 생겼을 때 원인 파악과 책임 추적을 위해 필수임. 특히 금융 도메인에서는 감사 추적이 기본 요건임.
읽기 → -
정산 SQL 수수료 집계 버그 수정
pg 버그를 수정했음. SystemRevenue_sql VA PG 수수료 300→330원 후속 갱신. 변경 파일: SQL 매퍼 1개 문제 원인 SQL 쿼리 조건이 잘못돼 있었거나, JOIN/필터 누락으로 데이터가 잘못 집계되고 있었음. 기대값과 실제값을 비교해서 어느 쿼리에서 차이가 발생하는지 좁혀 찾았음. 수정 내용 - SQL 쿼리 조건/집계
읽기 → -
가상계좌 PG 수수료
pg 버그를 수정했음. 가상계좌 PG 수수료 300→330원 갱신 및 익월 후정산 라벨 추가. 변경 파일: SQL 매퍼 3개, 뷰/스타일 2개, 설정/문서 1개 문제 원인 기존 로직에서 엣지 케이스가 처리되지 않아 특정 상황에서 잘못된 결과를 반환하거나 오류가 발생하고 있었음. 수정 내용 - SQL 쿼리 조건/집계 수정 - 화면 렌더링 수정 -
읽기 → -
감사 로그와 실제 DB 상태의 드리프트 감지 시스템 구축
감사 로그와 실제 상태의 불일치를 감지하고 진단하는 시스템을 구축했다. 감사 로그 드리프트란 무엇인가 운영 중인 서비스에서 감사 로그(audit log)는 모든 중요한 상태 변화를 기록하는 안전장치다. 사용자 정보 수정, 권한 변경, 거래 처리 같은 작업들이 발생할 때마다 "누가, 언제, 무엇을, 왜" 변경했는지를 남긴다. 그런데 문제는 시간이 지나면
읽기 → -
정산 원장에 결제 발생 즉시 PENDING 미러링
정산 원장에 PENDING 상태 미러 로직을 추가하고 취소 시 동기화를 구현했음. 배경 결제가 발생하는 시점과 정산이 확정되는 시점 사이에 시간 차이가 존재함 (가상계좌: 2시간, 카드: 3일). 이 기간 동안 원장에 상태가 반영되지 않으면 운영자가 실제 재무 상황을 실시간으로 파악하기 어려움. PENDING → CONFIRMED 흐름 결제 발
읽기 → -
결산 고도화와 안드로이드 결제 모니터 엣지 케이스 정복
4월, 638개 커밋. 28개월 중 최고치다. 새 회사 두 번째 달이면서 자동화, 결산, 모니터링이 동시에 달렸다.
읽기 → -
결제 정산 감사 로직의 멱등성
system-ledger 버그를 수정했음. (C) 백필 시드 명확화 + audit 멱등성 보강. 변경 파일: 내부 클래스 3개, SQL 매퍼 1개, SQL 파일 1개 문제 원인 기존 로직에서 엣지 케이스가 처리되지 않아 특정 상황에서 잘못된 결과를 반환하거나 오류가 발생하고 있었음. 수정 내용 - SQL 쿼리 조건/집계 수정 - 내부 클래스 로직
읽기 → -
정산 원장에 결제 발생 즉시 PENDING 미러링
정산 원장에 PENDING 상태 미러 로직을 추가하고 취소 시 동기화를 구현했음. 배경 결제가 발생하는 시점과 정산이 확정되는 시점 사이에 시간 차이가 존재함 (가상계좌: 2시간, 카드: 3일). 이 기간 동안 원장에 상태가 반영되지 않으면 운영자가 실제 재무 상황을 실시간으로 파악하기 어려움. PENDING → CONFIRMED 흐름 결제 발
읽기 → -
선불 잔액 고지 문구 조사 오류 수정
이커머스 PG 플랫폼/footer 버그를 수정했음. 선불 잔액 고지 문구 조사 수정 (는→가). 변경 파일: 뷰/스타일 1개 문제 원인 기존 로직에서 엣지 케이스가 처리되지 않아 특정 상황에서 잘못된 결과를 반환하거나 오류가 발생하고 있었음. 수정 내용 - 화면 렌더링 수정 - 프론트 스크립트 수정 버그 수정 프로세스 단순히 증상만 픽스하는
읽기 → -
정산 출금 가능 금액 산식 개선과 명세 투명화
결제 플랫폼의 정산 시스템에서 가맹점이 실제로 출금할 수 있는 금액을 계산하는 로직을 손봤다. "확정 출금 가능" 필드의 산식을 개선하고, UI에 세부 라인을 추가해서 투명성을 높이는 작업이었다. 정산 금액 산식, 왜 다시 봤나 이커머스 정산 시스템에서 가맹점이 언제 돈을 빼갈 수 있는지는 매우 예민한 부분이다. 단순히 "매출액 - 수수료"가 아니라,
읽기 → -
대시보드에 쿠폰 마진 집계 지표 추가
admin/dashboard/total-summary 영역에 새 기능을 추가했음. 비외부 채널 쿠폰 마진 산식 및 세부 항목 추가. 변경 파일: SQL 매퍼 1개, 뷰/스타일 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현 내용 -
읽기 → -
결제 플랫폼 월별 정산 누적액 추적 오류 해결
결제 플랫폼의 출금 로직에서 월 단위 누적액(carryover) 처리를 개선했다. 출금 정산과 누적액의 관계 결제 플랫폼을 운영하면서 가장 까다로운 부분 중 하나가 정산 주기와 미정산 잔액 관리다. 보통 플랫폼은 일일, 주간, 월간 단위로 정산을 진행하는데, 각 주기마다 정산 기준 미달(예: 최소 정산액 1만 원 미만)로 인해 다음 주기로 미루어지는
읽기 → -
매출 요약 폰트 조정과 총합 메뉴 비활성화 처리
유지보수성 개선 작업. revenue_summary 폰트 사이즈 + total-summary 메뉴 비활성화 SQL. 변경 파일: SQL 파일 1개, 뷰/스타일 1개 배경 기능 변경 없이 내부 품질을 높이기 위한 작업. 설정 값 업데이트, 스케줄 조정, 문서 보완 등 개발 환경과 운영 편의성을 개선했음. SQL 업데이트 스키마나 기준 데이터를 변경
읽기 → -
수익 대시보드 순수익 섹션 마크업과 라벨 구조 개선
대시보드 수익 요약 영역의 UI/UX 개선 작업을 진행했다. 복잡하게 얽혀 있던 순수익 섹션의 마크업을 정리하고 라벨 표기를 명확하게 다시 정의했는데, 이 작은 refactor 가 왜 필요했고 어떤 고민이 담겼는지 회고해본다. 수익 대시보드, 왜 단순화가 필요했나 관리자 영역의 수익 요약 페이지는 운영팀이 매일 들어오는 공간이다. 순수익(net rev
읽기 → -
매출 대시보드 폴링 시 결제 항목 라벨과 데이터 불일치 해결
관리자 대시보드의 매출 요약 화면에서 실시간 데이터 갱신과 라벨 정합 문제를 함께 해결했다. 대시보드 폴링과 데이터 동기화의 어려움 운영 대시보드는 실시간 지표를 보여줘야 하는데, 특히 매출 통계처럼 시간대별로 변하는 데이터는 사용자가 화면을 열어둔 상태에서도 최신 정보를 받아야 한다. 이걸 구현하는 방식은 크게 두 가지인데, 웹소켓 같은 양방향 통신
읽기 → -
매출 차트에 확정·대기 구분 서브라인과 발생주의 라벨 추가
관리자 대시보드의 매출 현황 차트에 확정/대기 상태를 구분하는 서브라인과 발생주의 라벨을 추가했다. 단순해 보이는 UI 변경이지만, 재무 데이터 시각화에서는 꽤 중요한 작업이었다. 왜 이 변경이 필요했나 관리자 입장에서 시간축 그래프를 볼 때 전체 합계만 표시되면 실제 의사결정에 필요한 정보가 부족하다. 예를 들어 매출이 100만 원으로 표시되어 있어
읽기 → -
카드 결제 PENDING 상태의 발생주의 정산 기준 정책화
내부 정책 문서에 발생주의 카드의 PENDING 상태 처리 방식을 추가했다. 배경: 카드 결제와 PENDING 상태의 모호함 결제 플랫폼을 다루다 보면 "발생주의" vs "현금주의" 같은 회계 원칙과 실제 결제 상태가 자주 엇갈린다. 특히 카드 거래는 승인 요청을 한다고 해서 즉시 돈이 빠지는 게 아니라, 몇 시간에서 며칠에 걸쳐 정산이 진행된다. 그
읽기 → -
수수료 최소값과 비교 기준값을 정책 문서에서 명확히 분리
내부 정책 문서를 정리하면서 '비교 기준값'과 '플랫폼 수수료 최소값' 두 개념을 명확히 분리했다. 한 파일에서 여러 정책을 관리할 때 이런 개념 분리가 왜 중요한지, 그리고 어떤 문제를 예방하는지 정리해봤다. 두 가지 값의 혼동이 왜 생기나 시스템을 운영하다 보면 '기준'이라는 단어가 여러 맥락에서 나타난다. 비교 기준값(A)은 어떤 조건을 판단할
읽기 →