파일 이름만 잘 지으면 나중에 찾기 쉽겠지
“이 파일 어디 갔지?”
“최종_진짜최종_수정본_v3.docx”
“project_final_FINAL_real.pptx”
이런 파일명 지옥에서 벗어나고 싶었다.
파일명 카오스의 시작
계기:
중요한 보고서를 찾는 데 30분 걸렸다.
“보고서_수정.docx”
“보고서_수정2.docx”
“보고서_최종.docx”
“보고서_최종_수정.docx”
“보고서_진짜최종.docx”
다 비슷하게 생겼다.
“어떤 게 진짜 최종이야?”
결국 하나씩 열어봤다.
클라우드에 모든 걸 저장했는데 정작 찾지 못했던 경험이 떠올랐다. 파일이 많아지면 정리 체계가 필요하다고 생각했다.
결심: 파일명 규칙을 만들자
완벽한 명명 규칙 설계
1단계: 규칙 리서치
구글링: “파일 명명 규칙 best practice”
발견한 것들:
– ISO 8601 날짜 형식
– 시맨틱 버저닝
– 케이스 컨벤션 (snake_case, camelCase, kebab-case)
– 접두어/접미어 시스템
“이거 다 적용하면 완벽하겠다!”
2시간 리서치.
나만의 규칙 만들기
2단계: 규칙 정의
기본 구조:
[날짜]_[프로젝트]_[카테고리]_[제목]_[버전].[확장자]
날짜 형식:
YYYY-MM-DD (ISO 8601)
예: 2024-01-15
프로젝트 코드:
- WORK: 업무
- PERS: 개인
- SIDE: 사이드 프로젝트
- TEMP: 임시
카테고리:
- DOC: 문서
- IMG: 이미지
- DATA: 데이터
- CODE: 코드
- REF: 참고자료
버전:
- v1.0: 초안
- v1.1: 수정
- v2.0: 대폭 수정
- FINAL: 최종
예시:
2024-01-15_WORK_DOC_분기보고서_v1.0.docx
2024-01-16_WORK_DOC_분기보고서_v1.1.docx
2024-01-20_WORK_DOC_분기보고서_FINAL.docx
“완벽해!”
규칙 문서 작성: 3시간
노션 템플릿을 완벽하게 만들던 때가 생각났다. 그때도 이렇게 체계를 세우는 데 열중했었다.
적용의 어려움
3단계: 실전 적용
첫 번째 파일:
“회의록을 저장하자.”
고민 시작:
“이건 프로젝트가 뭐지?”
“WORK? 근데 어떤 프로젝트?”
“카테고리는 DOC? 아니면 따로 MTG 만들어야 하나?”
“버전은… 회의록에 버전이 필요해?”
파일명 결정: 15분
2024-01-15_WORK_MTG_주간회의_v1.0.docx
“MTG 카테고리를 추가해야겠다.”
규칙 수정: 10분
두 번째 파일:
“스크린샷을 저장하자.”
고민:
“날짜는… 찍은 날짜? 저장한 날짜?”
“프로젝트는? 어떤 프로젝트에서 쓸지 모르는데…”
“IMG_001인데 제목을 뭐로 해야 하지?”
파일명 결정: 10분
세 번째 파일:
“다운로드한 PDF…”
고민:
“이건 REF인데 원본 이름을 바꿔도 돼?”
“다운로드 날짜? 문서 작성 날짜?”
“저자 정보도 넣어야 하나?”
새로운 규칙 추가: 참고자료용 규칙
[날짜]_REF_[출처]_[제목].[확장자]
규칙 문서 업데이트: 20분
규칙의 진화
매일:
새로운 케이스 발견 → 규칙 추가
1주일 후:
규칙 목록:
– 기본 규칙
– 회의록 규칙
– 스크린샷 규칙
– 참고자료 규칙
– 이미지 규칙
– 다운로드 파일 규칙
– 임시 파일 규칙
– 버전 관리 규칙
– 예외 케이스 규칙
규칙 문서: 15페이지
북마크를 완벽하게 정리하던 때와 같은 패턴이었다. 분류 체계가 계속 복잡해진다.
역효과
문제 1: 파일 저장이 두려워졌다
“뭔가 저장해야 하는데…”
“규칙에 맞는 이름을 지어야 해…”
“음… 일단 나중에 하자.”
바탕화면에 임시 파일 쌓임.
문제 2: 이름 짓는 데 시간 소모
파일 저장할 때마다:
– 날짜 확인: 30초
– 프로젝트 결정: 1분
– 카테고리 선택: 30초
– 제목 고민: 2분
– 버전 확인: 30초
파일당 약 5분.
하루 파일 20개 × 5분 = 100분
문제 3: 규칙을 기억 못 함
“REF는 뭐였지?”
“날짜 형식이… 하이픈? 언더스코어?”
규칙 문서 다시 확인: 매번 2분
문제 4: 협업 불가능
동료에게 파일 보내면:
“이게 뭐야? 파일명 왜 이래?”
“2024-01-15_WORK_DOC_분기보고서_v1.1.docx?”
“그냥 ‘분기보고서’라고 하면 안 돼?”
깨달음의 순간
어느 날:
“파일명 짓는 데 얼마나 시간 쓰지?”
계산:
파일당 5분 × 하루 20개 = 100분/일
한 달: 50시간
파일 찾는 시간 절약:
– 기존: 파일당 3분
– 현재: 파일당 1분
– 절약: 2분 × 20개 = 40분/일
한 달: 20시간
결과:
– 투자: 50시간
– 절약: 20시간
– 손해: 30시간
“이름 짓느라 찾는 시간보다 더 쓰고 있어.”
더 큰 문제
진짜 문제:
파일명 규칙 만드느라 정작 파일을 만들지 못함.
예시:
“보고서 써야 하는데…”
“일단 파일명부터 정하자…”
(10분 고민)
“… 내일 하자.”
미룬 작업: 수십 개
규칙은 완벽한데 결과물은 없음.
미니멀리즘 하려고 정리하느라 더 바빠졌던 이야기가 떠올랐다. 정리 자체가 목적이 되어버린 것이다.
실험
1주일간:
규칙 전부 삭제.
새로운 규칙 딱 1개:
알아볼 수 있으면 된다.
방법:
– 직관적인 이름
– 길어도 괜찮음
– 날짜는 필요할 때만
– 검색으로 찾기
예시:
분기보고서 초안.docx
분기보고서 수정본.docx
분기보고서 최종 제출용.docx
결과:
파일 저장 시간: 5분 → 30초
파일 찾는 시간: 비슷함 (검색 사용)
스트레스: 급감
검색이 답이었다
깨달음:
완벽한 파일명 < 검색 기능
현대 운영체제:
– Spotlight (Mac)
– Windows Search
– Everything (Windows)
내용으로 검색 가능.
파일명이 “asdf.docx”여도 “분기보고서”로 검색하면 나옴.
정리 규칙의 무의미함.
사진 5년 치를 정리하느라 추억은 못 봤던 경험도 같은 맥락이었다. 정리하느라 본질을 놓친다.
새로운 방법
규칙 1: 직관적 이름
나중에 “이게 뭐였지?” 안 할 정도로만.
규칙 2: 날짜는 선택
필요한 파일만 (계약서, 영수증 등).
규칙 3: 버전은 간단히
v1, v2 또는 “수정본”, “최종”
규칙 4: 검색에 의존
정리보다 검색.
현재 상태
파일명:
– “회의록 1월 15일.docx”
– “프로젝트A 보고서.pptx”
– “참고자료 – 시장조사.pdf”
규칙 문서: 삭제함
저장 시간: 30초 이내
찾는 시간: 검색으로 30초
스트레스: 없음
비교
이전 (완벽한 명명 규칙):
– 규칙 설계: 5시간+
– 파일당 저장: 5분
– 규칙 유지: 매일 추가 수정
– 스트레스: 높음
– 실제 작업: 미룸
현재 (직관적 이름):
– 규칙: 없음
– 파일당 저장: 30초
– 유지 비용: 0
– 스트레스: 없음
– 실제 작업: 바로 함
깨달은 것
1. 이름 < 내용
파일명 고민하느라 내용 못 만들면 본말전도.
2. 규칙의 유지 비용
규칙이 복잡할수록 지키기 어렵고 시간 듦.
완벽한 지식 관리 시스템을 만들다 배우지 못했던 함정도 똑같았다. 시스템 구축에 시간을 뺏기면 본업이 밀린다.
3. 검색 기술의 발전
정리 안 해도 찾을 수 있음.
4. 미래의 나는 기억 못 함
완벽한 규칙도 까먹음.
그냥 직관적으로 지으면 됨.
5. 완벽주의의 함정
완벽한 시스템 만들기 < 일단 하기
템플릿을 수백 개 모았지만 하나도 못 쓴 이야기가 이를 증명한다.
결론: 파일명보다 파일 내용
파일 명명 규칙의 역설:
문제:
– 복잡한 규칙 체계
– 저장할 때마다 고민
– 유지 비용
– 정작 작업은 미룸
해결:
– 직관적 이름
– 검색 활용
– 간단하게
파일 이름을 완벽하게 짓는 것보다,
그 시간에 파일을 만드는 게 100배 낫다.
가장 좋은 파일명은 고민 안 해도 되는 파일명이다.
규칙에 맞추려 하지 말고, 알아볼 수 있으면 된다.
P.S. 이 글의 파일명은 “블로그 파일명함정.md”다. 규칙 없이 그냥 지었다.