자주 묻는 질문

셀프호스터들이 자신의 서버를 도구에 맡기기 전에 가장 많이 묻는 질문들입니다.

내 데이터를 업로드하나요?

아니요. Hostveil은 전적으로 로컬에서 동작합니다 — SaaS도, 데이터베이스도, 계정도 없습니다. 선택적인 AI 설명조차 기본값은 사용자 자신의 컴퓨터에 있는 모델이며, 사람이 읽을 수 있는 필드만(원본 비밀값이나 경로는 절대 아님) 전달됩니다. AI 설명을 참고하세요.

수정이 서버를 망가뜨리지는 않나요?

적용되기 전에 정확한 변경 내용을 볼 수 있고, 원본 파일은 먼저 체크포인트로 백업되며, hostveil rollback이 이를 바이트 단위 그대로 복원합니다. 안전하게 자동화할 수 없는 수정은 Manual로 분류되어 설명만 되고 절대 적용되지 않습니다. 수정 및 롤백을 참고하세요.

Hostveil 자체는 어떻게 테스트하나요?

Hostveil은 root로 실행되며 다른 사람이 의존하는 서버의 설정 파일을 고칩니다. 그만큼 검증이 필요한 일이라, 이 저장소에는 제품 코드보다 테스트 코드가 더 많습니다. 목표로 잡은 비율이 아니라, 운영체제를 정직하게 감사하는 데 드는 비용입니다. 매일 밤 퍼즈 타깃 5개를 각각 5분씩, 설정 파일을 다시 쓰는 YAML과 JSON5 편집기에 돌립니다. 모든 풀 리퀘스트가 시드된 Debian 컨테이너 안에서 실제 바이너리를 스캔 → 수정 → 히스토리 → 롤백 → 재스캔까지 끝에서 끝까지 굴립니다. 적용과 롤백 기계가 진짜 파일시스템을 만나는 유일한 곳입니다.

이 사이트도 같은 방식으로 프로그램에 묶여 있습니다. 공개된 페이지가 코드와 어긋나면 빌드를 깨뜨리는 것만이 일인 패키지가, 모든 영역 표와 스크린샷 속 모든 발견 항목 ID, 측정 결과의 모든 수치, 점검 항목의 개수까지 대조합니다. 이 사이트에 낡은 숫자가 남아 있으면 독자가 알아채야 할 일이 아니라 빌드가 깨집니다.

읽는 것보다 직접 보는 편이 낫다면, 저장소에 취약하게 시드된 Vagrant VM이 들어 있습니다. 하드닝 도구가 서버를 고치고, 되돌리고, 다시 스캔하는 모습을 실제 서버에 쓰기 전에 지켜볼 수 있습니다. 기여하기를 참고하세요.

수정에 절충안이 있다면요?

그런 경우는 Auto-fix가 아니라 Review 수정입니다. Hostveil은 독립적인 대안들을 제시하고 --action으로 직접 선택하게 합니다. fix --all은 명백히 안전한 Auto-fix 발견 항목만 건드리고 나머지는 모두 사용자에게 맡깁니다. --review를 붙이면 Review 항목도 각각의 첫 번째 대안 — 해당 항목의 수정 안내가 설명하는 그 대안 — 으로 적용합니다.

Docker나 Trivy가 필요한가요?

아니요. SSH, 방화벽, 자동 업데이트 점검은 추가 도구 없이 네이티브로 실행됩니다. Docker/Compose 점검은 Docker가, 이미지 CVE 스캔은 Trivy가 필요합니다 — 각각 있으면 사용되고 없으면 깔끔하게 건너뛰어지며, 건너뛴 영역이 결과를 부풀리지 않도록 점수가 재정규화됩니다.

왜 sudo를 요구하나요?

일부 점검은 sshd_config 같은 root 소유 파일을 읽어야 하고, 수정을 적용하려면 보호된 경로에 써야 합니다. 그래서 hostveil은 sudo로 자동으로 권한을 상승시킵니다 — 표시되는 프롬프트는 sudo 자체의 것으로 sudo hostveil을 실행할 때와 동일하며, 인증하면 같은 터미널에서 계속 진행됩니다. version과 help는 절대 프롬프트를 띄우지 않습니다. 권한 없이(스크립트·CI에서) 실행하려면 HOSTVEIL_NO_SUDO=1을 설정하세요. 그러면 root 소유 영역은 명확한 메시지와 함께 건너뛰어집니다.

웹 대시보드가 네트워크에 노출되나요?

아니요. hostveil serve는 127.0.0.1:8787(루프백 전용)에 바인딩되고, 모든 경로가 일회용 접근 토큰을 요구합니다. 대시보드는 localhost로 향하지 않은 요청을 거부하므로 --addr로도 네트워크에 노출할 수 없습니다. 원격 접근이 필요하면 SSH 포트 포워딩을 쓰세요. 인터페이스를 참고하세요.

0–100 점수는 무엇을 의미하나요?

도메인마다 별도의 축으로 채점한 뒤 가중치로 합칩니다. 수정되지 않은 항목은 각자 그 축에 남아 있는 점수의 일부를 가져가는데, 지금 당장 닿는 HIGH 항목은 절반을, 아래 두 단계는 그보다 적게 가져갑니다. 업스트림 패치가 없는 취약점도 조치 가능한 항목과 똑같이 가져가며, 아직 고칠 방법이 없다고 위험이 줄어들지는 않습니다. 몫이 더해지는 게 아니라 곱해지므로 항목 두 개만으로 축이 바닥나지 않습니다. 지적할 것이 없는 호스트는 속 빈 100점이 아니라 Clean으로 표시되며, 수정되지 않은 발견 항목 중 HIGH가 하나라도 있으면 scan은 0이 아닌 값으로 종료됩니다. 전체 모형은 점수 산정을 참고하세요.

Lynis나 CIS 벤치마크와는 무엇이 다른가요?

그쪽은 감사합니다. Hostveil은 감사한 다음 고치겠다고 제안합니다. 미리보기와 백업과 명령 한 줄짜리 롤백을 함께 걸고요. 서버를 그냥 잘 돌리고 싶은 사람에게는 그 차이가 전부입니다. Jellyfin이나 OpenClaw 같은 셀프호스팅 AI 에이전트를 돌리는 사람에게 “SSH 설정이 약합니다”라고 알려 주는 보고서는 문제를 옮겨 놓았을 뿐 풀지 않았습니다.

Lynis는 Hostveil보다 넓고 깊으며 앞으로도 그럴 것입니다. Hostveil이 다루지 않는 영역까지 수백 개의 검사를 돌리고, 직접 읽을 철저한 감사 결과가 필요하다면 그쪽이 더 나은 도구입니다. CIS 벤치마크는 프로그램이 아니라 기준입니다. 지켜야 할 문서이고, 보통은 그 일을 담당할 사람이 있는 조직에서 씁니다.

흥미로운 답은 따로 있습니다. 이건 믿어 달라고 부탁하는 주장이 아닙니다. Hostveil 자신의 수정으로 Hostveil 자신의 점수가 오르는 것은 아무것도 증명하지 않습니다. 그래서 저장소에는 일부러 취약하게 만든 호스트를 Lynis, Docker의 CIS 벤치마크, 호스트 밖에서 쏘는 TCP 스캔, 커널 자신의 소켓 목록으로 재는 하네스가 들어 있습니다. 수정 전, 수정 후, 서비스 재시작 후, Review 수정까지 받아들인 후, 그리고 전부 롤백한 후까지요. 모든 수치는 JSON으로 커밋되고 페이지의 모든 숫자는 거기에 고정돼 있습니다. 개선되지 않은 것까지 포함한 결과를 전부 공개합니다.

어떤 플랫폼을 지원하나요?

Hostveil은 리눅스 호스트를 감사합니다. 사전 빌드 바이너리는 Linux와 macOS의 amd64·arm64를 대상으로 하고 macOS 빌드도 실행되지만, 그 안의 탐지 규칙은 전부 리눅스에 관한 것입니다. Mac에서는 열두 도메인 중 열 개가 N/A이고, 두 개(SSH와 파일 권한)가 실행되며, 점수는 전체 가중치의 5분의 1에 대한 평균입니다. 자세한 것은 macOS에서 실행하기에 있습니다.

직접 점검 항목을 추가할 수 있나요?

다시 컴파일하지 않고는 안 됩니다. 플러그인 시스템도, 룰 파일도, 설정 파일도 없습니다. Hostveil은 정적 바이너리 하나이고 점검 항목은 Go 코드입니다. 이건 빠진 기능이 아니라 의도한 선택입니다. 점수가 의미를 가지려면 축 가중치의 합이 100이어야 하고, 모든 발견 항목은 누군가 따져 본 조치를 달고 있어야 하며, 서명된 단일 바이너리가 배포의 전부입니다. 룰 형식은 이 세 가지를 아무도 서명하지 않는 파일 뒤로 밀어 넣게 됩니다.

Go를 건드리지 않고 조정할 수 있는 것은 환경 변수와 플래그로 하는 모양새와 동작이며, 그중 어느 것도 임계값이나 심각도나 축 가중치를 바꾸지 않습니다. 알아 둘 예외가 하나 있습니다: HOSTVEIL_NO_SUDO=1은 어떤 도메인이 아예 실행될 수 있는지를 바꿉니다.

무언가를 추가하고 싶다면 규모가 아주 다릅니다. 기존 도메인에 규칙을 하나 더하는 건 작은 일입니다. 함수 하나와 테스트 하나면 됩니다. 기존 발견 항목에 수정을 더하는 것도 작습니다. 하지만 도메인을 더하는 건 진짜 변경입니다: 패키지 하나, 도메인 표의 행 하나, 등록, 합계를 100으로 유지하기 위해 다른 도메인에서 떼어 온 가중치, 양 언어 점검 항목 표의 행들, 그리고 각 단계를 마칠 때까지 실패하는 테스트 열한 개쯤. 기여하기에서 따라갑니다.