-
결제 송금 알림 메시지 빌더를 분리해 가독성 개선
왜 손댔나 연락처 송금 메시지 유틸이 너무 비대해졌음. 결제 플랫폼에서 파트너끼리 잔액을 옮길 때 알림 문구를 만드는 부분인데, 한 메서드 안에 분기가 켜켜이 쌓여 있었음. - 송금 성공/실패/대기/취소 4종 - 파트너 등급별 호칭 표기 차이 - 결제대행사 결과코드에 따른 문구 분기 - 다국어 금액 포맷 분기 새 메시지 한 줄 추가하려고 200라인짜
읽기 → -
연락처 송금 자동 매칭 누락으로 쌓이던 PENDING 건 해소
연락처 송금 매칭, 왜 다시 손댔나 연락처 기반 송금 흐름에서 입금자명/금액으로 자동 매칭하는 로직이 돌고 있는데, 큐에 들어온 건이 실제로 수령됐는지 확인하는 단계가 비어있었음. 매칭은 됐는데 수령 확인이 누락돼서 PENDING으로 남아있는 건들이 쌓였고, 운영팀이 손으로 정리하고 있던 상태. 원인은 두 가지였음. - 매칭 유틸이 입금 레코드 상태만
읽기 → -
파트너 정산 은행 자동화 UI 감지 로직 개선과 에러 분류
은행 자동화에서 만난 함정 파트너 정산 자동화 손볼 일이 있어서 특정 은행 웹 자동화 핸들러를 다시 깠음. 단순 셀렉터 교체겠거니 했는데, 막상 들어가보니 UI 감지 로직 자체가 깨져있었음. 문제 상황 기존 코드는 페이지 진입 후 고정 selector 하나로 "직접받기" 버튼을 찾고 있었음. 그런데 상대 사이트가 UI 를 살짝 바꾸면서 버튼이 여러 형
읽기 → -
직접받기 콜백 분기 지옥을 정규화 단계 분리로 해소
문제 상황 금융 파트너 쪽 "직접받기" 버튼 처리 로직이 누더기였음. 콜백으로 들어오는 응답 코드 케이스가 계속 늘었고, 분기가 6단 깊이까지 박혀 있었음. 새 케이스 하나 붙이려면 어느 가지에 끼워야 할지 5분씩 노려보고 있어야 했음. 무엇이 꼬여 있었나 - 외부 응답 상태와 내부 판정 결과가 같은 변수에 섞여 흘러다님 - 성공/실패 분기가 try
읽기 → -
입금 매칭 우선순위 정리로 결제 연동 모듈 구조 개선
무엇을 손봤나 특정 은행 입금 연동 모듈을 정리했음. 기존 코드는 UI 렌더링, 입금 콜백 파싱, 잔액 갱신이 한 클래스에 다 들어있어서 손대기 무서운 상태였음. 한 줄 바꾸면 어디서 터질지 모르는 전형적인 레거시. 이번엔 두 갈래로 쪼갰음. - **표시 레이어**: 파트너 화면에서 보여주는 입금 안내 / 계좌 표기 부분 - **처리 레이어**: 결
읽기 → -
정산 주문 매칭 로직을 변경 축 기준으로 분리해 누락 추적 속도를 높임
매칭 로직을 다시 봐야 했던 이유 파트너별 정산 화면에서 주문 누락이 보고됐음. 입금 데이터를 받아 주문과 매칭하고, 그 결과로 파트너를 결정한 뒤 계좌를 조회하는 흐름인데, 단계마다 책임이 섞여 있어서 어느 단계에서 어긋난 건지 추적이 오래 걸림. 기존 컨트롤러는 다음을 한꺼번에 하고 있었음: - 입금 식별자 파싱 - 주문 후보 조회 - 매칭 우선
읽기 → -
결제 매칭과 파트너 귀속 로직을 단계별로 분리해 동명이인 버그 해결
시작점 주문 매칭과 파트너 결정 로직이 한 유틸 안에 뒤엉켜 있었음. 입금 들어오면 어떤 주문에 매칭할지, 그 주문이 어떤 파트너 소속인지, 수수료를 누가 부담하는지 한 메서드 안에서 다 처리했음. 이번 리팩토링은 이걸 떼어내는 작업. 기존 흐름에서 가장 골치 아팠던 부분: - 매칭 후보가 여러 개일 때 우선순위 결정 분기가 6단계 넘게 중첩 - 파
읽기 → -
무통장 입금 미매칭을 주문번호 기준으로 자동 보정
배경 무통장 입금 매칭에서 파트너를 잘못 잡거나 계좌 정보가 비어있는 케이스가 누적됨. 운영팀이 손으로 일일이 보정하던 흐름을 주문 데이터 기준으로 자동화함. 결제 플랫폼 쪽 미매칭 건이 월말마다 쌓여서 더 미룰 수 없었음. 무엇을 바꿨나 - 주문번호를 키로 파트너 ID 역추적 - 입금자명·금액 일치 외에 주문 메타데이터로 보강 - 관리자 화면에서 미
읽기 → -
파트너 송금 조회 쿼리 리팩터링으로 응답 속도 5배 개선
무엇을 줄였나 파트너 송금 조회 쿼리가 길었음. 같은 조인을 세 번 반복하고 인라인 뷰도 두 개나 끼어 있었음. 화면 하나에 결과 보여주는 게 전부인데 실행계획 떠보면 풀스캔이 두 번 찍혀서 손봐야 했음. 원본 구조를 거칠게 정리하면 이랬음: - 송금 본 테이블 + 파트너 정보 조인 - 같은 조건으로 수수료 합계 뽑는 서브쿼리 - 환불 차감용 또 다른
읽기 → -
파트너 대시보드에 송금·주문 통계 위젯 추가
파트너 대시보드에 송금·주문 통계 붙이기 기존 파트너 대시보드는 결제 흐름 위주로만 정보를 뿌려줬음. 그러다 보니 파트너가 송금 내역이나 주문 추이를 보려면 메뉴를 두세 번 더 타고 들어가야 했고, "한 화면에서 다 보고 싶다"는 피드백이 누적돼 있었음. 이번 작업으로 두 가지를 한 위젯 영역에 묶었음. - 연락처 송금 통계: 일/주/월 단위 송금
읽기 → -
파트너 화면에 쿠폰·광고·메시지 메뉴 4종 추가
사이드바부터 손댄 이유 파트너 화면 기능이 늘어나는데 진입점은 그대로였음. 신규 페이지를 한꺼번에 붙이려니 메뉴 구조부터 정리해야 했음. 단순 링크 추가가 아니라 권한 단계에 따라 노출 항목이 달라져서, 사이드바 모델을 손볼 수밖에 없었음. 한 번에 묶은 화면들 오늘 붙인 컨트롤러는 4종류: - 파트너 간 메시지 화면 - 쿠폰 광고 배너 관리 -
읽기 → -
내장 브라우저에 광고 차단 레이어 구현해 로딩 속도 2배 개선
광고 차단을 직접 붙여본 이유 사내 도구로 쓰는 내장 브라우저에 외부 트래커가 너무 많이 붙어서 응답 속도가 들쭉날쭉했음. 페이지 로딩 자체보다 추적 스크립트 기다리는 시간이 더 길어 보일 정도였고, 그래서 차단 레이어를 직접 끼워 넣어봤음. 접근 방식 비교 확장 기능을 그대로 가져다 쓰는 방법도 있었지만, 임베디드 환경이라 권한이 제한적이었음.
읽기 → -
결제 웹훅 중복 수신 막고 정산 추적 로그 정비
웹훅 개선하면서 깨달은 것 결제대행사 쪽에서 들어오는 웹훅이 가끔 누락되거나 중복으로 찍히는 이슈가 있었음. 처음엔 "재시도 정책이려니" 하고 넘겼는데, 정산 데이터 검수하다가 같은 거래에 대해 콜백이 3번 들어온 케이스를 발견했음. 더는 못 미루겠다 싶어서 손댐. 무엇을 바꿨나 핵심은 두 가지. **웹훅 수신부 자체의 멱등성 보장**과 **로그를
읽기 → -
근태관리 설계 문서를 분리해 정산 흐름과 용어를 정돈한 과정
근태관리 SaaS 상세 설계 문서를 따로 뽑아낸 이유 처음엔 그냥 PLAN.md 한 장에 다 욱여넣으려고 했음. 근데 막상 출퇴근, 휴가, 시프트, 정산 흐름까지 그리다 보니 한 문서에서 스크롤이 끝도 없이 늘어나서 결국 PLAN_ATTENDANCE_DETAIL 로 분리함. 상위 PLAN 은 "무엇을 만든다"만 남기고, 디테일 문서는 "어떻게 동작하느냐
읽기 → -
백오피스 관리자 매뉴얼 슬라이드 자동 생성으로 갱신 시간 대폭 단축
매뉴얼을 매번 손으로 만드는 건 한계였음 이커머스 백오피스 운영팀에서 신규 기능이 붙을 때마다 관리자 매뉴얼 갱신 요청이 들어왔음. 처음엔 그냥 슬라이드 열어서 캡처 붙이고 화살표 그렸는데, 화면 하나만 바뀌어도 슬라이드 전체를 다시 손봐야 했음. 페이지 60장 넘어간 시점부터는 도저히 답이 없었음. 그래서 설정 파일 하나로 슬라이드를 자동 생성하는
읽기 → -
관리자 매뉴얼 자동화로 수동 작업 반나절을 수분으로 단축
매뉴얼 엔진을 손으로 짜기로 한 이유 관리자 화면이 계속 늘어나면서 운영팀에서 "이 버튼 뭐예요"라는 질문이 매주 쌓였음. 외부 문서툴에 정리하던 매뉴얼이 화면 변경 속도를 못 따라잡아서, 빌드 시점에 화면 메타데이터를 긁어 자동으로 매뉴얼 HTML을 뽑는 스크립트를 직접 만들기로 함. 처음엔 외부 문서 도구를 붙일까 고민했는데, 이커머스 도메인 특성
읽기 → -
크로스 오리진 iframe 비디오 감지율을 절반 이상 끌어올린 방법
iframe 안의 비디오, 왜 못 잡나 부모 document에서 querySelectorAll('video') 돌리면 같은 오리진 iframe 안의 비디오까지는 그래도 contentDocument로 파고 들어갈 수 있음. 근데 크로스 오리진 iframe은 브라우저가 막아놔서 접근 자체가 불가. 외부 임베드 페이지가 많은 사이트일수록 감지율이 뚝 떨어짐.
읽기 → -
iframe 내부 영상 감지 누락 수정으로 감지율 향상
사이트마다 다른 DOM 구조 영상 감지 기능이 일부 페이지에서 침묵하는 제보가 들어옴. 직접 들어가 보니 페이지 자체엔 분명히 플레이어가 떠 있는데 감지기는 0개를 리턴함. 콘솔 찍어보니 원인이 명확했음 — 플레이어가 iframe 안에 들어 있는 케이스였음. 기존 videoDetector는 top window 기준으로만 querySelectorAll(
읽기 → -
영상 감지율을 60%에서 94%로 끌어올린 네트워크 후킹 도입
문제 상황 이전 videoDetector는 페이지 로드 시점의 <video> 태그만 훑고 끝났음. 그러다 보니 - SPA에서 라우팅 후 동적으로 붙는 영상은 놓침 - 플레이어가 blob URL이나 MSE로 스트림을 주입하면 src가 비어있어서 못 잡음 - API가 m3u8 매니페스트만 내려주고 DOM에는 아무것도 안 박히는 케이스도 있음 결국 "감지
읽기 → -
안드로이드 웹뷰 백지 화면, 결제 콜백 평문 트래픽 차단이 원인
안드로이드 웹뷰에서 갑자기 화면이 백지로 뜬 사건 QA에서 "안드로이드 앱 켜면 흰 화면만 나옴" 제보가 들어왔음. iOS는 멀쩡한데 안드로이드만 그럼. 로그를 까보니 익숙한 메시지가 보임. net::ERR_CLEARTEXT_NOT_PERMITTED 원인은 한 줄로 정리됨. 안드로이드 9(API 28)부터 평문 HTTP 트래픽이 기본 차단됨. 우
읽기 →