개발 slecs

매출 차트 결제 완료 필터 누락 버그 수정

목차

analytics 쪽 매출 차트 버그를 수정했다. SQL 매퍼 파일 하나, 쿼리 2건에 payment_status = 'PAID' 필터를 추가한 게 전부다. 변경 줄 수로 보면 몇 줄 안 되지만, 이 버그가 왜 생겼는지, 어디까지 영향을 미쳤는지 파악하는 데 꽤 시간을 썼다.

왜 틀린 숫자가 나왔나

매출 집계 쿼리에서 결제 상태 필터가 빠져 있었다. PAID 건만 잡아야 하는데, PENDING이나 FAILED 상태의 결제까지 합산되고 있던 것. 금액 기준으로 보면 취소·실패 건이 매출로 잡히는 셈이라 차트 숫자가 실제보다 부풀어 있었다.

원인 파악은 기댓값과 실젯값을 직접 비교하는 방식으로 좁혔다. 어드민에서 보이는 매출 합계와 DB에서 직접 SUM으로 뽑은 숫자를 비교했을 때 차이가 생기는 지점을 찾으면, 어느 쿼리가 범인인지 거의 바로 나온다. 이런 방식으로 쿼리 2건 모두 같은 패턴으로 필터가 없다는 걸 확인했다.

결제 상태 컬럼이 있는데 왜 처음부터 안 걸었는지는 짐작이 가는 부분이 있다. 초기 개발 단계에서 결제 상태가 한 가지뿐이었거나, 테스트 환경에서는 모든 데이터가 PAID라 차이가 안 보였을 가능성이 높다. 나중에 PENDING, FAILED 케이스가 실제로 쌓이기 시작하면서 비로소 숫자가 어긋나기 시작했을 것이다.

수정 내용과 확인 방법

변경은 SQL 매퍼 파일 1개에서 WHERE 절에 payment_status = 'PAID' 조건을 추가하는 것으로 끝났다.

-- 수정 전
SELECT DATE(paid_at) AS dt, SUM(amount) AS revenue
FROM orders
WHERE created_at BETWEEN :start AND :end
GROUP BY dt

-- 수정 후
SELECT DATE(paid_at) AS dt, SUM(amount) AS revenue
FROM orders
WHERE payment_status = 'PAID'
  AND created_at BETWEEN :start AND :end
GROUP BY dt

같은 패턴이 다른 쿼리에도 있는지 매퍼 파일 전체를 훑었다. 매출 관련 집계가 나오는 곳은 전부 확인했고, 위험한 케이스는 이번에 함께 수정했다. 하나만 고치고 나왔다가 비슷한 버그로 다시 돌아오는 건 두 배로 비효율적이다.

검증은 간단하게 했다. 수정 전후로 같은 날짜 범위를 DB에서 직접 뽑아 숫자를 비교하고, 관련 화면이 여러 개 있어서 서로 같은 숫자를 가리키는지 cross-check했다. 숫자가 맞아떨어지면 끝.

버그 수정 때 항상 챙기는 체크 항목은 대략 이렇다.

  • 같은 로직이 다른 경로에도 있는지 (매퍼 파일 내 중복 쿼리, 유사 API 엔드포인트)
  • 수정이 기존 정상 케이스를 망가뜨리지 않는지 (PAID 건 집계가 기존과 동일한지)
  • 해당 화면에서 실제 동작 확인
  • 관련 숫자를 다른 화면이나 리포트와 cross-check

엣지 케이스를 꼼꼼히 따지는 게 귀찮아 보여도, 나중에 같은 버그로 다시 오는 시간 비용이 훨씬 크다.

금융 도메인 숫자는 틀리면 신뢰가 깎인다

기능 하나가 단순히 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감한다. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링, 권한 체크가 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 사용자에게 이상한 화면이 나온다.

특히 결제/매출 도메인은 숫자 하나가 틀리면 "이 어드민 믿을 수 있나?"로 이어진다. 대시보드 숫자를 내부적으로 신뢰하지 못하면 의사결정 자체가 흔들리고, 그게 누적되면 차트를 아예 안 보게 된다. "대충 맞는 것 같다"로 넘어가면 반드시 나중에 다시 돌아온다.

결제 상태 필터 같은 조건은 집계 쿼리를 짤 때 기본값처럼 붙어야 하는 것들이 있다. 어떤 상태의 데이터까지 포함할 것인지 명시적으로 결정하고 쿼리에 반영해야, 나중에 새로운 상태값이 추가됐을 때도 집계 로직이 의도대로 동작한다. 필터가 없으면 새 상태가 생기는 순간 조용히 숫자가 틀어진다.

개발 습관 차원에서도 몇 가지를 유지하려고 한다. 변경 전 현재 동작을 수치로 메모해두고, 수정 후 같은 케이스로 확인하는 것. 커밋 메시지는 "무엇을"보다 "왜"를 담으려고 노력한다. 이번 커밋도 payment_status 필터 추가보다는 매출 차트 쿼리에서 미결제 건 포함 버그 수정 - PAID 상태만 집계하도록 조건 추가에 가깝게 썼다. 작은 커밋을 자주 쌓으면, 나중에 어느 변경에서 뭔가 깨졌는지 찾는 시간이 훨씬 줄어든다.

이어보기

댓글 0

첫 댓글 달아줘.