개발
코드 / 아키텍처 / 디버깅
-
출금 실패 알림과 포인트 조회 오류 동시 수정
출금 실패 복구에 긴급 알림 붙임 결제대행사 webhook 처리 중 출금 실패가 났을 때, 자동 복구는 돌아가는데 운영자가 모르고 지나가는 사고가 있었음. 새벽에 터지면 다음날 아침에 발견해서 정산 마감 직전에 허둥대는 패턴이 반복됨. 복구 자체보다 **인지 지연**이 진짜 리스크라는 걸 늦게 깨달음. 알림 분기를 단순하게 잡았음. | 트리거 | 채
읽기 → -
결제 큐에서 재시도 초과 건이 무한 반복되던 문제 해결
무한 재시도 지옥에서 빠져나옴 큐에서 작업 꺼내올 때 retry_count 조건이 빠져있었음. max_retry 도달한 작업도 계속 다시 집어가는 구조였음. 결제대행사 응답 지연으로 한 번 실패한 건이 영원히 큐를 떠다녔던 거. 어떻게 발견했는지 파트너 정산 모니터링 보다가 실패 누적이 비정상적으로 많은 걸 발견함. 같은 트랜잭션 ID가 로그에 수
읽기 → -
은행 입금 연동 오류 응답 파싱과 필수값 검증 개선
사건 요약 - 은행 파트너 입금 호출에서 간헐적 실패가 발생, 사용자 화면에는 "처리 실패"만 노출됨 - Step2 진입 시 일부 필수값이 누락된 채 호출되어 NPE 로 흐름이 끊김 - 운영팀이 원인 파악을 못해 같은 케이스를 반복 문의받았음 두 갈래로 손봄 입금 유틸의 응답 파싱과 Step2 입력 검증, 두 군데를 같은 변경에 묶었음. 응답 파싱은
읽기 → -
입금 크롤링을 HTTP 직접 호출로 교체해 응답 10배 빠르게
출발점 입금 내역 확인용 유틸이 헤드리스 브라우저로 은행 사이트를 띄워서 DOM 긁는 구조였음. 의존성 무겁고, 셀렉터 한 번 어긋나면 통째로 멈춤. 새벽에 알람 받고 일어난 적이 한두 번이 아니라서 진짜로 한 번 갈아엎고 싶었음. 무엇을 바꿨나 실제 동작을 패킷 캡처로 까보니 결국 로그인 토큰 받고 거래내역 조회 엔드포인트 두세 번 때리는 게 전부였
읽기 → -
입금 통보 파서에 AI 검증 얹어 정산 수기 보정 60% 줄임
배경 이커머스 결제 플랫폼에서 파트너별 입금 통보 메시지를 수신해 자동 매칭하는 기능이 있었음. 문제는 결제대행사·은행마다 포맷이 제각각이라 정규식이 폭발적으로 늘어났다는 것. 기존 파서는 새 포맷 하나 추가될 때마다 분기 로직이 누더기처럼 붙음. 입금자명 한 글자 누락되면 매칭 실패했고, 그게 누락 데이터로 쌓여서 운영팀이 매일 수기 보정함. 구
읽기 → -
컴포넌트 스캔 범위 확장으로 터진 빈 이름 충돌 해소
서버가 안 뜬다 월요일 아침 출근하자마자 빌드는 통과했는데 기동 단계에서 컨테이너가 죽음. 로그 맨 아래 한 줄이 모든 걸 설명해줬음. ConflictingBeanDefinitionException: Annotation-specified bean name 'xxxController' for bean class [com.example.biz.XxxCo
읽기 → -
결제 플랫폼 빈 이름 충돌로 서버 부팅 실패 해결
빈 이름 충돌로 서버가 안 떴던 날 이커머스 결제 플랫폼 백엔드를 띄우는데 갑자기 부팅 실패. 로그 끝까지 내려가지도 않고 컨텍스트 초기화 단계에서 죽음. 처음엔 단순 의존성 문제인 줄 알았는데, 메시지를 천천히 읽어보니 빈 이름이 중복됐다는 얘기였음. 원인 찾기 스택을 위로 거슬러 올라가면서 확인한 것들: - 같은 도메인의 컨트롤러 두 개가 동
읽기 → -
결제 플랫폼 서버 기동 실패, 컨트롤러 빈 이름 충돌로 해결
서버가 안 뜸 오전에 결제 플랫폼 모듈 한 군데 손보고 로컬에 띄우는데 기동 자체가 실패함. 로그 끝부분만 잘라보면 "동일한 빈 이름이 이미 정의되어 있다"는 메시지가 떡하니 박혀 있었음. 코드는 컴파일 통과했는데 컨테이너 초기화 단계에서 막힌 케이스. | 증상 | 원인 | 영향 | |---|---|---| | 컨테이너 초기화 실패 | 동일 이름 빈
읽기 → -
브라우저 자동화 격리로 세션 충돌 없애고 확인 작업 속도 개선
심볼릭 링크에서 실제 파일로 agent-browser 스킬 추가하면서 같이 정리한 게 AGENTS.md 처리 방식임. 원래는 다른 문서를 참조하는 형태로 두고 있었는데, 도구가 그 참조를 따라가지 못하는 케이스가 자꾸 생겨서 그냥 실제 파일로 박아버림. 겉보기엔 똑같은데, 도구가 읽을 때 동작이 달라짐. | 구분 | 이전 | 변경 후 | |---|-
읽기 → -
폐업 사업자 정산 오류 막으려 진위확인 API와 알림 로그 관리 도입
사업자 진위확인 외부 API 붙이기 파트너 등록 화면에서 사업자번호 검증을 외부 API로 처리하기로 함. 기존엔 입력값을 그냥 믿고 저장했는데, 실제로 폐업·휴업 사업자 데이터가 섞여서 정산할 때 골치 아팠음. 검증 응답에서 챙긴 필드: | 필드 | 의미 | |---|---| | 상태코드 | 계속/휴업/폐업 | | 과세유형 | 일반/간이/면세 | |
읽기 → -
결제 거래 실시간 동기화 API 설계와 멱등성 확보
배경 결제 플랫폼 모니터링 도구에서 거래 이력을 외부 시스템과 맞춰야 하는 요구가 있었음. 기존엔 새벽 배치로 한 번씩 긁어왔는데, 파트너 쪽에서 실시간에 가까운 동기화를 요청. 배치 주기를 줄이는 건 한계가 있어서 동기화용 API를 따로 뽑기로 함. 설계 포인트 처음엔 "최근 N분치 가져오기" 식으로 만들려다가, 멱등성을 못 잡으면 중복 적재가
읽기 → -
입금자명 파싱 다단계 분류와 정산 계좌 조회 엔드포인트 분리
입금자명 파싱, 정규식 한 줄로는 안 됨 문자 메시지에서 입금자명 뽑는 로직 손봤음. 처음엔 정규식 한 줄로 끝낼 수 있을 줄 알았는데, 실제 데이터 까보니 케이스가 너무 많았음. - 은행마다 메시지 포맷이 다름 (콜론 위치, 줄바꿈, 특수문자) - 영문/한글 이름 혼합 - 법인명 뒤에 담당자명 붙는 케이스 ((주)○○ 홍길동) - 광고 문구가 본문에
읽기 → -
송금 URL로 은행 자동 판별하는 구조 짜기
캡처된 송금 URL을 어떻게 받을지 고민함 스마트폰에서 연락처 송금을 누르면 은행 앱이 뜨는 게 일반적인데, 우리는 한 칸 앞에 끼어들어야 했음. 사용자가 송금 직전에 URL을 캡처해 넘겨주면, 그걸 보고 어느 은행인지 판별하고 후속 흐름을 잇는 구조. 문제는 은행마다 URL 포맷이 제각각이라는 점. 은행 판별을 어떻게 짰나 처음엔 정규식 한 줄
읽기 → -
쿠폰 매입 신청·정산 흐름을 상태머신으로 안정화
쿠폰 매입 신청 관리, 왜 필요했나 이커머스 파트너 정산 흐름에서 발행된 쿠폰 중 안 팔린 잔량을 다시 사들이는 절차가 필요했음. 기존엔 발행 이력만 시스템에 있었고 매입은 메일+엑셀로 수기 처리 중이었음. 운영팀이 월별 분량 늘면서 누락·중복 신청 사고 두 건 터지고 나서야 짬이 남. 설계 핵심 세 흐름으로 분리함: - 매입 신청 접수 (파트너
읽기 → -
정지 파트너 결제 메시지를 컨트롤러 입구에서 즉시 차단
정지 파트너인데 메시지가 계속 들어옴 이커머스 결제 플랫폼에서 파트너를 정지시켰는데, 결제대행사 쪽 모니터링 메시지가 계속 들어오는 문제가 발견됨. 정지 사유가 사기 의심이든 계약 해지든, 일단 정지 걸린 시점부터는 어떤 입금/결제 이벤트도 우리 시스템 안쪽으로 흘러들면 안 됐음. 문제는 컨트롤러에서 메시지를 받자마자 파싱 → 매칭 → 잔액 반영까지
읽기 → -
연락처 송금 결제수단 추가로 콜백과 매칭 로직 전면 재작성
연락처 송금이 결제수단으로 들어왔을 때 이커머스 결제 흐름에 새 결제수단이 하나 끼어들었음. 기존 카드/가상계좌/포인트 옆에 "연락처 송금"이 들어오는 작업. 처음엔 단순히 결제수단 enum 하나 늘리는 줄 알았는데, 까보니 매칭 로직이 본체였음. 매칭이 진짜 일이었음 연락처 기반이라 "보낸 사람 번호"와 "받을 사람 번호"가 정확히 매핑돼야 함
읽기 → -
결제 승인 거짓 성공으로 인한 정산 오류 수정
거짓 성공(false SUCCESS) 한 건이 부른 사고 결제대행사 두 곳의 응답 핸들러에서 **승인 실패인데 SUCCESS 로 찍히는 케이스**를 잡았음. 정산 다음 날 파트너 잔액이 비어있다는 문의로 발견. 회고 정리. 무엇이 문제였나 핸들러가 결제대행사의 raw 응답을 파싱할 때, 일부 에러 케이스에서 결과 코드가 비어 들어옴. 비어있으면 디
읽기 → -
연락처이체 자동화 오류 13건을 조건 대기와 이중 검증으로 해결
13개가 한꺼번에 터졌다 연락처이체 웹 자동화가 또 깨졌음. 은행별 페이지 구조가 미묘하게 달라서 한 곳 고치면 다른 데서 터지는 두더지잡기. 이번엔 분산해서 잡지 말고 13개 케이스 한꺼번에 모아서 정리함. 증상은 비슷했음: - "이체 성공"으로 찍혔는데 실제 거래는 미체결 - 페이지 전환 도중 다음 step 클릭해서 element not found
읽기 → -
은행별 입금 감시 오류 분류와 멱등성으로 이중 처리 방지
입금 감시 로직, 은행마다 다르게 터지는 게 문제였음 여러 은행 핸들러에서 입금 완료 감시 로직이 들쭉날쭉이라 정리한 회고. 같은 "입금 확인"인데 은행별로 응답 포맷, 타임아웃 패턴, 에러코드가 다 달라서 분기마다 한 번씩 장애가 났음. 무엇이 문제였나 기존 구조는 각 은행 핸들러가 자기 방식대로 예외를 던지고, 상위 스케줄러는 그걸 단순히 ca
읽기 → -
송금 수취인 계좌 오매칭을 파트너 식별자 조회로 해결
파트너 식별자 기반 계좌 조회로 갈아탄 이유 연락처 송금 흐름 손볼 때 가장 거슬렸던 게 수취인 계좌 매칭 로직임. 기존엔 입력값(연락처 + 이름) 조합으로 계좌를 끌어왔는데, 동명이인이거나 같은 번호를 공유하는 파트너가 끼면 엉뚱한 잔액 계좌로 꽂힐 위험이 있었음. 이번에 파트너 식별자(partnerSn)를 1차 키로 잡고 계좌를 조회하도록 갈아엎음.
읽기 →