일기
회고 / 메모
-
하위 정산 관리 JSP 삭제로 코드베이스 기술 부채 해소
불필요한 하위 정산 관리 JSP 제거 및 관련 코드 정리 유지보수 및 정리 작업을 했음. 배경 기능 개발에 집중하다 보면 불필요한 코드, 오래된 설정, 중복 파일이 쌓임. 이런 기술 부채는 당장은 문제가 없어 보여도 점점 코드베이스를 읽기 어렵게 만듦. 작업 내용 - 사용하지 않는 JSP/코드 제거 - 데드코드 방치 시 코드베이스 파악이 어려
읽기 → -
공통코드 초기화 스크립트 추가로 신규 환경 세팅 자동화
공통코드 그룹 및 상세 항목 초기화 스크립트 추가 2026-04-01에 공통코드 관련 기능을 추가했음. 공통코드는 상태값, 타입, 카테고리 같은 값들을 DB에서 관리하는 구조임. 하드코딩을 줄이고, 관리자가 화면에서 코드 목록을 수정할 수 있게 하는 게 목적임. 구조 공통코드 그룹 (GROUP_CODE) ├── 코드 항목 1 (CODE_VA
읽기 → -
결제 모니터링·영상 다운로더 직접 제작한 이직 첫 달 적응기
3월, 새 회사 첫 달. 공식 등록은 아직이었는데, 그건 절차의 문제이고 실제 작업은 3월 초부터 시작됐다.
읽기 → -
쇼핑몰과 운영서버 간 공급 모듈 통신 초기 세팅
쇼핑몰 플랫폼과 운영서버 간 공급 모듈 통신 초기 세팅 2026-03-31에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스, 내부 클래스, common.js 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로
읽기 → -
커미션 조회 화면 안정성
20260329 0230 commission-overview-refactor 2026-03-29에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 -
읽기 → -
은행 이체 알림 판정을 정규식 우선으로 전환해 응답 속도 개선
정규식 먼저, AI는 폴백으로 은행 알림에서 "이체 완료" 여부를 판정하는 핸들러들을 손봤음. 기존엔 AI 분류기를 1차로 돌리고 정규식을 폴백으로 두는 구조였는데, 이걸 뒤집었음. 정규식 1차, AI 폴백. 왜 뒤집었나 처음 설계 의도는 "AI가 더 똑똑하니까 먼저 시키고, 못 잡으면 정규식이 보조한다"였음. 근데 운영 들어가니 뒤집힌 비용 구조
읽기 → -
SMS 수신 추적과 자체 점유인증으로 알림 사각지대 제거
알림 수신 통계 — 보낸 것보다 받은 게 더 중요했음 이커머스 운영하면서 결제·배송 알림을 SMS로 쏴왔는데, 그동안 로그에는 "발송했음"만 남기고 있었음. 근데 진짜 봐야 할 건 **수신자가 실제로 받았느냐**였음. 통신사 리포트랑 우리 발송 카운트가 종종 어긋났고, 파트너 CS로 "고객이 못 받았다" 컴플레인이 들어오면 추적이 어려웠음. 이번에 회
읽기 → -
입금 매칭 라우팅 개선으로 은행 통보 미매칭 70% 복구
배경: 은행 통보 메시지 라우팅이 자꾸 어긋남 파트너 입금 매칭 파이프라인은 SMS/푸시로 들어온 은행 통보를 파싱해 은행별 핸들러로 보내는 구조임. 그런데 한 시중은행이 발신 번호 포맷을 살짝 바꿨는지, 그 시점부터 매칭률이 슬금슬금 떨어지기 시작함. 룰이 헤더 패턴 한 줄에만 의존하고 있어서, 통신사가 표기 방식을 손대거나 은행이 캠페인 문구를 끼우
읽기 → -
송금 매칭 쿼리에 파트너 식별자 누락으로 인한 오정산 수정
송금 주문 매칭에서 새어나간 필터 이커머스 결제 플랫폼에서 연락처 기반 송금 기능을 만지다가 매칭 로직에 구멍 발견함. 입금 통보가 들어오면 미체결 송금 주문을 찾아 매칭하는데, 파트너 식별자를 조건에 안 넣고 있었음. 다른 파트너의 동일 금액·동일 계좌 주문이 우연히 먼저 잡히면 엉뚱한 곳으로 정산이 흘러가는 시나리오였음. 발견한 순간 등에 식은땀.
읽기 → -
은행 입금 동의 누락·알림 실패 건 자동 재처리로 개선
무엇을 바꿨나 은행 파트너 입금 처리 흐름에서 두 가지를 손봤음. - 개인정보 동의 처리 로직을 분리함: 기존엔 신청 폼에서 동의 체크박스만 받고 끝났는데, 은행 측 검증 시점에 동의 이력이 함께 넘어가야 정상 처리됨. 이게 안 맞아서 일부 건이 미처리로 빠지고 있었음. - 미처리 알림 재처리 큐를 추가함: 알림 전송이 실패하거나 누락된 건을 자동 재
읽기 → -
연락처 송금 자동 매칭 누락으로 쌓이던 PENDING 건 해소
연락처 송금 매칭, 왜 다시 손댔나 연락처 기반 송금 흐름에서 입금자명/금액으로 자동 매칭하는 로직이 돌고 있는데, 큐에 들어온 건이 실제로 수령됐는지 확인하는 단계가 비어있었음. 매칭은 됐는데 수령 확인이 누락돼서 PENDING으로 남아있는 건들이 쌓였고, 운영팀이 손으로 정리하고 있던 상태. 원인은 두 가지였음. - 매칭 유틸이 입금 레코드 상태만
읽기 → -
파트너 정산 은행 자동화 UI 감지 로직 개선과 에러 분류
은행 자동화에서 만난 함정 파트너 정산 자동화 손볼 일이 있어서 특정 은행 웹 자동화 핸들러를 다시 깠음. 단순 셀렉터 교체겠거니 했는데, 막상 들어가보니 UI 감지 로직 자체가 깨져있었음. 문제 상황 기존 코드는 페이지 진입 후 고정 selector 하나로 "직접받기" 버튼을 찾고 있었음. 그런데 상대 사이트가 UI 를 살짝 바꾸면서 버튼이 여러 형
읽기 → -
직접받기 콜백 분기 지옥을 정규화 단계 분리로 해소
문제 상황 금융 파트너 쪽 "직접받기" 버튼 처리 로직이 누더기였음. 콜백으로 들어오는 응답 코드 케이스가 계속 늘었고, 분기가 6단 깊이까지 박혀 있었음. 새 케이스 하나 붙이려면 어느 가지에 끼워야 할지 5분씩 노려보고 있어야 했음. 무엇이 꼬여 있었나 - 외부 응답 상태와 내부 판정 결과가 같은 변수에 섞여 흘러다님 - 성공/실패 분기가 try
읽기 → -
입금 매칭 우선순위 정리로 결제 연동 모듈 구조 개선
무엇을 손봤나 특정 은행 입금 연동 모듈을 정리했음. 기존 코드는 UI 렌더링, 입금 콜백 파싱, 잔액 갱신이 한 클래스에 다 들어있어서 손대기 무서운 상태였음. 한 줄 바꾸면 어디서 터질지 모르는 전형적인 레거시. 이번엔 두 갈래로 쪼갰음. - **표시 레이어**: 파트너 화면에서 보여주는 입금 안내 / 계좌 표기 부분 - **처리 레이어**: 결
읽기 → -
정산 주문 매칭 로직을 변경 축 기준으로 분리해 누락 추적 속도를 높임
매칭 로직을 다시 봐야 했던 이유 파트너별 정산 화면에서 주문 누락이 보고됐음. 입금 데이터를 받아 주문과 매칭하고, 그 결과로 파트너를 결정한 뒤 계좌를 조회하는 흐름인데, 단계마다 책임이 섞여 있어서 어느 단계에서 어긋난 건지 추적이 오래 걸림. 기존 컨트롤러는 다음을 한꺼번에 하고 있었음: - 입금 식별자 파싱 - 주문 후보 조회 - 매칭 우선
읽기 → -
파트너 송금 조회 쿼리 리팩터링으로 응답 속도 5배 개선
무엇을 줄였나 파트너 송금 조회 쿼리가 길었음. 같은 조인을 세 번 반복하고 인라인 뷰도 두 개나 끼어 있었음. 화면 하나에 결과 보여주는 게 전부인데 실행계획 떠보면 풀스캔이 두 번 찍혀서 손봐야 했음. 원본 구조를 거칠게 정리하면 이랬음: - 송금 본 테이블 + 파트너 정보 조인 - 같은 조건으로 수수료 합계 뽑는 서브쿼리 - 환불 차감용 또 다른
읽기 → -
결제 플랫폼에 근태관리 모듈 추가하고 메뉴얼 자동 생성 도입
배경 이커머스 결제 플랫폼에 근태관리 SaaS 모듈을 끼워 넣는 작업 시작. 파트너들이 "정산도 여기서 보는데 직원 출퇴근까지 한 화면에서 보면 안 되냐"라고 계속 요청해서 결국 사이드 모듈로 붙이기로 결정함. 테이블 구조 근태 도메인은 본업이 아니라서 최소한으로 잘랐음. 일단 5개만 만듬. | 테이블 | 용도 | | --- | --- | | 직
읽기 → -
정산 유니크 제약 누락으로 중복 적재되던 문제 수정
dump.rdb 가 또 올라왔음 로컬에서 캐시 띄워놓고 작업하다 보면 워킹 디렉토리에 dump.rdb 가 슬쩍 생김. 평소엔 잘 피해다녔는데 다른 변경이랑 같이 add 되면서 한번 커밋에 따라 들어간 적이 있었음. 수십 MB 바이너리가 히스토리에 박히면 클론할 때마다 짜증나고, 무엇보다 캐시 스냅샷에 뭐가 들었는지 모르니 보안적으로도 찜찜함. 그래서
읽기 → -
비회원 파트너 링크 결제 흐름과 쿠폰 발급 유틸 분리
비회원이 파트너 링크로 들어왔을 때 이커머스에서 회원 가입 → 로그인 → 구매가 정석이지만, 파트너가 외부 SNS에 링크를 뿌리는 시나리오에선 비회원도 그냥 결제까지 끝내고 싶음. 가입 강제하면 이탈률이 확 올라감. 이번 WIP는 그 흐름을 통째로 새로 깐 작업. 일단 절반 정도 됨. 진입점에서 막힌 것들 상품 상세 진입부터 손봤음. 기존엔 세션
읽기 → -
결제 화면 포함 CSS와 SCSS 원본 불일치 해소
SCSS 컴파일 결과 동기화 스타일 빌드 파이프라인이 분리돼 있다 보니, SCSS 원본 변경분과 실제 배포되는 CSS 파일이 어긋나는 일이 종종 있었음. 이번 커밋은 그 어긋남을 한 번 정리하는 작업이었음. 대상은 세 파일: - 공통 스타일 시트 - 신규 테마 시트 - 이커머스 결제 플랫폼 화면용 시트 세 파일 모두 SCSS 원본과 컴파일 결과 CS
읽기 →