자동화
n8n / 스크립트 / 봇
-
결제대행사 정산 배치 로직 개선
결제대행사 시스템별 활성화 로직 추가 및 배치 간소화 2026-03-31에 배치 작업 관련 코드를 수정하거나 추가했음. 배치는 Spring @Scheduled로 주기적으로 실행됨. 만료 처리, 정산 집계, 상태 동기화 등 실시간 요청 흐름 밖에서 처리해야 하는 작업들을 담당함. 배치 목록 일부 | 배치 | 역할 | |---|---| | 쿠폰 만료
읽기 → -
Spring MVC 플랫폼 기능 개선과 무중단 배포 안정성 확보
20260330 0030 shorts batch 2026-03-30에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 - SQL 쿼리 작성 및 결과 매
읽기 → -
Spring MVC 내부 클래스 비즈니스 로직 개선
20260330 1200 shorts batch 2026-03-30에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 - SQL 쿼리 작성 및 결과 매
읽기 → -
Spring MVC 내부 클래스 개선과 무중단 배포 안정성 확보
20260330 1801 korea divided shorts 2026-03-30에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 - SQL 쿼리 작
읽기 → -
쇼츠 히스토리 전체 조회 기능 추가
20260330 1800 shorts history global 2026-03-30에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 - SQL 쿼리
읽기 → -
수수료 계층별 정산 배치와 미입금 알림 화면 추가
수수료 개요 화면 및 미입금 주문 알림 배치 추가 2026-03-28에 수수료 계산 또는 정산 관련 로직을 작업했음. 수수료 구조는 유통 계층별로 요율이 다르게 설정되는 차등 모델임. 하위 계층이 상위 계층보다 높은 요율을 부담하고, 그 차액이 상위 계층의 수익이 되는 구조임. 수수료 계층 예시 | 계층 | 요율 | 비고 | |---|---|--
읽기 → -
미정산 파트너 자동 정지
미정산 파트너 자동 정지 배치 추가 2026-03-27에 수수료 계산 또는 정산 관련 로직을 작업했음. 수수료 구조는 유통 계층별로 요율이 다르게 설정되는 차등 모델임. 하위 계층이 상위 계층보다 높은 요율을 부담하고, 그 차액이 상위 계층의 수익이 되는 구조임. 수수료 계층 예시 | 계층 | 요율 | 비고 | |---|---|---| | 최하위
읽기 → -
결제 알림 앱 Android 14·15 호환
v3.1: 자동수신 큐잉 시 원본 메시지 서버 전송 유지 및 플래그 추가 Android 앱(v3.1) 관련 작업을 진행했음. 결제 알림 수신·처리용 앱인데, 알림 캡처 → 파싱 → 서버 전송 흐름으로 동작함. 이번 작업에서는 안정성과 Android 버전 호환성을 중점적으로 개선했음. 주요 변경 | 항목 | 내용 | |---|---| | Andro
읽기 → -
Playwright 드라이버 자동 탐지·재시작
Playwright 드라이버 자동 탐지 및 재시작 개선, 메시지 자동수령 로직 추가 2026-03-26에 기능을 추가하거나 개선했음. 수정 파일: build.gradle, 내부 클래스, PlaywrightBrowserPool.java 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트
읽기 → -
결제 알림 캡처 안정화와 비회원 주문 매칭 버그 수정
원격 제어 서비스 안정화 및 MediaProjection 자동 승인 로직 개선 Android 앱(최신버전) 관련 작업을 진행했음. 결제 알림 수신·처리용 앱인데, 알림 캡처 → 파싱 → 서버 전송 흐름으로 동작함. 이번 작업에서는 안정성과 Android 버전 호환성을 중점적으로 개선했음. 주요 변경 | 항목 | 내용 | |---|---| | An
읽기 → -
정산 배치 재시도 큐 추가와 로그 레벨 정비
NO_MATCH 및 MANUAL_REQUIRED 큐 재시도 배치 추가 2026-03-25에 배치 작업 관련 코드를 수정하거나 추가했음. 배치는 Spring @Scheduled로 주기적으로 실행됨. 만료 처리, 정산 집계, 상태 동기화 등 실시간 요청 흐름 밖에서 처리해야 하는 작업들을 담당함. 배치 목록 일부 | 배치 | 역할 | |---|---
읽기 → -
외부 채널 수수료 정산 화면 버그 수정
파트너 Discord Webhook 필드 슈퍼관리자만 표시 2026-03-25에 외부 채널 관련 버그를 수정했음. 외부 채널은 결제 플랫폼을 통해 서비스를 제공하는 사업자 단위임. 채널별로 수수료 설정, 메뉴 권한, 하위 채널 관리 등이 개별로 동작함. 수정 내용 포털 메뉴 노출 조건, 파라미터 바인딩 오류, 화면 갱신 타이밍 등의 버그를 잡았음
읽기 → -
자동입금 배치 무한 재처리와 알림 폭탄 수정기
증상 새벽에 알림 채널이 폭발했음. 자동입금 처리 배치가 같은 건을 계속 재처리하면서 처리 완료 알림을 수백 건씩 쏘는 중이었음. 확인해보니 두 가지 문제가 겹쳐있었음. - 기동 시 리셋 로직이 PROCESSING 상태인 큐를 전부 PENDING 으로 되돌리고 있었음 - 처리 완료 직전 잠깐 PROCESSING 으로 머무는 건도 같이 리셋됨 - 그게
읽기 → -
결제 알림을 텔레그램·디스코드 이중화하고 비즈니스 로직에서 분리
알림 채널 이중화하면서 깨달은 것 운영 중 결제 이벤트가 발생하면 텔레그램으로만 쏘던 구조였는데, 채널이 한 곳이라 알림이 묻히거나 봇 토큰 만료 시 통째로 깜깜해지는 게 늘 마음에 걸렸음. 이번에 디스코드 웹훅을 추가하고, 기존 텔레그램 유틸도 손봤음. 왜 디스코드를 골랐나 후보가 슬랙/디스코드/이메일이었는데, 결정 기준은 단순했음. | 항목
읽기 → -
결제 웹훅 중복 수신 막고 정산 추적 로그 정비
웹훅 개선하면서 깨달은 것 결제대행사 쪽에서 들어오는 웹훅이 가끔 누락되거나 중복으로 찍히는 이슈가 있었음. 처음엔 "재시도 정책이려니" 하고 넘겼는데, 정산 데이터 검수하다가 같은 거래에 대해 콜백이 3번 들어온 케이스를 발견했음. 더는 못 미루겠다 싶어서 손댐. 무엇을 바꿨나 핵심은 두 가지. **웹훅 수신부 자체의 멱등성 보장**과 **로그를
읽기 → -
SNS 영상 감지와 OAuth 리다이렉트 오류 동시에 수정
구글 로그인이 또 깨졌다 오랜만에 사이드 프로젝트 손봤더니 OAuth가 안 됐음. 콘솔에는 redirect_uri_mismatch. 도메인 옮긴 걸 까먹은 게 원인이었음. 등록된 redirect와 실제 요청 URL이 슬래시 한 글자 차이로 어긋나 있었음. - 콘솔 → 인증 정보 → 승인된 리디렉션 URI 갱신 - 로컬/스테이징/프로덕션 3개 환경 따로
읽기 → -
비회원 구매 흐름에 핀 검증과 주문 자동매칭까지 완성
비회원 구매에 마침표 찍은 날 이커머스 플랫폼에 비회원 구매 흐름 붙이는 작업이 드디어 끝남. 회원만 받던 구조에 비회원 진입로를 뚫어야 했는데, 뚫는 김에 핀 검증·배송지 입력·주문-회원 자동매칭까지 한 번에 묶음. 분리해서 배포하면 비회원이 결제까지 갔다가 매칭 누락으로 고아 주문 생길 게 뻔해서 묶어서 가는 게 맞다고 판단함. 핀 검증, 보안과
읽기 → -
파트너코드 소문자 입력 시 매칭 오류 3중 정규화로 해결
파트너코드 입력 시 대문자 강제 변환 이슈 파트너 가입 화면에서 코드 입력 필드에 소문자를 쳤더니 그대로 저장되는 케이스를 발견함. 정책상 파트너코드는 전부 대문자(A-Z, 0-9)인데, 일부 사용자가 소문자로 입력하고 그대로 등록되니 조회·매칭 단계에서 어긋났음. 어떤 게 문제였나 - 프론트단에서 toUpperCase() 변환을 입력 시점에 거는
읽기 → -
정산 사전 시뮬레이션 화면과 수수료 체계 문서화로 파트너 문의 대응
정산 미리보기 화면이 필요했던 이유
읽기 → -
충전 잔액 만료 배치를 원장 구조로 개선한 과정
충전 만료 배치 만들면서 깨달은 것들
읽기 →