Windows · PowerShell · 실제 복구 기록
Codex로 디스크 공간 정리하기: C 드라이브 0GB에서 12.76GB를 되찾은 실제 사례
개인 파일은 그대로 두고, 고정된 캐시 경로의 재생성 가능한 데이터만 정리한 과정
어디에서 공간을 되찾았나
실제 삭제량 기준입니다. 시스템 파일과 개인 원본은 제외했습니다.
안전한 정리의 5단계
드라이브 측정
후보 크기 계산
재생성 여부 판단
절대 경로 검증
전후 수치 확인
안녕하세요, SCV입니다.
윈도우가 “디스크 공간이 부족합니다”라고 경고할 때 가장 위험한 대응은 큰 폴더부터 무작정 지우는 것입니다. 이번에는 C 드라이브의 남은 공간이 사실상 0GB가 된 실제 PC에서 Codex에게 “디스크 공간 부족하다는데 정리 좀 해줘”라고 요청했습니다. 다만 명령의 핵심 조건은 분명했습니다. 개인 문서나 프로젝트처럼 사람이 만든 원본은 건드리지 않고, 위치와 용도가 확인된 재생성 가능 캐시만 정리하도록 범위를 제한했습니다. 일반 임시 폴더도 사용 중인 파일과 권한이 필요한 항목은 건너뛰었습니다. 결과는 C 드라이브 여유 공간 0GB에서 12.76GB로 회복, 정리 작업으로 직접 확보한 공간은 약 8.96GB였습니다.
이 글은 단순히 PowerShell 삭제 명령을 복사하는 튜토리얼이 아닙니다. 무엇을 확인했고, 어떤 기준으로 삭제 대상을 정했으며, 왜 Windows 업데이트 캐시 일부와 사용 중인 임시 파일은 남겨 두었는지 실제 판단 과정을 기록합니다. 같은 상황을 만난 개발자라면 명령보다 이 순서를 먼저 가져가면 좋습니다.
먼저 결론: 무엇이 얼마나 정리됐나
점검 당시 C 드라이브는 269.79GB를 사용하고 있었고 표시 가능한 여유 공간은 0GB였습니다. 반면 D 드라이브에는 109.62GB가 남아 있었습니다. 휴지통은 0GB라 비워도 효과가 없었습니다. Codex가 캐시 후보를 재귀적으로 계측하자 Gradle 캐시 5.148GB, 사용자 홈의 .cache 1.534GB, npm 캐시 1.101GB, Windows 업데이트 다운로드 캐시 0.961GB, 사용자 임시 폴더 0.611GB, pip 캐시 0.018GB가 확인됐습니다.
실제 정리에서는 Gradle 캐시 5.133GB, 재생성 가능 여부를 확인한 사용자 캐시 1.531GB, npm 캐시 1.101GB, 사용 중이지 않은 임시 데이터 0.236GB, pip 캐시 0.018GB를 확보했습니다. Windows 업데이트 다운로드 폴더는 권한과 사용 상태 때문에 984.5MB가 남았고, 사용자 임시 폴더에도 사용 중인 파일 384.9MB가 남았습니다. 삭제 권한을 우회하지 않고 안전하게 건너뛴 결과입니다. 작업 완료 직후 측정값은 C 드라이브 12.76GB, D 드라이브 109.62GB였습니다. 이후 첨부한 파일 탐색기 화면에서는 C 드라이브 10.8GB로 보이는데, 이는 프로그램 실행과 캐시 재생성으로 사용량이 다시 변한 시점의 화면입니다.
여기서 “직접 삭제한 용량은 8.96GB인데 왜 여유 공간은 12.76GB인가?”라는 의문이 생길 수 있습니다. 최초 점검 시 Windows가 여유 공간을 0GB로 표시했고, 삭제 직전에는 백그라운드 정리나 파일 해제 등으로 일부 공간이 이미 돌아온 상태였습니다. 따라서 결과는 작업 전후 드라이브 수치와 개별 삭제 합계를 구분해서 읽어야 합니다. 중요한 것은 개별 경로별 삭제량을 별도로 측정했다는 점입니다.
실제 파일 삭제, 정말 괜찮았나?
삭제 허용 기준
5개 조건을 모두 만족한 데이터만 정리했습니다.
파일 삭제라는 표현만 보면 불안한 것이 당연합니다. 하지만 이번 작업은 C 드라이브에서 큰 파일을 찾아 지우는 방식이 아니었습니다. 삭제가 허용된 대상은 미리 작성한 고정 목록에 들어 있는 캐시 경로뿐이었습니다. Gradle의 caches, Windows 기본 위치의 npm-cache와 pip Cache처럼 이름뿐 아니라 공식 문서와 용도가 분명한 위치를 선택했습니다. 사용자 홈의 .cache도 내부 데이터가 다시 생성되거나 내려받을 수 있는 캐시인지 확인한 뒤 포함했습니다.
정리 대상은 다음 5개 조건을 모두 만족해야 했습니다. 첫째, 경로가 캐시 또는 일시 데이터 저장 위치로 명확해야 합니다. 둘째, 삭제 후 프로그램이 다시 만들거나 패키지 관리자가 다시 내려받을 수 있어야 합니다. 셋째, 문서, 사진, 다운로드, 소스 코드, 프로젝트, 데이터베이스, 설정 파일 같은 원본이 아니어야 합니다. 넷째, Resolve-Path로 확인한 절대 경로가 미리 지정한 경로와 정확히 일치해야 합니다. 다섯째, 사용 중이거나 권한이 필요한 파일은 강제로 지우지 않고 그대로 남겨야 합니다.
따라서 “실제 파일을 삭제했으니 문제가 생길 수 있다”기보다 “프로그램이 성능을 위해 저장해 둔 복사본을 비웠다”에 가깝습니다. 캐시를 비우면 다음 Gradle 빌드나 npm, pip 설치가 처음 한 번 느려질 수 있고 네트워크 다운로드가 다시 발생할 수는 있습니다. 그러나 프로젝트 원본이나 개인 파일이 없어지는 작업은 아닙니다. 이 기준을 만족하지 못한 pagefile.sys, Windows 시스템 파일, Downloads, Documents, Desktop, 프로젝트 폴더는 크기와 관계없이 삭제 대상에서 제외했습니다.
일반 Temp 폴더는 캐시보다 범위가 넓으므로 더욱 보수적으로 다뤘습니다. 이번 사례에서는 사용 중이지 않고 지워도 다시 만들어지는 일시 데이터만 처리했으며, 잠겨 있던 384.9MB는 남겼습니다. 더 엄격하게 운용하려면 다음 실행부터는 일반 Temp를 자동 정리 목록에서 제외하고 Windows 저장소 센스에 맡겨도 됩니다. 핵심은 폴더 이름이 아니라 재생성 가능 여부와 고정 경로 검증입니다.
Codex가 바로 삭제하지 않고 진단부터 한 이유
디스크 정리의 핵심은 삭제 기술이 아니라 분류입니다. 파일은 크게 사용자 원본, 애플리케이션 데이터, 재생성 가능한 캐시, 시스템 관리 파일로 나눌 수 있습니다. 사진, 문서, 다운로드, 소스 코드, 데이터베이스는 사용자가 필요성을 판단해야 하는 원본입니다. 반면 패키지 관리자가 다시 내려받을 수 있는 캐시와 실패한 프로그램이 남긴 임시 파일은 상대적으로 안전한 후보입니다. pagefile.sys 같은 시스템 파일은 크기가 커도 임의 삭제 대상이 아닙니다.
이번 사례에서도 C 루트에서 pagefile.sys가 24.24GB인 것이 보였습니다. 숫자만 보면 가장 먼저 지우고 싶지만, 페이지 파일은 Windows가 가상 메모리를 처리하는 데 사용하는 시스템 파일입니다. 사용 중인 파일을 강제로 지우려 하거나 설정을 즉흥적으로 바꾸면 성능 저하, 애플리케이션 오류, 시스템 불안정으로 이어질 수 있습니다. 그래서 목록에는 표시만 하고 삭제 대상에서는 제외했습니다.
휴지통 역시 먼저 측정했습니다. 흔히 “휴지통을 비우면 된다”고 생각하지만 이번 PC의 휴지통은 이미 0GB였습니다. 효과 없는 작업을 반복하지 않고 실제로 큰 경로를 찾은 것이 5GB가 넘는 Gradle 캐시를 발견한 이유입니다.
1단계: 드라이브 여유 공간 확인
PowerShell의 Get-PSDrive는 현재 세션에서 드라이브 정보를 가져옵니다. FileSystem 공급자로 한정하면 레지스트리나 인증서 같은 PowerShell 가상 드라이브를 제외하고 실제 파일 시스템 드라이브만 볼 수 있습니다.
사용한 형태는 다음과 같습니다.
Get-PSDrive -PSProvider FileSystem | Select-Object Name, Used, Free, Root사람이 읽기 쉽게 GB로 변환하면 사용량과 여유 공간을 빠르게 비교할 수 있습니다. 중요한 것은 “C가 부족하다”는 감각을 수치로 바꾸는 것입니다. 정리 후에도 같은 명령을 다시 실행해야 실제 효과를 확인할 수 있습니다.
2단계: 후보 폴더의 크기만 측정
다음 단계에서는 삭제하지 않고 후보 폴더의 파일 크기 합계를 구했습니다. 대상은 사용자 임시 폴더, Windows 임시 폴더, Windows 업데이트 다운로드 폴더, 충돌 덤프, 브라우저 임시 캐시, npm 캐시, pip 캐시, 사용자 .cache, NuGet 패키지, Gradle 캐시, Cargo 레지스트리였습니다.
측정은 Get-ChildItem으로 파일을 재귀 조회하고 Measure-Object의 Length 합계를 계산하는 방식입니다. 접근이 거부되거나 사용 중인 경로는 ErrorAction SilentlyContinue로 건너뜁니다. 이 옵션은 오류를 숨기기 위한 꼼수가 아니라, 읽을 수 없는 시스템 경로 때문에 전체 진단이 중단되지 않게 하는 장치입니다. 다만 중요한 오류까지 놓치지 않도록 최종 삭제 결과에서는 경로별 남은 용량도 다시 측정해야 합니다.
이번 결과에서 가장 큰 후보는 C:\Users\사용자\.gradle\caches였습니다. 5.148GB로 전체 후보 중 절반 이상을 차지했습니다. 그다음은 사용자 .cache 1.534GB, npm-cache 1.101GB였습니다. 개발 환경을 오래 사용하면 패키지와 빌드 도구가 내려받은 파일이 누적되기 때문에 일반적인 Windows 정리 화면만으로는 이 공간이 잘 드러나지 않을 수 있습니다.
3단계: 무엇을 지워도 되는지 판단
Gradle의 공식 문서에 따르면 의존성 캐시는 GRADLE_USER_HOME 아래 caches에 저장되며, 다운로드한 바이너리와 메타데이터를 재사용해 네트워크 요청을 줄입니다. 캐시를 지우면 프로젝트 원본이 사라지는 것이 아니라 다음 빌드에서 필요한 의존성을 다시 내려받게 됩니다. 따라서 디스크가 완전히 찬 긴급 상황에서는 큰 효과를 낼 수 있지만, 다음 빌드 시간이 길어지고 네트워크 사용량이 늘어날 수 있습니다. 빌드가 실행 중일 때는 캐시 잠금과 충돌 가능성이 있으므로 관련 프로세스를 종료한 뒤 정리하는 편이 안전합니다.
npm 공식 문서는 Windows의 기본 캐시 위치를 %LocalAppData%\npm-cache로 설명합니다. npm 캐시는 자체 복구를 고려해 설계됐고 보통은 지울 필요가 없지만, 디스크 공간 회수가 목적이라면 정리할 수 있습니다. 공식 CLI를 쓸 때는 npm cache verify로 무결성과 불필요한 데이터를 먼저 검사할 수 있고, 전체 삭제는 npm cache clean --force를 사용합니다. 이번 사례에서는 대상 경로를 검증한 뒤 캐시 폴더 내용만 제거했습니다.
pip 공식 문서는 Windows 캐시 기본 위치를 %LocalAppData%\pip\Cache로 안내합니다. py -m pip cache info로 위치와 용량을 보고, py -m pip cache purge로 wheel과 HTTP 캐시를 비울 수 있습니다. 이번 PC의 pip 캐시는 18MB 정도라 큰 비중은 아니었지만, 동일한 원칙을 적용해 함께 정리했습니다. 캐시를 영구적으로 끄는 것은 반복 다운로드와 빌드 때문에 오히려 비효율적일 수 있으므로 권장하지 않습니다.
사용자 홈의 .cache는 프로그램마다 의미가 다를 수 있습니다. 이름이 cache라고 해서 무조건 전체를 삭제하는 습관은 좋지 않습니다. 이번에는 내부가 재생성 가능한 캐시인지 확인하고 정리 대상으로 포함했습니다. 머신러닝 모델이나 대형 데이터셋이 이 폴더에 있다면 다시 다운로드하는 비용이 클 수 있으므로, 평상시에는 하위 폴더별 크기와 용도를 확인하는 편이 낫습니다.
Windows 업데이트 다운로드 폴더는 약 0.961GB였지만 실제로는 지워지지 않았습니다. PowerShell의 Force 옵션도 운영체제의 보안 권한을 우회하지 못합니다. Windows Update 서비스가 사용 중이거나 관리자 권한이 필요한 파일을 억지로 다루지 않고 남긴 것은 올바른 결과입니다. 이런 영역은 Windows 설정의 저장소 센스나 디스크 정리 같은 공식 기능으로 처리하는 편이 좋습니다.
4단계: 삭제 전에 경로를 검증
이번 자동화에서 가장 중요한 안전장치는 삭제 명령 자체가 아니라 경로 검증이었습니다. 정리할 경로를 고정된 목록으로 만들고, 각 경로가 실제로 존재하는지 Test-Path로 확인했습니다. 이어 Resolve-Path로 얻은 절대 경로가 예정한 대상과 정확히 같은지 비교했습니다. 하위 항목을 열거한 뒤에는 각 항목의 전체 경로가 검증된 루트 경로와 디렉터리 구분자로 시작하는지도 확인했습니다.
이 검증이 필요한 이유는 문자열 조합 실수, 빈 변수, 와일드카드 해석 때문입니다. 예를 들어 삭제 대상 변수가 비어 있는데 루트 경로와 결합되면 의도보다 넓은 위치를 가리킬 수 있습니다. 그래서 와일드카드가 해석되는 Path 대신 문자열을 그대로 다루는 LiteralPath를 사용했습니다. Microsoft의 Remove-Item 문서도 LiteralPath가 와일드카드를 해석하지 않는 매개변수임을 설명합니다.
삭제는 캐시 루트 폴더 자체가 아니라 그 안의 자식 항목에만 적용했습니다. 루트가 유지되면 프로그램이 기대하는 폴더 구조를 보존할 수 있고, 삭제 범위도 명확해집니다. 사용 중이거나 권한이 없는 항목은 ErrorAction SilentlyContinue로 건너뛴 뒤 남은 크기를 다시 계산했습니다. 즉 “명령이 끝났다”가 성공 기준이 아니라 “경로별로 몇 GB가 줄었고 몇 MB가 남았는가”가 성공 기준입니다.
실제 정리 흐름을 재현하는 PowerShell 예시
아래 코드는 원리를 보여 주기 위한 축약 예시입니다. 그대로 실행하기 전에 사용자 이름과 경로를 자신의 환경에 맞게 확인해야 합니다. 먼저 측정만 하고, 결과를 검토한 뒤 삭제 단계를 실행하세요. 특히 Downloads, Documents, Desktop, 프로젝트 폴더는 자동 삭제 목록에 넣지 않는 것이 좋습니다.
Get-PSDrive -PSProvider FileSystem
$targets = @(
"$env:USERPROFILE\.gradle\caches",
"$env:LOCALAPPDATA\npm-cache",
"$env:LOCALAPPDATA\pip\Cache",
"$env:TEMP"
)
foreach ($target in $targets) {
if (Test-Path -LiteralPath $target) {
$sum = (Get-ChildItem -LiteralPath $target -File -Recurse -Force -ErrorAction SilentlyContinue |
Measure-Object Length -Sum).Sum
[pscustomobject]@{ Path = $target; GB = [math]::Round($sum / 1GB, 3) }
}
}이 측정 결과를 확인한 뒤에는 캐시별 공식 명령을 우선 고려할 수 있습니다.
npm cache verify
npm cache clean --force
py -m pip cache info
py -m pip cache purgeGradle 캐시는 다음 빌드 시 재생성된다는 점을 알고 정리해야 합니다. 빌드 도중에는 삭제하지 말고 Android Studio, Gradle 데몬, 관련 터미널 작업을 종료하세요. 자주 쓰는 프로젝트라면 전체 캐시 대신 오래된 버전이나 사용하지 않는 항목만 정리하는 방법도 고려할 수 있습니다.
Codex에게 요청할 때 안전성을 높이는 프롬프트
“디스크 정리해 줘”만으로도 작업은 시작할 수 있지만, 다음 조건을 함께 주면 의도가 더 명확해집니다.
윈도우 C 드라이브 용량을 확인해 줘. 먼저 삭제 없이 큰 폴더와 재생성 가능한 캐시를 측정하고 결과를 알려 줘. 삭제는 Gradle caches, npm-cache, pip Cache처럼 용도가 확인된 고정 캐시 경로에만 허용해. 개인 문서, 다운로드, 사진, 프로젝트, 데이터베이스, 설정 파일, 시스템 파일은 삭제하지 마. 일반 Temp 폴더는 자동 삭제 대상에서 제외하고 Windows 저장소 센스를 우선 안내해 줘. 삭제 전에는 Resolve-Path로 절대 경로가 허용 목록과 정확히 일치하는지 검증하고, 캐시 루트는 남긴 채 내부 데이터만 지워 줘. 사용 중이거나 권한이 없는 파일은 건너뛰고, 작업 전후 여유 공간과 경로별 확보 용량을 비교해 줘.
이 프롬프트는 다섯 가지 경계를 만듭니다. 첫째 진단과 삭제를 분리합니다. 둘째 삭제 가능한 캐시 경로를 허용 목록으로 고정합니다. 셋째 개인 원본과 시스템 파일을 명시적으로 제외합니다. 넷째 절대 경로 검증을 요구합니다. 다섯째 잠긴 파일을 강제로 처리하지 않게 합니다. 자동화 도구를 쓸 때는 “무엇을 할지”만큼 “무엇을 하지 않을지”를 명확히 적는 것이 중요합니다.
정리 후 반드시 확인할 것
첫 번째는 드라이브 여유 공간입니다. Get-PSDrive로 C 드라이브의 Free 값을 다시 확인합니다. 두 번째는 삭제 대상별 남은 크기입니다. 이번 사례에서는 Gradle 캐시 14.9MB, 사용자 .cache 2.8MB, npm 캐시 0MB, pip 캐시 0MB, 사용자 임시 폴더 384.9MB가 남았습니다. Gradle과 사용자 캐시에 소량이 다시 생긴 것은 실행 중인 도구가 필요한 파일을 재생성했을 가능성이 있습니다.
세 번째는 개발 환경의 정상 동작입니다. Gradle 빌드, npm install, pip install을 다음에 실행하면 패키지를 다시 내려받을 수 있습니다. 인터넷 연결이 제한된 환경이나 곧 발표해야 하는 상황이라면 캐시를 지우기 전에 필요한 의존성을 확보했는지 확인해야 합니다. 캐시 삭제는 소스 코드를 지우지는 않지만 오프라인 작업 능력과 첫 실행 속도에는 영향을 줍니다.
네 번째는 Windows 업데이트와 시스템 상태입니다. 디스크가 0GB에 가까우면 업데이트, 브라우저, 빌드, 압축 해제, 가상 메모리 등 여러 작업이 실패할 수 있습니다. 12.76GB를 확보했더라도 269.79GB 드라이브 기준 4.7%에 불과하므로 장기적으로 충분한 상태는 아닙니다. 큰 개인 파일을 D 드라이브로 옮기거나 사용하지 않는 앱을 제거하고 저장소 센스를 설정하는 후속 조치가 필요합니다.
Windows 기본 기능도 함께 사용하기
Microsoft는 저장소 센스를 사용해 임시 파일과 휴지통 항목을 자동으로 정리할 수 있다고 안내합니다. Windows 11에서는 설정, 시스템, 저장소에서 저장소 센스를 켜고 정리 권장 사항을 검토할 수 있습니다. 기본 설정에서는 다운로드 폴더와 클라우드 파일을 임의로 지우지 않지만, 사용자가 보존 기간을 설정할 수 있으므로 옵션을 꼼꼼히 읽어야 합니다.
Windows 업데이트 공간이 부족하다면 저장소 센스와 디스크 정리를 먼저 사용하는 것이 좋습니다. 외장 저장 장치를 임시 공간으로 활용하는 방법도 있습니다. 시스템 폴더를 수동으로 강제 삭제하는 것보다 Windows가 제공하는 정리 절차를 따르는 편이 업데이트 상태와 권한을 올바르게 처리할 가능성이 높습니다.
이번 사례에서 얻은 교훈
첫째, 가장 큰 파일이 가장 안전한 삭제 대상은 아닙니다. 24.24GB의 pagefile.sys는 그대로 두고, 합계 8.96GB의 캐시를 정리한 것이 좋은 예입니다. 둘째, 휴지통처럼 익숙한 후보도 먼저 측정해야 합니다. 이번에는 0GB라 아무 효과가 없었습니다. 셋째, 개발 도구 캐시는 생각보다 큽니다. Gradle 하나만 5GB가 넘었고 npm까지 합치면 6GB 이상이었습니다.
넷째, 권한 오류와 잠긴 파일은 억지로 뚫을 문제가 아닙니다. 남은 Windows 업데이트 캐시 984.5MB와 임시 파일 384.9MB는 시스템이 사용 중인 항목을 보호한 결과입니다. 다섯째, 삭제 후 검증이 자동화의 일부여야 합니다. 작업 전후 드라이브 수치, 경로별 확보량, 경로별 잔여량을 모두 확인해야 “대충 지웠다”가 아니라 재현 가능한 정리가 됩니다.
Codex의 장점은 한 줄짜리 삭제 명령을 만들어 주는 데 있지 않았습니다. 여러 위치를 빠르게 계측하고, 위험한 시스템 파일과 재생성 가능한 캐시를 구분하고, 경로를 검증한 뒤 결과를 다시 측정하는 전체 흐름을 실행했다는 데 있습니다. 자동화가 강력할수록 삭제 범위를 좁히고 증거를 남기는 방식이 더 중요합니다.
실패하기 쉬운 접근과 개선 방법
첫 번째 실수는 파일 탐색기에서 크기가 큰 폴더를 발견하자마자 삭제하는 것입니다. AppData에는 캐시뿐 아니라 애플리케이션 설정, 로그인 상태, 로컬 데이터베이스가 함께 있을 수 있습니다. 폴더 이름만 보고 판단하지 말고 프로그램 공식 문서에서 기본 캐시 위치와 재생성 여부를 확인해야 합니다. 이번 사례도 AppData 전체가 아니라 npm-cache, pip Cache, Temp처럼 용도가 명확한 하위 경로만 지정했습니다.
두 번째 실수는 한 번에 여러 루트 경로를 와일드카드로 지우는 것입니다. 명령은 짧아지지만 변수가 비어 있거나 특수문자가 해석되면 예상보다 넓은 범위가 선택될 수 있습니다. 대상 목록을 출력하고, Resolve-Path 결과를 확인하고, LiteralPath로 자식 항목을 하나씩 처리하면 코드가 길어져도 검토 가능성이 높아집니다. 처음 실행할 때는 Remove-Item의 WhatIf 옵션으로 삭제 예정 항목을 미리 확인하는 방법도 유용합니다.
세 번째 실수는 오류가 없으면 모두 삭제됐다고 믿는 것입니다. 잠긴 파일, 접근 권한, 백신 검사, 실행 중인 빌드 프로세스 때문에 일부 항목이 남을 수 있습니다. 그래서 삭제 전 크기와 삭제 후 크기의 차이를 경로별로 계산해야 합니다. 이번 작업에서도 Windows 업데이트 캐시는 0GB가 확보됐고 984.5MB가 그대로 남았다는 사실을 별도로 기록했습니다. 이 수치가 없었다면 전체 명령이 성공한 것처럼 오해하기 쉽습니다.
네 번째 실수는 캐시 삭제를 매주 무조건 반복하는 것입니다. 캐시는 설치와 빌드를 빠르게 하기 위해 존재합니다. 여유 공간이 충분한데도 자주 비우면 네트워크 트래픽과 빌드 시간이 늘고, 출장이나 장애 상황에서 오프라인 빌드가 어려워집니다. 정리는 사용량이 임계값을 넘었을 때 실행하고, 자주 쓰는 도구와 오래 쓰지 않은 도구를 구분하는 편이 효율적입니다.
다섯 번째 실수는 확보한 공간을 보고 작업을 끝내는 것입니다. C 드라이브가 다시 차는 원인을 줄이지 않으면 같은 문제가 반복됩니다. Gradle과 npm 캐시가 큰 개발 PC라면 새 SDK와 패키지 버전을 설치할 때 증가 폭을 주기적으로 확인해야 합니다. Docker 이미지, 가상 머신, Android 에뮬레이터, 로컬 AI 모델처럼 더 큰 저장소를 사용하는 도구도 별도 목록으로 관리하는 것이 좋습니다. 다만 이 항목들은 프로젝트나 실행 환경에 직접 영향을 줄 수 있으므로 캐시와 같은 방식으로 자동 삭제하면 안 됩니다.
재발 방지를 위한 월간 점검표
매달 한 번 C 드라이브의 전체 용량, 남은 용량, 여유 비율을 기록합니다. 여유 비율이 계속 줄어들면 휴지통, 다운로드, 임시 파일, 개발 캐시, 설치된 앱 순서로 원인을 분리합니다. 다운로드와 문서는 자동 삭제하지 않고 날짜와 크기 기준으로 사람이 검토합니다. 개발 캐시는 Gradle, npm, pip, NuGet, Cargo처럼 도구별로 위치와 용도를 기록합니다.
Windows 저장소 센스는 시스템 임시 파일 정리에 활용하되 다운로드 폴더 보존 기간을 확인합니다. D 드라이브처럼 여유가 있는 볼륨이 있다면 대형 설치 파일, 압축 파일, 영상, 오래된 프로젝트 백업을 옮기는 방안을 검토합니다. 이동 후에는 바로 원본을 지우지 말고 파일 개수와 용량, 필요한 경우 해시를 비교한 뒤 삭제합니다.
마지막으로 정리 기록을 남깁니다. 작업 날짜, 정리 전 여유 공간, 삭제한 경로, 확보 용량, 남은 오류, 다음 점검 시점을 한 표에 적어 두면 증가 속도를 알 수 있습니다. 이번 사례처럼 “2026년 7월 15일, C 드라이브 0GB, 캐시 8.96GB 정리, 최종 여유 12.76GB, Windows 업데이트 캐시 984.5MB 잔존” 정도만 있어도 다음 작업의 기준점이 됩니다.
마무리
이번 실제 사례의 핵심 수치는 0GB에서 12.76GB, 직접 정리한 캐시는 약 8.96GB입니다. 하지만 더 중요한 결과는 삭제 범위를 고정된 캐시 경로로 제한했다는 점입니다. 개인 문서와 프로젝트를 건드리지 않았고, 24.24GB의 페이지 파일을 크다는 이유만으로 삭제하지 않았으며, 권한이 필요한 시스템 캐시는 남겨 두었습니다.
디스크 정리는 “많이 지우기”가 아니라 “다시 만들 수 있는 것만 정확히 지우기”입니다. Codex에게도 같은 원칙을 전달하세요. 먼저 측정하고, 삭제 후보를 설명하고, 경로를 검증하고, 잠긴 파일은 건너뛰고, 마지막에 수치로 확인하는 흐름이면 자동화의 속도와 사람의 안전 판단을 함께 가져갈 수 있습니다.
자주 묻는 질문
Q1. Gradle 캐시를 지우면 프로젝트가 망가지나요?+
소스 코드와 프로젝트 설정은 지워지지 않습니다. 다만 다음 빌드에서 필요한 Gradle 배포 파일과 의존성을 다시 내려받을 수 있어 첫 빌드가 느려집니다. 오프라인 환경이라면 필요한 캐시를 유지하세요.
Q2. npm 캐시는 항상 지워도 되나요?+
npm 캐시는 재생성할 수 있지만 평소에는 npm cache verify가 더 적절할 수 있습니다. 디스크 공간을 즉시 확보해야 할 때 전체 정리를 고려하고, 이후 설치 시 네트워크 사용량이 증가할 수 있음을 기억하세요.
Q3. pagefile.sys가 큰데 삭제하면 안 되나요?+
임의 삭제하지 마세요. Windows 가상 메모리와 관련된 시스템 파일입니다. 크기 조정이 필요하다면 시스템 설정과 공식 문서를 확인하고, 메모리 용량과 사용 패턴을 고려해 별도 작업으로 진행해야 합니다.
Q4. 임시 폴더가 완전히 비워지지 않는 이유는 무엇인가요?+
실행 중인 프로그램이나 Windows 서비스가 파일을 사용 중일 수 있습니다. 강제 종료하거나 권한을 우회하기보다 해당 파일을 건너뛰고 재부팅 후 Windows 저장소 센스나 디스크 정리를 사용하는 편이 안전합니다.
Q5. 12.76GB면 충분한가요?+
긴급 상황은 벗어났지만 전체 용량의 4.7%라 넉넉하지 않습니다. 대형 개인 파일을 여유 있는 D 드라이브로 옮기고, 사용하지 않는 앱과 오래된 개발 SDK를 검토하며, 저장소 센스를 설정하는 후속 관리가 필요합니다.
공식 출처
'AI > Codex' 카테고리의 다른 글
| Codex Micro 드디어 출시, 230달러짜리 Codex 전용 키보드는 35만원의 값어치를 할까 (0) | 2026.07.16 |
|---|---|
| Codex 5시간 제한이 사라졌다, 하지만 주간 한도는 남아 있다 (0) | 2026.07.14 |
| Codex Gmail MCP로 메일 자동 관리하기 (0) | 2026.07.05 |
| Codex 가이드 (3): manage-your-inbox 기능으로 메일을 자동으로 관리하세요 (0) | 2026.07.05 |
| Codex 가이드 (2): csv, excel, google sheet 이젠 Codex한테 맡기자 (0) | 2026.07.05 |
