[연재] 조회수는 어떻게 세나 — 방문과 열람은 다른 수입니다

제일 많이 읽힌 글 1위가, 글이 아니었습니다

사이트가 얼마나 읽히는지 한눈에 보려고 요약을 만들던 날이었어요. 어려운 일도 아니라고 생각했습니다. 조회수는 이미 어딘가에 쌓이고 있었거든요. 그걸 받아다가 큰 순서로 줄만 세우면 되는 일이었죠.

받아온 표를 열어봤습니다. 그런데 위쪽이 이상했어요.

__visit__2026-07-24
__visit__2026-07-25
__visit__2026-07-26
260727-연재-도구-하나가-나오기까지...

맨 위 세 줄은 글이 아닙니다. 제목도 없고, 열어볼 수도 없어요. 그런데 숫자는 어느 글보다도 컸습니다.

이대로 정렬해서 "많이 읽힌 글"을 뽑으면 1등이 2026-07-24가 됩니다. 게다가 전부 더해서 "우리 사이트 총 조회수"라고 적으면, 있지도 않은 숫자가 얹힌 값이 나오고요.

누가 그런 이상한 걸 넣어뒀냐고요. 닷새 전의 저였습니다.

문제가 된 숫자가 붙어 있는 화면은 이렇게 생겼어요. 그냥 글 목록입니다. 날짜 뒤에 조그맣게 붙은 게 오늘 이야기의 주인공이고요.

닷새 전, 저는 새 테이블을 안 만들었습니다

7월 24일에 사이트를 크게 손봤어요. 그때 왼쪽 아래에 방문자 수를 붙였습니다. 오늘 몇 명, 누적 몇 명. 개인 홈페이지에 그거 하나 없으면 좀 허전하잖아요.

문제는 방문자를 담을 자리가 없었다는 거예요. 글 조회수를 담는 자리는 이미 있었는데, 방문자는 새로 만들어야 했습니다. 저장할 표를 하나 더 만들고, 권한을 다시 열어주고, 숫자를 올려주는 함수도 하나 더 만들고요.

그때 이런 생각을 했어요. "그냥 있는 데다 넣으면 안 되나?"

그래서 이렇게 했습니다. 조회수 표에 __visit__2026-07-24 라는 가짜 글을 한 편 만들어두고, 누가 사이트에 들어오면 그 가짜 글의 조회수를 1 올리는 거예요. 날짜별로 가짜 글이 하나씩 생기니까, 오늘 방문자는 오늘 날짜 줄을 보면 되고 누적은 가짜 글을 전부 더하면 됩니다.

새 표도, 새 함수도, 새 권한도 필요 없었어요. 코드 여섯 줄로 끝났습니다. 커밋에는 이렇게 적어뒀더라고요.

사이드바: 방문자 카운터(오늘/누적, 25초 라이브 갱신).
새 테이블 없이 bump_view RPC를 '__visit__<날짜>' 가상 슬러그로 재활용

그날 화면은 잘 나왔습니다. 오늘 몇 명, 누적 몇 명. 25초마다 알아서 새 값으로 바뀌고요. 만족했어요.

대가는 닷새 뒤에, 전혀 다른 자리에서 청구됐습니다. 편해 보이는 쪽을 고르면 대개 이렇게 되더라고요. 그 자리에서는 아무 일도 안 일어나고, 나중에 다른 데서 이상한 숫자로 돌아옵니다.

"몇 명이 왔나"는 사실 질문 두 개였어요

가짜 글을 걷어내려고 코드를 들여다보다가, 더 근본적인 걸 하나 놓치고 있었다는 걸 알았습니다.

저는 계속 "몇 명이 왔나" 하나를 알고 싶다고 생각했어요. 그런데 제가 가진 숫자는 두 종류였습니다.

• 방문 — 사이트에 들어온 사람 수
• 열람 — 글이 열린 횟수

이게 왜 다르냐면요. 한 사람이 들어와서 글을 다섯 편 읽으면 방문은 1이고 열람은 5입니다. 열 사람이 들어와서 각자 한 편씩만 읽고 나가면 방문은 10이고 열람도 10이고요.

두 경우의 열람 수는 똑같이 10에 가깝지만, 벌어지고 있는 일은 정반대예요. 앞쪽은 한 사람이 푹 빠져서 읽고 있는 것이고, 뒤쪽은 사람은 많이 왔는데 한 편만 보고 나간 겁니다. 앞쪽이면 글을 더 써야 하고, 뒤쪽이면 다음 글로 넘어가는 길을 만들어야 하죠. 할 일이 완전히 달라요.

그런데 두 숫자를 한 통에 담아두면 그걸 영영 구분할 수 없습니다. 합계는 늘어나는데 왜 늘어나는지는 모르는 상태가 되는 거예요.

그날 커밋에 이렇게 적었습니다.

방문은 '__visit__YYYY-MM-DD' 가상 슬러그로 쌓여서 글 조회수와 한 통에 있다.
갈라 놓지 않으면 상위 목록이 날짜로 도배되고 합계가 두 배로 부푼다 —
방문(사람 수)과 열람(글 연 횟수)은 다른 수다.

이 편에서 제일 중요한 대목이 여기예요. 저는 "어떻게 셀까"를 고민하고 있었는데, 진짜 문제는 "무엇을 셀까" 였습니다. 세는 방법은 코드가 알아서 합니다. 무엇을 세야 하는지는 아무도 안 알려줘요.

지금은 이렇게 갈라져 있습니다. 왼쪽 아래에는 오늘 · 누적 방문이 뜨고, 글 목록 각 줄에는 그 글이 열린 횟수가 붙어요. 같은 화면에 있지만 서로 다른 숫자입니다.

같은 사람이 새로고침을 열 번 하면 열 번인가요

지난 편 끝에서 던져놓은 질문이 이거였죠. 답부터 말하면 아니요입니다.

새로고침마다 1씩 올라가면 그 숫자는 아무 의미가 없어요. 저만 해도 글 하나를 올리고 나면 오타 고치느라 열 번씩 열어봅니다. 그때마다 숫자가 오르면, 그건 "몇 명이 읽었나"가 아니라 "제가 몇 번 새로고침했나"가 되죠.

그래서 규칙을 하나 뒀습니다. 같은 글은 6시간에 한 번만 셉니다.

/* 조회수 — 같은 사람이 새로고침할 때마다 오르면 숫자가 무의미해진다.
   같은 글은 6시간에 한 번만 센다. */

방식은 단순해요. 브라우저 안에 "이 글을 언제 셌는지"를 적어둡니다. 다시 열었을 때 6시간이 안 지났으면 숫자를 올리지 않고 읽어만 옵니다. 6시간이 지났으면 그때 1을 올리고 시각을 다시 적고요.

방문자 쪽도 같은 방식인데 기준이 다릅니다. 브라우저마다 하루에 한 번이에요. 오늘 처음 들어오면 오늘 날짜 칸을 1 올리고, 그다음부터는 숫자를 읽어만 옵니다.

그럼 이 숫자는 정확할까요? 아니요. 한계를 그대로 적어둘게요.

• 폰에서 한 번, 노트북에서 한 번 들어오면 두 명으로 셉니다. 브라우저를 기준으로 세니까요.
• 시크릿 창으로 들어오면 매번 새 사람입니다.
• 브라우저 기록을 지우면 다시 새 사람이 되고요.
• 반대로 6시간 안에 진짜 두 사람이 같은 컴퓨터로 같은 글을 읽으면 한 번으로 셉니다.

정확한 사람 수가 아니라 "대략 이 정도" 를 보는 눈금이에요. 저는 이걸 정확하게 만들려고 애쓰지 않기로 했습니다. 정확하게 만들려면 사람을 식별해야 하는데, 그건 다음에 나올 이야기 때문에 안 하기로 했거든요.

숫자를 마음대로 만들지 못하게

여기서 조금 다른 종류의 문제가 하나 있었습니다.

이 사이트는 서버가 없어요. 글은 전부 미리 만들어둔 파일이고, 조회수만 밖에 있는 데이터베이스에 저장합니다(지난 편 이야기예요). 그러니까 숫자를 올리는 일을 브라우저가 직접 합니다. 그리고 그러려면 브라우저 안에 열쇠가 들어 있어야 하죠.

이 열쇠는 공개용입니다. 누구든 화면 소스를 열면 볼 수 있어요. 그 상태에서 조회수 표에 직접 쓰는 길까지 열어두면 어떻게 될까요. 아무나 조회수를 999999로 만들 수 있습니다. 남의 글 조회수를 0으로 되돌릴 수도 있고요.

그래서 7월 22일에 조회수를 붙일 때부터 이렇게 해뒀습니다.

조회수는 Supabase 함수(bump_view)로만 올린다. anon 키로 테이블에
직접 쓰는 길은 막아 뒀다 - 열어두면 숫자를 마음대로 만들 수 있다.

표에 직접 쓰는 문은 잠가두고, "이 글 조회수를 1 올려줘"라는 함수 하나만 열어놨어요. 그 함수는 딱 그것밖에 못 합니다. 값을 정해서 넣을 수도 없고, 줄일 수도 없고, 남의 줄을 지울 수도 없어요.

물론 완벽한 방어는 아닙니다. 마음먹고 그 함수를 천 번 부르면 조회수는 천 오릅니다. 그건 못 막아요. 다만 누가 마음먹지 않는 한 틀어지지 않는 상태까지는 온 거고, 개인 사이트에는 그 정도면 충분하다고 봤습니다. 여기서 더 가려면 서버가 필요한데, 서버를 안 두기로 한 게 이 사이트의 첫 결정이었으니까요.

재밌는 부수 효과가 하나 있어요. 이 방식은 브라우저가 자바스크립트를 돌려야만 숫자가 올라갑니다. 그런데 검색엔진 수집기 같은 자동 프로그램은 대개 자바스크립트를 안 돌려요. 그래서 이 숫자는 기계보다 사람 쪽에 가깝습니다. 코드 주석에도 그렇게 적어뒀어요.

/* ... 봇은 JS를 안 돌려 대체로 사람 수다. */

서버 접속 기록으로 세면 정반대가 됩니다. 수집기가 하루에도 몇 번씩 훑고 가니까 숫자는 훨씬 커지는데, 그 안에 사람이 몇인지는 알 수가 없어요. 어느 쪽이 크냐가 아니라 어느 쪽이 내 질문에 답하느냐로 골랐습니다.

0은 아예 안 씁니다

목록에 조회수를 붙이면서 정한 표시 규칙이 하나 있어요. 조회수가 0이면 아무것도 안 붙입니다.

if (v[s]) parts.push('조회 ' + v[s]);

이 한 줄이에요. 숫자가 0이면 조건이 거짓이 되니까 '조회 0'이라는 글자 자체가 안 만들어집니다.

별거 아닌 것 같지만 화면에서는 꽤 다릅니다. 어제 올린 글에 '조회 0' 이 또렷하게 붙어 있는 목록을 상상해보세요. 아무도 안 읽었다는 사실이 화면에 대문짝만하게 걸려 있는 거예요. 쓴 사람 기분도 그렇지만, 들어온 사람도 그걸 봅니다.

숫자가 없으면 그냥 날짜만 뜹니다. 아래 사진에서 위쪽 글에는 날짜만 있고, 아래 두 글에는 날짜 뒤에 조회수가 붙어 있어요.

거짓말은 아닙니다. 0을 1로 적은 게 아니라 안 적은 것뿐이에요. 그런데 화면은 완전히 달라 보입니다. 무엇을 보여줄지 고르는 것도 결국 사람 몫이더라고요.

글을 하나 열면 제목 바로 아래, 날짜 옆에 붙습니다. 여기도 같은 규칙이에요.

총합만 보면 언제나 우상향입니다

숫자를 갈라놓고 나서 요약을 만들었는데, 며칠 보다가 이게 별로 쓸모없다는 걸 알았어요.

누적 조회수는 절대 안 줄어듭니다. 어제보다 오늘이 크고, 오늘보다 내일이 커요. 심지어 아무도 안 들어와도 그대로입니다. 줄지는 않으니까요.

그래서 그래프를 보면 늘 오른쪽 위로 갑니다. 기분은 좋은데 아무것도 안 알려줘요. "지금 잘 되고 있나" 라는 질문에 총합은 답을 못 합니다.

그래서 요약을 만들 때 어제 대비 얼마나 늘었는지를 같이 계산해 둡니다.

# 하루 전과 견준다. 없으면 가진 것 중 가장 오래된 것 — 처음엔 0 이 나온다.
day = next((s for s in reversed(hist[:-1]) if now - s["at"] >= 86400),
           hist[0] if len(hist) > 1 else None)

한 줄로 풀면 이래요. 지금부터 24시간 이상 지난 기록 중에 제일 최근 것을 찾아서, 그때와 지금을 뺍니다. 딱 "어제 이 시각"을 찍는 게 아니라 "24시간은 지난 것 중 가장 가까운 것"을 쓰는 거예요. 기록이 매시간 쌓이니까 대개 24~25시간 전 기록이 잡힙니다.

그런 기록이 아직 없으면(막 시작했을 때죠) 가진 것 중 제일 오래된 걸 씁니다. 그러면 증가분이 0으로 나와요. 없는 값을 그럴듯하게 지어내는 것보다 0이 낫다고 봤습니다.

글마다도 똑같이 어제 대비를 붙입니다. 다만 여기에 조건이 하나 더 있어요. 어제 기록에 없던 글은 증가분을 0으로 둡니다. 오늘 처음 생긴 글은 조회수 전부가 "오늘 늘어난 것"이 되는데, 그러면 새 글이 무조건 1등이 돼서 목록이 매일 뒤집히거든요.

화면에서 계산하지 않기로 한 것

여기가 이 편에서 제일 값어치 있는 판단이었다고 생각해요. 코드 맨 앞 주석에 이렇게 적어뒀습니다.

"""사이트가 얼마나 읽혔나 → site_stats_summary.json

쇼츠·릴스와 같은 규칙이다. 봇이 요약을 만들고 화면은 읽기만 한다 —
화면에서 계산하면 터미널에서 본 숫자와 갈라진다.
"""

무슨 말이냐면요. 화면에서 그때그때 계산하는 게 훨씬 쉬워 보입니다. 표를 통으로 받아와서 화면에서 더하면 되니까, 파일도 안 만들고 저장할 것도 없어요.

그런데 그렇게 하면 같은 숫자를 계산하는 자리가 두 곳이 됩니다. 하나는 화면, 하나는 제가 터미널에서 돌려보는 쪽이요. 둘이 처음에는 같아요. 그러다 한쪽만 고치는 날이 옵니다. "가짜 글은 빼고 더하자" 같은 걸 한쪽에만 넣는 거죠.

그때부터 화면의 숫자와 터미널의 숫자가 달라집니다. 그럼 어느 쪽이 맞는지 확인하러 가야 하고, 그러다 보면 둘 다 안 믿게 돼요. 계기판은 못 믿는 순간 없는 것보다 나쁩니다. 있으면 자꾸 보게 되거든요.

그래서 계산하는 자리를 하나로 못 박았습니다. 매시 35분에 프로그램이 한 번 돌면서

1. 지금 숫자를 통으로 받아와서 한 줄로 기록에 이어 붙이고 2. 가짜 글(방문)과 진짜 글(열람)을 갈라서 각각 합치고 3. 어제와 견줘 증가분을 붙이고 4. 결과를 요약 파일 하나로 다시 씁니다

화면은 그 요약 파일을 읽기만 해요. 더하지도, 빼지도, 정렬을 바꾸지도 않습니다. 화면이 뭘 계산하지 않으면 화면과 터미널이 갈라질 일이 없어요.

돌고 나면 이런 한 줄이 남습니다. 숫자는 가렸어요.

2026-08-17 08:35 · 글 310편 · 읽힘 ○,○○○ · 방문 ○○○(오늘 ○) (하루 +○○)

원본은 안 지웁니다

기록을 쌓는 방식도 한 가지 정한 게 있어요. 덮어쓰지 않고 이어 붙입니다.

한 시간에 한 번, 그 시각의 숫자를 통째로 한 줄 적어요. 지난 줄은 절대 안 건드립니다. 지금 그 파일은 400줄이 넘었고, 앞으로도 한 시간에 한 줄씩 계속 늘어납니다.

용량이 아깝지 않냐고요? 한 줄이 아주 작아서 몇 년을 쌓아도 사진 한 장보다 가볍습니다. 그리고 이유가 있어요.

요약은 언제든 다시 만들 수 있지만, 기록은 못 되살립니다.

나중에 "주말이랑 평일이 다른가?" 가 궁금해지면, 쌓아둔 줄을 다시 읽어서 새로 계산하면 돼요. 그런데 그때그때 요약만 쓰고 원본을 버렸으면 과거는 영영 없습니다. 오늘부터 다시 모아야 하고, 답은 한 달 뒤에나 나오죠.

화면에 보여주는 건 최근 30일치뿐이고, 글 순위도 상위 40편까지만 요약에 담습니다. 보여주는 걸 줄이는 것과 쌓아두는 걸 줄이는 건 완전히 다른 얘기예요. 화면은 좁혀도 되지만 기록은 넓혀둡니다.

제목이 ''폴드7' 막차' 로 찍혀 있었습니다

요약을 다 만들어놓고 열어봤는데, 글 제목 하나가 이렇게 적혀 있었어요.

'폴드7' 막차

원래 제목은 '폴드7' 막차 입니다. 작은따옴표요.

왜 이렇게 됐냐면, 제목을 만들어둔 페이지 파일에서 꺼내오기 때문이에요. 웹 페이지에서 따옴표 같은 기호는 ' 처럼 바꿔서 적어둡니다. 브라우저는 그걸 읽어서 화면에 따옴표로 그려주고요. 그러니까 페이지에는 원래 저렇게 들어 있는 게 맞습니다.

그런데 저는 그 파일을 브라우저가 아니라 글자 그대로 읽어왔어요. 브라우저가 해주던 번역을 아무도 안 해준 거죠. 그래서 한 줄을 넣었습니다.

# ' 같은 것을 풀어 둔다. 그냥 두면 화면에 그대로 찍힌다 —
# 제목에 따옴표를 쓴 글이 ''폴드7' 막차' 로 보였다.
t = html.unescape(m.group(1).strip())

이건 프로그램이 절대 안 잡아주는 종류의 문제예요. 오류가 안 납니다. 값도 정상이고, 파일도 잘 만들어지고, 숫자도 다 맞아요. 그냥 사람이 읽었을 때만 이상합니다. 눈으로 안 봤으면 그대로 갔을 거예요.

애초에 제목을 꺼내오는 일 자체가 사람을 위한 것이기도 합니다. 기계는 260813-연재-성경-아틀라스-2-지형-위에... 같은 주소만 있으면 충분해요. 그런데 사람은 그걸 보고 어느 글인지 못 알아봅니다. 그래서 페이지를 뒤져서 제목을 붙이는 코드가 따로 있어요. 주석에도 그렇게 적혀 있고요.

"""슬러그 → 제목. 화면에 슬러그만 뜨면 어느 글인지 모른다."""

셀 수 있다고 다 세지는 않았습니다

이 편에서 진짜 하고 싶은 얘기가 이거예요. 무엇을 셀지 정하는 것만큼 무엇을 안 셀지 정하는 것도 결정이었습니다.

마음만 먹으면 이런 걸 다 셀 수 있어요. 어디서 들어왔는지, 어떤 검색어로 왔는지, 몇 초 머물렀는지, 어디까지 스크롤했는지, 어느 링크에 마우스를 올렸는지. 분석 도구 하나 붙이면 코드 두 줄로 전부 따라옵니다. 요즘은 그게 기본값에 가깝죠.

안 붙였습니다. 지금 이 사이트에는 분석 도구가 하나도 없어요. 이유가 셋입니다.

첫째, 남의 정보를 받아두면 지킬 의무가 생깁니다. 개인정보처리방침에 뭘 받는지 다 적어야 하고, 적었으면 실제로 그렇게 굴러가야 해요. 지금 조회수 칸에는 이렇게 적혀 있습니다 — "글별 조회 횟수 (개인 식별 안 함)". 이 한 줄을 지키려면 개인을 식별하는 걸 안 받으면 됩니다. 안 받은 건 샐 일도 없어요.

둘째, 화면이 무거워집니다. 분석 도구는 대개 남의 서버에서 코드를 하나 더 받아옵니다. 그러면 페이지가 그만큼 늦게 뜨죠. 이 사이트는 파일만 올려두는 방식이라 빠른 게 거의 유일한 자랑인데, 그걸 숫자 보려고 깎고 싶지 않았어요.

셋째, 봐도 제가 할 게 없습니다. 평균 체류 시간이 42초라고 나오면 저는 뭘 하죠? 늘리려고 글을 늘려야 하나요? 저는 어떤 글이 읽히는지만 알면 됩니다. 그건 글별 조회수 하나로 충분해요.

대신 못 아는 것도 생깁니다. 숫자를 올리는 함수는 "어느 글"만 받고 "어디서 왔는지"는 안 받아요. 그러니까 검색으로 들어온 사람이 몇인지, 링크를 타고 온 사람이 몇인지 저는 모릅니다. 그건 진짜 모르는 채로 두기로 했어요. 모르는 걸 아는 척하는 것보다 낫다고 봤습니다.

숫자가 작다는 걸 그대로 보기로 했습니다

숫자가 들어오고 나서야 쓸 수 있게 된 게 하나 있어요. 목록 위의 정렬 단추입니다. 최신순·오래된순은 날짜만 있으면 되지만, 조회수순은 숫자가 먼저 와 있어야 생길 수 있는 기준이거든요.

눌러보면 이렇게 위에서부터 다시 세워집니다.

여기서 하나 배운 게 있습니다. 숫자가 작을 때는 순위가 별 의미가 없어요. 몇 회 차이로 1등과 5등이 갈리니까, 하루만 지나도 순서가 통째로 바뀝니다. 그러니 "이 글이 제일 인기"라고 말할 수가 없어요. 그냥 "요즘 이 근처가 좀 읽힌다" 정도죠.

그래서 총합보다 어제 대비 증가분을 보게 됐습니다. 총합은 지금까지 쌓인 것이고, 증가분은 어제 뭔가 달라졌나를 알려주니까요.

연재 글만 따로 모아 세워보면 이렇게 보이고요.

숫자를 여기 적지는 않을게요. 개인 사이트 성적이라 자랑할 것도 부끄러워할 것도 아니고, 무엇보다 이 편의 얘기는 숫자가 얼마냐가 아니라 그 숫자를 어떻게 만들었냐 니까요.

첫 화면과 폰에서도 똑같이 보입니다. 폭이 좁아지면 왼쪽 메뉴가 접히는데, 붙는 숫자는 같은 규칙이에요.

정리하면

세는 일은 쉬워 보였는데 정할 게 꽤 많았어요. 그리고 정한 것들은 거의 다 코드가 아니라 판단이었습니다.

이 중에 코드로 어려운 건 하나도 없었어요. 전부 "무엇을 알고 싶은가" 를 먼저 정해야 답이 나오는 것들이었습니다. 그걸 안 정하고 세기 시작하면 가짜 글이 인기 1위가 되는 표를 만들게 되고요.

그리고 마지막 하나. 요약을 만들어놓고 눈으로 열어봤기 때문에 제목이 깨진 걸 잡았습니다. 그건 오류로 안 나요. 코드는 끝까지 아무 말도 안 해줍니다.

다음 편에

다음 편은 실패담입니다. 자동화가 매일 밤 정확하게 돌면서 제 사이트를 망가뜨리고 있었습니다.

고장이 난 게 아니에요. 하나도 안 고장 났어요. 시킨 대로 매일 09시에 정확히 돌았습니다. 그런데 그 사이에 일의 방향이 반대로 뒤집혔고, 크론은 그걸 모릅니다. 알 방법도 없고요.

며칠 동안 조용히 틀어지고 있던 걸 어떻게 알아챘는지 쓰겠습니다.

#조회수카운터 #방문자카운터 #웹분석 #액세스로그 #Supabase #수파베이스 #정적사이트 #서버리스 #개인홈페이지 #홈페이지만들기 #블로그통계 #구글애널리틱스 #개인정보처리방침 #데이터수집 #지표설계 #대시보드 #크론탭 #자동화 #파이썬 #자바스크립트 #로컬스토리지 #RLS #행수준보안 #클라우드플레어페이지스 #무료호스팅 #바이브코딩 #AI코딩 #클로드 #휴먼인더루프 #빅터하우스