결제대행사 연동 제거로 충전 로직 버그까지 발견 정리

결제대행사 연동 삭제와 충전 로직 손질

오늘 작업은 두 갈래였음. 더 이상 트래픽이 들어오지 않는 결제대행사 연동을 들어내는 것, 그리고 충전 흐름에 쌓여있던 잔버그를 정리하는 것.

왜 들어냈는가

• 해당 결제대행사로 유입되는 트래픽이 사실상 0에 수렴
• 그런데 유지보수 비용은 그대로 발생 (콜백 검증, 환불 분기, 예외 처리)
• 다른 결제대행사 한 곳으로 통합 운영 중이라 둘을 둘 이유가 없었음

"안 쓰는 코드는 빨리 빼는 게 정답"이라는 걸 또 체감함. 죽은 분기 하나 살려두면 신규 기능 짤 때마다 그 분기까지 같이 고려해야 됨.

어디를 건드렸는가

라인 수는 -300쯤. 더 줄어들 줄 알았는데 의외로 적었음. 한 군데 박혀있는 줄 알았던 분기가 네 군데에 흩어져있던 게 문제였음.

충전 로직에서 발견한 버그

연동 삭제하면서 충전 흐름을 다시 따라가다가 두 가지를 찾음.

• PENDING row가 만들어진 뒤 콜백이 안 들어오면 영원히 PENDING으로 남음 → 만료 처리 누락
• 동일 주문번호 재요청 시 중복 row가 생성되는 윈도우가 좁게 존재함

만료 처리는 배치로 돌리도록 분리했고, 중복 방지는 unique 제약으로 막음.

-- 기존: 주문번호 단일 인덱스
-- 변경: (주문번호, 상태) unique
ALTER TABLE charge_log
  ADD CONSTRAINT uk_order_status UNIQUE (order_no, status);

unique 거는 거 자체보다 기존 데이터 정합성을 먼저 확인하는 절차를 빠뜨릴 뻔함. 운영 DDL 적용 전에 중복 row 카운트부터 떠봤더니 다행히 0건. 만약 1건이라도 있었으면 ALTER가 그대로 깨졌을 거고, 운영 트랜잭션 밀렸을 듯.

회고

• 죽은 연동은 빨리 들어낸다. 미루면 새 기능마다 부채가 붙음
• 코드 들어내면서 따라가는 리딩이 의외로 버그 발견 효과가 큼 (덕분에 두 건 잡음)
• DDL은 검증 → 적용 → 모니터링 순서. 한 번에 운영 들어가지 않기
• 결제수단 분기는 한 곳에 모아두자. 흩어지면 들어낼 때 누락이 생김

다음