리눅스 서버에서 /tmp 용량이 가득 차면 파일 업로드 실패, 압축 해제 실패, 배치 오류, 애플리케이션 임시파일 생성 실패 같은 문제가 생길 수 있습니다. 이때 초보 운영자는 “임시파일이니까 지워도 되겠지”라고 생각하고 rm -rf /tmp/*를 실행하기 쉽지만, 운영 서버에서는 현재 프로세스가 사용 중인 임시파일, 소켓 파일, lock 파일까지 지워서 장애를 키울 수 있습니다.
이번 글에서는 서버 운영 중 /tmp 용량이 찼을 때 df -h, du, find, lsof로 무엇이 쌓였는지 확인하고, 오래된 파일과 사용 중인 파일을 구분해 안전하게 점검하는 순서를 정리합니다.
/tmp는 어떤 곳일까?
/tmp는 이름 그대로 임시파일이 저장되는 경로입니다.
애플리케이션, 배치 작업, 압축 해제, 업로드 처리, 패키지 설치, 스크립트 실행 중에 잠깐 필요한 파일이 /tmp에 만들어질 수 있습니다.
예를 들면 이런 파일들이 쌓일 수 있습니다.
- 업로드 임시파일
- 압축 해제 파일
- 세션 임시파일
- 배치 작업 중간 파일
- 설치 작업 임시파일
- 애플리케이션 작업 파일
- 소켓 파일
- lock 파일문제는 이 임시파일이 자동으로 정리되지 않거나, 특정 작업이 비정상 종료되면서 계속 쌓일 때입니다.
임시파일이라는 이름만 보면 가볍게 느껴지지만, 운영 서버에서는 /tmp가 꽉 차는 것만으로도 서비스 오류가 날 수 있습니다.
가상의 운영 상황 예시
예를 들어 웹 애플리케이션 서버에서 이런 상황이 발생했다고 가정해보겠습니다.
[상황]
- 사용자가 파일 업로드를 시도했지만 실패함
- 애플리케이션 로그에 No space left on device 메시지 확인
- df -h /tmp 결과 Use% 95% 확인
- /tmp 아래 batch-work 디렉터리에 임시파일이 많이 쌓인 것으로 보임이 상황에서 초보 운영자는 이렇게 생각하기 쉽습니다.
/tmp는 임시파일이니까 그냥 지우면 되지 않을까?하지만 바로 삭제하면 안 됩니다.
현재 업로드 중인 파일, 실행 중인 배치의 작업 파일, 프로세스가 사용하는 소켓 파일이 같이 지워질 수 있기 때문입니다.
초보 운영자가 하기 쉬운 실수
/tmp가 꽉 찬 걸 보면 급하게 이런 명령어를 떠올리기 쉽습니다.
rm -rf /tmp/*하지만 운영 서버에서는 조심해야 합니다.
/tmp 안에는 지금 실행 중인 프로세스가 사용하는 파일이 있을 수 있습니다.
특히 아래 파일들은 무작정 지우면 서비스 영향이 생길 수 있습니다.
- 소켓 파일
- lock 파일
- 업로드 중인 임시파일
- 배치 작업 파일
- 설치 중 생성된 파일
- 애플리케이션이 참조 중인 캐시 파일그래서 /tmp는 “임시니까 다 지워도 된다”가 아니라, “오래됐고 사용 중이 아닌 파일부터 확인 후 정리한다”가 더 안전합니다.
1단계. df -h로 /tmp가 별도 파일시스템인지 확인하기
먼저 /tmp가 실제로 얼마나 찼는지 확인합니다.
df -h /tmp예시입니다.
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 10G 9.5G 500M 95% /tmp여기서 중요한 건 Use%와 Mounted on입니다.
Mounted on이 /tmp라면 /tmp가 별도 파일시스템으로 잡혀 있는 상태입니다.
이 경우에는 /tmp 안에서 무엇이 쌓였는지 확인해야 합니다.
반대로 /tmp가 별도 마운트가 아니고 /에 포함되어 있다면 루트 파일시스템 전체 용량 문제와 연결될 수 있습니다.
예를 들어 이렇게 보일 수 있습니다.
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 50G 48G 2G 96% /이 경우 /tmp만의 문제가 아니라 / 전체 용량 문제일 수 있습니다.
따라서 /tmp 문제를 볼 때도 df -h 결과에서 Mounted on을 같이 확인해야 합니다.
df -h 결과를 볼 때는 Use%만 보는 것보다 Mounted on을 함께 확인하는 것이 중요합니다. 같은 90%라도 어느 파일시스템이 찼는지에 따라 대응 방향이 달라질 수 있습니다.
2026.05.02 - [리눅스] - 리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서
전체 용량부터 봅니다.
du -sh /tmp그리고 1단계 깊이로 확인합니다.
du -xhd1 /tmp 2>/dev/null | sort -h예시입니다.
100M /tmp/systemd-private-example
1.5G /tmp/upload-cache
6.0G /tmp/batch-work
7.8G /tmp이 경우 /tmp/batch-work 쪽에 파일이 많이 쌓였을 가능성이 있습니다.
여기서 바로 삭제로 가지 말고, 먼저 이 디렉터리가 어떤 용도로 쓰이는지 확인해야 합니다.
- 배치 작업 중간 파일인지
- 업로드 임시파일인지
- 압축 해제 파일인지
- 특정 애플리케이션이 사용하는 작업 디렉터리인지
- 최근에도 계속 파일이 생성되는지운영 서버에서는 처음부터 깊게 뒤지기보다, 이렇게 한 단계씩 좁혀가는 게 안전합니다.
3단계. 오래된 파일부터 확인하기
삭제 후보는 보통 오래된 파일부터 봅니다.
먼저 7일 이상 된 파일을 확인합니다.
find /tmp -xdev -type f -mtime +7 | head개수도 확인합니다.
find /tmp -xdev -type f -mtime +7 | wc -l예시입니다.
1523407일 이상 된 파일이 15만 개 이상이라면 정리 후보가 될 수 있습니다.
하지만 바로 삭제하지 말고 먼저 목록을 더 확인합니다.
find /tmp -xdev -type f -mtime +7 -ls | head -n 20파일명, 경로, 수정 시간을 보고 어떤 애플리케이션이 만든 파일인지 추정해야 합니다.
오래된 파일이라고 해서 모두 안전한 것은 아닙니다.
특정 서비스가 장기간 유지하는 임시파일일 수도 있고, 이름은 임시파일처럼 보여도 애플리케이션이 참조 중일 수 있습니다.
4단계. 최근 생성된 파일이 계속 늘어나는지 보기
/tmp가 계속 차고 있다면 현재도 파일이 생성 중일 수 있습니다.
최근 1시간 내 생성된 파일을 봅니다.
find /tmp -xdev -type f -mmin -60 | head개수도 확인합니다.
find /tmp -xdev -type f -mmin -60 | wc -l최근 1시간 안에 파일이 매우 많이 만들어지고 있다면, 단순 정리보다 원인 확인이 먼저입니다.
예를 들어 이런 상황일 수 있습니다.
- 업로드 실패가 반복되면서 임시파일 누적
- 배치가 실패하면서 중간 파일 누적
- 애플리케이션이 캐시 파일을 계속 생성
- 압축 해제 작업이 반복 실패
- 외부 연동 실패로 재처리 파일 누적이런 경우에는 파일을 지워도 금방 다시 찰 수 있습니다.
따라서 “무엇을 지울까”보다 먼저 “왜 계속 생기고 있나”를 확인해야 합니다.
5단계. 사용 중인 파일인지 확인하기
삭제 전에는 사용 중인 파일인지 확인하는 게 좋습니다.
특정 경로가 의심된다면 lsof로 확인할 수 있습니다.
lsof +D /tmp/batch-work 2>/dev/null | head다만 lsof +D는 해당 디렉터리를 훑기 때문에 파일이 아주 많으면 무거울 수 있습니다.
운영 서버에서는 /tmp 전체보다 의심 경로로 범위를 좁혀서 쓰는 게 좋습니다.
예를 들어 /tmp 전체를 바로 훑기보다 이렇게 좁혀서 봅니다.
lsof +D /tmp/upload-cache 2>/dev/null | head결과에 프로세스가 잡힌다면, 해당 파일은 현재 사용 중일 수 있습니다.
이 경우 삭제 전 서비스 영향 여부를 먼저 확인해야 합니다.
deleted 파일도 같이 확인할 수 있습니다.
lsof | grep deleted | grep /tmp이미 삭제됐지만 프로세스가 잡고 있는 /tmp 파일이 있다면 df 용량이 바로 줄지 않을 수 있습니다.
이때도 바로 kill 하거나 reboot 하기보다, 어떤 프로세스가 파일을 잡고 있는지 먼저 확인해야 합니다.
/tmp 용량이 꽉 찼는데 파일을 삭제해도 df 용량이 바로 줄지 않는다면 deleted 파일도 함께 의심해볼 수 있습니다. df와 du 결과가 다르게 보이는 상황은 아래 글에서 이어서 확인할 수 있습니다.
6단계. 바로 삭제 대신 조건을 좁히기
정리가 필요하다면 조건을 좁혀서 진행해야 합니다.
먼저 삭제 대상만 출력합니다.
find /tmp -xdev -type f -mtime +30 -print | head개수를 확인합니다.
find /tmp -xdev -type f -mtime +30 | wc -l정말 삭제해도 되는 파일이라고 판단되면 그때 삭제를 검토합니다.
find /tmp -xdev -type f -mtime +30 -delete이 명령어도 운영 서버에서는 신중해야 합니다.
삭제 조건을 잘못 잡으면 필요한 파일까지 지울 수 있습니다.
처음에는 -delete를 붙이지 말고 반드시 -print로 대상부터 보는 습관이 안전합니다.
find /tmp -xdev -type f -mtime +30 -print | head대상이 맞는지 확인한 뒤, 영향 범위를 판단하고 조치해야 합니다.
7단계. 디렉터리 자체를 지우는 건 더 조심하기
아래 명령어는 특히 조심해야 합니다.
rm -rf /tmp/*그리고 이런 명령어도 조심해야 합니다.
find /tmp -xdev -type d -mtime +7 -delete디렉터리 안에 사용 중인 파일이나 소켓 파일이 있을 수 있습니다.
또 어떤 애플리케이션은 특정 임시 디렉터리가 있어야 정상 동작할 수도 있습니다.
파일 정리와 디렉터리 정리는 위험도가 다릅니다.
파일은 오래된 파일만 조건을 좁혀 정리할 수 있지만, 디렉터리를 지우면 그 안의 구조나 권한, 애플리케이션이 기대하는 경로까지 사라질 수 있습니다.
디렉터리를 지울 때는 더 신중하게 확인해야 합니다.
8단계. /tmp 정리 정책 확인하기
일부 리눅스 환경에서는 systemd-tmpfiles가 /tmp 정리 정책을 관리합니다.
설정을 확인할 수 있습니다.
systemd-tmpfiles --cat-config | grep -A3 "/tmp"또는 설정 파일을 확인합니다.
ls -l /usr/lib/tmpfiles.d/
ls -l /etc/tmpfiles.d/환경에 따라 정리 주기나 정책이 다를 수 있습니다.
운영 서버에서는 임의로 삭제 스크립트를 만들기보다 기존 정리 정책이 있는지 먼저 확인하는 게 좋습니다.
만약 정리 정책이 없거나 애플리케이션 임시파일이 계속 쌓이는 구조라면, 단발성 삭제만으로는 다시 같은 문제가 반복될 수 있습니다.
9단계. 애플리케이션 임시 경로 설정 확인하기
애플리케이션이 /tmp를 과도하게 사용한다면 설정을 봐야 할 수 있습니다.
예를 들어 Java 애플리케이션은 임시 디렉터리를 따로 지정할 수 있습니다.
-Djava.io.tmpdir=/app/tmpNode.js, Python, WAS, 배치 프로그램도 환경변수나 설정값에 따라 임시 경로를 사용할 수 있습니다.
확인할 만한 환경변수는 다음과 같습니다.
env | grep -i tmp서비스 단위로는 systemd 환경 설정을 확인해야 할 수 있습니다.
systemctl cat example-app/tmp가 자주 찬다면 단순 삭제보다 애플리케이션이 어떤 임시 경로를 쓰는지 확인하는 게 더 중요할 수 있습니다.
필요하다면 애플리케이션 임시 경로를 별도 디스크로 분리하거나, 정리 정책을 명확히 잡는 방향도 검토할 수 있습니다.
10단계. 운영자 보고 문장 예시
/tmp 용량 부족을 발견했다면 이렇게 정리하면 좋습니다.
[/tmp 용량 부족 확인]
- 발생 시각: 2026-07-08 14:30
- 대상 서버: web-01
- 증상: 파일 업로드 실패 및 No space left on device 오류 발생
- 확인 내용:
1) df -h /tmp 결과 Use% 95% 확인
2) du -xhd1 /tmp 결과 /tmp/batch-work 약 6G 확인
3) /tmp/batch-work 내 30일 이상 파일 다수 확인
4) 최근 1시간 내 생성 파일 증가 여부 확인 중
5) lsof 기준 현재 사용 중인 파일 여부 확인 중
- 추정 원인:
배치 작업 임시파일 누적 가능성
- 조치 방향:
사용 중 여부와 정리 정책 확인 후 오래된 파일부터 정리 검토이렇게 쓰면 단순히 “/tmp 찼습니다”보다 훨씬 좋습니다.
운영 보고에서는 아래 내용을 함께 적으면 좋습니다.
- 어느 파일시스템이 찼는지
- 어떤 경로가 많이 차지하는지
- 오래된 파일인지 최근 생성 파일인지
- 현재 사용 중인 파일인지
- 바로 삭제 가능한지, 확인이 더 필요한지운영 서버에서 조심할 점
/tmp 용량이 찼을 때 아래 작업은 특히 조심해야 합니다.
rm -rf /tmp/*
find /tmp -type f -delete
reboot
kill -9 <PID>이런 조치는 빠른 해결처럼 보일 수 있지만, 현재 실행 중인 서비스에 영향을 줄 수 있습니다.
안전한 흐름은 이렇게 잡는 게 좋습니다.
1. df -h /tmp 확인
2. Mounted on 확인
3. du -xhd1 /tmp 로 큰 경로 확인
4. 오래된 파일 목록 확인
5. 최근 생성 파일 확인
6. 사용 중인 파일 확인
7. 정리 정책 확인
8. 삭제 대상 확정 후 조치/tmp에 작은 임시파일이 너무 많이 쌓이면 용량뿐 아니라 inode 부족 문제가 함께 생길 수 있습니다. 용량은 남았는데 파일 생성이 안 되는 상황은 아래 글에서 df -i 기준으로 따로 정리했습니다.
2026.07.11 - [리눅스] - 리눅스 서버 용량은 남았는데 파일 생성이 안 될 때 df -i로 inode 확인하는 법
정리하면
/tmp는 임시파일 경로지만, 운영 서버에서는 함부로 비우면 안 됩니다.
먼저 확인할 명령어는 아래와 같습니다.
df -h /tmp
du -xhd1 /tmp 2>/dev/null | sort -h
find /tmp -xdev -type f -mtime +7 | head
find /tmp -xdev -type f -mmin -60 | head
lsof | grep deleted | grep /tmp이번 상황의 핵심은 단순합니다.
`/tmp`가 찼다면, 지우기 전에 먼저 쓰는 주체를 확인해야 합니다.
`/tmp`는 이름 때문에 가볍게 보기 쉽지만, 운영 서버에서는 현재 서비스나 배치 작업이 임시 파일을 사용 중일 수 있습니다.
그래서 바로 삭제하기보다 어떤 파일이 쌓였는지, 최근에 생성된 파일인지, 현재 프로세스가 잡고 있는 파일은 아닌지 확인하는 순서가 먼저입니다.
디스크 용량 문제를 전체 순서로 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/70
리눅스 서버 디스크 용량 문제 확인 순서 총정리
리눅스 서버를 운영하다 보면 디스크 용량 문제는 생각보다 자주 만납니다.처음에는 단순해 보입니다.디스크가 찼다.공간이 부족하다.큰 파일을 지우면 된다. 하지만 운영 서버에서는 이렇게
opsnote.tistory.com
`/tmp`와 함께 자주 확인해야 하는 경로가 `/var`입니다.
`/var`에는 로그, 캐시, 서비스 데이터가 함께 들어갈 수 있어서 더 조심해서 봐야 합니다.
https://opsnote.tistory.com/68
리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서
리눅스 서버에서 /var 용량이 가득 차면 단순히 디스크 공간이 부족한 문제로 끝나지 않을 수 있습니다. /var에는 로그, 캐시, 스풀, 패키지 데이터, 애플리케이션 상태 파일이 쌓이는 경우가 많아
opsnote.tistory.com
리눅스 서버 장애 대응 전체 흐름은 아래 글에서 정리했습니다.
https://opsnote.tistory.com/69
초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리
리눅스 서버를 운영하다 보면 어느 날 갑자기 이런 말을 듣게 됩니다.서버가 느립니다.접속이 안 됩니다.서비스가 안 뜹니다.디스크가 가득 찼습니다.로그가 계속 쌓입니다.재기동하면 될까요?
opsnote.tistory.com
'리눅스' 카테고리의 다른 글
| 초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리 (0) | 2026.08.10 |
|---|---|
| 리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서 (0) | 2026.07.12 |
| 리눅스 서버 용량은 남았는데 파일 생성이 안 될 때 df -i로 inode 확인하는 법 (0) | 2026.07.11 |
| 리눅스 서버 df와 du 결과가 다르게 보일 때 deleted 파일부터 확인하는 법 (0) | 2026.07.09 |
| 리눅스 서버 웹 장애 보고할 때 HTTP 코드 정리하는 법, 한눈에 보이는 오류 보고 가이드 (0) | 2026.07.08 |