이름에 담을 정보는 찾는 순서로 정합니다
파일 이름은 모든 정보를 담는 설명서가 아니라 다음에 찾을 때 쓰는 단서입니다. 먼저 “어느 프로젝트의 무엇을 언제 만들었는가”와 “수신자가 어떤 용도로 쓰는가”를 구분하세요. 폴더가 이미 프로젝트를 구분한다면 파일명에 같은 말을 길게 반복할 필요는 없습니다.
아래 규칙은 HLB의 편집 예시이며 표준이나 모든 회사에 맞는 정답은 아닙니다. 팀의 기존 규칙이 있다면 그것을 먼저 사용하고, 검색에 필요한 항목만 보완합니다.
확정본과 작업본을 같은 이름으로 덮어쓰지 않습니다
작업 중인 문서는 계속 바뀌지만 외부에 전달한 확정본은 그때의 내용을 식별할 수 있어야 합니다. “최종”이라는 표현을 계속 붙이기보다 제출 날짜와 버전을 남기고, 수정 중인 원본과 전달한 사본을 분리하세요.
가상의 디자인 검토 작업이라면 초안은 design_review_v03, 전달본은 design_review_2026-10-10_v03.pdf처럼 정할 수 있습니다. 날짜가 작성일인지 전달일인지도 팀에서 하나로 맞춰야 합니다.
| 역할 | 이름 예시 | 남길 정보 |
|---|---|---|
| 편집 중 원본 | design_review_v03 | 작업 버전 |
| 검토 요청 사본 | design_review_2026-10-10_v03.pdf | 전달일과 버전 |
| 승인 기록 | design_approved_2026-10-10_v03.pdf | 승인한 내용을 식별 |
폴더와 파일의 역할을 나눕니다
폴더는 작업의 범위나 단계, 파일은 문서의 종류와 버전을 나타내도록 나누면 이름이 짧아집니다. 예를 들어 프로젝트 폴더 안에 working, delivered, archive를 두는 방식입니다. 이 단계 이름도 실제 업무에 맞게 정하세요.
폴더를 너무 세분화하면 분류하는 시간이 찾는 시간보다 길어질 수 있습니다. 가장 자주 찾는 파일 세 개를 기준으로, 몇 번 이동해야 도착하는지 직접 확인해보세요.
기존 이름을 바꿀 때는 작은 묶음부터
이미 공유한 링크나 자동화가 파일 이름·경로를 참조한다면 이름 변경이 다른 작업에 영향을 줄 수 있습니다. 먼저 사본 몇 개에 새 규칙을 적용하고 연결된 작업을 확인하세요. 이 글은 사용하는 서비스의 링크 유지 동작을 보장하지 않습니다.
변경 전 이름과 변경 후 이름을 두 열로 기록해두면 문의가 왔을 때 파일을 찾기 쉽습니다. 대량 변경 전에 원본 목록과 되돌릴 방법을 확보하고, 확인한 범위만 확장합니다.
- 공유된 파일과 내부 작업 파일을 먼저 구분합니다.
- 현재 경로를 사용하는 자동화·문서 링크를 확인합니다.
- 예전 이름과 새 이름의 대응 목록을 남깁니다.
정리가 끝났는지는 검색으로 확인합니다
규칙을 만들었다면 익숙하지 않은 사람에게 프로젝트명·날짜·문서 종류를 주고 찾게 해보세요. 어디에서 헷갈리는지 기록하고 이름이나 폴더 구조를 고칩니다. 실제 검색해보기 전부터 시간 절약 효과를 확정하지 않습니다.
이름만 잘 정해도 모든 보관 문제를 해결하지는 못합니다. 중복 사본, 보관 기간, 접근 권한과 복원 가능한 백업은 별도로 관리하세요.
