안녕하세요. 2011년 부터 데이터에 집착해온 아카이빙 덕후입니다. 15년 동안 기성품 NAS(시놀로지, 큐냅, WD)와 DAS를 거치며 산전수전 다 겪고, 드디어 인생 NAS를 완성해서 그 여정을 공유해 봅니다.
1. 나의 NAS 연대기
2011년: 첫 아이피타임 2베이 NAS 입문 (2TB)
2013년: 아마존 EX4 대란 (WD Red 2TB 4개 포함 $750) - 10년 무사고 사용
2023년: EX4 단종 및 디스크 에러로 10년 치 자료 대부분 유실 (홧병...)
2023~24년: 시놀로지 918+ → 큐냅 464TA로 기성품 끝판왕 도전
현재: N100 + OMV(OpenMediaVault) + MergerFS + SnapRAID 정착
2. 왜 기성품을 버리고 DIY로 왔는가?
시놀로지(918+): GUI는 예술이지만, NVMe를 캐시로만 가둬두고 전용 하드만 고집하는 '폐쇄적인 애플식 생태계'에 질렸습니다. 확장을 위해선 본체값에 맞먹는 유닛을 또 사야 했죠.
큐냅(464TA): 성능은 압도적이고 NVMe OS 설치까지 지원해줬지만, OS의 섬세함은 시놀로지에 한참 못 미쳤습니다. 늘 SSH로 들어가서 직접 만져줘야 했죠.
중국산 DAS: "가성비 확장"이라 믿었지만 S.M.A.R.T 검사조차 제대로 안 되는 '디스크 부패의 온상'이었습니다. 자료 다 날리기 직전에 구사일생으로 탈출했습니다.
3. 깨달음의 시대: 왜 자작 NAS인가? (N100 + OMV)
결국 "내가 원하는 확장성과 안정성"은 내가 직접 만드는 길뿐이었습니다.
CPU (N100): 시놀로지의 R1600이나 큐냅의 N5095보다 연산 성능은 1.7배 높은데, TDP는 6W라는 미친 전성비를 보여줍니다.
케이스: 프랙탈 디자인 Define 7 XL. 현재 14베이를 채웠고, 내부에 8베이가 더 남았습니다. 평생 업그레이드할 일 없는 케이스죠.
OS: OMV(Debian 기반). GUI는 대시보드 수준이고, 시놀로지보다 투박해도 리눅스의 자유도가 모든 걸 상쇄합니다.
4. DIY 나스의 끝판왕이라고 불리는 ZFS를 버린 이유
처음엔 저도 당연히 ZFS(TrueNAS)가 정답인 줄 알았습니다. 하지만 100TB가 넘어가는 개인 아카이브 환경에서 ZFS는 너무나 가혹한 운영료를 요구하더군요.
[공포의 RAM 세금]: ZFS는 1TB당 1GB RAM을 권장합니다. 196TB를 돌리려면 RAM만 128GB 이상이 필요했고, 이는 저전력 N100을 포기해야 한다는 뜻이었습니다.
[융통성 제로의 확장성]: 하드 하나 추가할 때마다 기존 풀(Pool)을 엎거나 똑같은 개수의 하드를 추가해야 하는 구조는 개인에게 너무 비효율적입니다.
[전기료 폭탄]: 파일 1개만 읽으려 해도 14개의 하드가 동시에 스핀업되는 소음과 전력을 감당할 자신이 없었습니다.
결론: 금융권이나 기업용에서 1비트 단위의 corrupt도 용서하지 않는 결벽증수준의 데이터 무결성을 필요로 하는 시스템은 제 개인 아카이빙 NAS에는 맞지 않았습니다.
5. 제가 원하는건
1개의 단일 디스크풀 유지
언제든 디스크 풀을 유지하면서 디스크를 추가, 제거할 수 있는 유연성
한두개 디스크가 불량나더라도 최소 Raid 5수준의 데이터 복구 능력
이 모든걸 자동으로 주기적 점검하고 레포트를 보내줄 수 있는 시스템
저전력 유지 (24시간 돌아가는 DIY NAS이기 때문에 브랜드 기성품에 뒤쳐지면 안됨)
6. SnapRAID, "안정성이 낮다"는 편견을 깨다
많은 분이 ZFS의 실시간 무결성 검사 때문에 SnapRAID가 불안하지 않냐고 묻습니다. 하지만 공부해보니 SnapRAID는 아카이빙 환경에서 ZFS보다 더 끈질긴 생명력을 가졌더군요.
[Bit Rot(데이터 부패) 완벽 방지]: ZFS의 전유물로 알려진 체크섬(Checksum) 검사, SnapRAID도 똑같이 수행합니다. 파일 하나하나 지문을 대조해 미세하게 깨진 데이터(Silent Corruption)를 찾아내고 패리티로 완벽히 복구해냅니다.
[공포의 '풀 깨짐'으로부터 해방]: ZFS는 패리티 허용치를 넘는 하드가 고장 나면 전체 데이터가 증발합니다. 하지만 SnapRAID는 설령 3~4개가 동시에 죽더라도, 살아남은 나머지 하드의 데이터는 100% 보존됩니다. 152TB라는 거대 용량에서 이 차이는 심리적으로 엄청난 안정감을 줍니다.
[실수의 복구]: 실시간 RAID는 파일을 실수로 지우면 즉시 패리티에서도 사라집니다. 하지만 SnapRAID는 '동기화(Sync)' 전까지는 패리티에 이전 정보가 남아 있어, 삭제한 파일도 복구해낼 수 있는 '타임머신' 같은 방어력을 보여줍니다.
7. 현재 시스템(N100 + OMV)이 '압도적'인 이유
최강의 전성비: 팬 8개를 풀가동하고도 아이들 30W. 쿨링팬 전력을 빼면 기성품보다 적게 먹는 괴물 효율입니다.
개별 디스크 구동: 영화 볼 때 하드 1개만 돌고 13개는 잡니다. 소음과 하드 수명에서 비교 불가입니다.
무한 확장성: 5년 뒤 30TB 하드가 나와도 그냥 꽂으면 끝입니다. 파일시스템(XFS)의 유연함은 ZFS가 죽어도 못 따라오는 영역이죠.
8. AI가 완성한 관리 시스템
리눅스 명령어 하나 몰라도 괜찮습니다. AI의 도움으로 매일 아침 디스코드로 시스템 점검 리포트를 받고, 업무 자동화(n8n)와 24시간 돌아가는 Win11 VM까지 올린 완벽한 서버를 구축했습니다. 이제 더 이상 신제품 NAS 소식에 가슴이 뛰지 않습니다. 기성품 그 어떤 모델도 제 DIY 시스템보다 나을 리 없다는 확신이 들었거든요.
마치며... 15년 만에 비로소 새로운 NAS에 대한 갈망으로부터 졸업했습니다. 혹시 시놀로지/큐냅의 베이 확장에 현타 오신 분들, 혹은 데이터 안정성 때문에 고민 중인 분들 댓글 남겨주세요. 제가 겪은 삽질 노하우, 기꺼이 공유하겠습니다!
현재는 WTR PRO N100 시스템에 SATA 4베이, NVMe 1개, 단일 32GB 램 구성으로 Proxmox VE(PVE)를 운영 중입니다. 기회도면 OMV로 전환도 고려해봐야겠네요.
PVE에서는 주로 LXC 컨테이너(PVE 유기적 관계)와 VM 2개(헤놀로지, PBS)를 운영합니다. VM은 격리된 시스템으로, 헤놀로지에는 SATA PCIe 패스스루로 대용량 HDD 1개를 연결하고, 나머지는 SATA SSD로 단일 볼륨을 구성했습니다.
PVE 호스트에는 1TB NVMe가 있으며, LXC 컨테이너 백업은 PBS로 자동 백업됩니다(헤놀 NFS 마운트 활용). Ubuntu LXC에 Docker+Portainer를 설치해 Vaultwarden, Joplin, ArchiveBox(저장소는 헤놀 SMB 마운트), AdGuard Home, 고카이(헤놀), 이미치(헤놀 포토 마운트), Plex, Jellyfin(헤놀 SMB) 등 다양한 서비스를 운용 중입니다.
다만, N100 CPU의 성능이 부족해 CPU 사용률이 자주 100%에 도달하는 점이 아쉽습니다.
인텔 arc a380 외장글카 인코딩 디코딩용으로 좋습니다
4k영상 AV1로 재인코딩 시 50프로 절감 합니다 저전력이라 끝판왕이죠 ㅎ
구슬님, N100으로 정말 다양한 가상화 환경을 구축하셨네요! PVE 위에서 헤놀로지, PBS, Ubuntu LXC까지 돌리시는 걸 보니 상당한 내공이 느껴집니다.
다만, N100 CPU가 자주 100%를 친다고 아쉬워하셨는데, 이건 N100의 성능이 부족해서가 아니라 가상화 구조의 병목(Overhead) 과 트랜스코딩 설정에서 CPU가 불필요한 헛고생을 하고 있을 확률이 매우 높습니다. 현재 설계에서 성능을 100% 제대로 뽑아내기 위한 두 가지 방향을 제안해 드립니다.
1. 가상화 유지 시: '내부 네트워크 세금' 제거 및 내장 그래픽 활성화
현재 Proxmox(PVE)의 장점을 포기하기 힘드시다면, 내부 데이터 흐름과 하드웨어 가속(QSV) 설정을 완전히 뜯어고치셔야 합니다.
헤놀로지 SMB 마운트의 함정: 현재 헤놀로지(VM)에서 하드를 관리하고, 그걸 다시 Ubuntu LXC로 SMB 연결을 해서 Plex/Jellyfin을 돌리고 계십니다. 이 구조는 N100 입장에서는 데이터를 내부 가상 스위치로 계속 패킷을 싸고 푸는 엄청난 '네트워크 연산'을 강요합니다. 여기서 CPU 자원이 다 갉아먹힙니다.
해결책 (바인드 마운트): 중간 관리자인 헤놀로지를 빼버리고, Proxmox 호스트(PVE)에 디스크를 직접 마운트하세요. 그리고 Ubuntu LXC에 네트워크 통신(SMB)이 아닌, 디렉토리를 직접 꽂아주는 '바인드 마운트(Bind Mount)' 방식을 쓰셔야 I/O 오버헤드가 사라지고 CPU가 쉴 수 있습니다.
Arc A380 외장 글카 추가에 대하여: 4K AV1 재인코딩을 위해 외장 글카를 달겠다고 하셨는데, N100의 내장 그래픽(UHD 24EU)은 이미 AV1 디코딩을 완벽하게 지원합니다. 만약 Plex에서 CPU가 100%를 친다면, LXC 컨테이너로 내장 그래픽 패스스루(Passthrough)가 제대로 안 되어서 깡으로 소프트웨어 인코딩을 돌리고 있을 확률이 99%입니다. 외장 글카에 돈과 전력을 쓰기 전에, 내장 그래픽 패스스루만 완벽히 잡아주시면 N100 혼자서도 쾌적하게 트랜스코딩을 해냅니다.
2. 궁극적인 최적화: 가상화를 버리고 '베어메탈(OMV)'로 직결
가장 추천해 드리고 싶은 방법이자, 제가 14베이를 N100으로 쾌적하게 굴리는 비결입니다. 애초에 N100은 복잡한 하이퍼바이저(Proxmox)를 겹겹이 돌리기엔 체급이 작은 '초저전력 칩셋'입니다.
OS 직결 (베어메탈): Proxmox라는 껍데기를 아예 벗어던지고, 기계 위에 OMV(OpenMediaVault)나 Debian을 직접 설치하는 겁니다.
구조의 단순화: 구슬님이 돌리시는 Vaultwarden, AdGuard, Plex 등은 가상 머신이나 LXC로 쪼갤 필요 없이, OMV 위에 Docker(도커)로 한 번에 올리면 끝납니다.
압도적인 성능 향상: 가상화 오버헤드가 '0'이 되므로 디스크 I/O가 100% 다이렉트로 나옵니다. 내장 그래픽(QuickSync)도 복잡한 패스스루 설정 없이 도커에 바로 매핑되니, CPU 점유율은 바닥을 치고 아이들 전력 소모도 극적으로 낮아질 겁니다.
결론적으로: N100은 짐을 많이 싣는 트럭(제온)이 아니라 연비가 미친 경차입니다. 짐칸(가상화 OS)을 무겁게 짜면 당연히 엔진이 비명을 지릅니다. 구조를 단순화해서 직통으로 연결해 주면, 굳이 외장 글카를 안 달아도 펄펄 날아다니는 N100을 보실 수 있을 겁니다! 한번 세팅을 다이어트해 보시는 걸 강력히 권해드립니다.
Arc A380 외장 그래픽카드를 언급한 이유는 ASUS P11C-M/4L 메인보드(i3-8100 탑재)에 설치할지를 고민하고 있어서입니다.
PVE=PBS 장점을 가지고있어서 버리기 힘들어요 원클릭으로 복구 가능합니다
이미 iGPU 패스스루는 완벽하게 잡혀 있는 상태고, 트랜스코딩 부하 문제도 아니라고 하시니 상황이 명확해지네요. 그렇다면 말씀하신 대로 다수의 Docker 컨테이너 운용에 따른 CPU 스케줄링 영향이 핵심인 것 같습니다. N100이 전성비는 깡패지만 4C4T 구조다 보니, 동시에 여러 서비스가 교차할 때 CFS 스케줄러가 바빠지며 점유율이 튀는 건 플랫폼의 어쩔 수 없는 숙명 같기도 합니다.
PVE + PBS 구조를 유지하시는 이유도 충분히 공감됩니다. 서비스 격리와 원클릭 복구가 주는 심리적 안정감은 OMV 단일 구조가 주지 못하는 큰 장점이죠. 결국 데이터 저장의 순수성을 중시하느냐, 관리의 유연성을 중시하느냐의 설계 철학 차이이지 정답이 하나는 아닌 것 같습니다.
Arc A380을 i3-8100 쪽에 붙여 워크로드를 분산하겠다는 계획도 아주 합리적인 판단으로 보입니다. i3 플랫폼의 안정성과 PCIe 확장성을 활용하면 지금보다 훨씬 균형 잡힌 시스템이 될 것 같네요.
결국 N100은 저전력 최적화라는 명확한 타겟이 있는 플랫폼이고, 구슬님처럼 홈랩 성격이 강해질수록 튜닝의 묘미가 더 커지는 것 같습니다. 좋은 사례와 깊이 있는 기술 공유 정말 감사드립니다. 즐거운 나스 생활 되세요!
라즈베리파이 기반으로 쓰고 있어서 ICC 안되는게 아쉽긴 했거든요 ㅜㅜ
조금 더 시간적 여유 있으면 도전 해보고 싶지만, 글만 읽어도 대리 체험한 것 같네요. :)