셀프 호스팅 웹 분석 도구 추천 및 VPS 서버 사양 가이드

VPS에서 운영할 만한 셀프 호스팅 웹 분석 도구는 무엇입니까?

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

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

스크립트 태그와 서버 로그: 각각의 가시성 범위

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

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

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

봇 트래픽은 격차의 나머지 절반을 차지합니다. 로그 기반 집계에는 필터링하지 않는 한 크롤러가 포함되며, 일반적인 사이트에서 크롤러가 차지하는 비중은 결론을 바꿀 만큼 큽니다. GoAccess와 Matomo의 로그 가져오기 기능은 모두 알려진 봇을 필터링합니다. 하지만 사용자 에이전트를 속이는 크롤러까지는 걸러낼 수 없습니다. 이것이 로그 기반 집계를 서버 수준에서 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(automatic certificate management environment)를 활용하며, 다른 서비스가 없는 서버에서 유용합니다. 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(전송 계층 보안) 설정을 먼저 완료한 후 로그인하십시오.

Umami: Postgres와 익숙한 대시보드

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

이 명령은 PostgreSQL 컨테이너와 함께 3000번 포트에서 애플리케이션을 시작합니다. 문서에 따르면 최소 요구 사항은 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

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

Plausible의 자체 요구 사항에 따르면 ClickHouse와 애플리케이션이 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 status의 설정보다 우선하는 자체 방화벽 규칙을 작성하므로, -p 3000:3000로 공개된 컨테이너는 포트가 거부된 상태여도 인터넷에서 접근할 수 있습니다. 다른 머신에서 curl http://SERVER_IP:3000로 테스트하면 대시보드가 나타날 것입니다. 반면 -p 127.0.0.1:3000:3000로 공개하면 동일한 테스트에서 Connection refused이 반환되며, 오직 프록시만 접근할 수 있게 됩니다.

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에서 온 것으로 기록되어 국가별 보고서가 비어 있게 되고, 순 방문자 수도 하나로 합쳐집니다. 각 프로젝트마다 신뢰하는 헤더와 필요한 설정이 다르므로, 임의로 판단하지 말고 해당 프록시의 문서를 한 번 확인하십시오. 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은 방문자 수 측정 도구가 동의 면제 대상이 될 수 있는 조건을 명시하고 있습니다. 이 섹션은 사실에 기반한 요약일 뿐 법률 자문이 아닙니다. 실제 사용자가 있는 사이트를 운영한다면 관할 지역의 변호사와 상담하십시오.

사람들이 간과하는 점이 하나 있습니다. 액세스 로그 또한 개인정보입니다. GoAccess는 페이지에 스크립트를 추가하지 않지만 여전히 IP 주소를 처리하므로, 로그 기반 분석 도구라고 해서 자동으로 규제 대상에서 제외되는 것은 아닙니다.

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

필터 목록은 호스트 이름과 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에서 다른 도구로 이전하는 것은 매우 번거로운 작업이 될 것입니다. 같은 서버에 무엇을 더 설치할지 고민 중이라면 더 넓은 범위의 셀프 호스팅 정리에서 함께 운영하기 적합한 도구를 확인할 수 있으며, 방문자 수 집계가 아니라 애플리케이션 수준의 요청 추적이 필요하다면 셀프 호스팅 관측성 서비스가 적합한 도구입니다.

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이나 브라우저 캐시에서 제공된 페이지는 서버에 요청이 도달하지 않으므로 집계에서 누락됩니다. 많은 사이트가 두 방식을 모두 운영하며 각각을 서로 다른 측정 지표로 활용합니다.