---
title: "시놀로지 없이 ZFS NAS를 직접 굴리는 최소 구성 가이드"
published: 2026-07-08T03:59:35.000Z
canonical: https://jeff.news/article/4847
---
# 시놀로지 없이 ZFS NAS를 직접 굴리는 최소 구성 가이드

그래픽 관리 도구가 필요 없다면, 데비안과 오픈ZFS, 삼바만으로도 꽤 단순한 NAS를 만들 수 있다는 실전 가이드다. 4개의 4테라바이트 NVMe SSD로 레이드제트1 풀을 만들고, 데이터셋을 나눈 뒤 맥과 리눅스에서 접근 가능한 공유 스토리지로 구성하는 흐름을 다룬다.

- 트루나스나 시놀로지 없이도, 기본 NAS 정도는 ZFS와 삼바만으로 충분히 만들 수 있다는 가이드임
  - 목표는 화려한 관리자 화면이 아니라 “내가 구조를 전부 아는 파일 서버”에 가까움
  - 작성자는 트루나스가 나쁘다는 게 아니라, 단순한 공유 스토리지엔 기능이 너무 많고 무겁다고 봄

- 예시 구성은 꽤 현실적인 홈랩·소규모 서버 감성임
  - 운영체제는 데비안 12 북웜 기준
  - 스토리지는 삼성 990 프로 4테라바이트 NVMe SSD 4개
  - 메모리는 16기가바이트 ECC RDIMM, CPU는 중고로 구할 수 있는 4코어 제온 서버 CPU 정도를 상정함
  - 레이드 레벨은 디스크 1개 장애를 버티는 RAIDZ1, 암호화와 백업은 이 글 범위에서 제외함

> [!IMPORTANT]
> 이 글의 핵심은 “NAS 제품을 사지 말자”가 아니라, ZFS 풀을 직접 이해하고 최소 구성으로 운영할 수 있다는 점임.

- 작성자가 제일 강조하는 ZFS의 장점은 구성이 디스크에 남는다는 것임
  - 운영체제가 망가지거나 서버 본체가 죽어도, 디스크들이 멀쩡하면 다른 머신에 꽂고 ZFS 도구 설치 후 `zfs import`로 다시 가져올 수 있음
  - RAIDZ2로 6개 디스크를 묶은 구성도 같은 방식으로 풀 정보가 디스크에 들어 있음
  - `/etc/zfs/vdev_id.conf` 같은 호스트 쪽 편의 설정이 사라져도 풀 자체를 복구하는 데 핵심 문제는 아니라고 설명함

- 첫 단계는 디스크를 안정적으로 식별하는 것임
  - `lsblk -d -o TRAN,NAME,TYPE,MODEL,SERIAL,SIZE`로 디스크 모델, 시리얼, 용량을 확인함
  - `/dev/nvme1` 같은 이름은 장착 순서에 따라 바뀔 수 있어서 권장하지 않음
  - 대신 `/dev/disk/by-id`의 시리얼 기반 경로를 쓰거나, `/etc/zfs/vdev_id.conf`에 `nvme0`부터 `nvme3`까지 별칭을 매핑함

- ZFS 풀은 RAIDZ1로 만들고, 생성 시점에 `ashift=12`를 지정함
  - 예시 명령은 `zpool create -o ashift=12 s16z1 raidz1 nvme0 nvme1 nvme2 nvme3`
  - `ashift=12`는 4킬로바이트 섹터 정렬을 의미함
  - 많은 디스크가 호환성 때문에 운영체제에는 512바이트 섹터처럼 보고하지만, 실제 대용량 SSD에서는 4킬로바이트나 8킬로바이트 정렬이 성능에 중요할 수 있음

> [!WARNING]
> `ashift`는 풀을 만든 뒤 바꾸기 어려운 값이라 처음에 잘 잡아야 함. 대충 만들었다가 나중에 성능 문제를 보면 꽤 귀찮아질 수 있음.

- 풀을 만들었다고 끝이 아니라, 파일시스템 성격의 데이터셋을 나눠야 함
  - 작성자는 `zfs set mountpoint=/mnt/s16z1 s16z1`로 마운트 위치를 잡고, `zfs set compression=lz4 s16z1`로 압축을 켬
  - 이후 `s16z1/docs`, `s16z1/backups` 같은 데이터셋을 별도로 만듦
  - ZFS 데이터셋은 그냥 폴더가 아니라 스냅샷, 복제, 암호화, 전송 같은 기능을 독립적으로 걸 수 있는 관리 단위임

- 네트워크 공유는 삼바가 맡음
  - ZFS는 디스크와 파일시스템을 담당하고, 삼바는 그 마운트된 경로를 네트워크에 노출함
  - `useradd -m john`, `passwd john`, `smbpasswd -a john` 흐름으로 리눅스 사용자와 삼바 사용자를 연결함
  - 이후 `smb.conf`에서 `docs`와 `backups` 공유를 각각 설정함

- 맥 타임머신까지 고려한 설정도 들어 있음
  - `backups` 공유에는 `fruit:time machine = yes`, `fruit:aapl = yes`, `streams_xattr` 같은 옵션을 넣음
  - 맥에서는 파인더에서 `smb://10.0.0.6/backups` 형태로 연결한 뒤 타임머신 대상 디스크로 추가할 수 있음
  - 리눅스에서는 `smbclient -U john //10.0.0.6/docs -c 'ls'` 같은 식으로 접근 테스트를 함

- 이 가이드가 다루지 않는 부분도 분명함
  - 백업 전략은 빠져 있고, 작성자는 별도 ZFS 백업 스케줄러를 쓰라고만 언급함
  - 암호화와 ZFS 데이터셋 복제는 다음 글에서 확장할 계획이라고 함
  - 그러니까 이 글은 완성형 운영 매뉴얼이라기보다 “최소한의 ZFS NAS를 직접 띄우는 골격”에 가까움

---

## 기술 맥락

- 여기서 선택한 핵심은 트루나스 같은 올인원 NAS 배포판 대신, 리눅스 위에 OpenZFS와 Samba만 얹는 방식이에요. 왜냐하면 필요한 게 파일 공유뿐이라면 관리자 화면, 플러그인, 엔터프라이즈 기능이 오히려 운영 표면을 넓힐 수 있거든요.

- ZFS를 고른 이유는 단순히 레이드가 되기 때문이 아니에요. 풀 구성 정보가 디스크에 저장되기 때문에 운영체제가 깨져도 다른 머신에서 `zfs import`로 다시 가져올 수 있다는 점이 커요. 개인 NAS에서 제일 무서운 건 UI가 예쁘냐가 아니라, 장애 때 데이터를 다시 잡을 수 있느냐예요.

- RAIDZ1은 4개 디스크에서 디스크 1개 장애를 버티는 절충안이에요. RAIDZ2가 더 안전하지만 usable capacity가 줄고, 이 글의 목표는 초보자가 최소 구성으로 시작하는 NAS라서 RAIDZ1을 택한 흐름이에요.

- 데이터셋을 `docs`와 `backups`로 나누는 것도 중요한 선택이에요. 그냥 폴더로 나누면 나중에 스냅샷, 복제, 권한, 백업 정책을 따로 가져가기 어렵거든요. ZFS에서는 데이터셋이 운영 단위라서 처음부터 큰 용도별로 나눠두는 게 관리하기 좋아요.

- Samba는 ZFS와 역할이 완전히 달라요. ZFS가 로컬 스토리지의 무결성과 구조를 책임진다면, Samba는 그 경로를 맥이나 리눅스 클라이언트가 네트워크 드라이브처럼 쓰게 해줘요. 특히 맥 타임머신은 전용 옵션이 필요해서 일반 공유와 백업 공유를 분리한 구성이 자연스러워요.

## 핵심 포인트

- 트루나스 같은 대형 관리 도구 없이 ZFS와 삼바만으로 기본 NAS를 구성함
- 4개 4테라바이트 NVMe SSD, 레이드제트1, 16기가바이트 ECC 메모리 같은 구체적 사양을 제시함
- ZFS 풀 설정은 디스크 자체에 저장되므로 운영체제가 망가져도 zfs import로 복구할 수 있다는 점을 강조함
- ashift=12, lz4 압축, 데이터셋 분리, 타임머신용 삼바 설정까지 실제 명령 중심으로 설명함

## 인사이트

홈랩이나 소규모 팀 스토리지에서 ‘관리 화면 예쁜 NAS’보다 ‘내가 구조를 이해하는 NAS’가 더 나을 때가 있다. 특히 ZFS의 이식성과 데이터셋 단위 운영을 제대로 이해하면, 단순 파일 서버도 백업·복제 전략의 출발점이 될 수 있음.
