일기 slecs

사이트 PV 조회를 고정 30일에서 날짜 선택기로 교체

목차

사이트 PV 관리 화면에서 고정된 30일 트렌드 차트를 걷어내고, 날짜 선택기를 붙이는 리팩터링을 했다.


왜 고정 30일 차트가 문제였나

처음 PV 대시보드를 만들 때는 "일단 30일" 이라는 암묵적 합의로 차트를 박아뒀다. 당시엔 운영자가 요청하는 대부분의 조회가 "최근 한 달 추이"였고, 그게 유일한 유즈케이스처럼 보였기 때문이다.

그런데 시간이 지나면서 문제가 생기기 시작했다. 운영 현장에서 "특정 캠페인 기간만 따로 보고 싶다", "지난주 월~일만 뽑아달라" 같은 요청이 꾸준히 들어왔다. 30일 차트는 그 요청을 하나도 소화하지 못했고, 매번 별도 쿼리나 외부 툴로 우회하는 방식이 반복됐다.

고정된 기간 차트가 갖는 본질적인 한계는 이렇다:

  • 기간이 하드코딩되면 비즈니스 리듬(캠페인, 정산 주기, 이슈 발생 구간)과 맞지 않는 경우가 대부분
  • 차트를 보는 사람이 "이 데이터가 정확히 언제 기준이냐"를 매번 확인해야 함
  • 날짜 범위가 바뀔 때마다 코드 수정이 필요 → 운영 민첩성 저하

결국 30일 차트는 초기 프로토타입의 흔적이었고, 이번에 정리하는 게 맞다고 판단했다.


작업 내용 — 차트 제거 + 날짜 선택기 연결

변경 파일은 src/app/admin/(protected)/site-pv/page.tsxtsconfig.json 두 개다.

page.tsx 가 핵심이다. 30일 트렌드 차트 컴포넌트와 그에 딸린 데이터 페칭 로직을 제거하고, 날짜 선택기(date picker) 를 붙여서 선택한 날짜 범위 기준으로 PV 데이터를 조회하도록 흐름을 바꿨다.

tsconfig.json 이 함께 변경된 건, 날짜 선택기 라이브러리나 관련 타입 패키지를 추가하면서 path alias 또는 컴파일 옵션 조정이 필요했기 때문으로 보인다. tsconfig 변경은 작은 라인이어도 팀 전체 빌드 환경에 영향을 줄 수 있어서 항상 주의 깊게 보는 편이다. 특히 paths 설정을 건드렸다면 다른 팀원의 import 경로 해석이 달라질 수 있고, strict 옵션 변경이면 기존 코드에 타입 에러가 새로 튀어나올 수 있다.

항목 변경 전 변경 후
조회 기간 30일 고정 날짜 선택기로 자유 지정
차트 존재 여부 고정 트렌드 차트 있음 차트 제거
운영자 유연성 없음 원하는 구간 직접 선택
코드 유지보수 기간 변경 시 코드 수정 필요 선택기 UX로 해결

날짜 선택기를 연결할 때 일반적으로 주의할 부분을 정리하면:

// 날짜 범위 상태를 관리할  흔히 쓰는 패턴
const [dateRange, setDateRange] = useState<{
  from: Date | null;
  to: Date | null;
}>({ from: null, to: null });

// API 호출  날짜를 쿼리 파라미터로 직렬화
const params = new URLSearchParams({
  from: dateRange.from?.toISOString().split('T')[0] ?? '',
  to: dateRange.to?.toISOString().split('T')[0] ?? '',
});

날짜를 다룰 때 timezone 처리를 놓치면 "내가 선택한 날짜와 실제 조회 결과의 날짜가 다르다"는 버그가 생긴다. 운영자 입장에서 가장 당황스러운 케이스 중 하나라 이 부분은 코드리뷰 때도 꼭 체크 포인트로 잡는다.


리팩터링 회고

이번 작업은 기능 추가가 아니라 기존 가정을 교체하는 작업이었다. "30일이면 충분하다"는 초기 가정이 운영 현실과 맞지 않았고, 그 가정을 담은 코드를 걷어내는 데 생각보다 시간이 걸리지 않았다. 오히려 차트 컴포넌트를 억지로 유지하면서 그 주변에 예외 처리를 쌓아갔다면 훨씬 더 복잡해졌을 것이다.

팀 리딩 관점에서 이런 종류의 리팩터링은 우선순위 판단이 핵심이다. 완전히 동작하는 기능을 건드리는 건 리스크가 있어서 밀리기 쉽다. 근데 "지금은 돌아가지만 요구를 못 쫓는 기능"을 그대로 두면 우회 작업 비용이 조용히 쌓인다. 이번에 결정한 건 그 누적 비용이 리팩터링 리스크보다 크다는 판단이었다.

page.tsx 한 파일의 변경이지만, 운영자 워크플로우에서 매일 마주치는 화면이라 체감 영향은 꽤 크다. 작은 파일 변경이 큰 UX 변화로 연결되는 케이스다.

끝.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.