What I Self-Host | Aspirational Self Hosting Guide
무엇을 셀프 호스팅하고 무엇은 맡기지 않는가
저자는 Jellyfin을 시작으로 28개 서비스를 집의 미니 PC에서 운영하며 선택 기준과 구성 방식을 공개합니다. 외부 공개를 VPN 서버로 제한하고 단순한 설치와 낮은 자원 사용량을 선호합니다. 셀프 호스팅의 편의뿐 아니라 모니터링과 장애 대응 같은 운영 조건도 함께 드러납니다.
- 주제
에디터 노트
이 구성에서 가장 설득력 있는 기준은 서비스 수보다 운영 부담을 먼저 따진다는 점입니다. 단일 바이너리와 SQLite를 선호하고, 실제로 Firefly III의 복잡한 컨테이너 구성을 Actual Budget으로 바꾼 사례가 기준과 선택을 연결합니다. 카메라 해상도와 미디어 품질을 조절해 16GB 메모리에서 28개 서비스를 운용한다는 결과도 구체적입니다. 반면 Uptime Kuma처럼 집 안에서만 도는 모니터링은 서버 자체가 멈췄을 때 알려주지 못합니다. 댓글은 외부 데드맨 스위치, 다른 지역의 VPS, 친구와 나누는 백업과 모니터링을 대안으로 제시합니다. 각 방식의 비용과 운영 부담은 서로 다릅니다. 글은 공용 인터넷에 서비스를 직접 공개하지 않는 원칙을 밝혔지만 VPN 연결과 장애 대응을 함께 맡을 별도 체계는 설명하지 않습니다. Tailscale이나 Headscale을 쓰는 댓글과 WireGuard로 충분하다는 경험담도 보여주듯, 접근 편의와 특정 도구에 대한 의존 사이의 선택은 서비스 목록만으로 정해지지 않습니다.
AI 요약
저자는 인도에서 저렴한 스트리밍 서비스를 쓰다가 서구권 가격과 추천 콘텐츠 중심의 사용 경험에 지쳐 Jellyfin으로 옮겼습니다. 이후 클라우드 서비스 의존을 줄이면서 직접 운영하는 서비스를 늘렸습니다. 새 기능과 약관 변경을 서비스 제공자가 정하는 대신, 직접 업데이트 시점을 고르는 점도 셀프 호스팅의 장점으로 꼽습니다.
운영 원칙과 하드웨어
라우터에서 운영하는 VPN 서버를 제외하면 서비스를 공용 인터넷에 직접 공개하지 않습니다. ISP가 IPv4에 CGNAT를 적용해 외부에서 집 네트워크에 직접 연결할 수 없고, VPN은 IPv6로만 공개합니다. 그 결과 IPv6를 지원하지 않는 공용 Wi-Fi에서는 VPN 연결이 거의 되지 않는 단점이 있습니다.
복잡한 서비스나 의존성이 많은 경우에는 컨테이너를 쓰지만, 가능하면 단일 바이너리처럼 설치가 단순한 서비스를 고릅니다. Docker 대신 Podman을 사용하고 systemd로 서비스를 관리합니다. 컨테이너 안에서 명령을 실행하거나 별도 네트워크와 포트 매핑을 다루는 부담을 피하고 싶기 때문입니다.
서버는 Intel N100 프로세서, 메모리 16GB, SSD 512GB를 갖춘 Beelink S12 Pro 미니 PC입니다. 구입 당시 가격은 180유로였고, 글을 쓴 시점에는 같은 상품이 Amazon에서 359유로였습니다. 미디어 저장용으로 6TB 하드 드라이브도 연결했습니다.
서비스 구성과 선택 기준
28개 서비스 가운데 17개는 네이티브로, 11개는 Podman으로 운영하며 모두 systemd로 관리합니다. 금융 관리에는 Actual Budget을 쓰되 거래 내역은 매달 OFX나 CSV 파일로 직접 가져옵니다. 사진은 Immich에 저장하고 Restic과 Backrest로 백업합니다. Jellyfin은 영화와 TV 프로그램, 홈 비디오에 쓰며 자동 재생과 추천 콘텐츠 없이 원하는 영상을 찾는 데 초점을 둡니다. Frigate는 IP 카메라 8대의 영상을 처리하고 Home Assistant와 연동합니다. 네트워크 혼잡과 CPU, 메모리, 저장 공간 사용을 줄이려고 카메라 해상도를 낮추고, 객체 감지에는 저해상도 RTSP 서브스트림을 씁니다.
그 밖에 비밀번호 관리에는 Vaultwarden, 작업 관리에는 SQLite를 기본으로 쓰는 Vikunja를 사용합니다. Trello의 며칠간 이어진 장애가 Vikunja를 찾은 계기였습니다. 이메일은 발신과 수신이 멈추는 상황을 감당하기 어렵다고 보고 직접 운영하지 않으며, 유료 서비스로 옮길 계획입니다. Firefly III는 여러 컨테이너를 설정해야 해 Actual Budget으로 바꿨고, OwnTracks는 Android 위치 보고가 안정적이지 않아 포기했습니다. Sonarr, Lidarr, Radarr 같은 *arr Stack도 자원 사용과 잦은 고장 가능성 때문에 선택하지 않았습니다.
미디어 품질을 720p 위주로 고르는 등 자원 사용을 조절한 결과, 서버는 메모리 약 7.5GB를 사용하고 CPU 사용률은 30~40% 사이를 오갑니다. 저자는 AI 추론을 제외하면 이 하드웨어에서 나머지 서비스가 별다른 문제 없이 동작했다고 설명합니다.
Lobsters 반응
- @markerz — Uptime Kuma를 셀프 호스팅하는 이유를 잘 모르겠습니다. 셀프 호스팅을 좋아하지만 모니터링과 가동 시간 확인 도구는 직접 운영하지 않습니다. 실수로든 의도적으로든 서비스를 자주 내립니다. 장비의 디스크 공간이나 전원이 끊기면 어떻게 되나요? 다른 서비스도 모니터링하나요? 저는 클라우드 Grafana와 UptimeRobot을 쓰지만 UptimeRobot은 놀랄 만큼 불안정합니다.
- @technomancy — 셀프 호스팅을 하는 사람들이 서로를 찾아 백업과 모니터링을 상대방의 인프라에서 맡아 주면 기업 서비스에 의존하지 않아도 되겠다는 생각을 오래전부터 했습니다. 저는 모니터링을 신경 쓸 만큼 제 일을 정리하지 못해 실행하지는 않았지만, 실행할 셀프 호스터를 위한 아이디어입니다.
- @bjeanes — 백업은 친구와 그렇게 하고 있습니다. 둘 다 여유 공간이 테라바이트 단위인 NAS를 갖고 있어, 서로를 위한 사용자와 공유 폴더를 하나씩 만들고 전용 ZeroTier 네트워크로 연결했습니다. 요즘 저는 Tailscale을 쓰지만 한 노드를 둘 이상의 tsnet에 연결하지 못합니다. ZeroTier는 됩니다.
- @avh-on1 — 스페인에서 저전력 태양광 웹사이트를 운영하는 Low-Tech Magazine 사례를 읽어볼 만합니다. 발코니 창가에 설치했고 작은 배터리로 밤 대부분을 버팁니다. 특히 겨울에는 배터리가 바닥나 몇 시간 동안 사이트에 접속할 수 없습니다. 사이트 CSS에는 현재 배터리 잔량이 표시됩니다. 배터리와 패널을 키우면 가동 시간은 늘지만 환경과 비용 부담도 커지므로 운영자는 다운타임을 받아들였습니다.
- @tuxes — Uptime Kuma 같은 프로버를 직접 운영하고 healthchecks.io 같은 외부 데드맨 스위치에 상태를 보내는 방식이 흔합니다. 모니터링 도구가 멈추면 healthchecks.io가 알려줍니다.
- @noirscape — 셀프 호스팅 Uptime Kuma는 바로 알아차리지 못한 서비스 장애를 알려주는 데 유용합니다. 저는 공개 변경 내역이 없는 API를 호출하는 시간별 스크립트를 실행합니다. 성공해도 출력이 따로 남지 않지만 실패하면 조치가 필요합니다. curl POST를 보내도록 설정해 90분 동안 요청이 없으면 실패했거나 실행 시간이 길어진 것으로 간주하고 알림을 받습니다. 네트워크 드라이브가 사라져 서비스가 조용히 내려가는 경우에도 도메인으로 요청을 보내 상태를 확인하면 도움이 됩니다.
- @baetylboy — 제 셀프 호스팅 구성은 Tailscale에 많이 얽혀 있습니다. MagicDNS와 서비스 이름을 쓰고 어디서든 접근하기 쉬워 유지 관리가 편합니다. Tailscale에 의존하고 싶지 않은 사람들의 입장도 이해하지만 글에 언급조차 되지 않아 놀랐습니다.
- @e3bc54b2 — Headscale을 몇 년째 쓰고 있습니다. 대체로 순조롭습니다. 설정을 잘못 건드려 Cloudflare Tunnel 뒤의 Raspberry Pi에 Headscale 서버에서만 접근할 수 있게 된 적이 있지만 제 실수였습니다. 원인을 찾지 못했지만 처음부터 다시 설정해야 하니 더 파고들지는 않을 것 같습니다. 무료 Tailscale 기기 수 제한을 오래전에 넘겼을 텐데 Headscale은 계속 잘 동작합니다.
- @zie — Headscale에서 가장 귀찮은 점은 업그레이드할 때마다 설정 파일을 고쳐야 한다는 것입니다. 문서대로 따라가면 괜찮지만 설정 항목을 추가하거나 제거하거나 바꾸지 않아도 됐던 릴리스를 하나도 떠올릴 수 없습니다. 잘못된 설정을 남기면 무엇이 문제인지 알려준다는 점은 좋습니다. 그 외에는 오래 잘 쓰고 있습니다.
- @msangi — 최근 Tailscale에서 일반 WireGuard로 바꿨고 만족합니다. 여러 기기와 사용자, 계속 변하는 서비스를 관리한다면 Tailscale이 주는 편의가 유용합니다. 제 경우에는 서버 하나와 VPS 하나, 연결할 휴대폰 몇 대가 전부라 설정한 뒤 새 기기가 생길 때까지 손댈 일이 없습니다. Tailscale이 주는 NAT 통과 기능은 대체하기 어려웠지만 IPv6로 서버를 공개하고 VPS를 중계기로 쓰는 방식으로 해결했습니다. 대신 생각하고 설정할 부분이 늘었습니다. 연결은 거의 즉시 되고 전송 속도는 더 빨라졌습니다.
- @hackguy — 하드웨어 가격이 부담스럽다면 중고 제품도 고려해 보세요. 기업에서 퇴역시킨 장비 가운데 가정용으로 충분한 제품이 많습니다. 저는 최근 i5-9500T, 메모리 32GB, SSD 256GB를 갖춘 중고 Lenovo M720q를 배송비 포함 270유로에 샀습니다.
- @mxuribe — 동의합니다. 집에서 셀프 호스팅하는 컴퓨터 몇 대는 리퍼 제품이나 기업에서 퇴역한 장비입니다. 배터리가 괜찮은 구형 노트북을 쓰면 정전 때 전원 백업 역할도 한다고 들었습니다.
- @msangi — 노트북 배터리를 늘 전원에 꽂아 두는 방식에는 논란이 있습니다. 배터리가 부풀어 오를 위험이 있습니다.
- @manifold — 셀프 호스팅을 막 시작할 때 누군가 NixOS 서버를 쓰면 모든 일이 훨씬 쉬워진다고 알려줬으면 좋았겠습니다.
- @xjix — NixOS 덕분에 셀프 호스팅을 지속할 수 있게 됐습니다.
원문: Vice Console / 번역·요약: Trawling