자동 결제 내역 분석을 위한 데이터 흐름 설계

필요한 데이터

아이디어에서 서비스까지 - 왜 SubTrack.AI인가에 이은 개발일지 2편이다. 이전에 기록된 내용을 기반으로 어떤 데이터가 필요할 것이고, 그 데이터가 어떻게 흐르고, 처리되고, 자동화로 이어지는지를 기록하고자 한다.

초기 분석용 (배치 기반)

데이터 유형	설명	수집 방식
카드/계좌 명세서	과거 3~6개월치 결제 이력 (금액, 상호명, 일시 등)	API 연동 or 파일 업로드 (CSV, PDF)
이메일 알림	결제 확인, 인보이스 등	Gmail, Outlook API (IMAP 연동)
상호명 DB	구독 서비스 여부 확인 (e.g. 넷플릭스, 어도비 등)	내장 DB or 크롤링
서비스 약관/플랜 정보	해지 조건, 요금 주기 등	크롤링 + RAG 기반 추출

데이터 흐름

시나리오

1단계: 사용자 데이터 입력

입력 방식 선택 UX

• 사용자는 다음 중 하나를 선택하거나 동시에 제출(필요하다면 API 호출로 자동 연동)
  • 카드/은행 API 연동 (OAuth)
  • 명세서 PDF or CSV 업로드
  • 이메일 연동 (Google, Outlook)

예: 사용자 A는 카카오뱅크 + 현대 카드 + Gmail 을 연동

2단계: 결제 내역 파싱

데이터 전처리

• PDF/CSV/이메일 내역에서 결제일, 금액, 상호명, 수단 등 추출
• 이중 거래 제거, 소액/1회성 결제 필터링 (예: 스타벅스 5,300원, 배달의민족 제외)

예: 넷플릭스 17,000원, 애플뮤직 8,900원, NCP 44,000원 등 추출됨

3단계: 반복 패턴 탐지

주기 추론 알고리즘

• 동일 상호명 + 유사 금액 + 일정 주기(예: ±2일) 조건으로 클러스터링
• 발생 횟수 ≥ 2 이상이면 구독 후보군으로 분류

상호명	금액	간격(일)	감지 여부
Netflix	17,000원	30일	✅ 정기 결제
Adobe	27,500원	31일	✅ 정기 결제
스타벅스	5,300원	불규칙	❌ 1회성 결제
Naver Cloud	44,000원	30일	✅ 정기 결제

4단계: 구독 여부 검증 (서비스 메타 + 약관 기반)

상호명 ↔ 서비스 DB 매칭

• 예: Netflix → ✅ 구독 서비스로 확인
• 예: Naver Cloud → ✅ 비즈니스용 SaaS로 확인

약관 RAG 분석

• 크롤링된 약관 텍스트에서:
  • 해지 조건, 요금 갱신 주기, 약정 여부 추출
• 예: “1년 약정, 매월 자동 청구” 등의 조건 추출

5단계: 사용자 확인 및 구독 리스트 구성

**결과 요약 화면 예시

“총 8개의 정기 결제를 발견했어요!**” 아래 구독 중 일부는 사용률이 낮거나 요금이 증가했을 수 있어요.

서비스명	금액	주기	상태	추천 행동
Netflix	17,000원	월간	유효	유지 추천
Adobe	27,500원	월간	요금 증가	대체 서비스 추천
Naver Cloud	44,000원	월간	무사용	해지 추천
애플뮤직	8,900원	월간	유효	유지

최종 등록 결과

선택된 구독 항목은 SubTrack.AI의 추적 대상이 되며, 이후 실시간 결제 감지, 요금 변화 추적, 자동 리마인드/해지/문의 등에 연결된다. 또한, 납부 예정일이 캘린더에 자동으로 반영된다.

실시간 추적용 (이벤트 기반)

데이터 유형	설명	수집 방식
실시간 결제 알림	신규 결제 발생 감지	카드사/은행 API의 Webhook 또는 Polling
이메일 수신 이벤트	“결제되었습니다” 유형 자동 분석	실시간 메일 감시 or 이메일 파서
반복 조건 기록	동일 상호명/금액/주기 로그	시스템 자동 저장 & 분석

데이터 흐름

시나리오

1단계: 실시간 결제 이벤트 수신

수집 방식

• Webhook / Pooling API를 통해 다음 채널에서 결제 발생 감지
  • 카드사 or 오픈뱅킹 API (결제 승인 이벤트)
  • 이메일 수신 이벤트 (ex: “결제되었습니다” 제목)
  • 간편결제 알림 (토스, 카카오페이 등)
  • POS 또는 가맹점 Webhook (기업용)

예: 6월 16일 오후 1:32, "ADOBE" 27,500원 카드 승인 감지됨

2단계: 기존 구독과 비교

중복 여부 판단

• 최근 결제 목록과 비교:
  • 동일 상호명 & 유사 금액이 일정 주기(30±2일 등)로 반복 중이라면 $\to$ 기존 구독 갱신
  • 전혀 새로운 상호명 or 금액이라면 $\to$ 신규 후보군 등록

예: Adobe는 이미 구독 등록된 항목 $\to$ 갱신으로 처리됨 예: “ENFJ Inc.”는 처음 등장한 상호명 $\to$ 신규 결제 후보로 분류됨

3단계: 정기성 판단 후보 등록

반복 가능성 분석

• 다음 요소를 기록:
  • 상호명
  • 금액
  • 결제 수단 (카드/계좌)
  • 일시
  • 이메일/영수증 텍스트
• 시스템은 이를 기반으로 2~3회 반복 시 구독으로 확정

예: 6/16 $\to$ ENFJ Inc. 9,900원 7/16 $\to$ 동일 금액, 동일 상호명 감지됨 $\to$ 정기 구독으로 자동 등록

4단계: 사용자 협업 루프

알림 & 선택 요청

“새로운 결제가 감지되었습니다. 이 항목은 반복될 가능성이 있어요. 추적할까요?”

• 등록해서 추적
• 보류 (일시 등록 안 함)
• 1회성으로 간주 (블랙리스트에 저장)

5단계: 후속 자동 처리로 연계

• 등록되면 이후 흐름은 기존 구독과 동일:
  • 납부 스케줄 자동 생성 (캘린더 반영)
  • 요금 이상 탐지 $\to$ 알림
  • 해지 조건 RAG or 비교 추천 등 실행 가능

후속 행동용 (분석 + 자동화)

데이터 유형	설명	수집 방식
캘린더 일정	납부 예정일, 해지 마감일 자동 등록	Google/Outlook Calendar API
사용자 행동 로그	추천 클릭, 해지 여부 등	클라이언트 이벤트 추적 SDK
유사 서비스 목록	대체 추천 제공용	크롤링 or 제휴 DB
자동화 로그	어떤 액션을 자동 수행했는지	내부 DB + 로그 기록

시나리오

등록된 구독 항목을 지속적으로 모니터링하고 요금 인상, 사용 빈도 저하, 계약 위험 등 정략적·정성적 이상 상태를 감지를 한다. 이후 알림, 자동화된 추천, 사용자 승인 후 실행까지 연결한다.

1단계: 정기 분석 트리거

트리거 방식	설명
주기적 실행	월 1회 or 사용자가 설정한 날짜에 전체 구독 상태 점검
행동 기반 실행	특정 항목에 변화가 생겼을 때 자동 점검 (ex: 요금 인상, 사용 로그 없음)
외부 이벤트	이메일 수신, 신규 약관 반영 등 외부 변화 감지 시

예: 매월 1일 오전, 지난달 결제 내역 전체 점검 시작

2단계: 요금/사용/변동 감지

요금 변화 분석

• 이전 결제 금액 대비 ±n% 이상 변화 감지
• 플랜 변경 여부 추론 (약관 + 이메일 본문 등으로)

사용률 분석

• 해당 서비스의 로그인 기록, 기능 사용 로그 없음
• 사용자가 직접 메모(“이번 달 안 씀”)한 경우

이상 패턴 감지

• 이중 결제 감지 (동일 서비스에서 다른 수단으로 결제 발생)
• 원래 정기 결제가 끊겼는데 새롭게 시작됨 (이중 과금 가능성)
• 예상 주기보다 빠르게 결제됨 (ex: 월간인데 2주 간격으로 두 번 청구)

3단계: RAG 기반 해석 + 리스크 판단

• 요금 인상 시 $\to$ 약관 변경이 있었는지 자동 확인
• 무료 체험 종료 시점 추론 (이메일/청구서 기반)
• 해지 마감 시점 도래 여부 확인

4단계: 사용자 알림 + 선택 루프

UX 메시지 예시

“이상 징후를 3건 감지했습니다.”

• “Adobe CC 요금이 22,000 $\to$ 27,500원으로 인상되었어요”
• “Naver Cloud 는 지난 45일간 사용 기록이 없어요”
• “Wix.com 은 같은 달에 2건 결제가 발생했어요”

$\to$ 사용자 선택:

• 자동 해지 요청
• 플랜 변경 안내 보기
• 다음 달까지 보류
• 무시하고 유지

5단계: 후속 자동 실행

항목	자동화 예
해지	해지 조건 확인 후 자동 양식 작성 or API 호출
고객 문의	”이중 결제 문의” 메일 자동 생성 + 담당자 연결
대체 서비스 추천	유사 서비스 요금 비교 → 전환 제안
캘린더 갱신	다음 결제일 리마인드 재설정, 또는 종료

궁금한 내용 정리

Pooling vs. Webhook

우선 두 방식을 비교하자면, 다음과 같다.

방식	설명	장점	단점
Polling (Pull)	일정 주기로 API 요청 → 데이터 비교	단순 구현	API 호출 낭비, 지연 발생
Webhook (Push)	결제가 발생하면 서버로 자동 이벤트 전송	실시간성 우수, 트래픽 최소화	지원 안 하는 서비스 많음

따라서, 계속 API를 요청하는 방식(Pooling)은 비효율적이고, 가능하다면 Webhook(push 방식)을 사용하는 것이 훨씬 낫다.

하지만, 대부분의 카드사/은행 Open API는 Pooling 방식만 지원한다. 그래서 기본적으로는 가장 최근 거래 내역을 n분마다 요청해서, 새로운 결제 발생 여부를 판단한다.

예: 매 10분마다 카카오뱅크 거래내역 조회 API 호출 $\to$ 최근 거래 비교 $\to$ 새로운 항목이면 처리

일부 금융 파트너사 또는 사설 서비스 API는 결제 승인/실패/취소 이벤트를 Webhook으로 전송해주며 B2B 기업용 PG사 연동에서 실시간 감지가 가능하다.

Webhook을 지원하지 않는 서비스가 많아서 이를 보완하기 위한 방법으로는 이메일/명세서 기반 감지 등이 있다. Gmail API나 IMAP 연동으로 메일 수신 이벤트 감지가 가능하다. 감지된 메일 제목이나 본문에 결제가 완료되었습니다 등의 키워드를 탐색하면 되긴 하지만, 간접적인 방법이라 정확도가 낮을 것으로 생각한다.

Webhook

한 시스템에서 다른 시스템으로 특정 이벤트가 발생했을 때, 자동으로 알림을 보내는 방식이다. 즉, 이벤트 발생하면, 지정된 URL로 HTTP 요청 (주로 POST)을 보내, 다른 시스템에 알리는 것이다. Webhook의 주요 특징:

• 실시간 데이터 교환: 이벤트 발생 시 즉시 데이터를 전달할 수 있다.
• HTTP 기반: HTTP 프로토콜을 사용하여 데이터를 전달한다.
• 콜백 방식: 지정된 URL로 콜백 요청을 보내어 알림을 전달한다.
• 다양한 이벤트 지원: 서버에서 발생하는 다양한 이벤트를 Webhook으로 알림할 수 있다.

병목 현상

초기 분석용 배치 프로세스에서 수천 명의 결제 이력을 받아와 처리하려면, 단순한 구조로는 성능, 비용, 안정성에서 병목이 생길 수밖에 없다. 이걸 해결하려면 아키텍처, 스케줄링, 저장 구조, 처리 방식까지 전방위 최적화가 필요하다.

위험 요소	내용
I/O 병목	API 호출량 증가 → 속도 지연 or 호출 제한 발생
메모리/CPU 부하	1000명의 거래내역을 한 번에 파싱하면 인스턴스 메모리 폭발 가능
시간 지연	대량 사용자 처리 시 UX 응답이 늦어짐 → “왜 이리 오래 걸려요?” 발생
서비스 실패 리스크	하나의 실패로 전체 배치 중단 위험

해결 방법으로는 비동기 분산 처리 구조를 도입 (Celery or AWS SQS/Lambda) 한다. 위 방식은 사용자 수와 무관하게 수평 확장이 가능하고, 실패한 작업만 재처리가 가능해서 안정성을 보장한다.

이외에도 아래 방법들이 있다.

1. 초기 분석을 “즉시 처리”에서 “예약 처리”로 분리
2. 데이터 소스 호출량 줄이기 (Delta + Paging + Chunking)
3. 결제 데이터 캐싱 (초기 분석 결과 저장)
4. 요약 결과만 먼저 보여주고, 정밀 분석은 지연 처리

빅데이터 처리

“수많은 유저 $\times$ 수많은 거래 내역 = 고속 처리 + 대용량 저장 + 유연한 스케일링” 이 핵심인데, 이를 계층적 빅데이터 처리 아키텍처로 대응

3줄로 정리하자면, 다음과 같다.

1. 거래 데이터는 RAM이 아닌 S3, Parquet, 분산 큐 등을 활용해 디스크 기반으로 저장하고 처리
2. 배치(Spark 등)와 스트리밍(Kafka 등)을 분리해 확장성 있고 빠른 처리를 구현
3. 분석 결과는 요약해 DB/Redis에 캐싱하고, 원본은 압축·샤딩해 열 지향 저장소에 보관