어드민에 일별 PV 조회 KPI 대시보드 신설

사내 어드민에 KPI 대시보드 페이지를 새로 팠다. admin_db.cms_site_pv_daily 테이블을 직접 조회해서 일별 PV 수치를 볼 수 있는 화면인데, 생각보다 이 작업이 단순한 "페이지 하나 추가" 이상의 의미를 가졌다.

왜 이 타이밍에 KPI 대시보드였나

팀에서 운영 데이터를 보는 방식이 그동안 꽤 파편화돼 있었다. 누군가는 DB 직접 쿼리로, 누군가는 외부 분석 툴로, 누군가는 구글 스프레드시트로 보고 있었다. 이 상태가 지속되면 팀원마다 "어제 PV가 얼마였냐"는 질문에 답이 다르게 나온다. 숫자의 단일 출처(Single Source of Truth)를 어드민 안으로 끌어오는 게 목적이었다.

cms_site_pv_daily는 이미 적재되고 있는 테이블이라 데이터 파이프라인을 새로 만들 필요가 없었다. 그냥 읽어서 보여주면 되는 상황이었는데도 여태 어드민 UI가 없었던 건, 우선순위에서 계속 밀렸기 때문이다. 기능 개발 사이클에서 "내부 도구"는 항상 후순위가 되기 쉽다. 근데 내부 도구의 부재가 누적되면 운영팀 커뮤니케이션 비용이 슬금슬금 올라간다. 이번에 그 비용이 임계점을 넘었다고 판단해서 스프린트에 직접 넣었다.

변경 파일 두 개가 하는 일

layout.tsx를 건드린 게 포인트다. Next.js App Router의 (protected) 그룹 레이아웃은 인증 미들웨어나 세션 체크가 걸려 있는 구간이다. 새 페이지를 이 그룹 안에 넣는다는 건 "이 화면은 인증 없이는 절대 못 본다"는 의도를 라우팅 구조 자체로 표현하는 것이다. 별도로 페이지 컴포넌트 안에서 if (!session) redirect(...) 같은 방어 코드를 또 짤 필요가 없다. 구조적으로 보호가 되니까.

src/app/admin/
  (protected)/
    layout.tsx        ← 공통 인증 레이아웃
    site-pv/
      page.tsx        ← KPI 대시보드
    ...다른 보호된 라우트들

이 구조를 처음 설계할 때 팀에 충분히 설명해뒀던 게 이번에 효과를 봤다. 신규 어드민 페이지를 추가할 때 (protected) 그룹 안에 폴더만 만들면 인증이 자동으로 따라온다. 팀원이 보호 레이어를 깜빡할 여지를 구조적으로 줄여둔 것.

어드민 DB 직접 조회, 괜찮은가

admin_db.cms_site_pv_daily를 어드민 서버 사이드에서 직접 읽는 방식을 택했다. 별도 API 엔드포인트를 만들지 않았다. 이 선택에 대해 짧게 트레이드오프를 정리하면:

• 직접 조회 (현재 방식)
• 중간 레이어 없이 단순함
• 어드민 전용 read-only DB 커넥션 사용 → 서비스 DB와 분리됨
• 외부에 노출되는 API 엔드포인트가 늘지 않음

• 단, 이 조회 로직을 재사용하기 어렵다 (어드민 전용이면 그게 맞긴 함)

• API 엔드포인트 별도 분리 방식

• 클라이언트 사이드 페칭 가능 → 캐싱/로딩 UX 제어 쉬움
• 여러 클라이언트에서 재사용 가능
• 엔드포인트 추가 보안 처리 필요

KPI 대시보드 특성상 실시간성보다는 "일별 집계 데이터를 정확하게 보여주는 것"이 우선이라 직접 조회로도 충분하다고 봤다. 추후 차트 라이브러리 붙이거나 필터(기간 선택 등)가 복잡해지면 그때 API 분리를 고려하면 된다.

회고

이런 내부 도구 작업을 팀장이 직접 짜는 게 맞냐는 의문을 가질 수도 있다. 근데 내부 도구 품질이 팀 운영 속도에 직결된다고 생각한다. 지금은 작은 페이지 하나지만, 이게 기준이 되면 팀원들이 다음 어드민 페이지를 추가할 때 참조 코드가 생기는 거다. 첫 삽을 어떻게 파느냐가 이후 확장 패턴을 결정하기 때문에, 구조적 의사결정이 담긴 코드는 직접 짜는 편이다.

다음은 날짜 범위 필터와 간단한 시각화 추가가 예정돼 있다.

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

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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