영중소 차액정산 자동화 회고: 정책 데이터와 소급 정산을 시스템으로 흡수한 기록

1. 왜 이 문제를 해결해야 했는가

여신금융협회는 반기마다 전국 사업자를 대상으로 영세·중소·일반 사업자 구간 데이터를 제공해요. 이 데이터는 가맹점 수수료율에 직접적인 영향을 미쳐요.

문제는 이 데이터가 정적이지 않다는 점이었어요.

반기 중에도 가맹점의 구간이 변경됨
이미 처리된 과거 거래에도 새로운 수수료 기준이 적용되어야 함
처리 실수는 곧 매출 손실 또는 과다 정산으로 이어짐

기존 방식은 필요 시점에 데이터를 수작업으로 비교하고, 정산 대상 가맹점을 선별해 사람이 직접 검증하는 구조였어요.

데이터 규모가 커질수록 "이번 반기는 과연 다 맞게 처리됐을까?"라는 불안이 반복되고 있었어요.

2. 문제를 어떻게 정의했는가

처음에는 단순히 "데이터가 많다", "처리가 번거롭다"는 문제로 보였어요.

하지만 구조적으로 보면 핵심은 달랐어요.

정책 데이터는 반기 단위로 '다시 정의'됨
과거 거래와 현재 기준이 계속 충돌함
변경 이력이 명확히 남아 있지 않음

결국 정산 로직이 '현재 상태'만을 기준으로 설계되어 있었고, '시간에 따른 변화'를 시스템이 기억하지 못하고 있었어요.

그래서 문제를 다음과 같이 재정의했어요.

"정책 데이터의 변경 이력을 시스템이 직접 기억하고, 과거 거래에 대해 소급 정산할 수 없을까?"

3. 선택 가능한 대안들은 무엇이었는가

문제를 정의한 뒤, 몇 가지 접근을 검토했죠.

① 변경 가맹점만 선별하여 수작업 처리

초기 구현 비용이 낮음
하지만 누락 가능성 상존
검증 비용이 계속 사람에게 남음

→ 데이터 규모가 커질수록 리스크가 기하급수적으로 증가해요

② 최신 구간 데이터만 유지

시스템 구조는 단순
하지만 과거 거래와의 연결 불가
소급 정산 불가능

→ "정확성보다 편의성을 택하는 선택"이라고 판단

③ 원천 데이터 전체 저장 + 변경 이력 관리

데이터 용량은 증가
하지만 모든 시점의 상태 추적 가능
소급 정산 및 검증 구조화 가능

→ 정산 도메인에서는 가장 보수적이지만 가장 안전한 선택

4. 그래서 어떤 선택을 했는가

결론적으로 영중소 원천 데이터를 반기별로 모두 저장하고, 가맹점별 구간 변경 이력을 관리하는 구조를 선택했죠.

핵심 결정은 다음과 같았죠.

여신금융협회 제공 원천 데이터 전체 저장
반기별 스냅샷 유지로 시점 기준 데이터 확보
가맹점별 구간 변경 이력 테이블 설계
과거 거래와 변경 이력을 조인하여 차액 계산

이 선택의 목적은 명확했죠.

"정산 결과를 설명할 수 없는 시스템은, 결국 신뢰를 잃는다."

5. 구현에서 가장 중요했던 포인트

① 대용량 데이터 처리를 전제로 한 구조

반기마다 약 400만 건 이상의 데이터를 처리해야 했어요. 단순 전체 스캔은 현실적인 선택지가 아니었어요.

그래서

Spring Batch 기반 청크 처리
사업자번호 기준 인덱스 최적화
신규 / 변경 / 삭제 데이터 분리 처리

를 통해 반기 정산 작업이 안정적으로 반복 가능한 구조를 만들었죠.

② 변경 이력을 중심으로 한 정산 모델링

정산의 기준은 "현재 상태"가 아니라 거래 시점에 적용되어야 했던 상태였어요.

이를 위해

가맹점별 영중소 구간 변경 시점 기록
거래 발생 시점과 구간 이력을 매칭
차액 발생 여부를 시스템이 판단하도록 설계

정산 로직이 사람의 기억이 아니라 데이터의 시간 축을 기준으로 동작하도록 만들고자 했죠.

6. 결과는 무엇이 달라졌는가

구조 도입 이후 변화는 분명했죠.

반기 정산 프로세스 자동화
신규 및 구간 변경 가맹점 누락 위험 제거
과거 거래에 대한 소급 정산 및 검증 가능
수수료 적용 오류로 인한 매출 손실 리스크 제거

무엇보다 "이번 반기 정산은 맞을까?"라는 불안이 사라졌어요.

7. 이 경험을 통해 얻은 판단 기준

이 프로젝트를 통해 확실해진 기준이 있죠.

정책 데이터는 언제든 바뀐다는 전제로 설계해야 해요
정산 시스템은 '현재'보다 '이력'을 더 중요하게 다뤄야 해요
데이터 용량보다 무서운 것은, 설명할 수 없는 결과예요

정산 도메인에서의 신뢰는 속도가 아니라 추적 가능성에서 나온다는 점을 체감했죠.

8. 다음에 다시 한다면

초기에는 정책 데이터 변경 케이스를 더 촘촘히 시뮬레이션하지 못한 아쉬움이 있고요.

다음에는 정책 변경 시나리오를 먼저 정의하고, 그에 맞춰 데이터 모델을 검증하는 과정을 선행하고 싶어요.

정산 시스템은 "잘 돌아가는 것"보다 "언제든 설명 가능한 것"이 더 중요하다는 점을 다시 느꼈죠.