특정 결제사 전용 스코프로 발급현황 조회 버그 수정
목차
가상계좌 발급현황을 조회하는 쿼리에 특정 결제사(제주 KP_PAY)로만 동작하도록 스코프를 제한하는 수정을 했다. SQL 매퍼 파일 한 곳에 조건을 추가한 작은 변경이었지만, 단순한 쿼리 튜닝이 아니라 결제 도메인에서 꽤 자주 마주치는 패턴 문제를 드러낸다.
가상계좌와 결제사별 구현의 차이
가상계좌는 온라인 결제에서 자주 쓰이는 수단으로, 고객에게 계좌번호를 임시 발급하고 그 계좌로 입금하면 거래가 확정되는 방식이다. 문제는 결제 플랫폼마다 가상계좌 발급 정책, 상태 관리, 만료 처리가 조금씩 다르다는 것이다. 어떤 플랫폼은 발급 후 일정 시간 내 입금이 없으면 자동 취소되고, 또 다른 플랫폼은 수동으로 관리하거나 다른 상태 코드를 쓴다. 이렇게 플랫폼별로 구현이 다르면, 발급현황을 조회할 때도 각 플랫폼의 로직에 맞춰야 한다.
이전에는 아마도 여러 플랫폼의 발급현황을 한 쿼리로 통합해서 조회하려고 했을 것 같다. 코드 재사용이나 단순함을 추구하는 건 좋은 의도지만, 실제로는 각 플랫폼의 세부 동작이 섞여버리면 버그가 생기기 쉽다. 특히 제주 결제 시스템(KP_PAY)의 발급현황 조회가 다른 로직과 충돌했거나 잘못된 데이터를 포함했을 수 있다.
SQL 매퍼에서 스코프를 명시화하는 이유
이번 수정은 단순히 WHERE 절에 결제사 = 'KP_PAY' 같은 조건을 추가한 것일 텐데, 이게 중요한 이유는 쿼리 수준에서 데이터 경계를 명확히 했다는 뜻이다.
<!-- Before (문제 있던 쿼리) -->
SELECT * FROM VA_ISSUE_HISTORY
WHERE status IN ('ISSUED', 'COMPLETED', 'TIMEOUT')
<!-- After (특정 결제사로 제한) -->
SELECT * FROM VA_ISSUE_HISTORY
WHERE payment_provider = 'KP_PAY'
AND status IN ('ISSUED', 'COMPLETED', 'TIMEOUT')
이렇게 명시적으로 조건을 넣으면, 개발자가 코드를 읽을 때 "아, 이 쿼리는 제주 전용이구나"가 바로 드러난다. 또한 DB 수준에서도 원치 않는 데이터를 들고오지 않으니, 애플리케이션 로직에서 추가로 필터링할 필요가 없다. 이건 성능뿐 아니라 데이터 정확성 관점에서도 중요하다.
유사 버그를 줄이기 위해 배워야 할 점
이런 수정은 보통 다음과 같은 순서로 발견된다. 먼저 운영 중에 "발급현황 조회가 이상하다"는 신고가 들어온다. 그럼 데이터베이스를 직접 조회해서 기대값과 실제값을 비교한다. 그 과정에서 "어? 다른 결제사의 기록까지 섞여 있네?"라는 걸 발견하고, 최종적으로 쿼리가 범위를 제한하지 않았다는 걸 깨닫는다.
결제 도메인에서는 이런 일이 자주 생기는데, 그 이유는 초기 개발 단계에서는 한두 개 결제사만 지원했다가 점점 더 추가되면서, 기존 쿼리나 로직을 모두 손대지 않고 새 결제사만 붙이려고 하기 때문이다. 결과적으로 "결제사 A 전용" 로직과 "결제사 B 전용" 로직이 섞여서 실행되는 상황이 생긴다.
이를 방지하려면, 결제사별 처리가 필요한 부분에서는 다음 중 하나를 선택해야 한다:
- 조건을 쿼리 수준에서 명시 (이번 수정처럼)
- 결제사별로 완전히 분리된 함수/메서드 만들기
- 전략 패턴(Strategy Pattern) 같은 설계로, 각 결제사 구현체가 독립적으로 존재하도록 하기
- 최소한 코드 주석으로 "이건 제주 전용", "이건 모든 결제사 공통" 같이 명기하기
코드리뷰 때도 이 부분을 꼼꼼히 봐야 한다. "이 쿼리가 정말 의도한 결제사만 대상으로 하는가?", "만약 새 결제사가 추가된다면 이 부분도 수정이 필요한가?"라는 질문을 항상 던진다.
마치며
이 수정은 작지만 실무에서는 매우 흔한 시나리오다. 여러 비즈니스 파트너나 결제 채널을 지원하다 보면, 어느 순간 "어? 이 로직은 어디까지 적용되는 거지?"라는 혼동이 생긴다. 그걸 방지하는 가장 간단한 방법이 바로 경계를 명확히 하는 것이다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.