파트너 포털에 본인 포함 하위 파트너 조회 기능 추가

파트너 포털에서 하위 파트너 드롭다운을 쓸 때 항상 불편한 게 있었다. "내가 직접 조회하고 싶은데 드롭다운에 본인이 없네?" 하는 상황. 파트너가 자기 자신의 데이터를 확인하려면 별도 경로를 거쳐야 했는데, 이번에 드롭다운 목록에 "본인(나)" 옵션을 추가하면서 그 흐름을 정리했다.

변경 파일은 세 곳. 내부 클래스 하나, SQL 매퍼 하나, 뷰/스타일 하나. 파일 수만 보면 작아 보이지만 실제로는 쿼리 레벨부터 화면 렌더링까지 수직으로 다 건드린 작업이었다.

왜 쿼리부터 손댔나

단순히 드롭다운에 고정 값 하나 박는 방식도 있었다. <option value="self">나</option> 추가하고 프론트에서 분기 처리하는 식. 근데 그렇게 하면 결국 조회 로직이 두 군데로 쪼개진다. 드롭다운 선택값에 따라 쿼리 경로가 달라지고, 나중에 집계 화면이나 엑셀 다운로드 쪽에서 같은 분기를 또 타야 한다. 관리 포인트가 늘어나는 건 금융 도메인에서 특히 위험하다 - 어느 한 군데서 분기를 빠뜨리는 순간 숫자가 화면마다 달라진다.

그래서 SQL 매퍼부터 시작했다. 하위 파트너 목록을 가져오는 쿼리에 본인의 파트너 ID를 포함시키는 방향으로 설계하면, 이후 조회 로직은 드롭다운에서 선택된 ID를 그냥 넘기는 것과 동일하게 처리된다. 뷰에서도 특별한 분기 없이 일관된 흐름을 유지할 수 있고.

-- 변경 전: 하위 파트너만 조회
SELECT partner_id, partner_name
FROM   partners
WHERE  parent_id = #{currentPartnerId}

-- 변경 후: 본인 포함 UNION
SELECT partner_id, partner_name, 0 AS sort_order
FROM   partners
WHERE  partner_id = #{currentPartnerId}
UNION ALL
SELECT partner_id, partner_name, 1 AS sort_order
FROM   partners
WHERE  parent_id = #{currentPartnerId}
ORDER  BY sort_order, partner_name

sort_order로 본인을 항상 맨 위에 두도록 했다. UX상 "나"가 맨 위에 있어야 직관적으로 쓰기 편하다는 판단.

설계할 때 체크한 항목들

기능 자체는 크지 않아도, 금융/결제 포털 특성상 아래 항목들은 무조건 확인하고 넘어간다.

권한 인터셉터 쪽은 처음에 한 번 놓쳤었다. 로컬에서 관리자로 테스트하니까 당연히 통과했는데, 실제 파트너 계정으로 붙으면 다른 경로를 타는 구조였다. 이런 게 나중에 "왜 내 화면에서만 안 되나요?"로 돌아오는 전형적인 패턴이라 잡고 넘어갔다.

JSP + AJAX 연동 구조

프론트는 기존 패턴 그대로 따라갔다. 드롭다운 change 이벤트에서 AJAX 요청 보내고, 응답받은 데이터로 테이블을 갱신하는 구조. 실시간 폴링은 넣지 않았다 - 이 화면의 데이터 성격상 드롭다운 선택 시점에 한 번 조회하는 것으로 충분하고, 폴링 주기 설정하고 중복 요청 방어하는 복잡도를 감수할 이유가 없었다.

$('#partnerSelect').on('change', function () {
    var partnerId = $(this).val();
    if (!partnerId) return;

    $.ajax({
        url  : '/partner/sub/list',
        data : { partnerId: partnerId },
        success: function (res) {
            renderTable(res.data);
        }
    });
});

단순하게 유지하는 게 맞는 상황이었다. AJAX 콜 하나, 렌더 함수 하나.

작업 후기

기능 하나가 단순히 화면에 옵션 하나 추가하는 것으로 끝나지 않는다는 걸 이번에도 다시 체감했다. SQL 집계, 권한 체크, 예외 처리, 화면 렌더링이 모두 엮여 있어서 어느 하나만 빠뜨려도 특정 계정에서 이상한 화면이 나오거나 숫자가 맞지 않는다.

금융/결제 도메인은 숫자 하나가 틀리면 신뢰가 무너질 수 있다. "대충 맞는 것 같다"로 넘어가면 나중에 반드시 다시 돌아온다. 그래서 작업 전 현재 동작 수치를 메모해두고, 수정 후 같은 케이스로 비교하는 루틴을 유지하고 있다. 관련 화면이 있으면 숫자 cross-check까지.

커밋은 "SQL 매퍼 수정", "내부 클래스 본인 ID 포함 처리", "뷰 드롭다운 본인 옵션 추가" 세 단위로 쪼갰다. 이렇게 논리적으로 독립된 단위로 커밋을 나눠두면 나중에 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 훨씬 쉽다. 커밋 메시지에는 "무엇을" 보다 "왜"를 담으려고 노력하는데, 이번 SQL 매퍼 커밋엔 "관리 포인트 분산 방지를 위해 쿼리 레벨에서 본인 포함 처리"라고 적었다. 한 달 뒤에 다시 봐도 맥락이 읽혀야 하니까.