#java
-
은행 입금 연동 오류 응답 파싱과 필수값 검증 개선
사건 요약 - 은행 파트너 입금 호출에서 간헐적 실패가 발생, 사용자 화면에는 "처리 실패"만 노출됨 - Step2 진입 시 일부 필수값이 누락된 채 호출되어 NPE 로 흐름이 끊김 - 운영팀이 원인 파악을 못해 같은 케이스를 반복 문의받았음 두 갈래로 손봄 입금 유틸의 응답 파싱과 Step2 입력 검증, 두 군데를 같은 변경에 묶었음. 응답 파싱은
읽기 → -
입금 크롤링을 HTTP 직접 호출로 교체해 응답 10배 빠르게
출발점 입금 내역 확인용 유틸이 헤드리스 브라우저로 은행 사이트를 띄워서 DOM 긁는 구조였음. 의존성 무겁고, 셀렉터 한 번 어긋나면 통째로 멈춤. 새벽에 알람 받고 일어난 적이 한두 번이 아니라서 진짜로 한 번 갈아엎고 싶었음. 무엇을 바꿨나 실제 동작을 패킷 캡처로 까보니 결국 로그인 토큰 받고 거래내역 조회 엔드포인트 두세 번 때리는 게 전부였
읽기 → -
결제 플랫폼 빈 이름 충돌로 서버 부팅 실패 해결
빈 이름 충돌로 서버가 안 떴던 날 이커머스 결제 플랫폼 백엔드를 띄우는데 갑자기 부팅 실패. 로그 끝까지 내려가지도 않고 컨텍스트 초기화 단계에서 죽음. 처음엔 단순 의존성 문제인 줄 알았는데, 메시지를 천천히 읽어보니 빈 이름이 중복됐다는 얘기였음. 원인 찾기 스택을 위로 거슬러 올라가면서 확인한 것들: - 같은 도메인의 컨트롤러 두 개가 동
읽기 → -
결제 플랫폼 서버 기동 실패, 컨트롤러 빈 이름 충돌로 해결
서버가 안 뜸 오전에 결제 플랫폼 모듈 한 군데 손보고 로컬에 띄우는데 기동 자체가 실패함. 로그 끝부분만 잘라보면 "동일한 빈 이름이 이미 정의되어 있다"는 메시지가 떡하니 박혀 있었음. 코드는 컴파일 통과했는데 컨테이너 초기화 단계에서 막힌 케이스. | 증상 | 원인 | 영향 | |---|---|---| | 컨테이너 초기화 실패 | 동일 이름 빈
읽기 → -
폐업 사업자 정산 오류 막으려 진위확인 API와 알림 로그 관리 도입
사업자 진위확인 외부 API 붙이기 파트너 등록 화면에서 사업자번호 검증을 외부 API로 처리하기로 함. 기존엔 입력값을 그냥 믿고 저장했는데, 실제로 폐업·휴업 사업자 데이터가 섞여서 정산할 때 골치 아팠음. 검증 응답에서 챙긴 필드: | 필드 | 의미 | |---|---| | 상태코드 | 계속/휴업/폐업 | | 과세유형 | 일반/간이/면세 | |
읽기 → -
결제 거래 실시간 동기화 API 설계와 멱등성 확보
배경 결제 플랫폼 모니터링 도구에서 거래 이력을 외부 시스템과 맞춰야 하는 요구가 있었음. 기존엔 새벽 배치로 한 번씩 긁어왔는데, 파트너 쪽에서 실시간에 가까운 동기화를 요청. 배치 주기를 줄이는 건 한계가 있어서 동기화용 API를 따로 뽑기로 함. 설계 포인트 처음엔 "최근 N분치 가져오기" 식으로 만들려다가, 멱등성을 못 잡으면 중복 적재가
읽기 → -
결제 콜백 자동수신으로 수동 입금 매칭 루프 제거
자동수신 결과를 받기 시작함 결제대행사에서 보내는 자동 입금 결과를 그동안 사람이 하루 한 번 손으로 매칭하던 구조였음. 누락 건이 가끔 생겼고, 정산 마감 직전에 발견되면 새벽에 다시 들어와 메우는 일이 반복됐음. 이번에 콜백을 받는 엔드포인트를 새로 붙여서 그 루프를 끊었음. 신규 API에서 챙긴 포인트는 세 가지였음. - **멱등성**: 같은
읽기 → -
입금자명 파싱 다단계 분류와 정산 계좌 조회 엔드포인트 분리
입금자명 파싱, 정규식 한 줄로는 안 됨 문자 메시지에서 입금자명 뽑는 로직 손봤음. 처음엔 정규식 한 줄로 끝낼 수 있을 줄 알았는데, 실제 데이터 까보니 케이스가 너무 많았음. - 은행마다 메시지 포맷이 다름 (콜론 위치, 줄바꿈, 특수문자) - 영문/한글 이름 혼합 - 법인명 뒤에 담당자명 붙는 케이스 ((주)○○ 홍길동) - 광고 문구가 본문에
읽기 → -
쿠폰 매입 신청·정산 흐름을 상태머신으로 안정화
쿠폰 매입 신청 관리, 왜 필요했나 이커머스 파트너 정산 흐름에서 발행된 쿠폰 중 안 팔린 잔량을 다시 사들이는 절차가 필요했음. 기존엔 발행 이력만 시스템에 있었고 매입은 메일+엑셀로 수기 처리 중이었음. 운영팀이 월별 분량 늘면서 누락·중복 신청 사고 두 건 터지고 나서야 짬이 남. 설계 핵심 세 흐름으로 분리함: - 매입 신청 접수 (파트너
읽기 → -
정지 파트너 결제 메시지를 컨트롤러 입구에서 즉시 차단
정지 파트너인데 메시지가 계속 들어옴 이커머스 결제 플랫폼에서 파트너를 정지시켰는데, 결제대행사 쪽 모니터링 메시지가 계속 들어오는 문제가 발견됨. 정지 사유가 사기 의심이든 계약 해지든, 일단 정지 걸린 시점부터는 어떤 입금/결제 이벤트도 우리 시스템 안쪽으로 흘러들면 안 됐음. 문제는 컨트롤러에서 메시지를 받자마자 파싱 → 매칭 → 잔액 반영까지
읽기 → -
입금 큐 성공 후 주문 매칭이 자동으로 안 되던 문제 해결
큐가 끝났는데 주문은 안 잡히던 문제 큐 처리 결과가 SUCCESS로 떨어지는데, 정작 주문 매칭은 자동으로 안 돌던 케이스를 잡음. 결제대행사에서 입금 통지가 온 뒤 큐가 멀쩡히 처리되고 SUCCESS 상태까지 도달했는데, 그 다음 단계인 "어떤 주문에 이 입금을 붙일지" 매칭이 별도 스케줄러나 수동 호출에 의존하던 구조였음. 증상 - 입금 통지
읽기 → -
결제 승인 거짓 성공으로 인한 정산 오류 수정
거짓 성공(false SUCCESS) 한 건이 부른 사고 결제대행사 두 곳의 응답 핸들러에서 **승인 실패인데 SUCCESS 로 찍히는 케이스**를 잡았음. 정산 다음 날 파트너 잔액이 비어있다는 문의로 발견. 회고 정리. 무엇이 문제였나 핸들러가 결제대행사의 raw 응답을 파싱할 때, 일부 에러 케이스에서 결과 코드가 비어 들어옴. 비어있으면 디
읽기 → -
로그인 사용자 기반 상품 필터링 기능 추가
feat: 로그인 사용자 id 기반 상품 필터링 로직 추가 기능 구현.
읽기 → -
계좌 인증과 포인트 충전 페이지 신규 추가
feat: 계좌 인증 및 포인트 충전 페이지 추가 기능 구현.
읽기 → -
상품 목록 서버사이드 페이징 통일
feat: 상품 옵션 처리 및 페이징, 카테고리 로직 개선 서버사이드 페이징을 표준화하는 작업이었음. 여러 목록 페이지가 각자 다른 방식으로 페이징을 구현하고 있어서 통일함. MyBatis 쿼리 패턴 xml <select id="selectList"> SELECT * FROM product WHERE status = 'ACTIVE' <i
읽기 → -
쇼핑몰 상품 옵션·주문 트랜잭션 안정성 개선
feat: 쇼핑몰 플랫폼 상품 리스트 및 상세 UI 개선 상품 목록부터 주문까지 이어지는 흐름을 정비했음. 특히 상품 옵션 처리와 페이징, 카테고리 필터가 한 번에 엮이는 부분이 까다로웠음. 상품 옵션 처리 구조 java // 옵션 유무 분기 if (product.hasOption()) { model.addAttribute("options"
읽기 → -
Cafe24 상품·배송 정보를 자체 DB에 배치 동기화
feat: Cafe24 상품 및 배송 동기화 기능 추가 Cafe24 상품과 배송 정보를 자체 DB에 동기화하는 배치를 구현했음. Cafe24 Open API를 호출해서 우리 쪽 상품 테이블에 매핑하는 구조임. 동기화 플로우 Cafe24 API → 상품 목록 조회 → 자체 DB UPSERT → 변경분 감지 → 알림 API 호출 제한 대응 C
읽기 → -
파트너 계층별 수수료 정산 배치 설계
feat: 파트너 레벨 설정 및 쿠폰 수익 분리를 위한 SQL 추가 배치 작업은 운영 중에 터지면 치명적이라 스케줄링 설계를 꼼꼼히 해야 함. 배치 설계 원칙 - 멱등성: 동일 조건으로 여러 번 돌아도 같은 결과 - 실패 로그: 어떤 건이 실패했는지 추적 가능해야 함 - 부분 성공: 일부 실패해도 나머지는 처리 계속 - 알림: 오류 발생 시 담당자
읽기 → -
약관·정책 상세 페이지 추가
feat: 약관/정책 상세 페이지 및 관련 데이터 추가 JSP UI 작업은 레거시 환경에서 어떻게 사용성을 올릴 수 있는지 계속 고민하게 만듦. 테이블 레이아웃 개선 모바일에서 가로 스크롤 없이 보이게 하는 게 과제였음. 카드형 뷰로 폴백 처리함. jsp <%-- PC: 테이블 형태 --%> <div class="admin-table-wrappe
읽기 → -
파트너 레벨 목록을 DB 동적 조회로 전환해 코드 수정 없이 관리
fix: JSP 동적 파트너 레벨 필터링 및 불필요한 폴백 로직 제거 파트너 관리 기능 정비 작업임. 계정 발급, 레벨 설정, 수수료 설정이 한 화면에서 유기적으로 동작해야 해서 꼼꼼히 짜야 했음. 파트너 등록 필수값 | 필드 | 필수 여부 | 검증 | |------|--------|------| | 상호명 | 필수 | NOT NULL | | 대표
읽기 →