---
title: "리눅스 파일 시스템 완전 비교 가이드 — ext4 vs XFS vs Btrfs vs ZFS"
date: 2026-09-23
time: "22:00"
model: admin
category: knowhow
summary: "리눅스 4대 파일 시스템(ext4, XFS, Btrfs, ZFS)의 특징, 벤치마크, 실무 명령어, 선택 기준을 실전 코드와 함께 정리"
tags: 리눅스,파일시스템,ext4,XFS,Btrfs,ZFS,서버,스토리지,포맷,백업
---

# 리눅스 파일 시스템 완전 비교 가이드 — ext4 vs XFS vs Btrfs vs ZFS

"어떤 파일 시스템으로 포맷해야 하지?" 이 질문에 대한 답은 사용 목적에 따라 완전히 달라집니다. ext4는 안정성의 왕, XFS는 대용량 처리의 달인, Btrfs는 스냅샷 마법사, ZFS는 엔터프라이즈 끝판왕입니다.

## 1. 파일 시스템이란 무엇인가

파일 시스템은 디스크 위에 데이터를 저장하고 관리하는 규칙입니다. 마치 도서관의 도서 분류 체계와 같습니다. 같은 하드디스크라도 파일 시스템에 따라 읽기/쓰기 속도, 안정성, 기능이 완전히 달라집니다.

## 2. 4대 파일 시스템 핵심 비교

| 특징 | ext4 | XFS | Btrfs | ZFS |
|------|------|-----|-------|-----|
| 최대 볼륨 크기 | 1 EB | 8 EB | 16 EB | 256 ZiB |
| 스냅샷 | 미지원 (LVM 필요) | 미지원 (LVM 필요) | 내장 (매우 빠름) | 내장 (강력함) |
| 축소(Shrink) | 가능 | 불가능 | 가능 | 불가능 |
| 압축 | 미지원 | 미지원 | 내장 (zstd/lzo) | 내장 (lz4/zstd) |
| RAID 내장 | mdadm 필요 | mdadm 필요 | Btrfs RAID 내장 | RAID-Z 내장 |
| 메모리 소모 | 매우 적음 | 적음 | 보통 | 많음 (RAM 필요) |
| 데이터 무결성 | 기본 | 기본 | 기본 (CoW) |checksum 대체 불가 |
| 커널 기본 내장 | 예 | 예 | 예 | 아니오 (라이선스) |
| 커널 도입 연도 | 1992 (ext) → 2008 (ext4) | 1993 | 2009 | 2005 (Solaris) → 2013 (Linux) |

## 3. ext4 — 리눅스의 오랜 표준

### 핵심 특징

ext4는 20년 이상 검증된 파일 시스템입니다. 버그가 거의 없고, 어떤 리눅스 배포판에서든 기본값으로 제공됩니다.

- ** journaling**: 데이터 쓰기 전에 저널에 기록하여 시스템 비정상 종료 시 복구 속도가 빠름
- **extent 기반 할당**: 연속된 블록을 하나의 extent로 묶어 작은 파일 처리 속도 향상
- **延迟 할당 (Delayed Allocation)**: 쓰기 버퍼를 모았다가 한꺼번에 할당하여 파일 단편화 감소

### practical 명령어

```bash
# ext4 포맷
sudo mkfs.ext4 /dev/sdb1

# 마운트 (기본 옵션)
sudo mount /dev/sdb1 /mnt/data

# 마운트 옵션 튜닝 — 읽기 중심 서버
sudo mount -o noatime,nodiratime,data=writeback /dev/sdb1 /mnt/data

# fstab에 영구 등록
echo '/dev/sdb1 /mnt/data ext4 defaults,noatime,nodiratime 0 2' | sudo tee -a /etc/fstab

# 디스크 사용량 확인
df -hT /mnt/data

# 조각 모음 (ext4는 자동 조각 모음이 없으므로 수동 필요)
sudo e4defrag /mnt/data

# 무결성 검사 (온라인 가능)
sudo e2fsck -f /dev/sdb1
```

### best practice

- `/etc/fstab`에 `noatime` 옵션을 넣으면 불필요한 접근 시간 기록을 생략하여 I/O 성능 향상
- `data=writeback` 모드는 쓰기 성능이 가장 빠르지만 비정상 종료 시 데이터 손실 위험 약간 증가
- `data=ordered` (기본값)는 안정성과 성능의 균형이 가장 좋음

## 4. XFS — 대용량 처리의 달인

### 핵심 특징

XFS는 IRIX에서 개발된 고성능 파일 시스템으로, MySQL/PostgreSQL 같은 대규모 데이터베이스와 대용량 미디어 파일 처리에 최적화되어 있습니다.

- **일_allocation 그룹 (AG)**: 디스크를 독립적인 구역으로 나누어 동시 쓰기 처리 성능 향상
- **B+tree 기반 디렉토리**: 수백만 개 파일이 있어도 디렉토리 검색 속도 유지
- ** realtime 스트리밍**: 미디어 스트리밍 같은 실시간 I/O에 특화
- **확장은 가능하나 축소 불가**: 볼륨을 키우는 것은 가능하지만, 줄이는 것은 불가능

### practical 명령어

```bash
# XFS 포맷
sudo mkfs.xfs /dev/sdb1

# 마운트
sudo mount /dev/sdb1 /mnt/data

# 마운트 옵션 — DB 서버용
sudo mount -o noatime,nodiratime,logbufs=8,logbsize=256k /dev/sdb1 /mnt/data

# fstab 등록
echo '/dev/sdb1 /mnt/data xfs defaults,noatime 0 2' | sudo tee -a /etc/fstab

# 디스크 사용량 확인
df -hT /mnt/data
xfs_info /dev/sdb1

# 조각 모음
sudo xfs_fsr /mnt/data

# 복구 도구
sudo xfs_repair /dev/sdb1

# 온라인 복구 (마운트된 상태에서)
sudo xfs_repair -L /dev/sdb1
```

### best practice

- RHEL/CentOS/Fedora 계열은 기본값이 XFS — 그대로 유지하는 것이 가장 안전
- PostgreSQL의 `shared_buffers`와 XFS의 `noatime`을 조합하면 DB 성능이 극대화됨
- 대용량 로그 파일 저장 시 `logbufs=8` 옵션으로 로그 버퍼를 늘리면 쓰기 성능 향상

## 5. Btrfs — 스냅샷과 데이터 보호의 마법사

### 핵심 특징

Btrfs는 Copy-on-Write(CoW) 기반으로 파일 시스템 레벨에서 스냅샷, 복구, RAID, 실시간 압축을 지원합니다. 시놀로지 NAS 등에서 주로 채용하고 있습니다.

- **Copy-on-Write (CoW)**: 데이터를 수정할 때 기존 블록을 건드리지 않고 새 블록에 기록 → 스냅샷이 순간적으로 생성됨
- **실시간 압축**: 파일을 저장할 때 자동으로 압축 (zstd, lzo, zlib) → 디스크 용량 절약
- **Btrfs RAID**: mdadm 없이 파일 시스템 레벨에서 RAID 0/1/5/6/10 지원
- **서브볼륨**: 하나의 파티션 안에서 독립적인 볼륨처럼 관리 가능

### practical 명령어

```bash
# Btrfs 포맷 (single, RAID 없이)
sudo mkfs.btrfs /dev/sdb1

# Btrfs 포맷 (RAID 1 — 미러링)
sudo mkfs.btrfs -d raid1 -m raid1 /dev/sdb1 /dev/sdc1

# 마운트
sudo mount /dev/sdb1 /mnt/data

# fstab 등록
echo '/dev/sdb1 /mnt/data btrfs defaults,noatime 0 2' | sudo tee -a /etc/fstab

# 서브볼륨 생성
sudo btrfs subvolume create /mnt/data/@home
sudo btrfs subvolume create /mnt/data/@snapshots

# 스냅샷 생성 (1초 만에 완료)
sudo btrfs subvolume snapshot /mnt/data/@home /mnt/data/@snapshots/home-$(date +%Y%m%d)

# 스냅샷 목록 확인
sudo btrfs subvolume list /mnt/data

# 스냅샷 삭제
sudo btrfs subvolume delete /mnt/data/@snapshots/home-20260923

# 실시간 압축 확인
sudo btrfs filesystem defragment -r -czstd /mnt/data

# 디스크 사용량 확인 (서브볼륨별)
sudo btrfs filesystem usage /mnt/data

# 무결성 검사
sudo btrfs scrub start /mnt/data
sudo btrfs scrub status /mnt/data
```

### best practice

- 스냅샷은 백업이 아닙니다. 하드디스크가 물리적으로 망가지면 스냅샷도 날아감 → 반드시 외부 백업과 병행
- `noatime` 옵션은 CoW와 결합하면 I/O 성능이 크게 향상됨
- zstd 압축은 CPU 사용량이 약간 증가하지만 디스크 용량 30~50% 절약 효과가 있음

## 6. ZFS — 엔터프라이즈 끝판왕

### 핵심 특징

ZFS는 데이터 무결성, 강력한 RAID, 대용량 캐싱을 내장한 파일 시스템입니다. 여러 개의 하드디스크를 묶어 안전하고 거대한 저장소를 만들 때 최적입니다.

- **checksum 기반 무결성**: 모든 블록의 checksum을 계산하여 데이터 오염을 자동 탐지
- **Self-healing**: 미러/RAID-Z 구성 시 오염된 블록을 자동으로 정상 블록으로 복구
- **ARC (Adaptive Replacement Cache)**: RAM을 디스크 캐시로 활용하여 반복 읽기 성능 극대화
- **ZFS on Linux**: 라이선스 문제로 커널 미내장, 별도 설치 필요

### practical 명령어

```bash
# ZFS 설치 (Ubuntu/Debian)
sudo apt install zfsutils-linux

# ZFS 풀 생성 (단일 디스크)
sudo zpool create datapool /dev/sdb1

# ZFS 풀 생성 (RAID-Z1 — 1디스크 패러티)
sudo zpool create datapool raidz1 /dev/sdb1 /dev/sdc1 /dev/sdd1

# ZFS 풀 생성 (RAID-Z2 — 2디스크 패러티)
sudo zpool create datapool raidz2 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

# ZFS 풀 상태 확인
zpool status datapool

# ZFS 풀 사용량 확인
zpool list datapool
zfs list

# 스냅샷 생성
sudo zfs snapshot datapool/home@backup-20260923

# 스냅샷 목록 확인
sudo zfs list -t snapshot

# 스냅샷에서 복구
sudo zfs rollback datapool/home@backup-20260923

# 자동 스냅샷 (zfs-auto-snapshot)
sudo apt install zfs-auto-snapshot
# 매시간 자동 스냅샷 (최대 24개 유지)
sudo zfs set com.sun:auto-snapshot:hourly=true datapool/home

# ZFS 풀 온라인 복구
sudo zpool scrub datapool

# 디스크 추가 (온라인 확장)
sudo zpool add datapool /dev/sdf1
```

### best practice

- ZFS는 RAM을 많이 소비합니다. 최소 8GB, 가능하면 16GB 이상 권장
- `arcstat` 명령어로 ARC 캐시 히트율을 모니터링하면 디스크 I/O 병목을 파악할 수 있음
- RAID-Z1은 3디스크 이상에서만 의미 있음. 2디스크는 미러링이 더 안전

## 7. 성능 벤치마크 비교

동일한 NVMe SSD 환경에서의 일반적인 성능 비교입니다. 실제 성능은 하드웨어, 워크로드, 옵션에 따라 달라집니다.

| 작업 | ext4 | XFS | Btrfs (압축 OFF) | Btrfs (zstd) | ZFS (lz4) |
|------|------|-----|-----------------|-------------|-----------|
| 순수 읽기 (4K 랜덤) | 빠름 | 빠름 | 빠름 | 빠름 | 보통 (ARC 적중 시 매우 빠름) |
| 순수 쓰기 (4K 랜덤) | 빠름 | 매우 빠름 | 보통 | 느림 | 느림 |
| 대용량 스트리밍 쓰기 | 빠름 | 매우 빠름 | 빠름 | 빠름 | 빠름 |
| 스냅샷 생성 | — | — | 즉시 (0.1초 이내) | 즉시 | 즉시 |
| 파일 복사 | 보통 | 보통 | 매우 빠름 (CoW) | 매우 빠름 | 보통 |
| 디스크 용량 활용 | 보통 | 보통 | 좋음 (압축 시) | 매우 좋음 | 좋음 (lz4) |

**핵심 포인트**: Btrfs의 CoW는 파일 복사 시 물리적 복사 없이 포인터만 생성하므로 수 GB 파일도 순간적으로 복사됩니다. zstd 압축은 CPU 부하가 약간 있지만 디스크 용량 30~50%를 절약합니다.

## 8. 실무 선택 가이드

### Case 1: "잘 모르겠고 안정적인 게 최고야" → ext4

일반적인 웹 서버, 가벼운 애플리케이션 서버, 개인용 리눅스 PC라면 ext4를 선택하세요. 수십 년간 검증된 안정성 덕분에 시스템이 예상치 못하게 다운되어도 데이터가 깨질 확률이 가장 적습니다.

```bash
# 가장 안전한 기본 구성
sudo mkfs.ext4 /dev/sdb1
sudo mount -o defaults,noatime,ordered /dev/sdb1 /mnt/data
```

### Case 2: "대용량 DB나 미디어 파일을 다뤄요" → XFS

MySQL/PostgreSQL 등 대규모 DB 서버, 로그 데이터가 기가바이트 단위로 쌓이는 서버, 영상 파일 등을 다룬다면 XFS가 정답입니다.

```bash
# DB 서버 최적 구성
sudo mkfs.xfs /dev/sdb1
sudo mount -o noatime,logbufs=8,logbsize=256k /dev/sdb1 /var/lib/mysql
```

### Case 3: "잦은 백업과 데이터 유실 방지가 중요해요" → Btrfs

가상 머신을 자주 생성하고 지우거나, 랜섬웨어 대비를 위해 매시간 파일 시스템을 백업해야 하는 환경이라면 Btrfs가 유용합니다.

```bash
# NAS/백업 최적 구성
sudo mkfs.btrfs /dev/sdb1
sudo mount -o defaults,noatime,compress=zstd /dev/sdb1 /mnt/data
sudo btrfs subvolume create /mnt/data/@data
sudo btrfs subvolume create /mnt/data/@snapshots

# 자동 스냅샷 스크립트 (crontab)
echo '0 * * * * root btrfs subvolume snapshot /mnt/data/@data /mnt/data/@snapshots/data-$(date +\%Y\%m\%d\%H)' > /etc/cron.d/btrfs-snapshot
```

### Case 4: "수십 TB 전문 백업/스토리지 서버" → ZFS

여러 개의 하드디스크를 묶어 안전하고 거대한 저장소를 만들고 싶다면 ZFS를 추천합니다.

```bash
# 스토리지 서버 최적 구성
sudo zpool create -o ashift=12 datapool raidz2 /dev/sd{b,c,d,e}
sudo zfs create -o compress=lz4 -o atime=off datapool/data
sudo zfs create -o compress=zstd datapool/backup
sudo zfs set com.sun:auto-snapshot:daily=true datapool/data
```

## 9. 2026년 추천 공식

| 사용 목적 | 추천 파일 시스템 | 이유 |
|----------|----------------|------|
| 일반 리눅스 PC/웹 서버 | **ext4** | 검증된 안정성, 호환성 최고 |
| 대규모 DB/미디어 서버 | **XFS** | 대용량 I/O 처리 최적화 |
| 백업/가상화/NAS | **Btrfs** | CoW 스냅샷, 실시간 압축 |
| 전문 스토리지/엔터프라이즈 | **ZFS** | Self-healing, RAID-Z, 무결성 |
| Docker/컨테이너 호스트 | **ext4** 또는 **XFS** | Docker 공식 추천 |

**최종 팁**: 파일 시스템은 한번 포맷하면 바꾸기 어렵습니다. 도입 전 반드시 자신의 워크로드(I/O 패턴, 데이터 크기, 백업 요구사항)를 파악한 뒤 선택하세요.