slecs 블로그 — 개발·자동화·사이드프로젝트 실전 기록

웹훅 원장 기록부터 깔았음 결제대행사 웹훅이 들어올 때 처리만 하고 흘려보내던 구조였는데, 정산 분쟁 한 번 터지고 나니 "그때 그 웹훅 진짜 왔었냐"는 질문에 답을 못 했음. 헤더, 페이로드, 서명검증 결과, 처리 결과까지 전부 원장으로 적재하기로 했음. - 들어온 원본은 가공 없이 그대로 저장 - 처리 단계별 상태 코드 분리 (수신완료 / 검증완료

읽기 →

개발 2026-03-17

가상계좌 충전 정산에 결제수단 컬럼과 멱등 처리 추가

결제수단 필드를 왜 이제야 추가했나

읽기 →

개발 2026-03-17

결제대행사 충전 화면 개선과 조회 쿼리 최적화

무엇을 건드렸나 결제대행사 연동 충전건의 상세 화면과 리스트 화면을 손봤음. 어드민에서 보던 충전 상세는 정작 운영자가 필요한 정보가 흩어져 있어서 매번 DB 스크립트로 까봤는데, 이걸 화면에서 한 번에 확인 가능하게 정리. 작업한 레이어 정리하면 이런 모양: | 레이어 | 변경 포인트 | |---|---| | 어드민 컨트롤러 | 상세 응답 DTO

읽기 →

개발 2026-03-17

결제 수수료 정산을 지연 차감 방식으로 전환해 환불 흐름 단순화

배경 결제 플랫폼에서 파트너에게 부과되는 수수료를 결제 즉시 차감하는 기존 로직이 있었음. 문제는 이커머스 특성상 결제 후에도 환불/취소가 빈번하게 일어난다는 점. 즉시 차감해버리면 환불이 들어왔을 때 수수료를 다시 환원해야 하는데, 이 역방향 흐름이 곳곳에서 깨지고 있었음. 흐름 재설계 결제대행사에서 정산 데이터가 넘어오는 시점을 기준으로 상태를

읽기 →

개발 2026-03-17

결제대행사 연동 제거로 충전 로직 버그까지 발견 정리

결제대행사 연동 삭제와 충전 로직 손질 오늘 작업은 두 갈래였음. 더 이상 트래픽이 들어오지 않는 결제대행사 연동을 들어내는 것, 그리고 충전 흐름에 쌓여있던 잔버그를 정리하는 것. 왜 들어냈는가 - 해당 결제대행사로 유입되는 트래픽이 사실상 0에 수렴 - 그런데 유지보수 비용은 그대로 발생 (콜백 검증, 환불 분기, 예외 처리) - 다른 결제대행

읽기 →

개발 2026-03-17

충전 수수료를 충전 트랜잭션 단위로 매칭해 회계 역추적 해결

충전 수수료 차감, 어느 시점 요율을 따라야 하나 결제 플랫폼에서 파트너가 잔액을 충전할 때 충전 수수료를 떼는 구조인데, 환불·취소 흐름에서 차감 기준이 애매했음. 충전 시점 요율을 박아두는 방식이었는데, 파트너 등급이 중간에 바뀌면 과거 충전건과 현재 차감액이 어긋남. 회계팀에서 "이 충전건이 그 차감인지 매칭이 안 된다"는 컴플레인이 들어와서 손을

읽기 →

개발 2026-03-17

결제 수단 추가로 드러난 정산 쿼리 누락과 분기 구조 개선

새 결제 수단 붙이기 이커머스에서 결제대행사 한 곳을 추가함. 기존엔 카드/가상계좌만 받던 흐름에 새 수단이 끼어들면서, 결제 요청 분기에서 슬슬 균열이 보이기 시작함. 처음엔 그냥 if 한 줄 더 넣고 끝날 줄 알았는데, 실제로 붙여보니 응답 콜백 포맷이 달라서 파싱 단계부터 다시 짜야 했음. 단순 추가가 아니라 "이미 너무 비대해진 분기"를 건드리

읽기 →

개발 2026-03-17

카드 충전 수수료 차감 로직 원자적 처리 구현

feat: 결제대행사 카드 충전 수수료 차감 로직 추가 로직을 구현했음.

읽기 →

자동화 2026-03-17

입금 웹훅 구조를 레지스트리 패턴으로 전환해 은행 추가 용이성 개선

배경 연락처 송금 기능에 입금 통보 받을 은행이 한 곳 더 늘어남. 기존엔 진입 컨트롤러에서 은행 코드별 if-else로 분기하던 구조라 추가할 때마다 같은 파일을 또 건드려야 했음. 이번에 인터넷전문은행 한 곳 더 붙이라는 요청 받았는데, 같은 자리를 또 손대기 싫어서 레지스트리 패턴으로 갈아엎기로 함. 무엇을 바꿨나 - 결제대행사 웹훅 수신 진입점

읽기 →