목차
- 왜 XFS와 Btrfs, 파일 시스템 선택이 중요한가요?
- XFS vs Btrfs 비교: 개념부터 쉽게 정리
- XFS는 어떤 파일 시스템인가요?
- Btrfs는 어떤 파일 시스템인가요?
- 제가 1년 운영하면서 나눈 기준
- 실전 구현: XFS와 Btrfs 세팅 방법
- 1. XFS 파일 시스템 생성과 마운트
- 2. Btrfs 파일 시스템 생성과 서브볼륨 구성
- 3. Btrfs 스냅샷 생성
- 4. 사용 상태 확인
- 운영하면서 느낀 XFS 성능과 Btrfs 체감 차이
- ⚠️ 주의사항과 트러블슈팅
- 1. Btrfs는 스냅샷이 많아지면 관리가 필요합니다
- 2. 데이터베이스나 VM 이미지처럼 쓰기 패턴이 민감한 경우
- 3. XFS는 축소(shrink)가 까다롭습니다
- 4. 마운트 옵션은 기본값만 맹신하지 마세요
- 검증: 실제 운영에서 어떻게 확인했나
- 그래서 어떤 파일 시스템 선택이 맞을까요?
- 정리 및 FAQ
- Q1. 초보자라면 XFS와 Btrfs 중 뭐가 더 쉬운가요?
- Q2. Btrfs 스냅샷만 보고 선택해도 될까요?
- Q3. 리눅스 파일 시스템을 서버마다 다르게 써도 괜찮나요?
[리눅스] XFS vs Btrfs: 1년 운영 후기와 선택 기준
XFS Btrfs 비교 이야기는 리눅스 서버 좀 굴려보신 분들이라면 한 번쯤은 꼭 부딪히는 주제입니다. 저도 홈랩에서 VM, 컨테이너, 백업 스토리지까지 이것저것 올려두고 1년 넘게 굴려보니까, 처음엔 "파일 시스템이 다 거기서 거기 아닌가?" 싶었는데 실제로 써보면 차이가 꽤 크더라고요. 특히 리눅스 파일 시스템을 고를 때 성능만 볼지, 복구 편의성을 볼지, Btrfs 스냅샷 같은 운영 기능까지 볼지에 따라 선택이 완전히 달라집니다.
이번 글에서는 제가 실제 운영하면서 느낀 점을 바탕으로, XFS 성능이 빛나는 구간과 Btrfs 스냅샷이 진짜 편했던 상황을 같이 정리해보겠습니다. 숫자 벤치마크를 과장해서 들이밀기보다는, 운영할 때 몸으로 느껴지는 차이를 중심으로 보시면 됩니다.
홈랩 환경에서 XFS와 Btrfs의 특성과 선택 포인트를 비교하는 개요 이미지입니다.
왜 XFS와 Btrfs, 파일 시스템 선택이 중요한가요?
서버를 처음 세팅할 때는 CPU, RAM, 스토리지 용량부터 보게 되죠. 근데 실제로 오래 굴리다 보면 마지막에 발목 잡는 게 파일 시스템인 경우가 꽤 많습니다. 쉽게 말해 파일 시스템은 "디스크를 어떻게 쓰고, 보호하고, 복구할지"를 정하는 운영의 바닥층이거든요.
- XFS: 대용량 파일 처리와 안정적인 일반 운영에 강한 전통적인 파일 시스템입니다.
- Btrfs: Copy-on-Write(COW, 쓰기 시 복사) 구조를 기반으로 스냅샷, 서브볼륨, 체크섬 같은 기능을 제공하는 파일 시스템입니다.
여기서 중요한 포인트! 같은 SSD를 써도, 같은 리눅스 배포판을 써도 파일 시스템이 달라지면 백업 방식, 장애 대응 방식, 체감 성능이 꽤 달라져요. 저도 처음엔 용량만 보고 만들었다가, 나중에 스냅샷이 아쉬워서 마이그레이션 삽질 좀 했습니다 ㅎㅎ
XFS vs Btrfs 비교: 개념부터 쉽게 정리
XFS는 어떤 파일 시스템인가요?
XFS는 오래 검증된 고성능 파일 시스템입니다. 대용량 파일, 연속 쓰기, 안정적인 처리에 강한 편이고, 서버 운영에서 무난하게 선택하기 좋거든요. 특히 로그 저장소, 미디어 파일, 백업 저장소처럼 "꾸준히 쓰고 읽는" 패턴에서 편하더라고요.
Btrfs는 어떤 파일 시스템인가요?
Btrfs는 기능이 많은 쪽입니다. Subvolume(서브볼륨, 논리적 분리 단위), Snapshot(스냅샷, 특정 시점 상태 보존), Checksum(체크섬, 데이터 무결성 검증) 같은 운영 기능이 내장돼 있어요. 쉽게 말해 "파일 시스템 안에 운영 툴킷이 같이 들어있다"고 보시면 됩니다.
| 항목 | XFS | Btrfs |
|---|---|---|
| 기본 성격 | 전통적이고 안정적인 고성능 파일 시스템 | 기능 중심의 현대적 파일 시스템 |
| 스냅샷 | 기본 제공 없음 | 기본 제공 |
| 체크섬 | 기본 데이터 체크섬 중심 구조 아님 | 메타데이터/데이터 무결성 검증에 강점 |
| 확장/운영 감각 | 단순하고 예측 가능 | 기능이 많아 이해할 포인트가 더 많음 |
| 추천 용도 | 일반 서버, 로그, 대용량 파일 저장 | 백업, 실험 환경, 롤백이 필요한 서버 |
제가 1년 운영하면서 나눈 기준
실제로 써보니까 저는 기준을 딱 세 가지로 나누게 되더라고요.
- 속도가 우선인가? 대용량 파일을 단순하게 밀어 넣고 읽는 작업이 많으면 XFS 쪽이 마음이 편했어요.
- 롤백이 중요한가? 설정을 자주 바꾸거나 패키지 업데이트가 잦은 서버는 Btrfs가 정말 편했습니다.
- 운영 복잡도를 감당할 수 있나? Btrfs는 좋지만 구조를 모르고 쓰면 "왜 용량이 안 줄지?", "스냅샷이 왜 이렇게 많지?" 같은 상황이 생기더라고요.
혹시 이런 경험 있으신가요? 서비스는 잘 돌고 있는데, 업데이트 한 번 잘못해서 복구 포인트가 없어 멘붕 오는 상황이요. 저는 그때 Btrfs의 장점을 제대로 체감했습니다.
실전 구현: XFS와 Btrfs 세팅 방법
이제 실제로 어떻게 구성하는지 보겠습니다. 아래 예시는 추가 디스크가 <code>/dev/sdb라고 가정했어요. 운영 환경에서는 디스크 이름을 꼭 다시 확인하세요.
1. XFS 파일 시스템 생성과 마운트
lsblk
sudo mkfs.xfs /dev/sdb
sudo mkdir -p /data
sudo mount /dev/sdb /data
sudo blkid /dev/sdb
blkid로 UUID를 확인한 다음 /etc/fstab에 등록하면 재부팅 후에도 자동 마운트돼요.
UUID=YOUR-UUID /data xfs defaults,noatime 0 0
noatime은 access time(접근 시간) 갱신을 줄여서 불필요한 쓰기를 덜어주는 옵션입니다. 무조건 정답은 아니지만, 일반적인 서버 데이터 볼륨에서는 꽤 자주 쓰는 편입니다.
2. Btrfs 파일 시스템 생성과 서브볼륨 구성
lsblk
sudo mkfs.btrfs /dev/sdb
sudo mkdir -p /btrfs
sudo mount /dev/sdb /btrfs
sudo btrfs subvolume create /btrfs/@
sudo btrfs subvolume create /btrfs/@data
sudo btrfs subvolume create /btrfs/@snapshots
sudo umount /btrfs
sudo mount -o subvol=@ /dev/sdb /btrfs
저는 Btrfs를 쓸 때 서브볼륨을 미리 나누는 편이에요. 나중에 스냅샷 정책을 다르게 가져가기 편하거든요. 처음엔 이게 뭔가 싶었는데, 한 번 구조를 잡아두면 운영이 훨씬 수월합니다.
Btrfs 서브볼륨, 데이터 영역, 스냅샷 영역이 어떻게 나뉘는지 보여주는 구성 이미지입니다.
3. Btrfs 스냅샷 생성
sudo btrfs subvolume snapshot /btrfs /btrfs/@snapshots/root-2026-07-21
sudo btrfs subvolume list /btrfs
이게 왜 좋냐면, 패키지 업데이트 전이나 설정 변경 전에 스냅샷 하나 떠두면 심리적으로 엄청 편해요. 잘못 건드려도 "일단 돌아갈 구멍"이 생기니까요.
4. 사용 상태 확인
df -h
sudo btrfs filesystem usage /btrfs
sudo xfs_info /data
XFS는 구조가 비교적 단순해서 확인 포인트도 직관적입니다. 반면 Btrfs는 usage를 볼 때 메타데이터와 실제 사용량 감각이 좀 다를 수 있더라고요. 여기서 헷갈리는 분들 많습니다.
운영하면서 느낀 XFS 성능과 Btrfs 체감 차이
이 부분은 벤치마크 숫자보다, 운영자가 느끼는 감각에 가깝습니다.
- XFS 성능: 큰 파일을 다루거나 단순한 데이터 볼륨으로 쓸 때 일관성이 정말 좋았어요. 특별히 신경 쓸 요소가 적어서 운영 피로도가 낮습니다.
- Btrfs: 스냅샷과 롤백의 편의성이 압도적이에요. 다만 COW 특성 때문에 쓰기 패턴에 따라 체감이 달라질 수 있고, 운영자가 구조를 이해해야 합니다.
- 백업 관점에서는 Btrfs가 훨씬 매력적이었어요. 스냅샷을 기준으로 관리 포인트를 잡기 쉽거든요.
- 장기 운영 안정감은 둘 다 충분히 실사용 가능했지만, 단순함은 확실히 XFS 쪽이 강했습니다.
| 운영 시나리오 | 제가 더 선호한 선택 | 이유 |
|---|---|---|
| 미디어 저장소 | XFS | 큰 파일 위주, 단순 운영, 예측 가능한 성능 |
| 홈서버 애플리케이션 데이터 | Btrfs | 업데이트 전 스냅샷과 롤백이 편함 |
| 백업 테스트 환경 | Btrfs | 시점 관리가 수월함 |
| 일반 데이터 볼륨 | XFS | 설정 후 잊고 쓰기 좋음 |
⚠️ 주의사항과 트러블슈팅
여기는 꼭 보셔야 합니다. 저도 처음에 몇 번 삽질했던 부분이거든요.
1. Btrfs는 스냅샷이 많아지면 관리가 필요합니다
스냅샷이 편하다고 막 쌓아두면 용량 감각이 흐려져요. 지웠는데도 공간이 바로 안 돌아오는 것처럼 느껴질 때가 있거든요. 주기적으로 정리 정책을 잡는 게 정말 중요합니다.
sudo btrfs subvolume list /btrfs
sudo btrfs subvolume delete /btrfs/@snapshots/root-2026-07-21
2. 데이터베이스나 VM 이미지처럼 쓰기 패턴이 민감한 경우
Btrfs의 COW 특성이 항상 이득만 주는 건 아니에요. 워크로드에 따라 쓰기 증폭이나 단편화 체감이 생길 수 있거든요. 이런 경우는 애초에 XFS 쪽이 더 편할 때가 많습니다. 제가 직접 써보니 "기능이 많다"와 "내 워크로드에 맞다"는 완전히 다른 문제더라고요.
3. XFS는 축소(shrink)가 까다롭습니다
XFS는 확장은 편하지만 축소는 일반적으로 간단하지 않아요. 그래서 파티션 설계할 때 처음부터 여유를 두는 게 좋습니다. 이건 나중에 손대려면 꽤 귀찮아집니다.
4. 마운트 옵션은 기본값만 맹신하지 마세요
예를 들어 SSD, 로그 저장소, 백업 볼륨은 성격이 다르죠. noatime 같은 옵션도 환경에 맞게 써야 해요. 이전 글에서 다뤘던 스토리지 레이아웃 정리 방식과 같이 보시면 더 이해가 쉬우실 겁니다. RAID나 LVM 위에 올릴 때는 계층별 책임도 같이 봐야 하고요.
검증: 실제 운영에서 어떻게 확인했나
저는 새로 만든 파일 시스템을 바로 실서비스에 넣지 않고, 꼭 아래 순서로 검증했습니다.
- 테스트 디렉터리에 더미 데이터 복사
- 재부팅 후 자동 마운트 확인
- Btrfs라면 스냅샷 생성/삭제 동작 확인
- 로그와 권한이 유지되는지 확인
- 백업 스크립트와 충돌 없는지 점검
mount | grep -E 'xfs|btrfs'
findmnt /data
findmnt /btrfs
sudo btrfs subvolume list /btrfs
이렇게 확인해두면 "마운트는 됐는데 기대한 서브볼륨이 아니네?" 같은 사고를 줄일 수 있어요. 별거 아닌 것 같아도 이 검증 루틴이 장애를 꽤 많이 막아주더라고요.
XFS와 Btrfs의 사용량, 스냅샷, 마운트 상태를 점검하는 운영 검증 이미지입니다.
그래서 어떤 파일 시스템 선택이 맞을까요?
정리하면 이렇습니다.
- XFS를 추천하는 경우: 대용량 데이터, 단순 운영, 예측 가능한 성능이 중요할 때
- Btrfs를 추천하는 경우: 스냅샷, 롤백, 실험 환경, 백업 관리가 중요할 때
- 둘 중 하나가 절대 정답은 아니에요. 서버 역할에 따라 나눠 쓰는 게 훨씬 현실적입니다.
저는 지금도 전부 한쪽으로 통일하지 않습니다. 미디어 저장소나 덤프 저장소는 XFS, 자주 만지는 애플리케이션 데이터나 테스트 서버는 Btrfs 쪽이 더 잘 맞았어요. 사실 운영은 "이론상 최고"보다 "내 장애 패턴에 잘 맞는가"가 훨씬 중요하거든요.
XFS와 Btrfs의 선택 기준을 한눈에 정리한 요약 비교 이미지입니다.
정리 및 FAQ
Q1. 초보자라면 XFS와 Btrfs 중 뭐가 더 쉬운가요?
보통은 XFS가 더 단순해요. 구성 후 운영 감각이 직관적이거든요.
Q2. Btrfs 스냅샷만 보고 선택해도 될까요?
스냅샷은 정말 강력하지만, 워크로드 특성도 같이 봐야 합니다. 특히 쓰기 패턴이 민감한 데이터는 꼭 테스트해보세요.
Q3. 리눅스 파일 시스템을 서버마다 다르게 써도 괜찮나요?
오히려 그게 훨씬 현실적이에요. 용도별로 나누면 운영이 편해집니다.
이번 글을 한 줄로 줄이면 이겁니다. XFS는 단순하고 강하고, Btrfs는 유연하고 똑똑합니다. 제가 1년 운영해보니 둘 다 장점이 분명했고, 결국 중요한 건 서버 역할에 맞춰 고르는 기준이었어요. 다음 글에서는 Btrfs 스냅샷 자동화와 백업 스크립트 연동 방법도 정리해보겠습니다. 그 글까지 보시면 파일 시스템 선택에서 한 단계 더 앞으로 가실 수 있을 겁니다. 🎉
'IT > Linux' 카테고리의 다른 글
| [Linux] APT vs Snap: 리눅스 패키지 관리, 1년 사용 후기 및 생태계 분석 (0) | 2026.07.22 |
|---|---|
| [Linux] sudo 권한 문제 해결: 'is not in the sudoers file' 오류 및 권한 설정 디버깅 (0) | 2026.07.22 |
| [Linux] SSH 하드닝 실전 가이드: 무단 접근 방어 5단계 보안 강화 (0) | 2026.07.22 |
| [리눅스 스토리지] LVM 볼륨 확장 및 축소: 실전 마이그레이션 시나리오 분석 (0) | 2026.07.19 |
| [Linux] tmux 세션 관리 실패 사례: 복구 및 재발 방지 전략 (1) | 2026.07.18 |
| [Linux] zsh vs bash: 쉘 스크립팅 생산성 1년 실측 비교 (0) | 2026.07.18 |