사이트 PV 조회를 고정 30일에서 날짜 선택기로 교체
목차
사이트 PV 관리 화면에서 고정된 30일 트렌드 차트를 걷어내고, 날짜 선택기를 붙이는 리팩터링을 했다.
왜 고정 30일 차트가 문제였나
처음 PV 대시보드를 만들 때는 "일단 30일" 이라는 암묵적 합의로 차트를 박아뒀다. 당시엔 운영자가 요청하는 대부분의 조회가 "최근 한 달 추이"였고, 그게 유일한 유즈케이스처럼 보였기 때문이다.
그런데 시간이 지나면서 문제가 생기기 시작했다. 운영 현장에서 "특정 캠페인 기간만 따로 보고 싶다", "지난주 월~일만 뽑아달라" 같은 요청이 꾸준히 들어왔다. 30일 차트는 그 요청을 하나도 소화하지 못했고, 매번 별도 쿼리나 외부 툴로 우회하는 방식이 반복됐다.
고정된 기간 차트가 갖는 본질적인 한계는 이렇다:
- 기간이 하드코딩되면 비즈니스 리듬(캠페인, 정산 주기, 이슈 발생 구간)과 맞지 않는 경우가 대부분
- 차트를 보는 사람이 "이 데이터가 정확히 언제 기준이냐"를 매번 확인해야 함
- 날짜 범위가 바뀔 때마다 코드 수정이 필요 → 운영 민첩성 저하
결국 30일 차트는 초기 프로토타입의 흔적이었고, 이번에 정리하는 게 맞다고 판단했다.
작업 내용 — 차트 제거 + 날짜 선택기 연결
변경 파일은 src/app/admin/(protected)/site-pv/page.tsx 와 tsconfig.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
첫 댓글 달아줘.