이 글의 목적은 Windows의 임시 파일 자동 정리 기능과 각종 클리너가 개발 빌드 캐시와 빌드 산출물 폴더를 삭제해 빌드 시간이 급증하거나 오류가 반복되는 문제를 재현 없이 해결하도록, 예외 설정과 캐시 경로 고정 방법을 실무 기준으로 정리하는 것이다.
1. 문제 개요와 증상 정리
임시 파일 자동 정리는 디스크 공간을 확보하는 데 유용하지만, 개발 환경에서는 “임시처럼 보이는 캐시”가 실제로는 빌드 성능과 안정성을 좌우하는 핵심 데이터인 경우가 많다. 이때 자동 정리가 캐시를 지우면 다음과 같은 증상이 발생하다.
- 평소 1~3분 빌드가 10~30분 이상으로 늘어나다.
- 첫 빌드처럼 의존성을 다시 내려받아 네트워크 사용량이 급증하다.
- Incremental build가 깨져서 매번 전체 컴파일이 수행되다.
- “캐시 손상”, “패키지 누락”, “잠금 파일 오류”, “중간 산출물 없음”과 같은 오류가 반복되다.
- CI나 로컬 개발 PC에서만 간헐적으로 재현되어 원인 분석이 지연되다.
2. 어떤 기능이 캐시를 지우는지 원인부터 특정하다
캐시 손실은 Windows 기본 기능, 기업 보안 기준, 또는 서드파티 클리너가 개입하면서 발생하다. 원인을 특정하지 않으면 동일 문제가 재발하다. 아래 표 기준으로 먼저 범위를 좁히는 것이 실무적으로 가장 빠르다.
| 분류 | 대표 기능/프로그램 | 주요 삭제 위치 | 특징 | 우선 점검 |
|---|---|---|---|---|
| Windows 기본 | Storage Sense(저장소 센스) | %TEMP%, 임시 파일, 휴지통, 다운로드(설정에 따라) | 주기 실행, 사용자 설정/정책 영향 | 설정 앱, 정책, 작업 스케줄러 |
| Windows 기본 | 디스크 정리(cleanmgr) 및 자동화 | 임시 파일, 업데이트 정리 등 | /sageset, /sagerun으로 무인 실행 가능 | 작업 스케줄러, 스크립트 |
| 서드파티 | 클리너/최적화 도구 | Temp, 캐시, 브라우저/개발도구 캐시 | “안전 정리” 명목으로 광범위 삭제 | 설치 목록, 실행 로그 |
| 기업 환경 | 보안 기준/CIS/MDM 정책 | Temp, 사용자 프로필, 다운로드 | 사용자 UI에서 꺼도 다시 켜질 수 있음 | GPO/Intune/MDM 설정 |
2.1 가장 흔한 패턴을 먼저 의심하다
실무에서 가장 흔한 패턴은 “빌드 캐시를 %TEMP% 아래에 두고 있었는데 자동 정리 대상이 되었다” 또는 “캐시가 사용자 프로필 캐시 폴더에 있는데 클리너가 이를 임시로 판단해 삭제했다”인 경우다. 따라서 해결 전략은 다음 두 축으로 잡는 것이 안정적이다.
- 자동 정리 기능의 “임시 파일 정리” 범위를 줄이거나 주기를 조정하다.
- 빌드 캐시를 “정리 대상이 아닌 고정 경로”로 옮기고, 도구 설정으로 경로를 강제하다.
3. Windows Storage Sense(저장소 센스)로 인한 캐시 손실을 막다
3.1 설정 앱에서 즉시 점검하다
Windows 11 기준으로 저장소 센스는 임시 파일과 휴지통, 다운로드 등을 자동 정리할 수 있다. 개발 PC에서는 아래 항목이 빌드 캐시 손실과 직접 연동되는 경우가 많다.
- 임시 파일 정리(Temporary files) 자동 실행 여부를 끄거나 범위를 축소하다.
- 실행 주기(매일/매주/매월/저장 공간 부족 시)를 빌드 업무 특성에 맞게 조정하다.
- 다운로드 폴더 정리가 켜져 있으면 개발 도구 설치 파일, 오프라인 패키지, 아카이브가 지워질 수 있으므로 끄는 것이 안전하다.
3.2 기업 환경이라면 정책에 의해 다시 켜질 수 있음을 전제하다
도메인 환경, MDM 환경에서는 사용자가 설정에서 꺼도 정책이 재적용되면서 다시 켜질 수 있다. 이런 경우에는 IT 정책 담당자와 협의하여 “임시 파일 자동 정리”만 제한하거나, 개발 장비 그룹에만 다른 정책을 적용하는 방식이 필요하다.
4. “캐시를 안전한 경로로 옮기고 고정”이 핵심 해결책이다
자동 정리가 강력한 환경에서도 빌드가 안정적으로 유지되려면, 캐시와 중간 산출물을 다음 원칙으로 재배치해야 하다.
- 원칙 1: %TEMP%, C:\Windows\Temp 같은 임시 경로를 캐시 저장소로 쓰지 않다.
- 원칙 2: 프로젝트별/사용자별 고정 디렉터리를 만들고, 도구 설정으로 경로를 강제하다.
- 원칙 3: 캐시 경로를 한 곳으로 모으면 예외 설정과 백업, 모니터링이 쉬워지다.
4.1 권장 캐시 루트 디렉터리 예시
아래처럼 개발 캐시 전용 루트를 만들어 두면, 자동 정리 예외 처리와 디스크 관리가 단순해지다.
C:\DevCache\ C:\DevCache\npm\ C:\DevCache\pip\ C:\DevCache\gradle\ C:\DevCache\maven\ C:\DevCache\nuget\ C:\DevCache\docker\ C:\DevCache\unity\ C:\DevCache\unreal\5. 주요 빌드 도구별 캐시 경로 예외 설정 방법
아래 표는 실무에서 빈도가 높은 빌드 도구들의 “기본 캐시 위치”와 “안전한 경로로 이동하는 방법”을 정리한 것이다. 개발 PC의 자동 정리 정책을 완벽히 통제하기 어렵다면, 이 표대로 캐시 위치를 바꾸는 것이 가장 확실하다.
| 도구 | 기본 캐시/저장 위치(대표) | 권장 해결(경로 고정 방법) | 비고 |
|---|---|---|---|
| Gradle | C:\Users\%USERNAME%\.gradle | 환경변수 GRADLE_USER_HOME을 C:\DevCache\gradle로 설정하다. | 전역 캐시/로그/설정이 함께 이동하다. |
| Maven | C:\Users\%USERNAME%\.m2\repository | -Dmaven.repo.local=C:\DevCache\maven\repo로 강제하다. | 프로젝트별 settings.xml로도 제어 가능하다. |
| NuGet | C:\Users\%USERNAME%\.nuget\packages | 환경변수 NUGET_PACKAGES를 C:\DevCache\nuget\packages로 설정하다. | 빌드 안정성이 크게 개선되다. |
| pip | C:\Users\%USERNAME%\AppData\Local\pip\Cache | 환경변수 PIP_CACHE_DIR을 C:\DevCache\pip로 설정하다. | 오프라인 설치와 재빌드 속도에 영향이 크다. |
| npm | C:\Users\%USERNAME%\AppData\Local\npm-cache | npm config set cache C:\DevCache\npm --global로 설정하다. | CI/로컬 모두 일관성 확보가 쉽다. |
| Yarn | Yarn 버전에 따라 상이 | yarn config set cacheFolder C:\DevCache\yarn 또는 정책에 맞게 지정하다. | 버전별 키가 달라 확인이 필요하다. |
| Docker(BuildKit) | 기본은 Docker 데이터 경로 | buildx cache-to/cache-from로 외부 경로 또는 레지스트리 캐시를 사용하다. | 로컬 정리의 영향을 덜 받게 설계 가능하다. |
5.1 Windows 환경변수로 캐시 경로를 강제하는 예시
아래는 시스템 또는 사용자 환경변수로 캐시 경로를 고정하는 대표 예시다. 적용 후에는 터미널/IDE를 재시작해야 반영되다.
GRADLE_USER_HOME=C:\DevCache\gradle NUGET_PACKAGES=C:\DevCache\nuget\packages PIP_CACHE_DIR=C:\DevCache\pip5.2 .NET 빌드에서 obj/bin 손실이 잦다면 “중간 산출물 경로”를 바꾸다
.NET 계열은 프로젝트 폴더 내부의 obj/bin이 삭제되면 재빌드가 발생하지만, 임시 파일 정리와 직접 충돌하기보다는 “클리너가 산출물 폴더를 불필요 파일로 판단”하는 케이스가 많다. 이때는 프로젝트 공통 설정 파일로 중간 산출물과 출력 경로를 별도 드라이브 또는 별도 루트로 옮기면 충돌이 줄어들다.
<!-- Directory.Build.props 예시이다. 솔루션 루트에 두고 공통 적용하다. --> <Project> <PropertyGroup> <BaseIntermediateOutputPath>C:\DevCache\dotnet\obj\</BaseIntermediateOutputPath> <BaseOutputPath>C:\DevCache\dotnet\bin\</BaseOutputPath> </PropertyGroup> </Project>6. 임시 파일 자동 정리를 “안전한 스크립트”로 대체하다
공간 확보가 꼭 필요하다면, 무작정 클리너에 맡기기보다 “삭제 기준이 명확한 스크립트”로 대체하는 것이 안전하다. 핵심은 캐시 루트(C:\DevCache)를 절대 건드리지 않고, 임시 경로에서도 오래된 것만 지우는 정책을 적용하는 것이다.
6.1 PowerShell 예시 스크립트로 안전 정리를 구현하다
# 안전 정리 스크립트 예시이다. # 원칙은 다음과 같아야 하다. # 1) 캐시 루트(C:\DevCache)는 제외하다. # 2) TEMP 내부에서도 "오래된 파일"만 정리하다. # 3) 잠금 파일/사용 중 파일은 오류 없이 건너뛰다.
$Days = 14
$Now = Get-Date
$Cutoff = $Now.AddDays(-$Days)
$TempPaths = @(
$env:TEMP,
$env:TMP,
"C:\Windows\Temp"
)
$ExcludeRoots = @(
"C:\DevCache"
)
foreach ($p in $TempPaths) {
if (-not (Test-Path $p)) { continue }
$items = Get-ChildItem -LiteralPath $p -Force -Recurse -ErrorAction SilentlyContinue |
Where-Object {
$.FullName -notlike "$($ExcludeRoots[0])*" -and
$.LastWriteTime -lt $Cutoff
}
foreach ($i in $items) {
try {
if ($i.PSIsContainer) {
Remove-Item -LiteralPath $i.FullName -Recurse -Force -ErrorAction Stop
} else {
Remove-Item -LiteralPath $i.FullName -Force -ErrorAction Stop
}
} catch {
# 사용 중이거나 권한 문제면 건너뛰다.
continue
}
}
}7. 서드파티 클리너를 쓰는 경우 예외 설정 원칙을 적용하다
서드파티 클리너는 제품마다 UI가 다르지만, 예외 설정 원칙은 공통이다.
- 개발 캐시 루트(C:\DevCache)를 “정리 제외” 또는 “보호 폴더”로 등록하다.
- “개발 도구 캐시”, “패키지 매니저 캐시”, “빌드 산출물 폴더” 옵션이 있다면 비활성화하다.
- 자동 실행 스케줄이 켜져 있다면, 개발 시간대(업무 시간)에는 실행되지 않도록 조정하다.
- 정리 로그를 남기는 모드가 있다면 반드시 활성화하여 추후 원인 추적이 가능하도록 하다.
8. 실무 적용 체크리스트로 재발을 막다
아래 체크리스트를 한 번에 적용하면, 임시 파일 자동 정리로 인한 빌드 캐시 손실 문제를 구조적으로 차단할 수 있다.
| 단계 | 체크 항목 | 목표 | 완료 기준 |
|---|---|---|---|
| 1 | 저장소 센스 설정 및 실행 주기 점검 | 임시 파일 자동 정리 과도 실행 방지 | 임시 파일 정리 옵션이 개발 정책에 맞게 조정되다. |
| 2 | 클리너/최적화 도구 자동 실행 여부 확인 | 무인 삭제 차단 | 스케줄 정리가 꺼지거나 예외가 반영되다. |
| 3 | 캐시 루트(C:\DevCache) 생성 및 권한 정리 | 캐시를 한 곳으로 통합 | 도구별 캐시가 루트 하위로 이동되다. |
| 4 | 도구별 캐시 경로 강제(환경변수/설정) | 임시 경로 의존 제거 | 빌드 후 캐시가 고정 경로에 쌓이다. |
| 5 | 필요 시 안전 정리 스크립트로 대체 | 공간 확보와 안정성 동시 달성 | 캐시 루트는 보존되고 임시만 정리되다. |
FAQ
저장소 센스를 껐는데도 캐시가 계속 지워지다. 무엇을 봐야 하다?
기업 환경에서는 정책(GPO/MDM)이나 서드파티 클리너 스케줄이 다시 켜는 경우가 많다. 설정 앱에서 껐더라도 일정 시간 뒤 자동으로 원복되면 정책 적용을 의심해야 하다. 또한 작업 스케줄러에 cleanmgr, 정리 스크립트, 최적화 도구 작업이 등록되어 있는지 확인해야 하다.
캐시 경로를 바꾸면 기존 캐시는 어떻게 하다?
경로 변경 후 첫 빌드에서는 새 경로로 캐시가 다시 생성되다. 기존 캐시는 즉시 삭제하지 말고, 정상 빌드가 여러 번 확인된 뒤에 공간이 필요할 때 단계적으로 정리하는 것이 안전하다.
캐시를 다른 드라이브로 옮기면 빌드가 더 빨라지다?
드라이브 성능에 따라 달라지다. NVMe SSD로 옮기면 속도가 개선될 수 있고, 느린 HDD로 옮기면 오히려 느려질 수 있다. 중요한 것은 속도보다 “예기치 않은 삭제가 없는 안정성”이며, 그 다음에 성능을 튜닝하는 순서가 안전하다.
프로젝트 폴더 안의 obj/bin을 보호만 하면 해결되다?
일부 케이스는 해결되지만, 패키지 캐시(Gradle, NuGet, npm 등)가 별도로 삭제되면 여전히 빌드 시간이 폭증하다. 따라서 산출물 폴더 보호와 함께 패키지 캐시 경로 고정을 동시에 적용하는 것이 재발 방지에 유리하다.