하나의 미니 PC가 미디어 라이브러리를 소유하고 시작, 권한 및 네트워크 종속성을 최소화하려면 직접 연결된 스토리지에 로컬 마운트를 사용하세요. 미디어 파일을 독립적인 NAS 또는 파일 서버에 두어야 하거나, 여러 시스템에서 공유해야 하거나, 미니 PC를 재구축하거나 교체한 후에도 그대로 유지해야 한다면 SMB 공유를 사용하세요. 대부분의 홈 미디어 서버에서 결정적인 요소는 SMB가 영화를 충분히 빠르게 스트리밍할 수 있는지가 아니라 스토리지 소유권과 복구입니다.
여기서 “로컬 마운트”는 내부 SATA/NVMe 또는 USB 인클로저처럼 미니 PC에 직접 연결된 스토리지의 파일 시스템을 의미합니다. SMB 공유는 미디어가 다른 컴퓨터에 남아 있고, 미디어 애플리케이션이 미디어를 읽기 전에 미니 PC의 운영 체제에 마운트되는 방식을 의미합니다. 서버가 Docker에서 실행된다면 해당 호스트 마운트를 컨테이너에 바인드 마운트할 수 있습니다.
스토리지 소유자가 프로토콜보다 더 많은 것을 결정합니다
로컬 마운트를 사용하면 미니 PC가 컴퓨팅 소유자이자 스토리지 경로 소유자가 됩니다. 서버가 부팅되고 디스크가 정상이라면 다른 호스트, DNS 레코드, 자격 증명 교환 또는 네트워크 경로를 기다리지 않고도 일반적으로 미디어 경로를 바로 사용할 수 있습니다. 이는 단일 장치로 구성된 미디어 시스템에 매력적인 방식입니다.
SMB 공유에서는 파일 소유권이 별도의 NAS 또는 파일 서버에 있습니다. Jellyfin의 스토리지 지침에 따르면 Samba 또는 NFS 스토리지는 운영 체제에 마운트해야 하며, 데이터베이스는 로컬에 유지해야 합니다. 이러한 분리는 유용한 아키텍처 경계를 제공합니다. 애플리케이션 데이터베이스까지 원격으로 만들지 않고도 미디어를 원격에 둘 수 있습니다.
따라서 선택은 복구에 관한 질문에서 시작합니다. 미니 PC를 교체해도 미디어 라이브러리가 그대로 유지되고 다른 호스트에서 즉시 다시 사용할 수 있어야 한다면 SMB가 유리합니다. 미니 PC와 해당 드라이브를 복구 가능한 하나의 장치로 의도적으로 구성했다면, 실제로 필요한 요구 사항을 포기하지 않으면서 로컬 스토리지를 사용해 종속성을 줄일 수 있습니다.
| 결정 기준 | SMB 공유 | 로컬 마운트 |
|---|---|---|
| 스토리지 소유자 | 독립형 NAS 또는 파일 서버 | 미니 PC 자체 |
| 시작 종속성 | 네트워크, 원격 서버, 자격 증명, 마운트 | 로컬 디스크 및 파일 시스템 |
| 여러 기기에서 공유 | 로컬의 강점 | 미니 PC에서 데이터를 다시 공유해야 함 |
| 권한 모델 | 파일 시스템과 SMB ID/ACL 계층 | 로컬 UID/GID 또는 파일 시스템 ACL |
| 호스트 교체 | 미디어는 스토리지 서버에 계속 보관됨 | 저장소를 호스트와 함께 이동하거나 호스트에서 분리해야 함 |
| 적합한 경우 | 독립적인 공유 라이브러리 | 단일 호스트용 간단한 미디어 어플라이언스 |
로컬 저장소는 시작 시 필요한 종속성을 하나 줄입니다
직접 연결된 디스크는 일반적으로 호스트의 로컬 파일 시스템 시퀀스에 포함되어 사용할 수 있습니다. 미디어 서버는 해당 파일 시스템이 마운트된 후 시작할 수 있으며, 컨테이너에는 동일한 안정적인 호스트 경로를 제공할 수 있습니다. NAS가 재부팅하거나 네트워크가 늦게 연결되어 사라지는 원격 공유도 없습니다.
systemd는 네트워크 마운트와 로컬 파일 시스템을 구분하고 네트워크 마운트 유닛을 원격 파일 시스템 대상에 맞춰 정렬합니다. 이 차이는 상시 실행되는 미디어 서버에서 중요합니다. 원격 파일 시스템을 실제로 사용할 수 있게 되기 전에 애플리케이션이 예상 라이브러리 경로를 검색해서는 안 되기 때문입니다.
로컬 저장소가 자동으로 더 안전한 것은 아닙니다. 헐거운 USB 인클로저, 고장 난 SATA 케이블, 가득 찬 디스크 또는 손상된 파일 시스템은 네트워크 장애만큼이나 효과적으로 라이브러리에 접근하지 못하게 만들 수 있습니다. 로컬 저장소의 장점은 스토리지 장애에 면역이라는 것이 아니라, 접근 경로에 포함된 구성 요소가 적다는 점입니다.
SMB는 라이브러리를 미니 PC와 독립시킵니다
미디어 저장소가 현재 컴퓨팅 장치를 넘어 계속 사용될 경우 SMB가 가장 강력한 선택입니다. NAS는 디스크를 물리적으로 이동하지 않고도 Jellyfin 서버, 파일 관리를 위한 데스크톱, 백업 프로세스, 다른 미디어 호스트에 동일한 라이브러리를 제공할 수 있습니다. 미니 PC를 재구축할 때도 데이터 마이그레이션이 아니라 컴퓨팅 환경 복구 작업으로 처리할 수 있습니다.
Docker 바인드 마운트는 호스트 경로를 컨테이너 내부에 노출하므로, 호스트에 마운트된 공유 폴더를 다른 파일 시스템 경로처럼 미디어 컨테이너에 제공할 수 있습니다. Docker의 바인드 마운트 모델은 읽기 전용 마운트도 지원합니다. 미디어 서버가 라이브러리 파일을 읽기만 하고 원본을 수정해서는 안 될 때 유용합니다.
숨은 조건은 가용성입니다. Jellyfin은 작업이 실행되는 동안 미디어 스토리지를 사용할 수 없으면 예약된 유지 관리가 라이브러리 항목을 제거할 수 있다고 경고합니다. 따라서 네트워크 공유에는 안정적인 마운트 순서와 장애 처리가 필요합니다. 시작 스크립트에 SMB 경로를 단순히 추가하는 것만으로는 종속성을 안정적으로 구성한 것과 같지 않습니다.
로컬에서는 더 단순하지만 SMB에서는 더 명시적인 권한
로컬 스토리지는 일반적으로 미디어 서버 호스트에서 확인할 수 있는 권한 계층이 하나뿐입니다. 즉 파일 시스템의 소유권, 모드 비트 또는 ACL입니다. 컨테이너에서는 여전히 UID/GID 매핑 문제가 발생할 수 있지만, 운영자는 원격 공유의 사용자 ID와 접근 정책까지 동시에 디버깅할 필요는 없습니다.
TrueNAS는 SMB에 대해 공유 수준 ACL과 파일 시스템 ACL을 별도로 관리하는 방법을 설명합니다. 현재 제공되는 SMB 공유 및 ACL 관리 지침은 원격 경로가 더 명시적일 수 있지만 계층도 더 많다는 점을 보여줍니다. 미디어 호스트가 자체 로컬 프로세스 권한을 적용하기 전에 스토리지 서버가 어떤 계정에 공유 데이터셋 탐색, 읽기 또는 수정 권한을 부여할지 결정하기 때문입니다.
여러 장치에 서로 다른 권한이 필요할 때는 이 추가 계층이 유용합니다. 하지만 신뢰할 수 있는 미디어 프로세스 하나만 사용하는 경우에는 오버헤드가 됩니다. 권한 문제가 스캔 오류나 root 소유 파일의 반복적인 원인이라면 원격 스토리지를 확장성 향상 수단으로 보기 전에 인증 및 권한 경로를 단순화하세요.
스캔과 스트리밍은 경로의 서로 다른 부분에 부하를 줍니다
영화 재생은 대부분 순차적으로 진행되며 정상적인 기가비트 링크의 일부 대역폭만 사용할 수 있습니다. 따라서 네트워크와 스토리지 서버에 여유가 있다면 SMB 공유로 미디어를 매우 원활하게 스트리밍할 수 있습니다. 반면 라이브러리 스캔은 많은 메타데이터 조회, 디렉터리 작업, 아트워크 읽기, 소규모 파일 액세스를 수행할 수 있어 지연 시간이 더 크게 드러납니다.
Linux CIFS 클라이언트 문서는 SMB 공유를 Linux 파일 시스템에 마운트하는 데 사용되는 커널 클라이언트를 설명합니다. 마운트가 완료되면 미디어 애플리케이션은 여전히 파일 시스템 경로를 인식하지만, 캐시에 없는 각 작업은 네트워크를 거치며 원격 서버의 응답에 의존할 수 있습니다.
스캔이 느리다고 해서 SMB가 근본적으로 잘못된 방식이라고 단정하지 마세요. 실제 네트워크에서 동일한 라이브러리를 비교하고, NAS 디스크 지연 시간과 링크 사용률을 확인하며, 썸네일, 메타데이터 데이터베이스 또는 트랜스코딩 캐시가 실수로 원격에 배치되지 않았는지 점검하세요. 애플리케이션이 원격 배치를 명시적으로 지원하지 않는 한 애플리케이션 데이터베이스와 변경이 잦은 캐시 데이터는 로컬에 유지하세요.
복구가 단순성의 승자를 뒤집을 수 있습니다
로컬 스토리지는 정상 운영 중에는 더 단순하지만 미디어와 컴퓨팅 환경의 복구를 서로 묶을 수 있습니다. 미니 PC가 고장 나고 라이브러리가 내부 드라이브에 있다면 재생을 재개하기 전에 해당 드라이브를 옮기고, 마운트를 다시 만들거나, 백업에서 복원해야 할 수 있습니다.
SMB 라이브러리는 데이터 경로가 이미 다른 곳에 존재하므로 컴퓨팅 환경 복구를 더 빠르게 만들 수 있습니다. 교체 호스트에 미디어 애플리케이션을 설치하고 구성을 복원한 다음, 동일한 마운트 지점을 다시 만들고 기존 공유에 연결하면 됩니다. 인접한 DAS와 NAS 스토리지 비교에서는 더 넓은 소유권 차이를 다룹니다. 미니 PC 미디어 서버에서는 이러한 차이가 구체적인 복구 종속성으로 나타납니다.
따라서 선택이 뒤집히는 조건은 분명합니다. 독립적인 복구보다 단일 장치의 단순성이 중요하다면 로컬 방식이 우세합니다. 라이브러리가 특정 미디어 서버 호스트 하나보다 오래 유지되어야 하거나 여러 시스템에서 사용되어야 한다면, SMB라는 추가 종속성이 전체 복구 작업을 늘리기는커녕 줄일 수 있습니다.
라이브러리의 수명 주기에 따라 마운트 모델을 선택하세요
미니 PC가 의도적으로 스토리지 장치 역할을 하고 드라이브를 쉽게 백업할 수 있으며 부팅부터 재생까지 가장 짧은 경로를 원한다면, 소규모 단일 호스트 라이브러리에 로컬 마운트를 선택하세요. 항상 켜져 있는 NAS에 의존할 수 없는 휴대용 또는 단순한 구성에도 적합합니다.
NAS가 이미 미디어를 관리하고 여러 시스템에서 파일에 액세스해야 하거나, 스토리지 용량을 컴퓨팅과 독립적으로 확장하거나, 라이브러리를 이동하지 않고 미디어 서버 하드웨어를 교체하려는 경우 SMB를 선택하세요. 마운트를 부팅의 핵심 종속 항목으로 설정하고 애플리케이션 데이터베이스와 트랜스코딩 캐시는 로컬 스토리지에 유지하세요.
합성 처리량 수치만으로 둘 중 하나를 선택하지 마세요. 두 경로 모두 필요한 비트레이트를 제공할 수 있다면, 더 나은 설계는 라이브러리가 실제로 운영되는 방식에 맞는 권한, 마운트 가용성, 복구 동작을 갖춘 쪽입니다.
제품 비교
더 읽어보기

Plex에 Docker와 가상 머신 중 어떤 배포 방식이 적합할까요?
공유된 운영 요구 사항을 기반으로 Docker, 가상 머신 또는 VM 내부의 Docker에 적용할 수 있는 조건부 Plex 배포 판단입니다.

Plex용 8GB vs 16GB vs 32GB RAM: 어떤 등급이 작업량에 맞을까요?
가벼운 Plex에는 8GB, 적당한 규모의 공유 앱에는 16GB, VM과 제한된 RAM 작업 공간에는 32GB를 선택하세요. 단, 측정 결과로 필요성이 입증된 경우에만 선택해야 합니다.

전용 하드웨어 가속이 Plex에 유의미한 이점을 제공할까요?
지원되는 반복 트랜스코딩에서는 하드웨어 가속이 유리하며, 직접 재생이나 드문 변환, 지원되지 않는 단계에서는 CPU만 사용하는 방식도 여전히 유효합니다.

