어제 오후, 당신이 견적서를 보내기 직전이었다고 합시다. 공유 폴더를 열자 이런 파일들이 나란히 있습니다. 견적서_최종.xlsx, 견적서_진짜최종.xlsx, 견적서_수정.xlsx, 견적서_최종_대표확인.xlsx. 어느 것을 고객에게 보내도 될까요?
이 장면에서 문제는 검색 기능이 약한 게 아닙니다. 어느 파일이 효력을 갖는지 합의가 없는 것입니다. 파일명에 ‘최종’을 세 번 붙여도, 다음 수정자가 ‘진짜최종’을 붙이면 다시 끝없는 경쟁이 시작됩니다.
같은 이름이 여러 개 생기는 하루
문서가 버전별로 쌓이는 경로는 거의 정해져 있습니다.
- ‘다른 이름으로 저장’을 눌러 파일이 두 갈래로 나뉜다
- 수정할 때마다
_최종,_최종최종같은 이름이 붙는다 - 승인본을 메신저나 이메일로 보내면서 사본이 또 흩어진다
- 나중에는 누가 언제 만든 건지 알 수 없는 파일이 폴더를 채운다
정보관리에서는 이렇게 쌓인 중복·만료·사소한 파일을 ROT 문서(Redundant·Obsolete·Trivial)라고 부릅니다. 정리하는 사람은 ‘문서가 너무 많아서’가 아니라 ‘정본이 어디인지 몰라서’ 시간을 잃습니다.
파일명을 고치기 전에 네 가지를 정합니다
최신본은 ‘수정 시각이 가장 최근’으로 정하지 않습니다. 오래된 계약서가 여전히 유효할 수도 있고, 방금 수정된 파일이 승인 전 초안일 수도 있습니다. 최소한 네 가지를 함께 봅니다.
- 소유자 — 내용과 상태를 최종 확인할 역할
- 상태 — 초안·검토 중·승인·폐기 중 무엇인지
- 버전 또는 승인일 — 변경의 기준점
- 정본 위치 — 승인본을 찾는 단일 경로
개념 이미지: 파일명만으로 최신본을 추측하지 않도록 소유자, 상태, 날짜, 보관 위치를 함께 확인하는 기준입니다.
정본과 작업본이 만나는 규칙
작업 중인 문서는 공동 편집 공간에 두고, 승인된 문서는 정해진 폴더나 문서 상태로 확정합니다. 개인 PC와 메신저 첨부본은 정본이 아니라고 명시합니다. 파일명에는 팀이 실제로 유지할 수 있는 요소만 넣고, 자동 버전 기록이 있는 도구에서는 중복 번호 체계를 만들지 않습니다.
문서 정리를 RAG(검색형 AI) 도입 전에 한다면, AI가 최신본을 고르는 기준도 사람과 같아야 합니다. 리서치에서 정리된 6가지 원칙이 유용합니다.
- 같은 주제 파일이 여러 개면 ‘현재 기준(정본)‘을 표시하고 참고자료와 등급을 분리
- 작성일보다 실제 적용일자를 기록하고, 대체된 문서에는 ‘대체됨’과 새 문서 경로 표시
- 내용 관리 담당자를 명시하고 적용 대상(전 직원·부서·사업)을 구분
- 개인정보·인사·계약·비공개 자료는 공개 문서와 분리
_최종본류 이름 대신 문서 주제와 결론이 드러나는 제목- 근거가 없거나 담당자 확인이 필요한 질문을 문서에 명시 — AI가 멈춰야 할 조건
OnPress의 사내 검색이나 RAG가 최신본을 우선 보여주려면, 저장소가 커넥터·API를 제공하고 문서 상태·소유자·권한 메타데이터를 함께 전달해야 합니다. 검색 결과가 원본 권한을 넘지 않는지, 승인본과 초안을 구별하는지 작은 문서 묶음으로 시험해 봅니다. 메타데이터가 없는 폴더를 AI가 문맥만 보고 ‘최신본’으로 추정하게 해서는 안 됩니다.
5개 문서 찾기 시험으로 끝냅니다
규칙을 정한 뒤에는 개편 전후를 비교합니다. 서로 다른 직원에게 최근 견적서, 승인된 제안서, 유효한 양식 등 5개 문서를 찾게 합니다.
- 정답 문서 도달시간의 중앙값
- 잘못된 버전을 연 횟수
- 소유자에게 다시 물어본 횟수
- 정본 위치 밖에서 발견된 승인본 수
정답률(%) = 올바른 정본을 찾은 문서 수 ÷ 시험한 5개 문서 × 100
검색시간이 줄어도 잘못된 문서를 빨리 찾았다면 실패입니다. 정답률을 먼저 보고, 시간은 그다음에 봅니다.
오늘 가장 자주 쓰는 문서 하나에 소유자·상태·정본 위치를 붙여 보세요. Core Company는 그 한 건을 기준으로 현재 폴더를 버리지 않고도 적용할 수 있는 최소 규칙을 설계해 드리겠습니다.
계약·인사·개인정보 문서는 보존과 접근 기준이 다를 수 있으므로 최신 법령과 사내 정책을 확인해야 합니다.
CORE COMPANY / READINESS
이 기준을 우리 환경에 대입해 보세요
현재 운영 흐름을 먼저 확인하면 필요한 기술 범위를 줄일 수 있습니다.
출처
- 버전관리 없이 보고서를 작성한 신입사원 — 문서는 원래 움직이는 거야 (파수AI)
- 확인일
- 자료 유형
- 네이버 블로그
- 문서 파일의 버전 관리 방법 (assert13763)
- 확인일
- 자료 유형
- 네이버 블로그
- RAG 구축 전 문서 정리, 담당자가 먼저 해야 할 6가지 (루벤타)
- 확인일
- 자료 유형
- 네이버 블로그
변경 이력
| 날짜 | 변경 내용 | 검수자 |
|---|---|---|
| V11: 네이버 블로그 리서치 3건 기반 재작성 — 파일명 실패 시나리오와 ROT 문서 개념, RAG 전 문서 정리 6기준 적용 | 기술 책임자 |
작성과 검수
- 작성
- Core Company
- 기술 검토
- 기술 책임자 검토 대기
- AI 활용 공개
- 초안의 구조와 문장 정리에 AI 보조를 사용했으며, 공개 전 기술 책임자가 사실·적용 조건·연락 수단을 검토해야 합니다.