팀을 위한 파일 명명 규칙 완벽 가이드

KISA(한국인터넷진흥원)의 정보보호 관리체계(ISMS) 인증 기준은 문서화와 추적 가능성을 핵심 요건으로 명시합니다. 파일 명명 규칙은 그 추적 가능성을 사람의 판단 없이 자동으로 유지하는 기반입니다. 현실에서 살아남는 파일 명명 규칙의 형식: YYYY-MM-DD_ProjectCode_DocType_Descriptor_vNN.ext. 항상 ISO 8601 날짜, 짧은 프로젝트 코드(3~10자), 문서 유형을 위한 통제된 어휘, 케밥 케이스 설명어, 두 자리 버전 번호(v02, v2 아님), 필요 없는 곳에는 소문자. 예시: 2026-06-12_ACME-RB_contract_master-services-agreement_v02.pdf. 형식보다 일관성이 더 중요합니다.

날짜를 앞에 두는 이유

ISO 8601 날짜(YYYY-MM-DD)를 파일 이름 앞에 두면 정렬 문제가 해결됩니다. 2026-06-12_report.pdf는 모든 파일 시스템, 모든 클라우드 드라이브에서 2026-06-13_report.pdf 바로 옆에 위치합니다. 날짜를 끝에 두면 이 장점이 사라집니다.

ISO 8601만이:

텍스트로 올바르게 정렬됨
로케일 전반에서 명확하게 파싱 가능 (06/05/2026은 6월 5일인가, 5월 6일인가?)
모든 주요 기술 회사 로그에서 사용하는 국제 표준과 일치

시간이 중요한 파일의 경우 시간도 추가: 2026-06-12T1430Z_meeting-notes.md는 UTC 기준. 다중 시간대 팀에서 생성 시점이 인수인계 명확성에 중요할 때 유용합니다.

확장 가능한 프로젝트 코드

두 번째 위치의 짧은 프로젝트 코드는 폴더 구조에 의존하지 않고 프로젝트별로 파일을 검색 가능하게 만듭니다. 효과적인 규칙:

3~10자, 대문자, 하이픈 허용
처음 3~4자는 클라이언트 또는 내부 단위 식별
선택적 접미사로 프로젝트 유형 또는 단계 식별

예시: ACME-RB(Acme 리브랜딩), INTL-ONBRD(내부 온보딩), FINOPS-Q2(재무 운영 Q2).

Notion, Confluence, 또는 공유 스프레드시트에서 프로젝트 코드 레지스트리를 관리하세요. 새 프로젝트 시작 시 코드를 등록하면 30초면 충분합니다. 세 달 후 누군가는 ACMErebrand, 다른 누군가는 Acme-RB라고 부르는 혼란을 방지합니다.

문서 유형을 위한 통제된 어휘

문서 유형 슬롯에는 고정된 목록이 필요합니다. 없으면 report, Report, rpt, summary, final-report 모두 같은 의미가 됩니다.

시작용 어휘:

brief — 초기 프로젝트 브리프, 크리에이티브 브리프
spec — 기술 또는 디자인 사양
contract — 법적 계약, SOW, NDA
invoice — 청구 문서
proposal — 제안서
report — 정기 또는 임시 보고서
presentation — 덱, 발표, 전체 회의
design — 디자인 자산과 납품물
dataset — CSV, Excel, JSON 데이터 파일
note — 회의록, 작업 메모
template — 재사용 가능한 시작점

목록을 짧게 유지하세요. 목록 수준의 규율이 복리 효과를 가져옵니다.

실제로 작동하는 버전 번호 체계

v1, v2, v3은 v10이 나올 때까지 작동합니다. v10은 v2 앞에 정렬됩니다. 처음부터 두 자리 버전 번호를 사용하세요: v01, v02, v03.

주 버전과 초안 구분:

v01 — 첫 번째 확정 버전
v01.1, v01.2 — 주 버전 내 마이너 초안
새로 검토할 가치가 있는 실질적 변경 시 주 버전 업

"최종"의 함정: 파일 이름에 절대 "final"이라는 단어를 넣지 마세요. final, final-final, final-final-REAL, final-use-this-one이 보장됩니다. 대신 v02를 사용하고 버전 번호를 신뢰하세요.

케밥 케이스 설명어

설명어 슬롯은 유일한 자유 형식 부분입니다. 다음을 유지하세요:

소문자
케밥 케이스(하이픈으로 단어 구분)
짧게: 2~5단어
훑어볼 수 있을 만큼 구체적: q2-revenue-forecast가 forecast보다 나음

master-services-agreement는 좋습니다. MasterServicesAgreement.pdf는 나쁩니다. 파일 이름의 공백은 커맨드라인 파이프라인과 URL 인코딩을 망칩니다.

경찰 국가 없이 규칙 적용하기

200명 조직의 모든 파일에 명명을 수동으로 적용할 수 없습니다. 가능한 방법:

온보딩: 입사 첫 주에 예시와 함께 명명 규칙 15분 교육
템플릿: /Knowledge/Templates/에 미리 명명된 템플릿 파일 제공
검토 중 현장 수정: 작업 검토 시 잘못 명명된 파일을 가벼운 코멘트와 함께 바로 수정
주간 정리 패스: 순환하는 담당자가 10분 동안 편차 수정
자동 이름 변경 봇: Python + watchdog + os.rename으로 고용량 폴더 자동 처리. 반나절 프로젝트.

특수 문자 및 길이 제한

특정 문자는 파일 시스템이나 클라우드 도구를 망칩니다:

피해야 할 것: / \ : * ? " < > |
파일 이름에 공백 금지
전체 경로를 255자 미만으로 유지

기록을 깨지 않고 마이그레이션하기

기존 혼란에 새 규칙을 적용할 때 기존 파일의 이름을 바꾸지 마세요. 기존 링크, 북마크, 참조가 깨집니다. 대신:

특정 날짜부터 모든 새 파일에 새 규칙 적용
진행 중인 작업에서 수정되는 파일만 이름 변경
아카이브를 2~3년에 걸쳐 자연스럽게 처리

10,000개 파일이 있는 드라이브의 완전 소급 이름 변경은 40시간짜리 프로젝트로 대부분 비용 대비 효과가 없습니다. 앞으로의 규율이 뒤로의 정리보다 효과적입니다.

https://hexatransfer.com 에서 HexaTransfer를 사용해 보세요. 무료이며, 계정이 필요 없고, 최대 10GB를 지원합니다.