모니프렌 Windows 작업 중 저장공간 부족으로 개발이 막혔습니다. 작업 폴더의 수를 관리하면 어느 정도 예방할 수 있을 것 같았지만, 실제로 살펴보니 폴더 개수만으로 설명되지 않는 부분이 있었습니다. 소스 옆에는 빌드 결과가 생겼고, 패키징 과정에서는 복사본이 만들어졌으며, 검증에 사용한 자산도 남을 수 있었습니다. 이번 기록은 그 누적 구조를 살펴보고, 무엇을 제한하고 무엇을 보존해야 할지 정리한 과정입니다.
작업 개수뿐 아니라 생성 중 최대 공간과 남겨둘 용량도 제한하기
작업 하나가 남기는 것은 하나가 아니었습니다
작업 폴더 하나를 떠올리면 그 안에서 필요한 파일이 생기고, 작업이 끝나면 함께 정리될 것 같습니다. 그러나 빌드와 패키징, 검증이 서로 다른 장소에 결과를 남긴다면 작업 폴더만 세어서는 전체를 알 수 없습니다. 조사한 범위에서도 소스 외의 산출물이 함께 남을 수 있었고, 일부 보관 제한은 성공한 작업에만 적용되거나 다른 경로의 결과물을 포함하지 않았습니다.
성공했을 때의 정리 규칙만 있으면 실패한 작업의 흔적은 어떻게 되는지도 따로 봐야 합니다. 작업이 중간에 끝나더라도 이미 만들어진 파일은 디스크에 남을 수 있습니다. 다음 작업이 새 결과를 만드는 동안 이전 실패의 결과가 함께 존재한다면, 실행 중인 작업 수가 적어도 공간은 계속 줄어들 수 있습니다.
이 문제를 살펴볼 때 필요한 목록은 작업 이름만이 아닙니다. 어떤 단계에서 무엇이 만들어지고, 다음 단계가 그것을 쓰는지, 언제 보관 대상이 되는지를 함께 알아야 합니다. 그래야 작업 종료와 파일 수명 종료가 어긋나는 지점을 찾을 수 있습니다.
폴더 수와 실제 사용량을 나누어 보기
작업 폴더의 개수, 파일 목록에서 보이는 논리 크기, 실제 디스크가 사용하는 공간은 서로 다를 수 있습니다. 여러 경로가 같은 파일 데이터를 공유하는 경우도 있고, 패키징 도중에는 원래 결과와 새 묶음이 동시에 존재할 수도 있습니다. 눈에 보이는 폴더 크기를 단순히 더하거나, 하나를 지우면 그만큼의 공간이 돌아올 것이라고 기대하기 어려운 이유입니다.
최종 결과물의 크기만 확인하는 것도 충분하지 않습니다. 가령 패키지를 만드는 동안 원본과 새 묶음이 함께 필요한 상황을 가정해볼 수 있습니다. 작업이 끝나면 둘 중 일부를 정리하더라도, 만드는 순간에는 더 넓은 공간이 필요합니다. 완료 후에 남는 양과 진행 중 가장 많이 사용하는 양을 나누어 생각해야 합니다.
그래서 공간 문제를 확인할 때는 생성 전, 무거운 단계가 겹치는 동안, 종료 후를 구분하는 편이 좋습니다. 완료 시점의 작은 결과물만 보고 다음 작업도 안전하다고 판단하면 중간 과정의 사용량을 놓칠 수 있습니다. 제한 기준이 어느 시점의 공간을 다루는지부터 분명해야 합니다.
정리보다 먼저 보존 기준을 세우기
공간이 부족하면 큰 파일부터 지우고 싶어집니다. 하지만 크기와 삭제해도 되는지는 다른 질문입니다. 소스, 수정 중인 작업, 유일하게 남은 출시 패키지는 다시 만들 수 있는 임시 결과와 구분해 보존해야 합니다. 오래됐다는 이유만으로 지우는 방식은 현재 사용 여부나 복구 가능성을 설명해주지 못합니다.
재생성 가능하다는 말도 확인이 필요합니다. 필요한 입력과 작업 조건이 남아 있는지, 현재 누군가 사용 중인 결과인지에 따라 정리 판단이 달라집니다. 파일을 만든 작업과 그 파일을 쓰는 단계가 연결되어 있어야, 실패한 작업의 임시 결과도 안전하게 골라낼 수 있습니다. 소유한 작업을 모르는 파일은 삭제 규칙을 적용하기 전에 한 번 더 확인할 대상입니다.
정리의 목적은 단순히 오래된 흔적을 없애는 데 있지 않습니다. 다시 쓸 가치가 있는 결과는 남기면서, 재생성 가능한 결과가 다음 작업을 막지 않도록 하는 것입니다. 보존 이유를 설명할 수 있어야 정리 규칙도 반복해서 적용할 수 있습니다.
개수와 용량, 겹치는 시간을 함께 제한하기
검토하는 방향은 무거운 빌드 구간의 동시 실행 제한, 시작 전 공간 예약, 완료본의 개수와 총용량 제한을 함께 두는 것입니다. 이 기준들은 서로 다른 문제를 다룹니다. 동시 실행 제한은 여러 작업이 한꺼번에 만드는 양을 줄이고, 공간 예약은 시작하기 전에 필요한 여유가 있는지 확인하며, 보관 제한은 끝난 결과가 계속 쌓이는 것을 다룹니다.
완료본을 몇 개만 남겨도 결과 하나가 커지면 전체 용량은 늘어날 수 있습니다. 반대로 총용량만 제한하면 아직 검토가 필요한 최근 결과가 먼저 정리될 수 있습니다. 어떤 결과를 남길지와 얼마까지 남길지를 함께 정해야 하는 이유입니다. 각 제한이 충돌할 때 무엇을 보존할지도 기준에 포함되어야 합니다.
공간이 부족한 상황에서 무리하게 시작했다가 실패하는 것보다, 시작을 보류하고 이유를 알려주는 흐름을 검토할 수 있습니다. 다만 이런 설계가 실제로 작동하는지는 별도 확인이 필요합니다. 제한을 설명하는 문서나 스크립트가 생겼다는 사실만으로 재발 방지가 입증되지는 않습니다.
다음에는 무엇을 확인해야 할까
정리 전후 실제 여유 공간이 어떻게 달라졌는지, 여러 작업이 겹칠 때 제한이 적용되는지, 중간 실패 뒤에도 임시 결과를 식별할 수 있는지 확인해야 합니다. 공간이 충분한 정상 상황만 통과해서는 부족합니다. 부족할 때 안전하게 멈추고, 보존할 결과를 건드리지 않는지도 검증할 범위입니다.
이번에 남긴 기준은 작업의 수를 넘어 결과물이 만들어지고 남는 과정을 함께 보자는 것입니다. 아직 전체 적용이나 재발 방지 검증이 끝났다고 말할 단계는 아닙니다. 확인한 누적 구조를 바탕으로 생성 중 사용량과 종료 후 보관량을 나누어 관리하는 방향을 잡았습니다.
