홈 셀프호스팅의 경계와 복구: 공개 경로부터 재구축·백업까지
세 사례는 외부 접속을 여는 방식부터 다릅니다. CGNAT를 VPS와 WireGuard로 우회하는 구성, 서비스 공개를 VPN으로 제한하는 선택, 기본 거부 네트워크와 선언형 재구축을 결합한 구성을 비교하고, 각 글이 설명하는 장애 대응과 백업의 범위도 구분합니다.
CGNAT를 통과하는 공개 경로는 하나가 아니다
‘CGNAT 뒤에서 셀프 호스팅하기’는 통신사 CGNAT 때문에 집 공유기의 포트 포워딩만으로는 외부에서 접속할 수 없는 문제를 다룹니다. 저자는 프랑스 데이터센터의 저가 VPS를 중계 지점으로 두고, 집의 홈랩이 시작하는 양방향 WireGuard 터널로 트래픽을 전달합니다. VPS에서 SSH와 VPN 포트는 따로 두고 나머지 포트를 홈랩으로 넘기는 구성입니다. 이 방식은 집에 고정 공인 IP를 두지 않고도 공개 서비스를 운영하지만, 글에서 밝힌 대가는 RTT 39ms입니다.
반면 ‘무엇을 셀프 호스팅하고 무엇은 맡기지 않는가’의 저자는 VPN 서버를 제외한 서비스를 공용 인터넷에 직접 노출하지 않습니다. IPv4로는 집 네트워크에 직접 도달할 수 없고, VPN은 IPv6로만 공개합니다. 그 결과 공개 Wi-Fi가 IPv6를 제공하지 않는 경우에는 VPN 접속이 거의 되지 않는다는 사용상의 제약도 함께 설명합니다. 두 글 모두 CGNAT 환경을 전제로 하지만, 하나는 VPS를 경유해 서비스를 외부에 전달하고 다른 하나는 공개 범위를 VPN 접속으로 제한합니다.
접근 통제는 공개 여부뿐 아니라 서비스 사이에도 걸린다
‘Incus OS로 구축한 셀프호스팅 인프라’는 외부 공개와 내부 격리를 함께 설계합니다. 기본적으로 인스턴스 간을 포함한 네트워크 연결을 거부하고, 필요한 연결만 OpenTofu 코드에 선언합니다. 인터넷 트래픽은 물리 네트워크에 연결된 HAProxy VM을 거쳐 공개 Caddy로 전달하며, VPN 전용 사이트는 별도의 Caddy 인스턴스로 분리합니다. 관리 도구에는 공개 엔드포인트를 두지 않고, 일부 서비스는 공개하더라도 관리자 API를 VPN에서만 접근하도록 합니다. 이는 앞선 글의 ‘공개 경로를 VPN에 한정’하는 선택보다, 서비스 내부의 통신과 관리자 기능까지 경계를 나누는 구성입니다.
이 세 사례는 접근 경계가 서로 다른 운영 조건을 반영한다는 점도 보여줍니다. VPS 브리지 사례는 외부 트래픽을 홈랩으로 들이는 방법과 실제 클라이언트 IP를 유지하는 NAT 규칙을 설명합니다. VPN 중심 사례는 공용 인터넷에 서비스를 내놓지 않겠다는 운영자의 원칙과 그에 따른 접속 제약을 밝힙니다. Incus 사례는 공개 서비스가 있더라도 관리자 경로와 인스턴스 간 통신을 별도로 제한합니다. 따라서 이 접근법들을 같은 수준의 보안 장치로 간주하기보다는, 공개 경로·관리 경로·서비스 간 연결 중 어디를 통제하는지 구별해야 합니다.
자동화는 운영 편의와 재구축 가능성을 서로 다르게 겨냥한다
‘Incus OS로 구축한 셀프호스팅 인프라’는 서비스를 Git 저장소에 선언하고 OpenTofu와 cloud-init으로 인스턴스를 구성합니다. 변경이 생기면 해당 인스턴스를 폐기한 뒤 새로 만들기 때문에 설정 드리프트를 막고, 침해 흔적도 다음 재구축 때 사라질 수 있다고 설명합니다. 다만 변경 중 해당 구성 요소는 1~2분 이용할 수 없습니다. 운영체제와 Podman 컨테이너의 자동 업데이트도 사용하지만, Ubuntu 기본 이미지 자체를 갱신하는 방식은 아직 해결해야 할 과제로 적었습니다.
다른 두 글은 같은 수준의 선언형 재구축 체계를 설명하지 않습니다. ‘무엇을 셀프 호스팅하고 무엇은 맡기지 않는가’의 저자는 새 버전의 릴리스 노트를 보고 직접 업그레이드 시점을 정한다고 말합니다. ‘CGNAT 뒤에서 셀프 호스팅하기’는 터널의 짧은 단절은 재협상으로 복구되고, 홈랩은 SSH 작동 여부를 확인하는 cron 작업으로 재부팅한다고 설명합니다. 즉, 한 사례는 변경 후 서비스를 다시 만드는 자동화에 초점을 두고, 다른 사례들은 버전 선택이나 특정 장애 감지·복구를 다룹니다.
백업과 장애 대응은 같은 보장이 아니다
‘무엇을 셀프 호스팅하고 무엇은 맡기지 않는가’는 Restic용 웹 UI인 Backrest를 사용해 백업 보존 정책을 관리하고, 실패 알림을 Gotify로 받는다고 설명합니다. 특히 Immich 사진 백업을 중요하게 다룹니다. ‘Incus OS로 구축한 셀프호스팅 인프라’도 운영 서비스 목록에 Restic을 포함하지만, 제공된 발췌 구간에는 백업 대상·보존 정책·복구 절차가 나오지 않습니다. 그러므로 두 글이 백업 체계를 같은 정도로 상세히 제시한다고 볼 수는 없습니다.
‘CGNAT 뒤에서 셀프 호스팅하기’의 장애 대응은 백업보다 가용성 복구에 초점이 있습니다. 홈랩이 SSH에 응답하지 않으면 재부팅하고, VPS가 고장 났을 때를 대비해 Cloudflare Tunnel이나 Tailscale을 통한 대체 진입점을 권하며, 짧은 터널 단절은 자동 재협상된다고 설명합니다. Incus 사례는 한 대의 노트북에서 전체 인프라를 운영한다고 명시하고, 재구축 가능한 시스템 구성을 설명하지만, 발췌문만으로 장비 전체 장애 시 복구 절차까지 확인할 수는 없습니다. 서비스 접근을 되살리는 대책, 설정을 다시 만드는 능력, 데이터를 복원하는 백업은 각각 따로 점검해야 합니다.