SMB 대 NFS: 집에서 어떤 파일 공유 방식을 사용해야 할까요?

가정 네트워크에 Windows PC, Mac, 휴대폰, 태블릿, 미디어 플레이어가 포함되어 있다면 SMB가 보통 더 나은 기본값입니다. 데스크톱 파일 탐색기와 자연스럽게 통합되고 사용자 기반 로그인 지원하며 소비자용 애플리케이션에서 널리 사용됩니다.

NFS는 클라이언트가 주로 Linux 서버, Proxmox 호스트 또는 저장소를 관리형 인프라 작업 흐름의 일부로 마운트하는 다른 Unix 계열 시스템일 때 더 매력적입니다. UID/GID 값, 내보내기 규칙, 마운트 동작, 파일 소유권이 올바르게 계획될 때 효율적이고 예측 가능합니다.

벤치마크가 아니라 클라이언트를 중심으로 프로토콜을 선택하세요

SMB와 NFS는 모두 NAS 또는 홈 서버에 저장된 파일을 열 수 있게 하지만, 서로 다른 생태계를 기반으로 설계되었습니다. SMB는 Windows에 네이티브이며 macOS, Linux, 모바일 파일 관리자, 스마트 TV, 미디어 애플리케이션에서 널리 지원됩니다. NFS는 Linux 및 Unix 마운트 작업 흐름에 더 자연스럽게 맞습니다.

이 구분은 한 프로토콜이 더 빠르다는 일반적인 주장보다 더 중요합니다. Windows 노트북은 SMB 클라이언트 스택이 SMB를 중심으로 구축되어 있어 더 부드럽고 빠른 경험을 할 수 있습니다. 수천 개의 파일을 처리하는 Linux 서버는 원격 디렉터리가 일반 Unix 마운트처럼 동작하기 때문에 NFS로 관리하는 것이 더 쉬울 수 있습니다.

공유에 접근할 기기와 그 기기들이 수행할 작업을 먼저 나열하세요. 사람의 파일 탐색, 기계 간 저장, 미디어 스트리밍, 백업, 가상화, 컨테이너 데이터는 항상 같은 프로토콜을 필요로 하지 않습니다.

SMB는 보통 혼합된 가정 환경에서 더 쉬운 기본 옵션입니다

SMB는 일반적으로 Windows 파일 탐색기, macOS 파인더, 휴대폰 또는 미디어 플레이어 애플리케이션에서 사용자가 수동으로 폴더를 열 때 가장 간단한 옵션입니다. 사용자는 NAS 사용자 이름과 비밀번호로 연결할 수 있으며, 모든 클라이언트에서 숫자형 Linux ID를 관리할 필요가 없습니다.

최신 SMB 버전은 기본 파일 전송을 넘어 사용자 및 그룹 ACL, 서명, 암호화, 파일 잠금, 캐싱, 다중 채널 기능 등 다양한 기능을 제공합니다. 이러한 기능들은 복잡성을 더하지만, 여러 가구 구성원이 서로 다른 접근 권한이 필요할 때 유용합니다.

Windows, macOS, Linux가 혼합된 네트워크의 경우, 최신 SMB 3.x는 더 넓은 클라이언트 호환성을 유지하면서 성능 격차를 크게 줄일 수 있습니다. 이는 문서, 가족 사진, 공유 다운로드 및 일반 NAS 탐색에 SMB가 실용적인 출발점임을 의미합니다.

NFS는 관리되는 리눅스 워크플로우에 더 자연스럽게 맞습니다

NFS는 클라이언트가 폴더를 탐색하는 사람이 아닌 리눅스 서버일 때 통합이 더 쉽습니다. 공유는 시작 시 고정 디렉터리에 마운트되어 백업 소프트웨어, 미디어 서비스, 가상화 호스트 또는 기타 시스템 프로세스에서 사용할 수 있습니다.

하나의 관리자가 NAS와 클라이언트를 모두 제어할 때 잘 작동합니다. 허용된 서브넷을 정의하고, 사용자 및 그룹을 정렬하며, 마운트 옵션을 선택하고, 네트워크 공유가 사용 가능해진 후에만 서비스가 시작되도록 할 수 있습니다.

Windows 노트북, 모바일 애플리케이션 또는 여러 가정 사용자가 직접 접근해야 할 때 NFS는 덜 편리해집니다. 크로스 플랫폼 NFS 클라이언트가 존재하지만, 설정과 신원 매핑은 보통 해당 장치에서 SMB를 사용하는 것보다 덜 직관적입니다.

SMB와 NFS는 서로 다른 접근 모델을 사용합니다

SMB는 보통 서버 계정으로 접근을 제공합니다. 사용자는 자격 증명으로 연결하고, NAS는 해당 신원과 연관된 공유 권한, 그룹 및 파일 시스템 ACL을 평가합니다.

일반적인 가정용 NFS 구성은 다르게 작동합니다. 내보내기는 종종 선택된 호스트나 서브넷으로 제한되며, 파일 접근은 클라이언트가 보내는 숫자형 유닉스 UID 및 GID 값에 따라 달라집니다. NFSv4는 더 고급 신원 및 Kerberos 구성을 사용할 수 있지만, 많은 가정 환경은 여전히 신뢰된 클라이언트 네트워크와 숫자 소유권에 의존합니다.

실질적인 차이점은 SMB는 일반적으로 사용자 및 그룹 ACL을 사용하는 반면, NFS 접근은 호스트 규칙과 리눅스 UID/GID 소유권에 밀접하게 연결되어 있습니다. 어느 모델이 자동으로 더 우수한 것은 아니지만, 각각 다른 문제 해결 과제를 만듭니다.

UID 및 GID 계획이 주요 NFS 학습 곡선입니다

리눅스 사용자 이름은 단지 읽을 수 있는 라벨일 뿐입니다. 파일 시스템은 궁극적으로 숫자 사용자 및 그룹 ID를 기록합니다. 두 대의 머신 모두 같은 이름의 사용자가 있을 수 있지만 미디어하지만 한쪽은 UID 1000을 사용하고 다른 쪽은 UID 1001을 사용하면 서로 다른 신원입니다.

이것이 NFS 공유가 성공적으로 마운트되었지만 파일 생성이 실패하는 이유입니다. 네트워크 경로와 내보내기는 작동하지만 클라이언트가 제시하는 사용자가 NAS의 소유자, 그룹 또는 ACL과 일치하지 않습니다.

여러 리눅스 시스템에서 NFS를 사용하기 전에 클라이언트와 서버에서 id username 결과를 비교하세요. 쓰기 가능한 NFS 공유에 필요한 숫자 UID 및 GID 정렬은 사용자가 디렉터리에 들어갈 수 있지만 파일을 생성할 수 없을 때 종종 누락된 단계입니다.

Root Squash는 무작위 권한 실패가 아닙니다

NFS 내보내기는 일반적으로 클라이언트 머신의 루트 사용자가 NAS에서 자동으로 루트가 되는 것을 방지하기 위해 root squashing을 사용합니다. 원격 UID 0에서 오는 요청은 권한이 낮은 익명 신원으로 매핑됩니다.

이것은 백업 스크립트, 컨테이너 또는 루트 권한으로 실행되는 관리 복사 명령을 사용하는 사용자에게 놀라움을 줄 수 있습니다. 공유는 마운트되지만 쓰기가 실패하거나 파일이 익명 사용자 아래에 나타납니다.

하나의 작업 흐름이 차단된다고 해서 root squashing을 비활성화하지 마세요. 먼저 어떤 비루트 사용자나 그룹이 데이터를 소유해야 하는지 결정한 다음, 그 신원에 필요한 접근 권한을 부여하세요. 사용 시 no_root_squash 중요한 보안 경계를 포기하는 것이며 일반 가정용 서버 단축키로 취급해서는 안 됩니다.

NFS가 SMB보다 자동으로 빠른 것은 아닙니다

성능은 클라이언트 운영 체제, 프로토콜 버전, 파일 크기, 메타데이터 작업 부하, 스토리지 풀, 서명 또는 암호화, 마운트 옵션, 네트워크 링크, 애플리케이션 동작에 따라 달라집니다.

단일 대용량 비디오는 주로 순차 처리량을 테스트합니다. 두 프로토콜 모두 디스크나 네트워크 링크를 포화시킬 수 있다면 결과가 비슷하게 보일 수 있습니다. 수천 개의 썸네일, 자막, 메타데이터 파일, 중첩된 폴더가 포함된 디렉터리는 파일 조회, 속성 캐싱, 작은 작업에 더 큰 부담을 줍니다.

그래서 하나의 벤치마크만으로 모든 가정의 선택을 결정할 수 없습니다. 최소한 네 가지 작업 부하를 테스트하세요: 하나의 대용량 읽기, 하나의 대용량 쓰기, 많은 작은 파일이 있는 디렉터리, 그리고 실제로 공유를 사용할 클라이언트에서의 일반 폴더 탐색.

대용량 미디어 파일은 보통 가장 빠른 프로토콜이 필요하지 않습니다

일반적인 영화 스트리밍은 건강한 기가비트 이더넷 연결이 제공할 수 있는 대역폭보다 훨씬 적은 대역폭을 소비합니다. 미디어 서버가 로컬 네트워크에서 한 비디오를 안정적으로 재생할 수 없다면, 병목 현상은 SMB와 NFS의 차이보다는 Wi-Fi, 트랜스코딩, 디스크 성능 또는 클라이언트 호환성 때문일 수 있습니다.

차이는 Plex, Jellyfin, Sonarr 또는 다른 애플리케이션이 대형 라이브러리를 스캔할 때 더 뚜렷해집니다. 서버는 실제 재생이 하나의 대용량 미디어 파일을 순차적으로 읽더라도 수천 개의 포스터, 자막, NFO 파일 및 데이터베이스 참조를 열 수 있습니다.

이 때문에 대용량 파일 스트리밍은 두 프로토콜 모두에서 잘 작동할 수 있지만 소규모 파일 라이브러리 스캔에서는 더 큰 차이가 나타납니다. Linux 기반 미디어 서버는 NFS의 이점을 누릴 수 있지만, Windows와 macOS 클라이언트는 여전히 SMB를 통해 지원하는 것이 더 쉽습니다.

SMB는 보통 직접 미디어 플레이어 접근에 더 적합합니다

Apple TV, Android TV 기기, 휴대폰, 태블릿 또는 노트북이 NAS에 직접 연결하는 경우, SMB가 보통 더 쉬운 선택입니다. 많은 미디어 애플리케이션이 서버 주소, 사용자 이름, 비밀번호로 SMB 공유를 탐색할 수 있습니다.

NFS 지원은 애플리케이션과 기기마다 다릅니다. 사용 가능하더라도 내보내기 및 권한 설정이 일반 가정 사용자에게는 일반 SMB 자격 증명을 입력하는 것보다 덜 명확할 수 있습니다.

이는 미디어 서버 자체가 저장소를 마운트하는 방식과는 별개입니다. Linux 기반 Jellyfin 서버는 NFS를 통해 라이브러리를 읽을 수 있지만, 가족 기기들은 Jellyfin의 웹 또는 스트리밍 인터페이스에만 연결합니다. 최종 사용자 기기는 기본 파일 프로토콜에 직접 접근할 필요가 없습니다.

NFS는 종종 Proxmox 저장소에 자연스럽게 적합합니다

Proxmox는 Linux 기반으로 작동하므로 NFS는 백업, ISO, 템플릿 및 공유 저장소 워크플로우에 자연스럽게 어울립니다. NAS 내보내기는 호스트에서 마운트되어 데스크톱 파일 공유가 아닌 인프라 저장소로 관리될 수 있습니다.

이것이 모든 가상 머신 디스크가 자동으로 홈 NFS 서버에 배치되어야 한다는 의미는 아닙니다. VM 저장소는 지연 시간, 동기 쓰기 동작, 네트워크 가용성, 백업 설계, NAS가 재부팅되거나 연결이 끊겼을 때 시스템이 어떻게 동작해야 하는지에 따라 달라집니다.

컨테이너의 경우, 모든 컨테이너에 네트워크 마운트 구성을 제공하거나 공유 마운트를 위해 권한을 부여하는 대신 Proxmox 호스트에서 NFS를 마운트하고 저장소 경로를 권한 없는 컨테이너에 전달하는 것이 더 깔끔할 수 있습니다.

Docker 저장소는 데이터 유형에 따라 선택해야 합니다

Docker 내에서 NAS 경로를 사용하는 것이 모든 컨테이너에 NFS가 자동으로 적합하다는 의미는 아닙니다. 작업 부하가 컨테이너 플랫폼보다 더 중요합니다.

미디어 라이브러리, 다운로드, 가져오기, 내보내기, 백업 및 기타 대용량 공유 파일은 SMB나 NFS에서 잘 작동할 수 있습니다. 리눅스 도커 호스트는 파일 소유권이 친숙한 UID/GID 값으로 표현되기 때문에 NFS가 더 편할 수 있습니다.

데이터베이스, SQLite 파일, 검색 인덱스, 애플리케이션 상태, 자주 잠금이나 동기 쓰기가 필요한 작업은 더 신중해야 합니다. 애플리케이션이 선택한 네트워크 파일 시스템을 명시적으로 지원하고 재시작, 잠금, 실패 동작을 테스트하지 않았다면 해당 파일은 로컬 스토리지에 보관하세요.

컨테이너에 전달하기 전에 호스트에서 공유를 마운트하세요

많은 홈 서버 배포에서 가장 깔끔한 모델은 NAS 공유를 도커 호스트에 한 번 마운트한 후, 필요한 컨테이너에 로컬 경로를 바인드 마운트하는 것입니다.

이렇게 하면 자격 증명, NFS 내보내기 설정, 재연결 동작, 시작 순서가 한 곳에 유지됩니다. 컨테이너는 일반 디렉터리만 보며, 호스트가 네트워크 파일 시스템을 관리합니다.

이 모델은 NFS나 SMB 어느 쪽에도 적용됩니다. 중요한 점은 호스트 마운트가 컨테이너 시작 전에 가능해야 하고, 컨테이너 UID/GID가 마운트된 파일에 접근할 수 있어야 하며, NAS가 오프라인일 때 서비스가 빈 로컬 디렉터리에 조용히 쓰지 않아야 한다는 것입니다.

계획 없이 두 프로토콜이 동일 데이터를 쓰도록 하지 마세요

대부분의 NAS 플랫폼은 동일한 데이터셋을 SMB와 NFS를 통해 노출할 수 있습니다. 기술적으로 이는 윈도우 사용자와 리눅스 애플리케이션이 동일한 파일을 다룰 수 있게 합니다.

문제는 두 경로가 서로 다른 ID 및 ACL 모델로 파일을 생성할 수 있다는 점입니다. SMB 업로드는 상세한 ACL이 있는 NAS 계정에 속할 수 있지만, NFS 애플리케이션은 UID 1000으로 POSIX 모드 비트와 다른 umask를 사용해 씁니다.

두 프로토콜 모두 접근이 필요하다면 하나를 주된 쓰기 프로토콜로 정의하세요. 다른 프로토콜은 읽기 전용이거나, 두 프로토콜 모두 신중하게 정렬된 공유 그룹과 상속 모델을 사용할 수 있습니다. 그런 계획이 없으면 권한 불일치가 즉시가 아니라 점진적으로 나타나는 경향이 있습니다.

역할이 분리되어 있을 때 두 프로토콜을 모두 사용하는 것이 합리적입니다

혼합 홈 랩은 모든 것에 하나의 프로토콜만 선택할 필요가 없습니다. 두 프로토콜을 모두 사용하는 것이 모든 장치를 동일한 접근 모델로 강제하는 것보다 더 깔끔할 수 있습니다.

실용적인 구분 중 하나는:

• 윈도우 및 맥 가족 폴더용 SMB
• 휴대폰, 태블릿, TV의 직접 접근을 위한 SMB
• Proxmox 백업 및 리눅스 호스트용 NFS
• 리눅스 미디어 서버의 읽기 전용 라이브러리 마운트를 위한 NFS
• 애플리케이션 데이터베이스 및 민감한 런타임 상태를 위한 로컬 스토리지

프로토콜은 기본적으로 모든 곳에서 활성화하기보다는 책임에 따라 구분해야 합니다. 별도의 데이터셋이나 명확한 읽기/쓰기 경계는 권한 충돌을 줄이고 문제 해결을 쉽게 만듭니다.

두 프로토콜 모두 인터넷에 직접 노출되어서는 안 됩니다

SMB와 NFS는 신뢰할 수 있는 로컬 네트워크 또는 사설 네트워크 경로용입니다. 가정 라우터에서 TCP 445(SMB)나 NFS 서비스 포트를 공용 인터넷으로 포트 포워딩하지 마세요.

원격 파일 접근 시 먼저 VPN이나 다른 인증된 사설 접근 계층을 통해 가정 네트워크에 연결하세요. 원격 장치가 신뢰된 경로 안에 들어오면 LAN에서 사용 가능한 동일한 SMB 또는 NFS 서비스를 사용할 수 있습니다.

SMB에서 NFS로 변경한다고 해서 공개 노출이 더 안전해지지 않습니다. 보안은 접근 가능한 클라이언트 제한, 소프트웨어 업데이트 유지, 적절한 인증 사용, 불필요한 공개 서비스 회피에 달려 있습니다.

전송 속도 이상의 벤치마크

공정한 가정 테스트는 동일한 NAS 데이터셋, 클라이언트, 네트워크 링크, 파일을 두 프로토콜 모두에 사용해야 합니다. 그렇지 않으면 결과가 SMB와 NFS가 아니라 다른 저장 경로나 클라이언트 장치를 측정하는 것일 수 있습니다.

초당 메가바이트 이상을 기록하세요. 마운트가 절전 모드나 재부팅 후 재연결되는지, 파일 이름과 메타데이터가 올바르게 동작하는지, 애플리케이션이 파일을 생성 및 삭제할 수 있는지, 권한이 일관되게 유지되는지 테스트하세요.

5% 더 빠르지만 재부팅 후 자주 실패하는 프로토콜은 더 나쁜 선택일 수 있습니다. 신뢰성, 클라이언트 호환성, 권한 유지에 필요한 시간은 실제 성능의 일부입니다.

이 결정 순서를 사용하세요

프로토콜 선호도보다 클라이언트부터 시작하세요. 데이터가 필요한 모든 컴퓨터, 모바일 장치, 미디어 플레이어, 서버, 하이퍼바이저, 애플리케이션을 나열하세요.

그런 다음 사람의 탐색과 기계 간 접근을 분리하세요. 가정 사용자들은 일반적으로 SMB 계정과 익숙한 파일 탐색기를 통해 이익을 봅니다. 관리되는 Linux 서비스는 NFS 마운트와 숫자 ID 제어로 이익을 볼 수 있습니다.

최종 공유를 활성화하기 전에 다음 질문에 답하세요:

1. Windows나 macOS 사용자가 파일을 탐색하나요?
2. 휴대폰이나 TV 애플리케이션이 직접 접근해야 하나요?
3. 대부분의 클라이언트가 관리되는 Linux 시스템인가요?
4. UID와 GID 값이 일관되게 유지될 수 있나요?
5. 작업 부하에 데이터베이스나 잠금에 민감한 파일이 포함되어 있나요?
6. SMB와 NFS가 동일한 데이터셋에 모두 쓰기를 하나요?
7. NAS를 사용할 수 없을 때 마운트는 어떻게 동작해야 하나요?
8. 선택한 프로토콜을 완전히 공용 인터넷에서 차단할 수 있나요?

대부분의 혼합 장치 가정에서는 SMB로 시작하세요. 특정 Linux, Proxmox, 백업 또는 컨테이너 작업 부하에 유용하고 일관되게 관리할 수 있는 경우에만 NFS를 추가하세요.

최종 요약

SMB는 보통 Windows, macOS, 휴대폰, 태블릿, 스마트 TV, 가족 공유 폴더에 더 적합한 기본값입니다. 광범위한 호환성과 가정 사용자에게 설명하기 쉬운 계정 기반 접근 모델을 제공합니다.

NFS는 Linux 서버, Proxmox 저장소, 자동 백업 및 기타 기계 간 워크플로우에 더 적합한 경우가 많습니다. 이는 UID/GID 값, 내보내기, 마운트 옵션, 소유권을 올바르게 관리하는 것에 달려 있습니다.

가정에서는 두 프로토콜을 모두 사용할 수 있지만 역할이 명확해야 합니다. 사람과 혼합 클라이언트 장치에는 SMB를, 관리되는 Linux 인프라에는 NFS를 사용하고, 동일 데이터셋에 두 프로토콜 모두 무제한 쓰기 권한을 주는 것은 피하세요.

자주 묻는 질문

NFS가 항상 SMB보다 빠른가요?

아니요. NFS는 일부 Linux 간 및 소형 파일 작업에서 더 나은 성능을 보일 수 있지만, 최신 SMB는 Windows 및 혼합 클라이언트 네트워크에서 매우 좋은 성능을 낼 수 있습니다. 실제 사용할 파일, 클라이언트, 저장소, 네트워크를 테스트하세요.

Plex와 Jellyfin에는 SMB와 NFS 중 어느 것을 사용해야 하나요?

둘 다 가능합니다. Linux 미디어 서버는 대형 라이브러리 스캔 시 NFS가 유리할 수 있고, Windows, macOS, 미디어 플레이어 애플리케이션이 NAS에 직접 접근할 때는 SMB가 더 쉬울 수 있습니다. 대용량 비디오 스트리밍은 두 프로토콜 모두 잘 작동합니다.

Proxmox에는 NFS가 더 좋은가요?

NFS는 Proxmox 백업, ISO 저장, 템플릿, 공유 저장소에 일반적이고 자연스러운 선택입니다. VM 디스크와 고부하 쓰기 작업은 지연 시간, 동기화 동작, NAS 가용성 테스트가 필요합니다.

Docker 컨테이너가 SMB 공유를 사용할 수 있나요?

네. Docker 호스트에서 SMB 공유를 마운트하고 결과 경로를 컨테이너에 바인드 마운트하세요. 컨테이너 사용자가 마운트된 파일에 접근할 권한이 있고, 컨테이너 시작 전에 호스트 마운트가 사용 가능해야 합니다.

공유가 마운트되었는데도 NFS에서 권한 거부가 발생하는 이유는 무엇인가요?

내보내기 및 네트워크 경로는 올바를 수 있지만 클라이언트 UID/GID가 NAS의 소유자 또는 허용된 그룹과 일치하지 않을 수 있습니다. 루트 스쿼싱이나 내보내기 매핑도 실제 사용자를 변경할 수 있습니다.

같은 폴더에서 SMB와 NFS를 모두 활성화할 수 있나요?

가능하지만, 동시에 쓰기 접근 시 소유권, ACL, 확장 속성 충돌이 발생할 수 있습니다. 별도의 데이터셋을 사용하거나 한 프로토콜을 읽기 전용으로 설정하거나 신중하게 정렬된 공유 권한 모델을 만드는 것이 좋습니다.

가정에서 어느 프로토콜이 더 안전한가요?

둘 다 신뢰할 수 있는 LAN에서 보안을 유지할 수 있습니다. SMB는 간단한 사용자 인증과 최신 서명 또는 암호화를 제공합니다. NFS는 신뢰할 수 있는 클라이언트에만 제한하고 올바른 내보내기 규칙과 루트 스쿼싱을 적용해야 합니다. 둘 다 인터넷에 직접 노출해서는 안 됩니다.

초보자가 어떤 프로토콜을 선택해야 하나요?

Windows, macOS, 휴대폰 또는 TV 애플리케이션이 포함된 가정에서는 SMB를 선택하세요. 클라이언트가 주로 Linux 시스템이고 마운트, UID/GID 값, 내보내기 권한 관리를 편하게 할 수 있다면 NFS를 선택하세요.