서버 디스크 용량이 늘지 않을 때: 볼륨·파티션·파일시스템 확장 순서

서버 용량 증설 후 운영체제가 새 공간을 사용하지 못하는 원인을 계층별로 진단하고 스냅샷, 콘솔 접근, 파일시스템별 명령과 검증 순서를 안내합니다.

INXSEO 편집팀SEO·웹 운영 검수팀2026년 8월 4일3분검토 2026년 7월 27일

클라우드 콘솔에서 디스크 크기를 늘렸는데 df -h 결과가 그대로인 것은 흔한 현상입니다. 공급자의 가상 볼륨, 운영체제가 인식하는 디스크, 파티션, LVM 논리 볼륨과 파일시스템은 서로 다른 계층이기 때문입니다. 위 계층만 커지고 아래 계층이 확장되지 않으면 애플리케이션이 새 공간을 사용할 수 없습니다.

디스크 작업은 장치 이름과 파일시스템을 잘못 지정하면 데이터 손실을 일으킬 수 있습니다. 아래 명령은 진단 예시이며, 출력 확인 없이 그대로 복사해 실행해서는 안 됩니다. 운영 서버에서는 먼저 공급자 스냅샷과 복구 가능한 백업, 콘솔 접근을 준비하세요.

용량 계층을 먼저 이해합니다

클라우드 볼륨: 공급자 콘솔에서 구매·연결한 가상 디스크
블록 장치: Linux가 보는 /dev/sda, /dev/vda, /dev/nvme0n1 등
파티션: 장치 안의 sda1, nvme0n1p1 등
LVM: 사용하는 경우 PV·VG·LV 계층
파일시스템: ext4, XFS 등 실제 파일을 저장하는 구조
마운트 지점: /, /var, /home처럼 애플리케이션이 사용하는 경로

변경 전 필수 준비

공급자 볼륨 스냅샷 또는 검증된 전체 백업
SSH가 끊겨도 사용할 수 있는 웹 콘솔·직렬 콘솔
현재 장치·파티션·파일시스템·마운트 정보를 저장한 기록
서비스 중단 가능성과 담당자 연락 계획
LVM, RAID, 암호화 볼륨 사용 여부

스냅샷은 애플리케이션 일관성을 자동으로 보장하지 않을 수 있습니다. 데이터베이스가 있다면 공급자 문서와 데이터베이스 백업 절차에 따라 일관된 복구 지점을 준비합니다.

1단계: 공급자 볼륨 확장이 완료됐는지 확인합니다

클라우드 콘솔에서 요청한 크기, 연결 대상 인스턴스와 작업 상태를 확인합니다. 공급자에 따라 “optimizing” 상태부터 새 크기를 사용할 수 있거나 완료까지 기다려야 할 수 있습니다. 잘못된 인스턴스의 다른 볼륨을 확장하지 않았는지도 확인합니다.

2단계: Linux가 새 디스크 크기를 보는지 확인합니다

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sudo fdisk -l
findmnt -no SOURCE,FSTYPE,TARGET /
df -hT

lsblk에서 디스크는 커졌지만 파티션이 작으면 파티션 확장이 필요할 수 있습니다. 디스크 자체 크기가 그대로면 공급자 작업, 장치 재스캔 또는 재부팅 필요 여부를 공급자 문서에서 확인합니다.

3단계: 파티션 유무와 번호를 정확히 확인합니다

장치를 통째로 파일시스템으로 사용하면 파티션 확장 단계가 없습니다. 파티션을 사용한다면 장치명과 파티션 번호를 분리해야 합니다. 예를 들어 /dev/nvme0n1p1은 디스크 /dev/nvme0n1의 1번 파티션입니다.

AWS 공식 문서의 예시는 다음과 같지만, 자신의 출력과 일치할 때만 사용합니다.

sudo growpart /dev/nvme0n1 1
# 또는 환경에 따라
sudo growpart /dev/xvda 1

growpart가 없거나 파티션 구조가 복잡하면 설치와 대체 도구를 임의로 진행하지 말고 운영체제·공급자 문서를 확인합니다. 부트, EFI, 암호화, RAID와 다중 파티션 환경은 별도 절차가 필요할 수 있습니다.

4단계: LVM 사용 여부를 확인합니다

lsblk, pvs, vgs, lvs 출력에 LVM 계층이 보이면 파티션만 늘린 뒤 바로 파일시스템을 확장해서는 안 됩니다. 일반적으로 물리 볼륨을 인식시키고 논리 볼륨을 확장한 다음 파일시스템을 늘립니다.

sudo pvs
sudo vgs
sudo lvs

LVM 명령과 대상 경로는 구성마다 다릅니다. 루트 논리 볼륨을 잘못 지정하면 다른 볼륨에 공간을 배정할 수 있으므로 현재 구조를 이해하지 못하면 전문가 또는 공급자 지원을 이용하세요.

5단계: 파일시스템 유형에 맞게 확장합니다

df -hT 또는 lsblk -f로 파일시스템을 확인합니다. ext4와 XFS 명령은 서로 바꿔 쓸 수 없습니다.

ext4 예시

sudo resize2fs /dev/nvme0n1p1

XFS 예시

sudo xfs_growfs -d /

XFS는 일반적으로 장치명이 아니라 마운트 지점을 지정합니다. “Bad magic number”, “not a mounted XFS filesystem” 같은 오류가 나오면 명령을 반복하지 말고 파일시스템과 대상을 다시 확인합니다.

6단계: 결과를 세 계층에서 검증합니다

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
df -hT
findmnt /

디스크와 파티션 크기가 의도한 값인지
LVM을 사용한다면 LV 크기가 늘었는지
파일시스템과 마운트 지점의 사용 가능 공간이 늘었는지
재부팅 후에도 정상 마운트되는지
애플리케이션과 데이터베이스가 정상 동작하는지

자주 발생하는 실패

No space left on device: growpart가 임시 파일을 만들 공간도 없을 수 있어 로그·캐시를 안전하게 정리한 뒤 재시도합니다.
NOCHANGE: 파티션이 이미 디스크 끝까지 확장됐거나 공급자 볼륨이 아직 커지지 않았을 수 있습니다.
Nothing to do: 파일시스템이 이미 현재 파티션 전체를 사용 중일 수 있습니다.
용량은 남았는데 저장 실패: inode 고갈, 쿼터, 읽기 전용 마운트 또는 별도 파티션 문제를 확인합니다.
CPU·메모리 상품만 변경: 컴퓨팅 플랜 변경이 디스크 크기를 자동으로 늘리지 않는 상품도 있습니다.

공식 자료

디스크 증설은 “한 번의 명령”이 아니라 현재 구조를 확인하고 필요한 계층만 순서대로 확장하는 작업입니다. 볼륨, 파티션, LVM과 파일시스템을 구분하면 용량이 늘지 않는 원인을 안전하게 좁힐 수 있습니다.