#java
-
중복 매칭 로직 정리로 코드 유지보수성 향상
불필요한 UI 컴포넌트 및 Java 매칭 로직 개선 리팩토링 작업을 완료했음. 리팩토링 이유 코드 가독성과 유지보수성 향상을 위한 리팩토링이었음. 변경 전/후 java // 수정 전: 중복/복잡 로직 // 각 클래스에 동일 로직 반복 // 수정 후: 명확하고 단일 책임 public static Long resolveId(Object sour
읽기 → -
채널 파트너 일괄 등록과 요율 계층 검증 기능 추가
파트너 일괄 등록 및 탈퇴 처리 기능 추가 2026-03-29에 외부 채널 관련 기능을 추가하거나 개선했음. 채널 포털은 각 외부 채널 사업자가 자신의 현황을 확인하고 설정하는 공간임. 대시보드에서 잔액, 거래 내역, 하위 채널 현황 등을 한눈에 볼 수 있음. 주요 기능 - 채널 계층 구조 관리 (상위/하위 채널 연결) - 수수료 설정 및 마진
읽기 → -
직접받기 콜백 분기 지옥을 정규화 단계 분리로 해소
문제 상황 금융 파트너 쪽 "직접받기" 버튼 처리 로직이 누더기였음. 콜백으로 들어오는 응답 코드 케이스가 계속 늘었고, 분기가 6단 깊이까지 박혀 있었음. 새 케이스 하나 붙이려면 어느 가지에 끼워야 할지 5분씩 노려보고 있어야 했음. 무엇이 꼬여 있었나 - 외부 응답 상태와 내부 판정 결과가 같은 변수에 섞여 흘러다님 - 성공/실패 분기가 try
읽기 → -
프로필 페이지 리디자인으로 체류 시간 3배 늘린 과정
프로필 페이지 갈아엎은 날 오래 묵힌 프로필 페이지를 손봤음. 기존 페이지는 정적인 카드 한 장에 이름·소개·연락처만 박아둔 형태였는데, 방문자가 1초 보고 바로 닫는다는 피드백이 누적돼서 작정하고 리디자인 들어감. 목표는 세 가지였음. - 첫 화면 진입 시 시선 잡아끄는 모션 - 보유 스킬을 한눈에 파악 가능한 아이콘 그리드 - 누적 활동량을 보여
읽기 → -
결제대행사 연동 제거로 충전 로직 버그까지 발견 정리
결제대행사 연동 삭제와 충전 로직 손질 오늘 작업은 두 갈래였음. 더 이상 트래픽이 들어오지 않는 결제대행사 연동을 들어내는 것, 그리고 충전 흐름에 쌓여있던 잔버그를 정리하는 것. 왜 들어냈는가 - 해당 결제대행사로 유입되는 트래픽이 사실상 0에 수렴 - 그런데 유지보수 비용은 그대로 발생 (콜백 검증, 환불 분기, 예외 처리) - 다른 결제대행
읽기 → -
결제 수단 추가로 드러난 정산 쿼리 누락과 분기 구조 개선
새 결제 수단 붙이기 이커머스에서 결제대행사 한 곳을 추가함. 기존엔 카드/가상계좌만 받던 흐름에 새 수단이 끼어들면서, 결제 요청 분기에서 슬슬 균열이 보이기 시작함. 처음엔 그냥 if 한 줄 더 넣고 끝날 줄 알았는데, 실제로 붙여보니 응답 콜백 포맷이 달라서 파싱 단계부터 다시 짜야 했음. 단순 추가가 아니라 "이미 너무 비대해진 분기"를 건드리
읽기 → -
카드 충전 수수료 차감 로직 원자적 처리 구현
feat: 결제대행사 카드 충전 수수료 차감 로직 추가 로직을 구현했음.
읽기 → -
결제대행사 회원 동기화를 비동기 큐로 전환해 정산 누락 해소
발단 이커머스 결제대행사 연동 작업 중 회원 정보 동기화 스펙 추가 요청 받았음. 신규 가입 시 결제대행사 쪽에 우리 회원 식별값을 함께 넘겨야 환불·정산 매칭이 깔끔해진다는 운영팀 피드백 때문이었음. 기존엔 결제 시점에 임시로 끼워 넣고 있어서 매칭 누락이 가끔 터졌음. 무엇을 추가했는가 가입/수정 흐름에 정식 필드를 박고, 변경 이벤트를 외부로
읽기 → -
가상계좌 수수료 후정산 전환과 충전 상태 머신 정합성 확보
가상계좌 충전 수수료, 결국 후정산이 답 결제대행사 가상계좌로 잔액 충전하는 흐름에서 수수료 처리가 계속 어긋났음. 충전 시점에 수수료까지 한 번에 차감하니까 회계팀에서 "이게 왜 여기서 빠져?"가 반복됨. 가상계좌 건당 부과되는 입금/발급 비용은 **이번 정산 시 차감되는 게 아니라 익월에 별도 청구**되는 구조. 그동안 코드는 충전 직후 머천트 잔
읽기 → -
이커머스 파트너 충전 결제 연동과 잔액 정산 안정화
결제대행사 충전 플로우 붙이기 이커머스 파트너 잔액에 충전 기능 하나 추가하는 일이었음. 단순히 API 한 개 더 까는 줄 알았는데, 결제대행사 쪽 응답 파싱이랑 트랜잭션 경계 잡는 게 생각보다 까다로웠음. 기본 흐름은 이렇게 정리: - 클라이언트 충전 요청 → 서버에서 주문 키 발급 - 결제대행사 팝업 띄워서 결제 진행 - 콜백 수신 → 검증 →
읽기 → -
결제 콜백 후 잔액 즉시 반영
결제 콜백 후 잔액이 안 보이던 문제 결제대행사 콜백이 들어와서 충전이 끝났는데, 정작 파트너 화면에서 새 잔액을 보려면 새로고침을 두세 번 해야 했음. 콜백 처리 자체는 멀쩡한데 후처리 흐름이 어긋난 것. 원인을 까보니: - 콜백 트랜잭션 커밋 직후 응답을 돌려주는데, 조회 API 쪽이 자체 캐시를 들고 있었음 - 잔액 반영 이벤트가 비동기로 흐르
읽기 → -
결제 웹훅 중복 처리를 멱등성 락으로 차단
결제대행사 Webhook이 같은 건을 두 번 때리는 문제 운영 중 결제대행사에서 같은 결제 건에 대해 동일한 웹훅이 두 번, 세 번 들어오는 케이스가 누적됨. 첫 호출에서 정상 처리됐는데 두 번째 호출이 잔액을 한 번 더 건드리거나 알림이 중복 발송되는 사고가 발생했음. 원인을 정리하면 이런 흐름이었음. - 결제대행사가 응답 ACK를 못 받으면 일정
읽기 → -
은행 연동 코드를 어댑터 패턴으로 신규 프로젝트에 이전
은행 핸들러 마이그레이션 시작 기존 이커머스 플랫폼에 흩어져 있던 은행 연동 코드를 신규 프로젝트로 옮김. 단순 복붙이 아니라 의존성부터 정리해야 했음. 문제는 기존 코드가 캐시 유틸을 직접 import 하고 있었고, 신규 쪽엔 그 유틸이 없었음. 같은 이름으로 새로 깎느냐, 인터페이스만 맞추느냐 사이에서 고민하다가 신규에 얇게 다시 만드는 쪽으로 감
읽기 → -
결제 플랫폼 보안 취약점 9건 한꺼번에 잡은 후기
코드 리뷰 한 방에 9건 결제 플랫폼 코드 리뷰 받은 거 한꺼번에 정리함. CRITICAL 2건, HIGH 4건, MEDIUM 3건. 충전/이체/파트너 관리/API 키 인증 구간이 골고루 걸렸음. 생각보다 한 군데 몰려 있어서 작업 자체는 반나절 컷. | 등급 | 영역 | 핵심 | |---|---|---| | CRITICAL | 이체 | 금액 검증 누
읽기 → -
입금 계좌 로테이션과 AI 입금자명 자동 매칭 도입
한 계좌만 쓰던 시절의 한계 파트너가 늘어나면서 단일 입금 계좌 구조가 슬슬 깨지기 시작함. 일 거래량이 일정 수준을 넘어가니 은행 쪽에서 거래 패턴을 의심하기도 하고, 한도에 막혀서 오후 늦게 입금이 튕기는 사고도 종종 났음. 파트너 입장에서는 한 번 튕긴 경험이 재충전 의욕을 꺾어버려서, 단순한 운영 이슈로 끝나지 않고 매출 직격타로 돌아왔음. 그
읽기 → -
결제대행사 콜백이 봇 필터에 막혀 정산 PENDING이 쌓인 문제 해결
외부 결제대행사 콜백이 차단당했음 이커머스 운영 중에 결제대행사 콜백이 봇 차단 필터에서 4xx로 떨어지는 사고 발생. 사용자 결제는 정상 완료됐는데 콜백이 막히니까 결제 플랫폼 내부 상태가 PENDING에서 안 넘어감. 정산 화면 보다가 발견했으니 운영 모니터링이 한 박자 늦은 것도 같이 발견됨. 원인 파악 - 봇 차단 필터를 외부 노출 API 경
읽기 → -
AI 분류로 자동입금 무한 재시도와 새벽 운영 알람을 잡다
문제 상황 자동입금 확정 단계에서 실패 메시지가 들어오면 무조건 재시도 큐에 다시 넣고 있었음. 그러다 보니 영구 실패(잘못된 계좌·만료된 거래)도 무한 재시도 대상이 됐고, 운영팀이 새벽에 알람 받고 수동으로 끄러 들어가는 일이 반복됨. 대표적으로 들어오는 메시지가 이런 식임. [입금알림] 거래종료 / 금액불일치 / 한도초과 / 일시오류 겉으
읽기 → -
파트너 정산 계좌 등록의 은행명 파싱 오류와 증권사 무한 로딩 수정
무슨 일이 있었음 파트너 정산용 계좌 등록 흐름에서 은행 응답 파싱이 들쭉날쭉해서 고치는 작업. 같은 은행이라도 응답 페이로드 표기가 케이스마다 달라서 매칭이 깨지는 문제였음. 거기에 한 파트너가 증권사 CMA를 등록하려다 무한 로딩에 빠졌다는 제보까지 들어옴. 핸들러가 증권사를 은행처럼 해석하다가 멍 때리는 동선. 깨졌던 표기 케이스 | 응답
읽기 → -
은행명 표기 불일치로 매일 누락되던 정산 30건 해결
은행명 매칭이 깨진 사연 결제대행사에서 내려주는 은행명 표기가 우리 내부 표준이랑 미묘하게 달라서 정산이 한 건씩 누락되던 이슈. 지역 농축협·새마을 계열에서 특히 자주 터졌음. 같은 은행인데 "새마을", "MG새마을", "새마을금고" 이렇게 세 가지 표기로 들어오는 게 발단. 문제의 코드 기존 매칭이 완전 일치 기반이라 한 글자라도 어긋나면 미매
읽기 → -
입금 유틸을 은행별 전용 핸들러로 분리해 확장성 개선
왜 손댔나 공용 입금 유틸 한 파일에 모든 은행 HTTP 호출이 쌓여있었음. 새 은행 붙일 때마다 같은 파일 열어서 if 분기 추가하는 구조. 이번엔 한 은행 케이스를 전용 핸들러로 떼어냈음. 변경 요약 | 항목 | 이전 | 이후 | |------|------|------| | HTTP 송신 위치 | 공용 유틸 | 은행별 전용 핸들러 | | 분기 방
읽기 →