마지막 수정
로컬 작업 폴더를 자동 정리하기 전에 정한 기준
파일 자동 정리 스크립트를 만들기 전에 폴더 역할, 예외, 되돌리기 기준을 먼저 정해야 하는 이유를 기록했습니다.
이 글에서 다루는 핵심 3가지
2026년 6월 11일, 작업 공간 정리를 하면서 파일을 임시 폴더로 옮겼다가 되돌리지 못할 뻔한 경험이 있었습니다. 그때부터 폴더 정리는 “깨끗하게”가 아니라 “잃어버리지 않기”로 바뀌었습니다.
정리 대상은 코드 플러그인 캐시, Codex 임시 파일, oMLX 캐시, 로그 데이터베이스였습니다. 이들을 삭제하는 대신 /Volumes/OWC_1M2/daejinyoun/Workspace/archive/local-pc-cleanup/20260611-112909/로 옮겼습니다. 이름에 날짜와 시각을 넣은 폴더라, 나중에 필요하면 원래 위치로 되돌릴 수 있었습니다. 실제 작업 폴더는 건드리지 않았습니다.
같은 시기에 다른 저장소를 검토하다가 rm -rf가 포함된 임시 폴더 정리 명령을 만난 적도 있습니다. 실행하지 않고 안전 확인으로 차단했습니다. 삭제 명령이 들어간 자동화는 잘못 돌리면 되돌릴 방법이 없기 때문입니다.
자동 정리 전에 정할 것
파일을 옮기는 스크립트를 만들기 전에 최소한 아래는 정해야 합니다.
정리 대상 폴더
절대 건드리면 안 되는 폴더
파일을 옮길 기준
중복 파일 처리 방식
되돌리기 로그 위치
dry-run 지원 여부특히 src/content/blog처럼 실제 사이트에 반영되는 폴더는 조심해야 합니다. 글 파일 하나가 사라지면 빌드가 깨지거나 URL이 바뀔 수 있습니다.
바로 삭제하지 않는다
자동 정리에서 가장 위험한 동작은 삭제입니다. 처음 버전에서는 삭제보다 이동이 안전합니다.
삭제하지 않는다.
먼저 _review 또는 _archive로 옮긴다.
옮긴 파일 목록을 로그로 남긴다.
같은 이름이 있으면 덮어쓰지 않는다.
빌드 산출물과 원본 파일을 구분한다.예를 들어 Astro 블로그에서는 dist/는 다시 만들 수 있는 산출물이지만, src/content/blog/의 Markdown은 원본입니다. 둘을 같은 기준으로 정리하면 안 됩니다.
dry-run을 먼저 둔다
파일을 실제로 옮기기 전에 dry-run이 필요합니다.
python organize_files.py --dry-run이 모드에서는 실제 이동 없이 아래처럼 출력만 합니다.
MOVE draft-a.md -> blog/Draft/draft-a.md
SKIP local-env-file
SKIP src/content/blog/post.md
ARCHIVE old-screenshot.png -> _archive/old-screenshot.png출력을 보고 이상한 이동이 없을 때만 실제 실행으로 바꿉니다.
블로그 운영 폴더에 적용할 기준
Daejin Lab 기준으로는 아래처럼 나누는 편이 안전합니다.
절대 자동 이동 금지:
- src/content/blog
- src/pages
- src/components
- public/robots.txt
- sitemap 관련 설정
- 로컬 비밀 설정 파일
정리 후보:
- 임시 캡처 이미지
- 사용하지 않는 초안 메모
- 오래된 빌드 로그
- 실험용 출력 파일즉, 사이트를 구성하는 원본은 사람이 확인하고, 임시 자료만 자동 정리 대상으로 두는 방식입니다.
지금 남긴 폴더 정리 기준
폴더 자동 정리는 “깨끗하게 만들기”보다 “잃어버리지 않기”가 먼저입니다. 특히 블로그처럼 URL과 글 파일이 연결된 프로젝트에서는 파일 이동 하나가 검색 노출에도 영향을 줄 수 있습니다.
그래서 첫 자동 정리 스크립트는 아래 원칙으로 시작하려고 합니다.
dry-run 먼저
삭제 금지
이동 로그 필수
원본 폴더 보호
빌드 후 확인작은 자동화라도 되돌릴 수 있게 만들면, 나중에 블로그가 여러 개로 늘어났을 때 더 안전하게 재사용할 수 있습니다.
자동 정리 전에 묶은 보호 구역
파일 자동 정리는 편해 보이지만, Daejin Lab에서는 먼저 건드리면 안 되는 구역을 정했습니다. 특히 wiki, raw 자료, 프로젝트 저장소는 한 번 섞이면 되돌리는 비용이 큽니다.
| 구역 | 자동화 허용 범위 | 금지선 |
|---|---|---|
| 블로그 저장소 | 글 수, frontmatter, 내부 링크 점검 | 자동 삭제, 자동 발행 |
| raw 자료 | 새 캡처 파일 생성 보조 | 출처 없는 요약만 저장 |
| wiki | 승인된 지식 정리 | 임시 메모를 바로 장기 지식으로 승격 |
| 빌드 산출물 | dist 재생성 확인 |
원본 Markdown 덮어쓰기 |
반복 점검은 반복 작업을 Python 스크립트로 줄인 사례처럼 읽기 전용부터 시작하고, 자동화 범위는 작은 자동화가 일을 더 늘리는 순간의 기준으로 한 번 더 걸러야 안전했습니다.
이번에 다시 확인한 저장소 경계
Daejin Lab을 운영하면서 파일이 실제로 나뉘는 곳은 세 군데였습니다.
repo: 공개 사이트 원본과 빌드 대상
wiki: 오래 보존할 전략과 운영 지식
raw/inbox: 아직 정제하지 않은 외부 자료와 캡처이 셋을 자동으로 섞으면 편해 보이지만 위험합니다. repo의 Markdown은 공개 URL과 연결되고, wiki는 다음 작업의 판단 기준이 되며, raw 자료는 출처 보존 역할을 합니다. 자동 정리 스크립트가 이 차이를 모르고 파일을 이동하면 사이트 품질보다 복구 비용이 먼저 커집니다.
그래서 오토파일럿 작업에서도 먼저 아래처럼 나눴습니다.
| 대상 | 자동화 가능 | 승인 또는 수동 확인 |
|---|---|---|
| repo 문서 | 전략 문서 생성, README 갱신 | push와 배포 |
| 글 파일 | 기존 글 보강, build 검증 | 발행 방향 변경 |
| wiki | 승인된 전략 저장 | 대량 병합/삭제 |
| raw 자료 | 새 캡처 추가 | 출처 없는 요약만 남기기 |
| 개인 폴더 | 기본 접근 안 함 | 사용자가 경로를 명시한 경우만 |
자동 정리보다 먼저 필요한 기록
파일을 옮기는 스크립트를 만들기 전에, “왜 이 파일이 여기 있어야 하는지”가 문서화되어야 합니다. 이번 전략 작업도 먼저 wiki에 장기 전략을 저장하고, repo에는 실행용 요약 문서를 두는 방식으로 나눴습니다.
이렇게 해두면 다음에 자동화가 이어받을 때도 판단 기준이 분명합니다.
wiki는 장기 방향
repo docs는 실행 체크리스트
글 파일은 공개 콘텐츠
build 결과는 검증 산출물자동화는 이 경계를 넘지 않을 때 도움이 됩니다. 경계가 흐려질 때는 정리 스크립트를 더 똑똑하게 만들기보다, 자동 실행을 멈추고 사람이 분류하는 편이 안전합니다.
자동 정리 전에 보는 선
지금은 자동 정리를 파일 이동보다 후보 분류에 가깝게 봅니다. 바로 옮기기보다, 어디로 보낼지 제안하고 사람이 마지막에 확인하는 방식이 안전했습니다.
특히 프로젝트 파일, 원본 자료, 업로드 후보처럼 되돌리기 귀찮은 파일은 자동 이동 대상에서 빼려고 합니다. 정리 자동화는 편해야 하지만, 원본을 잃으면 아무 의미가 없습니다.
자동 정리는 되돌리기부터 생각한다
폴더가 지저분하면 바로 정리 스크립트를 만들고 싶어집니다. 그런데 파일 이동 자동화는 한번 잘못 돌리면 찾는 시간이 더 듭니다. 그래서 저는 삭제나 이동보다 먼저 dry-run과 로그를 남기는 쪽을 기준으로 잡았습니다.
자동 정리가 자료를 망가뜨리는 지점
폴더 정리 자동화는 편해 보이지만, 잘못 돌면 원본이 사라집니다. 그래서 어디까지 자동으로 옮기고 어디부터 손으로 확인할지 미리 정해두는 편이 안전했습니다.
이 카드는 로컬 파일 자동정리 전에 보는 공개용 안전선입니다. 실제 사용자명, 개인 경로, 계정 정보는 넣지 않았습니다.
파일 자동정리는 작은 편의처럼 보이지만, 잘못 움직인 파일은 맥락을 잃습니다. 특히 블로그 원고, raw 메모, 이미지 원본, 다운로드 자료가 섞인 폴더는 확장자만 보고 정리하면 안 됩니다. 그래서 먼저 dry-run으로 예상 이동 목록을 보고, 보호 구역을 정하고, 되돌릴 수 있는 로그를 남기는 쪽을 기준으로 잡았습니다.
함께 본 문서
Python 문서는 파일 경로와 이동 처리의 기본을 확인하는 데 봅니다. GitHub 문서는 정리 중 실수로 비밀값이나 내부 자료가 공개 저장소에 들어가는 위험을 다시 확인하는 용도입니다.
확인 못 한 부분
이 글은 2026년 6월 11일 정리 한 건과 그 전후로 겪은 안전 규칙을 기준으로 합니다. 정리할 때마다 대상, 이동 경로, 되돌릴 방법이 바뀌므로, 다음 정리 전에는 당시 기록을 다시 확인해야 합니다.
정리하며 받은 질문
파일 자동정리는 왜 위험한가요?
확장자만 보고 옮기면 프로젝트 맥락이 깨질 수 있습니다. 원고, 원본 이미지, 설정 파일은 위치 자체가 의미를 가질 때가 많습니다.
가장 먼저 넣을 안전장치는 무엇인가요?
dry-run입니다. 실제 이동 전에 무엇이 어디로 갈지 먼저 출력해야 합니다.
블로그 운영과 어떤 관련이 있나요?
공개 글의 원본, 이미지, raw/wiki 메모가 섞이면 보안 사고가 날 수 있습니다. 폴더 정리 기준은 공개 안전과 연결됩니다.