영업대행사 출금요청에 운영자 계좌 노출

partner-portal 쪽에 새 기능을 하나 추가했다. 영업대행사가 출금요청을 올렸을 때 운영자 계좌 정보가 같은 화면에 보이도록 하고, relay-fee 저장 시 발생하던 UI 버그도 같이 잡았다. 변경된 파일은 뷰 2개, 내부 클래스 1개. 숫자만 보면 작은 작업인데 실제로는 설계부터 검증까지 꽤 신경 써야 했다.

왜 지금 이 기능이 필요했나

기존 출금요청 화면에는 신청 내역과 상태만 있었다. 그런데 실제 운영 흐름에서는 담당자가 요청을 처리할 때 운영자 계좌를 별도 화면에서 따로 찾아야 했고, 그게 맥락이 끊기는 포인트였다. 자잘한 불편이지만 하루에 수십 건 처리하는 담당자 입장에선 누적 피로가 꽤 된다.

relay-fee UI 버그는 값이 저장은 되는데 화면에 반영이 늦게 되거나 엉뚱한 값으로 보이는 케이스였다. 저장 성공 응답이 왔는데도 화면 상태가 업데이트되지 않는 흔한 AJAX 타이밍 문제. 이런 건 처음엔 "새로고침하면 맞잖아요" 하고 넘어가기 쉬운데, 결제 도메인에서 금액 숫자가 잠깐이라도 틀리게 보이면 담당자가 혼란을 겪고 재처리를 시도하는 사이드이펙트가 생긴다.

두 작업 다 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄다.

구현하면서 고민한 것들

계좌 데이터 노출 설계

운영자 계좌 정보를 출금요청 화면에 같이 보여주려면 기존 엔드포인트에 데이터를 얹거나 별도 API를 만들거나 둘 중 하나다. 이번엔 별도 엔드포인트로 갔다. 기존 API를 건드리면 다른 화면에도 영향 범위가 퍼지고, 나중에 데이터 접근 권한을 다르게 제어해야 할 때 분리돼 있는 게 훨씬 낫다.

권한 인터셉터는 기존 패턴을 따라서 추가했다. 파트너 포탈 영역은 일반 사용자와 분리된 세션/권한 체계를 쓰고 있어서, 신규 엔드포인트도 같은 인터셉터 체인에 태우는 게 맞다. 빠뜨리면 미인증 접근이 그냥 통과될 수 있다.

사이드바 메뉴 활성화는 JSP 레이아웃 공통 처리 방식을 따랐다. 이게 빠지면 기능은 동작하는데 메뉴가 하이라이트 안 돼서 사용자가 "내가 지금 어디 있는지" 모르게 된다.

relay-fee UI 버그

문제 구조는 이랬다.

// 버그가 있던 패턴 (단순화)
$.ajax({
  url: '/api/relay-fee/save',
  data: formData,
  success: function(res) {
    // 저장 응답만 처리, 화면 갱신 누락
    alert('저장되었습니다.');
  }
});

// 수정 후
$.ajax({
  url: '/api/relay-fee/save',
  data: formData,
  success: function(res) {
    alert('저장되었습니다.');
    refreshRelayFeeView(res.updatedData); // 응답 데이터로 즉시 갱신
  }
});

저장 API가 성공 응답에 업데이트된 값을 포함해서 내려주고 있었는데, 클라이언트에서 그걸 화면에 반영하는 코드가 빠져 있었다. 사용자가 새로고침하면 맞는 값이 보이는 이유가 여기 있었다. 응답 데이터를 바로 화면에 밀어 넣는 식으로 수정해서 새로고침 없이도 즉시 반영되게 했다.

실시간 갱신 필요성 판단

이번 기능에서 폴링이나 웹소켓은 고려하지 않았다. 출금요청 처리는 담당자가 의도를 갖고 액션을 취하는 동기적 흐름이고, 페이지를 열어두고 다른 사람이 상태를 바꾸는 상황이 실제로 발생할 빈도가 낮다. 복잡도 대비 효용이 낮아서 단순하게 갔다.

금융 도메인에서 실시간 갱신을 넣을지 판단할 때 보통 이 기준으로 생각한다.

이번 케이스는 오른쪽 열에 해당해서 단순하게 유지했다.

예외 처리

빈 데이터, NULL, 권한 없는 접근 케이스는 각각 방어 처리를 넣었다. 금융 포탈에서 예외 케이스를 빠뜨리면 숫자가 "-"로 보이거나 NPE가 500 에러로 떨어지는 게 사용자한테 그대로 노출된다. 내부 어드민이라도 마찬가지다.

검증 과정

구현 후 직접 화면에서 동작을 확인했다. relay-fee 저장 전/후 값이 일치하는지, 출금요청 화면에서 계좌 정보가 맞게 나오는지, 기존 데이터가 깨지지 않는지 cross-check했다. 특히 관련된 다른 화면에서 같은 숫자를 표시하는 곳이 있으면 거기서도 값이 일치하는지 보는 게 습관이 됐다.

쿼리 실행 계획은 새로 추가한 집계 쿼리 위주로 확인했다. 데이터 볼륨이 적더라도 인덱스를 타지 않는 풀스캔이 있으면 나중에 문제가 된다.

사내 파트너 포탈 같은 내부 도구는 "나중에 고치면 되지" 하고 묵혀두기 쉬운데, 매일 쓰는 사람들 입장에선 잘못 보이는 숫자 하나, 추가 탭 클릭 하나가 신뢰를 갉아먹는다. 특히 금융 도메인이면 "이 숫자 맞아?" 하는 의심이 생기는 순간 운영 효율이 확 떨어진다.

이번 작업은 파일 3개 변경이지만 쿼리, API, JSP, 권한, 메뉴까지 레이어를 다 건드렸다. 어느 하나 빠뜨렸으면 기능은 동작하는데 어딘가 이상한 상태가 됐을 것. 작은 작업일수록 꼼꼼하게 체크리스트 식으로 돌아보는 이유가 여기 있다.

커밋도 계좌 노출 기능과 relay-fee 버그 수정을 분리해서 넣었다. 나중에 어느 쪽에서 문제가 생기더라도 되돌리거나 원인을 추적할 때 섞여 있으면 골치 아프다. 논리적으로 독립된 단위로 쪼개는 습관은 지금 당장은 귀찮아도 결국 미래의 나를 위한 작업이다.