문서 버전 이름 정하기: 최종본을 여러 개 만들지 않는 규칙

파일 순서 맞히기 게임

가상의 회의 문서 네 개를 최근 날짜부터 선택하세요. 날짜가 같으면 v02를 v01보다 먼저 고릅니다. 실제 파일을 열거나 정리하는 게임은 아닙니다.

YYYY-MM-DD와 두 자리 버전 번호를 쓰는 이 예시에서만 적용하는 규칙입니다. 날짜가 최근이라는 이유만으로 승인된 최종 문서가 되지는 않습니다.

폴더에 ‘보고서 최종’, ‘보고서 최종2’, ‘보고서 진짜최종’이 함께 있으면 가장 최근 파일을 골라도 어떤 내용이 승인됐는지 알기 어렵습니다. 저장 시각이 늦다는 사실과 승인된 내용이라는 사실은 다릅니다. 문서 버전 관리는 이름을 길게 붙이는 기술보다 변경 순서와 상태를 분리하는 규칙입니다. 이 글에서는 개인 작업과 소규모 협업에서 사용할 수 있는 예시 규칙을 제안하고, 클라우드 버전 기록과 파일 이름의 역할을 함께 설명합니다.

1. 문서의 정체성, 버전, 상태를 나누어 생각한다

문서의 정체성은 어떤 업무의 어떤 문서인지입니다. 버전은 내용이 어떤 순서로 바뀌었는지이고, 상태는 초안인지 검토 중인지 승인됐는지입니다. 파일 수정 시각은 저장한 시점입니다. 이 네 가지를 ‘최종’이라는 단어 하나로 대신하면 서로 다른 정보가 섞입니다. 이름에는 짧게 식별할 정보를 담고, 변경 이유와 승인 기록은 별도 이력에 남기는 방식이 관리하기 쉽습니다.

미국 국립문서기록관리청 NARA의 파일 이름 안내는 일관된 구성, 의미 있는 이름, 날짜·버전 등의 위치를 정하는 원칙을 제시합니다. 이 글의 규칙은 그 원칙을 개인 문서 작업에 적용한 예시입니다. 미국 정부 기록의 기술 지침이 모든 한국 개인 파일에 의무적으로 적용된다는 뜻은 아닙니다. 회사의 문서 관리 규정이나 협업 시스템이 있다면 그 규칙을 먼저 확인하고 개인 규칙과 맞춰야 합니다.

2. 한 줄짜리 이름 규칙부터 정한다

설명용 이름은 YYYYMMDD_문서명_vNNN_상태.확장자로 만들 수 있습니다. 날짜는 이 예시에서는 ‘문서가 대상으로 삼는 업무 날짜’로 정합니다. 마지막 저장 날짜를 넣는 방식도 가능하지만 두 뜻을 섞지 않아야 합니다. 문서명은 작업을 식별하는 짧은 단어를 쓰고, 버전에는 세 자리 숫자를 사용하며, 상태는 draft·review·approved 세 가지로 시작합니다.

20261010_report_v001_draft.docx
20261010_report_v002_review.docx
20261010_report_v003_approved.docx

위 이름은 가상의 보고서 파일 예시입니다. v003이 승인됐다고 이름을 붙였다고 해서 누군가 실제로 승인한 사실이 생기지는 않습니다. 승인 기록과 이름이 일치하도록 관리해야 합니다. 확장자는 프로그램이 사용하는 실제 파일 형식과 연결되므로 이름을 정리하면서 임의로 바꾸지 않습니다. DOCX를 PDF로 변환하려면 해당 프로그램의 내보내기 기능으로 실제 형식을 만들어야 합니다.

구성 요소	예시 규칙	혼동을 줄이는 이유
날짜	업무 기준일 YYYYMMDD	업무 날짜와 저장 날짜를 섞지 않음
문서명	report 등 일관된 식별어	같은 문서의 파일을 함께 찾음
버전	v001, v002, v003	숫자의 자릿수를 맞춰 순서를 읽음
상태	draft, review, approved	내용 변경 순서와 승인 여부를 분리
확장자	실제 형식 .docx, .pdf	이름 변경과 형식 변환을 구분

3. 어떤 변경에서 버전을 올릴지 정한다

이 예시에서는 다른 사람에게 새 내용을 전달하는 변경이 생기면 버전 번호를 하나 올립니다. 가령 v001 초안에서 표의 항목을 추가하고 설명을 고친 뒤 검토를 요청하면 v002가 됩니다. 단순히 파일을 열었다 닫거나 저장만 했다고 업무 버전을 반드시 올릴 필요는 없습니다. 반대로 숫자나 결론이 바뀌었다면 글자 수가 적어도 중요한 변경일 수 있습니다. 변화의 크기보다 받는 사람이 새 내용으로 구분해야 하는지가 기준입니다.

버전 번호를 올리지 않는 사소한 수정도 있을 수 있지만 그 기준을 합의해야 합니다. 예를 들어 공유 전 개인 초안의 오탈자는 같은 버전 안에서 다듬고, 검토 요청 뒤의 내용 수정은 새 버전으로 만든다고 정할 수 있습니다. 이 규칙은 보편적인 표준이 아니라 작업에 맞춘 선택입니다. ‘내용 변경이 있었는데 같은 이름으로 덮어써도 되는가’를 먼저 정하면 공유 후 혼동을 줄일 수 있습니다.

메이저·마이너 번호가 꼭 필요한 것도 아닙니다. 세부 규칙 없이 v1.2.3처럼 복잡한 숫자부터 사용하면 사람마다 증가 기준이 달라질 수 있습니다. 소규모 작업에서는 v001부터 순서대로 올리고 변경 이력을 남기는 방식이 충분할 수 있습니다. 작업이 커져 별도 규칙이 필요해졌을 때 번호의 의미를 확장하세요. 번호 자체가 품질 점수나 승인 순위를 나타내지는 않습니다.

4. 검토 상태와 승인 상태를 실제 기록에 연결한다

draft는 작성 중, review는 검토를 요청한 상태, approved는 정해진 승인 절차를 마친 상태로 정의할 수 있습니다. 중요한 것은 정의가 실제 작업과 일치하는 것입니다. 검토자가 의견을 남겼다고 모두 승인된 것은 아니며, 승인 뒤 내용을 고치면 다시 검토가 필요한지 정해야 합니다. 승인된 파일을 수정하면서 이름만 approved로 유지하면 받는 사람이 승인 범위를 잘못 이해할 수 있습니다.

설명용 흐름은 ‘v001 초안 작성 → v002 검토 요청 → 의견 반영 후 v003 승인’입니다. 실제로 v002 내용 그대로 승인됐다면 이름의 상태만 바꾸고 같은 내용이라는 기록을 남기는 방식도 가능합니다. 어느 방식을 택하든 내용 변경과 상태 변경을 구분하세요. 버전을 반드시 올리는 방식과 상태만 갱신하는 방식이 섞이면 번호의 의미를 이해하기 어려워집니다.

승인 기록에는 대상 버전, 확인한 사람 또는 절차, 날짜, 남은 조건을 적을 수 있습니다. 개인 문서라면 ‘제출 전 점검 완료’처럼 실제 수행한 상태를 쓰면 됩니다. 회사 문서에서 승인을 받지 않았는데 혼자 approved라는 이름을 붙이지 않습니다. 이름은 상태를 보여주는 표시이며, 상태가 실제로 성립했는지 확인하는 근거는 이력이나 협업 시스템에 남겨야 합니다.

5. 변경 이력은 한 줄씩 남겨도 충분히 도움이 된다

파일 안의 첫 페이지나 별도 목록에 ‘버전·날짜·바뀐 내용·상태’를 기록합니다. 예를 들어 ‘v002, 2026-10-10, 비교표에 조건 열 추가, 검토 요청’이라고 적으면 번호가 왜 달라졌는지 알 수 있습니다. ‘여러 부분 수정’보다 어떤 부분의 의미가 바뀌었는지를 적는 것이 좋습니다. 모든 문장 차이를 이력에 복사할 필요는 없지만 결론이나 핵심 수치의 변경은 빠뜨리지 않습니다.

검토 의견을 여러 사람이 보냈다면 기준이 되는 파일 버전을 먼저 확인하세요. v001에 달린 의견을 v003에 적용할 때 이미 반영됐는지, 새 내용과 충돌하는지 살펴봅니다. ‘최신 파일에 모두 붙여 넣기’만 하면 옛 표현이 다시 들어가거나 표의 조건이 되돌아갈 수 있습니다. 변경 이력은 어느 의견을 어떤 버전에 반영했는지 추적하는 데도 사용할 수 있습니다.

여러 파일의 내용이 서로 다르면 수정 시각으로 곧바로 승자를 정하지 않습니다. 각 파일의 이력과 실제 차이를 비교하고, 필요한 변경을 한 기준본에 합친 뒤 새 버전으로 저장합니다. 검토 전 사본은 남겨 두세요. 기준본을 정한 뒤에는 현재 작업 위치를 한 곳으로 모으고, 예전 파일은 별도 보관 위치에 두어 검색 결과에서 함께 선택되는 일을 줄일 수 있습니다.

6. 클라우드 버전 기록은 이름 규칙을 보완한다

Microsoft는 OneDrive와 SharePoint에 저장된 파일에서 버전 기록을 확인하고 이전 버전을 복원하는 기능을 안내합니다. 웹에서 해당 파일의 메뉴나 오른쪽 클릭 메뉴에 있는 버전 기록을 열어 이전 항목을 확인할 수 있습니다. 학교·회사 계정에서는 관리자가 기능을 비활성화했을 수 있고, 실제 사용 가능한 기록의 범위는 환경에 따라 확인해야 합니다. 모든 로컬 파일에 자동으로 같은 기록이 생기는 것은 아닙니다.

복원할 때는 먼저 대상 파일과 버전 내용을 확인하세요. 공식 안내에 따르면 선택한 이전 버전이 현재 버전이 되고, 기존 현재 버전은 기록의 이전 항목으로 남는 방식입니다. 공동 작업 중이라면 다른 사람이 현재 내용을 보고 있을 수 있으므로 기준본을 되돌린다는 사실을 공유해야 합니다. 중요한 변경을 보존해야 한다면 복원 전에 현재 내용을 별도 사본으로 남기는 방식을 고려할 수 있습니다.

클라우드의 내부 버전과 파일 이름의 업무 버전은 같은 숫자 체계가 아닐 수 있습니다. 프로그램이 자동 저장하면서 기록을 여러 번 만들었어도 업무상 검토 요청은 한 번일 수 있습니다. 반대로 파일을 새 이름으로 복사하면 이전 파일의 기록을 그대로 이어 보는 방식과 다를 수 있습니다. 내부 기록은 복구와 변화 추적에, 업무 버전 이름은 공유와 승인 구분에 활용하는 식으로 역할을 정하세요.

7. 배포본과 편집본을 같은 버전에 연결한다

승인된 DOCX를 PDF로 내보냈다면 이름의 날짜와 버전, 상태를 맞출 수 있습니다. 가상의 20261010_report_v003_approved.docx와 20261010_report_v003_approved.pdf는 같은 승인 내용을 가리키도록 관리합니다. 그러나 이름이 같다는 것만으로 실제 내용이 같다는 증거가 되지는 않습니다. PDF를 만들고 페이지 누락, 표 잘림, 글꼴과 링크 등 배포에 필요한 항목을 확인해야 합니다.

PDF를 만든 뒤 DOCX의 내용이 다시 바뀌었다면 PDF도 새 기준본에서 다시 생성해야 합니다. 예전 PDF를 같은 이름으로 전달하면 편집본과 배포본의 연결이 끊어집니다. 이력에는 내보낸 기준 버전을 적고, 전달할 파일은 별도 배포 위치에 모으는 방법을 사용할 수 있습니다. 버전 이름의 목적은 이 연결을 사람이 빠르게 확인하도록 돕는 데 있습니다.

공유할 때는 ‘최종 파일 첨부’만 적기보다 문서명과 버전, 상태를 함께 적으세요. ‘보고서 v003 승인본 PDF를 전달합니다. 이전 v002 검토본은 사용하지 않습니다’처럼 구체적으로 안내할 수 있습니다. 공유 링크를 사용하는 경우에도 링크가 어느 기준본을 가리키는지 확인합니다. 링크의 내용이 계속 바뀌는 작업 파일인지, 제출용으로 고정한 파일인지 구분하면 받는 사람의 기대가 명확해집니다.

8. 규칙을 너무 복잡하게 만들지 않는 점검표

• 파일의 날짜가 무엇을 뜻하는지 한 가지로 정했는가?
• 같은 문서에 같은 식별어를 쓰는가?
• 버전 숫자의 자릿수를 맞췄는가?
• 내용 변경과 검토·승인 상태를 구분했는가?
• 공유 뒤 변경에는 새 기준본을 남기는가?
• 변경 이유와 승인 범위가 이력에 있는가?
• 편집본과 PDF의 기준 버전이 연결되는가?
• 클라우드 복원 대상과 현재 작업본을 확인했는가?

처음부터 모든 정보를 파일 이름에 넣으려고 하면 이름을 읽고 유지하기 어려워집니다. 짧은 식별 정보는 이름에, 자세한 이유와 승인 기록은 이력에 두세요. 규칙 한 줄과 이력 네 칸만으로도 ‘진짜최종’을 여러 번 붙이는 상황에서 벗어날 수 있습니다. 중요한 것은 긴 이름이 아니라 팀과 미래의 자신이 같은 기준본을 고를 수 있는 일관성입니다.

공식 출처와 작성 기준

• NARA: 파일 이름을 정하는 기본 원칙
• NARA: 일관된 파일 이름 구성 안내
• Microsoft: OneDrive 파일의 이전 버전 복원

자료 확인일: 2026-10-10. 실제로 연 공식 자료를 바탕으로 AI가 작성한 설명입니다. 별도 표시한 계산·코드·점검 사례는 설명용이며 사용자 환경을 직접 시험하거나 실측한 결과가 아닙니다. 발행일에는 기능과 자료의 변경 여부를 다시 확인합니다.