파트너 잔액 정산 배치 버그 수정

파트너 잔액 스냅샷 배치에서 엣지 케이스 처리가 빠져 있었다. 증상은 특정 조건에서 잔액 계산이 틀리거나 오류가 발생하는 것. 그냥 두면 파트너 정산 숫자가 어느 날 갑자기 안 맞는 상황이 생길 수 있어서, 증상 픽스보다 원인 파악부터 시작했다.

실행 시각은 00:10에서 02:05로 옮겼다. 단순히 시간대를 미룬 게 아니라, 전제 데이터가 이 시점 이후에 안정화된다는 판단에서 나온 결정이다. 배치 로직이 아무리 정확해도, 소스 데이터가 아직 마감 처리 중인 시점에 돌면 스냅샷이 중간 상태를 찍어버린다. 이걸 뒤늦게 깨달으면 "숫자가 가끔 틀린다"는 리포트로 반드시 다시 돌아온다.

배치 실행 시각이 갖는 의미

정산 도메인에서 배치 타이밍은 생각보다 중요하다. 집계 배치가 소스 데이터의 마감 완료 시점보다 앞서 돌면 중간값을 읽게 된다. 일별 마감이 자정을 넘겨 처리되는 케이스-트랜잭션 롤업, 포인트 정산, 외부 연동 데이터 싱크 같은 것들-는 배치 스케줄을 보수적으로 잡아두는 게 맞다.

# 소스 마감이 01:30~02:00 사이로 예상될 때
CRON = "5 2 * * *"   # 02:05 실행 - 완료 추정 시각 + 여유 5분

# 실행 소요 시간이 길면 다음 날 배치와 슬롯이 겹칠 수 있으므로
# (소요 시간 + 여유 시간)을 고려해 창을 잡는다

여유 5분이 별것 아닌 것 같지만, 마감 처리가 예상보다 늦어질 가능성을 감안하면 무시하기 어렵다. 반대로 너무 늦추면 파트너 측이 잔액 조회하는 시간대에 스냅샷이 아직 없는 문제가 생긴다. 결국 소스 데이터 완료 타임라인을 파악하고 적절한 균형점을 찾는 작업이다.

엣지 케이스 수정

내부 클래스 2개에서 처리되지 않은 케이스가 있었다. 발생 조건 자체가 흔하지 않아서 오히려 테스트에서 잘 안 걸렸던 것 같다. 흔하지 않은 케이스일수록 발견이 늦어지고, 발견됐을 때는 이미 데이터가 꽤 쌓인 이후인 경우가 많다.

수정 범위는 백엔드 로직만으로 끝나지 않았다. 화면 렌더링과 프론트 스크립트도 같이 건드렸다. 백엔드에서 올바른 값을 내더라도 뷰에서 잘못 표현하면 결국 사용자 입장에서는 버그다. 정산 화면에서 숫자가 하나라도 이상하면 "시스템 문제 아닌가요?"로 바로 이어지기 때문에, 뷰 레이어까지 같이 확인하는 게 맞다고 생각한다.

수정 후에는 아래 순서로 확인했다.

• 버그가 발생하던 조건을 직접 재현해서 정상 동작 확인
• 기존에 잘 되던 정상 케이스가 깨지지 않는지 회귀 확인
• 관련 화면에서 숫자를 cross-check - 같은 값을 다른 경로로 계산하는 화면이 있으면 맞춰봄
• 비슷한 처리 패턴이 코드베이스 다른 곳에도 있는지 확인하고, 같은 구멍이 있으면 같이 수정

마지막 항목이 귀찮아서 넘기고 싶을 때가 있다. 근데 이걸 건너뛰면 같은 유형의 버그 리포트가 두 달 후에 다른 파트너, 다른 화면으로 다시 들어온다. 그 시간 비용이 훨씬 크다.

금융 도메인에서 숫자를 대하는 방식

"대충 맞는 것 같다"는 판단이 가장 위험하다. 잔액이 실제와 단 몇 원 차이가 나도 신뢰 문제로 이어질 수 있는 도메인이다. 수치를 다룰 때 "왜 이 숫자가 나오는가"를 설명할 수 있어야 한다고 생각하고 작업한다. 설명하지 못하면 맞아도 운 좋은 것이다.

배치나 집계 로직을 건드릴 때마다 반복하는 원칙이 있다.

커밋을 논리적으로 쪼개는 것도 같은 이유다. "배치 타이밍 조정"과 "엣지 케이스 처리 추가"가 분리된 커밋으로 남아 있으면, 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 훨씬 빠르다. 한꺼번에 몰아서 커밋하면 그 추적 자체가 또 하나의 작업이 된다.

사내 서비스라도 SQL 집계, 상태 처리, 예외 케이스, 화면 렌더링, 권한이 전부 연결돼 있다. 어느 한 레이어에서만 고쳐도 되겠지 하고 넘기면, 실제로 틀린 건 다른 레이어였던 경우가 종종 있었다. 전체 경로를 머릿속에 넣고 들여다보는 습관이 결국 재작업을 줄여준다.