[NAS] "안녕, 시놀로지" 13년 차 엔지니어가 Pure Docker와 ZFS로 갈아탄 이유

들어가며: 기성복(Synology)을 벗고 맞춤 정장을 입어야 할 때

안녕하세요, 시스템 엔지니어이자 4남매 아빠 수누다입니다.

홈랩이나 개인용 서버를 처음 구축하시는 분들에게 시놀로지(Synology)는 분명 훌륭한 선택지입니다. 누구나 입기 편하고 디자인도 깔끔한 기성복과 같죠. 직관적인 GUI와 다양한 패키지 덕분에 클릭 몇 번이면 파일 서버부터 미디어 스트리밍까지 손쉽게 구성할 수 있습니다.

하지만 저처럼 12살 큰애부터 3살 막내까지, 4남매의 12년 치 추억이 담긴 방대한 데이터를 보관해야 하는 엔지니어의 입장에서는 이야기가 조금 다릅니다. 제조사의 폐쇄적인 정책에 따라 기능이 제한되거나, 메이저 OS 업데이트 한 번에 그동안 공들여 세팅해 둔 커스텀 스크립트가 꼬여버리는 상황은 늘 불안 요소로 작용했습니다. "내 하드디스크에 있는 데이터인데, 왜 제조사의 통제를 받아야 할까?"라는 근본적인 의문이 들었죠.

그래서 저는 과감하게 시놀로지는 물론, 오픈소스 진영의 대안으로 불리는 OMV(OpenMediaVault)나 TrueNAS 같은 중간 단계의 NAS OS마저 모두 걷어내기로 결심했습니다. 대신 Proxmox 호스트의 네이티브 ZFS 파일 시스템과 Docker를 직결하는 이른바 'Pure Docker' 방식을 택했습니다. 가상화 오버헤드를 극단적으로 줄이고 데이터 제어권은 100% 제가 가져오는, 엔지니어만의 맞춤 정장 같은 인프라 설계 과정을 상세히 공유합니다.

1. 전용 NAS OS(시놀로지, OMV)를 걷어낸 기술적 배경

불필요한 레이어(추상화) 제거를 통한 리소스 극대화

NAS 전용 OS는 리눅스 터미널에 익숙하지 않은 일반 사용자에게는 GUI라는 엄청난 편리함을 제공합니다. 하지만 시스템 구조를 훤히 꿰뚫고 있는 엔지니어에게는 굳이 필요 없는 데몬(Daemon)들이 백그라운드에서 돌아가며 자원을 갉아먹는, 관리해야 할 레이어가 하나 더 늘어나는 것에 불과합니다.

기존에 NAS OS가 점유하던 2~4GB의 RAM과 CPU 자원을 아껴서, 구글 포토를 대체할 Immich의 AI 안면 인식 및 머신러닝 작업이나 홈랩 내 k3s 쿠버네티스 클러스터에 온전히 할당하는 것이 훨씬 이득입니다. 13년 차 인프라 관리 경험에 비추어 볼 때, 시스템 자원은 덜어낼 수 있을 때 최대한 덜어내어 가장 무거운 핵심 워크로드에 집중시키는 것이 최적화의 기본입니다.

트러블슈팅의 투명성 확보

블랙박스처럼 닫혀 있는 전용 OS는 에러가 발생했을 때 제조사가 제공하는 제한된 로그만으로 원인을 유추해야 합니다. 반면, 순수 리눅스(Debian 기반 Proxmox) 환경에서 Docker를 돌리게 되면 모든 설정과 로그가 표준 방식을 따릅니다. 문제가 생기더라도 journalctl이나 docker logs 명령어 한 줄이면 원인을 명확히 파악할 수 있어 유지보수의 투명성이 비약적으로 상승합니다.

2. 11TB 데이터를 지키는 무적의 방패, ZFS 파일 시스템

제가 홈랩을 재구축하며 11TB라는 거대한 스토리지 풀을 운영하는 데 있어 가장 심혈을 기울인 부분은 바로 파일 시스템의 선택이었습니다. ext4나 xfs도 훌륭하지만, 데이터의 영속성을 보장하기 위해 엔터프라이즈급에서 사용되는 ZFS(Zettabyte File System)를 전격 도입했습니다.

Bit Rot(비트 부패) 원천 차단과 자가 치유(Self-Healing)

하드디스크에 오래 저장된 데이터는 자성 물질의 열화나 우주선(Cosmic Ray) 등의 영향으로 사용자도 모르게 비트가 반전되는 현상, 즉 '비트 로트(Bit Rot)'가 발생할 수 있습니다. 10년 전 아이들의 돌잔치 영상이 어느 날 갑자기 재생되지 않는 끔찍한 사태가 벌어지는 것이죠. ZFS는 모든 데이터 블록에 해시(Hash) 기반의 체크섬을 기록해 둡니다. 데이터를 읽을 때마다 이 체크섬을 대조하여 오류가 발견되면, 정상적인 복제본이나 패리티 데이터를 이용해 실시간으로 데이터를 자동 복구(Self-Healing)합니다.

Ashift=12 최적화와 스냅샷(Snapshot)의 위력

요즘 출시되는 대용량 하드디스크는 물리적 섹터 크기가 4K(4096 바이트)인 Advanced Format을 사용합니다. ZFS 풀을 생성할 때 반드시 ashift=12 속성을 명시적으로 할당해 주어야 논리적 블록과 물리적 섹터가 정확히 정렬되어 쓰기 성능이 반토막 나는 현상을 막을 수 있습니다.
또한, ZFS의 스냅샷 기능은 파일 시스템의 특정 시점 상태를 찰나의 순간에 얼려버립니다. 만약 랜섬웨어가 홈랩에 침투해 모든 파일을 암호화하더라도, 1초 전의 스냅샷으로 롤백(Rollback) 명령을 내리기만 하면 데이터는 완벽하게 원상 복구됩니다.

3. Proxmox 호스트와 Docker 컨테이너의 직결 (Pure Docker)

무거운 가상머신(VM)에 OMV를 올리는 대신, 저는 Proxmox 호스트 레벨에서 직접 관리하는 ZFS 데이터셋을 경량 LXC 컨테이너 내부의 Docker에 바인드 마운트(Bind Mount) 방식으로 직결했습니다. 네트워크 스택을 타지 않기 때문에 스토리지 I/O 성능의 손실이 0(Zero)에 가깝습니다.

FileBrowser와 Immich를 활용한 서비스 구축

복잡한 NAS 관리 페이지 대신, 빠르고 가벼운 웹 기반 파일 관리자인 FileBrowser를 컨테이너로 띄웠습니다. 외부에서 4남매의 교육 자료를 공유하거나 스마트폰으로 급하게 문서를 찾을 때, 시놀로지의 파일 스테이션보다 훨씬 빠르고 직관적인 사용자 경험을 제공합니다.

여기에 구글 포토를 완벽하게 대체할 수 있는 Immich 컨테이너를 함께 올렸습니다. 가족들의 스마트폰에 있는 사진들이 실시간으로 11TB ZFS 스토리지로 백업되며, Proxmox 호스트의 남는 자원을 활용해 사진 속 인물의 얼굴을 AI로 빠르고 정확하게 분류해 줍니다.

UID/GID 매핑을 통한 권한 트러블슈팅

이 'Pure Docker' 방식에서 엔지니어들이 가장 골치 아파하는 부분이 바로 권한(Permission) 문제입니다. Proxmox의 비특권(Unprivileged) LXC 컨테이너는 호스트와 격리되어 있기 때문에, 호스트의 ZFS 폴더를 컨테이너에 마운트하면 Permission denied 에러가 발생하며 쓰기가 불가능해집니다.

이를 해결하기 위해서는 Proxmox 호스트 쉘에서 해당 LXC 설정 파일(/etc/pve/lxc/ID.conf)을 열어 lxc.idmap 옵션을 통해 호스트의 사용자 ID(UID)와 그룹 ID(GID)를 컨테이너 내부의 권한 구조와 정확히 매핑해 주어야 합니다. 이 원리만 제대로 이해하고 설정한다면, 어떤 폴더든 자유자재로 권한을 제어할 수 있습니다.

요약 및 에필로그

1. 플랫폼의 전환: 폐쇄적인 전용 NAS OS(시놀로지, OMV)의 한계를 극복하기 위해, 불필요한 레이어를 걷어낸 Proxmox + Pure Docker 기반의 심플하고 강력한 아키텍처로 이주했습니다.
2. 무결성의 확보: 엔터프라이즈 파일 시스템인 ZFS의 자가 치유 능력과 스냅샷을 통해 11TB에 달하는 가족들의 소중한 데이터를 랜섬웨어와 하드웨어 오류로부터 안전하게 지켜냈습니다.
3. 성능의 극대화: 가상화 오버헤드를 제거한 바인드 마운트 방식을 통해 스토리지의 깡성능을 100% 활용하며, 남는 자원을 AI 분석과 오케스트레이션(k3s)에 재투자하는 엔지니어다운 효율성을 달성했습니다.

내 데이터의 주권을 온전히 내가 통제하고 설계하는 것. 이것이 바로 홈랩을 운영하는 진정한 묘미가 아닐까요? 앞으로도 인프라 최적화에 대한 치열한 고민을 꾸준히 나누도록 하겠습니다.

---