D 드라이브의 여유 공간 3.26 GiB에서 27.15 GiB로: AI와 단발 빌드 저장 위치를 결정하다
요약
개발 환경에서 AI 에이전트와 개발 캐시, 빌드 결과물 등의 용도를 체계적으로 분류하고 정리하는 과정을 기록한 글입니다. 단순히 공간 확보를 넘어, 데이터의 사용 목적과 중요도에 따라 보존 및 폐기 기준을 세우는 것이 핵심 내용입니다.
핵심 포인트
- AI 에이전트와 개발 캐시 등 출력물의 용도 구분이 필요합니다.
- 단순히 파일 크기가 아닌, 데이터의 논리적 사용처를 파악해야 합니다.
- 임시 파일 이름만으로 삭제 여부를 결정해서는 안 됩니다.
- 중요한 완성물이나 후보작은 반드시 보존하고 확인해야 합니다.

Windows 개발용 D 드라이브에 남아 있던 여유 공간은 3.26 GiB였습니다. AI 에이전트와 개발 캐시 및 출력물의 용도를 조사하고, Rust의 단발 빌드와 완성물을 보관할 장소를 결정하면서 디스크 용량을 정리한 기록입니다.
기존 청소 도구를 사용하자 여유 공간은 25.97 GiB까지 돌아왔습니다. 이후 완성물 일부를 외부로 보관하고, 미사용 빌드 중간물도 정리하여 27.15 GiB가 되었습니다.
이번에 생각한 것은 다음 작업을 마친 후에 무엇을 남길 것인가입니다. 다시 만들 수 있는 중간물, 사용할 완성물, 판단 자료로 남겨둘 출력을 구분하고, 확인할 수 있는 범위만 치웠습니다. 모든 수치는 이번 개인 환경에서 실측한 것입니다.

여유 공간은 3.26 → 25.97 → 27.15 GiB로 변화했습니다. 소스나 용도가 확정되지 않은 데이터는 남겨두고, 확인된 완성물은 보관하며, 작업이 끝난 전용 중간물을 치우는 방침을 세웠습니다.
처음에는 기존의 청소 도구를 사용하여 Rust의 target 폴더 5곳, Go의 빌드/종속성 캐시, pnpm의 참조되지 않은 패키지를 정리했습니다. 이 단계에서의 증가량은 약 22.71 GiB입니다.
이어지는 부분 이전 및 정리를 통해 늘어난 것은 약 1.18 GiB였습니다. 처음부터의 총 증가는 약 23.89 GiB입니다. 후반 작업만으로 23.89 GiB가 증가한 것은 아닙니다.
드라이브 여유 공간은 GiB로 기록했습니다. 개별 완성 파일은 bytes 단위로도 확인했지만, 파일의 논리적 크기와 드라이브에서 실제로 늘어난 여유 공간은 구분하여 다루었습니다. 나중에 설명할 17개의 영상 크기를 그대로 약 1.18 GiB의 회수량으로 설명할 수는 없습니다.
여유 공간이 돌아왔다고 해도, 용도가 불분명한 출력물을 지워도 괜찮은지는 별도의 확인이 필요합니다. 그래서 다음으로는 단순히 크기만 보고 고르지 않고, 남아있는 것들의 사용처를 조사했습니다.
약 20.55 GiB의 로컬 데이터에는 공개 후보작이나 접수 증적이 많이 포함되어 있었습니다. 용도를 확정할 수 없는 출력물도 있었기 때문에 이 데이터는 보존했습니다.
tmp나 임시 출력을 연상시키는 이름이라도, 그것만으로는 삭제 대상이 될 수 없습니다. 완성물을 확인할 자료나 채택될 후보가 들어 있다면, 공간을 확보하기 전에 사용처를 확인해야 합니다. 이번에는 용도를 확인한 완성 영상과 미사용으로 확인된 Rust의 target 폴더를 다음 정리 대상으로 삼았습니다.
동기화 폴더, 앱 본체, 기존 hook, 채택된 후보는 변경하지 않았습니다. 소스도 남겨두었습니다. 여유 공간이 크게 늘어날 것 같아도 현재 사용 중인 데이터를 한꺼번에 삭제하는 방법은 취하지 않았습니다.
여기서 남은 약 20.55 GiB는 이번에 추가로 회수된 용량에는 포함하지 않았습니다. 용도를 확정할 때까지 보존한다는 판단 역시 배치(配置)를 결정하는 작업의 일부였습니다.
보관 장소로는 원격 데스크톱을 통해 볼 수 있는 일반 디렉토리를 사용했습니다. 시작 시 이용 가능 용량은 약 217.48 GiB입니다. 다만, 용량과 존재만 확인했을 뿐이므로 완성물의 보관 장소로 사용할 수 있을지는 알 수 없습니다.
먼저 선행하는 1편을 복사하고 이미지로 육안 검사를 했습니다. 그 후, 용도를 확인한 완성 영상 17개, 총 37,911,314 bytes에 대해, 복사지로부터 읽어오기 및 사용, 복원(復元)을 확인했습니다.
확인된 내용은 다음과 같습니다:
- 전체 17편 모두 원본 파일・외부 사본・복원용 사본의 SHA256 값이 일치함
- 외부로 보관한 전 17편 모두 ffmpeg를 통한 전편 디코딩에 성공함
- 선행하는 1편은 이미지로 육안 검사 완료
SHA256 대조 외에도, 외부 파일 사용 확인을 추가했습니다. 다만, 전 17편을 사람이 전 편을 육안으로 본다는 의미는 아닙니다. 육안 검사한 범위와 기계적으로 디코딩을 확인한 범위는 구분합니다.
복사지와 일치하는지 여부만으로는 보관되었는지 확인하는 수준입니다. 복원용 사본까지 대조 대상에 포함함으로써, 되돌리는 작업까지 포함하여 확인했습니다. 원본을 정리하기 전에 이 확인 과정을 한 세트로 완료하는 순서로 진행했습니다.
이 확인을 마친 후, 원본 파일과 복원용 사본을 정리하고 외부의 17편을 보관했습니다. 소스, 로그, 폰트는 남겨두었습니다. 먼저 원본을 지워 여유 공간을 만든 다음, 나중에 복사된 상태를 조사하는 순서는 취하지 않았습니다.
이번에 확인한 것은 이 경로로 쓰기(書き込み), 읽어오기, 완성물의 사용, 복원이 가능했다는 것입니다. 연결 끊김/재연결 테스트까지는 실시하지 않았습니다.
다음으로 필요했던 Rust 기반 CLI를 1건 복원했습니다. 완성물을 외부로 보관할 수 있다면, 빌드 중간물도 처음부터 외부에서 만들 수 있는지 시험해 보았습니다.
외부로의 직접적인 cargo build는 temp-archive를 삭제하는 단계에서 Windows error 87이 발생하며 실패했습니다. 정확한 원인은 확정되지 않았습니다. 이 한 건만으로 모든 네트워크 환경에서 Cargo가 사용 불가능하다고 판단할 수는 없습니다.
그래서 같은 소스를 사용하여 D 드라이브 상의 작업 전용 임시 target로 전환하자, 15.38초 만에 빌드에 성공했습니다.

이번 경로에서는 외부로의 직접 빌드가 실패했고, D 드라이브 상의 전용 target에서는 성공했습니다. 이 결과를 바탕으로, 빌드는 D에서 진행하고 필요한 완성물만 외부로 복사하는 방식으로 배치했습니다.
동영상 보관 및 읽어오기가 성공한 것으로 미루어 볼 때, 같은 장소에서 빌드까지 완료한다고는 할 수 없었습니다. 이번 시도에서는 완성물을 보관하는 용도와 생성 중인 파일을 다루는 용도를 개별적으로 확인하게 되었습니다. 실패 원인을 추측으로 결정하지 않고, 성공을 확인할 수 있었던 D 측에서 생성하는 절차를 채택하고 있습니다.
완성된 exe 파일은 6,815,232 bytes였습니다. 외부로 보관함과 동시에 D 드라이브에도 평소 사용용으로 작은 사본을 남겼습니다. 양쪽의 SHA256이 일치했으며, 어느 쪽에서든 version 실행에 성공했습니다.
나아가 격리된 합성 Git fixture를 사용하여 검출 케이스와 허가 케이스를 테스트하고, 기대하는 종료 값과 건수에 일치함을 확인했습니다. 이는 준비된 합성 케이스에서의 확인입니다. 실제 프로젝트의 본 번 이용을 한 번에 검증한 결과와는 분리하여 다룹니다.
이 합성 검사의 소요 시간은 D에서는 약 0.1초, 외부에서는 약 2초였습니다. 단발적인 측정이라 일반적인 속도 비율을 단정하기는 어렵습니다. 이번 배치는 D에도 약 6.5 MiB의 exe를 남겨 평소 사용 가능한 형태로 만들었습니다.
빌드 후에는 로컬과 외부의 중간물을 공식 cargo clean으로 정리하여 대상이 사라진 것을 확인했습니다. 별도로 미사용 Rust target을 한 곳 정리할 때도, 소스와 추적되지 않은 변경 사항은 유지하고 있습니다.
Cargo의 공식 사양에 따르면, cargo clean은 Cargo가 생성한 target 내의 결과물을 삭제하며, --target-dir로 생성물 디렉토리를 지정할 수 있습니다. 옵션이 없을 경우 target 전체가 대상이 되므로, 전용 target 범위를 명확히 하여 다룹니다. [Cargo clean 공식 사양]
향후 배치는 D에서 작업 단위의 빌드를 진행하고, 필요한 완성물만 외부로 보관하는 형태로 했습니다. 동작 확인 후에 중간물을 정리하고, 소스와 평소 사용하는 작은 exe는 D에 남깁니다.

완성물의 복사 후 대조/이용/복원을 확인하고, 확인된 후에야 중간물 정리를 진행합니다. 확인이 완료되지 않은 경우에는 원본 데이터를 남겨 두고 확인을 계속하는 흐름입니다.
이 배치를 다루기 위해 배치 장부와 수동 Inspect/Clean 도구를 준비했습니다. finished가 된 작업의 전용 Cargo target을 ID로 지정하고, 먼저 dry-run으로 대상을 확인한 후 Apply로 진행합니다.
잘못된 범위를 정리하지 않도록 다음 경우에는 거부하도록 했습니다.
- source와 target의 범위가 겹치는 경우
- 공유 디렉토리를 대상으로 하는 경우
- 링크나 실행 중인 프로세스가 있는 경우
- 소유 마커가 일치하지 않는 경우
작업 단위의 전용 target이라면, 끝난 작업의 중간물로서 범위를 지정할 수 있습니다. 반면, 공유 디렉토리까지 대상을 삼으면 그 작업 외의 것을 휘말릴 우려가 있습니다. ID를 지정할 수 있다는 점에 더하여, 지정된 곳이 정말 해당 작업 전용인지도 막는 조건에 포함했습니다.
완성물 보관 영역을 삭제하는 기능은 없습니다. 검토일 또한 사람이 확인하는 참고 기준입니다. 날짜가 지나면 자동으로 사라지는 기한으로 설정하지 않았습니다.
다만, 도구를 준비했다고 해서 안전성 확인이 끝난 것은 아닙니다. 작업을 담당한 사람의 성공 보고와 별개로, 부모(상위 시스템)가 독립적으로 검토했을 때, 공유 폴더를 잘못 등록했을 경우의 청소 범위에 구멍이 발견되어 수정했습니다.
자녀의 보고만으로 합격 처리하지 않고, 등록을 잘못했을 경우 어디까지 건드릴 수 있을지까지 재검토한 점은 이번 도구 제작에서 남기고 싶은 부분입니다.
이번에 결정된 배치와 청소는 수동 운영입니다. 정기 체크나 알림, 모든 AI가 사용하는 공통 규칙으로의 통합은 미설정입니다. 평소 사용하는 모든 앱의 구동 시험도 아직 실시하지 않았습니다.
공간이 27.15 GiB가 된 것과, 앞으로 계속 방치하여 용량을 유지할 수 있는 것은 별개입니다. 완성물의 보관 및 이용을 확인한 범위, 합성 케이스로 CLI를 검사한 범위, 아직 시도하지 않은 범위를 남겨 다음 작업에 사용합니다.
보존된 소스나 변경 사항이 있다는 것이 모든 앱의 구동을 확인했다는 것은 아닙니다. 미실시 시험은 미실시 상태로 남겨두고, 이번 확인 결과로부터 말할 수 있는 범위를 지나치게 넓히지 않도록 하고 있습니다.
단발 빌드(one-off build)를 완료한 후, 필요한 결과물을 보관하고 사용 가능 여부를 확인하며 전용 타겟을 정리합니다. 우선은 그 작업이 끝날 때 함께 정리하는 습관부터 들이는 것이 중요합니다.
📎 다이어그램 버전 및 관련 링크가 모여있는 페이지가 있습니다:
※ 헤더 이미지와 인포그래픽 그림은 AI(이미지 생성)로 제작되었습니다.
※ 본문 삽화 역시 AI(이미지 생성)로 제작되었습니다.
작성자: ishizakahiroshi
군마 북부에서 보호묘 2마리와 함께 사는 재택 엔지니어(만물상)
X (업무 위탁/각종 상담은 여기로):
백엔드, 인프라, AI 연계 분야에서 업무 위탁 상담을 받고 있습니다. 풀 리모트 근무가 가능합니다. 스팟 작업이나 주 2~3시간부터도 환영하며, 다양한 프로젝트에 참여할 수 있다면 기쁠 것 같습니다. 다음과 같은 상담도 환영합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기