#정리 후보에 QA 폴더가 있었다
Ubuntu 디스크를 살피며 빌드 캐시와 이미지, 패키지 캐시, 오래된 QA 폴더를 정리 후보로 모았다. 크기만 보면 지울 순서를 정하기 쉬워 보였다. 하지만 임시 작업용 이름이 붙은 폴더에서도 서버가 계속 돌고 있었다.
앞서 Mac과 Ubuntu를 나눠 쓰는 방식을 정리했다. 계속 실행되는 작업을 Ubuntu에 두다 보니, 로컬에서 작업이 끝난 것처럼 보여도 그 실행본이 남아 있을 수 있었다. 디스크 목록과 실행 목록을 함께 봐야 했다.
#표시된 용량을 그대로 더하지 않았다
도구가 보여 준 회수 가능 용량과 정리 후 실제 확보량은 달랐다. Docker 이미지의 공유 레이어를 각 이미지 크기마다 더하면 같은 공간을 여러 번 셀 수 있다. 빌드 캐시, 컨테이너가 참조하지 않는 이미지, 패키지 캐시를 구분해서 적었다.
백업 준비본과 보안 패치 이전 컨테이너는 용량이 크다는 이유만으로 삭제 대상으로 확정하지 않았다. 복구용으로 남겨야 하는지 확인이 먼저였다. VS Code 서버도 현재 사용하는 버전을 남기고 구버전만 후보로 삼았다.
Docker에서는 이미지의 전체 크기와 그 이미지에만 속한 크기를 구분해야 했다. 여러 이미지가 같은 레이어를 참조하면 이미지 하나를 없애도 그 레이어는 남는다. 빌드 캐시도 실행 중인 컨테이너와 다른 종류의 데이터다. RECLAIMABLE 표시를 폴더 용량과 합산해 그대로 확보 예상치로 삼지 않았다. Docker의 디스크 사용량 문서
다음은 이 구분에 사용할 수 있는 읽기 전용 조회 예시다. 당시 실행 로그를 복원한 명령 목록은 아니다.
docker system df -v
docker ps --format '{{.ID}} {{.Names}} {{.Status}}'
git worktree list --porcelain
첫 명령으로 공유·고유 이미지 용량과 캐시를 보고, 두 번째로 실행 중인 컨테이너를 나눠 본다. 마지막 명령은 Git이 등록해 둔 작업 디렉터리를 확인한다. 이것만으로 일반 Node 서버의 작업 경로나 백업 보존 필요성까지 알 수는 없으므로 프로세스와 복구 참조도 별도로 확인해야 한다.
후보를 찾는 조회와 실제 삭제는 별도 단계였다. 아직 사용 여부를 확인하지 못한 폴더까지 정리 완료 목록에 넣지 않았다.
#남겨 둔 폴더 두 개
추가 정리 직전 QA 폴더 두 개에서 서버 8개가 실행 중인 것을 확인했다. 폴더를 지우려면 서버를 멈출 범위부터 정해야 했다. 그 두 폴더는 보류하고, 현재 사용 참조가 없는 것으로 확인한 다른 항목을 먼저 정리했다.
기록상 삭제한 대상은 구버전 VS Code 서버 6개, QA 폴더 하나, Android 빌드 폴더와 Git worktree 등록, 백업 준비본이었다. 이 선택 정리로 약 66GiB를 추가 확보했다. 당시 Docker 컨테이너 81개는 재시작 없이 유지됐다.
‘임시 폴더’라는 이름보다 그 안에서 실행 중인 작업이 더 중요한 기준이었다. 정리를 끝내기 위해 다른 서비스까지 멈추지는 않았다.
#확보한 공간과 확인하지 않은 것
66GiB는 그 작업에서 추가로 확보했다고 보고한 용량이다. 지금 남아 있는 공간을 뜻하지 않는다. 컨테이너를 재시작하지 않았다는 확인도 각 서비스의 기능 테스트를 통과했다는 뜻은 아니다. 당시에는 서비스별 기능 검증을 생략했다.
이번 초안에서는 대화의 삭제 명령과 완료 보고를 다시 확인했다. 상세 임시 로그의 경로는 찾았지만, 현재 로컬에서 파일을 다시 읽지는 못했다. 개별 파일의 삭제 전후 상태를 더 자세히 다루려면 원래 증빙을 확보해야 한다.
남겨 둔 QA 폴더를 이후에 정리했는지도 이 글의 확인 범위 밖이다. 글을 쓰기 위해 남은 서버를 멈추거나 정리를 재실행하지 않았다.
다음에 디스크를 정리할 때도 먼저 볼 것은 폴더 크기만은 아닐 것 같다. 어느 실행본이 그 경로를 쓰는지, 없앤 뒤 무엇으로 복구할지까지 확인한 항목부터 지우려고 한다.