[🛠] 공개 블로그 통계 페이지 만들기

✨ GPT-5.5의 요약 　

이상하게 튀던 방문자 카운터를 추적해 로컬 작업 카운트를 막고, Cloudflare Worker와 D1로 공개 가능한 집계형 analytics 페이지를 붙인 기록.

방문자 카운터가 이상했다.

하루 방문자수가 갑자기 80을 넘었다.

처음에는 그냥 “검색에 걸렸나?” 정도로 넘길 수도 있었다. 그런데 느낌이 이상했다. 최근 며칠 동안 내가 블로그를 계속 고치고 있었고, AI 작업 중에도 로컬 서버와 공개 URL을 꽤 많이 열어봤다.

그래서 의심이 생겼다.

내가 보고 있는 숫자가 진짜 방문자일까.

아니면 내가 만든 카운터가 내 작업까지 다 세고 있는 걸까.

로컬 작업 카운트가 공개 통계를 오염시켰다

먼저 구조를 다시 봤다.

앞서 방문자 카운터 작업에서 만든 방문자 카운터는 Cloudflare Worker와 D1을 쓴다.

페이지가 로드되면 JS가 Worker에 /track을 보내고, Worker가 D1의 counters, page_counters, dedupe_views를 올린다. Google Analytics는 baseline으로만 쓰고, 이후 증분은 D1에 쌓는 구조였다.

문제는 이 구조가 너무 정직했다는 점이다.

브라우저가 페이지를 열면 센다.

로컬 개발 서버에서 열어도 endpoint는 production Worker를 바라보고 있었다. Worker 쪽 CORS 허용 origin에도 localhost:4000과 127.0.0.1:4000이 들어 있었다.

그러면 당연히 로컬 미리보기도 실제 D1 카운터를 올릴 수 있다.

그리고 dedupe 기준도 visitorId + path였다. 같은 브라우저에서 같은 글을 10분 안에 여러 번 열면 한 번만 세지만, 서로 다른 글을 계속 열면 전부 세는 구조다. 블로그 점검 중 글을 여러 개 열면 그게 그대로 page view가 된다.

D1을 직접 확인하니 더 노골적이었다.

day:2026-06-06 = 14
day:2026-06-07 = 38
day:2026-06-08 = 81
day:2026-06-09 = 5

2026-06-08에는 오래된 Daily Review와 naver-* 글들이 넓게 한 번씩 찍힌 흔적이 있었다. 실제 독자라기보다 작업 중 페이지를 훑은 모양에 가까웠다.

로컬 작업은 표시만 하고 세지 않게 막았다

첫 번째 수정은 단순했다.

로컬에서는 조회수 표시만 하고 /track을 보내지 않게 했다.

localhost
127.0.0.1
::1

이 세 환경에서는 클라이언트 JS가 카운트 요청을 보내지 않는다.

하지만 클라이언트만 믿으면 안 된다. JS가 꼬이거나 다른 요청이 들어오면 다시 같은 문제가 생긴다. 그래서 Worker에서도 /track은 production origin만 카운트하도록 막았다.

TRACK_ALLOWED_ORIGIN=https://hyuk.blog

이제 로컬 origin에서 /track을 보내면 Worker가 origin_not_tracked로 무시한다.

추가로 production 화면을 직접 확인해야 할 때도 있었다. 그래서 브라우저 localStorage에 opt-out을 저장하는 우회로를 만들었다.

?hyuk_no_track=1
?visitor_tracking=off
?visitor_tracking=on

이건 숨겨진 관리자 기능이라기보다, 내가 공개 페이지를 점검할 때 카운터를 더럽히지 않기 위한 스위치다.

통계를 숨길 필요가 없었다

처음에는 세부 analytics를 나만 보는 페이지로 만들까 생각했다.

그런데 다시 생각해보니, 굳이 그럴 필요가 없었다.

IP 원문, User-Agent 원문, full referrer URL, 단건 이벤트 로그를 저장하지 않으면 된다. 공개해도 되는 값만 수집하면, 통계 페이지도 공개해도 된다.

그래서 방향을 바꿨다.

나만 보는 로그 페이지가 아니라, 누구나 볼 수 있는 공개 블로그 통계 페이지.

/analytics/

상단 메뉴에도 통계 링크를 붙였다. 사이드바의 작은 방문 통계 아래에도 같은 페이지로 가는 링크를 추가했다.

D1에는 집계만 쌓는다

새 테이블은 단순하다.

analytics_daily_dimensions

date
dimension
value
count
updated_at

한 번의 page view가 실제로 카운트될 때, Worker는 공개 가능한 차원을 분류해서 하루 단위로 누적한다.

수집하는 값은 이런 것들이다.

page
content_group
locale
country
region
continent
colo
asn_org
device
viewport
browser
os
language
client_timezone
color_scheme
connection
traffic_source
referrer_domain
hour
weekday

여기서 중요한 건 원문을 저장하지 않는다는 점이다.

예를 들어 referrer는 전체 URL이 아니라 domain만 저장한다. User-Agent도 원문을 저장하지 않고 browser, OS, device로 분류한다. IP는 저장하지 않는다.

정확한 분석 도구라기보다는 공개 블로그용 흐름판이다.

analytics API에 today/month/total/custom range를 붙였다

처음에는 기존 카운터처럼 오늘 / 월 / 총만 생각했다.

그런데 통계 페이지라면 특정 날짜나 기간도 봐야 한다.

그래서 /analytics API는 이렇게 받는다.

/analytics?range=today
/analytics?range=month
/analytics?range=total
/analytics?range=custom&start=2026-06-09&end=2026-06-12

total은 GA 전체 baseline이 아니라, analytics_daily_dimensions가 쌓이기 시작한 2026-06-09 이후의 세부 집계 기준이다. 사이드바의 총 조회수는 여전히 GA baseline + D1 increment다.

둘을 섞지 않았다.

전체 조회수 숫자와 세부 analytics 기준이 다르다는 점은 페이지와 운영 메모에 남겼다.

analytics 대시보드를 모바일 우선 막대 리스트로 짰다

통계 페이지는 특히 모바일에서 깨지기 쉽다.

표를 크게 만들면 바로 답답해진다. 그래서 표보다는 막대 리스트로 갔다.

핵심 숫자는 위에 네 개만 둔다.

선택 기간
오늘
이번 달
전체

그 아래는 카드형 막대 리스트다.

모바일에서는 기간 버튼이 2행으로 접히고, KPI는 2열, 상세 카드는 1열로 내려간다. 직접 기간 입력도 시작일, 종료일, 적용 버튼이 세로로 쌓인다.

데스크톱에서는 KPI가 한 줄이고, 상세 카드는 2열로 펼쳐진다.

브라우저에서 확인했을 때 가로 overflow는 없었다. 콘솔 오류도 없었다.

Worker 배포와 로컬 origin 차단을 확인했다

명령은 이렇게 돌렸다.

node --check cloudflare/ga-stats-worker.js
node --check assets/js/custom/visitor-stats.js
node --check assets/js/custom/analytics-dashboard.js
bundle exec jekyll build
npx wrangler d1 execute hyuk-blog-view-counter --remote --file cloudflare/schema.sql
npx wrangler deploy --keep-vars

Worker 배포 뒤 /analytics?range=today도 확인했다.

응답은 정상이고, 새 집계 테이블은 아직 비어 있었다. 당연하다. 세부 analytics는 배포 이후 실제 공개 방문부터 쌓인다.

로컬 origin에서 /track을 보내는 테스트도 했다.

{"status":"ignored","reason":"origin_not_tracked"}

이제 적어도 내가 로컬에서 글을 확인하는 행위가 생산 카운터를 올리지는 않는다.

방문자 카운터를 공개 analytics 페이지로 확장했다

처음에는 작은 숫자 세 개였다.

오늘, 월, 총.

그런데 실제로 운영해보니 숫자 자체보다 먼저 숫자가 오염되지 않는 구조가 필요했다. 그리고 공개 블로그라면, 숨겨진 관리자용 로그보다 공개 가능한 흐름을 보여주는 쪽이 더 맞았다.

정확한 분석 도구는 아니다. 그래도 이제 최소한 이런 질문에는 답할 수 있다.

어떤 글이 읽히는지.

어느 나라에서 들어오는지.

모바일이 많은지 데스크톱이 많은지.

검색인지 직접 유입인지.

그리고 무엇보다, 내가 작업하면서 만든 허수는 어디까지 막아야 하는지.

그 질문들을 보려고 /analytics/를 만들었다.