VPS에서 운영하기 좋은 자가 호스팅 웹 분석 도구 추천

VPS에서 운영할 만한 자가 호스팅 웹 분석 도구는 무엇인가?

자가 호스팅 웹 분석 도구는 크게 두 가지 유형으로 나뉩니다. 잘못된 유형을 선택하면 제품 자체를 잘못 선택하는 것보다 더 큰 비용이 발생합니다. 첫 번째 유형은 방문자의 브라우저에서 작은 스크립트를 실행하고 해당 스크립트가 보고하는 내용을 저장합니다. 두 번째 유형은 웹 서버가 이미 기록하고 있는 접근 로그를 읽어 들입니다. 데이터베이스와 필요한 메모리 용량을 포함한 이후의 모든 사항은 이 첫 번째 선택에 따라 결정됩니다.

소규모 서버를 위한 짧은 답변입니다. GoatCounter와 Medama는 1 GB 메모리 환경에 적합합니다. 두 도구 모두 단일 파일 위에서 하나의 프로세스로 동작하기 때문입니다. Umami는 Postgres 컨테이너를 추가하며, 비기술자도 읽을 수 있는 대시보드를 제공합니다. Plausible Community Edition과 Rybbit은 모두 ClickHouse를 실행하므로 2 GB 이상의 RAM을 계획해야 합니다. Matomo는 완전한 기능을 갖춘 제품으로, 트래픽 규모에 맞는 서버 사양을 요구합니다. GoAccess는 이미 존재하는 로그를 읽기 때문에 페이지에 어떠한 요소도 추가하지 않습니다.

스크립트 태그와 서버 로그: 각각 무엇을 볼 수 있는가

스크립트 태그는 브라우저를 측정합니다. 페이지가 로드되고 스크립트가 실행되면 수집기로 요청을 하나 보냅니다. 이 과정 중 하나라도 중단되면 데이터를 확인할 수 없습니다. JavaScript가 비활성화되었거나, 필터 목록이 요청을 차단했거나, 수집기로의 요청이 실패했거나, 스크립트를 실행하지 않는 크롤러인 경우가 이에 해당합니다.

로그 파서는 요청을 측정합니다. 웹 서버는 설치 여부와 관계없이 요청당 한 줄씩 기록하므로 데이터는 이미 디스크에 존재합니다. 로그 파서는 모든 크롤러와 스크립트 태그가 없는 파일에 대한 모든 히트를 확인합니다. 하지만 브라우저 내부에서 일어난 일은 볼 수 없으며, 브라우저 캐시나 서버 앞단의 CDN(콘텐츠 전송 네트워크)에서 제공된 페이지도 볼 수 없습니다. 해당 요청은 서버에 도달하지 않았기 때문입니다.

두 수치는 일치하지 않으며, 어느 쪽도 틀린 것은 아닙니다. Matomo는 두 방식 모두 지원하며, 로그 가져오기 방식에서 JavaScript 추적기보다 부족한 정보를 문서화하고 있습니다. 화면 해상도, 페이지 제목, 이벤트, 콘텐츠 추적, 히트맵, 세션 기록, 폼 분석 등이 이에 해당합니다. 이 목록은 브라우저 대신 요청을 집계할 때 치러야 할 대가입니다.

봇 트래픽은 차이의 나머지 절반을 차지합니다. 로그 기반 집계에는 필터링하지 않는 한 크롤러가 포함되며, 일반적인 사이트에서 크롤러가 차지하는 비중은 결론을 바꿀 만큼 큽니다. GoAccess와 Matomo의 로그 가져오기 기능은 모두 알려진 봇을 필터링합니다. 하지만 User Agent를 속이는 크롤러까지는 걸러낼 수 없습니다. 이것이 로그 기반 집계와 서버 수준에서 AI 크롤러 차단하기를 병행하고, 차단 전이 아닌 차단 후에 로그를 읽어야 하는 타당한 이유입니다.

GoAccess: 이미 보유한 로그를 통한 분석

배포판 패키지는 최신 릴리스보다 버전이 뒤처지므로, 프로젝트의 공식 Debian 및 Ubuntu 저장소에서 설치하십시오.

wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg arch=$(dpkg --print-architecture)] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess

그런 다음 로그를 지정하여 정적 보고서를 작성합니다.

goaccess /var/log/nginx/access.log -o ~/report.html --log-format=COMBINED

Ubuntu에서 nginx 로그는 root 소유이며 그룹은 adm이므로, 일반 사용자가 실행하면 Permission denied 오류가 발생하며 실패합니다. sudo usermod -aG adm $USER 명령으로 해당 그룹에 자신을 추가하십시오. 그룹 멤버십은 로그인 시점에 읽히므로, 로그아웃 후 다시 로그인해야 합니다. id을 실행하여 목록에 adm가 나타나는지 확인한 뒤 다시 시도하십시오.

실시간 로그에 대한 보고서는 logrotate가 아직 이동시키지 않은 내용만 포함합니다. 어제의 요청은 access.log.1에 위치하며 더 오래된 로그는 압축되어 있으므로, 주간 단위로 보려면 로테이트된 파일까지 함께 읽어야 합니다.

zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED -o ~/last-week.html

WebSocket을 통해 페이지를 업데이트하는 실시간 모드인 --real-time-html도 있습니다. 이 모드는 별도의 포트와 전용 프록시 규칙이 필요합니다. 대부분의 사이트에서는 cron으로 매시간 보고서를 작성하는 것만으로도 충분하며, 보안 유지 측면에서도 더 유리합니다.

GoatCounter: 단일 Go 바이너리와 SQLite 파일 하나

GoatCounter는 정적으로 컴파일된 바이너리로 제공되므로 별도의 런타임 설치가 필요하지 않습니다. 릴리스 페이지에서 빌드 파일을 내려받아 실행하거나 이미지를 사용하십시오.

docker run -p 8080:8080 -v goatcounter-data:/home/goatcounter/goatcounter-data arp242/goatcounter

바이너리로 실행할 경우 goatcounter serve는 8080 포트에서 대기하며 ./goatcounter-data/db.sqlite3에 SQLite 파일을 생성합니다. 인스턴스가 이미 프록시 뒤에 있다면 웹 마법사 대신 명령줄에서 첫 번째 사이트를 생성하십시오.

goatcounter db create site -vhost=stats.example.com -user.email=me@example.com

goatcounter serve -listen=:443 -tls=tls,rdr,acme를 사용하여 자체적으로 인증서를 관리할 수 있으며, ACME(자동 인증서 관리 환경)를 활용하므로 다른 서비스가 없는 서버에서 유용합니다. nginx나 Caddy가 이미 443 포트를 점유하고 있다면 GoatCounter를 8080 포트에 두고 프록시를 통해 연결하십시오. 추적 스크립트의 크기는 프로젝트 공식 수치 기준으로 약 3.5K이며, JavaScript를 지원하지 않는 페이지를 위한 추적 픽셀도 제공합니다. 트래픽이 많은 사이트에서 SQLite의 성능 한계에 도달하면, 동일한 바이너리를 goatcounter serve -db 'postgresql+dbname=goatcounter'와 함께 사용하여 Postgres로 전환할 수 있습니다. 백업은 파일 복사만으로 충분하며, 이것이 바로 이러한 형태의 도구가 가진 가장 큰 장점입니다.

Medama: 256 MB를 요구하는 단일 컨테이너

Medama는 이 분야에서 가장 최근에 등장한 단일 바이너리 옵션입니다. 설계상 쿠키를 사용하지 않으며, 프로젝트 측은 1 KB 미만의 추적기와 256 MB 메모리를 가진 가상 머신에서 소규모 사이트를 운영할 수 있다고 명시합니다. 이는 프로젝트에서 발표한 주장이며, 본 가이드에서 직접 측정한 수치는 아닙니다.

docker volume create medama-data
docker run -d -p 127.0.0.1:8080:8080 -v medama-data:/app/data ghcr.io/medama-io/medama:latest

공식 명령어는 포트를 8080:8080으로 게시합니다. 위 루프백 접두사는 의도된 것이며, 리버스 프록시 섹션에서 그 이유를 설명합니다. 첫 로그인은 admin이며 비밀번호는 CHANGE_ME_ON_FIRST_LOGIN입니다. 해당 비밀번호의 이름이 곧 지침입니다.

문서화된 한 가지 실패 사례에 주의해야 합니다. 로그인은 HTTPS를 통하거나 localhost에서만 작동합니다. 따라서 인증서 설정 전에 프록시를 먼저 구성하면, 올바른 비밀번호를 입력해도 폼에서 거부하며 그 이유는 출력되지 않습니다. TLS(transport layer security) 설정을 먼저 완료한 후 로그인하십시오.

Umami: Postgres 및 익숙한 대시보드

git clone https://github.com/umami-software/umami.git
cd umami
docker compose up -d

이 명령은 3000번 포트에서 애플리케이션을 시작하며, 그 옆에 PostgreSQL 컨테이너를 함께 실행합니다. 문서에 따르면 최소 요구 사양은 PostgreSQL v12.14이며, 소스에서 직접 빌드할 경우 Node.js 18.18 이상이 필요합니다. 미리 빌드된 이미지인 docker.umami.is/umami-software/umami:postgresql-latest을 사용할 수도 있는데, 이 경우 이미 운영 중인 데이터베이스를 가리키는 DATABASE_URL 설정이 필요합니다.

최초 로그인 계정은 admin이며 비밀번호는 umami입니다. DNS 레코드가 확인되고 프록시가 응답하는 즉시 인터넷에서 해당 인스턴스에 접근할 수 있으므로, DNS를 연결하기 전에 반드시 비밀번호를 변경하십시오. Compose 세부 설정, 환경 변수 파일, 재시작 정책에 관해서는 내용을 확인하지 않은 스택을 그대로 복사하기보다 VPS에서의 Docker Compose 스택 문서를 참조하십시오.

시스템 점유율은 Node 프로세스와 Postgres를 합친 수준입니다. 이는 단일 바이너리보다는 무겁지만, ClickHouse를 사용하는 어떤 환경보다 훨씬 가볍습니다.

Plausible Community Edition: ClickHouse의 RAM 하한선 설정

git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
touch .env
echo "BASE_URL=https://stats.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
docker compose up -d

2026년 8월 기준으로 v3.2.1 버전이 최신이며, clone 명령은 의도적으로 이 버전을 고정합니다. 스택은 애플리케이션, 계정 및 설정을 위한 Postgres, 이벤트 데이터를 위한 ClickHouse의 세 부분으로 구성됩니다. SECRET_KEY_BASE는 최소 64바이트 문자열이어야 하며, 이는 openssl 호출을 통해 생성됩니다.

Plausible은 ClickHouse와 애플리케이션이 OOM(Out of Memory) killer에 의해 종료되지 않도록 최소 2 GB의 RAM을 요구하며, ClickHouse가 필요로 하는 SSE 4.2 또는 NEON을 지원하는 CPU가 필요합니다. 두 번째 요구 사항은 구매 전에 반드시 확인해야 하며, 이는 ARM과 x86 VPS 선택 시 발생하는 실질적인 차이점 중 하나입니다. 또한 ClickHouse는 가용 메모리만큼 자원을 점유하려 하므로, 공유 서버를 사용할 경우 Compose에서 컨테이너 메모리 제한하기에 설명된 대로 상한선을 설정해야 합니다.

BASE_URL은 공용 URL과 정확히 일치해야 합니다. 일치하지 않으면 로그인 후 애플리케이션이 잘못된 호스트로 리다이렉트하며, 브라우저가 위치한 도메인이 아닌 다른 도메인으로 세션 쿠키가 작성되어 오류 메시지 없이 다시 로그인 화면으로 돌아오게 됩니다.

제공된 compose 파일은 프록시를 앞에 두는 것을 전제로 하므로 포트를 외부에 노출하지 않습니다. 루프백 인터페이스에서만 기본 애플리케이션 포트를 노출하도록 override 파일을 추가하십시오.

cat > compose.override.yml << EOF
services:
    plausible:
        ports:
            - 127.0.0.1:8000:8000
EOF

Matomo: 전체 제품 및 요구 서버 사양

Matomo는 PHP와 MySQL 또는 MariaDB 환경에서 실행되므로 컨테이너 스택보다는 전통적인 웹 스택에 적합합니다. 또한 이 문서에서 다루는 도구 중 트래픽 규모에 따른 하드웨어 가이드를 공식적으로 제공하는 유일한 제품입니다.

[
  {
    "label": "100K/month",
    "cpu_cores": 2,
    "ram_gb": 2,
    "disk_gb": 50
  },
  {
    "label": "1M/month",
    "cpu_cores": 4,
    "ram_gb": 8,
    "disk_gb": 250
  },
  {
    "label": "10M/month",
    "cpu_cores": 8,
    "ram_gb": 16,
    "disk_gb": 400
  }
]

위 수치는 2026년 8월 기준 Matomo가 발표한 최소 사양이며, 본 가이드에서 직접 측정한 값은 아닙니다. 월간 페이지뷰 100,000회까지는 2개의 CPU 코어, 2 GB의 RAM, 50 GB의 SSD가 필요하며, 애플리케이션과 데이터베이스를 하나의 서버에서 운영합니다. 1M/month 규모에서는 8 GB의 RAM과 250 GB의 디스크가 필요합니다. 10M/month 규모부터는 Matomo가 두 대의 서버를 권장하며, 마지막 행은 데이터베이스 서버 사양인 16 GB의 RAM과 400 GB의 디스크를 나타냅니다. 전체 데이터셋이 하나의 SQLite 파일로 구성되는 단일 바이너리 옵션과 비교하여 해당 디스크 수치를 확인하십시오.

아카이빙(Archiving)은 사용자들을 당황하게 만드는 요소입니다. 기본 설정에서 Matomo는 사용자가 대시보드를 열 때 보고서를 생성하므로, 데이터가 증가함에 따라 대시보드 속도가 느려지고 결국 타임아웃이 발생합니다. 이에 대한 공식 해결책은 일반 설정에서 브라우저 트리거 방식의 아카이빙을 끄고, Matomo 파일 소유자 계정으로 Matomo 디렉터리에서 cron을 통해 아카이버를 실행하는 것입니다.

php console core:archive --url=https://analytics.example.com

Matomo는 처리된 보고서 테이블과 별도로 원본 로그 테이블을 유지하며, 일정에 따라 오래된 원본 데이터와 보고서를 삭제할 수 있습니다. 이 기능은 디스크가 가득 찼을 때가 아니라 설치 시점에 미리 활성화하십시오. Matomo는 서버 접근 로그를 가져올 수도 있어, 이 문서에서 다루는 제품 중 유일하게 두 가지 분석 방식을 모두 지원합니다.

Rybbit 및 최신 스택

git clone https://github.com/rybbit-io/rybbit.git
cd rybbit
chmod +x *.sh
./setup.sh your.domain.name

Rybbit은 현대적인 대시보드를 갖춘 최근 등장한 도구입니다. 설치 스크립트는 환경 파일을 작성하고 Docker Compose를 사용하여 스택을 구동합니다. 이 도구는 ClickHouse를 실행하며, 자체 웹 서버로 Caddy를 포함합니다. Caddy는 443 포트를 점유하고 입력한 도메인에 대한 인증서를 요청합니다. 이미 nginx가 443 포트를 사용 중인 서버에서는 스크립트가 포트에 바인딩할 수 없으므로, 프로젝트에서 제공하는 수동 Compose 방식을 사용하여 기존 프록시 뒤에 배치해야 합니다. 문서에 따르면 최소 2 GB의 RAM이 필요하며, Ubuntu 24 LTS에서 테스트되었고, ClickHouse 사용으로 인해 ARM 환경에서는 ARMv8.2-A 이상이 요구됩니다.

모든 신규 프로젝트가 그렇듯 주의할 점이 있습니다. 기능이 빠르게 추가되는 만큼 변경 사항으로 인한 호환성 문제도 발생할 수 있습니다. 특정 태그를 고정하고, 업데이트를 수행하기 전에 릴리스 노트를 읽고, 무엇보다 먼저 데이터베이스를 백업하십시오.

보존 기간과 디스크 증가량: 직접 측정하기

디스크 증가량은 도구가 이벤트마다 무엇을 저장하느냐에 따라 달라집니다. GoatCounter는 히트를 카운터로 집계하므로, 파일 크기는 원시 데이터의 양보다는 고유 페이지와 날짜 수에 따라 증가합니다. Umami와 Matomo는 이벤트마다 행을 저장하며, Matomo는 원시 데이터 외에도 처리된 보고서 테이블을 추가로 저장합니다. ClickHouse는 이벤트를 열 단위로 저장하고 강력하게 압축하므로, Plausible은 행 기반 저장소라면 부담스러울 정도의 트래픽도 처리할 수 있습니다.

이 가이드에서는 백만 페이지 뷰당 메가바이트 수치를 제시하지 않습니다. 귀하의 트래픽 환경에서 직접 측정한 값이 아니기 때문입니다. 직접 측정하십시오. 서비스 및 사용자 이름은 귀하의 Compose 파일에 맞게 조정하십시오.

du -h goatcounter-data/db.sqlite3
docker compose exec db psql -U umami -d umami -c "SELECT pg_size_pretty(pg_database_size('umami'));"
docker compose exec plausible_events_db clickhouse-client -q "SELECT formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active"

현재 수치를 기록하고 일주일 뒤 다시 기록한 다음, 그 차이를 대시보드에 보고된 해당 주의 페이지 뷰 수로 나눕니다. 이 수치는 귀하의 사이트와 봇 필터링 환경을 반영하므로, 공개된 평균치보다 훨씬 가치가 있습니다. 수치가 작을 때 보존 제한을 설정하십시오. 디스크가 가득 차면 분석 도구뿐만 아니라 VPS의 모든 서비스가 중단됩니다. 이것이 바로 데이터베이스 볼륨을 df -h가 경고를 보낼 수 있는 위치에 두어야 하는 가장 강력한 이유입니다. 이미 용량이 큰 데이터를 보관 중인 서버라면 이 위험에 더 주의를 기울여야 합니다. 직접 호스팅하는 사진 서버는 분석 데이터베이스가 차기도 전에 디스크를 모두 소모할 것이기 때문입니다.

리버스 프록시 뒤에서의 동작 방식

수집기를 측정 대상 사이트의 서브도메인(예: stats.example.com)에 배치합니다. 이렇게 하면 수집기 요청이 퍼스트 파티(first party)로 간주되므로, 서드 파티 요청을 차단하는 브라우저 정책의 영향을 받지 않습니다.

컨테이너 포트를 공개할 때 애플리케이션을 loopback에 바인딩한다. Docker는 ufw보다 앞서 자체 방화벽 규칙을 적용하므로, -p 3000:3000으로 공개한 컨테이너는 ufw status에서 해당 포트를 거부한다고 표시하더라도 인터넷에서 접근할 수 있다. 다른 시스템에서 curl http://SERVER_IP:3000로 테스트하면 대시보드가 표시된다. -p 127.0.0.1:3000:3000으로 공개하면 같은 테스트에서 Connection refused가 반환되고 proxy만 접근할 수 있다. 이러한 설정은 대시보드를 숨기는 데 그치지 않는다. 같은 장비에서 onion service 실행의 핵심이기도 하다. 공개 인터페이스에서 계속 응답하는 서비스가 있으면 숨겨진 주소와 사용자의 IP가 연결되기 때문이다. collector endpoint는 공개 인터넷에서 계속 접근할 수 있어야 하지만 대시보드는 그럴 필요가 없다. 두 번째 subdomain을 공개하는 대신 private network를 통해 대시보드를 확인하려면 subnet router로 VPS network를 tailnet에 광고하면 포트를 열지 않고도 접근할 수 있다.

server {
    listen 443 ssl;
    server_name stats.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

포워딩 헤더는 이 구성에서 선택 사항이 아닙니다. X-Forwarded-For가 없으면 모든 방문이 127.0.0.1에서 온 것으로 기록되므로, 국가별 보고서가 비어 있게 되고 순 방문자 수가 1명으로 집계됩니다. 각 프로젝트마다 신뢰하는 헤더와 설정 방식이 다르므로, 임의로 판단하지 말고 해당 프록시의 문서를 확인하십시오. Caddy는 이러한 헤더를 자동으로 설정하며, 동일한 작업을 수행하는 Caddyfile은 단 두 줄로 작성할 수 있습니다.

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

아직 프록시를 선택하지 않았다면, Nginx, Caddy, Traefik 비교 문서를 통해 소수의 서브도메인을 운영하는 단일 서버에 가장 적합한 도구가 무엇인지 확인하십시오.

직접 호스팅을 할 때도 쿠키 배너가 필요한가요?

직접 호스팅을 한다고 해서 데이터의 소유 주체는 바뀔 수 있어도, 데이터에 관한 법적 규정까지 바뀌지는 않습니다. 두 가지 규칙을 구분해야 합니다. ePrivacy 동의 규칙은 방문자의 기기에 무언가를 저장하거나 읽는 행위에 관한 것이므로, 쿠키를 설정하지 않고 로컬 스토리지에 아무것도 기록하지 않는 도구는 해당 요구 사항에서 제외됩니다. GDPR은 개인 데이터 처리에 관한 규정이며, IP 주소는 개인 데이터로 간주됩니다. 따라서 여전히 적법한 처리 근거와 보관 기간을 설정해야 하며, 누군가 자신의 데이터를 어떻게 보유하고 있는지 문의할 경우 이에 대응할 준비가 되어 있어야 합니다.

Plausible, Umami, GoatCounter, Medama는 기본적으로 쿠키를 설정하지 않습니다. 각 도구가 대신 무엇을 수집하는지는 프로젝트마다 다르며 버전 업데이트에 따라 변경될 수 있으므로, 요약본보다는 해당 프로젝트의 개인정보 처리방침 문서를 직접 확인하십시오. Matomo는 관리자 인터페이스에서 활성화할 수 있는 IP 익명화 기능과 수집 거부(opt-out) 엔드포인트를 제공합니다.

국가별로 규제 기관의 판단은 다를 수 있습니다. 예를 들어 프랑스의 CNIL은 방문자 통계 분석이 동의 면제 대상이 될 수 있는 조건을 명시하고 있습니다. 이 섹션은 사실 관계를 요약한 것일 뿐 법률적 조언이 아닙니다. 실제 사용자가 있는 사이트를 운영한다면 해당 관할 구역의 변호사와 상담하십시오.

사람들이 흔히 간과하는 점이 하나 있습니다. 접근 로그(access log) 또한 개인 데이터라는 사실입니다. GoAccess는 페이지에 스크립트를 추가하지 않지만 여전히 IP 주소를 처리하므로, 로그 기반 분석 도구라고 해서 자동으로 규제 대상에서 제외되는 것은 아닙니다. 서비스를 자신의 서버로 옮기는 것은 노출의 위험을 제거하는 것이 아니라 위치를 옮기는 것에 불과합니다. 직접 호스팅하는 SearXNG 인스턴스가 실제로 숨겨주는 것이 검색 엔진 단계에서 멈추고, 검색 쿼리 자체는 여전히 자신의 로그에 남는 것과 같은 이유입니다.

광고 차단기와 트래픽 수치가 감소하는 이유

필터 목록은 호스트 이름과 URL 패턴을 기준으로 차단 여부를 결정합니다. 호스팅형 분석 제품은 모든 사용자가 동일하고 잘 알려진 호스트 이름에서 스크립트를 불러오기 때문에 차단하기가 쉽습니다. 수집기를 자체 서브도메인으로 옮기면 요청에서 해당 호스트 이름이 제거되며, 선택한 경로에서 스크립트를 제공하면 잘 알려진 파일 이름도 제거됩니다. 이 두 가지 조치 모두 필터 목록이 차단 기준으로 삼는 대상을 변경합니다.

이 글은 특정 차단율을 보장하지 않으며, 이를 측정하지도 않았습니다. 특정 설정을 차단하는 방문자의 비율은 서비스의 대상 독자에 따라 달라지며, 개발자 대상 서비스는 일반 서비스보다 차단율이 훨씬 높습니다. 대신 직접 차단율의 격차를 측정하십시오. 동일한 일주일 동안 GoAccess를 사용하여 액세스 로그에서 HTML 페이지 요청 수를 집계하고, 이를 스크립트 기반 도구가 보고하는 페이지 뷰 수와 비교하십시오. 그 차이는 차단된 방문 수와 캐시에서 제공된 페이지 수의 합입니다.

호스팅형 제품에서 전환한 당일에는 총계가 변동될 수 있으며, 이러한 변동의 일부는 광고 차단과는 무관할 수 있습니다. 제품마다 페이지 뷰를 정의하는 기준이 다르며, 단일 페이지 애플리케이션(SPA) 내의 경로 변경을 페이지 뷰로 간주할지 여부나 세션 종료 시점도 제품마다 차이가 있습니다. 트래픽이 감소했다고 결론 내리기 전에 여러 주에 걸친 추세를 비교하십시오.

사이트별 적합한 도구 선택

• 월간 페이지 뷰가 약 50,000회 이하인 개인 사이트나 블로그: 1 GB VPS에서 GoatCounter 또는 Medama를 사용하고, 파일 복사 방식으로 백업을 수행합니다.
• 스크립트를 추가할 수 없거나 방문자가 광고 차단기를 많이 사용하는 사이트: 기존 로그를 대상으로 GoAccess를 일정에 맞춰 실행합니다.
• 다른 사람이 대시보드를 확인해야 하는 소규모 비즈니스 사이트: Postgres 컨테이너를 포함한 Umami를 사용합니다.
• 목표 설정과 퍼널 분석이 필요하며 2 GB 이상의 RAM을 갖춘 서버: Plausible Community Edition을 사용하거나, 더 최신 대시보드를 원하고 초기 단계의 프로젝트임을 감수한다면 Rybbit을 사용합니다.
• 다수의 사이트와 사용자 계정이 필요하거나, 자체 보존 정책에 따라 원시 데이터를 보관해야 하는 경우: 위에 게시된 가이드에 따라 적절한 규모로 Matomo를 구성합니다.

실제 질문에 답을 줄 수 있는 가장 작은 도구부터 시작하십시오. 나중에 GoatCounter에서 Plausible로 이전하면 서브도메인과 일부 기록을 잃게 됩니다. Matomo에서 다른 도구로 이전하는 것은 매우 번거로운 마이그레이션 작업을 수반합니다. 같은 서버에 무엇을 더 설치할지 고민 중이라면 더 넓은 범위의 셀프 호스팅 정리에서 함께 설치하기 적합한 도구를 확인하십시오. 만약 방문자 수 집계가 아니라 애플리케이션의 요청 수준 추적(request level tracing)이 필요하다면, 셀프 호스팅 관측 가능성 서비스가 해당 작업에 적합한 도구입니다.

FAQ

자체 호스팅 분석 도구를 사용하면 쿠키 배너가 필요 없습니까?

아니요, 두 문제는 별개입니다. ePrivacy에 따른 동의 규정은 방문자의 기기에 데이터를 저장하거나 읽는 행위를 다룹니다. 따라서 쿠키를 설정하지 않고 로컬 스토리지에 아무것도 기록하지 않는 도구는 해당 요구 사항에서 제외될 수 있습니다. GDPR은 별도의 규정으로 개인정보 처리를 다루며, IP 주소는 개인정보에 해당합니다. 따라서 쿠키를 사용하지 않더라도 적법한 처리 근거와 보관 기간 제한이 여전히 필요합니다. 자체 호스팅은 데이터를 본인의 서버로 옮겨오며, 이에 대한 책임 주체가 본인이 됨을 의미합니다. 관할 규제 기관의 지침을 확인하고 본인의 사례에 대해 법률 전문가에게 문의하십시오.

자체 호스팅 분석 도구를 VPS에서 운영하려면 RAM이 얼마나 필요합니까?

대시보드가 아닌 데이터 저장소가 결정합니다. GoatCounter와 Medama는 하나의 파일 위에서 하나의 프로세스로 실행되며, Medama 문서에 따르면 소규모 사이트는 256 MB 환경에서도 운영 가능합니다. Umami는 Node 애플리케이션 옆에 Postgres 컨테이너를 추가합니다. Plausible Community Edition과 Rybbit은 모두 ClickHouse를 실행하며, 두 프로젝트 모두 최소 2 GB를 요구합니다. Matomo의 자체 지침에 따르면 월 100,000 페이지뷰까지는 2개의 CPU 코어와 2 GB의 RAM을 권장합니다.

왜 자체 호스팅 분석 도구의 수치가 기존에 쓰던 도구보다 낮게 나옵니까?

두 가지 원인이 있으며, 둘 다 실재하는 현상입니다. 필터 목록이 일부 수집 요청을 차단하므로 스크립트 기반 도구는 해당 방문을 모두 놓치게 됩니다. 또한 제품마다 페이지뷰를 집계하는 기준과 세션 종료 시점이 다르므로 계산 방식에도 차이가 있습니다. 액세스 로그의 1주일치 HTML 페이지 요청 수와 같은 기간의 스크립트 기반 페이지뷰를 비교해 보십시오. 그 차이는 차단된 방문과 브라우저 캐시된 페이지의 합이며, 타인의 공개된 비율을 빌려오는 것이 아니라 본인의 사이트에서 직접 측정한 값입니다.

ARM 기반 VPS에서 Plausible이나 Rybbit을 실행할 수 있습니까?

두 도구 모두 ClickHouse를 실행하며, ClickHouse는 x86 환경에서는 SSE 4.2, ARM 환경에서는 NEON을 필요로 합니다. Plausible의 요구 사항은 이를 명시하고 있으며, Rybbit 문서에는 ARM 시스템이 ARMv8.2-A 이상이어야 한다고 기재되어 있습니다. 최신 ARM 서버 코어는 이 기준을 충족하지만 구형 코어는 그렇지 못합니다. 이 경우 애플리케이션 로그가 아닌 ClickHouse가 명령어 집합 오류로 인해 시작을 거부하는 방식으로 실패가 나타납니다. 소형 ARM 장비에서는 ClickHouse를 사용하지 않는 단일 파일 도구를 선택하여 이 문제를 피할 수 있습니다.

추적 스크립트를 사용하는 대신 서버 로그를 파싱해야 합니까?

스크립트를 추가할 수 없거나, 방문자의 차단이 심하거나, 크롤러를 포함한 수치를 원할 때 로그 파싱을 사용하십시오. GoAccess는 서버가 이미 기록 중인 로그를 읽으므로 페이지 무게나 데이터베이스 부하를 추가하지 않습니다. 다만 브라우저 내부에서 일어나는 모든 정보는 포기해야 하며, CDN이나 브라우저 캐시에서 제공된 페이지는 서버에 요청이 도달하지 않으므로 집계에서 누락됩니다. 많은 사이트가 두 방식을 모두 운영하며 각각을 서로 다른 측정 지표로 활용합니다.