커버 이미지: Immich 프로젝트 — 공식 애플리케이션 스크린샷.
다른 사람들이 의지하기 시작하면 홈 서버의 성격이 달라집니다. 취미 프로젝트에 이제 가족이 찾으려는 사진, 누군가가 접속할 것으로 기대하는 게임, 또는 원래 쓰던 휴대전화를 바꾼 뒤에도 소중하게 여길 자료가 담깁니다. 이런 변화는 시스템을 정리하는 방식을 다시 살펴볼 좋은 계기입니다.
u/2Hard4Him의 셀프 호스팅의 날 댓글에서는 Pi-hole을 써 보려던 계획이 ZimaOS를 실행하는 구형 Dell OptiPlex로 발전합니다. 게시자는 RAID 1으로 구성한 4 TB IronWolf 드라이브 2개, Crafty로 관리하는 Minecraft 서버, Immich를 통한 가족 사진 업로드, 원격 접속을 소개합니다. 아직 해결하지 못한 과제는 외부 위치에 백업을 보관하는 일입니다. 미러링된 드라이브는 드라이브 고장에는 대비하지만, 실수로 삭제한 데이터를 복구하려면 별도의 계획이 필요합니다.
“RAID 1은 백업이 아닙니다”
u/2Hard4Him
중요한 업그레이드는 서비스에 대한 책임을 맡는 것입니다
ZimaSpace의 관점에서 주목할 만한 변화는 실험을 시작한 단계에서 공동의 책임을 맡는 단계로 넘어가는 것입니다. 설치에 성공하는 것은 시작일 뿐입니다. 가족이 함께 쓰는 서비스에는 이해하기 쉬운 주소, 적절한 계정, 유지 관리 절차, 중요한 데이터를 복구할 방법도 필요합니다. 이런 세부 사항에 따라 시스템 소유자가 클릭할 때마다 설명하지 않아도 다른 사람이 시스템을 사용할 수 있는지가 결정됩니다.
집에서 해결할 일 하나를 정하고, 사용자가 생각하는 성공의 기준을 설명해 보세요. 사진을 쉽게 찾고 제대로 열 수 있어야 합니다. 공유 폴더는 지정된 사람에게 올바른 접근 권한을 제공해야 합니다. 게임 세션은 모두가 합의한 진행 상황을 보존해야 합니다. 앱 목록을 늘리기 전에 이런 결과를 적어 두세요. 그러면 일상생활을 개선하지 않으면서 유지 관리할 일만 늘리는 서비스와 실제로 유용한 서비스를 구분하는 데 도움이 됩니다.
앱을 더 추가하기 전에 서비스 책임부터 정리하세요
애플리케이션, 설정, 보관 데이터가 설정의 서로 다른 부분으로 구분되어 보이게 관리하세요. 설치는 쉽게 반복할 수 있어도 데이터베이스나 저장된 상태는 복구하기 어려울 수 있습니다. 각 중요 구성 요소의 위치와 이를 관리하는 계정을 기록하세요. 가족이 함께 쓰는 기기라면 서비스를 관리할 수 있는 사람과 사용만 하면 되는 사람도 정하세요.
정교한 대시보드가 없어도 충분히 관리할 수 있는 프로젝트입니다. 간단한 목록을 작성하면 서비스와 용도, 데이터 저장 위치, 재시작 후 확인해야 할 사항을 파악할 수 있습니다. 폴더를 옮기거나 계정을 변경할 때마다 이 목록을 업데이트하세요. 홈랩 아키텍처 사례 연구에서는 애플리케이션 역할을 분리하는 더 큰 규모의 예를 확인할 수 있습니다. 같은 습관은 재활용한 컴퓨터 한 대를 사용할 때도 유용합니다.
가정용 서비스에는 앱 아이콘 이상의 것이 필요합니다
| 책임 | 기록할 항목 | 시연할 항목 |
|---|---|---|
| 접근 | 일반적인 접속 경로와 적절한 사용자 계정 | 가족 구성원이 의도한 서비스에 접속할 수 있습니다. |
| 데이터 | 원본 파일, 애플리케이션 상태 및 구성 파일 위치 | 서비스가 기준이 되는 데이터를 식별할 수 있습니다. |
| 유지 관리 | 계획된 가동 중지 시간 및 업데이트/복구 절차 | 변경 후에도 일반적인 클라이언트 작업 흐름이 계속 작동합니다. |
| 복구 | 독립적인 사본과 버전 요구 사항 | 운영 중인 컬렉션을 변경하지 않고도 샘플을 복원할 수 있습니다. |
애플리케이션 전체를 고려한 사진 복구 설계
사진 서비스를 복구할 때는 사용할 수 있는 컬렉션을 복원해야 합니다. Immich의 백업 문서에는 완전한 백업에 데이터베이스와 에셋 파일이 모두 포함된다고 나와 있습니다. 데이터베이스 덤프만으로는 사진과 동영상을 복원할 수 없습니다. 복사한 디렉터리 하나에 모든 것이 담겼다고 가정하지 말고, 애플리케이션 자체의 복구 요구 사항도 가정용 백업 계획에 포함하세요.
격리된 테스트 환경에 소규모로 복원하고, 복원 대상 버전에 맞는 문서를 따르세요. 대표적인 원본 파일이 열리는지, 복원된 애플리케이션에서 해당 파일을 찾을 수 있는지 확인하세요. 테스트 조건과 결과를 기록해 두세요. 이는 가정에서 실제로 보존하려는 사용 경험을 테스트하므로 백업 파일 개수를 세는 것보다 더 유용한 승인 검사입니다. 복구 절차를 개발하는 동안에는 운영 중인 라이브러리를 변경하지 마세요.

공유 서버의 유지 관리 시간 정하기
가정에서 사용하는 서비스는 예측 가능한 변경이 필요합니다. 업데이트 전에 중단될 수 있는 항목을 파악하고, 관련 설정을 보존하며, 복구 사본을 사용할 수 있는지 확인하세요. 작업 일정을 서비스 이용자에게 알리세요. 작업 후에는 관리자 대시보드에서만 확인하지 말고 일반 사용자 계정으로 테스트하세요. 관리자는 다른 사용자에게 허용되지 않은 경로로 서비스에 접속할 수 있기 때문입니다.
중요한 업데이트는 새 애플리케이션 버전과 관련 데이터 마이그레이션을 기록하세요. 저장된 데이터 형식이 변경됐다면 이전 컨테이너 이미지로 되돌리는 것만으로는 충분하지 않을 수 있습니다. 애플리케이션 전체를 위한 호환 가능한 복구 경로를 유지하고 릴리스 안내를 확인하세요. 이렇게 하면 나중에 결과를 알게 되는 재시작의 연속이 아니라, 공유 시스템을 위한 계획된 변경으로 유지 관리를 진행할 수 있습니다.
ZimaCube 2가 자연스러운 다음 단계가 되는 경우
가정의 데이터 모음이 임시방편으로 마련한 저장 공간을 넘어서기 시작했다면, ZimaCube 2 개인용 클라우드 NAS는 더욱 체계적인 로컬 데이터 허브를 위한 한 가지 선택지입니다. 이는 기고자가 보고한 하드웨어와는 별개인 ZimaSpace의 계획 관점입니다. 중요한 것은 이제 가정에서 더 명확한 저장 공간 구성, 더 큰 드라이브 용량, 또는 공유 애플리케이션과 보관 파일을 위한 일관된 저장 공간이 필요한지 여부입니다.
플랫폼을 활용해 수신 영역, 기준이 되는 데이터 모음, 애플리케이션 데이터, 별도의 복구 대상을 정해 역할을 구분하세요. 측정한 증가량과 활성 서비스에 맞춰 드라이브 구성과 SSD 작업 계층을 계획하세요. 용량을 늘리는 것은 기존 복구 정책을 뒷받침해야지, 복구 정책 도입을 미뤄서는 안 됩니다. 주요 장치 외부에 복구 가능한 사본을 하나 더 보관하고, 복원한 데이터 모음을 다른 사람도 이해할 수 있는지 테스트하세요.

시스템이 확장되어도 가족이 쉽게 사용할 수 있도록 유지하기
사람들이 하려는 일을 반영하는 이름과 진입점을 사용하세요. 사진 라이브러리를 여는 사람이 컨테이너 이름이나 저장소 구조를 알 필요는 없어야 합니다. 관리자에게는 더 상세한 서비스 목록을 제공하면서 편리한 사용자 경험을 유지하세요. 간단한 시작 화면과 문서화된 백엔드는 함께 사용할 수 있으며, 각각 다른 사람에게 유용합니다.
전체 컬렉션을 옮기거나 앱을 더 추가하기 전에, 원본에서 공유 액세스, 복구까지 이어지는 간단한 인계 절차를 한 번 완료하세요. 계정 권한을 확인하고, 원본 파일을 찾은 다음, 샘플 파일을 복원해 보세요. ZimaOS Photos 소개에서 로컬 사진 라이브러리 워크플로를 다른 관점으로 살펴볼 수 있습니다. 가족에게 잘 맞는 앱을 선택하고, 해당 앱의 저장 공간 및 복구 요구 사항을 명확히 정리해 두세요.
Self-Hosting Day에서 얻은 교훈
가족 서버의 다음 단계는 신뢰입니다. 누구나 사용할 수 있고, 관리자는 유지 관리할 수 있으며, 중요한 데이터를 복구할 방법이 있어야 합니다. 유용한 아이디어 하나에서 시작한 프로젝트가 거둘 수 있는 의미 있는 성과입니다.
더 둘러보기
- Self-Hosting Day 2026: 9월 25일이 셀프 호스팅 커뮤니티의 날인 이유
- AI 에이전트가 사용하는 파일의 복구 가능한 사본을 보관하는 방법
- 노트북을 교체해도 유지되는 사진 아카이브 설정
원문 스토리 및 프로젝트 참고 자료
위에 링크된 Self-Hosting Day 공개 기여 내용을 바탕으로 했습니다. 아키텍처 해석과 하드웨어 계획 관련 참고 사항은 ZimaSpace에서 작성했습니다. 스크린샷과 제품 일러스트는 원래 프로젝트 또는 제조업체에 저작권이 있습니다.
Zima 캠페인 허브
더 읽어보기

From a Patchwork ARM Homelab to Three x86 Servers: Julien’s Migration
Julien moved a varied ARM homelab to three compact x86 hosts with Debian, Docker, ZFS, Borg and Caddy, migrating services one at a time.

One Blade, Three Households: How a Tiny x86 Board Became My Family’s IT Department
Vladimir Penkin shares how two compact x86 servers became family infrastructure across countries, from a Tailscale exit node to Immich photo uploads.

Barely Works, but Getting There: Chris’s Mixed x86 and ARM Homelab
Chris pairs a dependable two-drive Debian NAS with a ZimaBoard 2 and Raspberry Pi cluster, experimenting with k3s, Ollama and a Pi Pico backup...




