자동화
n8n / 스크립트 / 봇
-
SNS 영상 감지와 OAuth 리다이렉트 오류 동시에 수정
구글 로그인이 또 깨졌다 오랜만에 사이드 프로젝트 손봤더니 OAuth가 안 됐음. 콘솔에는 redirect_uri_mismatch. 도메인 옮긴 걸 까먹은 게 원인이었음. 등록된 redirect와 실제 요청 URL이 슬래시 한 글자 차이로 어긋나 있었음. - 콘솔 → 인증 정보 → 승인된 리디렉션 URI 갱신 - 로컬/스테이징/프로덕션 3개 환경 따로
읽기 → -
비회원 구매 흐름에 핀 검증과 주문 자동매칭까지 완성
비회원 구매에 마침표 찍은 날 이커머스 플랫폼에 비회원 구매 흐름 붙이는 작업이 드디어 끝남. 회원만 받던 구조에 비회원 진입로를 뚫어야 했는데, 뚫는 김에 핀 검증·배송지 입력·주문-회원 자동매칭까지 한 번에 묶음. 분리해서 배포하면 비회원이 결제까지 갔다가 매칭 누락으로 고아 주문 생길 게 뻔해서 묶어서 가는 게 맞다고 판단함. 핀 검증, 보안과
읽기 → -
파트너코드 소문자 입력 시 매칭 오류 3중 정규화로 해결
파트너코드 입력 시 대문자 강제 변환 이슈 파트너 가입 화면에서 코드 입력 필드에 소문자를 쳤더니 그대로 저장되는 케이스를 발견함. 정책상 파트너코드는 전부 대문자(A-Z, 0-9)인데, 일부 사용자가 소문자로 입력하고 그대로 등록되니 조회·매칭 단계에서 어긋났음. 어떤 게 문제였나 - 프론트단에서 toUpperCase() 변환을 입력 시점에 거는
읽기 → -
정산 사전 시뮬레이션 화면과 수수료 체계 문서화로 파트너 문의 대응
정산 미리보기 화면이 필요했던 이유
읽기 → -
충전 잔액 만료 배치를 원장 구조로 개선한 과정
충전 만료 배치 만들면서 깨달은 것들
읽기 → -
정산 배치 OOM·이중보정·추적 누락을 한꺼번에 개선
페이지네이션 없이 돌리던 대조 배치를 손봄
읽기 → -
입금 웹훅 구조를 레지스트리 패턴으로 전환해 은행 추가 용이성 개선
배경 연락처 송금 기능에 입금 통보 받을 은행이 한 곳 더 늘어남. 기존엔 진입 컨트롤러에서 은행 코드별 if-else로 분기하던 구조라 추가할 때마다 같은 파일을 또 건드려야 했음. 이번에 인터넷전문은행 한 곳 더 붙이라는 요청 받았는데, 같은 자리를 또 손대기 싫어서 레지스트리 패턴으로 갈아엎기로 함. 무엇을 바꿨나 - 결제대행사 웹훅 수신 진입점
읽기 → -
결제 웹훅 중복 처리를 멱등성 락으로 차단
결제대행사 Webhook이 같은 건을 두 번 때리는 문제 운영 중 결제대행사에서 같은 결제 건에 대해 동일한 웹훅이 두 번, 세 번 들어오는 케이스가 누적됨. 첫 호출에서 정상 처리됐는데 두 번째 호출이 잔액을 한 번 더 건드리거나 알림이 중복 발송되는 사고가 발생했음. 원인을 정리하면 이런 흐름이었음. - 결제대행사가 응답 ACK를 못 받으면 일정
읽기 → -
결제대행사 웹훅 멱등 처리와 명세 불일치 극복기
결제대행사 API 연동, 명세서부터 다시 읽음 결제대행사 연동 작업 들어가면서 받아둔 명세서 PDF를 처음부터 다시 정독함. 이전에 한 번 훑었을 때는 "어차피 표준 PG 흐름이지" 싶어서 대충 봤는데, 막상 코드로 옮기려니까 필드 단위에서 막히는 부분이 한둘이 아니었음. 특히 헷갈렸던 포인트: - 승인 응답과 webhook 통보 메시지의 필드 이름
읽기 → -
AI 분류로 자동입금 무한 재시도와 새벽 운영 알람을 잡다
문제 상황 자동입금 확정 단계에서 실패 메시지가 들어오면 무조건 재시도 큐에 다시 넣고 있었음. 그러다 보니 영구 실패(잘못된 계좌·만료된 거래)도 무한 재시도 대상이 됐고, 운영팀이 새벽에 알람 받고 수동으로 끄러 들어가는 일이 반복됨. 대표적으로 들어오는 메시지가 이런 식임. [입금알림] 거래종료 / 금액불일치 / 한도초과 / 일시오류 겉으
읽기 → -
송금 대사 배치로 원장·결제·큐 불일치 자동 감지
연락처 송금 대사 배치를 만들게 된 이유 운영 들어간 지 한 달쯤 됐을 때 파트너 한 곳에서 "어제 송금 건 합계가 안 맞는다"는 문의가 들어왔음. 큐에 쌓인 송금 요청, 결제대행사로 넘긴 실제 출금, 우리 원장 잔액 차감 — 이 셋이 따로 노는 순간이 가끔 있다는 걸 그제서야 발견함. 사람이 매일 아침 SQL 돌려서 맞추고 있었는데 이게 지속 가능하지
읽기 → -
파트너 정산 송금을 접근성 서비스로 자동화한 과정
송금 자동화 배경 파트너 정산 처리량이 늘면서 수기 송금 부담이 한계점 도달. 결제대행사 정산 사이클 밖의 즉시 송금 건은 사람이 직접 은행 앱을 두드려야 했음. 안드로이드 접근성 서비스로 은행 앱 폼을 자동으로 채우는 보조 수단을 도입함. 결제 플랫폼 본 흐름은 그대로 두고, 운영팀 손이 닿는 부분만 줄이는 게 목표였음. - 메신저 알림 수신 → 송
읽기 → -
메신저 송금봉투 자동수령 누락 버그 수정
메신저 송금봉투 자동수령이 안 먹던 이유 파트너 정산 자동화 작업 중에 외부 메신저 송금봉투 알림이 들어와도 자동수령이 안 되는 케이스를 발견함. 알림 메시지는 분명히 들어왔는데 수령 처리가 안 되고 그대로 만료되는 상황. 이미 수동으로 처리하던 운영팀이 한참 쌓아둔 뒤에 알려줬음. 미안해서 바로 파봤음. 원인은 메시지 파서의 정규식 기존 파서는
읽기 → -
결제 콜백 자동수신으로 수동 입금 매칭 루프 제거
자동수신 결과를 받기 시작함 결제대행사에서 보내는 자동 입금 결과를 그동안 사람이 하루 한 번 손으로 매칭하던 구조였음. 누락 건이 가끔 생겼고, 정산 마감 직전에 발견되면 새벽에 다시 들어와 메우는 일이 반복됐음. 이번에 콜백을 받는 엔드포인트를 새로 붙여서 그 루프를 끊었음. 신규 API에서 챙긴 포인트는 세 가지였음. - **멱등성**: 같은
읽기 → -
가상계좌 입금 알림을 다중 은행 채널로 확장해 누락 해소
은행 알림에서 가상계좌 입금 URL을 자동으로 받아오는 경로에 손댔음. 기존엔 메신저 푸시 한 채널만 후킹해서 처리했는데, 일부 은행은 자체 푸시/SMS로만 결과를 쏴주니 누수가 생김. 파트너 화면에서 "입금됐는데 왜 반영 안 됨?" 문의가 한 주에 두어 건씩 올라왔음. 무엇을 바꿨나 주요 시중은행 두 곳(A, B) 알림을 별도 경로로 캡처하도록 텄음
읽기 → -
파트너 입금 정산 자동화로 야간 누락 제로 달성
왜 자동화했나 파트너 입금 확인을 매번 손으로 처리하다 보니 누락이 생김. 메신저로 알림 와서 → 사람이 브라우저 열고 → 링크 타고 들어가서 → 내용 확인 → 다시 내부 시스템에 등록하는 패턴이 반복됐는데, 야간엔 처리가 늦어져서 정산이 밀림. "이거 왜 사람이 함?" 싶어서 파이프라인으로 묶음. 처리 흐름 | 단계 | 주체 | 역할 | |---
읽기 → -
결제 알림 오프라인 유실 없애고 자동수령 안정화
시작 오늘은 메신저 자동수령 안정화 작업을 한 바퀴 돌렸음. 단말에서 결제 알림을 잡아 백엔드로 흘려보내는 모듈인데, 네트워크 끊겼을 때 알림이 통째로 사라지는 게 오래된 골칫거리였음. 한 방에 잡으려고 세 갈래로 손댔음. 오프라인 큐잉 기존엔 알림 받자마자 바로 HTTP 호출. 지하철/엘리베이터에서 끊기면 그대로 소실됐음. 로컬 DB에 1차 적재
읽기 → -
입금 큐 성공 후 주문 매칭이 자동으로 안 되던 문제 해결
큐가 끝났는데 주문은 안 잡히던 문제 큐 처리 결과가 SUCCESS로 떨어지는데, 정작 주문 매칭은 자동으로 안 돌던 케이스를 잡음. 결제대행사에서 입금 통지가 온 뒤 큐가 멀쩡히 처리되고 SUCCESS 상태까지 도달했는데, 그 다음 단계인 "어떤 주문에 이 입금을 붙일지" 매칭이 별도 스케줄러나 수동 호출에 의존하던 구조였음. 증상 - 입금 통지
읽기 → -
가상계좌 웹훅 암호화 필드 이중 디코딩 버그 수정
fix: VBANK_CHARGE Webhook 암호화 필드 이중 URL decode 버그 수정 Webhook 처리 로직에서 꽤 골치 아픈 이슈를 잡았음. 핵심은 이중 URL decode 문제임. 문제 발생 배경 결제대행사 Webhook은 POST body로 암호화된 필드를 넘겨주는데, 이 값이 URL-encoded 상태로 들어옴. 서버 프레임워크가
읽기 → -
결제 웹훅 이중 URL 디코딩으로 인한 시그니처 검증 오류 수정
fix: VBANK_CHARGE Webhook 시그니처 검증 시 URL-encoded trstnId를 primary로 변경 Webhook 처리 로직에서 꽤 골치 아픈 이슈를 잡았음. 핵심은 이중 URL decode 문제임. 문제 발생 배경 결제대행사 Webhook은 POST body로 암호화된 필드를 넘겨주는데, 이 값이 URL-encoded 상태
읽기 →