507 Insufficient Storage 원인

Problem

당연히 됐어야 할 요청 — 업로드, PUT, 폼 전송, 웹 앱에서의 파일 저장 — 이 507 Insufficient Storage로 돌아옵니다. 요청 자체는 멀쩡합니다. 서버가 HTTP 명세가 허락하는 가장 담백한 말로, 당신이 보낸 것을 놓아둘 곳이 없었다고 알려주는 겁니다. 서버 쪽 어딘가가 공간이 없습니다: 디스크, 쿼터, 아이노드 테이블, 또는 내부 버퍼. 해결책은 절대 당신 요청에 있지 않습니다 — 무엇이 찼는지에 있습니다.

507은 WebDAV 명세인 RFC 4918 §11.5에 정의돼 있습니다: “서버가 요청을 성공적으로 완료하는 데 필요한 표현을 저장할 수 없어 메서드를 수행할 수 없었다.” WebDAV를 위해 태어났지만, 그 의미 — 요청은 받았는데, 결과를 저장할 수가 없다 — 가 워낙 쓸모 있어서, 이제 WebDAV 바깥의 서버와 프레임워크도 저장 소진 상황이면 이 코드를 냅니다.

Symptoms

• 읽기는 되는데 쓰기가 실패합니다. 사이트 열람은 멀쩡한데, 업로드·저장·전송만 507을 냅니다.
• 갑작스럽고 전면적입니다 — 한 시간 전엔 됐고, 코드는 안 바뀌었는데, 이제 모든 쓰기가 507입니다.
• 누군가 공간을 비우는 순간 사라졌다가, 디스크가 다시 차면 돌아옵니다.
• WebDAV, Nextcloud, SharePoint, Git 서버, 오브젝트 스토리지 게이트웨이가 PUT/POST에는 507을, 기존 파일 서빙은 정상으로 냅니다.
• df는 여유 공간을 보여주는데 쓰기는 507 — 전형적인 아이노드 고갈 함정입니다.

What 507 Actually Means

507은 한 가지를 말합니다: 서버가 요청을 받아들인 뒤, 필요한 것을 저장하지 못했다. 이건 “서버가 망가졌다”보다 좁습니다. 500은 처리되지 않은 예외이고, 503은 서버가 아예 서빙을 거부하는 것이며, 507은 요청을 쓰기 직전까지 처리해 놓고 벽에 부딪힌 서버입니다.

그 벽은 거의 항상 세 종류의 “가득 참” 중 하나입니다.

블록이 가득 참. 앱이 쓰는 파티션에 남은 바이트가 0입니다. 업로드 디렉토리, /tmp, 데이터베이스 볼륨, 또는 조용히 커져 디스크를 삼킨 로그 파티션. 바이트를 써야 하는 모든 게 한꺼번에 실패합니다.

아이노드가 가득 참. 사람들이 여기서 속습니다. 파일시스템이 기가바이트의 여유 공간을 갖고도 파일 생성을 거부할 수 있습니다 — 파일 하나당 항목 하나를 담는 고정 크기 테이블, 아이노드가 바닥났기 때문입니다. 작은 파일 수백만 개를 뿌리는 캐시나 세션 저장소가 디스크를 채우기 훨씬 전에 아이노드 테이블을 소진합니다. df는 멀쩡해 보이고, df -i는 100%이고, 쓰기는 그래도 507입니다.

쿼터가 가득 참. 디스크는 멀쩡한데, 당신 몫이 아닙니다. 공유 호스팅 계정, 메일박스 쿼터, 사용자별 디스크 한도, 오브젝트 스토리지 버킷은 한 입주자가 저장할 수 있는 양을 제한합니다. 한도를 넘기면 바탕 볼륨은 여유가 있어도 507이 뜹니다 — 한도는 물리가 아니라 정책입니다.

관통하는 발상: 507은 계산 용량이 아니라 저장 용량에 관한 것입니다. 그게 옆자리 5xx 코드들과 507을 가르는 지점입니다.

Top Causes

1. 데이터 파티션이 실제로 가득 참 - 업로드, 로그, 데이터베이스 파일, 임시 데이터가 볼륨의 남은 바이트를 0으로 만들 때까지 커졌습니다. 공간이 회수될 때까지 그 파티션의 모든 쓰기가 507입니다. 폭주한 로그 파일이나 정리 안 된 업로드 디렉토리가 흔한 주범입니다.

2. 블록은 남았는데 아이노드 고갈 - 작은 파일 수백만 개(세션, 캐시 조각, 메일, PHP upload_tmp_dir 잔재)가 아이노드 테이블을 소진했습니다. df는 여유가 있다 하고, df -i는 없다 합니다. 디스크가 반쯤 비어 보여도 쓰기가 실패합니다.

3. 계정별·메일박스별 쿼터 초과 - 물리 디스크는 멀쩡한데 입주자 할당량이 소진됐습니다. 공유 호스팅, WebDAV/Nextcloud 사용자 쿼터, 메일 저장소에서 흔합니다. 디스크 증설이 아니라 쿼터를 올리거나 비우는 게 해결입니다.

4. 앱 내부의 저장 한도 - 일부 프레임워크와 오브젝트 스토리지 게이트웨이는 프로세스 내 버퍼, 설정된 최대 저장 크기, 백엔드 버킷 쿼터를 넘기면 호스트 디스크가 멀쩡해도 507을 냅니다. 한도는 파일시스템이 아니라 설정에 있습니다.

Diagnose with DechoNet

• HTTP 진단은 오리진이 반환하는 정확한 최종 상태 줄과 응답 헤더를 읽습니다. 이걸로 두 가지가 빨리 잡힙니다. 첫째, 507이 앞단의 프록시나 CDN이 아니라 당신 오리진에서 나오는지 확인됩니다 — 헤더의 서버 시그니처가 어느 박스가 실제로 공간이 떨어졌는지 알려줍니다. 둘째, 507이 상시인지 간헐인지 보여줍니다: 조용히 재시도하면 사라지는 저장 소진 507은, 모든 쓰기마다 돌아오는 것과 완전히 다르게 행동합니다 — 그 갈림이 “부하 걸리면 차는 디스크”인지 “이미 꽉 찬 디스크”인지 가리킵니다. 거기서부터 서버 내 확인은 앱이 쓰는 파티션에 df -h와 df -i입니다.

Resolution Checklist

• 코드와 출처를 확인하세요. HTTP 진단으로 앞단 프록시가 아닌 오리진의 진짜 507인지, 비슷한 메시지를 쓴 413(본문 한도)이나 508(자원/루프)이 아닌지 검증합니다.
• 블록 공간 확인: 서버에서 df -h. 앱 파티션이 100%면 무엇이 채웠는지 찾고(du -sh /* 또는 로그·업로드·임시 디렉토리 집중 점검) 공간을 회수하세요.
• 아이노드 확인: 같은 파티션에 df -i. 블록은 안 찼는데 아이노드가 100%면 작은 파일 더미(오래된 세션, 캐시 조각, 고아 임시 파일)를 찾아 지우세요. 여기선 디스크 증설이 안 통합니다.
• 쿼터 확인. 블록·아이노드가 다 멀쩡하면 한도는 계정별·메일박스별·버킷별 쿼터입니다. 올리거나 할당량 안에서 공간을 비우세요.
• 앱 자체 저장 설정을 보세요. 오브젝트 스토리지 게이트웨이와 일부 프레임워크는 디스크와 무관하게 저장 크기를 제한합니다 — 파일시스템이 멀쩡한 507은 여기를 가리킵니다.
• 증상이 아니라 증가를 고치세요. 로그를 로테이션·상한 설정하고, 임시·캐시 디렉토리를 주기적으로 정리하며, 디스크 와 아이노드 사용률 둘 다 100% 전에 알림을 걸으세요. 손으로 비운 507은 채운 것을 아무도 정리 안 하면 곧장 돌아옵니다.

When to Escalate

• 서버를 통제하지 못한다면 — 공유·매니지드 호스팅이라 df를 못 돌린다면 — 정확한 시각과 실패한 작업을 들고 호스트에 에스컬레이션하세요. 그쪽은 어느 볼륨·쿼터가 걸렸는지 몇 초면 봅니다.
• 블록과 아이노드가 다 건강하고 쿼터도 원인이 아니면, 507은 애플리케이션 내부나 상위 스토리지 서비스에서 나옵니다. 파일시스템 문제가 아니라 앱 설정·오브젝트 스토리지 문제이니, 그 계층을 소유한 쪽으로 가져가세요.