운영자수익 파트너별 기여 표에 드릴다운 기능 추가

admin 운영 영역에서 파트너별 수익 기여 표에 드릴다운을 붙였다. 클릭하면 해당 파트너의 대시보드로 바로 내려가는 기능인데, 얼핏 "링크 하나 달면 되는 거 아냐?"처럼 보이지만 실제로는 내부 클래스 2개, 뷰/스타일 1개까지 건드렸다. 이유가 있다.

왜 쿼리 레벨부터 다시 설계했나

기존 운영자수익 표는 집계값만 뿌리는 구조였다. 파트너별 행은 있지만 그 행이 "어느 파트너 ID"에 연결되어 있는지를 화면 레이어까지 들고 오지 않았다. 뷰모델이 단순히 {name, amount, ratio} 정도만 담고 있어서 드릴다운 링크를 붙이려면 파트너 ID를 추가로 실어야 했고, 그러려면 SQL 집계 쿼리부터 손봐야 했다.

기존 쿼리 결과셋 예시:

-- 기존: 이름·금액만 GROUP BY
SELECT p.name, SUM(t.amount) AS total_amount
FROM partner p
JOIN transaction t ON t.partner_id = p.id
WHERE t.settled_date BETWEEN :from AND :to
GROUP BY p.name

여기에 p.id를 같이 SELECT하면 될 것 같지만, 실제론 매퍼 DTO와 서비스 레이어 메서드 시그니처가 연동되어 있어서 중간 클래스를 건드리지 않으면 타입 불일치가 생긴다. 그래서 관련 내부 클래스 두 곳에 메서드/필드를 추가하고, SQL 매퍼에 쿼리를 새로 작성한 다음 화면 렌더링까지 연결했다.

설계할 때 챙긴 것들

금융·결제 도메인에서 숫자는 하나라도 틀리면 안 된다. "대충 맞는 것 같다"로 넘기면 나중에 반드시 다시 돌아온다는 걸 여러 번 겪어서 이제는 몸에 배어 있다. 이번에 고려한 항목들을 정리하면:

특히 권한 체크는 드릴다운이 생기면서 새로 따져야 할 케이스가 생겼다. 집계 표를 볼 수 있다고 해서 파트너 대시보드 내부까지 접근 가능한 건 아닐 수 있기 때문에, 드릴다운 링크 렌더 여부와 실제 접근 권한 체크를 분리해서 처리했다. 링크가 보이는데 클릭하면 403이 뜨는 것도 나쁘고, 권한이 있는데 링크가 안 보이는 것도 나쁘니까.

구현 후 검증 방식

구현하고 나서 직접 화면에서 동작을 확인했다. 이때 체크한 순서:

• 운영자수익 표의 합계와 드릴다운 내부 합계가 일치하는지
• 파트너가 여러 개일 때 각각 올바른 대시보드로 연결되는지
• 데이터가 없는 파트너 행이 있을 때 빈 화면이 아닌 적절한 안내가 나오는지
• 권한이 없는 계정으로 접근 시 올바르게 차단되는지

숫자 cross-check는 매번 번거롭지만 생략하면 안 된다. 이번에도 드릴다운 내부 합계를 집계 표와 맞춰보는 과정에서 기간 필터 적용 방식이 약간 달랐다는 걸 발견했다. 쿼리 레벨에서 정렬 기준이 settled_date vs created_date로 미묘하게 갈렸던 건데, 화면만 봐선 드러나지 않았을 것이다.

작업 전에 현재 동작을 스크린샷이나 수치로 메모해두는 습관이 이런 상황에서 빛을 발한다. "전에는 이 숫자였는데 지금은 왜 다르지?"를 바로 확인할 수 있으니까.

커밋도 논리 단위로 쪼갰다. SQL 매퍼 변경, 서비스 레이어 메서드 추가, 뷰 렌더링 연동을 각각 따로 커밋했다. 나중에 문제가 생기면 어느 변경에서 깨졌는지 추적하기 훨씬 쉽고, 리뷰어 입장에서도 diff 하나가 한 가지 의도만 담고 있으면 보기 편하다. 커밋 메시지는 "무엇을" 보다 "왜"를 담으려 했다. 파트너 ID 필드 추가 보다는 드릴다운 링크 생성을 위해 파트너 ID를 뷰모델에 포함이 나중에 맥락 파악하기 훨씬 낫다.

사내 서비스를 운영하면서 계속 느끼는 건, 기능 하나가 단순히 화면에 요소 하나 추가하는 것으로 끝나는 경우가 없다는 거다. SQL 집계, DTO, 서비스 레이어, 예외 처리, 화면 렌더링, 권한 체크가 전부 엮여 있어서 어느 하나를 빠뜨리면 숫자가 안 맞거나 특정 조건에서 이상한 화면이 나온다. 이번 드릴다운 작업도 그 흐름 그대로였다. 작아 보이는 기능일수록 더 꼼꼼히 살피는 게 기본값이어야 한다.