결제 수단 추가로 드러난 정산 쿼리 누락과 분기 구조 개선

새 결제 수단 붙이기

이커머스에서 결제대행사 한 곳을 추가함. 기존엔 카드/가상계좌만 받던 흐름에 새 수단이 끼어들면서, 결제 요청 분기에서 슬슬 균열이 보이기 시작함.

처음엔 그냥 if 한 줄 더 넣고 끝날 줄 알았는데, 실제로 붙여보니 응답 콜백 포맷이 달라서 파싱 단계부터 다시 짜야 했음. 단순 추가가 아니라 "이미 너무 비대해진 분기"를 건드리는 작업이었던 것.

무엇이 문제였나

• 결제 수단마다 콜백 필드명이 달라서 매번 새 분기가 늘어나는 구조
• PENDING → CONFIRMED 상태 전환 트리거가 수단별로 흩어져 있음
• 통계 쿼리가 결제 수단을 하드코딩으로 WHERE 절에 박아둔 상태

세 번째가 제일 심각했음. 새 수단 하나 추가했더니 리포트용 쿼리 7개가 동시에 누락 데이터를 뱉기 시작함.

쿼리 개선 포인트

복합 인덱스로 바꾼 게 컸음. 정산용 일별 집계 쿼리가 2.3초 → 180ms 로 떨어짐. 옵티마이저가 인덱스 머지를 안 타서 그동안 풀스캔 비슷하게 돌고 있었던 것.

-- before: 새 수단 추가할 때마다 7곳 수정
WHERE pay_type IN ('CARD','VBANK','ACCOUNT')

-- after: 메타 조인으로 자동 반영
JOIN pay_method m ON m.code = c.pay_type
WHERE m.is_active = 1

배운 것

• 결제 수단 추가는 "데이터 모델 추가"임. 컨트롤러 분기 추가가 아님. 이거 깨닫는 데 반나절 씀.
• 콜백 파서를 수단별 인터페이스로 분리해두니, 다음 결제대행사 붙일 때 같은 컨트롤러를 안 건드려도 됨
• 리포트 쿼리는 새 수단 추가 시 "검사 대상 1순위". 데이터는 조용히 누락되니까 알람도 안 옴
• PENDING/CONFIRMED 전환 로직은 수단별로 보지 말고 상태 머신 한 곳에 모으는 게 맞음. 다음 리팩터링 후보로 적어둠

PG 한 곳 더 붙일 일이 곧 있는데, 이번에 분리해둔 파서 인터페이스가 얼마나 잘 굴러갈지 그때 진짜 검증될 듯. 일주일짜리 작업이 이틀로 줄면 성공.

다음.