-
로컬 DB 싱글턴화로 초기화 속도 개선하고 커밋 컨벤션 정리
커밋 컨벤션 정리하다가 메시지가 꼬임 오늘 작업은 분량으로 보면 가벼운데 시간을 의외로 잡아먹었음. 스킬/에이전트 가이드 문서 두 개, 진입점 화면 클래스 라이프사이클 한 군데, 로컬 DB 추상 레이어를 한 커밋에 묶다가 prefix 표기를 잘못 적어서 다시 정리함. 무엇이 문제였나 처음엔 그냥 feat: chage git 이라고 적었음. 보다시피
읽기 → -
브라우저 자동화 격리로 세션 충돌 없애고 확인 작업 속도 개선
심볼릭 링크에서 실제 파일로 agent-browser 스킬 추가하면서 같이 정리한 게 AGENTS.md 처리 방식임. 원래는 다른 문서를 참조하는 형태로 두고 있었는데, 도구가 그 참조를 따라가지 못하는 케이스가 자꾸 생겨서 그냥 실제 파일로 박아버림. 겉보기엔 똑같은데, 도구가 읽을 때 동작이 달라짐. | 구분 | 이전 | 변경 후 | |---|-
읽기 → -
폐업 사업자 정산 오류 막으려 진위확인 API와 알림 로그 관리 도입
사업자 진위확인 외부 API 붙이기 파트너 등록 화면에서 사업자번호 검증을 외부 API로 처리하기로 함. 기존엔 입력값을 그냥 믿고 저장했는데, 실제로 폐업·휴업 사업자 데이터가 섞여서 정산할 때 골치 아팠음. 검증 응답에서 챙긴 필드: | 필드 | 의미 | |---|---| | 상태코드 | 계속/휴업/폐업 | | 과세유형 | 일반/간이/면세 | |
읽기 → -
기기 교체 후 수신 메시지 복구를 위한 서버 동기화 구현기
왜 만들었나 - 기기 교체하면 이전 수신 내역이 통째로 날아갔음. 사용자 문의가 꾸준히 들어옴 - 로컬에만 쌓아둔 데이터라 복구 경로가 아예 없었음 - 서버에 보존돼 있는 원본을 끌어와 로컬과 병합하는 흐름이 필요했음 구조 잡기 | 레이어 | 역할 | |--|--| | 진입 화면 | 최초 진입 시 동기화 트리거 | | 설정 화면 | 수동 재동기화 +
읽기 → -
간편결제 입금 자동 매칭으로 파트너 정산 클레임 해소
왜 자동 감지가 필요했나 - 간편결제 송금으로 들어오는 입금 건은 그동안 운영팀이 화면 보면서 손으로 매칭했음 - 입금량이 늘면서 매칭 지연 → 파트너 정산 클레임 누적 - 정산 파이프라인 끝단이 수동이라 앞단 자동화 효과가 다 깎이고 있었음 두 가지 선택지를 두고 고민함 결제대행사 쪽 입금 알림 채널과 자체 폴링을 같이 검토했음. | 방식 | 장점
읽기 → -
결제 거래 실시간 동기화 API 설계와 멱등성 확보
배경 결제 플랫폼 모니터링 도구에서 거래 이력을 외부 시스템과 맞춰야 하는 요구가 있었음. 기존엔 새벽 배치로 한 번씩 긁어왔는데, 파트너 쪽에서 실시간에 가까운 동기화를 요청. 배치 주기를 줄이는 건 한계가 있어서 동기화용 API를 따로 뽑기로 함. 설계 포인트 처음엔 "최근 N분치 가져오기" 식으로 만들려다가, 멱등성을 못 잡으면 중복 적재가
읽기 → -
결제 콜백 자동수신으로 수동 입금 매칭 루프 제거
자동수신 결과를 받기 시작함 결제대행사에서 보내는 자동 입금 결과를 그동안 사람이 하루 한 번 손으로 매칭하던 구조였음. 누락 건이 가끔 생겼고, 정산 마감 직전에 발견되면 새벽에 다시 들어와 메우는 일이 반복됐음. 이번에 콜백을 받는 엔드포인트를 새로 붙여서 그 루프를 끊었음. 신규 API에서 챙긴 포인트는 세 가지였음. - **멱등성**: 같은
읽기 → -
파트너 정산 은행 도메인 누락으로 송금 인증 실패하던 문제 수정
채팅 메시지 속 은행 링크를 못 찾았음 파트너 정산 채널에서 송금 인증 캡처 대신 메시지 앱 링크를 그대로 붙여넣는 케이스가 점점 늘었음. 메시지 본문에서 은행 도메인을 뽑아 송금 사실을 검증하는 로직이 있는데, CS팀에서 "특정 은행만 매번 인증 실패가 난다"는 리포트가 연달아 들어옴. 원인: 도메인 화이트리스트 노후화 은행 URL 추출기는 정규
읽기 → -
가상계좌 입금 알림을 다중 은행 채널로 확장해 누락 해소
은행 알림에서 가상계좌 입금 URL을 자동으로 받아오는 경로에 손댔음. 기존엔 메신저 푸시 한 채널만 후킹해서 처리했는데, 일부 은행은 자체 푸시/SMS로만 결과를 쏴주니 누수가 생김. 파트너 화면에서 "입금됐는데 왜 반영 안 됨?" 문의가 한 주에 두어 건씩 올라왔음. 무엇을 바꿨나 주요 시중은행 두 곳(A, B) 알림을 별도 경로로 캡처하도록 텄음
읽기 → -
입금자명 파싱 다단계 분류와 정산 계좌 조회 엔드포인트 분리
입금자명 파싱, 정규식 한 줄로는 안 됨 문자 메시지에서 입금자명 뽑는 로직 손봤음. 처음엔 정규식 한 줄로 끝낼 수 있을 줄 알았는데, 실제 데이터 까보니 케이스가 너무 많았음. - 은행마다 메시지 포맷이 다름 (콜론 위치, 줄바꿈, 특수문자) - 영문/한글 이름 혼합 - 법인명 뒤에 담당자명 붙는 케이스 ((주)○○ 홍길동) - 광고 문구가 본문에
읽기 → -
파트너 입금 정산 자동화로 야간 누락 제로 달성
왜 자동화했나 파트너 입금 확인을 매번 손으로 처리하다 보니 누락이 생김. 메신저로 알림 와서 → 사람이 브라우저 열고 → 링크 타고 들어가서 → 내용 확인 → 다시 내부 시스템에 등록하는 패턴이 반복됐는데, 야간엔 처리가 늦어져서 정산이 밀림. "이거 왜 사람이 함?" 싶어서 파이프라인으로 묶음. 처리 흐름 | 단계 | 주체 | 역할 | |---
읽기 → -
송금 URL로 은행 자동 판별하는 구조 짜기
캡처된 송금 URL을 어떻게 받을지 고민함 스마트폰에서 연락처 송금을 누르면 은행 앱이 뜨는 게 일반적인데, 우리는 한 칸 앞에 끼어들어야 했음. 사용자가 송금 직전에 URL을 캡처해 넘겨주면, 그걸 보고 어느 은행인지 판별하고 후속 흐름을 잇는 구조. 문제는 은행마다 URL 포맷이 제각각이라는 점. 은행 판별을 어떻게 짰나 처음엔 정규식 한 줄
읽기 → -
쿠폰 매입 신청·정산 흐름을 상태머신으로 안정화
쿠폰 매입 신청 관리, 왜 필요했나 이커머스 파트너 정산 흐름에서 발행된 쿠폰 중 안 팔린 잔량을 다시 사들이는 절차가 필요했음. 기존엔 발행 이력만 시스템에 있었고 매입은 메일+엑셀로 수기 처리 중이었음. 운영팀이 월별 분량 늘면서 누락·중복 신청 사고 두 건 터지고 나서야 짬이 남. 설계 핵심 세 흐름으로 분리함: - 매입 신청 접수 (파트너
읽기 → -
결제 알림 오프라인 유실 없애고 자동수령 안정화
시작 오늘은 메신저 자동수령 안정화 작업을 한 바퀴 돌렸음. 단말에서 결제 알림을 잡아 백엔드로 흘려보내는 모듈인데, 네트워크 끊겼을 때 알림이 통째로 사라지는 게 오래된 골칫거리였음. 한 방에 잡으려고 세 갈래로 손댔음. 오프라인 큐잉 기존엔 알림 받자마자 바로 HTTP 호출. 지하철/엘리베이터에서 끊기면 그대로 소실됐음. 로컬 DB에 1차 적재
읽기 → -
정지 파트너 결제 메시지를 컨트롤러 입구에서 즉시 차단
정지 파트너인데 메시지가 계속 들어옴 이커머스 결제 플랫폼에서 파트너를 정지시켰는데, 결제대행사 쪽 모니터링 메시지가 계속 들어오는 문제가 발견됨. 정지 사유가 사기 의심이든 계약 해지든, 일단 정지 걸린 시점부터는 어떤 입금/결제 이벤트도 우리 시스템 안쪽으로 흘러들면 안 됐음. 문제는 컨트롤러에서 메시지를 받자마자 파싱 → 매칭 → 잔액 반영까지
읽기 → -
입금 큐 성공 후 주문 매칭이 자동으로 안 되던 문제 해결
큐가 끝났는데 주문은 안 잡히던 문제 큐 처리 결과가 SUCCESS로 떨어지는데, 정작 주문 매칭은 자동으로 안 돌던 케이스를 잡음. 결제대행사에서 입금 통지가 온 뒤 큐가 멀쩡히 처리되고 SUCCESS 상태까지 도달했는데, 그 다음 단계인 "어떤 주문에 이 입금을 붙일지" 매칭이 별도 스케줄러나 수동 호출에 의존하던 구조였음. 증상 - 입금 통지
읽기 → -
연락처 송금 결제수단 추가로 콜백과 매칭 로직 전면 재작성
연락처 송금이 결제수단으로 들어왔을 때 이커머스 결제 흐름에 새 결제수단이 하나 끼어들었음. 기존 카드/가상계좌/포인트 옆에 "연락처 송금"이 들어오는 작업. 처음엔 단순히 결제수단 enum 하나 늘리는 줄 알았는데, 까보니 매칭 로직이 본체였음. 매칭이 진짜 일이었음 연락처 기반이라 "보낸 사람 번호"와 "받을 사람 번호"가 정확히 매핑돼야 함
읽기 → -
결제 승인 거짓 성공으로 인한 정산 오류 수정
거짓 성공(false SUCCESS) 한 건이 부른 사고 결제대행사 두 곳의 응답 핸들러에서 **승인 실패인데 SUCCESS 로 찍히는 케이스**를 잡았음. 정산 다음 날 파트너 잔액이 비어있다는 문의로 발견. 회고 정리. 무엇이 문제였나 핸들러가 결제대행사의 raw 응답을 파싱할 때, 일부 에러 케이스에서 결과 코드가 비어 들어옴. 비어있으면 디
읽기 → -
연락처이체 자동화 오류 13건을 조건 대기와 이중 검증으로 해결
13개가 한꺼번에 터졌다 연락처이체 웹 자동화가 또 깨졌음. 은행별 페이지 구조가 미묘하게 달라서 한 곳 고치면 다른 데서 터지는 두더지잡기. 이번엔 분산해서 잡지 말고 13개 케이스 한꺼번에 모아서 정리함. 증상은 비슷했음: - "이체 성공"으로 찍혔는데 실제 거래는 미체결 - 페이지 전환 도중 다음 step 클릭해서 element not found
읽기 → -
은행별 입금 감시 오류 분류와 멱등성으로 이중 처리 방지
입금 감시 로직, 은행마다 다르게 터지는 게 문제였음 여러 은행 핸들러에서 입금 완료 감시 로직이 들쭉날쭉이라 정리한 회고. 같은 "입금 확인"인데 은행별로 응답 포맷, 타임아웃 패턴, 에러코드가 다 달라서 분기마다 한 번씩 장애가 났음. 무엇이 문제였나 기존 구조는 각 은행 핸들러가 자기 방식대로 예외를 던지고, 상위 스케줄러는 그걸 단순히 ca
읽기 →