- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 Windows의 자동 정리 기능이나 서드파티 클리너가 개발 환경의 빌드 캐시를 “임시 파일”로 오인하여 삭제하는 문제를 재현 없이 차단하고, 조직 환경에서도 표준화 가능한 예외 설정·경로 설계·정리 스크립트 기준을 제공하는 데 있다.
1. 왜 빌드 캐시가 “임시 파일”로 지워지는가
빌드 캐시는 이름만 보면 “캐시”이지만 개발 워크플로에서는 속도와 재현성에 직결되는 자산이다. 문제는 많은 캐시가 사용자 프로필의 AppData, Temp, 숨김 폴더, 또는 “정리 대상”으로 분류되는 경로에 생성된다는 점이다. Windows의 저장소 관리 기능, 디스크 정리, 타사 클리너, 기업용 엔드포인트 정책이 이 경로를 광범위하게 스캔하면서 “사용하지 않는 파일” 또는 “임시 파일”로 판단해 삭제하는 경우가 발생한다.
1-1. 손실이 잦은 대표 시나리오
첫째, 빌드 시스템이 중간 산출물을 기본 Temp 경로에 두는 구성이다. 둘째, 패키지 매니저가 사용자 캐시 경로를 사용하고, 정리 도구가 이를 대용량 임시 파일로 간주하는 상황이다. 셋째, 공유 PC·VDI·RDP 환경에서 사용자 프로필 정리 정책이 강하게 적용된 환경이다. 넷째, 디스크 부족 시 자동 정리 트리거가 자주 발생하는 환경이다.
주의 : 빌드 캐시 삭제는 “재빌드하면 된다”로 끝나지 않는 경우가 많다. 패키지 다운로드 실패, 사내 프록시·인증 만료, 빌드 서버 자격 증명 문제, 오프라인 개발 환경, 특정 버전 패키지 폐기 등으로 인해 즉시 복구가 안 되는 장애로 확대될 수 있다.
2. 먼저 원인부터 특정하는 체크리스트
예외 설정은 “무엇이 지우는지”가 확정되어야 정확하게 적용된다. 아래 순서로 범인을 좁히는 것이 효과적이다.
| 점검 항목 | 확인 방법 | 삭제 흔적 | 다음 조치 |
|---|---|---|---|
| Storage Sense(저장소 센스) | 설정 > 시스템 > 저장소 | 임시 파일/다운로드/휴지통 자동 삭제 | 2-1 절의 설정 조정 |
| 디스크 정리/시스템 정리 | cleanmgr 실행, “시스템 파일 정리” | Windows 업데이트 정리, 임시 파일 대량 삭제 | 정리 항목 재검토, 자동 실행 차단 |
| 서드파티 클리너(CCleaner 등) | 클리너 옵션의 Include/Exclude | AppData/캐시 폴더까지 광범위 삭제 | 2-2 절의 예외 등록 |
| 기업 정책(GPO/MDM/스크립트) | 작업 스케줄러, 로그인 스크립트, Intune 정책 | 프로필 하위 폴더 정리, 특정 확장자 삭제 | 2-3 절의 표준 예외/화이트리스트화 |
| 보안 제품(AV/EDR) | 격리/정리 로그 확인 | 다운로드/캐시를 위험 파일로 처리 | 캐시 경로 검사 제외 검토 |
2-1. Windows Storage Sense로 인한 삭제를 막는 실무 설정
Storage Sense는 편리하지만 “폴더 단위 정교한 제외” 기능이 제한적이다. 따라서 개발 PC에서는 삭제 범위를 줄이고, 빌드에 영향이 큰 항목은 자동 정리에서 제외하는 방식으로 접근해야 한다.
2-1-1. 개인 PC에서 즉시 적용 가능한 권장값
설정 > 시스템 > 저장소에서 저장소 센스를 열어 아래 항목을 보수적으로 조정하는 방식이 안전하다.
| 설정 항목 | 권장값 | 이유 |
|---|---|---|
| 저장소 센스 자동 실행 | 개발 PC는 끔 또는 주기 최소화 | 대용량 캐시를 임시로 오인할 가능성이 커지기 때문이다. |
| 임시 파일 정리(앱이 사용하지 않는 임시 파일 삭제) | 켬을 쓰더라도 영향 경로를 분리해야 한다 | 캐시가 Temp 하위에 있으면 삭제 위험이 상시 존재하기 때문이다. |
| 다운로드 폴더 정리 | “안 함” | 오프라인 설치 파일, SDK, 패키지, 드라이버가 소실되기 쉽기 때문이다. |
| 휴지통 정리 | 30일 이상 또는 끔 | 실수로 지운 솔루션/패키지 복구 여지를 확보하기 때문이다. |
주의 : Storage Sense를 “완전히 끔”으로 두면 디스크 부족을 방치하는 부작용이 생길 수 있다. 개발 캐시를 안전한 경로로 옮긴 뒤에만 자동 정리를 점진적으로 켜는 방식이 바람직하다.
2-2. 서드파티 클리너에서 예외(Exclude)로 보호하는 방법
서드파티 클리너는 “브라우저 캐시” 수준을 넘어 사용자 AppData 전반을 청소 대상으로 포함하는 경우가 많다. 개발 PC에서 이 도구를 유지해야 한다면, 반드시 “삭제 대상(Include)”과 “보호 대상(Exclude)”를 분리해야 한다.
2-2-1. 예외로 보호해야 하는 대표 경로
아래 경로는 제품·구성에 따라 다르지만, 일반적으로 “재생성 가능한 임시 파일”이 아니라 “재다운로드/재인덱싱 비용이 큰 캐시”가 놓이기 쉬운 위치이다.
| 구분 | 대표 경로 예시 | 삭제 시 영향 |
|---|---|---|
| NuGet 패키지 캐시 | %UserProfile%\.nuget\packages | 빌드/복원 지연, 사내 피드 인증 문제 시 복구 불가 |
| Visual Studio 로컬 캐시(일부) | %LocalAppData%\Microsoft\VisualStudio\ | 로딩 지연, 분석기 캐시 재생성, 확장 기능 오류 |
| Node 패키지 캐시 | %LocalAppData%\npm-cache 또는 사용자 지정 캐시 | 의존성 재다운로드, 프록시 환경에서 장애 확대 |
| Gradle 캐시 | %UserProfile%\.gradle\caches | 대규모 빌드 재캐싱으로 생산성 급락 |
| Maven 로컬 저장소 | %UserProfile%\.m2\repository | 아카이브 의존성 복원 실패 가능 |
| Python 패키지 캐시 | %LocalAppData%\pip\Cache 또는 사용자 지정 | 빌드 휠 재생성, 다운로드 증가 |
| Docker/빌드 도구 캐시 | 도구별 상이(WSL/엔진/빌더) | 이미지 재빌드 증가, 네트워크/레지스트리 의존 증가 |
클리너에서 위 경로를 “폴더 제외”로 등록하고, 특히 %TEMP% 하위를 무차별 삭제하도록 설정되어 있다면 삭제 조건을 “오래된 파일만”으로 제한해야 한다.
2-3. 조직 환경에서 표준화하는 예외 전략
조직 환경에서는 개인이 설정을 바꾸기 어렵고, 정리 정책이 강하게 적용되는 경우가 많다. 이때 핵심은 “캐시를 보호할 경로를 표준으로 지정”하고, 정책/스크립트는 그 경로를 건드리지 않도록 설계하는 것이다.
2-3-1. 캐시 전용 루트 경로를 만드는 방식
가장 단순하고 효과적인 방식은 개발 도구 캐시를 한 곳으로 모으고, 그 경로를 정리 정책의 제외 대상으로 고정하는 방식이다. 예를 들어 C:\DevCache 또는 D:\DevCache 같은 전용 루트를 지정하는 방식이다. 이 루트 아래에 NuGet, npm, Gradle, pip 캐시를 모두 이동시키는 방식이다.
주의 : “Temp 아래에 캐시를 두지 않는다”가 최우선 원칙이다. 정리 도구는 Temp 폴더를 가장 공격적으로 삭제 대상으로 취급하기 때문이다.
2-3-2. 도구별 캐시 경로를 안전한 위치로 이동하는 예시
아래는 대표 도구의 “캐시 위치를 바꾸는” 실무 예시이다. 실제 조직 표준 경로에 맞게 값만 치환하면 된다.
REM NuGet: 환경 변수로 패키지 경로 이동 setx NUGET_PACKAGES "D:\DevCache\NuGet\packages" REM Gradle: 사용자 홈 이동 setx GRADLE_USER_HOME "D:\DevCache\Gradle" REM npm: 캐시 경로 이동(명령 프롬프트에서 실행) npm config set cache "D:\DevCache\npm-cache" --global REM pip: 캐시 경로 이동(환경 변수 예시) setx PIP_CACHE_DIR "D:\DevCache\pip-cache" 위 방식은 “자동 정리가 지우지 않는 위치로 캐시를 옮긴다”는 점에서 가장 재발 방지 효과가 크다. 단, 일부 도구는 기존 캐시를 그대로 두고 새 경로로 재생성하므로, 마이그레이션 후 구 캐시는 수동으로 정리하는 것이 바람직하다.
3. 안전한 임시 파일 정리의 원칙과 기준
임시 파일 정리를 아예 하지 않는 접근은 장기적으로 디스크 장애를 부른다. 따라서 “정리하되 빌드 캐시만은 보호”하는 기준을 문서화해야 한다.
3-1. 삭제 기준은 “경로 + 나이 + 사용 흔적”의 조합이어야 하다
경로만으로 판단하면 캐시가 섞여 들어가고, 나이만으로 판단하면 장기 캐시까지 지워진다. 따라서 최소한 다음 기준을 함께 적용해야 한다.
첫째, 삭제 대상 루트를 제한해야 한다. 둘째, 마지막 수정 시각 기준으로 충분히 오래된 파일만 삭제해야 한다. 셋째, 제외(화이트리스트) 경로를 최우선으로 보호해야 한다.
3-2. PowerShell로 “예외 포함 안전 정리”를 구현하는 예시
아래 예시는 Temp 정리를 하되, 개발 캐시 경로는 제외하고, 오래된 항목만 삭제하는 방식이다. 운영 적용 전에는 반드시 분석 모드로 결과를 확인해야 한다.
$TargetRoots = @( "$env:TEMP", "$env:LOCALAPPDATA\Temp" ) $ExcludeRoots = @( "D:\DevCache", "$env:USERPROFILE\.nuget\packages", "$env:USERPROFILE\.gradle", "$env:USERPROFILE\.m2", "$env:LOCALAPPDATA\npm-cache" ) $DaysOld = 14 $Now = Get-Date function Is-ExcludedPath($FullName, $ExcludeList) { foreach ($ex in $ExcludeList) { if ([string]::IsNullOrWhiteSpace($ex)) { continue } if ($FullName.StartsWith($ex, [System.StringComparison]::OrdinalIgnoreCase)) { return $true } } return $false } $DeleteCandidates = @() foreach ($root in $TargetRoots) { if (-not (Test-Path $root)) { continue } Get-ChildItem -Path $root -Force -Recurse -ErrorAction SilentlyContinue | ForEach-Object { $path = $_.FullName if (Is-ExcludedPath $path $ExcludeRoots) { return } $lastWrite = $_.LastWriteTime if ($lastWrite -lt $Now.AddDays(-$DaysOld)) { $DeleteCandidates += $_ } } } # 1) 분석 모드: 실제 삭제 없이 목록만 확인 $DeleteCandidates | Select-Object FullName, LastWriteTime | Sort-Object LastWriteTime | Out-Host # 2) 실제 삭제 모드로 전환하려면 아래 주석을 해제하고, 먼저 소량 경로에서 검증해야 한다 # $DeleteCandidates | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue 주의 : 자동 삭제 스크립트는 “실제 삭제 모드”를 바로 켜면 안 된다. 분석 모드로 후보 목록을 충분히 확인하고, 제외 경로가 기대대로 동작하는지 검증한 뒤 제한적으로 적용해야 한다.
4. 빌드 산출물(obj/bin)과 “캐시”를 구분해서 다루는 방법
개발 현장에서는 obj/bin 같은 중간 산출물과 패키지 캐시가 혼재되어 “그냥 다 지우면 되지 않느냐”로 흐르기 쉽다. 그러나 둘은 성격이 다르다. obj/bin은 프로젝트 단위이며 소스와 함께 재생성되기 쉬운 편이다. 반면 패키지 캐시와 도구 캐시는 네트워크·레포지토리·인증에 의존하며 재생성이 항상 보장되지 않는다.
4-1. 프로젝트 폴더 내 정리와 시스템 정리를 분리해야 한다
프로젝트 폴더의 obj/bin 정리는 개발자가 의도적으로 수행할 때 의미가 있다. 반면 시스템 정리 도구가 임의로 obj/bin까지 건드리기 시작하면, 증분 빌드 효율이 급격히 떨어지고, IDE 인덱스가 흔들리며, 디버깅 심볼이 소실되는 문제가 늘어난다.
4-2. 안전한 정리 운영 모델
| 정리 대상 | 권장 주체 | 권장 방식 | 자동화 권장도 |
|---|---|---|---|
| %TEMP% / 사용자 Temp | 시스템/스크립트 | 나이 기준 삭제 + 캐시 예외 | 높음 |
| 프로젝트 obj/bin | 개발자/CI | 클린 빌드가 필요할 때만 | 중간 |
| 패키지 캐시(NuGet/Gradle 등) | 개발자/플랫폼팀 | 경로 이동 후 보호, 정리는 정책적으로만 | 낮음 |
| IDE 인덱스/분석 캐시 | 개발자 | 문제 발생 시에만 제한적 삭제 | 낮음 |
5. 재발 방지를 위한 운영 팁
5-1. “캐시 루트 보호”를 원칙으로 문서화해야 한다
개발 PC 표준 이미지나 온보딩 문서에 “캐시 전용 루트 경로”와 “정리 정책 제외”를 명시해야 한다. 개인이 임의로 캐시 위치를 Temp로 되돌리면 다시 장애가 발생한다.
5-2. 디스크 부족을 빌미로 예외가 무력화되지 않게 해야 한다
디스크 부족 시 운영자가 임시로 강한 정리를 실행하면서 예외가 무시되는 사례가 있다. 이때를 대비해 캐시 루트는 다른 드라이브로 분리하거나, 최소 용량 가이드와 알림 기준을 함께 운영하는 것이 효과적이다.
5-3. “삭제 로그”를 남기는 정리 체계가 필요하다
무엇이 언제 삭제했는지 추적이 되지 않으면 예외 설정이 반복 시행착오로 흐른다. 스크립트 정리라면 삭제 후보와 실제 삭제 목록을 파일로 남기고, 정책 기반이라면 실행 시각과 대상 범위를 기록하는 것이 바람직하다.
FAQ
Storage Sense만 끄면 문제가 완전히 해결되는가?
일시적으로는 개선될 수 있지만 근본 해결은 아니다. 다른 정리 도구나 기업 정책이 동일 증상을 만들 수 있기 때문이다. 캐시를 Temp 밖의 안전한 경로로 이동시키고, 정리 도구에는 해당 경로를 예외로 등록하는 방식이 재발 방지에 가장 효과적이다.
개발자가 임의로 디스크 정리를 실행해도 안전한 기준이 있는가?
안전 기준은 “프로젝트 정리”와 “시스템 정리”를 분리하는 데서 시작한다. 프로젝트 obj/bin 정리는 개발자가 의도적으로 수행할 수 있지만, 패키지 캐시와 도구 캐시는 보호하는 기준이 필요하다. 캐시 루트 보호 원칙을 지키면 디스크 정리의 위험이 크게 줄어든다.
클리너에서 어떤 폴더를 반드시 제외해야 하는지 한 줄로 정리할 수 있는가?
한 줄로 요약하면 “사내 네트워크·인증에 의존하는 다운로드/패키지/빌드 캐시 폴더는 제외해야 한다”이다. 대표적으로 NuGet, Gradle, Maven, npm, pip 캐시와 개발 전용 캐시 루트는 자동 정리 대상에서 빼는 것이 안전하다.
Temp 정리를 해야 하는데, 캐시가 Temp 안에 이미 존재하면 어떻게 해야 하는가?
우선 캐시 경로를 Temp 밖으로 이동시키는 것이 우선이다. 이동이 즉시 어렵다면 임시로 정리 주기를 완화하고, 스크립트 정리 시 제외 경로를 확실히 적용해야 한다. 장기적으로는 도구별 설정을 통해 캐시를 전용 루트로 이관하는 것이 바람직하다.