맥과 윈도우, 나스의 파일시스템 호환성, 통일되지는 않을까?

윈도우(Windows)에서 잘 쓰던 외장 SSD를 맥(Mac)에 연결했더니 파일은 열리는데 저장은 안 되는 경우가 있습니다. 반대로 맥에서 포맷한 드라이브는 윈도우에서 드라이브 문자조차 나오지 않을 수 있습니다.

그런데 같은 두 컴퓨터가 나스(NAS)에 접속하면 파일을 함께 읽고 쓸 수 있습니다. 나스 내부에서는 Btrfs나 ZFS처럼 PC와 다른 파일시스템을 쓰는데도 그렇죠. 드라이브를 직접 연결할 때는 PC가 저장 형식을 해석하지만, 네트워크로 접속할 때는 나스가 그 일을 대신하기 때문입니다.

외장 드라이브는 연결할 컴퓨터에 맞춰 선택

맥과 윈도우 사이에서 외장 드라이브로 파일을 주고받는 용도라면 exFAT을 사용하면 좋습니다. 두 운영체제에서 별도 드라이버 없이 읽고 쓸 수 있고, 큰 영상 파일을 옮기기에도 적합합니다.

파일시스템(File System)은 드라이브에 파일 내용과 이름, 폴더 구조 등을 기록하는 규칙입니다. NTFS나 APFS가 그 규칙의 이름인데요, 연결한 컴퓨터에 해당 형식을 해석하는 드라이버가 있어야 파일을 열고 수정할 수 있습니다.

다음은 별도 드라이버나 복구 프로그램을 설치하지 않았을 때의 지원 범위입니다. 암호화하지 않은 정상 데이터 드라이브를 직접 연결하는 경우이며, 리눅스(Linux)는 최근 주요 배포판에 필요한 드라이버가 포함된 구성을 기준으로 합니다.

맥과 NTFS의 조합이 조금 특이한데요, 맥에서는 NTFS 파일시스템의 파일을 읽기만 할 수 있고, 기본적으로는 쓸 수 없습니다. 맥의 기본 NTFS 지원이 읽기 전용이기 때문입니다. SSD의 파일을 맥으로 복사하는 것은 가능하지만, 반대 방향으로 저장하려면 별도의 쓰기 지원이 필요한 거죠. 이런 추가 드라이버를 사용하는 경우는 위 표에서 제외했습니다.

리눅스는 NTFS3 드라이버로 NTFS 읽기·쓰기를 지원하며 배포판에 따라 NTFS-3G를 사용하기도 합니다. HFS+는 저널링 여부에 따라 쓰기가 제한되고, 쓰기를 강제하는 옵션에는 손상 위험이 있기 때문에 맥의 작업용 디스크를 그대로 옮겨 쓰는 건 자제해야 합니다. 윈도우에서 ext4를 읽는 방법 중에는 WSL의 리눅스 환경을 거치는 방식도 있지만, 기본적으로 지원되는 것도 아니고, USB 드라이브 등의 제약도 있습니다.

파일시스템이 맞아도 드라이브가 암호화되어 있으면 별도의 잠금 해제가 필요합니다. 구형 TV나 카메라에 연결한다면 지원 형식뿐 아니라 용량과 파티션 방식도 해당 기기의 조건에 맞아야 합니다.

파일 전달용 드라이브와 지속 작업용 드라이브는 별개

그렇다면 호환성이 좋은 exFAT으로 전부 통일하면 편할 것 같습니다. 그런데 exFAT은 여러 컴퓨터 사이에서 파일을 옮기기에는 편하지만, 각 운영체제의 저장 기능을 모두 제공하는 형식이 아닙니다.

예를 들어 exFAT에는 NTFS와 같은 메타데이터 저널링(Journaling)이나 파일별 접근제어목록(ACL)이 없습니다. 저널링은 파일시스템 구조를 바꾸는 과정을 기록해서, 쓰기 도중 전원이 끊겼을 때 구조를 복구하는 데 도움을 주는 기능입니다. 작업 중인 파일 내용까지 백업해 주는 기능은 아니지만, 계속 읽고 쓰는 드라이브에서는 이런 차이도 중요합니다.

맥에서만 작업할 드라이브라면 APFS, 윈도우에서 주로 쓸 드라이브라면 NTFS를 선택하시면 좋습니다. 타임머신(Time Machine)의 새 백업 디스크에도 APFS 계열이 권장됩니다. exFAT은 이런 작업용 드라이브를 대신하기보다, 서로 다른 컴퓨터에 파일을 전달할 때 선택하면 되는 거죠. FAT32도 양쪽에서 쓸 수 있지만 파일 하나가 당 최대 용량 4GB 제한이 있어서 큰 영상이나 디스크 이미지를 옮기기에는 불편합니다.

이미 자료가 들어 있는 드라이브의 형식을 바꾸려고 포맷하면 기존 자료가 지워지기 때문에 처음부터 용도와 환경에 따라 적절한 걸 선택하는 게 좋습니다.

나스는 PC와 다른 파일시스템이어도 됩니다

외장 드라이브를 번갈아 연결하는 대신 나스의 공유폴더를 함께 쓴다면, PC마다 파일시스템을 맞출 필요가 없습니다. 윈도우 PC가 NTFS를 쓰고 맥이 APFS를 쓰더라도 같은 공유폴더에 접속할 수 있습니다.

이때 PC는 SMB나 NFS 같은 네트워크 규약으로 "이 파일을 열어 달라", "여기에 저장해 달라"고 요청합니다. 나스가 자기 디스크에서 파일을 찾아 내용을 보내거나 저장하는 방식입니다. PC가 나스 디스크의 내부 구조까지 직접 읽지는 않는 거죠.

그래서 시놀로지 나스가 Btrfs를 사용해도 맥이나 윈도우에 Btrfs 드라이버를 설치할 필요는 없습니다. PC와 나스가 같은 공유 규약을 지원하고, 접속한 계정에 필요한 폴더 권한이 있으면 됩니다.

반대로 나스에서 디스크를 빼서 PC에 직접 연결하면 나스가 하던 일을 PC가 맡아야 합니다. 파일시스템뿐 아니라 RAID로 묶인 디스크 구성이나 암호화까지 해석해야 할 수 있어, 외장 드라이브처럼 연결해서 바로 읽기는 어렵습니다.

간혹 몇몇 고객께서 나스에서 쓰던 디스크의 내용을 나스 고장으로 인해 PC에 연결해서 보고싶다고 요청하시는데, 대부분의 경우 이건 불가능하다고 보셔야 합니다.

ZFS, ReFS, Btrfs는?

이 이름들은 최신 파일시스템 규격으로 모두 기존 파일시스템의 여러 단점을 해결하고 새로운 기능을 붙인 차세대 규격들입니다. 이름을 보면 NTFS나 exFAT을 대신할 새로운 공통 형식처럼 느껴질 수 있습니다만 세 파일시스템은 외장 드라이브의 호환성을 통일하기보다 서버나 나스에서 많은 데이터를 관리하고 보호하는 쪽에 더 초점이 있습니다.

ZFS는 여러 디스크를 하나의 저장공간으로 관리

ZFS는 디스크를 묶은 저장공간인 풀(Pool)을 만들고, 그 안의 파일시스템까지 함께 관리합니다. 여기에 스냅샷(Snapshot), 압축, 복제, 체크섬(Checksum) 같은 기능이 연결됩니다. 체크섬은 데이터의 내용을 바탕으로 계산한 값입니다. 읽을 때 다시 계산한 값과 저장된 값을 비교해 손상 여부를 확인합니다.

파일을 어느 디스크에 저장할지 관리하는 부분과 파일시스템이 함께 설계되어 있다는 것이 특징입니다. 여러 디스크를 묶는 서버·스토리지에서 많이 쓰이는 이유이기도 합니다. Solaris에서 시작한 기술을 이어가는 OpenZFS의 주 개발 저장소는 리눅스와 FreeBSD를 대상으로 하며, 여러 업체와 개발자가 함께 개선하고 있습니다.

맥용과 윈도우용 프로젝트도 있지만 별도의 드라이버를 설치해야 합니다. 운영체제와 CPU, 드라이버 버전이 지원하는 풀 기능도 맞아야 하므로, exFAT처럼 여러 컴퓨터에 바로 연결해 쓰는 용도와는 거리가 있습니다.

ReFS는 윈도우의 서버·개발 작업에 사용됩니다

ReFS는 마이크로소프트가 개발하며 대규모 데이터와 가상 머신 파일, 데이터 무결성 등을 다룹니다. 윈도우 서버와 Storage Spaces가 주요 사용 환경입니다.

일반 PC에서는 개발용 저장공간인 Dev Drive를 통해 ReFS를 접할 수 있습니다. 지원 빌드의 윈도우 11에서는 모든 에디션에서 사용할 수 있지만, 소스 코드나 패키지 캐시 등을 두는 용도입니다. USB 외장 드라이브나 윈도우가 설치된 C 드라이브를 Dev Drive로 지정할 수는 없습니다.

ReFS에는 같은 데이터 블록을 공유해 실제 복사를 줄이는 블록 복제(Block Cloning) 같은 기능이 있지만, NTFS의 모든 기능을 그대로 제공하지는 않습니다. 일반 ReFS 볼륨을 만들 수 있는 환경과 Dev Drive의 지원 범위도 다르고, ReFS는 부팅용으로 지원되지 않습니다. ReFS는 지원 환경에서 블록 복제나 무결성 기능의 이점을 얻을 수 있는 서버·개발 작업에 선택하면 됩니다.

리눅스와 나스에서 익숙한 Btrfs

Btrfs는 리눅스 커널에 포함된 파일시스템으로, 여러 업체와 개발자가 함께 개발합니다. 기존 내용을 바로 덮어쓰지 않고 변경 내용을 새 위치에 기록하는 쓰기 시 복사(Copy-on-Write) 방식을 사용합니다. 이 구조를 바탕으로 스냅샷, 체크섬, 압축 등을 제공합니다.

리눅스 배포판에서도 쓰이고 시놀로지 나스에서도 볼 수 있지만, 같은 Btrfs라고 지원 기능이 모두 같지는 않습니다. 나스 제조사가 자체 RAID 구성과 복구 기능, 관리 화면에 맞춰 통합하기 때문입니다. 윈도우나 맥이 기본으로 읽고 쓰는 형식도 아닙니다.

손상 발견 및 복구

체크섬이 있으면 데이터가 원래 내용과 달라졌는지 알아낼 수 있습니다. 하지만 어느 부분이 잘못됐는지 아는 것만으로 원래 내용을 다시 만들 수는 없습니다. 복구하려면 정상 사본이나 복구에 쓸 수 있는 중복 데이터가 있어야 합니다.

OpenZFS의 자동 복구는 적절한 RAID 구성이나 중복 사본을 이용합니다. ReFS도 파일 내용의 체크섬을 다루는 무결성 스트림(Integrity Streams) 설정과 Storage Spaces의 미러·패리티 구성을 함께 확인해야 합니다. 단일 디스크를 이런 파일시스템으로 포맷했다고 자동 복구까지 준비되는 것은 아닙니다.

사용자가 파일을 삭제하거나 랜섬웨어가 내용을 덮어쓰는 경우는 또 다릅니다. 파일시스템에는 정상적인 변경으로 기록될 수 있어, 체크섬만으로는 이를 실수나 공격이라고 구분할 수 없습니다. 이전 상태로 돌아갈 스냅샷과 별도 백업이 여전히 필요한 이유입니다.

좋은 파일시스템 하나로 통일하면 안 될까?

서로 읽고 쓸 수 없어서 생기는 불편만 보면 하나로 통일하는 편이 좋아 보입니다. 다만 파일시스템은 파일을 담는 형식뿐 아니라, 운영체제가 권한과 암호화, 복구 기능을 처리하는 방식과도 연결되어 있습니다.

메모리카드에서는 여러 기기에 쉽게 연결하는 것이 중요하고, 노트북에서는 부팅과 암호화가 필요합니다. 여러 디스크를 묶는 서버라면 디스크 고장이나 데이터 손상에 대응하는 기능의 비중이 더 커집니다. 같은 기능을 모두 갖추는 것보다 각 환경에 맞게 설계해 온 결과가 지금의 차이인 셈입니다.

새로운 형식이 나오더라도 기존 권한, 파일 이름의 대소문자 처리, 앱이 사용하는 속성, 백업과 복구 도구까지 함께 맞춰야 합니다. 다른 형식의 파일을 읽는 드라이버를 추가하는 일과 운영체제의 기본 저장 방식을 바꾸는 일은 규모가 상당히 다릅니다. 공개 소스 사이에도 제약이 있어서, OpenZFS는 라이선스 차이 때문에 리눅스 커널 바이너리에 직접 포함해 배포할 수 없다고 하기도 합니다. 별도 모듈로 사용하는 것과 커널에 합쳐 넣는 것은 다른 문제입니다.

무엇보다 파일시스템을 통일하지 않아도 네트워크를 통해 파일을 함께 쓸 수 있습니다. 맥과 윈도우가 섞여 있다면 외장 드라이브로 자료를 전달할지, 나스에 모아서 함께 작업할지부터 정하면 됩니다. 전자는 상대 컴퓨터가 읽고 쓸 수 있는 형식을 고르고, 후자는 나스의 공유 권한과 백업 구성을 맞추는 쪽이 중요합니다. 저희의 경우 윈도우 PC를 주로 작업용으로 사용하는데, NTFS 외장 하드디스크 드라이브를 큰 걸로 하나 준비해서 빠른 데이터 복사에 이용하곤 합니다.

여러 운영체제를 사용하는 사무실에서 파일을 함께 관리하려면, 사용하는 컴퓨터와 자료의 종류, 작업 인원을 정리해 나스 구성 상담을 요청하실 수 있습니다.