[NAS] TrueNAS ZFS 풀 확장: 성능 저하 없이 용량 늘리는 방법 분석

목차

• 왜 TrueNAS ZFS 확장이 까다로운가
• 핵심 개념: 성능 저하 없이 용량 늘린다는 말의 의미
• TrueNAS ZFS 확장 방법 비교
• 실전 1: 새 vdev 추가로 TrueNAS ZFS 확장하기
• 확장 전 확인
• 절차
• 이 방식이 성능 면에서 유리한 이유
• 실전 2: 디스크를 하나씩 교체해서 NAS 용량 증설하기
• 기본 흐름
• 자동 확장 확인
• TrueNAS GUI에서 볼 때 체크할 포인트
• ⚠️ 주의사항과 트러블슈팅
• 1. 디스크 하나만 추가해서 RAIDZ를 키우려는 시도
• 2. 크기가 다른 디스크를 섞어 넣는 문제
• 3. 리실버 중 성능 저하를 무시하는 문제
• 4. 백업 없이 확장 작업부터 들어가는 문제
• 5. 디바이스 이름을 대충 보고 진행하는 문제
• 검증: 확장 후 무엇을 확인해야 하나
• 어떤 확장 전략이 가장 현실적인가
• 자주 묻는 질문
• Q1. 디스크 추가만 하면 자동으로 성능도 같이 좋아지나요?
• Q2. NAS 용량 증설 시 제일 먼저 볼 명령은 뭔가요?
• Q3. ZFS 성능을 위해 SSD 캐시만 추가하면 해결되나요?
• 정리: TrueNAS ZFS 확장은 구조를 지키는 쪽이 결국 이깁니다

[NAS] TrueNAS ZFS 풀 확장: 성능 저하 없이 용량 늘리는 방법 분석

홈랩(Home Lab, 개인 실험실) NAS를 오래 굴리다 보면 결국 한 번은 맞닥뜨리는 문제가 있습니다. 분명 처음엔 넉넉하다고 생각했는데, 백업 데이터와 미디어 파일, VM 이미지가 쌓이면서 어느 순간 용량이 바닥을 보더라고요. 저도 TrueNAS ZFS 확장을 몇 번 직접 해보면서 느낀 건, 그냥 디스크 하나 더 꽂는다고 끝나는 구조가 아니라는 점이었습니다. 특히 TrueNAS ZFS 확장은 성능과 안정성을 같이 봐야 해서, 잘못 접근하면 NAS 용량 증설은 됐는데 ZFS 성능이 애매해지는 경우가 생깁니다.

처음엔 저도 "디스크 추가만 하면 되겠지?"라고 생각했었는데, ZFS(제트에프에스, 파일시스템+볼륨 매니저 통합 구조)는 생각보다 설계 철학이 명확합니다. 그래서 오늘은 성능 저하 없이 용량을 늘리는 방법에 초점을 맞춰서, 어떤 방식이 안전한지, 어떤 방식은 조심해야 하는지, 그리고 실제로 확인해야 할 명령어까지 한 번에 정리해보겠습니다.

TrueNAS ZFS 확장 전략을 한눈에 보여주는 개요 다이어그램입니다. 기존 풀, vdev, 디스크 추가 방향을 직관적으로 이해할 수 있게 배치하면 좋습니다.

왜 TrueNAS ZFS 확장이 까다로운가

쉽게 말해 ZFS는 단순히 디스크 몇 개를 묶는 수준이 아니라, vdev(Virtual Device, 가상 장치) 단위로 성능과 안정성을 관리합니다. 그리고 여러 vdev가 모여 하나의 pool(풀)을 만들죠. 여기서 중요한 포인트가 있습니다. 풀은 확장하기 쉬워 보여도, 기존 vdev 구조는 생각보다 보수적으로 다뤄야 한다는 점입니다.

예를 들어 mirror(미러, 동일 데이터 복제) vdev 2개로 풀을 만들었다면, 나중에 같은 형태의 mirror vdev를 하나 더 추가하는 건 비교적 자연스럽습니다. 반면 RAIDZ(레이드지, 패리티 기반 보호) vdev 하나로 구성한 풀은, 전통적으로는 그 vdev에 디스크 하나만 툭 추가하는 방식이 깔끔하지 않았거든요. 여기서 많은 분들이 삽질을 시작합니다. 저도 처음엔 이게 뭔가 싶었는데, 구조를 이해하고 나니 왜 ZFS가 그렇게 동작하는지 보이더라고요.

핵심 개념: 성능 저하 없이 용량 늘린다는 말의 의미

"성능 저하 없이"라는 표현을 좀 더 정확히 풀어보겠습니다. ZFS에서 성능은 대체로 다음 요소에 영향을 받습니다.

• vdev 개수: 일반적으로 vdev가 늘어나면 병렬성이 좋아질 수 있습니다.
• 각 vdev의 디스크 수와 형태: mirror인지 RAIDZ인지에 따라 IOPS(Input/Output Operations Per Second, 초당 입출력 작업 수) 특성이 달라집니다.
• 디스크 크기와 속도의 균형: 느린 디스크가 섞이면 전체 체감이 나빠질 수 있습니다.
• 확장 과정 중 resilver(리실버, 데이터 재동기화) 부하: 이 과정에서 일시적으로 성능이 떨어질 수 있습니다.

즉, 용량만 늘어나는 방식과 용량과 성능 특성을 함께 유지하는 방식은 다릅니다. 실제로 써보니까 가장 덜 후회하는 방법은 아래 두 가지였습니다.

1. 기존과 동일한 성격의 vdev를 추가해서 풀 병렬성을 유지하는 방법
2. 기존 디스크를 하나씩 더 큰 디스크로 교체한 뒤 자동 확장(autoexpand, 자동 확장)을 활용하는 방법

반대로, 크기나 성능이 제각각인 디스크를 즉흥적으로 추가하면 NAS 용량 증설은 되더라도 장기적으로 운영이 피곤해집니다. 특히 장애 대응할 때 구조가 복잡해지더라고요.

TrueNAS ZFS 확장 방법 비교

방법	언제 적합한가	ZFS 성능 영향	장점	주의점
동일한 새 vdev 추가	베이에 여유가 있고 구조를 깔끔하게 유지하고 싶을 때	대체로 유리	병렬성 유지, 확장 논리 명확	같은 급의 디스크를 여러 개 준비해야 함
기존 디스크 순차 교체 후 확장	베이 여유가 없고 현재 구조를 유지해야 할 때	구조 유지 측면에서 안정적	기존 풀 레이아웃 유지	리실버 시간이 길고 교체 순서가 중요
서로 다른 특성의 vdev 혼합 추가	임시 증설이 급할 때	예측 어려움	당장 공간 확보 가능	장기 운영, 장애 대응, 체감 성능 모두 애매해질 수 있음

여기서 제 경험상 가장 추천하는 건 "같은 성격으로 확장하기"입니다. 처음 설계를 mirror로 했다면 mirror로, RAIDZ로 했다면 이후 확장 시에도 같은 패턴을 유지하는 쪽이 관리가 편합니다.

pool 아래에 여러 vdev가 있고, 각 vdev 아래에 디스크가 연결되는 구조를 시각적으로 보여주는 이미지가 들어가면 이해가 훨씬 빠릅니다.

실전 1: 새 vdev 추가로 TrueNAS ZFS 확장하기

이 방법은 제가 홈랩에서 가장 선호하는 방식입니다. 이유는 단순합니다. 설계 의도를 망가뜨리지 않고 확장할 수 있거든요. 예를 들어 2디스크 mirror vdev 두 개로 운영 중이었다면, 같은 2디스크 mirror vdev를 하나 더 추가하는 식입니다.

확장 전 확인

먼저 현재 풀 구성을 확인합니다.

zpool status
zpool list
zpool iostat -v 1

zpool status는 현재 풀과 vdev 상태를, zpool list는 용량과 사용률을, zpool iostat -v 1은 vdev별 I/O 흐름을 보는 데 유용합니다. 저는 확장 전에 이 세 개는 거의 습관처럼 확인합니다. 나중에 비교하기 좋거든요.

절차

1. 새 디스크를 장착하고 시스템이 정상 인식하는지 확인합니다.
2. 기존 풀의 vdev 레이아웃과 동일한 방식으로 새 vdev를 구성합니다.
3. TrueNAS GUI 또는 CLI(Command Line Interface, 명령줄 인터페이스)에서 풀에 추가합니다.
4. 추가 직후 I/O 분산과 용량 변화를 확인합니다.

CLI 예시는 아래처럼 볼 수 있습니다. 디바이스 이름은 환경마다 다르니 반드시 직접 확인하셔야 합니다.

zpool add tank mirror /dev/disk/by-id/driveA /dev/disk/by-id/driveB

예시에서 tank는 풀 이름입니다. 이 명령은 새 mirror vdev를 기존 풀에 추가하는 형태입니다. 한 번 추가한 vdev는 쉽게 되돌리기 어렵다는 점, 꼭 기억하셔야 합니다. 제가 예전에 이름 비슷한 디스크를 잘못 보고 진행했다가 식은땀 좀 흘렸습니다 ㅎㅎ

이 방식이 성능 면에서 유리한 이유

새 vdev가 추가되면 풀은 더 많은 vdev에 I/O를 분산할 수 있습니다. 물론 워크로드 특성에 따라 체감은 다르지만, 최소한 구조적으로 병렬 처리 경로를 늘리는 방향이라 논리가 깔끔합니다. 특히 VM 저장소나 작은 파일이 많은 환경에서는 이 차이가 은근히 보이더라고요.

실전 2: 디스크를 하나씩 교체해서 NAS 용량 증설하기

베이(Bay, 디스크 장착 슬롯)가 꽉 찬 경우에는 이 방법이 현실적입니다. 기존 풀 구조는 유지하면서 디스크 용량만 키우는 방식이죠. mirror든 RAIDZ든 많이 쓰는 패턴인데, 핵심은 한 번에 하나씩 교체하고, 각 교체마다 리실버가 완전히 끝날 때까지 기다리는 것입니다.

기본 흐름

1. 현재 상태를 확인합니다.
2. 기존 디스크 하나를 오프라인 처리하거나 교체 절차에 맞춰 분리합니다.
3. 더 큰 디스크로 교체합니다.
4. 리실버 완료를 기다립니다.
5. 다음 디스크로 같은 작업을 반복합니다.
6. 모든 디스크가 교체된 뒤 풀 확장 여부를 확인합니다.

zpool status
zpool offline tank /dev/disk/by-id/old-drive
zpool replace tank /dev/disk/by-id/old-drive /dev/disk/by-id/new-drive
zpool status

실제 명령은 환경과 장치 식별 방식에 따라 달라질 수 있습니다. 그래서 저는 항상 /dev/disk/by-id 경로처럼 상대적으로 식별이 명확한 쪽을 선호합니다. /dev/sdX 같은 이름은 재부팅이나 장치 순서에 따라 헷갈릴 수 있거든요.

자동 확장 확인

디스크를 모두 더 큰 용량으로 바꾼 뒤에도 풀 크기가 바로 기대만큼 안 늘어나는 경우가 있습니다. 이럴 때는 autoexpand(자동 확장) 설정과 풀 상태를 확인해봐야 합니다.

zpool get autoexpand tank
zpool set autoexpand=on tank
zpool online -e tank /dev/disk/by-id/new-drive

처음엔 저도 "왜 디스크는 바뀌었는데 용량이 그대로지?" 싶었는데, 이런 부분에서 한 번씩 막히더라고요. 특히 교체 직후 바로 결과만 보고 판단하면 놓치는 게 있습니다. 리실버가 완전히 끝났는지부터 확인하셔야 합니다.

리실버 진행 상태, 풀 상태, 디스크 교체 흐름을 보여주는 운영 화면 이미지가 있으면 실전 감각이 살아납니다.

TrueNAS GUI에서 볼 때 체크할 포인트

CLI가 제일 명확하긴 하지만, 실제 운영에서는 TrueNAS GUI도 꽤 자주 보게 됩니다. 제가 보통 체크하는 항목은 이 정도입니다.

• Pool 상태: ONLINE인지, DEGRADED인지
• Disk 상태: 새 디스크가 정상 인식됐는지
• 작업 진행률: 리실버가 끝났는지
• Capacity 변화: 예상한 만큼 용량이 반영됐는지
• Alert: SMART 관련 경고나 I/O 오류가 없는지

GUI가 편하긴 한데, 중요한 작업일수록 CLI로 최종 확인하는 습관을 추천드립니다. 화면상으론 정상처럼 보여도 세부 상태는 zpool status 쪽이 더 직설적입니다.

⚠️ 주의사항과 트러블슈팅

여기서부터는 정말 실전 얘기입니다. 이 부분 때문에 삽질 좀 했습니다 ㅎㅎ

1. 디스크 하나만 추가해서 RAIDZ를 키우려는 시도

많이 하는 착각입니다. 기존 RAIDZ vdev가 있다고 해서, 거기에 디스크 하나를 단순 추가하는 방식이 항상 안전하고 익숙한 운영 패턴은 아닙니다. 운영 환경에서는 지원 여부와 절차를 현재 문서로 꼭 재확인하셔야 하고, 검증된 방식은 동일한 새 vdev 추가 또는 순차 교체라고 보시는 게 안전합니다.

2. 크기가 다른 디스크를 섞어 넣는 문제

ZFS는 동작은 하더라도, 실제 활용 가능한 용량과 균형은 가장 작은 축에 맞춰 생각해야 하는 경우가 많습니다. 그리고 확장 계획이 지저분해집니다. 처음엔 급해서 그렇게 넣고 싶어지는데, 나중에 교체 주기 맞출 때 정말 귀찮아집니다.

3. 리실버 중 성능 저하를 무시하는 문제

성능 저하 없이라는 말은 확장 중에도 항상 아무 영향이 없다는 뜻은 아닙니다. 리실버 중에는 읽기/쓰기 지연이 늘 수 있습니다. 그래서 중요한 건 최종 구조가 성능 저하를 만들지 않는 방향이어야 한다는 겁니다. 저는 대용량 복제나 스크럽(scrub, 무결성 검사) 작업과 겹치지 않게 시간대를 따로 잡습니다.

4. 백업 없이 확장 작업부터 들어가는 문제

이건 정말 강조하고 싶습니다. ZFS가 안정적이라고 해도, 확장 작업은 결국 저장장치 구성 변경입니다. 디스크 자체 불량, 케이블 문제, 슬롯 접촉 불량 같은 변수는 늘 있습니다. 백업 없는 확장은 자신감이 아니라 도박에 가깝습니다.

5. 디바이스 이름을 대충 보고 진행하는 문제

/dev/sda, /dev/sdb 같은 이름만 믿고 교체하다가 엉뚱한 디스크를 건드리면 정말 아찔합니다. 가능하면 시리얼 기반 식별 경로를 쓰시고, 작업 전후로 꼭 대조해보세요. 저는 메모장에 디스크 시리얼과 베이 위치를 적어두고 합니다. 이거 진짜 편하더라고요.

검증: 확장 후 무엇을 확인해야 하나

확장이 끝났다고 바로 안심하시면 안 됩니다. 최소한 아래 항목은 체크하시는 게 좋습니다.

1. 풀이 ONLINE 상태인지 확인
2. 예상한 만큼 총 용량이 늘었는지 확인
3. 각 vdev에 I/O가 비정상적으로 쏠리지 않는지 확인
4. 에러 카운터가 증가하지 않는지 확인
5. SMART 상태와 온도를 점검

zpool status -v
zpool list
zpool iostat -v 5
smartctl -a /dev/sdX

zpool iostat -v 5는 5초 단위로 상태를 보기에 좋습니다. 제가 직접 해보니 확장 직후에는 단순히 용량만 보지 말고, 실제로 파일 복사나 백업 작업을 한 번 흘려보내면서 vdev 반응을 같이 보는 게 좋았습니다. 그래야 "늘긴 늘었는데 뭔가 이상하게 굼뜬다" 같은 문제를 빨리 잡을 수 있거든요.

확장 전후의 총 용량, 사용률, I/O 분산 상태를 비교한 대시보드 이미지가 들어가면 결과 섹션의 설득력이 높아집니다.

어떤 확장 전략이 가장 현실적인가

환경별로 정리해보면 이렇습니다.

상황	추천 전략	이유
디스크 베이에 여유가 있음	동일한 새 vdev 추가	구조 확장이 자연스럽고 병렬성 유지에 유리
베이가 꽉 참	디스크 순차 교체	현재 레이아웃을 유지하면서 용량만 키우기 좋음
임시로 공간만 급함	가능하면 정식 확장 전 임시 데이터 정리	무리한 혼합 구성은 장기적으로 손해

혹시 이런 경험 있으신가요? 급하게 공간이 필요해서 손에 잡히는 디스크부터 넣고 싶은 순간이요. 저도 그랬습니다. 그런데 ZFS는 급한 마음으로 건드릴수록 나중에 구조가 발목을 잡는 편이더라고요. 그래서 제 기준에선 "지금 가장 쉬운 방법"보다 "3년 뒤에도 설명 가능한 구조"가 더 중요했습니다.

자주 묻는 질문

Q1. 디스크 추가만 하면 자동으로 성능도 같이 좋아지나요?

항상 그렇진 않습니다. 어떤 형태의 vdev를 추가했는지, 워크로드가 순차 읽기 위주인지, 랜덤 I/O 위주인지에 따라 다릅니다. 다만 동일한 성격의 vdev를 추가하는 방식은 구조적으로 예측 가능성이 높습니다.

Q2. NAS 용량 증설 시 제일 먼저 볼 명령은 뭔가요?

저는 zpool status부터 봅니다. 상태를 모르고 작업하는 건 위험합니다. 그다음 zpool list, 필요하면 zpool iostat -v를 봅니다.

Q3. ZFS 성능을 위해 SSD 캐시만 추가하면 해결되나요?

캐시 장치는 특정 워크로드에서 도움이 될 수 있지만, 기본 풀 구조가 좋지 않으면 근본 해결은 아닙니다. 먼저 풀 레이아웃과 vdev 구성을 정리하는 게 우선입니다. 캐시는 그 다음입니다.

정리: TrueNAS ZFS 확장은 구조를 지키는 쪽이 결국 이깁니다

오늘 정리한 내용을 한 줄로 줄이면 이렇습니다. TrueNAS ZFS 확장은 단순히 디스크 추가가 아니라, vdev 구조를 어떻게 유지하느냐의 문제입니다. 성능 저하 없이 가고 싶다면 검증된 방식으로 접근하시는 게 맞습니다. 즉, 베이에 여유가 있으면 동일한 새 vdev를 추가하고, 여유가 없으면 기존 디스크를 하나씩 더 큰 용량으로 교체하는 쪽이 가장 현실적입니다.

저도 처음엔 용량만 보면 되는 줄 알았는데, 실제로 써보니까 결국 중요한 건 장기 운영의 일관성이었습니다. ZFS 성능, 장애 대응, 다음 증설 계획까지 생각하면 설계를 흐트러뜨리지 않는 게 제일 낫더라고요. 다음 글에서는 스크럽 주기, SMART 모니터링, 백업 전략까지 묶어서 홈랩 NAS 운영 체크리스트로 정리해보겠습니다. 이전 글에서 다뤘던 스토리지 모니터링 내용과 같이 보시면 더 도움이 되실 겁니다.

추천 확장 방식, 피해야 할 방식, 점검 명령어를 한 장으로 정리한 요약 인포그래픽 이미지가 마무리용으로 잘 어울립니다.

📚 함께 읽으면 좋은 글

• Immich NAS 성능 벤치마크와 최적화
• Cloudflare NAS 원격 접속: Tunnel 연결 오류 디버깅 완벽 가이드
• Jellyfin 트랜스코딩 성능 벤치마크: N100 미니PC vs Ryzen 5700G NAS
• TrueNAS 파일 시스템 성능 비교: ZFS, Btrfs, ext4 실측 벤치마크
• ZFS vs Btrfs 비교: Proxmox 홈랩에서의 실측 성능과 데이터 무결성 분석