개발
코드 / 아키텍처 / 디버깅
-
정산 원장에 결제 발생 즉시 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 흐름 결제 발
읽기 → -
결제 정산 감사 로직의 멱등성
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만 원으로 표시되어 있어
읽기 → -
정산 출금 대시보드에 실시간 KPI 집계 카드 추가
admin/dashboard 영역에 새 기능을 추가했음. total-summary 카드 통합 + 정산 출금 partial 공유. 변경 파일: 뷰/스타일 3개, 내부 클래스 2개, SQL 매퍼 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음.
읽기 → -
이커머스 푸터 선불 잔액 보호 고지 문구 갱신
이커머스 PG 플랫폼의 푸터에 선불 잔액 보호 고지 문구를 갱신했다. 한 줄로 보면 단순한 UI 텍스트 변경이지만, 이 뒤에는 규제 요건, 사용자 보호, 그리고 법적 책임이라는 무거운 맥락이 있다. 선불금 관련 고지의 중요성 선불 잔액이나 포인트 같은 선불금을 다루는 서비스는 금융감독 입장에서 매우 민감한 영역이다. 사용자가 충전한 돈이 어떻게 관리되
읽기 → -
비회원 파트너 영수증 자동생성
pay/receipt 영역에 새 기능을 추가했음. 비회원 파트너 발급 영수증 자동생성 보강 + 과거건 백필. 변경 파일: 내부 클래스 2개, SQL 매퍼 2개, SQL 파일 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현 내용 - 영
읽기 → -
매출 대시보드에서 머천트 라이브 카드를 상단으로 복귀
매출 관리 대시보드의 머천트 카드 표시 방식을 다시 손봤다. 라이브 데이터를 메인으로 돌려놓는 작은 변경이지만, 운영 관점에서 꽤 의미 있는 결정이었다. 왜 이런 변경이 필요했나 결제 플랫폼 같은 시스템을 운영하다 보면, 머천트별 매출 현황을 실시간으로 파악해야 한다. 특히 관리자가 보는 시스템 전체 수익 요약(total-summary) 페이지에서는
읽기 →