ext4 vs Btrfs vs ZFS: 리눅스 파일시스템 뭐가 다를까

디스크에 파일 하나를 저장하는 방식조차 파일시스템마다 완전히 달라요. 우분투와 데비안 계열은 20년 넘게 ext4를 기본값으로 써왔고, Fedora와 openSUSE는 스냅샷이 되는 Btrfs로 넘어갔으며, TrueNAS 같은 NAS 진영은 처음부터 ZFS를 고집해요. 셋 다 “파일을 저장한다”는 목적은 같은데 왜 이렇게 선택이 갈리는 걸까요?

ext4는 무엇이고 왜 여전히 기본값일까?

ext4는 저널링 기반의 전통적인 리눅스 파일시스템으로, 데이터를 쓴 자리에 그대로 덮어쓰는 단순한 구조 덕분에 안정성과 속도의 균형이 가장 좋아요. 2008년 커널 2.6.28에 처음 포함된 이후 큰 구조 변경 없이 꾸준히 개선되어 왔고, 그만큼 버그가 적고 예측 가능한 동작을 보여요. Debian 계열과 우분투 서버가 지금도 ext4를 기본값으로 쓰는 이유가 바로 이 검증된 안정성이에요. 스냅샷이나 체크섬 같은 화려한 기능은 없지만, “파일시스템이 말썽을 일으키면 안 되는” 프로덕션 서버에서는 이 단순함 자체가 장점이 돼요.

Btrfs는 무엇이 다른가 — 스냅샷과 자가치유

Btrfs는 데이터를 원래 위치에 덮어쓰지 않고 새 위치에 쓴 뒤 포인터만 바꾸는 CoW(Copy-on-Write) 구조를 써서, 시스템 상태를 순간적으로 얼려두는 스냅샷 기능을 지원해요. 업데이트 전에 스냅샷을 하나 떠두면 문제가 생겼을 때 그 시점으로 즉시 되돌릴 수 있는데, Btrfs 스냅샷과 Snapper 조합이 바로 이 원리를 활용한 안전망이에요. 여기서 끝이 아니에요. Btrfs는 파일마다 체크섬을 저장해두고 읽을 때마다 검증하기 때문에, 디스크 어딘가가 조용히 손상되는 ‘사일런트 데이터 손상’도 잡아낼 수 있어요. Fedora Silverblue 같은 불변 리눅스가 시스템 업데이트를 스냅샷 기반 롤백으로 안전하게 처리하는 것도 이 구조 덕분이에요.

ZFS는 왜 커널 밖에서 따로 취급해야 할까?

ZFS는 파일시스템과 볼륨 매니저(RAID 관리 기능)가 하나로 합쳐진 구조라서, mdadm이나 LVM 없이도 여러 디스크를 묶어 RAID-Z 배열을 구성할 수 있어요. 원래 썬 마이크로시스템즈가 솔라리스용으로 개발했고 지금은 오픈소스 CDDL 라이선스로 공개되어 있는데, 문제는 이 CDDL이 리눅스 커널의 GPL과 법적으로 호환되지 않는다고 여겨진다는 점이에요. 그래서 ZFS는 커널에 직접 포함되지 못하고 ZFS on Linux라는 별도 커널 모듈로 설치해야 하고, 커널 버전이 바뀔 때마다 모듈을 다시 빌드해야 하는 번거로움이 따라와요. 그럼에도 데이터 무결성 검증, 압축, 중복 제거까지 한 번에 처리하는 완성도 때문에 NAS와 스토리지 서버에서는 사실상 표준 취급을 받아요.

성능은 실제로 얼마나 차이날까?

일반적인 순차 읽기·쓰기에서는 세 파일시스템의 체감 차이가 크지 않지만, 워크로드가 특수해지면 격차가 뚜렷하게 벌어져요. ext4는 단순한 덮어쓰기 구조 덕분에 대용량 파일을 반복적으로 수정하는 데이터베이스 워크로드에서 가장 안정적인 지연 시간을 보이고, Btrfs는 CoW 구조 특성상 같은 파일을 자주 덮어쓰는 작업(가상머신 이미지, DB 파일)에서 조각화가 누적되며 속도가 떨어지는 경향이 있어요. ZFS는 ARC라는 자체 캐싱 계층 덕분에 읽기 성능은 뛰어나지만, 그만큼 메모리를 넉넉하게 요구한다는 점이 부담이에요. 결국 “어떤 게 더 빠르냐”보다 “내 워크로드가 어떤 패턴이냐”를 먼저 따져야 답이 나오는 문제예요.

어떤 상황에 어떤 파일시스템을 골라야 할까?

용도별로 나눠보면 선택 기준이 훨씬 명확해져요.

일반 데스크톱·노트북: 안정성과 자원 효율이 우선이라면 ext4가 여전히 무난한 선택이에요.
롤백이 중요한 데스크톱: 업데이트 실패를 스냅샷으로 즉시 되돌리고 싶다면 Btrfs가 유리해요.
저사양 SBC나 오래된 PC: 라즈베리 파이처럼 자원이 빠듯한 환경에서는 체크섬 연산 부담이 적은 ext4나 f2fs가 더 적합해요.
NAS·스토리지 서버: 여러 디스크를 묶어 데이터 무결성까지 챙기고 싶다면 ZFS가 사실상 정답이에요.
프로덕션 데이터베이스 서버: 예측 가능한 I/O 패턴이 필요하다면 RHEL 계열의 엔터프라이즈 리눅스에서도 기본값인 XFS나 ext4를 우선 검토하는 게 안전해요.

마이그레이션은 어떻게 진행해야 할까?

기존 ext4 파티션을 Btrfs로 in-place 변환하는 btrfs-convert 도구가 존재하긴 하지만, 변환 도중 전원이 끊기거나 오류가 나면 데이터가 손상될 위험이 있어서 프로덕션 환경에서는 권장되지 않아요. 실무에서 가장 안전한 방법은 데이터를 외부로 백업한 뒤 원하는 파일시스템으로 새로 파티션을 만들고 데이터를 복원하는 방식이에요. ZFS로 옮기는 경우도 마찬가지로, zfs send/receive를 활용한 점진적 마이그레이션이 다운타임을 최소화하는 현실적인 경로예요.

파일시스템은 한 번 고르면 웬만해선 바꾸지 않는 기반 설계라서, 지금 당장의 화려한 기능보다 “이 시스템을 몇 년 뒤에도 이 구조로 쓸 수 있는가”를 기준으로 골라야 후회가 없어요. 결국 ext4, Btrfs, ZFS 중 무엇이 정답이냐는 질문에는 정답이 없고, 여러분의 워크로드가 무엇을 더 자주 요구하는지가 유일한 답이에요.