Linux / 파일 시스템 비교 – ext4·XFS·Btrfs의 차이와 선택 기준

ext4·XFS·Btrfs를 선택할 때는 어느 것이 더 최신인지보다 배포판의 지원, 필요한 기능, 크기 변경과 복구 방법을 먼저 비교해야 합니다. 익숙한 관리와 오프라인 축소가 중요하면 ext4, 큰 저장 공간과 동시 입출력을 고려하는 서버라면 XFS, 파일 시스템 자체의 스냅샷·압축·데이터 체크섬이 필요하면 Btrfs를 검토할 수 있습니다. 다만 이 구분은 선택의 출발점이며, 실제 성능과 운영 적합성은 사용하는 환경에서 확인해야 합니다.

이 글은 리눅스 PC와 일반 서버의 로컬 디스크용 파일 시스템 세 가지를 비교합니다. 파일 시스템은 파일의 내용과 이름·위치·권한 같은 정보를 저장하고 찾는 규칙입니다. 디스크·파티션·마운트의 관계가 헷갈린다면 디스크·파티션·파일 시스템을 구분하는 방법을 먼저 확인하면 비교 기준을 이해하기 쉽습니다.

ext4·XFS·Btrfs의 차이 한눈에 보기

메타데이터는 파일의 위치·크기·권한 등 관리 정보입니다. 저널링은 변경 기록을 이용해 비정상 종료 뒤 파일 시스템의 일관성을 회복하도록 돕는 방식이며, 백업이나 모든 파일 내용의 보존을 보장하는 기능은 아닙니다. Copy-on-Write(CoW, 변경 시 복사)는 수정할 내용을 새 공간에 기록하고 참조를 갱신하는 방식입니다.

여기서 ‘없음’은 파일 시스템 자체 기능을 기준으로 합니다. ext4·XFS도 논리 볼륨 관리자(Logical Volume Manager, LVM), 스토리지 장비나 가상화 플랫폼의 스냅샷을 활용할 수 있습니다. XFS의 reflink처럼 데이터 블록을 공유하는 파일 복사 기능도 파일 시스템 전체의 시점 스냅샷과는 다릅니다. 표의 체크섬 항목은 일반 파일의 내용을 대상으로 하며, ext4·XFS의 메타데이터 보호 기능이 없다는 뜻은 아닙니다.

ext4: 익숙한 관리와 오프라인 축소가 필요할 때

ext4는 Fourth Extended Filesystem의 약자로, ext2·ext3 계열을 잇는 파일 시스템입니다. Debian 13 설치 안내는 대부분의 경우 ext4가 기본으로 선택된다고 설명합니다. 특별한 기능 요구가 없는 시스템에서 배포판의 설치·복구 도구와 함께 검토하기 좋은 후보입니다. 다만 기본값이라는 이유로 다른 파일 시스템보다 항상 빠르거나 안전하다고 판단할 수는 없습니다. Debian 13 공식 설치 안내에서 배포판의 선택 기준을 확인할 수 있습니다.

ext4의 기본적인 data=ordered 모드는 메타데이터를 저널링하고 관련 데이터의 기록 순서를 관리합니다. 모든 파일 내용을 저널에 이중으로 저장하는 방식은 아니므로, 전원 장애 뒤 파일 시스템이 마운트된다는 사실과 애플리케이션의 마지막 쓰기가 보존된다는 사실을 구분해야 합니다. 관련 동작은 Linux 커널의 ext4 관리 문서에 설명되어 있습니다.

운영상 눈에 띄는 차이는 축소입니다. resize2fs는 조건에 맞는 ext4를 마운트 중 확장할 수 있지만, 축소는 마운트를 해제하고 진행해야 합니다. 루트 파일 시스템을 줄여야 한다면 일반적으로 별도 부팅 환경과 중단 시간이 필요합니다. 이 도구는 파티션 크기를 바꾸지 않으므로, 파일 시스템과 그 아래 저장 영역의 크기를 별도로 관리해야 합니다. resize2fs 매뉴얼을 기준으로 실제 환경의 지원 조건을 확인하세요.

예를 들어 하나의 디스크 공간을 나중에 운영체제와 데이터 영역 사이에서 재분배할 계획이 있다면 축소 가능 여부와 중단 시간을 미리 비교할 필요가 있습니다. 반대로 되돌리기용 스냅샷이 핵심 요구라면 ext4만 선택해서는 해결되지 않으며, LVM이나 별도 백업·스냅샷 계층까지 설계해야 합니다.

XFS: 큰 저장 공간과 동시 입출력을 고려하는 서버에서

XFS는 저장 공간을 할당 그룹으로 나누어 관리하며, 큰 파일과 여러 작업의 동시 입출력을 고려해 검토할 만한 파일 시스템입니다. Red Hat Enterprise Linux(RHEL) 10은 XFS를 기본 로컬 파일 시스템으로 사용합니다. 조직에서 사용하는 배포판, 스토리지 관리 도구와 복구 절차가 XFS를 중심으로 마련되어 있다면 그 운영 지원도 중요한 선택 근거입니다. RHEL 10의 파일 시스템 비교·관리 문서에서 지원 범위와 적용 조건을 확인할 수 있습니다.

XFS의 확장은 xfs_growfs로 마운트한 상태에서 수행합니다. 먼저 하위 장치에 실제로 더 큰 공간이 제공되어야 하며, 디스크나 논리 볼륨만 늘렸다고 파일 시스템이 자동으로 같은 크기가 되는 것은 아닙니다. 확장 계획에서는 디스크·파티션·논리 볼륨·파일 시스템 중 어느 계층을 바꾸는지 구분해야 합니다.

축소에 대해서는 ‘절대 불가능’과 ‘일반적으로 사용 가능’이라는 표현을 모두 피해야 합니다. RHEL 10.0 릴리스 노트에는 마지막 할당 그룹 안에서, 제거할 범위에 데이터와 메타데이터가 없는 경우의 제한적인 축소가 기술 미리보기(Technology Preview)로 안내되어 있습니다. 이는 임의의 크기로 줄이는 일반적인 운영 절차와 다릅니다. 축소가 중요한 요구라면 이 제한 기능을 전제로 선택하지 말고 배포판의 정식 지원을 확인하거나, 더 작은 새 파일 시스템으로 백업·복원하는 방법을 계획하세요. RHEL 10.0의 제한적 XFS 축소 안내와 xfs_growfs 매뉴얼에 조건이 나와 있습니다.

파일 공유 서버나 큰 데이터 파일을 다루는 서버라면 XFS를 후보에 넣되, 파일 크기만으로 결론 내리지는 마세요. 작은 파일의 생성·삭제 빈도, 동시에 접근하는 작업 수, 동기 쓰기와 지연 시간 요구까지 실제 서비스와 비슷한 조건에서 확인해야 합니다.

Btrfs: 스냅샷·압축·체크섬을 함께 활용하려면

Btrfs는 CoW를 기반으로 서브볼륨, 스냅샷, 투명 압축과 데이터·메타데이터 체크섬을 제공합니다. 체크섬은 저장한 내용에서 계산한 검증값으로, 다시 읽은 내용이 달라졌는지 판단하는 데 사용합니다. Fedora는 데스크톱 에디션과 스핀에서 Btrfs를 기본으로 사용합니다. 다만 기본 채택이 모든 서버·디스크 구성에 대한 지원을 뜻하지는 않습니다. Btrfs 공식 기능 소개와 Fedora의 Btrfs 안내를 참고하세요.

서브볼륨은 파일 시스템 안에서 독립적으로 관리할 수 있는 디렉터리 트리입니다. 스냅샷을 만들면 처음에는 원본과 데이터 블록을 공유하고, 이후 변경되는 부분에 따라 공간을 추가로 사용합니다. 업데이트 전 상태를 보관하는 데 활용할 수 있지만, Btrfs를 선택하는 것만으로 자동 스냅샷·보존 기간·부팅 복구 메뉴가 모두 구성되지는 않습니다. 배포판의 도구와 서브볼륨 구성을 함께 확인해야 합니다.

같은 디스크의 스냅샷은 별도 백업을 대신하지 않습니다. 원본과 스냅샷이 같은 저장 장치와 블록에 의존하므로 장치 고장이나 공유 블록 손상으로 둘 다 잃을 수 있습니다. 또한 중첩된 서브볼륨은 부모의 스냅샷에 재귀적으로 포함되지 않습니다. 데이터베이스처럼 쓰기 중인 애플리케이션은 자체 백업이나 쓰기 일시 정지 등 일관성을 확보하는 절차도 필요합니다. Btrfs 서브볼륨·스냅샷 문서는 스냅샷의 범위와 한계를 설명합니다.

오류 검출과 복구도 구분해야 합니다. btrfs scrub은 체크섬 등을 검사하지만, 손상된 내용을 복구하려면 해당 블록의 정상적인 중복 사본이 필요합니다. 단일 디스크에서 데이터가 한 벌만 저장되는 구성이라면 체크섬이 손상을 찾아도 원래 내용을 복원할 사본이 없을 수 있습니다. NOCOW로 설정된 파일은 데이터 체크섬이 적용되지 않는 예외도 있습니다. Btrfs scrub 공식 문서에서 검사·복구 조건을 확인할 수 있습니다.

압축은 데이터 특성에 따라 공간 사용량과 입출력을 줄일 수 있지만, 이미 압축된 영상·압축 파일에는 이점이 작을 수 있습니다. 잦은 덮어쓰기가 있는 가상 머신 이미지나 데이터베이스에서는 CoW와 단편화, 스냅샷 보존 정책을 함께 검토하세요. 성능만 보고 NOCOW를 일괄 적용하면 데이터 체크섬과 압축에도 영향을 줍니다. 관련 조건은 Btrfs 마운트 옵션 문서에 나와 있습니다.

여러 디스크를 묶을 때는 RAID(Redundant Array of Independent Disks, 여러 디스크를 조합하는 방식) 프로필별 상태도 따로 확인해야 합니다. 공식 기능 소개는 RAID5/6을 실험적이며 운영 환경에 적합하지 않은 상태로 설명합니다. 이를 다른 프로필과 같은 수준으로 취급하지 말고, 커널·도구 버전과 Btrfs 기능별 상태를 함께 확인하세요.

사용 환경에 따라 어떤 파일 시스템을 선택할까?

다음은 기능 차이를 실제 요구에 연결한 판단 기준입니다. 파일 시스템의 우열 순위나 모든 환경에 적용되는 권장 설정은 아닙니다.

예를 들어 업데이트 실패 뒤 운영체제를 되돌리는 것이 주목적이라면 Btrfs의 기능뿐 아니라 복구 도구가 어느 서브볼륨을 되돌리는지 확인해야 합니다. 운영체제만 복원하고 사용자 데이터는 유지하려는지, 둘을 같은 시점으로 맞춰야 하는지에 따라 설계가 달라집니다. 반대로 데이터 영역을 계속 늘리기만 하는 서버에서는 축소보다 배포판 지원과 확장·백업 절차가 더 중요한 기준일 수 있습니다.

성능 비교에서 반드시 맞춰야 할 조건

파일 시스템 이름만으로 속도를 예측하기는 어렵습니다. 같은 SSD에서도 작은 파일을 많이 만드는 작업, 큰 파일을 순차적으로 읽는 작업, 데이터베이스의 동기 쓰기는 서로 다른 결과를 낼 수 있습니다. 짧은 복사 작업은 메모리 캐시의 영향을 크게 받을 수도 있습니다.

• 저장 장치: 같은 SSD·HDD와 연결 방식, 사용량·여유 공간 조건을 사용합니다.
• 작업 특성: 파일 크기·개수, 읽기와 쓰기의 비율, 순차·임의 접근, 동시 작업 수를 맞춥니다.
• 기능과 설정: 압축, CoW, 스냅샷, 암호화와 마운트 옵션을 기록합니다. 기능을 켜거나 끈 결과를 같은 조건처럼 비교하지 않습니다.
• 보존 조건: 애플리케이션의 동기 쓰기와 저장 장치 캐시 정책을 맞춥니다. 데이터 보존 조건을 약하게 만든 설정을 단순한 성능 향상으로 평가하지 않습니다.
• 버전과 지표: 커널·관리 도구 버전을 기록하고 처리량뿐 아니라 지연 시간과 반복 실행의 변동도 확인합니다.

예를 들어 로그 저장 서버를 비교한다면 큰 파일 한 개의 복사 속도만 재지 말고, 실제 로그의 추가 쓰기·회전·압축·백업이 겹치는 조건을 시험해야 합니다. 이때 압축으로 사용 공간이 줄어드는 이점과 CPU 사용량이 늘어나는 비용도 함께 판단합니다. 작은 차이만 확인했다면 기존 파일 시스템을 바꾸는 이전 비용과 위험까지 고려하세요.

현재 형식 확인과 변경 전 점검

현재 시스템에서 읽기 전용으로 확인하기

일반적인 리눅스 환경에서 다음 명령은 장치·마운트·용량 정보를 조회합니다. lsblk와 findmnt는 util-linux, GNU/Linux의 df는 보통 coreutils에서 제공합니다. 이 명령들은 파일 시스템을 새로 만들거나 형식을 변경하지 않습니다.

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
findmnt -T / -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT /

lsblk에서는 장치 계층과 FSTYPE을, findmnt에서는 루트 경로를 담은 파일 시스템의 형식과 실제 마운트 옵션을 확인합니다. df -hT /는 루트 경로가 속한 파일 시스템의 형식과 용량을 보여 줍니다. / 대신 실제 데이터 디렉터리를 지정하면 해당 경로를 확인할 수 있습니다.

예를 들어 findmnt의 FSTYPE이 xfs라면 그 경로는 XFS 위에 있습니다. 디스크 자체 행의 FSTYPE이 비어 있어도 파티션이나 논리 볼륨 행에 형식이 표시될 수 있습니다. 컨테이너에서는 overlay 등으로 보일 수 있으므로 호스트 디스크의 형식이라고 단정하지 마세요. 오래된 lsblk가 MOUNTPOINTS를 지원하지 않으면 MOUNTPOINT로 바꾸어 조회합니다. 명령의 세부 옵션은 lsblk 매뉴얼과 findmnt 매뉴얼에서 확인할 수 있습니다.

Btrfs에서 공간이 예상과 다르면 btrfs filesystem usage로 데이터·메타데이터와 장치 할당을 함께 확인할 수 있습니다. 스냅샷이 참조하는 데이터가 남아 있으면 파일을 지운 만큼 공간이 곧바로 비지 않을 수 있습니다. 이때 일반적인 디렉터리 용량 합계만으로 판단하지 말고 Btrfs 공간 사용량·크기 변경 문서의 기준을 적용합니다.

새 파일 시스템으로 이전할 때의 순서

기존 파일 시스템에 다른 형식의 mkfs를 실행하는 것은 데이터를 보존하는 전환 방법이 아닙니다. 일반적인 이전 계획은 다음처럼 새 대상과 복원 검증을 중심으로 세우는 편이 이해하기 쉽습니다.

1. 원본 장치·형식·마운트 지점과 애플리케이션의 지원 조건을 확인하고, 독립된 저장 장치에 백업한 뒤 실제로 복원 가능한지 확인합니다.
2. 새 디스크나 별도로 확보한 영역에 대상 파일 시스템을 준비합니다. 포맷 전에는 비어 있는 대상이 맞는지 다시 확인합니다.
3. 서비스 중단이나 애플리케이션 자체 백업으로 데이터 일관성을 확보하고, 소유권·권한·접근 제어 목록(ACL)·확장 속성·하드 링크 등 필요한 정보를 보존해 복사하거나 복원합니다. 파일 내용만 복사하는 도구가 이 정보를 모두 보존한다고 가정하지 않습니다.
4. 새 경로에서 파일과 애플리케이션을 검증하고, 새 UUID(파일 시스템 식별자)를 기준으로 /etc/fstab과 관련 서비스 설정을 수정합니다. 운영체제 루트 영역 이전은 부트로더·초기 부팅 환경까지 포함한 별도 절차가 필요합니다.
5. 재부팅 후 마운트·서비스·권한을 확인합니다. 문제가 있으면 새 대상에 대한 쓰기를 멈추고 검증된 원본과 설정으로 돌아갈 수 있도록, 전환 확인이 끝날 때까지 원본과 백업을 보관합니다. 전환 뒤 새로 생긴 데이터도 되돌리기 계획에 포함합니다.

같은 파일 시스템 안에서 크기만 바꿀 때도 계층의 순서가 중요합니다. 확장은 보통 하위 저장 공간을 먼저 늘린 뒤 파일 시스템을 확장하고, 축소는 지원되는 파일 시스템을 먼저 줄인 뒤 하위 저장 공간을 줄입니다. Btrfs도 파일 시스템 크기 변경이 파티션 표를 자동 수정하는 것은 아닙니다. 이 원칙은 구체적인 실행 절차를 대신하지 않으므로 암호화·LVM·RAID가 있으면 각 계층의 지원 절차를 확인하세요.

오류가 있을 때는 파일 시스템에 맞는 도구를 사용해야 합니다. ext4의 e2fsck, XFS의 xfs_repair, Btrfs의 검사·복구 도구는 서로 대체할 수 없습니다. 특히 btrfs check --repair를 일반적인 첫 해결책으로 실행하지 마세요. 공식 문서는 숙련된 사용자나 개발자의 조언 없이 이 옵션을 사용하지 않도록 안내합니다. fsck와 파일 시스템별 점검 시 주의점, Btrfs 검사 도구의 경고를 확인하고, 변경 전 백업과 복구 계획을 우선 준비하세요.