Cloudflare 조회수가 이상할 때

같은 글의 조회수가 Cloudflare 대시보드에서는 120, 서버 로그에서는 340, 다른 분석 도구에서는 95로 나올 수 있습니다. 어느 숫자가 틀렸다고 보기 전에 먼저 해야 할 일은 세 숫자가 같은 것을 세고 있는지 확인하는 것입니다. 위 숫자는 설명을 위해 만든 가정이고 실제 측정값이 아닙니다.

Cloudflare Web Analytics 조회수가 실제 사람 수와 다르게 보이는 이유는 크게 네 갈래로 나뉩니다. 세는 단위가 다르고, 세는 방법이 다르고, 봇이 섞여 있고, 기간에 따라 숫자의 성격이 바뀝니다. 아래에서는 이 네 가지를 차례로 풀고, 대시보드에서 봇 제외 필터를 켜고 끄며 숫자 변화를 기록하는 절차까지 이어 갑니다. 봇 제외 필터 비교는 대시보드를 읽기만 하고 설정은 바꾸지 않습니다.

먼저 어디부터 의심할까

숫자가 어긋날 때 원인 후보를 확인 순서대로 늘어놓으면 이렇습니다.

1번과 2번은 설정을 열어 보지 않아도 되는 확인이라서 가장 먼저 합니다. 이 두 단계는 설정을 열지 않고 할 수 있어서 가장 먼저 합니다.

조회수와 방문 수는 다른 숫자입니다

Web Analytics의 핵심 지표는 Visits, Page views, Page load time, Core Web Vitals 네 가지입니다. 이 가운데 조회수와 관련된 것은 앞의 둘입니다.

Visits는 이전 페이지의 주소(HTTP referer)가 지금 사이트의 호스트 이름과 다를 때 새 방문으로 셉니다. 한 번의 방문 안에 page view가 여러 개 들어갈 수 있습니다. 그래서 같은 사람이 글 세 편을 이어서 읽으면 Page views는 3, Visits는 1이 됩니다.

고유 방문자 수(unique visitors)라는 항목은 이 지표 목록에 없습니다. Cloudflare는 개별 사용자를 고객 사이트들에 걸쳐 추적하지 않습니다. 그래서 “오늘 몇 명이 읽었나”라는 질문에는 Web Analytics 숫자만으로 답할 수 없습니다. 조회수가 높다고 독자가 많다고 단정하면 안 되는 첫 번째 이유입니다.

Web Analytics는 어떻게 세는가

Cloudflare Web Analytics는 방문자의 브라우저에서 도는 작은 JavaScript 스크립트(beacon)가 보낸 신호를 모아 세는 방식입니다. 이 스크립트는 페이지를 볼 때마다 실행되고, 일반 웹사이트에서는 페이지 로드가 끝났을 때와 방문자가 페이지를 떠날 때 /cdn-cgi/rum 주소로 측정값을 보냅니다. 한 화면에서 주소만 바뀌는 단일 페이지 앱(SPA)은 화면 전환마다 측정값이 추가로 전송됩니다.

이 구조에서 곧바로 따라오는 결과가 몇 가지 있습니다.

• 스크립트가 막히면 그 방문은 세어지지 않습니다. 광고 차단 확장 프로그램 중에는 이 스크립트를 막는 것들이 있습니다.
• 스크립트가 들어가지 않은 페이지는 아예 집계 대상이 아닙니다. Cloudflare 프록시를 거치는 사이트가 자동 설정을 쓰면 해당 영역의 모든 페이지에 스크립트가 들어가지만, 직접 설치하는 수동 설정에서는 스크립트가 있는 페이지만 집계됩니다.
• 자동 설정에서 Enable, excluding visitor data in the EU 옵션을 고르면 EU 방문자에게는 스크립트가 들어가지 않습니다. 이 옵션을 켜 둔 사이트는 다른 도구보다 숫자가 낮게 나올 수 있습니다.
• 원본 서버가 Cache-Control: public, no-transform 헤더를 보내면 Cloudflare 프록시가 응답을 고칠 수 없어서 스크립트가 자동으로 삽입되지 않고, Web Analytics가 동작하지 않습니다.
• 콘텐츠 보안 정책(CSP)을 쓰는 사이트는 스크립트를 불러오는 주소를 허용해야 합니다.
• 처음 설정한 직후에는 데이터가 나타나기까지 몇 분이 걸릴 수 있습니다.

서버가 받은 요청을 세는 방식과는 근본적으로 다릅니다. 원본 서버가 받은 요청 기록에는 광고 차단기가 막은 방문도, 스크립트가 없는 페이지에 대한 요청도, 검색 엔진과 봇의 요청도 남을 수 있습니다. 다만 Cloudflare 캐시가 대신 응답했거나 차단한 요청은 원본 서버까지 오지 않아 원본 로그에 없을 수 있으므로, 원본 서버 로그와 Cloudflare 쪽 기록은 따로 구분해서 봅니다. 반대로 서버 로그에는 방문자가 페이지를 떠나는 시점 같은 브라우저 안의 사건이 없습니다. 두 숫자는 일부러 같은 단위로 만들어진 것이 아닙니다.

Cloudflare 프록시를 쓰는 사이트는 별도로 엣지 분석도 받습니다. Web Analytics 화면은 브라우저 쪽 분석만 보여 주고, 서버 쪽 요청을 URL별로 나눠 보려면 Pro, Business, Enterprise 플랜의 고급 HTTP 트래픽 분석이 필요합니다. 봇 제외 비교 절차는 Web Analytics 화면 안에서만 진행합니다.

Exclude Bots로 봇 트래픽 제외하기

Exclude Bots는 Web Analytics에서 데이터에 걸 수 있는 필터 기준(dimension) 가운데 하나입니다. 값을 Yes로 두면 봇 트래픽을 뺀, 실제 사용자 트래픽에 더 가까운 데이터가 됩니다. 이 필터를 켠 숫자도 사람 수를 확정한 값이 아니라 봇 제외 필터를 적용한 값으로 읽어야 합니다. 문서가 말하는 효과는 ‘실제 사용자 트래픽에 더 가까운 데이터’까지입니다.

이 절차는 조회만 하고 사이트 설정은 바꾸지 않습니다. 필터는 화면에서 보는 범위를 좁힐 뿐입니다. 하나의 글(경로)을 정해 전후를 비교하는 방식으로 진행합니다.

1. Cloudflare 대시보드 왼쪽 메뉴에서 관찰 가능성 > Analytics > Web Analytics를 엽니다(영문 화면에서는 Web Analytics).
2. 확인할 사이트를 선택합니다.
3. 그래프 위의 기간 드롭다운으로 비교할 기간을 정합니다. 기본값은 지난 24시간입니다. 그래프에서 구간을 끌어 선택해 특정 시간대만 볼 수도 있습니다.
4. 필터 추가를 선택하고 새 필터 상자에서 경로를 골라 확인할 글의 경로를 /blog처럼 /로 시작하게 입력한 뒤 적용합니다.
5. 왼쪽의 방문(Visits)과 페이지 보기(Page views) 카드 숫자를 기록합니다. 이것이 봇 제외를 적용하기 전 기준값입니다.
6. 다시 필터 추가를 선택해 봇 제외를 Yes로 두고 적용합니다. 화면에는 봇 제외 같음 Yes 칩이 생깁니다.
7. 같은 기간, 같은 경로에서 Page views와 Visits를 다시 기록합니다.
8. 두 기록을 나란히 놓고 변화량을 봅니다.

아래는 weftware.com의 /blog를 지난 24시간으로 본 화면입니다(2026-10-27). 첫 화면은 경로 같음 /blog 칩만 있고, 두 번째는 봇 제외 같음 Yes 칩을 더했습니다.

두 화면에서 방문은 0, 페이지 보기는 7로 같습니다. 이 글, 이 기간에는 봇 제외 필터가 걸러 낸 트래픽이 없었다는 뜻이지, 봇이 없다는 뜻은 아닙니다. 방문이 0인데 페이지 보기가 7인 것은 방문이 ‘다른 사이트나 직접 링크에서 시작한 페이지 보기’만 세기 때문에 생기는 차이로 읽힙니다. 두 화면은 같은 시점에 연달아 찍었습니다. 시간 간격을 두고 찍으면 그사이 새 방문이 섞여서 필터 효과와 구분되지 않습니다.

변화량 읽는 법

변화량을 “봇 비율”이라고 이름 붙이지 않는 편이 안전합니다. 필터 하나가 걸러 낸 몫일 뿐 실제 봇의 전체 몫이 아니기 때문입니다.

7일 이내와 그 이상이 다른 이유

대시보드의 조회수 숫자는 모든 구간에서 같은 성격이 아닙니다. 방문자 브라우저에서 도착한 신호는 수신 단계에서 샘플링 없이 모두 기록하고, 이 원본은 최근 7일 동안만 비샘플링 상태로 보관됩니다. 그 이후에는 원래 양의 약 10% 수준으로 줄여 집계한 값을 장기 보관합니다. 접근할 수 있는 기간은 지난 6개월입니다.

이와 별개로 대시보드와 GraphQL API가 숫자를 계산할 때도 샘플링 수준이 정해지며, 7일 이내라도 이 샘플링은 걸릴 수 있습니다. 집계할 때는 적용한 필터와 해당하는 행의 양에 따라 0.0001%에서 100% 사이의 샘플링 수준이 자동으로 정해집니다. 방문이 아주 적은 사이트는 더 높은 비율로 샘플링해서 집계의 신뢰도를 유지합니다.

같은 사이트를 기간만 바꿔 본 화면입니다. 왼쪽 카드의 숫자에 주목합니다.

7일에서 30일로 가면 방문은 45에서 440으로 약 10배, 페이지 보기는 219에서 680으로 약 3배입니다. 두 숫자의 늘어난 비율이 크게 다릅니다. 이 차이가 샘플링 때문인지, 기간별 방문 구성이 달랐기 때문인지는 대시보드 숫자만으로는 가를 수 없습니다. 그래서 길이가 다른 기간의 숫자는 이어 붙이지 않습니다.

이 내용을 숫자 해석에 옮기면 몇 가지 주의점이 생깁니다.

• 최근 7일 안의 숫자와 한 달짜리 숫자는 같은 정밀도로 계산된 값이 아닙니다. 길이가 다른 기간의 숫자를 단순히 이어 붙이거나 비교할 때는 이 차이를 염두에 둡니다.
• 필터를 추가하면 샘플링 수준이 달라질 수 있습니다. 경로 필터와 봇 제외 필터를 겹쳤을 때 숫자가 필터의 효과 때문에 변했는지, 샘플링 수준이 바뀐 탓인지 대시보드 숫자만으로는 구분하기 어렵습니다. 전후 비교는 가능하면 7일 이내의 같은 기간에서 하는 것이 낫습니다.
• 샘플링 결과는 추정치입니다. Cloudflare 분석에서 샘플링은 표본 수에 비율의 역수를 곱해 전체를 추정하는 방식이어서, 비율이 10%일 때 표본이 5,000건이면 전체는 5만 건(5,000 × 10)으로 보여 줍니다. 계산 방식을 이해하기 위한 예이고 Web Analytics 숫자에 대입한 값이 아닙니다.
• GraphQL API로 숫자를 가져오는 경우에만 해당하며 대시보드만 쓴다면 건너뛰어도 됩니다. 가져온다면 응답에 sampleInterval 필드가 있고, 이 필드가 질의에 적용된 샘플링 수준을 알려 줍니다. 숫자를 저장해 둘 때 이 값을 함께 저장하면 나중에 서로 다른 시점의 숫자를 비교할 때 같은 수준으로 계산되었는지 구분할 수 있습니다.

“수신된 이벤트 수”와 “대시보드에 보이는 숫자”도 혼동하지 않아야 합니다. 수신 단계에서는 샘플링을 하지 않고 받은 신호를 모두 기록하지만, 우리가 대시보드에서 보는 것은 그 위에서 집계하고 추정한 값입니다.

지금까지의 내용을 방문 하나가 대시보드 숫자가 되기까지의 흐름으로 이으면 아래와 같습니다. 세어지지 않는 지점과 숫자의 성격이 달라지는 지점이 서로 다른 곳에 있습니다.

숫자가 너무 낮을 때와 너무 높을 때

기대한 것보다 낮게 나오는 경우와 높게 나오는 경우는 원인 후보가 거의 겹치지 않습니다. 증상별로 나눠서 확인하면 빠릅니다.

낮게 나올 때

스크립트가 아예 실행되지 않는 페이지가 있는지부터 봅니다. 확인 순서는 이렇습니다.

1. Web Analytics 사이트 목록에서 해당 사이트 카드의 사이트 관리(Manage site) 링크를 열어 설정 방식을 봅니다. 화면에는 사용(JS 코드 조각 자동 삽입), 활성화(EU에서는 방문자 데이터 제외), JS 코드 조각을 설치하여 활성화(수동 설치), 사용 중지 네 가지가 있습니다. EU 제외 옵션이 선택되어 있으면 EU 방문자는 숫자에서 빠지고, 수동 설치라면 숫자가 낮은 페이지에 스크립트가 실제로 들어 있는지 확인합니다.

2. 경로별 규칙이 걸려 있는지 봅니다. 자동 설정은 기본적으로 영역 전체에 스크립트를 넣는 규칙 하나를 만들고, 사이트 관리 > 고급 옵션의 규칙에서 호스트 이름과 경로를 지정해 일부 경로를 포함하거나 제외할 수 있습니다. 이 계정의 고급 옵션에는 필터링된 트래픽의 Web Analytics를 보려면 Pro 플랜 이상으로 업그레이드하라는 안내가 보입니다. 규칙은 Cloudflare 프록시를 거치는 사이트에서만 쓸 수 있고, Free 플랜은 규칙 수가 0이라 모든 하위 도메인에 스크립트가 들어갑니다.
3. 원본 서버의 Cache-Control 응답 헤더에 no-transform이 있는지 확인합니다. 아래 명령은 페이지를 GET으로 한 번 요청해 응답 헤더만 출력하고 아무것도 바꾸지 않습니다.

curl -s -o /dev/null -D - https://example.com/ | grep -i cache-control

example.com을 확인할 사이트 주소로 바꿔 실행합니다. 출력이 cache-control: public, no-transform처럼 나오면 Cloudflare 프록시가 응답을 고치지 못해 스크립트가 자동으로 들어가지 않습니다. 이 명령이 보여 주는 것은 Cloudflare 엣지가 내보낸 응답 헤더라 원본과 다를 수 있고, 경로나 요청 방식에 따라 헤더가 달라질 수 있으니 확정 진단이 아니라 단서로 봅니다. no-transform이 들어 있으면 원본 서버의 응답 헤더 설정에서 해당 값을 빼야 하고, 설정 위치는 서버마다 다르니 사용하는 호스팅의 캐시 헤더 설정을 확인합니다. 헤더가 아예 없거나 no-transform이 없으면 이 원인은 아닙니다.

4. 브라우저 개발자 도구의 Console 탭에서 스크립트 로드 오류를 봅니다. 사이트가 콘텐츠 보안 정책(CSP) 헤더를 쓴다면 두 군데를 열어 줘야 합니다. 스크립트를 내려받을 수 있도록 script-src에 https://static.cloudflareinsights.com/beacon.min.js를 추가하고, 측정값을 보낼 수 있도록 connect-src도 맞춥니다. 자동 설정에서는 같은 도메인으로 전송하므로 'self'가 들어 있어야 하고, 수동 설치에서는 cloudflareinsights.com이 들어 있어야 합니다. 운영 사이트에 바로 적용하기보다 테스트 환경이나 Content-Security-Policy-Report-Only로 먼저 확인하는 편이 안전합니다.
5. 태그 관리자(Google Tag Manager 등)로 스크립트를 넣었다면 코드 형태를 확인합니다. 태그 관리자에는 data-cf-beacon 속성 대신 사이트 토큰을 주소의 쿼리 문자열(beacon.min.js?token=...)로 넣는 형태를 씁니다. 이때 CSP의 script-src에도 쿼리 문자열이 붙은 주소를 그대로 적어야 합니다.
6. 광고 차단 확장 프로그램을 끈 브라우저 창에서 페이지를 열어 보고 같은 현상인지 비교합니다. 차단기를 켠 창과 끈 창에서 대시보드의 Page views가 각각 얼마나 늘어나는지 보면, 스크립트가 막히는 환경인지 알 수 있습니다.

높게 나올 때

봇이 가장 먼저 떠오르지만, 한 사람이 만드는 중복 조회도 있습니다. 그래서 탐색 유형(Navigation type)으로 조회가 어떤 경로로 일어났는지 나눠 봅니다. 필터 추가의 기준 목록(경로, 참조자, 장치 유형, 탐색 유형 등)에서 고를 수 있고, 이 기준에는 링크를 눌러 새로 연 경우(Navigate), 새로고침(Reload), 뒤로 가기·앞으로 가기(Back-forward), 브라우저가 미리 그려 둔 페이지(Prerender), 스크립트가 화면만 바꾼 이동(Soft Navigation, Routing APIs) 등이 구분되어 있고, 새로고침과 뒤로 가기는 캐시에서 다시 그린 값(Reload Cache, Back-forward Cache)이 따로 있습니다. 비중을 볼 때는 둘을 합쳐 봅니다. 필터를 한 번에 하나씩 추가하면서 어느 유형이 큰 몫을 차지하는지 보면, 높은 숫자의 상당 부분이 새로고침이나 단일 페이지 앱의 화면 전환인지 알 수 있습니다.

• 새로고침과 뒤로 가기 비중이 높다면 같은 독자가 반복해서 본 몫이 큽니다. 봇과는 별개의 이야기입니다.
• 화면 전환(Soft Navigation, Routing APIs) 비중이 높은 사이트라면 단일 페이지 앱이 경로가 바뀔 때마다 조회를 추가로 보내고 있을 가능성을 의심합니다.
• 특정 국가, 기기, 브라우저에 한쪽으로 쏠려 있다면 Country, Device type, Browser 필터로 쏠림을 확인합니다. 쏠림 자체가 봇의 증거는 아니지만, 설명이 필요한 숫자라는 표시입니다.

고친 뒤 확인하는 방법

설정을 바꾸었다면 데이터에 반영되기까지 몇 분은 기다립니다. 그다음 같은 경로를 새 창에서 열고, 대시보드의 기간을 지난 24시간으로 두고 Page views가 늘어나는지 봅니다. 광고 차단기를 끈 새 창에서 여러 번(예: 5회) 열고 몇 분 뒤 숫자가 늘어나는지 봅니다. 샘플링 때문에 정확히 +5가 아닐 수 있으니 늘어나기만 하면 수집은 되는 것입니다. 숫자가 바로 움직이지 않으면 필터가 남아 있는 것은 아닌지, 기간이 너무 넓어 변화가 가려지는 것은 아닌지 먼저 봅니다.

그래도 맞지 않을 때

위의 설치·필터 점검을 끝냈는데도 다른 도구와 큰 차이가 남으면, 측정 방식 자체가 다른 숫자끼리 비교하고 있을 가능성이 큽니다. 브라우저 스크립트로 세는 숫자와 서버가 받은 요청 수는 어긋나는 것이 정상입니다. 이럴 때는 어느 쪽이 맞는지 가리려 하지 말고, 각 숫자가 답하는 질문을 정해 따로 기록하는 쪽이 낫습니다.

다른 도구와 숫자가 다를 때 확인할 순서

서버 로그나 다른 분석 도구와 비교한다면 아래 순서로 조건을 맞춥니다. 조건이 하나라도 다르면 숫자가 다른 것이 정상입니다.

1. 기간과 시간대. 하루 경계를 어느 시간대로 자르는지 두 도구가 같은지 확인합니다.
2. URL 단위. Cloudflare Web Analytics는 쿼리 문자열을 기록하지 않습니다. 다른 도구가 ?utm_source=...가 붙은 주소를 따로 센다면 경로 기준으로 합쳐서 비교해야 합니다.
3. 지표 종류. Page views는 Page views끼리, Visits는 방문 단위로 센 숫자끼리 맞춥니다. 사용자 수와는 비교하지 않습니다.
4. 필터. 한쪽만 봇을 제외한 숫자라면 다른 쪽도 같은 조건으로 맞추거나, 둘 다 제외하지 않은 숫자끼리 비교합니다.
5. 수집 방식. 브라우저 스크립트 기반인지 서버 요청 기반인지에 따라 광고 차단과 봇의 영향이 다릅니다.
6. 설치 범위. 수동 설치라면 스크립트가 빠진 페이지가 없는지, 자동 설정이라면 EU 제외 옵션이나 no-transform 헤더가 걸려 있지 않은지 봅니다.

이 여섯 가지를 맞춘 뒤에도 차이가 크다면 그때 측정 오류를 의심해도 늦지 않습니다. 맞춘 것이 하나도 없는 상태에서 숫자가 다르다고 오류로 해석하면 헛수고가 됩니다.

비교 기록 양식

아래 양식에 전후 값을 적습니다.

기록할 때 지킬 점은 두 가지입니다. 기간과 경로는 전후에서 반드시 같게 둡니다. 그리고 같은 비교를 서로 다른 기간(예를 들어 최근 3일과 최근 30일)에서 한 번씩 해 보면 샘플링이 숫자에 어느 정도 끼어드는지 감을 잡을 수 있습니다. 두 결과의 변화 비율이 크게 다르다면 샘플링 수준이 달랐을 수도 있고 기간마다 봇 비중이 달랐을 수도 있습니다. 이 비교만으로는 어느 쪽인지 가를 수 없으니 변화량은 참고로만 기록합니다.

어떤 숫자를 기준으로 볼까

조회수를 어디에 쓰려는지에 따라 믿어야 할 숫자가 달라집니다.

서버에서 직접 이벤트를 세는 카운터를 두는 경우에도 그 숫자가 가리키는 것은 서버가 받은 이벤트의 개수이지 독자의 수가 아닙니다. 같은 사람이 새로고침을 하면 올라가는 숫자와, 방문 단위로 센 숫자는 처음부터 다른 질문에 답합니다. 그래서 Cloudflare의 브라우저 기준 분석과 직접 집계를 하나로 합치려 하지 말고, 각자 어떤 질문에 답하는지를 정해 두고 따로 읽는 편이 낫습니다.

Cloudflare를 쓰는 사이트라면 조회수와 별개로 요청 단위 사용량과 비용을 보여 주는 화면도 있습니다. 이쪽 숫자는 Cloudflare Workers 기본에서 다룬 Billable Usage처럼 요금을 계산하려는 목적이어서, 조회수와 같은 단위로 비교할 수 없습니다.

마무리 정리

• 숫자를 비교하기 전에 기간, 경로, 지표 종류(Page views, Visits), 필터를 먼저 맞춥니다. 이 네 가지만 맞춰도 차이의 상당 부분이 설명됩니다.
• 봇 영향이 궁금하면 같은 경로와 같은 기간에서 Exclude Bots를 Yes로 바꾸기 전후의 Page views와 Visits를 기록합니다. 변화량은 “필터로 걸러진 몫”이라고만 읽습니다.
• 전후 비교는 가능하면 최근 7일 이내의 기간에서 하고, 길이가 다른 기간끼리의 숫자를 직접 이어서 해석하지 않습니다.
• 사람 수가 필요하면 Web Analytics의 Visits를 참고만 하고, 정확한 요청 건수가 필요하면 서버 로그나 직접 집계를 따로 둡니다.
• 설치 범위(자동 또는 수동 설정, EU 제외 옵션, Cache-Control: public, no-transform)를 한 번 점검하면, 일부 페이지의 조회수가 계속 낮게 나오는 원인을 빠르게 걸러 낼 수 있습니다.