정산 출금 수수료 KPI에 PG사 차감 누락 수정

정산 출금 모달의 수수료 수익 KPI에 PG사 차감액이 반영되지 않던 버그를 수정했다. 변경 파일은 뷰/스타일 1개. 얼핏 작은 수정 같지만 금융 도메인에서 수치 KPI가 틀리면 그 숫자를 보고 의사결정을 내리는 사람이 생기고, 그 피해는 꽤 뒤늦게 발견된다. 운영 쪽에서 "이번 달 수수료 수익이 이 정도면 괜찮겠다"라고 판단한 뒤에야 실제 값이 다르다는 걸 알게 되는 상황. 수치 버그는 UI 버그와 다르게 눈에 잘 안 띈다는 게 더 무섭다.

PG 차감이 KPI에서 빠지는 이유

결제 흐름을 단순하게 보면 "사용자가 결제하면 금액이 들어온다"처럼 보이지만, 실제로 정산 통장에 꽂히는 금액은 이미 PG사 수수료가 차감된 뒤다. 흐름을 단계별로 쪼개면:

수수료 수익 KPI를 계산할 때 "서비스가 가져가는 수수료"만 따지는 경우가 많다. PG 차감을 포함해야 실제 마진이 보이는데, 초기 구현에서 이 부분이 누락된 채로 집계되고 있었음. 표시된 수치가 항상 실제보다 높게 나왔을 것이고, 이 화면의 숫자를 기준으로 판단이 이뤄졌다면 그 판단 자체가 흔들리게 된다.

이런 버그가 생기는 패턴은 대체로 비슷하다.

첫째, 정산 계산 로직과 화면 표시 로직이 분리돼 있을 때 어느 한쪽에서만 PG 차감을 처리하고 나머지는 raw 값을 그대로 쓰는 경우. 백엔드 API가 이미 차감 완료 금액을 내려줄 때 프론트에서 한 번 더 뺄 필요가 없는데, 역으로 API가 차감 전 값을 내리면 프론트에서 처리해야 한다. 어느 쪽이 책임지는지 암묵적으로만 정해져 있으면 중간에서 빠지기 쉽다.

둘째, 기능 추가 시점마다 집계 쿼리나 계산 로직을 복사해 쓰다가 한쪽만 PG 차감 컬럼을 추가하고 다른 쪽은 빼먹는 경우. "정산 리스트" 화면은 반영이 돼 있는데 "출금 모달 KPI"는 초기 버전 코드를 그대로 가져온 탓에 차감이 없는 상태로 남아 있는 것. 이번 건도 후자에 가까웠음. 화면 렌더링 쪽에서 집계된 수수료를 표시할 때 PG 차감 전 값을 직접 참조하고 있었다.

수정 내용과 검증

수정 자체는 화면 렌더링 로직과 프론트 스크립트 두 군데였다. KPI 수치를 표시하는 컴포넌트가 PG 차감 후 금액을 참조하도록 바꿨고, 관련 계산식도 함께 정리했음.

수정 전후 구조를 개략적으로 보면:

// Before: PG 차감 전 원금 기준으로 표시
const feeRevenue = settlement.fee_amount;

// After: PG 차감액을 반영한 실 수익 기준으로 표시
const feeRevenue = settlement.fee_amount - settlement.pg_fee_amount;

단순해 보이는 한 줄이지만, 이 값이 KPI 카드에 찍히고 그 카드를 보고 "이번 달 수수료 수익이 얼마"라는 판단이 나온다. 한 줄의 무게가 컨텍스트에 따라 완전히 달라지는 사례다.

수정 후 검증 순서:

• 버그 재현: 수정 전과 동일한 조건으로 정산 출금 모달을 열어 수치 캡처
• 수정 후 동일 조건 재확인: PG 차감 반영 여부 직접 눈으로 확인
• 관련 화면 cross-check: 정산 리스트, 출금 내역 등 다른 화면의 집계와 숫자 비교

cross-check 단계가 생각보다 중요하다. 화면 하나를 고쳤는데 다른 화면과 숫자가 달라지면, 어느 쪽이 맞는 건지 다시 따져야 한다. 이번에는 수정한 쪽이 정합성을 맞추는 방향이었고 다른 화면과도 일치했음. 만약 cross-check에서 차이가 발생했다면, 어느 화면이 올바른 기준인지를 먼저 확정한 다음 나머지를 맞춰야 했을 것이다.

금융 도메인에서 숫자 버그를 대하는 법

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

특히 결제/정산 도메인은 "대충 맞는 것 같다"로 넘어가면 안 된다. 수치 KPI는 의사결정의 근거가 되는 순간 단순한 UI 버그가 아니라 판단 오류로 이어진다. 수치 버그는 특정 조건에서만 틀린 값이 나오는 경우도 많아서, 운이 나쁘면 오랫동안 발견이 안 된다. 이번처럼 PG 차감이 구조적으로 항상 빠진다면 매번 틀리니 그나마 빨리 잡히는 편이지만, "특정 PG사 or 특정 결제 방식에서만" 차감이 빠진다면 꽤 오랜 시간이 지난 뒤에야 이상하다는 게 보인다.

이번 버그를 수정하면서 다시 정리한 체크리스트:

• 같은 로직이 다른 경로에도 있는지 - 중복 집계 코드가 있다면 함께 수정
• 수정이 기존 정상 케이스를 망가뜨리지 않는지 - 회귀 방지
• 해당 화면 또는 API에서 실제 동작 직접 확인
• 관련 숫자를 다른 화면과 cross-check

단순히 증상만 픽스하는 게 아니라 왜 발생했는지 원인을 파악하는 게 먼저다. "PG 차감이 빠졌다"는 증상이고, "프론트 렌더링 로직이 raw 값을 직접 참조하고 있었다"가 원인이다. 원인을 알면 비슷한 패턴이 다른 곳에도 있는지 훑어볼 수 있다. 이번에도 같은 방식으로 복사된 코드가 있는지 확인하고, 위험한 케이스는 함께 정리했음.

개발 습관 면에서 몇 가지는 계속 유지하고 있다. 변경 전에 현재 수치나 동작을 메모해두는 것, 커밋 메시지에 "무엇을"보다 "왜"를 담으려는 것, 논리적으로 독립된 단위로 커밋을 쪼개는 것. 작은 커밋이 쌓이면 나중에 어느 변경에서 문제가 생겼는지 찾기 훨씬 쉽다. 금융 도메인에서 수치가 갑자기 이상해졌을 때 "어느 배포 이후부터 틀렸는가"를 빠르게 pinpoint할 수 있는 게 작은 커밋의 진짜 가치다.

엣지 케이스를 꼼꼼히 따지는 게 귀찮게 느껴질 때도 있다. 근데 그걸 넘어가면 나중에 같은 버그로 다시 오는 시간이 더 크다. 특히 돈 관련 수치는 잘못된 숫자를 믿고 쓴 사람이 생긴 뒤에야 발견되는 경우가 많아서, 발견 즉시 고치는 게 최선이다. 나중에 고치면 "그때 그 수치 믿고 판단했는데" 하는 소급 문제까지 따라온다.