파트너 포털 외부 채널 수수료·정산 버그 수정

파트너 포털 작업은 외부 채널 수수료·정산 관련 버그 몇 가지를 잡는 일이었다. 규모 자체는 작았는데, 건드리는 영역이 금전 계산이라 꼼꼼하게 들어갔다.

외부 채널이란 결제 플랫폼 위에서 서비스를 제공하는 사업자 단위다. 채널별로 수수료 요율이 다르고, 하위 채널(서브채널)을 두는 구조면 계층별로 요율이 또 달라진다. 포털은 이 채널들이 자기 수수료 설정, 메뉴 권한, 하위 채널 목록을 직접 관리하는 화면이다. 백오피스가 아니라 파트너가 직접 쓰는 화면이다 보니, 잘못된 정보가 노출되거나 수정 후 반영이 안 되면 바로 문의로 이어진다.

잡은 버그들

크게 세 가지 유형이었다.

메뉴 노출 조건 오류. 채널 유형이나 권한에 따라 메뉴가 다르게 나와야 하는데, 조건 분기가 잘못 걸려 있었다. 봐선 안 되는 메뉴가 노출되거나, 반대로 필요한 메뉴가 안 보이는 경우. 서버사이드 권한 체크는 별도로 있어서 실제 데이터 접근까지 뚫리는 건 아니었지만, UI에서 메뉴가 잘못 나오는 것 자체가 혼란이다.

파라미터 바인딩 오류. 수수료 수정 폼에서 채널 ID나 요율 값이 요청에 제대로 안 실려 가는 문제였다. 폼 필드 name 속성이 서버 파라미터 이름과 안 맞거나, hidden input이 누락된 경우다. 이런 건 화면에서는 정상처럼 보이는데 서버에서 null로 들어오니까 디버깅 포인트를 찾는 게 좀 걸렸다.

화면 갱신 타이밍. 수수료를 수정하고 저장하면 성공 응답은 오는데, 목록이 즉시 안 바뀌는 문제. AJAX 요청 후 응답 콜백에서 목록을 다시 조회하도록 처리했다. 아래 패턴이다.

$.ajax({
  url: '/partner/channel/fee/update',
  method: 'POST',
  data: feeForm.serialize(),
  success: function(res) {
    if (res.success) {
      // 저장 성공 후 목록 재조회
      loadFeeList(channelId);
      showToast('수수료가 수정되었습니다.');
    }
  }
});

단순해 보이지만 이게 없으면 사용자는 저장됐는지 알 방법이 없다. 새로고침하거나 다른 메뉴 갔다 와야 바뀐 값이 보이는 상황이 된다.

테이블 컬럼 수 불일치. <thead>의 <th> 수와 <tbody>의 <td> 수가 안 맞는 케이스가 있었다. 브라우저가 자동으로 채워주다 보니 눈으로 보면 멀쩡해 보인다. 이 버그가 조용히 살아남는 이유가 여기 있다. 개발자 도구에서 Elements 탭으로 실제 DOM을 보면 브라우저가 맞춰놓은 흔적이 보인다. colspan이 필요한 컬럼에는 명시적으로 처리해서 정리했다.

수수료 계산과 정산 검증

수수료 계산 로직은 금전 관련이라 오류가 나면 바로 신뢰 문제가 된다. 계층별 요율을 다르게 적용하는 구조면 올림/버림 처리 방향도 신경 써야 한다.

통상적으로 쓰는 기준은 이렇다.

원 단위 처리를 사용자에게 유리한 방향으로 잡는 게 관행인 건 맞는데, 계층이 많아질수록 각 단계에서 버림이 쌓이면 총합과 차이가 생기기도 한다. 이 차이를 어느 레이어에서 흡수할지는 설계 시점에 명확하게 정해두는 게 좋다.

정산 배치는 멱등성이 핵심이다. 같은 정산 기간을 두 번 돌려도 결과가 동일해야 한다. 배치 시작 전에 해당 기간의 기존 데이터를 지우고 재생성하는 방식이면 멱등성을 맞추기 쉬운데, 이 경우 중간 상태가 잠깐 비어 있을 수 있으니 조회 타이밍을 고려해야 한다. INSERT 전 DELETE 패턴보다는 UPSERT나 상태값으로 처리 여부를 관리하는 쪽이 안전하다.

정산 UI 자체는 사용자가 가장 많이 보는 게 숫자다. 총 거래액, 수수료, 실수령액이 한눈에 들어오게 정렬되어야 한다. 천 단위 구분자와 '원' 단위 표기는 기본이고, 마이너스 금액은 빨간색으로 표시해서 시각적으로 바로 구분되게 하는 것도 중요하다. 금액 컬럼은 오른쪽 정렬이 자릿수 비교하기 훨씬 편하다.

작업하면서 남긴 메모

화면 갱신 이슈는 대부분 상태 동기화 문제다. 서버에는 저장됐는데 화면이 안 바뀐다면 대부분 성공 콜백에서 목록 재조회가 빠진 경우다. 반대로 저장이 실패했는데 화면이 바뀌는 것처럼 보이는 케이스도 있는데, 이건 응답 코드 확인 없이 무조건 목록을 갱신하도록 짜놓은 경우다. 응답 성공 여부를 반드시 체크하고 분기해야 한다.

테이블 렌더링 오류는 개발자 도구 Elements 탭에서 DOM을 직접 보는 게 제일 빠르다. 화면이 멀쩡해 보인다고 마크업이 맞는 게 아니다. 브라우저가 자동 보정해주는 영역이 생각보다 넓다. colspan 처리나 컬럼 수는 명시적으로 맞춰두는 게 나중에 동적으로 컬럼이 추가되거나 조건부로 숨길 때 사고를 예방한다.

작업 규모는 크지 않았다. 그래도 수수료·정산처럼 돈이 직결되는 화면에서 잘못된 데이터가 노출되거나 수정이 안 먹히는 상황은 운영 신뢰도에 직접 영향을 준다. 작은 버그 수정이 쌓이는 게 전체 시스템 안정성을 만든다는 걸 다시 확인한 작업이었다.