파트너 포털에 수수료 비교 하위체인 포커스 뷰 추가

partner-portal 영역에 수수료 비교 테이블 하위체인 포커스 뷰를 추가했다. 변경 파일은 뷰/스타일 1개인데, 화면 한 장 추가치고는 설계 과정이 꽤 깊었음.

배경

수수료 비교 테이블은 기존에도 있었다. 문제는 전체 체인을 한눈에 보여주는 구조라 특정 하위체인만 집중해서 보고 싶을 때 노이즈가 많다는 것. 파트너 측에서 관리하는 하위체인이 늘어날수록 테이블이 길어지고, 원하는 항목을 찾는 데 스크롤을 한참 내려야 했음.

포커스 뷰는 필터 하나 걸면 되지 않냐고 생각할 수 있는데, 기존 API 응답 구조상 그게 단순하지 않았다. 전체 체인 기준으로 집계된 수치를 하위체인 단위로 다시 슬라이싱하려면 쿼리 레벨에서 분리가 필요했음. 그래서 단순 UI 작업이 아니라 백엔드 엔드포인트를 새로 추가하고, 거기서 데이터를 뽑아 프론트로 내려주는 흐름 전체를 설계했다.

구현

흐름 자체는 전형적인 JSP + AJAX 패턴. 포탈 레거시 구조가 이미 이 패턴으로 되어 있어서 새 엔드포인트도 같은 컨벤션을 따랐음.

// 하위체인 포커스 뷰 데이터 요청 (AJAX)
$.ajax({
  url: '/partner/fee/subchain/focus',
  type: 'GET',
  data: { subchainId: selectedId },
  success: function(res) {
    if (res.result === 'OK') {
      renderFocusTable(res.data);
    } else {
      showErrorMessage(res.message);
    }
  }
});

성공 케이스만 가정하고 구현하면 데이터가 없거나 권한이 없는 사용자가 들어왔을 때 화면이 텅 빈 채로 멈춘다. 에러 응답 분기를 명시적으로 두는 게 포인트임.

백엔드에서는 권한 인터셉터 통과 여부를 먼저 확인했다. 파트너 포털은 파트너별로 접근 가능한 하위체인이 다르기 때문에, subchainId를 직접 쿼리 파라미터로 넘겨도 본인 관할 외 데이터를 못 보도록 인터셉터에서 걸러지는지 체크가 필요했음. 신규 기능에서 자주 놓치는 부분이라 이 부분은 꼼꼼하게 확인했다.

사이드바 메뉴 활성화 처리도 자잘하지만 빠뜨리면 사용자 경험이 이상해진다. 포커스 뷰 URL로 직접 진입했을 때 사이드바 강조가 제대로 되는지, 브레드크럼이 맞게 나오는지까지 챙겼음.

설계 시 고려한 것들

금융/결제 도메인에서 가장 무서운 건 숫자가 맞지 않는 상황이다. 포커스 뷰에서 보이는 수수료 합계가 기존 전체 테이블 해당 행 값과 달라지면, 파트너 입장에서는 어느 쪽을 믿어야 할지 모르게 됨. 한번 의심받으면 복구하기 쉽지 않다.

그래서 설계 단계에서 아래 네 가지를 명시적으로 결정하고 들어갔음.

실시간 갱신이 필요한지는 항상 명시적으로 결정해야 한다. 폴링을 달아두면 불필요한 DB 요청이 계속 나가고, 반대로 필요한데 없으면 사용자가 새로고침을 수동으로 눌러야 함. 이 기능은 파트너가 조회 목적으로 쓰는 화면이라 snapshot 방식으로 충분하다고 판단했다.

쿼리 실행 계획 확인은 습관으로 만들어두면 좋음. 새 파라미터 하나 추가됐을 뿐인데 풀스캔으로 빠지는 경우가 있어서, 실행 계획을 안 보면 로컬에서는 멀쩡하다가 데이터가 쌓인 운영 환경에서 터지는 패턴이 나온다. 다행히 이번엔 기존 인덱스를 그대로 쓸 수 있었음.

검증과 회고

구현 후 직접 화면에서 동작을 확인했다. 포커스 뷰 수치와 기존 전체 테이블 해당 행 수치를 수동으로 맞춰봤고, 권한이 다른 파트너 계정으로 비정상 접근도 시도해봤음. 기존 데이터가 깨지지 않았는지, 관련 화면 숫자가 일치하는지 cross-check까지 마쳐야 비로소 "됐다"고 할 수 있는 작업이었다.

작업 전후로 수치를 메모해두는 습관이 이럴 때 특히 유용함. "이전에 이랬는데 지금은 이렇다"를 기록해둬야 무언가 이상할 때 내가 바꾼 건지 원래 그랬던 건지 구분할 수 있다. 그게 없으면 디버깅이 추리 게임이 됨.

커밋은 논리 단위로 쪼갰다. 백엔드 엔드포인트, 프론트 뷰, 메뉴 활성화 처리를 각각 따로 묶었음. 파일이 1개라도 변경 의도가 다른 것들을 한 커밋에 섞으면, 나중에 git log로 원인을 추적할 때 맥락을 잃는다. 커밋 메시지에는 "무엇을"보다 "왜 이 구조로 만들었는지"를 담으려고 노력했음. 작은 커밋을 자주 남기면 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 훨씬 쉽고, 롤백 범위도 좁힐 수 있다.

사내 서비스를 만들다 보면 기능 하나가 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감함. SQL 집계, 권한 인터셉터, 예외 방어, 화면 렌더링이 한 덩어리로 엮여 있어서 어느 하나를 얕게 보면 반드시 다른 쪽에서 문제가 나온다. 특히 금융 도메인에서 "대충 맞는 것 같다"로 넘어가면 반드시 다시 돌아옴.