[리눅스] LVM vs 일반 파티션: 서버 디스크 구성, 무엇을 선택해야 할까?

리눅스 서버를 처음 세팅할 때 은근히 오래 고민하게 되는 게 바로 LVM 일반 파티션 비교입니다. 디스크를 한 번 나눠 놓으면 나중에 바꾸기 번거롭거든요. 특히 운영 중인 서버에서 용량이 부족해지면, 그때부터는 단순한 설정 문제가 아니라 장애 예방 이슈가 됩니다. 저도 처음엔 그냥 <code>fdisk로 파티션 나누고 끝내면 되는 거 아닌가 싶었는데, 실제로 서버를 몇 번 굴려보니까 상황이 그렇게 단순하지 않더라고요. 어떤 서버는 일반 파티션이 훨씬 단순해서 관리가 편했고, 또 어떤 서버는 LVM(Logical Volume Manager, 논리 볼륨 관리자)을 안 써서 나중에 꽤 크게 삽질했습니다 ㅎㅎ

이번 글에서는 리눅스 디스크 구성 관점에서 LVM과 일반 파티션을 어떻게 봐야 하는지, 어떤 상황에서 무엇을 선택하면 좋은지, 그리고 실제 서버에서 어떻게 구성하고 확인하는지 차근차근 정리해보겠습니다.

일반 파티션과 LVM의 구조를 한눈에 비교하는 개요 이미지입니다.

LVM과 일반 파티션, 쉽게 말하면 뭐가 다른가요?

쉽게 말해 일반 파티션은 디스크를 잘라서 바로 파일시스템을 올리는 방식입니다. 예를 들어 /dev/sda1에 바로 ext4를 만들고 /var에 마운트하는 식이죠. 구조가 단순합니다. 그래서 장애 분석할 때도 직관적입니다.

반면 LVM은 한 단계를 더 둡니다. 물리 디스크나 파티션을 PV(Physical Volume, 물리 볼륨)로 만들고, 그걸 모아 VG(Volume Group, 볼륨 그룹)를 만든 뒤, 그 안에서 LV(Logical Volume, 논리 볼륨)를 잘라 쓰는 방식입니다. 처음엔 이게 뭔가 싶었는데, 익숙해지고 나면 “아, 디스크를 좀 더 유연하게 다루기 위한 추상화 계층이구나” 하고 이해되더라고요.

여기서 중요한 포인트가 있습니다.

• 일반 파티션: 단순하고 빠르게 이해 가능
• LVM: 유연하고 확장/재배치가 쉬움
• 대신 LVM은 계층이 하나 더 있으니 초반 학습 비용이 있습니다

LVM 일반 파티션 비교: 어떤 차이가 실제 운영에서 체감될까?

문서상 기능보다 실무 체감이 더 중요하죠. 제가 직접 해보니 차이는 아래에서 확실히 갈렸습니다.

예를 들어 로그가 많이 쌓이는 서버에서 /var만 빨리 커지는 경우가 있거든요. 일반 파티션으로 딱딱 나눠 두면 남는 공간은 다른 파티션에 있는데 정작 필요한 곳은 못 늘리는 상황이 생깁니다. 반대로 LVM이면 볼륨 그룹 안에 여유 공간이 있을 때 비교적 수월하게 확장할 수 있습니다. 이거 진짜 편하더라고요.

일반 파티션이 더 나은 경우도 분명 있습니다

LVM이 무조건 정답은 아닙니다. 저도 홈랩에서 아주 작은 테스트 머신이나, 금방 버릴 실험용 VM(Virtual Machine, 가상 머신)에는 일반 파티션을 자주 써요. 이유는 간단합니다. 빠르고, 설명하기 쉽고, 복잡도가 낮기 때문입니다.

일반 파티션을 추천하는 상황

• 단일 디스크에 간단한 서버를 빠르게 구성할 때
• 용량 확장 계획이 거의 없을 때
• 운영자가 LVM 구조를 굳이 알 필요 없는 환경일 때
• 복구 절차를 최대한 단순하게 가져가고 싶을 때

특히 부트 파티션이나 아주 단순한 웹 서버는 일반 파티션으로도 충분한 경우가 많습니다. 복잡한 도구를 넣는다고 항상 더 좋은 건 아니거든요.

LVM 장점이 빛나는 상황: 서버 파티션을 유연하게 가져가야 할 때

반대로 LVM 장점이 확실히 보이는 구간도 있습니다. 운영 서버에서 디스크 사용량이 예측대로 안 움직일 때입니다. DB(Database, 데이터베이스) 서버, 로그 서버, 백업 서버는 특히 그렇습니다.

LVM이 유리한 대표 상황

• /var, /home, /data 중 어디가 커질지 애매할 때
• 나중에 디스크를 추가해서 공간을 합칠 가능성이 있을 때
• 서비스 중단 시간을 줄이며 디스크 확장을 준비해야 할 때
• 볼륨을 논리적으로 나눠 관리하고 싶을 때

실제로 써보니까 초기에 조금 더 손이 가는 대신, 나중에 “아, 그때 LVM으로 해두길 잘했다” 싶은 순간이 옵니다. 특히 예측 실패를 흡수하는 능력이 꽤 큽니다.

실전 구현 1: 일반 파티션으로 리눅스 디스크 구성하기

먼저 가장 단순한 방식부터 보겠습니다. 새 디스크가 /dev/sdb로 붙었다고 가정해볼게요. 파티션 작업 도구로는 fdisk나 parted를 많이 써요. MBR(Master Boot Record)보다 GPT(GUID Partition Table)를 더 많이 쓰는 환경에서는 parted가 좀 더 편하더라고요.

1. 디스크 확인
2. 파티션 생성
3. 파일시스템 생성
4. 마운트 및 /etc/fstab 등록

lsblk
sudo fdisk /dev/sdb
sudo mkfs.ext4 /dev/sdb1
sudo mkdir -p /data
sudo mount /dev/sdb1 /data
df -h

parted를 쓰면 이런 식으로도 가능합니다.

sudo parted /dev/sdb --script mklabel gpt
sudo parted /dev/sdb --script mkpart primary ext4 1MiB 100%
sudo mkfs.ext4 /dev/sdb1

그리고 재부팅 후에도 유지되게 하려면 UUID(Universally Unique Identifier, 고유 식별자) 기준으로 /etc/fstab에 등록하는 게 좋습니다.

sudo blkid /dev/sdb1

UUID=xxxx-xxxx /data ext4 defaults 0 2

여기까지는 정말 단순합니다. 그래서 입문자 입장에선 일반 파티션이 덜 부담스럽습니다.

일반 파티션을 생성하고 파일시스템을 만드는 실전 예시 이미지입니다.

실전 구현 2: LVM으로 서버 파티션 구성하기

이제 LVM 방식입니다. 단계는 조금 더 많지만, 구조만 이해하면 어렵지는 않습니다.

1. 디스크 또는 파티션을 PV로 초기화
2. PV를 묶어 VG 생성
3. VG에서 LV 생성
4. 파일시스템 생성 후 마운트

lsblk
sudo pvcreate /dev/sdb
sudo vgcreate vg_data /dev/sdb
sudo lvcreate -n lv_data -L 100G vg_data
sudo mkfs.ext4 /dev/vg_data/lv_data
sudo mkdir -p /data
sudo mount /dev/vg_data/lv_data /data
df -h

남는 공간을 VG 안에 남겨두면 나중에 필요할 때 확장하기 좋습니다. 예를 들어 /data가 부족해졌다면 아래처럼 진행할 수 있습니다.

sudo lvextend -L +50G /dev/vg_data/lv_data
sudo resize2fs /dev/vg_data/lv_data

XFS(X File System, 고성능 파일시스템)를 쓰는 환경이라면 확장 명령이 다를 수 있습니다.

sudo lvextend -L +50G /dev/vg_data/lv_data
sudo xfs_growfs /data

처음엔 이 명령어 순서가 꽤 헷갈렸습니다. 저도 처음엔 파일시스템 확장 전에 뭘 확인해야 하는지 자꾸 놓쳤거든요. 근데 몇 번 해보면 패턴이 잡힙니다. 핵심은 “LV를 먼저 늘리고, 그 위 파일시스템을 확장한다”입니다.

⚠️ 제가 실제로 겪었던 주의사항과 트러블슈팅

이 섹션이 사실 제일 중요합니다. 문법보다 운영 실수에서 더 많이 터지거든요.

1. 파일시스템 종류를 확인 안 하고 확장

예전에 ext4인 줄 알고 습관적으로 명령을 넣었다가, 실제로는 XFS라서 한 번 멈칫했던 적이 있습니다. 다행히 큰 문제는 없었지만, 운영 서버였다면 식은땀 좀 났을 겁니다. 확장 전에 아래 명령으로 꼭 확인하세요.

df -Th
lsblk -f

2. 파티션은 늘렸는데 파일시스템 확장을 안 함

이거 진짜 자주 나옵니다. LV나 파티션 크기는 커졌는데, 실제 마운트 용량은 그대로인 경우요. 대부분 파일시스템 확장 단계를 빠뜨린 겁니다. “왜 안 늘었지?” 하면서 한참 봤던 기억 있으실 수도 있습니다.

3. 일반 파티션에서 설계를 너무 촘촘하게 잡음

/, /var, /home, /tmp를 너무 빡빡하게 나눠놓으면 나중에 한 군데만 부족해져도 골치 아픕니다. 처음엔 안전해 보였는데, 실제 운영에선 예측이 빗나가더라고요. 그래서 요즘은 정말 이유가 있는 경우에만 세분화합니다.

4. 디스크 이름만 믿고 작업

클라우드나 가상화 환경에서는 디스크 이름이 생각보다 달라질 수 있습니다. /dev/sdb라고 확신하고 작업했다가 다른 디스크를 건드리면 큰일이죠. 작업 전에 lsblk, blkid로 구조를 꼭 다시 확인하셔야 합니다.

• 작업 전: 대상 디스크 확인
• 작업 중: 현재 마운트 상태 확인
• 작업 후: 재부팅 후 자동 마운트 확인

LVM 확장 시 PV, VG, LV, 파일시스템 순서를 이해하기 쉽게 보여주는 이미지입니다.

검증: 지금 내 서버 디스크 구성이 제대로 되었는지 확인하는 방법

구성은 했는데 진짜 잘 된 건지 확인해야죠. 저는 아래 순서로 봅니다.

1. lsblk로 디스크, 파티션, LVM 계층 확인
2. df -h로 실제 마운트 용량 확인
3. mount 또는 findmnt로 마운트 포인트 확인
4. /etc/fstab 등록 상태 확인

lsblk
sudo pvs
sudo vgs
sudo lvs
df -h
findmnt
cat /etc/fstab

일반 파티션이라면 pvs, vgs, lvs는 필요 없지만, LVM 환경에서는 이 세 개가 거의 기본 점검 세트입니다. 결과가 예상한 구조와 맞는지 꼭 보세요.

검증이 끝나면 드디어 됐다! 싶은 순간이 옵니다. 디스크 관련 작업은 조용해 보여도 실제론 꽤 민감해서, 확인 단계까지 끝내야 마음이 놓이더라고요.

구성 완료 후 디스크, 볼륨, 마운트 상태를 검증하는 결과 예시 이미지입니다.

그래서 무엇을 선택해야 할까? 제 기준을 정리해보면

결론은 이렇습니다. LVM vs 일반 파티션은 우열의 문제가 아니라 운영 방식의 문제입니다.

• 작고 단순한 서버: 일반 파티션이 편합니다
• 확장 가능성이 있는 운영 서버: LVM이 유리합니다
• 팀 내 운영자 숙련도가 낮고 단순성이 중요: 일반 파티션 쪽이 낫습니다
• 용량 재배치와 확장 대응이 중요: LVM 쪽이 낫습니다

저는 요즘 이렇게 갑니다. 부트 영역은 단순하게 두고, 데이터 영역은 LVM으로 가져가는 식이 많습니다. 완전한 정답은 아니지만 실무 밸런스가 좋았습니다. 특히 로그, 데이터, 백업이 커질 가능성이 있는 서버라면 더 그렇고요.

자주 묻는 질문

Q1. LVM이 성능상 불리한가요?

일반적인 서버 운영 관점에서는 구조적 유연성이 더 큰 고려 포인트인 경우가 많습니다. 성능보다 관리 편의성과 확장성을 우선해서 판단하는 경우가 많더라고요.

Q2. 초보자는 무조건 일반 파티션이 나을까요?

꼭 그렇진 않습니다. 다만 서버 파티션 구조를 처음 익히는 단계라면 일반 파티션으로 감을 잡고, 이후 LVM으로 넘어가는 흐름이 이해에는 도움이 됩니다.

Q3. 이미 일반 파티션으로 만든 서버도 괜찮을까요?

네, 괜찮습니다. 지금 당장 문제가 없고 확장 계획도 뚜렷하지 않다면 굳이 복잡하게 바꿀 필요는 없습니다. 중요한 건 현재 운영 방식과 앞으로의 성장 가능성입니다.

마무리: 리눅스 디스크 구성은 현재보다 미래를 보고 정하셔야 합니다

LVM 일반 파티션 비교를 한 줄로 정리하면 이렇습니다. 지금 단순한 게 중요한가, 나중에 유연한 게 중요한가입니다. 제가 직접 해보니 처음 구축보다 나중 확장에서 차이가 훨씬 크게 느껴졌습니다. 특히 서비스가 이미 올라간 뒤에는 디스크 구조 변경이 생각보다 부담스럽거든요.

혹시 지금 새 서버를 세팅 중이시라면, 단순한 테스트 머신인지, 아니면 몇 달 이상 운영할 서버인지부터 먼저 생각해보세요. 그 기준만 세워도 선택이 훨씬 쉬워집니다. 다음 글에서는 디스크 확장 작업을 실제 운영 중인 리눅스 서버에서 어떻게 안전하게 진행하는지, 파일시스템별로 체크 포인트가 무엇인지 이어서 다뤄볼 예정입니다. 이전 글에서 다룬 리눅스 기본 스토리지 점검 방법도 같이 보시면 흐름 잡는 데 도움이 되실 겁니다.

LVM과 일반 파티션의 선택 기준을 한 장으로 정리한 요약 이미지입니다.