기술 블로그가 GA4로 놓치는 트래픽 60%, 측정할 수 있을까 (1편)

관리자 페이지에 조회수 컬럼을 추가하려다가, 제가 지금까지 얼마나 편향된 숫자를 보고 있었는지를 먼저 직시하게 됐습니다. 이 블로그는 오랫동안 Google Analytics 4(GA4)만 붙여 두고 있었습니다. 대시보드는 예쁘지만, 기술 블로그 독자의 상당수는 GA4가 애초에 카운트하지 못하는 존재라는 점이 이제야 마음에 걸렸습니다.

이 글은 4편짜리 시리즈의 첫 번째입니다. "GA4 외에 자체 조회수를 어떻게 붙였나"를 다루기 전에, 왜 GA4만으로는 충분하지 않은지부터 정리해두고 싶었습니다.

기술 블로그 독자의 60%는 GA4에 잡히지 않는다

광고 차단기 얘기입니다. uBlock Origin, AdBlock Plus, Brave의 내장 차단, Firefox의 Enhanced Tracking Protection, Safari의 Intelligent Tracking Prevention까지 — 이들은 EasyList와 EasyPrivacy 같은 공개 필터 리스트를 참고해서 google-analytics.com, googletagmanager.com 등을 네트워크 레벨에서 차단합니다. 요청 자체가 GA4 서버에 도달하지 않으니, 그 방문은 GA4에 존재하지 않는 셈이 됩니다.

문제는 독자 구성에 따라 차단율이 크게 달라진다는 점입니다. Plausible이 자사 블로그 방문자를 대상으로 측정한 결과는 꽤 충격적이었습니다.

독자군	GA 차단율
일반 웹사이트 평균	15~30%
기술 블로그 평균	58.67%
Firefox 사용자	88.28%
Linux 사용자	82.30%
uBlock Origin 사용자	~99%

제가 쓰고 있는 GA4 대시보드가 "월 1,000 PV"라고 말한다면, 실제로는 2,000~3,000에 가까울 가능성이 높다는 뜻입니다. 단순히 숫자가 작다는 문제를 넘어, 독자군이 편향돼 있기도 합니다. 광고 차단기를 쓰지 않는 일부 독자만 집계되고, 정작 "제 글을 가장 깊게 읽어주는 개발자 독자"는 측정에서 빠져나간다는 점이 특히 마음에 걸렸습니다.

그렇다면 다른 도구로 바꾸면 되는가

2022년 EU에서 Google Analytics 사용이 GDPR 위반이라는 판정이 이어진 이후, 셀프호스팅 analytics 시장은 빠르게 성장했습니다. 대표적인 대안을 몇 가지 살펴봤습니다.

도구	DB	메모리 부담	특징
Umami	PostgreSQL	~256MB	쿠키리스, MIT, 대시보드 깔끔
Plausible CE	PG + ClickHouse	~2GB	AGPL, 셀프 CE는 봇 필터링 취약
GoatCounter	SQLite/PG	매우 낮음	Go 단일 바이너리, 가장 가벼움
Counterscale	없음(CF AE)	0	Cloudflare Workers 기반, 무료 티어

조사하면서 한 가지가 걸렸습니다. 이 중 MongoDB를 쓰는 도구가 단 하나도 없다는 사실입니다. 메인스트림 셀프호스팅 analytics는 모두 PostgreSQL 또는 ClickHouse 기반입니다. 제 블로그는 MongoDB Atlas 한 군데에 모여 있는 모노레포라서, 새 DB 컨테이너를 하나 더 띄우고 백업 정책을 분리하고 관리자 페이지를 넘나들 이유가 썩 달갑지 않았습니다.

게다가 실제로 Plausible Community Edition을 써본 개발자(Loopwerk)의 최근 회고를 보면, 봇 필터링이 Cloud 버전만큼 정교하지 않아서 일일 200명이던 숫자가 5,000명으로 폭증한 사례도 있었습니다. 셀프호스팅이 만능은 아니라는 경고였습니다.

결국 자체 카운터를 붙이는 수밖에 없었습니다

여러 글을 읽으면서 결론이 좁혀졌습니다. 제 스택과 운영 여력을 고려하면, 자체 백엔드에 조회수 API 하나를 여는 방식이 가장 현실적이었습니다. 이유는 세 가지입니다.

첫째, first-party 도메인(예: api.mydomain/…/view)은 광고 차단기의 필터 리스트에 등재돼 있지 않습니다. 차단기 입장에서 보면 "개인 블로그가 자기 백엔드에 보내는 평범한 POST 요청"이라 막을 이유가 없습니다. GA4가 잃어버리던 60%가 대부분 돌아옵니다.

둘째, MongoDB의 $inc 연산자 한 줄이면 원자적으로 조회수를 올릴 수 있습니다. 신규 인프라가 필요 없습니다.

셋째, GA4는 완전히 버리지 않습니다. 유입 채널, 검색어, 체류 시간, 디바이스 분포 같은 풍부한 차원은 GA4 쪽이 여전히 훨씬 강합니다. GA4 Data API로 일일 배치 동기화만 해두면, 정확한 "절대값"은 자체 카운터에서, 상세 분석은 GA4에서 가져올 수 있습니다.

3-레이어 하이브리드 아키텍처

그래서 아래와 같이 정리했습니다.

Layer 1  실시간 자체 카운터 (광고 차단 우회)
  POST /blog-posts/:slug/view
    → isbot 필터 + IP 해시 + 24h 디바운스
    → blog_posts.viewCount $inc 1

Layer 2  GA4 Data API 일일 배치 (상세 차원)
  @Cron('0 4 * * *', KST)
    → pagePath × [PV, 채널, 국가, 디바이스, 체류시간]
    → blog_posts.ga4Stats 갱신

Layer 3  GSC 검색 성과 (이미 연동됨)
  관리자 페이지의 glass box

"그러면 자체 카운터 숫자와 GA4 숫자가 얼마나 차이 날까?"라는 질문이 남는데, 이건 실제로 운영해본 뒤에 나오는 데이터로 검증할 생각입니다. 비율 자체가 "내가 얼마나 편향된 렌즈로 블로그를 보고 있었는지"의 지표가 되리라 기대합니다.

다음 편 예고

다음 글에서는 이 Layer 1을 실제로 어떻게 구현했는지를 정리합니다. Next.js 클라이언트에서 fetch로 first-party 엔드포인트를 치는 부분, NestJS 쪽의 isbot + $inc 로직, 그리고 view_logs 컬렉션의 unique index + TTL 설계까지 담겠습니다.

"그런 걸 왜 굳이 직접 만드느냐"는 질문에 제가 들인 시간과 바꾸려고 했던 것이 정리되는 글이 되면 좋겠습니다.