네버와 티토리를 벗어난 순간, 내 방문자는 ‘익명’이 된다

최근에 직접 기술 블로그를 운영하기 시작해 보니, 플랫폼 블로그에서는 당연하게 주어지던 방문자 통계를 이제는 내가 직접 골라 붙여야 했다. 그런데 막상 붙이고 보니 문제는 “무슨 도구를 쓸까”보다 “내가 지금 무엇을 보려는가”에 더 가까웠다.

처음에는 Google Analytics와 Cloudflare Web Analytics를 비교하면 끝나는 문제라고 생각했다. 그런데 실제로 써 보니 나는 서로 다른 층위를 한데 묶어서 보고 있었다. 특히 전세계에서 /.env와 그 파생 경로를 반복 조회하는 요청을 보면서 처음에는 “Cloudflare Web Analytics가 이런 것도 잘 보여주는구나”라고 생각했다. 다시 보니 이건 단순 웹 분석이라기보다 Worker 레벨의 요청 관측에 더 가까운 이야기였다.

블로그를 운영한다는 것은 결국 세 종류의 신호를 다루는 일에 가깝다.

방문자는 어떻게 들어왔는가
네트워크 요청은 어떻게 흘렀는가
백엔드나 Worker는 그 요청을 어떻게 처리했는가

이 경험을 기준으로 다시 정리하면 구분은 세 가지다.

Google Analytics는 사용자 행동 분석 도구다.
Cloudflare Web Analytics는 엣지 레벨 웹 분석 도구다.
Cloudflare Workers 기반 관측은 애플리케이션 운영 관측에 가깝다.

즉, 이 셋은 모두 “통계”처럼 보이지만 실제로는 서로 다른 층위의 질문에 답한다.

Web Analytics 와 Observability 는 비슷해 보여도 같은 범주가 아니다.

방문자(트래픽)를 보는 세 가지 관점

같은 트래픽을 보더라도, 블로그 운영에서 던지는 질문은 층위마다 달라진다.

“누가 어떤 글을 읽었나?”
“어떤 요청이 들어왔나?”
“내 Worker가 그 요청을 어떻게 처리했나?”

flowchart TB
    A["Google Analytics<br/>사용자 행동 분석"]
    B["Cloudflare Web Analytics<br/>엣지 레벨 웹 분석"]
    C["Cloudflare Workers 기반 관측<br/>요청 처리와 운영 관찰"]

    A --> D["무엇을 읽었나<br/>어디서 들어왔나"]
    B --> E["어떤 요청이 들어왔나<br/>전달은 어땠나"]
    C --> F["요청을 어떻게 처리했나<br/>내 코드 안에서 무슨 일이 있었나"]

Google Analytics: 사용자 행동 분석

Google Analytics는 브라우저 안에서 실행되는 스크립트로 데이터를 모은다.

클라이언트 사이드(client-side) 는 사용자의 브라우저에서 코드가 실행되는 방식을 뜻한다.

그래서 이 도구는 “방문자가 이 블로그를 어떻게 소비했는가”를 읽는 데 강하다.

어떤 글이 많이 읽혔는지
검색, SNS, 외부 링크 중 어디서 유입됐는지
클릭, 스크롤, 전환 같은 이벤트가 얼마나 발생했는지
어느 페이지에서 이탈이 많았는지

이벤트(event) 는 페이지뷰, 클릭, 스크롤, 다운로드처럼 사용자의 특정 행동을 하나의 기록 단위로 저장한 것이다.

UTM 은 링크에 붙여 유입 경로를 구분하는 추적 파라미터다. 예를 들어 뉴스레터, X, 광고, 커뮤니티 링크를 서로 다르게 식별할 때 쓴다.

콘텐츠 성과나 유입 분석에는 여전히 가장 직접적이다. 특히 utm_source, utm_medium, utm_campaign 같은 값을 함께 보면 어떤 채널에서 어떤 글이 읽혔는지 해석하기 쉽다. 블로그 운영자 입장에서는 “방문자”를 보는 도구에 가장 가깝다. 반면 광고 차단기나 추적 방지 기능 영향을 많이 받고, 비정상 요청이나 서버 단 이상 징후는 거의 보여주지 못한다.

Cloudflare Web Analytics: 엣지 레벨 웹 분석

Cloudflare Web Analytics는 사용자 요청이 Cloudflare 엣지를 통과하는 흐름을 기준으로 본다.

엣지(edge) 는 원본 서버보다 사용자 가까이에서 요청을 먼저 받는 CDN 또는 프록시 지점을 말한다.

이 도구는 사용자 세부 행동보다 요청과 전달 상태, 즉 네트워크에 가까운 층위를 더 잘 본다.

요청이 얼마나 들어왔는지
어떤 경로가 많이 호출됐는지
페이지뷰가 어느 정도 발생했는지
전달 성능이 대체로 어떤지

정적 블로그에서는 이쪽 숫자가 더 안정적으로 보일 때가 많다. Google Analytics처럼 브라우저 스크립트가 막혀서 통계가 빠지는 문제가 덜하기 때문이다. 블로그 운영에서 “방문자 행동”보다 “요청 흐름”을 보고 싶을 때는 이쪽이 더 직접적이다.

TTFB(Time To First Byte) 는 요청 후 첫 번째 바이트를 받기까지 걸린 시간을 뜻한다.

다만 여기서 선을 그어야 한다. Cloudflare Web Analytics는 어디까지나 웹 분석이다. 엣지에서 본 요청과 전달 흐름은 보여주지만, 내 애플리케이션 코드 내부에서 어떤 분기와 처리가 일어났는지까지 설명해 주지는 않는다. 즉, 이 도구는 “네트워크를 통과한 요청”을 보는 쪽에 가깝다.

Cloudflare Workers 기반 관측: 운영과 처리 흐름

내가 .env 경로 탐색 시도를 보고 혼동했던 부분이 바로 여기다. 그 신호는 “페이지가 얼마나 읽혔는가”가 아니라 “들어온 요청을 내 코드가 어떻게 처리했는가”에 가까웠다. 이 지점부터는 이미 방문자 통계보다는 백엔드 운영 관점으로 넘어간다.

Observability 는 서비스 내부에서 무슨 일이 일어나는지 로그, 메트릭, 트레이스 같은 신호로 파악할 수 있는 능력을 뜻한다.

LGTM 은 보통 Loki, Grafana, Tempo, Mimir 조합을 가리키며, 로그·메트릭·트레이스를 함께 보는 관측 스택을 뜻한다.

PLG 스택은 여기서는 Promtail, Loki, Grafana처럼 로그 중심으로 가볍게 관측을 구성하는 흐름을 가리킨다.

Cloudflare Workers로 배포하면 요청을 직접 처리하게 되므로, 단순 요청 수를 넘어서 운영 문맥을 붙여 볼 수 있다.

어떤 경로 요청을 차단했는지
어떤 국가나 도시에서 비정상 요청이 반복되는지
특정 요청을 캐시로 보냈는지, 원본으로 보냈는지
어떤 분기에서 어떤 응답 코드를 반환했는지
처리 시간이 어디서 길어졌는지

이 관점은 정적 사이트 방문 통계보다는, 일반적인 백엔드 개발자가 로그와 메트릭을 쌓아 운영 상태를 파악하려는 흐름에 더 가깝다. 그래서 감각으로는 Cloudflare Web Analytics보다 LGTM 같은 관측 스택 쪽에 더 닿아 있다. 말하자면 이 영역은 “방문자”보다 “로그와 메트릭”을 보는 감각에 가깝다.

반대로 이 글에서 다루는 대상은 정적 웹에 가깝기 때문에 PostHog 같은 제품 분석 도구와는 조금 거리가 있다. 그런 도구는 보통 웹앱 안에서 퍼널, 기능 사용 흐름, 세션 재생, 기능 채택처럼 더 제품 분석적인 질문에 잘 맞는다.

즉, Workers 기반 관측은 Cloudflare Web Analytics의 상위 버전이라기보다, 아예 다른 층위의 도구라고 보는 편이 맞다.

솔루션별 특징 한눈에 비교

관점	Google Analytics	Cloudflare Web Analytics	Cloudflare Workers 기반 관측
주된 질문	누가 무엇을 읽었나	어떤 요청이 들어왔나	요청을 어떻게 처리했나
관찰 위치	브라우저	Cloudflare 엣지	Worker 실행 코드
강한 영역	유입, 이벤트, 콘텐츠 성과	요청량, 페이지뷰, 경로 분포, 전달 흐름	로그, 분기 처리, 차단, 응답 제어
약한 영역	비정상 요청, 서버 처리	사용자 세부 행동, 코드 내부 처리	마케팅 분석, 유입 경로 분석
잘 맞는 용도	콘텐츠 운영	웹 트래픽 파악	운영 관측과 디버깅

언제 무엇을 보면 되나

Google Analytics를 볼 때

어떤 글이 실제로 잘 읽히는지 보고 싶을 때
검색 유입과 SNS 유입을 구분하고 싶을 때
클릭, 스크롤, 전환 같은 사용자 행동을 보고 싶을 때

Cloudflare Web Analytics를 볼 때

사이트 전체 요청 흐름을 빠르게 훑고 싶을 때
경로별 요청량이나 404 분포를 보고 싶을 때
정적 블로그 기준으로 페이지뷰를 비교적 안정적으로 보고 싶을 때

Workers 기반 관측을 볼 때

수상한 요청이 어디서 반복되는지 알고 싶을 때
특정 요청을 왜 차단했는지 추적하고 싶을 때
코드 분기, 응답 상태, 처리 시간을 운영 관점에서 보고 싶을 때

정리

핵심은 블로그 운영에서 다루는 신호를 한 줄로 묶지 않는 것이다.

Google Analytics는 사람의 행동을 본다.
Cloudflare Web Analytics는 웹 요청과 전달 흐름을 본다.
Cloudflare Workers 기반 관측은 애플리케이션의 처리 과정을 본다.

직접 운영하는 기술 블로그에서는 이 세 층위가 자주 겹쳐 보인다. 하지만 질문을 나눠 보면 정리가 쉽다. “누가 읽었나”를 알고 싶으면 Google Analytics, “어떤 요청이 들어왔나”를 알고 싶으면 Cloudflare Web Analytics, “내 Worker가 그 요청을 어떻게 처리했나”를 알고 싶으면 Workers 기반 관측을 보면 된다.

네*버와 티*토리를 벗어난 순간, 내 방문자는 ‘익명’이 된다