AWS EC2에서 Docker 빌드 중 “no space left on device” 오류 해결기

AWS EC2에서 Docker 빌드 중 “no space left on device” 오류 해결기

최근 AWS EC2 인스턴스에서 Docker 이미지를 빌드하는 과정 중, 예상치 못한 디스크 용량 부족 문제를 겪었습니다.
이번 글에서는 문제 원인 파악부터 EBS 볼륨 확장 및 파티션 조정, 파일시스템 리사이즈까지 진행한 과정을 단계별로 정리해 보겠습니다.

---

문제 상황: Docker 빌드 중 “no space left on device” 오류 발생

Docker 빌드 중 다음과 같은 에러 메시지를 확인했습니다.

error Error: ENOSPC: no space left on device, copyfile '/frontend/.cache/yarn/v6/npm-plotly-js-1.58.5-.../world_110m.json' -> '/frontend/node_modules/plotly.js/dist/topojson/world_110m.json'

이 메시지는 디스크 용량 부족으로 인해 파일 복사 작업이 실패했다는 뜻입니다.

---

1. 디스크 사용량과 파티션 상태 점검

즉시 EC2 인스턴스에 접속하여 디스크 상태를 점검했습니다.

$ df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root         29G   26G  2.9G  90% /
tmpfs            1.9G     0  1.9G   0% /dev/shm
tmpfs            768M  1.3M  767M   1% /run
...

루트 파티션의 남은 용량이 약 2.9GB에 불과해 거의 가득 찬 상태임을 확인했습니다.

2. EBS 볼륨 확장 전 스냅샷 백업 권장

EBS 볼륨 크기를 변경하기 전에 AWS 콘솔에서 현재 볼륨의 스냅샷을 생성해 백업하는 것을 강력히 권장합니다.
스냅샷은 문제가 발생할 경우 즉시 복구할 수 있는 안전장치 역할을 하므로, 작업 안정성을 높여줍니다.

3. AWS 콘솔에서 EBS 볼륨 크기 확장

AWS 콘솔에서 EBS 볼륨 크기를 30GB에서 100GB로 확장했습니다.

AWS 콘솔에서 EBS 볼륨 확장 방법

1. AWS Management Console 접속 후 EC2 대시보드로 이동
2. 좌측 메뉴에서 “Volumes” 선택
3. 확장할 EBS 볼륨 선택 (인스턴스에 연결된 볼륨)
4. 상단의 “Actions” → “Modify Volume” 클릭
5. Size 값을 원하는 만큼 (예: 50GB, 100GB 등) 증가시킴
6. Modify 버튼 클릭 후 확인

30GB는?

일반적으로 30GB는 보통 OS 및 소규모 앱 구동에는 적당하지만,
Docker 빌드 캐시, 이미지, 로그 등이 쌓이면 빠르게 부족해질 수 있습니다.
최소 50~100GB 이상 확보하는 게 무난하며, 특히 빌드, 데이터 저장, 캐시 용량에 따라 더 늘려야 할 수도 있습니다.

확장 후에도 디스크 용량 변화 없음 확인

볼륨을 확장했음에도 불구하고, EC2 인스턴스 내부에서 df -h로 확인해보면 여전히 용량이 29GB로 표시되는 것을 볼 수 있습니다.

$ df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root         29G   26G  2.9G  90% /

이는 OS레벨에서 파티션과 파일시스템 크기를 별도로 확장하지 않았기 때문입니다.
좀더 자세한 확인을 위해 lsblk 명령어로 확인했습니다.

볼륨 확장 후 파티션 크기 확인 - lsblk 명령어

$ lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0          7:0    0 27.2M  1 loop /snap/amazon-ssm-agent/11320
...
nvme0n1      259:0    0  100G  0 disk
├─nvme0n1p1  259:1    0   29G  0 part /
├─nvme0n1p14 259:2    0    4M  0 part
├─nvme0n1p15 259:3    0  106M  0 part /boot/efi
└─nvme0n1p16 259:4    0  913M  0 part /boot
...

EBS 볼륨 크기는 100GB이나, 실제 파티션은 29GB로만 할당되어 있어 파티션 확장이 필요함을 알 수 있었습니다.

4. 파티션 확장 및 파일시스템 리사이즈

OS 내에서 볼륨 확장 이후, 다음 절차로 파티션과 파일시스템 크기를 늘렸습니다.

1. 파티션 크기 확장

$ sudo growpart /dev/nvme0n1 1
CHANGED: partition=1 start=2099200 old: size=60815327 end=62914526 new: size=207615967 end=209715166

2. 파일시스템 크기 조정

$ sudo resize2fs /dev/nvme0n1p1
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/nvme0n1p1 is mounted on /; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 13
The filesystem on /dev/nvme0n1p1 is now 25951995 (4k) blocks long.

5. 최종 확인 및 재시도

확장 작업 완료 후, 다시 df -h 명령어로 디스크 상태를 확인했습니다.

$ df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root        100G   26G   69G  28% /

이제 충분한 여유 공간이 확보되어 Docker 빌드가 정상적으로 진행되었습니다.

---

💡 실제 작업 시간을 단축하기 위해 미리 준비해둘 점(삽질 방지)
✅ EBS 용량을 충분히 잡아 두기:
Docker 빌드 + Node/yarn 캐시용으로 최소 50GB 이상 권장.

✅ AWS CLI 설치 및 익숙해지기:
용량 부족 시 growpart, resize2fs 즉시 실행 가능.

✅ df -h, lsblk, file -s, growpart, resize2fs 명령어 숙지:
CLI 환경에서 빠르게 상태 확인 및 조치 가능.

✅ 빌드 캐시, Yarn 캐시 정리 주기적 점검:
디스크 사용량 80% 이상 시 사전 정리로 장애 예방.

---

마치며

이번 경험을 통해 단순히 AWS 볼륨 크기만 변경하는 것이 아닌, OS 내부 파티션과 파일시스템까지 확장해야 제대로 공간이 확보된다는 점을 확인했습니다.
앞으로는 이런 점들을 고려해 더 안정적인 인프라 운영과 빌드 환경 관리가 가능할 것 같습니다.