# 내 Homelab은 유지보수하지 않는다

> Clean Markdown view of GeekNews topic #31126. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31126](https://news.hada.io/topic?id=31126)
- GeekNews Markdown: [https://news.hada.io/topic/31126.md](https://news.hada.io/topic/31126.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-05T06:02:28+09:00
- Updated: 2026-07-05T06:02:28+09:00
- Original source: [cleberg.net](https://cleberg.net/blog/homelab-maintenance.html)
- Points: 1
- Comments: 1

## Topic Body

- 개인 Homelab 운영 부담을 줄이기 위해 **단일 서버 구성**과 자동 업데이트에 집중해, 일상적인 손봐야 할 일을 대부분 없앤 상태임
- 여러 서버를 하나로 통합하면서 환경 복잡도가 줄었고, 서버 수 기준 유지보수도 **75% 감소**함
- Raspberry Pi 4는 **Home Assistant OS**, 네트워크는 UniFi의 자동·예약 업데이트에 맡겨 수동 관리 지점이 줄어듦
- Docker 서비스는 주 1회 `docker compose pull`과 `docker compose up -d`를 실행하는 **crontab**으로 갱신하고, root crontab은 주로 백업에 쓰임
- 긴급 상황이 없다면 월간 유지보수는 약 **15분**이며, `apt update`와 재시작을 미뤄도 당장 서비스 영향은 거의 없음

---

### 단순화된 인프라 구성
- Homelab 서비스는 여러 장비에서 **단일 서버**로 통합됨
  - 기존에는 4대 서버를 사용했지만, 현재는 하나의 물리 서버에 서비스를 모음
  - 클러스터, 하이퍼바이저, 하이브리드 클라우드 대신 지하실의 물리 장비 하나로 운영함
  - 이 단순화로 서버 기준 유지보수량이 **75% 감소**함
- Raspberry Pi 4는 별도로 있지만, **Home Assistant OS**가 자체 업데이트를 처리해 관리 부담이 작음
  - 기술적으로는 서버에 가깝지만, 실제 사용감은 자체 유지되는 IoT 장치에 가까움
- 네트워크 장비는 미니 랙의 **UniFi** 구성으로 운영됨
  - UniFi Dream Machine Pro, 스위치, 여러 AP가 포함됨
  - 자동 업데이트와 예약 업데이트를 지원해 네트워크 장비도 수동으로 자주 만질 필요가 없음

### 자동화된 소프트웨어 업데이트와 백업
- Docker 서비스 업데이트는 서버의 단일 **crontab** 항목으로 매주 실행됨
  - `0 0 * * 0 docker-update`
  - `docker-update`는 `~/docker/*/` 아래 각 디렉터리에서 `sudo docker compose pull`과 `sudo docker compose up -d`를 실행함
- root 사용자 crontab은 대부분 **백업** 용도임
  - 매일 시스템 리포트를 생성함
  - Immich와 Piped의 PostgreSQL 덤프를 생성함
  - Plex, 웹 서버, Nginx 설정, Docker 디렉터리, SSH 파일을 ZFS 풀로 `rsync` 백업함
  - Docker 디렉터리 백업에서는 데이터베이스·캐시·임시 파일·일부 로그 경로를 제외함
- 남은 수동 작업은 `apt update`, `apt upgrade`, `apt autoremove` 실행과 필요 시 재시작 정도임
  - 이 작업에는 약 **60초**가 걸림
- 긴급 상황이 없다면 유지보수 시간은 월 약 **15분** 수준임
  - 한 달 동안 SSH로 접속해 업데이트하지 않아도 실제 서비스에는 영향이 없음
  - 6개월 이상 손대지 않아도 고장 나지 않을 가능성이 있지만, 일부러 시험할 계획은 없음
- 현재 구성은 바쁜 일정 속에서도 **프라이버시, 보안, 편의성** 사이의 균형을 제공함

## Comments



### Comment 61266

- Author: neo
- Created: 2026-07-05T06:02:29+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/fx5e0f/i_don_t_maintain_my_homelab) 
- 집 서버도 비슷하게 운영 중임  
  **Debian**에 무인 보안 업그레이드를 켜고, 모든 것은 버전을 고정한 루트리스 컨테이너로 돌리며, Podman Quadlet을 통해 systemd가 관리함  
  Podman의 [auto-update](https://docs.podman.io/en/latest/markdown/podman-auto-update.1.html)가 컨테이너 업데이트를 처리하고, systemd 타이머가 백업·이미지 정리 같은 반복 작업을 맡음  
  커널 업그레이드가 있거나 이미지 버전을 올릴 때만 재부팅하러 들어가며, 이 작업은 **Ansible**이 처리함
  - “버전 고정”과 “Podman auto-update”가 같이 쓰인 부분이 헷갈림  
    버전을 고정했다는 말은 자동으로 업데이트를 가져오지 않는다는 뜻으로 이해했는데, 실제로는 업데이트를 하고 있는 듯해서 서로 다른 대상이 업데이트되는 건지 잘 모르겠음
  - 거의 같은 구성을 **10년 넘게** 써왔고, 격년으로 최신 stable로 올림  
    따로 관리하는 장비는 라우터 하나뿐인데 **OpenBSD**라 새 버전이 나오는 약 6개월마다 업그레이드함  
    둘 다 지루할 정도로 안정적임

- 비슷하지만, 원하는 기능이 생기기 전에는 아무것도 업데이트하지 않음  
  **셀프호스팅 소프트웨어**의 좋은 점은 내 일정에 맞춰 업데이트할 수 있다는 것임  
  모든 게 잘 돌아가고, Tailscale을 통해서만 접근되고 인터넷에 직접 노출되지 않는다면 하드웨어 고장을 제외하고는 그냥 놔둬도 안정적임
  - 애플리케이션이 인터넷에 직접 노출되는 것과 **Tailscale**을 통해 노출되는 것이 왜 다른지 궁금함  
    애플리케이션에 도달하는 데이터는 결국 같으니, 같은 취약점이 악용될 수 있는 것 아닌가 싶음

- 그런 상태라면 꽤 좋은 상황임  
  나도 거기에 도달하려고 하지만 아직 완전히는 못 했음  
  **Debian 메이저 업그레이드**는 2년마다 여전히 수작업이 필요함: ["Issues to be aware of for trixie"](https://www.debian.org/releases/stable/release-notes/issues.en.html#issues-to-be-aware-of-for-releasename), ["Obsolescence and deprecation"](https://www.debian.org/releases/stable/release-notes/issues.en.html#obsolescence-and-deprecation), ["Cleanup after the upgrade"](https://www.debian.org/releases/stable/release-notes/upgrading.en.html#cleanup-after-the-upgrade)  
  오래된 Ansible은 최신 Debian 시스템을 다루지 못해서, Debian 서버를 올리면 Ansible 버전도 올려야 하고 결국 플레이북도 새 Ansible에 맞게 고쳐야 함  
  지금은 [using more Docker containers](https://lobste.rs/s/htfm3p/pyinfra_agentless_infrastructure#c_mbor2w)로 이를 줄이려 하지만 Ansible을 완전히 대체하긴 어려울 듯함  
  freeDNS, dynv6.net처럼 직접 호스팅하고 싶지 않은 온라인 서비스도 있고, 이들도 가끔 깨지는 변경을 냄  
  그래도 전체적으로는 꽤 괜찮은 편임  
  솔직히 말하면 “유지보수 없는” 홈랩의 관리는 우리가 쓰는 소프트웨어, 패키지, Docker 이미지를 관리하는 전 세계 **오픈소스 개발자들**에게 맡기고 있는 셈임

- 내 구성을 “홈랩”이라고 부르긴 망설여지지만, 여러 **Docker 컨테이너**를 돌리는 unRAID NAS임  
  unRAID에 돈을 내도 만족하는 이유 중 하나가 Docker 지원이 적당히 좋고, 플러그인으로 컨테이너 자동 업데이트가 가능하며, 다른 유지보수도 꽤 단순하기 때문임

- 개인적으로 “랩”은 실험하는 장소에 가깝고 실험 자체를 유지보수할 필요는 없다는 점이 좀 걸림  
  **컨테이너** 사용은 장단이 섞여 있음  
  어떤 프로젝트는 컨테이너가 1급 배포 수단이라 그 방식으로 제대로 업데이트를 받을 수 있음  
  하지만 많은 사람이 관리가 애매한 컨테이너를 돌리는 것 같고, 거기서 문제가 많이 생길 것으로 봄  
  핵심은 내가 쓰는 소프트웨어에서 업데이트를 받는 **정식 경로**가 무엇인지 파악하는 데 있음  
  나는 주로 RHEL 클론을 자동 업데이트로 운영하고, 재부팅이 필요하면 Nagios가 알려줌  
  대부분의 서비스가 RHEL이나 EPEL 안에 있어서 유지보수가 꽤 적음

- 내 홈랩 유지보수에는 `pyinfra`가 딱 적당히 게으를 수 있는 수준이었음  
  설정 과정을 코드로 적어둘 수 있고, 특히 설정 파일 같은 것에 유용하며, `nix`에서 이걸 어떻게 처리하지 같은 고민 없이 필요하면 `apt`를 호출하면 됨  
  아주 똑똑한 도구는 아니지만 단일 셸 스크립트보다는 낫고, 앞으로 더 발전시켜보고 싶음  
  에이전트형 코딩을 쓰는 경우에는 Claude에게 **pyinfra 파일**을 보여주고 구성 디버깅 도움을 받을 수 있다는 보너스도 있음

- 서버에서 **NixOS**를 쓰고 있고, 생각날 때마다 가끔 업데이트함  
  대부분은 `nix flake update && nix run .#deploy` 정도로 끝나서 크게 신경 쓰지 않음

- 나도 매우 비슷한 상황인데, 인정하긴 싫지만 상당 부분은 결국 구성이 더 단순해진 덕분임  
  예전에는 회전 로그까지 갖춘 전체 **관측성 스택**을 좋아했지만, 최근의 골치 아픈 일들은 2년 넘게 전부 그 복잡성에서 나온 사소한 문제였음  
  로그와 메트릭 때문에 디스크가 꽉 차는 식의 일들임  
  해결은 아주 쉽지만 이제는 그런 것들을 더는 처리하고 싶지 않음

- docker-compose 구성을 최신으로 유지하는 데는 **Watchtower**가 마음에 듦  
  https://hub.docker.com/r/nickfedor/watchtower  
  버전을 계속 올리면서도 주요 변경을 어느 정도 감안할 수 있는 설정 옵션이 꽤 좋음  
  기본 운영체제는 Debian LTS에 무인 업데이트만 켜두고, 새 커널이 나오면 재부팅하러 들어감  
  정말 일이 많지 않고, 월 15분 미만이라는 말에 동의함