ext4, xfs, btrfs 파일 시스템 비교: 서버에서 뭐가 더 좋을까

왜 지금 파일 시스템 선택이 중요한가

컨테이너화와 NVMe 확산으로 서버의 I/O 패턴이 다양해졌다. 데이터 무결성, 성능, 운영 편의성을 균형 있게 가져가려면 파일 시스템의 설계 철학을 먼저 이해해야 한다. ext4, xfs, btrfs는 모두 리눅스에서 널리 쓰이지만, 강점이 미묘하게 다르다. 커널 문서와 배포판 가이드를 기준으로 핵심을 압축해 정리한다. (docs.kernel.org)

한눈에 보는 성격 차이

ext4: 성숙하고 범용적인 저널링 파일 시스템. 지연 할당, 익스텐트 등으로 성능·단편화 개선을 노린 실용 지향 설계. 리스크 낮고 관리가 쉽다. (docs.kernel.org)
xfs: 대규모 파일·순차 I/O에 강한 저널링 FS. 온라인 확장, 조각 모음, 외부 로그 디바이스 등으로 대용량 워크로드에서 일관된 처리량을 낸다. RHEL 계열이 기본값으로 채택해 운영 경험이 풍부하다. (레드햇 문서)
btrfs: CoW 기반의 스냅샷, 서브볼륨, 데이터/메타데이터 체크섬, 투명 압축 등 “데이터 서비스” 중심의 현대적 기능 제공. 관리 유연성이 큰 대신, 구성과 튜닝을 이해하고 써야 제 성능이 난다. (docs.kernel.org)

ext4: 안전한 기본값

ext4는 ext3의 계보를 잇되 64비트 확장성, 익스텐트, 지연 할당(allocate-on-flush)로 성능과 단편화 억제를 강화했다. 특정 워크로드에서 저널을 끄는 모드도 허용하지만, 일반 서버에서는 기본 저널링을 유지하는 편이 낫다. 대규모 기능은 적지만 예측 가능한 동작과 복구 용이성이 장점이다. (docs.kernel.org)

ext4가 빛나는 경우

범용 웹·애플리케이션 서버, 중소 규모 DB의 OS 파티션
단순한 운영 모델이 필요한 가상 서버(VPS)
RAID 컨트롤러 캐시를 적극 활용하는 환경

주의점

아주 큰 파일·디렉터리 트리를 장기간 다룰 때는 성능 튜닝 여지가 제한적
스냅샷·내장 압축 같은 고급 데이터 서비스는 외부 도구 의존

xfs: 대용량과 순차 I/O의 실력자

xfs는 SGI에서 설계된 대규모 병렬 I/O 지향 FS다. 메타데이터 저널링, 온라인 확장, 조각 모음, 분리된 로그 디바이스 지원 등으로 대형 파일, 백업 이미지, 로그 수집, 오브젝트 스토리지 노드에서 강점을 보인다. RHEL에서는 오랫동안 기본 FS로 운영돼 도구와 가이드가 잘 갖춰져 있다. (레드햇 문서)

xfs가 빛나는 경우

TB~PB급 볼륨, 대용량 연속 쓰기(백업, 미디어, 분석 결과물)
파일 수가 많아도 디렉터리 성능을 유지해야 하는 로그/아카이브
운영 중 파일시스템 확장과 조각 모음이 필요한 스토리지 노드

주의점

스냅샷·압축 같은 데이터 서비스는 LVM/스토리지 계층 또는 외부 솔루션 의존
작은 랜덤 I/O 위주 워크로드에서는 튜닝(예: 로그 장치, 매개변수)이 성패를 좌우한다. (docs.kernel.org)

btrfs: 기능의 종합선물세트

btrfs는 CoW 설계로 스냅샷(읽기/쓰기), 서브볼륨, 전면 체크섬(crc32c/xxhash/sha256/blake2b), 자동 복구, 디스크 추가/제거, 온라인 밸런스, 투명 압축(ZSTD 등)까지 파일 시스템 레벨에서 제공한다. 운영 체제 롤백, 빠른 클론, 공간 효율 최적화가 필요한 서버에서 높은 가치를 만든다. (btrfs.readthedocs.io)

btrfs가 빛나는 경우

스냅샷 기반의 패치 롤백, 테스트/배포 파이프라인
체크섬·스크럽로 사일런트 데이터 손상 탐지를 중시하는 저장소
NVMe 다중 장치에서 압축을 통한 용량/속도 균형 추구

주의점

CoW 특성상 빈번한 덮어쓰기 워크로드(예: 대형 DB의 데이터 파일)에서는 오버헤드가 생길 수 있어 마운트 옵션(NoCoW에 준하는 속성)·서브볼륨 설계가 중요하다.
성능 특성이 구성에 민감하며, 밸런스/스크럽 같은 유지보수 작업을 계획해야 한다. (btrfs.readthedocs.io)

성능 관점: “무엇을 빠르게 할 것인가”

벤치마크 경향을 요약하면, 순차 읽기/쓰기에서 xfs가 강하고, 다양한 혼합 워크로드에서는 ext4가 예측 가능하며, btrfs는 압축·스냅샷을 활용할 때 가치가 커진다. 다만 실제 성능은 스토리지(SSD/NVMe/RAID), 큐 깊이, 파일 크기 분포, 마운트 옵션에 크게 좌우된다. 최근 종합 비교 글도 비슷한 결론을 보여준다. (Onidel Cloud)

신뢰성과 복구

저널링: ext4와 xfs는 메타데이터 저널링으로 장애 후 빠른 일관성 회복을 제공한다. xfs는 외부 로그 장치를 분리해 경쟁을 줄일 수 있다. (docs.kernel.org)
무결성 검증: btrfs는 데이터와 메타데이터 모두에 체크섬을 적용해 사일런트 손상을 탐지·복구한다. ext4/xfs는 기본적으로 데이터 체크섬을 제공하지 않는다(메타데이터는 일부 보호). (docs.kernel.org)
스냅샷/복구 지점: btrfs는 네이티브 스냅샷·서브볼륨로 수초 단위의 복구 지점을 만들 수 있다. ext4/xfs는 LVM 스냅샷, 스토리지 어레이, ZFS 등 외부 도구에 의존한다. (btrfs.readthedocs.io)

운영 편의성과 생태계

배포판 기본값과 툴링: RHEL 계열은 xfs 중심의 운영 가이드를 오래 축적했다. btrfs는 서브볼륨·스냅샷 관리 도구(snapper 등)와 함께 쓰면 강력하지만, 정책 설계가 필요하다. ext4는 어디서나 통하는 “안전한 선택”으로 남아 있다. (레드햇 문서)
온라인 작업: xfs는 마운트된 상태에서의 확장과 조각 모음을 공식 지원한다. ext4도 온라인 조각 모음이 가능하지만, 대형 환경에서의 유연성은 xfs가 한 수 위다. (레드햇 문서)

워크로드별 추천 시나리오

컨테이너/쿠버네티스 노드

로그·이미지·아티팩트가 크고 순차 I/O가 많다면 xfs
단순성과 보편성을 원하면 ext4
노드 스냅샷·롤백으로 빠른 복구를 노린다면 btrfs(스냅샷 정책 포함)

데이터베이스

전통적 RDBMS(대형 데이터 파일, WAL/Redo)라면 ext4 또는 xfs에서 장치/마운트 옵션 튜닝
btrfs는 NoCoW 속성/서브볼륨 설계를 신중히 적용해 테스트 후 투입

파일·백업 서버

대용량 순차 쓰기/읽기: xfs
압축·중복 데이터가 많고 스냅샷 보존이 중요: btrfs

범용 웹/애플리케이션

운영 단순성과 호환성: ext4

선택 가이드: 체크리스트

데이터 특성

평균 파일 크기와 접근 패턴(랜덤/순차, 덮어쓰기/추가 쓰기)
무결성 검증·스냅샷·압축의 필요성(있다면 btrfs 우선 고려) (btrfs.readthedocs.io)

스토리지 및 확장성

단일 대용량 볼륨, 온라인 확장/조각 모음 필요(있다면 xfs) (레드햇 문서)
다중 장치·공간 효율(압축/밸런스) 요구(btrfs) (btrfs.readthedocs.io)

운영 문화와 생태계

조직 표준, 배포판 기본값, 백업/복구 도구의 호환성(xfs·ext4는 성숙, btrfs는 정책 설계 중요) (레드햇 문서)

결론: “만능”은 없다, 목적에 맞게 고르자

안정성과 범용성: ext4 — 최소한의 튜닝으로도 예측 가능한 결과를 원할 때
대용량·순차 성능과 성숙한 운영: xfs — 확장·조각 모음·큰 파일 처리에 강함
데이터 서비스와 유연성: btrfs — 스냅샷·체크섬·압축이 가치인 환경

새 서버를 배포한다면, OS 파티션은 ext4, 대용량 데이터 볼륨은 xfs, 스냅샷·무결성 검증이 중요한 구성에는 btrfs처럼 “혼합 전략”도 현실적이다. 실제 투입 전에는 동일 하드웨어에서 대표 워크로드로 간단한 파일 크기 분포·큐 깊이 별 I/O 리허설을 돌려 차이를 수치로 확인하자. 최근 비교 글과 공식 문서들이 보여주듯, 이 세 파일 시스템은 각자의 강점을 확실히 갖고 있다. (Onidel Cloud)