SLECS. blog
개발 자동화 사이드프로젝트 일기 태그 검색 RSS ← Portfolio
  • 개발 2026-04-30

    정산 원장에 결제 발생 즉시 PENDING 미러링

    정산 원장에 PENDING 상태 미러 로직을 추가하고 취소 시 동기화를 구현했음. 배경 결제가 발생하는 시점과 정산이 확정되는 시점 사이에 시간 차이가 존재함 (가상계좌: 2시간, 카드: 3일). 이 기간 동안 원장에 상태가 반영되지 않으면 운영자가 실제 재무 상황을 실시간으로 파악하기 어려움. PENDING → CONFIRMED 흐름 결제 발

    읽기 →
  • 개발 2026-04-30

    선불 잔액 고지 문구 조사 오류 수정

    이커머스 PG 플랫폼/footer 버그를 수정했음. 선불 잔액 고지 문구 조사 수정 (는→가). 변경 파일: 뷰/스타일 1개 문제 원인 기존 로직에서 엣지 케이스가 처리되지 않아 특정 상황에서 잘못된 결과를 반환하거나 오류가 발생하고 있었음. 수정 내용 - 화면 렌더링 수정 - 프론트 스크립트 수정 버그 수정 프로세스 단순히 증상만 픽스하는

    읽기 →
  • 개발 2026-04-30

    정산 출금 가능 금액 산식 개선과 명세 투명화

    결제 플랫폼의 정산 시스템에서 가맹점이 실제로 출금할 수 있는 금액을 계산하는 로직을 손봤다. "확정 출금 가능" 필드의 산식을 개선하고, UI에 세부 라인을 추가해서 투명성을 높이는 작업이었다. 정산 금액 산식, 왜 다시 봤나 이커머스 정산 시스템에서 가맹점이 언제 돈을 빼갈 수 있는지는 매우 예민한 부분이다. 단순히 "매출액 - 수수료"가 아니라,

    읽기 →
  • 개발 2026-04-30

    대시보드에 쿠폰 마진 집계 지표 추가

    admin/dashboard/total-summary 영역에 새 기능을 추가했음. 비외부 채널 쿠폰 마진 산식 및 세부 항목 추가. 변경 파일: SQL 매퍼 1개, 뷰/스타일 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현 내용 -

    읽기 →
  • 개발 2026-04-30

    결제 플랫폼 월별 정산 누적액 추적 오류 해결

    결제 플랫폼의 출금 로직에서 월 단위 누적액(carryover) 처리를 개선했다. 출금 정산과 누적액의 관계 결제 플랫폼을 운영하면서 가장 까다로운 부분 중 하나가 정산 주기와 미정산 잔액 관리다. 보통 플랫폼은 일일, 주간, 월간 단위로 정산을 진행하는데, 각 주기마다 정산 기준 미달(예: 최소 정산액 1만 원 미만)로 인해 다음 주기로 미루어지는

    읽기 →
  • 개발 2026-04-30

    매출 요약 폰트 조정과 총합 메뉴 비활성화 처리

    유지보수성 개선 작업. revenue_summary 폰트 사이즈 + total-summary 메뉴 비활성화 SQL. 변경 파일: SQL 파일 1개, 뷰/스타일 1개 배경 기능 변경 없이 내부 품질을 높이기 위한 작업. 설정 값 업데이트, 스케줄 조정, 문서 보완 등 개발 환경과 운영 편의성을 개선했음. SQL 업데이트 스키마나 기준 데이터를 변경

    읽기 →
  • 개발 2026-04-30

    수익 대시보드 순수익 섹션 마크업과 라벨 구조 개선

    대시보드 수익 요약 영역의 UI/UX 개선 작업을 진행했다. 복잡하게 얽혀 있던 순수익 섹션의 마크업을 정리하고 라벨 표기를 명확하게 다시 정의했는데, 이 작은 refactor 가 왜 필요했고 어떤 고민이 담겼는지 회고해본다. 수익 대시보드, 왜 단순화가 필요했나 관리자 영역의 수익 요약 페이지는 운영팀이 매일 들어오는 공간이다. 순수익(net rev

    읽기 →
  • 개발 2026-04-30

    매출 대시보드 폴링 시 결제 항목 라벨과 데이터 불일치 해결

    관리자 대시보드의 매출 요약 화면에서 실시간 데이터 갱신과 라벨 정합 문제를 함께 해결했다. 대시보드 폴링과 데이터 동기화의 어려움 운영 대시보드는 실시간 지표를 보여줘야 하는데, 특히 매출 통계처럼 시간대별로 변하는 데이터는 사용자가 화면을 열어둔 상태에서도 최신 정보를 받아야 한다. 이걸 구현하는 방식은 크게 두 가지인데, 웹소켓 같은 양방향 통신

    읽기 →
  • 개발 2026-04-30

    매출 차트에 확정·대기 구분 서브라인과 발생주의 라벨 추가

    관리자 대시보드의 매출 현황 차트에 확정/대기 상태를 구분하는 서브라인과 발생주의 라벨을 추가했다. 단순해 보이는 UI 변경이지만, 재무 데이터 시각화에서는 꽤 중요한 작업이었다. 왜 이 변경이 필요했나 관리자 입장에서 시간축 그래프를 볼 때 전체 합계만 표시되면 실제 의사결정에 필요한 정보가 부족하다. 예를 들어 매출이 100만 원으로 표시되어 있어

    읽기 →
  • 일기 2026-04-30

    카드 결제 PENDING 상태의 발생주의 정산 기준 정책화

    내부 정책 문서에 발생주의 카드의 PENDING 상태 처리 방식을 추가했다. 배경: 카드 결제와 PENDING 상태의 모호함 결제 플랫폼을 다루다 보면 "발생주의" vs "현금주의" 같은 회계 원칙과 실제 결제 상태가 자주 엇갈린다. 특히 카드 거래는 승인 요청을 한다고 해서 즉시 돈이 빠지는 게 아니라, 몇 시간에서 며칠에 걸쳐 정산이 진행된다. 그

    읽기 →
  • 일기 2026-04-30

    수수료 최소값과 비교 기준값을 정책 문서에서 명확히 분리

    내부 정책 문서를 정리하면서 '비교 기준값'과 '플랫폼 수수료 최소값' 두 개념을 명확히 분리했다. 한 파일에서 여러 정책을 관리할 때 이런 개념 분리가 왜 중요한지, 그리고 어떤 문제를 예방하는지 정리해봤다. 두 가지 값의 혼동이 왜 생기나 시스템을 운영하다 보면 '기준'이라는 단어가 여러 맥락에서 나타난다. 비교 기준값(A)은 어떤 조건을 판단할

    읽기 →
  • 개발 2026-04-29

    정산 출금 대시보드에 실시간 KPI 집계 카드 추가

    admin/dashboard 영역에 새 기능을 추가했음. total-summary 카드 통합 + 정산 출금 partial 공유. 변경 파일: 뷰/스타일 3개, 내부 클래스 2개, SQL 매퍼 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음.

    읽기 →
  • 개발 2026-04-29

    이커머스 푸터 선불 잔액 보호 고지 문구 갱신

    이커머스 PG 플랫폼의 푸터에 선불 잔액 보호 고지 문구를 갱신했다. 한 줄로 보면 단순한 UI 텍스트 변경이지만, 이 뒤에는 규제 요건, 사용자 보호, 그리고 법적 책임이라는 무거운 맥락이 있다. 선불금 관련 고지의 중요성 선불 잔액이나 포인트 같은 선불금을 다루는 서비스는 금융감독 입장에서 매우 민감한 영역이다. 사용자가 충전한 돈이 어떻게 관리되

    읽기 →
  • 개발 2026-04-29

    비회원 파트너 영수증 자동생성

    pay/receipt 영역에 새 기능을 추가했음. 비회원 파트너 발급 영수증 자동생성 보강 + 과거건 백필. 변경 파일: 내부 클래스 2개, SQL 매퍼 2개, SQL 파일 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현 내용 - 영

    읽기 →
  • 개발 2026-04-29

    매출 대시보드에서 머천트 라이브 카드를 상단으로 복귀

    매출 관리 대시보드의 머천트 카드 표시 방식을 다시 손봤다. 라이브 데이터를 메인으로 돌려놓는 작은 변경이지만, 운영 관점에서 꽤 의미 있는 결정이었다. 왜 이런 변경이 필요했나 결제 플랫폼 같은 시스템을 운영하다 보면, 머천트별 매출 현황을 실시간으로 파악해야 한다. 특히 관리자가 보는 시스템 전체 수익 요약(total-summary) 페이지에서는

    읽기 →
  • 개발 2026-04-29

    머천트 카드 결제 화면의 회사 가용 자금 계산식 오류 수정

    머천트 카드 결제액을 집계하는 화면에서 실제 회사 가용 자금 계산식이 잘못되어 있었는데, 이번에 정정했다. 왜 이런 버그가 생겼나 수익 관련 대시보드를 구축할 때 보통 여러 단계의 자금 흐름이 존재한다. 머천트 쪽 카드 결제가 발생하면 → 수수료 차감 → 정산 대기 → 실제 입금 같은 식으로. 문제는 화면에 노출되는 "가용 자금" 수치가 이 흐름을 제

    읽기 →
  • 일기 2026-04-29

    잔액 동기화 배치 주기를 2시간마다로 단축해 데이터 최신성 개선

    유지보수성 개선 작업. 잔액 동기화 주기 매일 06:00 → 2시간마다 :11분. 변경 파일: 내부 클래스 2개, 설정/문서 1개, 뷰/스타일 1개 배경 기능 변경 없이 내부 품질을 높이기 위한 작업. 설정 값 업데이트, 스케줄 조정, 문서 보완 등 개발 환경과 운영 편의성을 개선했음. 스케줄 조정 이유 배치 실행 주기를 변경했음. 너무 자주 실

    읽기 →
  • 개발 2026-04-29

    정산 화면에 사용자 가용 잔액 카드 추가

    system-revenue/total-summary 영역에 새 기능을 추가했음. 사용자 가용 잔액 카드 추가. 변경 파일: 뷰/스타일 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현 내용 - 관련 내부 클래스에 메서드 추가 - SQL

    읽기 →
  • 개발 2026-04-29

    결제 분해 동기화 제거로 쿼리 성능 개선

    쿼리/로직 성능 개선 작업. SubordinateCount 통합 + 결제 분해 동기화 제거. 변경 파일: 내부 클래스 1개, SQL 매퍼 1개, 뷰/스타일 1개 개선 결과: 체감할 수 있는 수준으로 개선 문제 상황 특정 화면이나 API가 눈에 띄게 느렸음. 데이터가 쌓일수록 더 느려지는 선형 구조라서 근본적인 개선이 필요했음. 사용자 입장에서 몇

    읽기 →
  • 개발 2026-04-29

    파트너 대시보드에 결제 KPI 기간 필터와 실시간 집계 추가

    partner-portal/dashboard 영역에 새 기능을 추가했음. 누적 KPI 카드 임의 기간 필터 추가 (startDate/endDate). 변경 파일: 내부 클래스 1개, SQL 매퍼 1개, 뷰/스타일 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서

    읽기 →
« ‹ 이전 1 … 67 68 69 70 71 … 129 다음 › »
총 2576편 · 69 / 129

카테고리

  • 개발1847
  • 자동화243
  • 사이드프로젝트121
  • 일기365

인기 글

  • 프론트엔드 보안 응답 헤더 일괄 적용으로 XSS·클릭재킹 방어 강화186
  • 신상 그룹 등록 프로세스 완전 자동화119
  • 리포트 조회를 캐릭터 내레이션으로 재구성104
  • 법정 필수 문서를 푸터에 배치하고 페이지 구조화101
  • 대기 중인 결제가 중복 처리되던 버그 수정95

태그

#sql426#api297#payment269#lock203#settlement167#test156#fix143#java127#log123#batch116#css105#auth93#claude88#retry73#refactor69#queue56#javascript44#schema44#webhook40#transaction34
전체 태그 →
© slecs 블로그 — 개발·자동화·사이드프로젝트 실전 기록 About Contact 이용약관 개인정보처리방침 쿠키정책 운영정책 RSS Sitemap 관리자