매출 대시보드에서 머천트 라이브 카드를 상단으로 복귀

매출 관리 대시보드의 머천트 카드 표시 방식을 다시 손봤다. 라이브 데이터를 메인으로 돌려놓는 작은 변경이지만, 운영 관점에서 꽤 의미 있는 결정이었다.

왜 이런 변경이 필요했나

결제 플랫폼 같은 시스템을 운영하다 보면, 머천트별 매출 현황을 실시간으로 파악해야 한다. 특히 관리자가 보는 시스템 전체 수익 요약(total-summary) 페이지에서는 지금 이 순간의 정확한 상태가 중요하다.

아마도 이전에는 다른 뷰를 메인으로 두거나, 캐시된 데이터를 우선 표시하거나, 혹은 UI/UX 재구성 때문에 라이브 카드 표시가 뒤로 밀려났을 것 같다. 운영팀이나 관리자 피드백이 들어왔을 가능성도 있다. "왜 지금 매출이 안 보여?" 같은 요청 말이다.

머천트 카드를 메인으로 복귀하는 것의 의미

대시보드 같은 페이지는 정보 아키텍처가 생각보다 중요하다.

대시보드는 단순 조회 페이지가 아니라 운영 의사결정의 진입점이다. 따라서 어떤 정보를 맨 위에 두느냐는 단순 UI 문제가 아니라 서비스 철학 문제다. "우리 시스템의 가장 중요한 지표는 뭔가"를 화면 구성으로 표현하는 것이기 때문이다.

JSP 단에서의 리팩터링

이 파일은 JSP 템플릿이므로, 아마도 다음과 같은 작업이 포함됐을 것 같다:

<!-- 변경 전: 다른 뷰가 상단 -->
<div class="summary-section">
  <% /* 집계 통계 / 필터된 데이터 등 */ %>
</div>

<!-- 변경 후: 머천트 라이브 카드가 상단 -->
<div class="merchant-card merchant-card--live">
  <% /* 실시간 머천트 데이터 */ %>
</div>

단순해 보이지만, JSP에서 DOM 순서를 바꾼다는 것은:
- HTML 마크업 순서 재정렬
- 혹은 CSS order / flex-direction 변경 (Flexbox/Grid)
- 혹은 JavaScript로 동적 재배치 (비추천 — 성능 + 유지보수성)

1인 개발자 관점에서는 마크업 순서를 직접 손보는 게 가장 깔끔하다. 서버 렌더링 시점에 정의되므로 클라이언트 재계산이 없고, git diff도 명확하기 때문이다.

대시보드 리팩터링에서 배운 것들

비슷한 상황을 또 마주칠 때를 위해 정리해두면:

1. 정보 계층(information hierarchy)이 곧 디자인 결정 — 위치 = 중요도. 눈에 띄는 곳에 뭘 둬야 할까를 자주 재검토해야 한다.

2. 운영팀의 피드백은 조용할 수 있다 — "이게 빠져있다", "이게 더 위에 있어야 한다" 같은 목소리를 놓치기 쉽다. 주기적으로 확인하기.

3. 라이브 vs 캐시의 트레이드오프 — 실시간성이 중요하면 라이브 데이터를 우선. 대신 로딩 시간이 늘 수 있으니 UX 성능도 함께 모니터링해야 한다.

4. 리팩터는 기능 변경 없는 정리가 아닐 수 있다 — 이 경우 마크업 순서 변경만으로도 사용자의 인식과 행동이 달라질 수 있다. 작은 변경도 영향 범위를 생각하고 진행하자.

실제로 대시보드는 관리자가 매일 보는 페이지인 만큼, 이런 순서 개선이 누적되면 운영 효율에 꽤 큰 차이를 만든다. 다음에 대시보드 영역을 건드릴 일이 있으면, 단순 버그 수정이 아니라 "지금 이 정보 구조가 최선인가" 한 번 더 물어보고 진행해야겠다.