R&D 보관문서 인덱스 체크리스트: 보존기간, 위치, 열람권한 기록

R&D 보관문서 인덱스는 파일 목록을 예쁘게 정리하는 표가 아니라, 나중에 누가 어떤 근거를 찾아야 할 때 같은 문서를 같은 기준으로 다시 꺼낼 수 있게 만드는 운영 장치다. 연구노트, 시험 원자료, 설계 변경 기록, 시료 인수인계, 과제비 증빙, 외부기관 제출본은 모두 만들어진 순간에는 담당자가 기억한다. 문제는 과제가 닫히고 팀원이 바뀌고 저장소가 개편된 뒤다. 이때 인덱스에 보존기간, 보관 위치, 열람권한, 원본 여부, 폐기 보류 사유가 없으면 “문서가 있다”는 사실만 남고 “쓸 수 있는 문서인지”는 다시 조사해야 한다.

이 글의 기준은 간단하다. R&D 보관문서마다 최소한의 색인 필드를 정해 두고, 보존기간은 하나의 숫자로 단정하지 않으며, 열람권한은 직책명이 아니라 실제 접근 조건으로 남긴다. 공공기록물, 정부과제, GLP, 해외 보조금, 세액공제, 품질문서처럼 적용 기준이 서로 다른 영역이 섞일 수 있으므로 이 체크리스트는 법률 자문이나 심사 통과 보장이 아니다. 대신 연구조직이 보관문서를 검토할 때 빠뜨리기 쉬운 항목을 한 줄씩 확인할 수 있는 실무용 틀이다.

R&D 보관문서 인덱스는 보존기간표보다 먼저 문서의 쓰임을 묻는다

보존기간을 먼저 적기 시작하면 표가 금방 막힌다. 같은 “시험성적서”라도 내부 검토용 초안, 고객 제출본, 인증기관 제출본, 규제 제출 근거, 장비 교정과 연결된 원자료의 의미가 다르기 때문이다. 따라서 첫 열은 보존연수가 아니라 문서군과 쓰임이어야 한다. 문서군은 연구기획, 설계입력, 시험수행, 원자료, 품질검토, 대외제출, 비용증빙, 계약 및 권리, 폐기 또는 이관 기록처럼 과제 흐름으로 나누는 편이 좋다.

두 번째로 봐야 할 것은 “나중에 이 문서를 찾는 사람의 질문”이다. 연구책임자는 왜 이 결론을 냈는지 묻고, 품질 담당자는 어떤 버전이 승인본인지 묻고, 재무 담당자는 비용과 과제 활동이 연결되는지 묻고, 외부기관은 제출 당시의 근거가 보존되어 있는지 묻는다. 인덱스가 이 질문을 받아낼 수 있어야 한다. 파일명, 폴더 경로, 담당자 이름만 있는 목록은 담당자가 떠나는 순간 검색 힌트가 사라진다.

실무에서는 문서별로 다음 다섯 가지를 먼저 채운다. 문서가 증명하는 사실, 연결되는 과제 또는 제품, 원본이 존재하는 장소, 변경되면 안 되는 기준일, 외부 요청이 들어왔을 때 공개 가능한 범위다. 이 다섯 칸을 채운 뒤에야 보존기간과 열람권한을 넣어도 의미가 생긴다.

보존기간은 기본값, 예외, 기산일을 따로 기록한다

보존기간 칸에는 “5년”처럼 숫자만 넣지 않는다. 최소한 `기본 보존기간`, `기산일`, `연장 사유`, `폐기 가능 조건`을 분리해야 한다. 공공기록물 관리 기준처럼 보존기간을 영구, 준영구, 30년, 10년, 5년, 3년, 1년으로 구분하는 체계도 있고, 보조금이나 연구비 기록처럼 최종 재무보고 제출일 이후 일정 기간을 요구하는 체계도 있다. R&D 세액공제나 해외 과제의 경우에는 비용 증빙과 기술 활동 증빙이 함께 필요할 수 있다. 그래서 숫자 하나를 조직 공통 규칙처럼 복사하면 위험하다.

기산일은 특히 중요하다. “과제 종료일”과 “최종보고서 제출일”, “최종 재무보고 제출일”, “제품 허가일”, “분쟁 종료일”, “장비 처분일”은 서로 다르다. 인덱스에서 기산일 근거가 빠지면 보존기간이 끝났는지 판단할 수 없다. 예를 들어 정부지원 과제의 회계 증빙은 최종 정산 또는 최종보고와 연결될 수 있고, 장비나 시료 기록은 처분 또는 반환과 연결될 수 있다. 특허, 분쟁, 감사, 규제 질의가 걸린 문서는 원래 보존기간이 지났더라도 보류 대상이 될 수 있다.

보존기간 칸의 추천 형식은 다음과 같다.

이 표는 보존기간을 늘리라는 뜻이 아니다. 무기한 보관도 비용과 보안 위험을 만든다. 핵심은 “왜 아직 보관하는지”와 “언제 다시 판단할지”를 인덱스 안에 남기는 것이다.

위치 기록은 폴더명이 아니라 원본성, 매체, 복구 경로까지 포함한다

문서 위치는 `공유드라이브/R&D/완료`처럼 적으면 부족하다. 실제로 찾을 때 필요한 것은 원본 위치, 열람용 사본 위치, 백업 위치, 물리 보관 위치, 시스템 식별자다. 전자기록은 파일 포맷과 시스템 의존성도 함께 봐야 한다. 장기보존이 필요한 전자기록은 시간이 지나도 재현 가능한 포맷과 메타데이터가 중요하고, 손상되었거나 암호화되어 읽을 수 없는 파일은 그 사유 자체가 이력으로 남아야 한다.

R&D 조직에서 자주 생기는 오류는 “최종본”이라는 폴더가 여러 개 생기는 것이다. 품질팀의 최종본, 연구팀의 최종본, 외부기관 제출본, 고객 전달본이 서로 다른 파일일 수 있다. 인덱스에는 `원본성`을 별도 필드로 둔다. 승인 원본, 제출본, 열람 사본, 변환본, 스캔본, 백업본처럼 구분하면 나중에 잘못된 사본을 근거로 쓰는 일을 줄일 수 있다.

물리 문서도 같은 기준이 필요하다. 실험실 캐비닛, 문서고 박스, 외부 보관업체, 냉동 시료 보관함, 장비 로그북 위치가 따로 흩어지면 인덱스가 없을 때 담당자 기억에 의존한다. 위치 필드는 `보관 단위`, `상세 위치`, `식별 코드`, `반출 가능 여부`, `반출 기록 위치`로 쪼개는 편이 안전하다. 박스 번호만 있고 문서군이나 과제 코드가 없으면 박스를 열어야만 확인할 수 있고, 반대로 파일명만 있고 시스템 문서번호가 없으면 권한 이관 때 누락된다.

전자 파일의 위치 기록에는 최소 네 가지를 남긴다. 저장소 이름, 시스템 문서번호 또는 영구 링크, 파일 포맷, 마지막 무결성 확인일이다. 해시값까지 운영하지 않더라도, 적어도 “2026-07-03 기준 열람 가능 확인”처럼 확인 흔적을 남기면 이관 후 깨진 링크를 빨리 발견할 수 있다.

열람권한 기록은 직책보다 목적, 범위, 승인 조건을 적는다

열람권한은 “연구팀 가능, 외부 불가”처럼 적으면 실제 운영에서 흔들린다. 같은 연구팀이라도 프로젝트 멤버, 부서장, 품질검토자, 정보보호 담당자, 외부 감사 대응자에게 필요한 범위가 다르다. 개인정보, 영업비밀, 미공개 특허, 계약상 비밀유지 정보, 임상 또는 인체유래 데이터가 섞이면 단순한 팀 권한으로 처리하기 어렵다.

인덱스에는 `열람 목적`, `기본 권한`, `승인 필요 조건`, `마스킹 필요 여부`, `외부 제공 가능 범위`, `접근 로그 위치`를 둔다. 예를 들어 원자료는 연구책임자와 품질 담당자가 볼 수 있지만 외부기관 제출 시에는 개인정보와 영업비밀을 분리해야 할 수 있다. 계약서와 공동연구 결과물은 내부 검토용 권한과 파트너 제공 가능 범위가 다를 수 있다. 열람권한을 이렇게 적어 두면 “누가 볼 수 있나”보다 “어떤 목적으로 어디까지 볼 수 있나”를 판단할 수 있다.

권한 기록에서 피해야 할 표현은 “필요시 공개”, “관리자 승인”, “관계자 열람”이다. 모두 실제 승인 기준을 숨긴다. 대신 `과제 종료 후 외부기관 현장점검 시 품질책임자 승인 하에 열람`, `공동연구기관에는 제출본 PDF만 제공`, `원자료 다운로드는 금지하고 열람 로그 저장`처럼 조건을 적는다. 이렇게 써도 완전한 통제나 감사 통과를 보장하지는 않는다. 다만 나중에 권한 판단을 반복할 때 기준을 남긴다는 점에서 인덱스의 가치가 생긴다.

보관문서 인덱스 체크리스트 12개 항목

아래 항목은 새 저장소를 만들기 전, 이미 쌓인 완료 과제 폴더를 정리할 때 먼저 적용하기 좋다.

이 12개 항목을 모두 복잡한 시스템에 넣을 필요는 없다. 작은 팀이라면 스프레드시트로 시작해도 된다. 다만 파일명, 경로, 담당자만 있는 목록은 인덱스가 아니라 찾기 보조표에 가깝다. 보존기간과 위치, 열람권한을 판단할 수 있어야 보관문서 인덱스라고 부를 수 있다.

완료 과제 폴더를 정리할 때는 문서별이 아니라 질문별로 샘플링한다

이미 수백 개의 폴더가 있다면 처음부터 전수 정리하려고 하지 않는 편이 낫다. 먼저 최근 완료 과제 3개와 오래된 과제 2개를 고른다. 그리고 문서별 목록을 만드는 대신 질문별로 샘플링한다. “최종보고서 근거 원자료를 10분 안에 찾을 수 있는가”, “외부 제출본과 내부 승인본이 구분되는가”, “보존기간이 끝난 문서와 보류 문서를 구분할 수 있는가”, “외부 열람 요청이 오면 제공 가능 범위를 판단할 수 있는가”를 시험한다.

이 샘플링에서 막힌 지점이 인덱스 필드의 우선순위다. 원자료를 못 찾으면 위치와 원본성 필드가 먼저이고, 폐기 판단이 안 되면 보존기간과 기산일 필드가 먼저이며, 외부 제공 범위가 불명확하면 열람권한과 민감정보 필드가 먼저다. 이렇게 시작하면 조직에 필요 없는 칸을 줄이고, 실제로 문제가 난 부분부터 고칠 수 있다.

정리 과정에서는 담당자에게 “이 문서가 왜 필요한가”를 묻는 짧은 메모를 남기는 것이 좋다. 예를 들어 `TRL 5 검증 회의에서 성능 기준을 확정한 근거`, `공급사 변경 전 원재료 사양 비교`, `정부과제 최종보고 수치의 원자료`처럼 한 줄 설명이 있으면 이후 검색과 권한 판단이 훨씬 쉬워진다.

같은 사이트에서 이어 읽을 내부 링크 계획

이 초안은 rndatlas.com 안에서 보관문서와 증거 추적성 클러스터로 연결하는 편이 자연스럽다. 먼저 [/guide/rnd-data-retention-archive-checklist](/guide/rnd-data-retention-archive-checklist)는 보존기간과 아카이브 운영 기준을 더 넓게 설명하는 상위 글로 연결한다. [/guide/rnd-evidence-traceability-matrix-checklist](/guide/rnd-evidence-traceability-matrix-checklist)는 문서가 어떤 주장과 결정을 뒷받침하는지 추적하는 다음 단계로 배치한다. [/guide/rnd-final-report-evidence-checklist](/guide/rnd-final-report-evidence-checklist)는 최종보고서 제출 전 근거 묶음을 확인하는 실무 흐름과 연결한다. 마지막으로 [/guide/rnd-lab-notebook-evidence-checklist](/guide/rnd-lab-notebook-evidence-checklist)는 연구노트와 원자료가 인덱스에서 어떻게 분리되어야 하는지 설명하는 보조 링크로 둔다.

내부 링크의 목적은 검색 순위를 약속하는 것이 아니라 독자의 다음 작업을 줄이는 것이다. 이 글을 읽은 사람이 “우리 문서 목록에 어떤 칸을 추가해야 하는가”를 정했다면, 다음 글에서는 “그 문서가 어떤 결론을 뒷받침하는가”와 “보고서 제출 전에 무엇을 묶어야 하는가”로 이동할 수 있어야 한다.

마지막 점검: 인덱스는 보관함이 아니라 재현 가능한 설명이다

R&D 보관문서 인덱스가 잘 작동하는지 보려면 한 가지 질문을 던지면 된다. 담당자가 없어도, 1년 뒤에도, 다른 부서가 봐도 이 문서의 보존기간과 위치와 열람조건을 같은 방식으로 판단할 수 있는가. 그렇다면 인덱스는 제 역할을 하고 있다. 반대로 담당자에게 물어봐야만 알 수 있거나, 폴더를 열어 하나씩 확인해야 하거나, 권한 요청 때마다 새로 논의해야 한다면 아직 목록 수준에 머물러 있다.

처음부터 완벽한 기록관리 체계를 만들 필요는 없다. 다만 완료 과제가 늘어날수록 작은 누락은 찾기 비용, 권한 혼선, 폐기 보류, 제출 지연으로 커진다. 이번 점검에서는 보존기간 숫자를 채우는 데서 멈추지 말고, 기산일과 예외를 분리하고, 위치를 원본성과 매체까지 나누고, 열람권한을 목적과 범위로 기록해 보자. 그 세 가지가 들어가면 R&D 보관문서 인덱스는 단순한 파일 목록에서 나중에 설명 가능한 근거 체계로 바뀐다.