VPS용 가벼운 서버 모니터링 툴: Beszel vs Netdata vs Uptime Kuma vs Nezha (그리고 아무것도 필요 없을 때)

2026년 10월 15일 · Termalin Team vpslinuxcomparisontoolshomelab

VPS 한 대나 몇 대를 위한 가벼운 서버 모니터링 툴이라면, 솔직한 후보 목록은 짧고, 올바른 선택은 내가 던지는 질문에 달려 있습니다. 상자가 건강한지 알고 싶다면 Beszel을, 사용자가 사이트를 열 수 있는지 알고 싶다면 Uptime Kuma를 쓰세요. 여러 리전에 걸친 VPS 무리를 한 패널로 보려면 Nezha, 지금 이 순간 상자 하나를 보려면 Glances, 장애가 벌어지는 동안 1초 단위 세부를 보려면 Netdata입니다. 대부분은 이 중 하나로, 때로는 둘로 충분하고, 완전한 관측(observability) 스택이 필요한 경우는 드뭅니다.

밝혀 둡니다: 저희는 Termalin을 만듭니다. Termalin도 아래 선택지 중 하나입니다. 오픈소스 도구들은 2026년 10월 15일에 확인한 공개 문서를 바탕으로 설명하며, 그중 여러 개는 비교 항목에서 분명히 앞섭니다.

이 글은 각 도구가 무엇을 지켜보는지, ‘가볍다’가 실제로 치르는 비용이 무엇인지, 그리고 상위 검색 결과가 건너뛰는 부분들을 다룹니다. VPS 자체가 죽었을 때 누가 모니터를 지켜보는지, 알림이 소음이 되지 않게 하는 방법, 작은 대비용 스크립트, 그리고 열린 포트가 없는 상자를 모니터링하는 방법입니다.

짧은 답: 어떤 질문에 어떤 도구

Beszel — ‘내 상자들 괜찮나?’ 허브 하나에 서버마다 작은 에이전트 하나. 호스트 지표와 Docker 통계를 보고, Telegram 등으로 알림을 보냅니다. 가벼운 기본값입니다.
Netdata — ‘바로 그 1초에 무슨 일이 있었나?’ 1초 단위 지표와 프로세스별 깊은 세부. 여기서 데이터를 가장 많이 먹지만, 그게 핵심입니다.
Uptime Kuma — ‘바깥세상이 내 서비스에 닿을 수 있나?’ HTTP·TCP·ping·DNS 체크와 상태 페이지. CPU·메모리·디스크는 보지 않습니다.
Nezha — ‘여러 제공업체와 리전에 걸친 내 VPS 무리는 어떤가?’ 웹 터미널이 딸린 프로브형 패널로, 멀티 리전 구성에서 인기가 많습니다.
Glances — ‘지금 이 상자 하나는 뭘 하고 있나?’ htop이나 btop에 화면 정보를 더 얹은 듯한 실시간 뷰. 알림 도구는 아닙니다.
Termalin — ‘추가로 설치할 것 없이 내 서버를 지켜보고 알려 줘.’ 모니터링이 이미 쓰고 있는 SSH 액세스용 Connector에 얹혀 갑니다. 유료이고, 실제 한계도 있습니다(아래).

서버 모니터링에서 ‘가볍다’가 진짜 뜻하는 것

‘가볍다’는 보통 에이전트의 메모리로 인용되지만, 그건 틀린 숫자입니다. 전체를 세어야 합니다:

상자마다의 에이전트 — 보통 컴파일된 단일 바이너리 하나로, 설계상 작습니다.
허브 또는 대시보드 — 무게는 여기에 있습니다. 웹 앱, 흔히 데이터베이스까지, 계속 떠 있는 어딘가에서 돌아갑니다.
열린 포트 — 수신 대기하는 포트 하나하나가 이제 내가 떠안은 공격 표면입니다.
패치해야 할 컨테이너와 서비스 — 영원히 업데이트를 챙겨야 할 것이 하나 더 늘어납니다.

그 기준으로 보면 Beszel(에이전트 하나 + 허브 컨테이너 하나)과 Uptime Kuma(컨테이너 하나)는 진짜로 가볍습니다. Netdata의 1초 단위 수집은 이 그룹에서 CPU와 저장 공간 모두 가장 많이 먹는데, 그 해상도를 얻는 대가입니다. 그리고 고전적인 ‘큰 스택’ — Prometheus에 node_exporter, Grafana, Alertmanager까지 — 은 배포하고 보안을 챙기고 패치해야 할 움직이는 부품이 넷입니다. 훌륭하지만 가볍지는 않고, 서버 1~20대에는 보통 필요 이상입니다.

후보들

Beszel

허브(PocketBase 기반) 하나에 서버마다 작은 Go 에이전트 하나. 에이전트는 두 가지로 돌 수 있습니다. 허브가 포트 45876으로 SSH를 통해 에이전트에 연결하거나, 에이전트가 토큰을 들고 WebSocket으로 허브에 바깥쪽으로 다이얼합니다. 두 번째 방식은 인바운드 포트가 필요 없고 NAT 뒤에서도 됩니다. 호스트 지표와 Docker 컨테이너 통계를 읽고, CPU·메모리·디스크·대역폭·온도·업/다운 상태에 대해 Telegram과 ntfy를 포함한 25개 이상의 채널로 알림을 보냅니다. MIT 라이선스이며, 이 글을 쓰는 시점에 문서는 v0.21입니다. 단순히 ‘내 상자들 건강한가’라면 이게 넘어야 할 기준입니다.

Netdata

조밀한 실시간 대시보드와, 프로세스별·서비스별로 자동 수집되는 많은 세부가 함께하는 1초 단위 지표. 에이전트는 무료이고 내 호스트에서 개수 제한 없이 돌며 자체 대시보드를 로컬에서 제공합니다. 에이전트들을 묶고 알림을 라우팅하는 Netdata Cloud는 Community 등급에서 연결 노드 5개까지 무료이고, 그 이상은 Homelab 연 $90(무제한, 공정 사용) 또는 Business 노드당 월 $4.50(연간 결제)입니다. 급등을 디버깅하는데 1분 평균이 너무 뭉툭할 때 꺼내 드세요.

Uptime Kuma

셀프 호스팅 업타임 모니터. HTTP(s)·TCP·키워드·ping·DNS·push·Docker 컨테이너 체크, 90개 이상의 알림 서비스, 공개 상태 페이지를 제공합니다. GitHub 스타 약 92k, MIT. 분명히 해 둘 한 가지. Uptime Kuma는 호스트 CPU·RAM·디스크를 수집하지 않습니다. 서비스가 바깥에서 응답하는지를 지켜봅니다. 그래서 호스트 지표 도구의 대체가 아니라 자연스러운 짝이고, ‘셀프 호스팅 Uptime Kuma 대체’에 대한 흔한 답은 사실 ‘Kuma에 Beszel을 짝지어라’입니다.

Nezha

대시보드 하나에, 시스템 상태를 보고하고 HTTP/TCP/ping 체크와 인증서 만료 체크를 돌리고 알림을 올리고 예약 작업을 실행하며 호스트마다 웹 터미널을 주는 에이전트. 에이전트가 대시보드로 바깥쪽으로 다이얼합니다. 중국어권과 한국어권 커뮤니티에서는 사실상 표준인 VPS ‘프로브’ 패널이고, 여러 제공업체와 리전에 흩어진 작은 VPS가 많고 그 전부를 한 페이지로 보고 싶을 때 빛을 발합니다.

Glances (그리고 htop/btop)

Glances는 실시간 단일 상자 뷰입니다. CPU·메모리·디스크·네트워크·프로세스 등을 SSH로, 또는 선택적인 로컬 웹 페이지로 한 화면에 보여 줍니다. htop이나 btop처럼 ‘이 상자가 지금 뭘 하는가’에 답할 뿐, 그 이상은 아닙니다. 기록도 없고 제대로 된 알림도 없습니다. 직접 손으로 디버깅할 때 도구함에 넣어 두되, 문제가 생겼다고 불러 주리라 기대하지는 마세요.

비교 표

도구	무엇을 보는가	알림·채널	인바운드 포트 필요?	비용	가장 잘하는 것
Beszel	호스트 지표 + Docker 통계	CPU/메모리/디스크/대역폭/온도/상태; 25개 이상 채널(Telegram, ntfy)	WebSocket 모드는 불필요, SSH 모드는 필요(`45876`)	무료, MIT(셀프 호스팅)	가벼운 서버 무리 상태 점검
Netdata	호스트 지표, 1초 단위	내장 경보; 에이전트 또는 Cloud로 알림	로컬 대시보드는 `19999`; Cloud 연결은 아웃바운드	에이전트 무료; Cloud는 노드 5개 이하 무료, 이후 연 $90 또는 노드당 월 $4.50	고해상도 장애 분석
Uptime Kuma	업타임: HTTP/TCP/ping/DNS/push/컨테이너(호스트 지표 없음)	90개 이상 서비스; 상태 페이지	대상으로 바깥쪽 체크; 대시보드는 직접 호스팅	무료, MIT(셀프 호스팅)	외부 업타임 + 상태 페이지
Nezha	시스템 상태 + HTTP/TCP/ping + 인증서 만료	알림, 예약 작업; 웹 터미널	에이전트가 대시보드로 아웃바운드 다이얼	무료(셀프 호스팅)	멀티 리전 VPS 패널
Glances	상자 하나, 실시간	알림 도구 아님	로컬; 선택적 웹 뷰	무료(셀프 호스팅)	지금 이 순간 상자 하나
Termalin	Connector를 통한 호스트 지표(두 번째 에이전트 없음)	기본 임계값 알림; 이메일, iOS 푸시, Telegram, webhook	불필요 — Connector는 아웃바운드 전용	Pro 월 $10 또는 연간 시 월 $8; Team 사용자당 $15	설치할 것 없이 상태 점검 + 알림

VPS가 죽으면 누가 모니터를 지켜보나?

대부분의 비교가 건너뛰는 빈틈이 여기 있습니다. 허브나 대시보드가 자기가 지켜보는 바로 그 VPS에서 돌아간다면, 그 VPS와 함께 죽습니다 — 그리고 죽은 서버는 자기가 죽었다고 알려 주지 못합니다. ‘서버 오프라인’은 가장 받고 싶은 알림인데, 그것은 두 번째 관측 지점에서만 동작합니다.

이를 메우는 세 가지 방법:

다른 위치의 두 번째 저렴한 VPS에서 외부 체크를 돌립니다. 저희가 바로 이렇게 합니다. 주 상자들이 응답을 멈추는 때를 알아차리는 것만을 유일한 일로 하는 별도의 저가 VPS에서 Uptime Kuma를 돌립니다.
무료 외부 체커가 내 네트워크 밖에서 공개 엔드포인트를 ping 합니다.
호스팅 서비스는 ‘떠 있나?’ 로직이 내 것이 아닌 인프라에서 돌아가므로, 내 상자가 다운돼도 살아남습니다.

무엇을 고르든 규칙은 단순합니다. ‘오프라인’을 감지하는 쪽이 오프라인이 되는 그 머신 위에 살면 안 됩니다.

무시하도록 길들이지 않는 알림

한 시간에 열 번 호출하는 모니터는 일주일 안에 음소거되고, 그러면 없느니만 못합니다. 기본 상태의 도구들은 규칙을 쓰기 전까지 조용하거나, 튜닝하기 전까지 수다스럽거나 둘 중 하나인 편입니다. 어느 쪽이든 해야 할 일은 같습니다:

문제가 생길 때 한 번, 해소될 때 한 번 — 5분마다 울리는 리마인더가 아니라.
묶음 — 같은 1분 안의 여러 문제가 한 메시지로 도착하되, 정말로 위급한 것은 그래도 곧장 통과합니다.
같은 문제에 대한 같은 날 반복 없음 — 위급하고 지속되는 경우가 아니라면.
조용한 첫날 — 새로 지켜보기 시작한 상자가 이미 있던 모든 실패한 유닛과 만료된 인증서를 한꺼번에 쏟아붓지 않도록.
알림별·서버별 음소거 — 시끄러운 체크 하나 때문에 전부를 조용히 시킬 필요가 없도록.

그리고 의미 있는 임계값을 고르세요. 디스크 90%에 경고, 95%에 위급, 또는 하루 안에 가득 찰 것으로 예측될 때; inode 고갈; 메모리 부족으로 인한 강제 종료(OOM); 실패한 systemd 유닛; 만료 14일 전의 TLS 인증서(3일 전에는 위급); 그리고 ‘오프라인’은 몇 분이 지난 뒤에만 — 재부팅이 경보가 되지 않도록. 어떤 도구를 고르든, 이 튜닝이 모니터링의 진짜 일입니다 — 도구를 고르는 것보다 더요.

열 줄짜리 대비책: Telegram으로 보내는 디스크 공간 알림

무엇이든 배포하기 전에, 가장 흔한 단 하나의 VPS 장애 — 꽉 찬 디스크 — 는 cron, df, curl만으로 커버할 수 있습니다. 아직 대시보드를 원하지 않을 때 ‘disk space alert script linux’와 ‘server monitoring telegram alerts’에 대한 답입니다.

비밀 값은 스크립트 밖에 두세요. 환경 변수에서 읽습니다:

#!/usr/bin/env bash
# disk-alert.sh — warn via Telegram when a filesystem is too full.
set -euo pipefail

: "${TELEGRAM_BOT_TOKEN:?set TELEGRAM_BOT_TOKEN}"
: "${TELEGRAM_CHAT_ID:?set TELEGRAM_CHAT_ID}"
threshold="${DISK_THRESHOLD:-90}"

df -x tmpfs -x devtmpfs --output=pcent,target | tail -n +2 | while read -r pct mount; do
  used="${pct%\%}"
  [ "$used" -ge "$threshold" ] || continue
  curl -fsS --max-time 15 \
    --data-urlencode "chat_id=${TELEGRAM_CHAT_ID}" \
    --data-urlencode "text=$(hostname): ${mount} is ${used}% full" \
    "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" >/dev/null
done

실제 값은 root 전용 파일에 넣고, 스크립트나 crontab에는 절대 넣지 마세요:

# /etc/disk-alert.env  — chmod 600, owned by root
export TELEGRAM_BOT_TOKEN=123456789:replace-with-your-bot-token
export TELEGRAM_CHAT_ID=987654321
export DISK_THRESHOLD=90

그런 다음 cron으로 15분마다 돌리세요. 이 줄을 /etc/cron.d/disk-alert로 저장하세요(사용자 이름이 들어가는 이 형식은 /etc/cron.d/의 파일을 위한 것입니다):

*/15 * * * * root . /etc/disk-alert.env && /usr/local/bin/disk-alert.sh

디스크가 가득 찬 동안에는 15분마다 반복됩니다. 최후의 보루 알림이라면 그건 의도된 것이고, 너무 시끄러우면 대신 한 시간에 한 번 돌리세요.

@BotFather로 봇을 하나 만들고, 봇이 답장할 수 있도록 메시지를 한 번 보낸 뒤, getUpdates에서 chat_id를 한 번 읽어 오세요. 이게 전부입니다. 에이전트도, 포트도, 대시보드도 없습니다. 상자 몇 대를 넘어서면 확장되지 않지만, 대부분의 VPS를 쓰러뜨리는 그 장애는 잡아냅니다.

NAT·CGNAT 뒤, 또는 열린 포트 없이 모니터링하기

NAT나 CGNAT 뒤의 상자는 인바운드 연결을 받을 수 없으므로, 상자로 연결해서 동작하는 모니터는 모두 탈락입니다. 동작하는 것들은 하나의 모양을 공유합니다 — 상자가 바깥쪽으로 닿는 것입니다:

Beszel의 WebSocket 모드: 에이전트가 허브로 바깥쪽으로 다이얼하며, 인바운드 포트가 없습니다. (SSH 모드는 인바운드 45876이 필요하므로 여기서는 피하세요.)
Netdata: 에이전트와 Netdata Cloud의 연결은 아웃바운드입니다.
Uptime Kuma: push 모니터를 쓰세요 — 상자가 일정에 맞춰 Kuma URL을 호출하고, 호출이 멈추면 Kuma가 알립니다.
Termalin: Connector는 아웃바운드 전용이며 포트에서 수신 대기하지 않습니다.

일반적인 기법 — 그리고 왜 ‘바깥쪽으로 닿게 하라’가 사설 상자에 대한 유일하게 안전한 답인지 — 는 포트 포워딩 없이 NAT 뒤 SSH(영어)에 있고, 홈 랩 버전은 홈 NAS·서버에 SSH로 접속하기에 있습니다.

Termalin이 들어맞는 지점 — 그리고 아닌 지점

Termalin의 접근은 위 도구들과 다릅니다. 모니터링 에이전트를 아예 추가하지 않습니다. 서버에 이미 Termalin Connector — 키 없이 SSH에 접근할 때 쓰는 바로 그 아웃바운드·인바운드 포트 없는 에이전트 — 가 있다면, 그 서버는 이미 모니터링되고 있습니다. 두 번째 에이전트는 없습니다. Termalin은 Connector가 이미 쥐고 있는 연결 위로 1분에 한 번 읽기 전용 명령 몇 개(/proc, df, ps 등)를 실행합니다. 상자가 치르는 비용은 CPU 몇 밀리초와 1분에 약 1킬로바이트입니다.

읽는 것은 익숙한 상태 그림입니다. CPU(iowait과 steal 포함), 부하와 압력(PSI), 메모리와 스왑, 디스크 공간과 inode, 디스크·네트워크 I/O, 소켓과 열린 파일, 프로세스, 컨테이너, 실패한 서비스, 실패한 SSH 로그인, 대기 중인 보안 업데이트, 수신 대기 포트, 그리고 만료까지 남은 일수가 붙은 TLS 인증서입니다. 알림은 기본 임계값으로, 규칙을 쓸 필요 없이 동작하고, 조용하도록 만들어졌습니다. 들어올 때 한 번, 나갈 때 한 번, 묶음 처리, 같은 날 반복 없음, 차분한 첫날, 알림별 음소거입니다. 알림은 이메일, iOS 푸시, Telegram(봇 연결은 한 번 탭), 그리고 Slack과 Discord가 받는 webhook으로 가며, HMAC-SHA256으로 서명됩니다. 기록은 Pro에서 90일, Team에서 2년입니다.

AI 어시스턴트도 Termalin의 호스팅 MCP 엔드포인트(server_metrics와 alerts_list)로 같은 데이터를 읽을 수 있으므로, Claude나 ChatGPT에서 ‘내 서버들 어때?‘라고 묻기만 하면 수집된 데이터로부터 답을 받습니다. 웹 터미널의 출력에서 오류를 선택하고 선택 영역 설명을 고르세요. 어시스턴트가 짧고 쉬운 말로 진단을 적고, 버튼이 세션에 대신 입력해 주는 읽기 전용 점검 명령 몇 개로 마무리합니다. 전체 그림은 서버 모니터링 페이지에 있습니다.

이제 솔직한 한계입니다. 오픈소스 도구들이 그중 여러 항목에서 Termalin을 앞서기 때문입니다:

외부 업타임 체크 없음, 상태 페이지 없음. 이것은 호스트 지표와 알림 도구이지 업타임 모니터가 아닙니다 — Uptime Kuma가 여전히 보완합니다.
로그 수집 없음, 커스텀 지표 없음. Grafana/Prometheus 대체가 아닙니다.
대시보드는 지금은 웹 캐비닛에만 있고 데스크톱 앱에는 없습니다 — 다만 데스크톱 앱은 연결된 호스트의 CPU·메모리·디스크를 상태 표시줄과 워치 그리드(영어)에서 실시간으로 보여 줍니다.
종단 간 암호화 아님 — 이 숫자들은 서비스가 읽을 수 있는 형태로 저장됩니다. 차트를 그리고 알림을 올리려면 그 값을 읽어야 하기 때문입니다.
Free 요금제에서는 안 됩니다. Connector가 필요하고, Connector는 **Pro(월 $10, 연간 결제 시 월 $8 — 연 $96)**와 **Team(사용자당 $15)**에 포함됩니다. 14일 Pro 체험은 카드 등록이 필요 없습니다.

‘무료이고 셀프 호스팅’이 절대 조건이라면 Beszel이나 Uptime Kuma가 답이고, 그건 타당한 판단입니다. Termalin이 맞는 경우는 더 좁습니다. 이미 SSH 액세스에 Termalin을 쓰고 있고, 상태 차트와 합리적인 알림을 얻자고 별도의 모니터링 스택을 세워 돌봐 주고 싶지는 않을 때입니다.

상황별 추천

취미용 VPS 한 대. 상태 점검에는 Beszel, 두려운 게 꽉 찬 디스크뿐이라면 위의 cron 스크립트만으로도 됩니다. 공개 사이트를 운영한다면 나중에 Uptime Kuma를 더하세요.
여러 제공업체에 걸친 VPS 5~20대(Hetzner, Contabo, Hostinger, droplet 한두 개). 지표에는 Beszel, 업타임에는 Uptime Kuma를 쓰되 Kuma 인스턴스는 별도 상자에 두세요. 웹 터미널이 딸린 한 패널을 선호한다면 Nezha. 이미 SSH 때문에 Termalin을 돌리고 있다면, 그 모니터링을 켜고 추가 스택은 건너뛰세요.
CGNAT 뒤의 홈 랩. 아웃바운드 전용이면 무엇이든 됩니다. WebSocket 모드의 Beszel, Cloud로 가는 Netdata, 또는 Kuma push 모니터 — NAT 뒤 가이드(영어)를 보세요.
‘내 AI 어시스턴트가 ‘내 서버들 어때’에 답해 줬으면 좋겠다.’ 그게 Termalin이 맞는 경우입니다. 사람이 보는 것과 같은 데이터를, 에이전트가 MCP로 읽습니다.

자주 묻는 질문

Netdata는 무료인가요? 에이전트는 무료이고 내 호스트에서 개수 제한 없이 돌며 자체 로컬 대시보드를 갖습니다. Netdata Cloud의 Community 등급은 연결 노드 5개까지 무료이고, 그 이상은 Homelab 연 $90 또는 Business 노드당 월 $4.50(연간 결제)입니다.

Uptime Kuma는 CPU·메모리·디스크를 모니터링하나요? 아니요. Uptime Kuma는 서비스가 바깥에서 응답하는지를 체크합니다 — HTTP, TCP, ping, DNS, 컨테이너, push입니다. 호스트 CPU·RAM·디스크를 보려면 Beszel, Netdata, 또는 Termalin과 짝지으세요.

Beszel vs Netdata — 어느 쪽이 더 가볍나요? Beszel입니다. 상자마다 작은 에이전트 하나에 허브 하나입니다. Netdata는 1초 단위로 수집하며 이 그룹에서 자원을 가장 많이 먹습니다. 가벼워서가 아니라 해상도 때문에 고르는 것입니다.

Telegram 알림이 되는 가장 좋은 무료 VPS 모니터링은 무엇인가요? 호스트 상태에는 Beszel이 Telegram으로 보내고 셀프 호스팅이 무료입니다. 업타임에는 Uptime Kuma도 그렇습니다. 설치 없는 임시방편으로는, 위의 cron + curl 스크립트가 백그라운드에 아무것도 돌리지 않고 Telegram으로 곧장 보냅니다.

NAT 뒤이거나 열린 포트가 없는 VPS는 어떻게 모니터링하나요? 상자가 바깥쪽으로 닿는 도구를 쓰세요. WebSocket 모드의 Beszel, Cloud로 가는 Netdata 에이전트, Kuma push 모니터, 또는 Termalin Connector입니다. 어느 것도 인바운드 포트가 필요 없습니다. 포트 포워딩 없이 NAT 뒤 SSH(영어)를 보세요.

Termalin은 크로스 플랫폼 SSH 클라이언트입니다. Pro와 Team에서는 Connector가 있는 모든 서버가 차트와 기본 임계값 알림으로 모니터링되고, 상자에는 아무것도 추가로 설치되지 않습니다 — 서버 모니터링을 보거나 다운로드하세요.