업무 문서 버전 관리, ‘최종본’ 대신 상태가 보이게 남기는 방법
수정본이 계속 생기는 업무 문서를 v01·v02처럼 관리하고, 검토중·승인본·배포본 상태를 헷갈리지 않게 구분하는 실무용 버전 관리 기준을 정리합니다.
업무 문서가 여러 번 수정되기 시작하면 ‘최종’, ‘최종수정’, ‘진짜최종’, ‘최종2’ 같은 파일명이 빠르게 늘어납니다. 문제는 파일 수가 많아서가 아니라 어느 파일이 최신이고 어느 파일이 승인된 것인지 이름만 보고 판단할 수 없다는 점입니다.
문서 버전 관리는 복잡한 시스템을 만드는 일이 아닙니다. 파일명에 버전과 상태를 분리해서 적고, 수정할 때마다 같은 규칙을 반복하면 됩니다.
버전 번호와 문서 상태는 서로 다른 정보다
가장 먼저 구분해야 할 것은 버전과 상태입니다.
- 버전: 몇 번째 수정본인지
- 상태: 지금 이 문서가 어떤 단계인지
예를 들어 v03은 세 번째 수정본이라는 뜻이고, review는 검토 중이라는 뜻입니다. 두 정보를 섞어서 ‘최종수정본’처럼 쓰면 나중에 다시 수정될 때 이름이 무너집니다.
그래서 파일명은 다음처럼 나누는 편이 좋습니다.
2026-09-29_project-report_v03_review.docx
이름만 봐도 세 번째 수정본이며 아직 검토 단계라는 것을 알 수 있습니다.
처음부터 v1보다 v01처럼 자릿수를 맞춘다
수정 횟수가 많아질 가능성이 있다면 v1, v2, v3보다 v01, v02, v03처럼 두 자리로 맞추는 편이 정렬하기 좋습니다.
파일 탐색기에서 이름순으로 정렬했을 때도 순서가 자연스럽게 이어집니다. 문서가 열 번 이상 수정될 가능성이 거의 없더라도 팀 규칙을 하나로 통일한다는 장점이 있습니다.
중요한 것은 숫자 체계 자체보다 모든 사람이 같은 방식으로 버전을 올리는 것입니다.
사소한 오타 수정까지 새 버전으로 만들 필요는 없다
버전을 너무 자주 올리면 오히려 관리가 번거로워집니다. 모든 저장마다 새 파일을 만드는 방식은 피하는 편이 좋습니다.
새 버전은 보통 다음과 같은 변화가 있을 때 남기면 충분합니다.
- 검토자에게 새로 전달할 때
- 내용 구조가 의미 있게 바뀌었을 때
- 수치나 결론이 달라졌을 때
- 승인 단계가 바뀌었을 때
반면 줄바꿈 하나, 단순 오타 하나를 고친 정도라면 같은 작업 파일에서 수정하고 다음 공유 시점에 버전을 올리는 방식이 실용적입니다.
‘최종’은 한 번만 쓰고 승인 이후에는 상태명으로 바꾼다
가장 혼란스러운 표현이 ‘최종’입니다. 검토가 다시 시작되면 최종본이 또 생기기 때문입니다.
차라리 상태를 명확하게 나누는 편이 낫습니다.
- draft: 작성 중
- review: 검토 중
- approved: 승인 완료
- issued 또는 published: 외부 배포 완료
팀에서 한국어를 선호한다면 ‘초안’, ‘검토중’, ‘승인’, ‘배포’처럼 써도 됩니다. 핵심은 상태 단어를 미리 정해두고 같은 의미에 같은 표현을 쓰는 것입니다.
최신 작업 파일과 보관본을 같은 폴더에 뒤섞지 않는다
버전 파일이 계속 쌓이면 최신본을 찾는 데 시간이 걸립니다. 이때 오래된 버전을 삭제할 필요는 없지만 작업 중인 파일과 과거 보관본을 분리하는 편이 좋습니다.
예를 들어 프로젝트 폴더 안에 다음처럼 둘 수 있습니다.
working: 현재 작업 중인 파일archive: 지난 버전final: 승인·배포된 결과물
폴더 구조를 이미 만들고 있다면 프로젝트 폴더 구조 정리 방법과 연결해서 운영하면 더 깔끔합니다.
파일명 규칙과 버전 규칙을 따로 만들지 않는다
버전 관리가 잘 되려면 기본 파일명 규칙과 함께 움직여야 합니다.
기존에 날짜, 프로젝트명, 문서종류를 쓰고 있다면 뒤에 버전과 상태만 붙이면 됩니다.
2026-09-29_alpha_proposal_v02_review.pdf
이 방식은 날짜·버전·프로젝트명을 활용한 업무 파일명 규칙과도 자연스럽게 이어집니다. 파일명 전체 구조는 그대로 두고 버전과 상태 위치만 고정하면 됩니다.
여러 사람이 수정한다면 ‘누가 최신본을 관리하는지’도 정한다
팀 작업에서는 파일명보다 더 중요한 문제가 있습니다. 각자 수정한 파일을 따로 가지고 있으면 같은 버전 번호의 다른 문서가 생길 수 있습니다.
공유 폴더를 쓴다면 최신본을 올리는 위치를 하나로 정하고, 수정 후에는 그곳의 파일을 기준으로 다음 작업을 시작하는 편이 좋습니다.
이메일 첨부로 파일을 주고받는 경우에도 받은 파일을 그대로 새 문서처럼 저장하기보다 공용 작업본에 반영한 뒤 버전을 올리는 방식이 덜 헷갈립니다.
승인본은 수정하지 말고 다음 버전으로 복사한다
승인된 파일을 열어서 그대로 수정하면 어떤 내용이 실제 승인됐는지 추적하기 어려워집니다.
승인 이후 추가 변경이 필요하다면 승인본은 그대로 보관하고 새 작업본을 복사해 다음 버전으로 시작하세요.
예를 들어 v04_approved가 승인본이라면 수정이 필요할 때 v05_draft를 새로 만드는 식입니다.
이렇게 하면 승인 이력과 현재 수정 중인 문서를 동시에 유지할 수 있습니다.
버전 메모가 필요하면 파일명보다 문서 안에 남긴다
파일명에 모든 변경 내용을 넣으려 하면 이름이 지나치게 길어집니다. “표 수정”, “2페이지 문구변경”, “대표님 피드백 반영” 같은 설명은 파일명보다 문서 내부의 변경 기록이나 별도 메모에 남기는 편이 낫습니다.
파일명은 문서를 찾고 상태를 구분하는 역할만 해야 합니다. 세부 변경사항은 문서 안에서 관리해야 규칙이 오래 유지됩니다.
가장 단순한 운영 규칙은 세 줄이면 된다
팀에서 바로 적용하려면 아래 세 가지면 충분합니다.
- 공유할 때마다 버전을 한 단계 올린다.
- 버전 뒤에 draft·review·approved 같은 상태를 붙인다.
- 승인본은 덮어쓰지 않고 보관한다.
문서 버전 관리는 완벽한 기록 시스템보다 누가 봐도 최신 작업본과 승인본을 구분할 수 있게 만드는 것이 목적입니다. 파일명이 그 역할을 해준다면 이미 충분히 잘 운영되고 있는 것입니다.