처음엔 금방 끝날 줄 알았는데, 디스크 정리는 늘 옆길로 샌다

갑자기 저장공간이 사라진 날부터 시작됐다

노트북이 갑자기 느려진 건 아니었는데, 뭔가 저장할 때마다 공간이 부족하다는 경고가 뜨기 시작했다. 처음엔 그냥 다운로드 폴더나 바탕화면 쪽이 지저분해졌겠거니 했는데, 막상 들어가 보면 생각보다 큰 파일이 안 보였다.

이럴 때 보통 윈도우 기본 저장소 관리부터 보게 되는데, 그게 대략적인 분류는 보여줘도 결국 어디 폴더가 문제인지 따라가려면 한 번 더 손이 간다. 예전에 이걸로 몇 번 찾다가 중간에 짜증 나서 포기한 적이 있어서, 이번에는 아예 TreeSize Free를 먼저 켰다.

처음 이걸 선택한 이유는 단순했다. 탐색기처럼 보여서 덜 낯설고, 폴더 크기가 바로 눈에 들어온다. 이런 류의 프로그램이 몇 개 더 있긴 한데, 너무 시각화 위주거나 반대로 너무 기술자용처럼 보이는 건 손이 잘 안 갔다. TreeSize는 딱 중간쯤 느낌이었다.

처음 스캔했을 때 생각보다 헷갈렸던 부분

처음 실행하고 C 드라이브를 스캔했는데, 예상처럼 사용자 폴더가 제일 클 줄 알았다. 그런데 상단 쪽에 보이는 큰 항목들이 내가 평소에 직접 만지는 폴더 이름이 아니라서 순간 좀 멈췄다. ProgramData, Windows, AppData 같은 것들이 눈에 띄는데, 여기서 바로 뭘 지우면 안 된다는 건 알겠는데 또 그렇다고 그냥 닫기도 애매했다.

여기서 첫 번째로 막혔다. 뭘 하려고 했냐면, 단순히 큰 폴더를 찾아서 정리하고 싶었던 건데, 막상 큰 폴더가 시스템 쪽에 몰려 있으니까 손댈 수 있는 영역과 아닌 영역을 먼저 구분해야 했다. 처음엔 크기 순으로만 보면 되겠지 싶었는데, 실제로는 “지워도 되는 것”과 “큰데 건드리면 안 되는 것”이 섞여 있어서 생각보다 단순하지 않았다.

그래서 여기서는 바로 삭제로 가지 않고, 사용자 폴더 아래만 다시 좁혀서 보기 시작했다. TreeSize에서 좋은 점이 이런 식으로 들어가면서 볼 수 있다는 거였다. 그라데이션 바도 은근 도움이 됐다. 숫자만 보면 감이 안 오는데, 유독 길게 칠해진 폴더가 있으면 눈이 먼저 간다.

비슷한 도구 중에 WinDirStat처럼 블록으로 보여주는 방식도 예전에 써봤는데, 큰 파일 찾기에는 확실히 직관적이어도 폴더 구조를 따라가면서 정리할 때는 나는 TreeSize 쪽이 더 편했다. 반대로 파일 하나하나의 덩어리를 시각적으로 빨리 보고 싶으면 다른 방식이 더 잘 맞을 사람도 있을 것 같다.

AppData에서 한 번 막히고, 괜히 자신 있게 들어갔다가 돌아나왔다

결국 용량이 많이 잡아먹는 쪽은 AppData 아래였다. 이건 사실 어느 정도 예상은 했는데, 문제는 여기부터였다. 캐시인지 설정 파일인지, 프로그램이 잠깐 쓰고 남긴 건지 구분이 안 가는 폴더가 많았다. 이름만 보고 지워도 되는 줄 알았다가 나중에 프로그램 꼬이면 더 귀찮아진다.

여기서 두 번째 시행착오가 나왔다. 처음에는 “어차피 캐시겠지” 하고 큰 폴더 몇 개를 탐색기에서 바로 열어봤는데, 일부는 접근 권한이나 사용 중 문제로 바로 정리가 안 됐다. 당장 공간만 확보하고 싶었던 입장에서는 여기서 좀 맥이 빠졌다.

그래서 방향을 바꿨다. TreeSize에서 파일 유형이랑 마지막 수정 날짜 쪽을 같이 보기 시작했다. 이게 막 엄청 정교한 분석은 아니어도, 최근에 계속 불어난 로그나 임시 파일을 찾는 데는 꽤 도움 됐다. 특히 오래된 설치 파일이나 압축 풀어놓고 잊어버린 잔재는 날짜랑 크기를 같이 보면 금방 걸린다.

짧은 팁 하나만 말하면, AppData는 Local, Roaming, LocalLow 성격이 좀 다르니까 무조건 큰 것부터 지우는 건 위험하다. 나는 Local 쪽 임시 파일부터 보고, 프로그램 이름이 명확한 캐시 폴더 위주로 손댔다. 반대로 Roaming은 설정이 섞여 있는 경우가 많아서 좀 더 조심했다.

다운로드 폴더보다 더 컸던 건 의외로 작업 중간 산출물이었다

사실 제일 많이 나올 줄 알았던 건 다운로드 폴더였다. 설치 파일, 압축 파일, 예전 문서 이런 게 몰려 있으니까 보통 여기서 끝나는 경우가 많다. 그런데 이번에는 다운로드보다 작업용 폴더 안의 중간 산출물이 더 컸다.

영상 편집은 안 해도 캡처 파일, 변환 파일, 테스트용 백업본 같은 게 쌓여 있었다. 특히 같은 파일을 이름만 바꿔 여러 버전으로 보관한 경우가 많았는데, 탐색기에서는 이게 그렇게까지 크게 안 느껴진다. TreeSize로 보니까 특정 프로젝트 폴더 하나가 유독 길게 표시돼서 바로 걸렸다.

여기서는 선택을 좀 잘못했다. 처음에는 폴더째로 정리하면 되겠지 하고 큰 폴더를 통으로 백업해 다른 드라이브로 옮겼는데, 옮기고 나서 보니 실제로 자주 쓰는 파일도 같이 들어 있었다. 결국 다시 일부를 원래 자리로 가져왔다.

즉, 세 번째 시행착오는 기능 문제가 아니라 선택을 잘못한 경우였다. 뭘 하려고 했냐면 공간을 빨리 비우고 싶어서 큰 폴더를 한 번에 치우려 했는데, 막상 작업 흐름에 필요한 파일까지 같이 빠져버리니까 오히려 한 바퀴 더 돌게 됐다. 그 뒤로는 무조건 폴더 단위보다 파일 확장자나 수정 날짜 기준으로 한 번 더 걸렀다.

실무에서 이게 은근 중요하다. 특히 결과물보다 중간 생성물 용량이 더 큰 작업은, 용량 정리 기준을 “오래된 것” 하나로 잡으면 사고 난다. 최근 프로젝트라도 다시 쓸 일이 없는 캐시가 있고, 오래됐어도 계속 참조하는 원본이 있기 때문이다.

안 지워지는 파일 때문에 한참 돌아갔던 구간

한 번은 엄청 큰 로그 파일 비슷한 걸 찾았는데, 지우려고 하니까 사용 중이라고 나왔다. 처음엔 TreeSize에서 바로 안 되는 건가 싶었는데, 알고 보니 해당 파일을 어떤 프로그램이 계속 잡고 있었다. 여기서 괜히 재부팅 먼저 할까, 그냥 놔둘까 잠깐 고민했다.

이때 문제를 푼 과정이 좀 기억에 남는다. 왜 안 되는지 보려고 파일 경로를 확인하고, 최근에 켜둔 프로그램을 하나씩 닫아봤다. 그래도 그대로라서 작업 관리자에서 백그라운드 프로세스를 정리해봤는데, 그제야 삭제가 됐다. 나중에 보니 동기화 프로그램이랑 로그 수집 성격의 툴이 파일을 붙잡고 있던 거였다.

그 후부터는 용량 큰 파일이 보여도 바로 지우기보다, 먼저 경로랑 확장자를 보고 대충 어떤 프로그램이 만든 건지 추정하는 습관이 생겼다. 이건 TreeSize 자체 기능이라기보다 이런 도구를 쓰면서 같이 배우게 되는 부분이었다.

비슷한 상황이면 안전하게는 프로그램 내부 정리 기능을 먼저 보는 게 낫다. 예를 들어 브라우저 캐시나 메신저 첨부파일 캐시 같은 건 앱 안에서 비우는 쪽이 덜 꼬인다. 다만 그런 메뉴가 숨겨져 있거나, 정리해도 체감이 별로 없는 경우가 있어서 결국 TreeSize로 확인하는 과정이 필요하긴 하다.

네트워크 드라이브와 클라우드 동기화 폴더는 기대와 조금 달랐다

설명만 보면 네트워크 드라이브나 클라우드에 동기화된 로컬 저장소도 볼 수 있어서, 이것도 한 번에 정리하면 좋겠다고 생각했다. 실제로 원드라이브 동기화 폴더 쪽을 봤는데, 여기서는 조금 애매했다.

로컬에 내려받은 파일과 온라인 전용처럼 동작하는 파일이 섞여 있으면 체감 용량하고 표시가 딱 맞아떨어지지 않는 느낌이 있었다. 물론 구조를 보는 데는 도움이 됐지만, “이걸 지우면 바로 얼마가 비나” 같은 감각은 일반 로컬 폴더보다 덜 명확했다.

네트워크 드라이브도 비슷했다. 스캔 자체는 되는데, 연결 상태나 권한, 응답 속도에 따라 답답할 때가 있었다. 그래서 이건 회사 공용 폴더 전체를 분석하는 용도보다는, 내가 접근 가능한 범위 안에서 대략 어디가 큰지만 보는 정도로 쓰는 게 낫겠다고 생각했다.

다른 방법으로는 서버 쪽 저장소 분석 도구나 클라우드 서비스 자체 대시보드를 보는 게 더 정확할 때도 있다. TreeSize 하나로 다 해결하려고 하면 오히려 애매해지는 구간이 있다. 이 부분은 기대를 조금 낮추고 쓰는 편이 편했다.

결국 남긴 기준은 몇 가지 안 됐다

한참 돌고 나서 남은 건 의외로 간단했다. 첫째, 시스템 폴더가 크다고 바로 건드리지 말 것. 둘째, 사용자 폴더 아래에서도 AppData는 이름만 보고 지우지 말 것. 셋째, 프로젝트 폴더는 폴더째 이동하기 전에 중간 산출물부터 따로 볼 것.

그리고 TreeSize에서 개인적으로 제일 자주 본 건 결국 크기, 파일 개수, 수정 날짜였다. 소유자나 점유 디스크 공간 같은 정보도 필요할 때는 유용한데, 일상적인 정리에서는 너무 많은 정보를 한 번에 보면 오히려 판단이 느려졌다. 처음엔 이것저것 다 보다가, 나중에는 필요한 열만 놓고 보는 쪽이 빨랐다.

이 프로그램이 좋았던 건 “어디가 큰지”를 빠르게 보여준다는 점이고, 아쉬운 건 거기서부터는 결국 사용자가 판단해야 하는 영역이 꽤 많다는 점이었다. 그런데 생각해보면 그게 당연하기도 하다. 저장공간 문제는 단순히 큰 파일 찾기보다, 그 파일이 지금도 필요한지 아닌지 결정하는 쪽이 더 어렵다.

지금은 정리보다 확인용으로 더 자주 켠다

처음엔 디스크 비우려고 깔았는데, 지금은 뭔가 이상하게 공간이 줄어든 느낌이 들 때 확인용으로 더 자주 켠다. 예를 들어 어떤 프로그램 업데이트 후에 갑자기 용량이 늘었다 싶으면, TreeSize로 해당 폴더만 한번 훑어본다. 이게 은근 쓸모 있다.

정리도 정리지만, 원인 파악이 빨라진 게 더 컸다. 예전에는 저장공간 줄면 막연하게 “뭐가 쌓였나 보다” 하고 넘어갔는데, 이제는 적어도 어느 축에서 불어났는지는 금방 보인다. 캐시인지, 로그인지, 다운로드인지, 작업 산출물인지 대충 방향이 잡히니까 괜히 이것저것 다 뒤질 일이 줄었다.

물론 아직도 애매한 부분은 남아 있다. 특히 시스템이 잡고 있는 공간, 복원 지점, 숨은 캐시, 클라우드 동기화 영역 같은 건 여전히 한 번에 명쾌하게 떨어지지 않는다. 그래서 TreeSize만 믿고 끝내기보다는 윈도우 저장소 관리나 디스크 정리, 앱 자체 정리 메뉴랑 같이 보는 편이 더 낫다.

그래도 적어도 “내 저장공간이 어디로 갔는지” 찾는 첫 단계로는 꽤 괜찮았다. 나는 이번에 이걸로 급한 불은 껐는데, 아마 다른 방식이 더 잘 맞는 사람도 있을 것 같다. 비슷하게 써본 사람 있으면 어떤 기준으로 정리하는지 좀 궁금하다.