R&D 원자료 검토 체크리스트: 서명, 수정 이력, 계산값 재현성 확인

R&D 원자료 검토는 “자료가 많다”는 사실을 확인하는 일이 아니다. 실험노트, 장비 출력물, 엑셀 계산표, 분석 파일, 회의 기록, 사진, 코드 실행 로그가 서로 이어져서 같은 결론을 설명하는지 보는 일이다. 특히 과제 종료 직전에는 보고서 문장이 먼저 정리되고 원자료가 나중에 맞춰지는 흐름이 생기기 쉽다. 이때 검토자는 결과값의 타당성을 단정하기보다, 누가 언제 무엇을 만들었고 어떤 근거로 수정했으며 같은 입력값으로 계산을 다시 따라갈 수 있는지 확인해야 한다.

이 글은 연구자가 제출 전 스스로 확인하거나, 연구관리 담당자가 내부 검토 전에 빠르게 빈틈을 찾기 위한 체크리스트다. 법적 판단이나 감사 통과를 보장하는 문서가 아니라, 원자료의 설명력을 높이기 위한 실무형 점검 순서로 읽으면 된다. 핵심은 세 가지다. 첫째, 서명과 작성 주체가 기록의 책임을 설명하는가. 둘째, 수정 이력과 원본성이 남아 있어 자료 흐름을 되짚을 수 있는가. 셋째, 보고서의 계산값이 원자료와 같은 방식으로 재현되는가.

먼저 원자료 범위를 보고서 결론에서 역추적한다

원자료 검토를 폴더 목록부터 시작하면 빠진 자료를 놓치기 쉽다. 먼저 최종보고서나 중간보고서의 주요 결론, 성능 수치, 개발 단계, 시험 결과 표를 펼쳐 두고 “이 문장을 뒷받침하는 최초 기록은 무엇인가”를 역으로 적는다. 예를 들어 “시제품의 평균 응답시간이 1.8초로 단축되었다”는 문장은 측정 환경, 원시 로그, 제외 기준, 계산식, 비교 기준, 그래프 생성 파일이 함께 있어야 설명된다. 보고서 표 하나에 원자료 하나만 연결되는 경우보다, 원자료 묶음 하나가 여러 단계의 해석을 거쳐 표가 되는 경우가 많다.

검토 범위는 다음처럼 나누면 과도하게 넓어지지 않는다.

이 표에서 하나라도 “있을 것 같다”로 끝나면 검토 완료로 보지 않는 편이 안전하다. 파일이 존재한다는 사실과 기록이 설명 가능하다는 사실은 다르다. 원자료 범위표에는 파일 경로, 생성일, 작성자, 관련 보고서 문단, 검토 상태를 적어 두면 나중에 누락 논쟁을 줄일 수 있다.

서명은 이름보다 역할과 시점을 확인한다

서명 검토에서 흔한 실수는 이름 칸이 채워졌는지만 보는 것이다. 원자료의 서명은 “이 사람이 이 시점에 이 기록을 작성하거나 확인했다”는 연결고리다. 따라서 작성자 서명, 검토자 서명, 승인자 서명이 같은 의미로 섞이면 곤란하다. 연구노트 한 페이지에 연구자 이름이 있어도, 첨부된 장비 출력물이나 계산표를 누가 붙였는지 알 수 없다면 증빙력이 약해진다.

서면 기록은 페이지 번호, 작성일, 작성자, 확인자, 빈 공간 처리, 첨부 자료 표시를 함께 본다. 수정하거나 삭제한 부분은 원래 내용이 판독 가능해야 하고, 수정자와 수정일, 수정 사유가 남아야 한다. 전자 기록은 계정명, 전자서명, 생성 시각, 저장 시각, 접근 권한, 감사 추적 로그가 같은 사람의 실제 작업 흐름을 설명하는지 확인한다. 공용 계정으로 저장된 파일은 편해 보이지만, 나중에 작성 주체를 설명하기 어렵다.

검토 질문은 구체적이어야 한다. “서명 있음” 대신 “측정 담당자, 계산 검토자, 최종 보고서 반영자가 구분되는가”라고 묻는다. “날짜 있음” 대신 “실험 수행일, 파일 생성일, 검토일, 보고서 반영일이 시간순으로 맞는가”라고 묻는다. 같은 날짜에 모든 서명이 몰려 있거나, 보고서 작성 이후에 원자료가 처음 생성된 것처럼 보이면 추가 설명이 필요하다.

수정 이력은 틀린 값을 숨기는 장치가 아니라 판단 과정을 보존하는 장치다

R&D 과정에서 값이 바뀌는 것은 자연스럽다. 문제는 값이 바뀌었다는 사실보다 왜 바뀌었는지 남아 있지 않은 경우다. 장비 설정을 바꿨는지, 시료 조건을 다시 잡았는지, 이상치를 제외했는지, 단위 환산 오류를 고쳤는지에 따라 결과 해석이 달라진다. 수정 이력은 연구자가 실수를 인정하지 않기 위한 방어 문서가 아니라, 어떤 판단을 거쳐 최종값에 도달했는지 보여주는 작업 기록이다.

엑셀 파일은 특히 주의가 필요하다. 최종본 하나만 남기면 수식 변경, 행 삭제, 기준값 변경을 확인하기 어렵다. 파일명을 final, final2, real_final처럼 늘리는 방식도 충분하지 않다. 최소한 버전표에는 변경일, 변경자, 변경 범위, 변경 사유, 영향을 받는 보고서 표를 적어야 한다. 수식 셀을 값으로 붙여 넣은 경우에는 원래 수식 파일이나 계산 절차를 별도로 보존해야 한다. 외부에서 받은 시험성적서나 분석 결과를 내부 계산표로 옮긴 경우에는 전사 과정에서 숫자가 바뀌지 않았는지도 샘플링 검토한다.

전자 장비나 분석 소프트웨어에서 나온 자료는 원본 파일, 메타데이터, 감사 추적, 처리 조건을 함께 봐야 한다. PDF 출력물만 남아 있으면 사람이 보기에는 편하지만, 재처리 조건이나 삭제된 실행 기록을 확인하지 못할 수 있다. 원본 시스템을 더 이상 유지할 수 없는 상황이라면, 어떤 시점에 어떤 방식으로 진본 사본을 만들었고 어떤 정보가 포함되었는지 문서화해야 한다. 이 부분은 기관의 내부 규정과 시스템 환경에 맞춰 판단해야 하며, 단순히 PDF가 있다는 이유만으로 충분하다고 단정하지 않는다.

계산값 재현성은 “같은 숫자”보다 “같은 경로”를 확인한다

계산값 재현성 검토의 목표는 검토자가 연구 전체를 다시 수행하는 것이 아니다. 같은 입력 자료, 같은 제외 기준, 같은 계산식, 같은 반올림 규칙을 적용했을 때 보고서의 핵심 숫자가 설명되는지 보는 것이다. 따라서 모든 셀을 다시 계산하기보다 영향이 큰 지표부터 표본을 잡는다. 과제 성과를 대표하는 KPI, 전년 대비 개선율, 목표 대비 달성률, 평균·표준편차, 민감도 분석, 원가 절감액처럼 의사결정에 쓰인 숫자가 우선이다.

재현성 검토는 네 단계로 진행하면 효율적이다.

1. 보고서의 핵심 숫자 5~10개를 고른다.

2. 각 숫자의 원자료 파일, 처리 파일, 결과 표 위치를 연결한다.

3. 계산식과 제외 기준을 별도 칸에 적고 실제 파일에서 다시 계산한다.

4. 차이가 있으면 반올림, 단위, 버전, 필터, 누락 행, 수식 범위를 순서대로 확인한다.

예를 들어 시험 반복 30회 중 2회를 제외했다면 제외 기준이 사전에 정해졌는지, 제외 전 원자료가 남아 있는지, 제외 후 평균만 보고서에 들어갔는지 확인한다. 코드로 계산한 경우에는 실행 환경, 입력 파일 해시나 버전, 주요 파라미터, 결과 저장 위치가 있어야 한다. 사람이 수기로 옮긴 값은 표본 추적을 한다. 원자료 10개 중 1개를 골라 보고서 표까지 따라가 보는 방식만으로도 단위 오류나 잘못된 행 참조를 찾는 경우가 많다.

체크리스트: 제출 전 30분 안에 보는 핵심 항목

아래 체크리스트는 모든 기관 규정을 대체하지 않는다. 내부 연구노트 규정, 과제 협약, 보안 규정, 개인정보·영업비밀 처리 기준이 있으면 그 기준을 우선 적용한다. 다만 원자료 묶음이 보고서 결론을 설명하는지 빠르게 보려면 다음 항목을 순서대로 확인한다.

• 보고서의 핵심 주장마다 최초 원자료와 처리 파일이 연결되어 있다.
• 연구노트 또는 실험 기록에 작성자, 작성일, 확인자 역할이 구분되어 있다.
• 첨부 자료에는 출처, 생성일, 관련 실험 번호나 샘플 번호가 표시되어 있다.
• 수정·삭제 흔적은 원래 내용을 알아볼 수 있고 수정 사유가 남아 있다.
• 전자 파일은 공용 계정이 아니라 작업자 식별이 가능한 계정 또는 관리 절차로 설명된다.
• 최종본만 남긴 계산표는 원본 입력값, 수식, 버전 변경 사유를 별도로 보존한다.
• 보고서 표의 핵심 숫자는 원자료에서 같은 계산식으로 다시 산출된다.
• 반올림, 단위 변환, 제외 기준, 필터 적용 여부가 문서화되어 있다.
• 외부 시험·분석 자료는 내부 계산표로 옮겨지는 과정에서 샘플링 대조가 끝났다.
• 원본 파일을 대체한 사본은 메타데이터와 이력 보존 범위를 설명할 수 있다.
• 검토 의견과 보완 조치가 별도 기록으로 남아 있다.
• 보완 후 다시 확인한 사람과 날짜가 기록되어 있다.

이 목록에서 중요한 것은 “예/아니오”보다 “아니오일 때 어떤 보완이 가능한가”다. 예를 들어 서명이 빠진 과거 기록을 나중에 임의로 고치는 것은 더 큰 문제를 만들 수 있다. 그 대신 누락 사실, 확인 가능한 보조 자료, 보완 검토 의견, 향후 재발 방지 절차를 분리해 남기는 편이 낫다. 수정 이력이 없는 파일도 무조건 폐기할 것이 아니라, 백업본·메일 첨부·장비 로그·버전 관리 기록 등 주변 증거로 흐름을 재구성할 수 있는지 살핀다.

담당자별로 보는 관점이 달라야 한다

연구자는 실험의 맥락을 가장 잘 알지만, 익숙한 생략을 발견하기 어렵다. 연구관리 담당자는 형식 누락을 잘 찾지만, 계산식의 연구적 의미를 놓칠 수 있다. 그래서 원자료 검토는 역할별 질문을 나눠야 한다. 연구자는 “제3자가 이 기록만 보고 실험 조건을 이해할 수 있는가”를 본다. 연구관리 담당자는 “보고서 결론과 증빙 자료가 연결되는가”를 본다. 검토자는 “수정·재계산·전사 과정에서 책임과 이유가 남았는가”를 본다.

팀 단위 검토에서는 책임자를 몰아세우는 방식보다 결함 유형을 분류하는 방식이 효과적이다. 단순 누락, 파일명 혼선, 계산식 오류, 원본성 설명 부족, 접근 권한 문제, 외부 자료 전사 오류처럼 유형을 나누면 재발 방지 조치를 만들기 쉽다. 같은 문제가 여러 과제에서 반복된다면 개인 실수보다 양식, 폴더 구조, 교육, 승인 흐름의 문제일 가능성이 크다.

보완 기록은 원자료를 다시 꾸미지 않고 별도로 남긴다

원자료 검토에서 누락을 발견했을 때 가장 피해야 할 대응은 과거 기록을 지금 작성한 것처럼 보이게 만드는 것이다. 서명이 빠졌다고 해서 당시 작성일로 새 서명을 넣거나, 수정 이력이 없는 계산표를 조용히 덮어쓰거나, 보고서 숫자와 맞지 않는 원본 파일을 삭제하면 문제의 성격이 바뀐다. 검토의 목적은 흠을 없애는 것이 아니라 현재 설명 가능한 범위와 설명이 부족한 범위를 분리하는 데 있다.

보완 기록은 원자료와 같은 폴더에 섞어 두기보다 review-note, clarification, calculation-recheck처럼 성격이 드러나는 이름으로 분리한다. 보완 기록에는 발견일, 발견자, 원자료 위치, 차이 내용, 확인한 보조 자료, 보완 판단, 후속 조치를 적는다. 예를 들어 장비 원본 파일의 생성자는 확인되지만 연구노트 첨부 표시가 빠진 경우라면, “원자료 첨부 표시 누락”으로 남기고 장비 로그, 실험일지, 파일 생성 시각이 서로 맞는지 확인한 내용을 적는다. 계산표의 평균값이 보고서와 다르면 원본을 덮어쓰지 말고, 기존 파일을 보존한 뒤 재계산 파일과 차이 사유를 별도로 남긴다.

이 방식은 자료를 약하게 만드는 것이 아니라 오히려 검토 가능성을 높인다. 나중에 다른 사람이 같은 폴더를 열었을 때 “어떤 문제가 있었고 어떻게 확인했는지”를 볼 수 있기 때문이다. 특히 공동 연구, 외부 시험기관 자료, 퇴사자 작성 파일처럼 작성자에게 바로 물어보기 어려운 자료일수록 보완 기록의 형식이 중요하다. 원자료의 원래 상태, 보완 판단, 최종 보고서 반영 여부가 구분되어야 같은 문제가 다시 생겼을 때 원인을 찾을 수 있다.

보완 후에는 체크리스트의 상태값도 단순히 완료로 바꾸지 않는다. 원본 확인, 보조 자료로 설명, 재계산 완료, 추가 설명 필요, 내부 규정 확인 필요처럼 상태를 나누면 남은 위험이 보인다. 모든 항목을 억지로 초록색으로 만들 필요는 없다. 제출 전 검토에서 더 중요한 것은 빨간 항목을 숨기지 않고, 왜 빨간지와 어떤 근거까지 확인했는지를 남기는 일이다.

내부 링크로 이어질 독자 경로

이 글을 읽은 독자는 원자료 검토 후 바로 보완 작업으로 넘어가야 한다. 같은 사이트 안에서는 다음 흐름의 내부 링크가 자연스럽다.

• /guide/rnd-research-note-writing-basics: 연구노트 작성 기본 원칙과 누락 방지 양식
• /guide/rnd-evidence-folder-structure: R&D 증빙 폴더 구조와 파일명 규칙
• /guide/rnd-cost-evidence-checklist: 연구개발비 증빙과 원자료 연결 체크
• /guide/rnd-final-report-data-table-review: 최종보고서 표·그래프 숫자 검토 절차
• /guide/rnd-project-closeout-document-pack: 과제 종료 전 문서 패키지 정리 순서

내부 링크는 순서가 중요하다. 이 글에서 문제를 발견한 독자는 먼저 연구노트 작성 원칙으로 보완 기준을 확인하고, 그다음 폴더 구조와 비용 증빙, 최종보고서 표 검토로 이동하는 흐름이 좋다. 반대로 과제 종료 문서 패키지 글에서는 이 글을 “원자료 신뢰성 최종 점검” 단계로 연결하면 된다.

마무리: 원자료 검토의 결론은 “충분함”보다 “설명 가능함”이다

R&D 원자료는 완벽한 기록을 요구받기보다, 연구 과정과 결과 해석을 설명할 수 있어야 한다. 서명은 책임 주체와 시점을 보여주고, 수정 이력은 판단의 변화를 보존하며, 계산값 재현성은 보고서 숫자가 원자료에서 나온 것임을 확인한다. 이 세 가지가 연결되면 자료가 많지 않아도 검토자가 따라갈 수 있다. 반대로 자료가 많아도 작성자, 변경 이유, 계산 경로가 끊기면 결론의 신뢰도는 낮아진다.

제출 전에는 보고서의 핵심 숫자부터 거꾸로 추적해 보자. 누가 만들었는지, 언제 고쳤는지, 같은 방식으로 다시 계산되는지 답할 수 있으면 원자료 묶음은 한 단계 단단해진다. 답이 막히는 지점은 실패가 아니라 보완 지점이다. 그 지점을 지금 표시해 두는 것이 과제 종료 후 뒤늦게 자료를 맞추는 것보다 훨씬 낫다.

마지막으로 검토 결과를 한 문장으로 남길 때도 표현을 조심한다. “문제없음”보다는 “보고서 핵심 수치 8개 중 7개는 원자료와 계산 경로가 확인되었고, 1개는 외부 시험자료 전사 확인이 추가 필요함”처럼 범위와 남은 일을 함께 적는다. 이렇게 적어야 다음 담당자가 같은 자료를 다시 볼 때 검토의 수준을 이해할 수 있다. 원자료 검토는 결론을 꾸미는 단계가 아니라, 결론이 어디까지 근거로 설명되는지 선을 긋는 단계다. 그 선이 명확할수록 연구팀은 보완할 일을 빨리 찾고, 관리자는 제출 전 위험을 더 현실적으로 판단할 수 있다.

검토 회의에서는 이 문장을 기준으로 역할을 배분하면 된다. 연구자는 남은 원자료를 찾고, 계산 담당자는 재현이 막힌 수식을 확인하며, 관리 담당자는 보완 기록과 제출 문서의 연결 상태를 정리한다. 각자 같은 체크리스트를 보되 판단 기준을 공유하면, 자료 정리는 단순 취합이 아니라 보고서 결론을 설명하는 검증 흐름이 된다. 이 흐름을 과제 종료 직전에 한 번만 쓰지 말고 중간 점검 때 반복하면, 누락은 작을 때 발견되고 수정 이유도 자연스럽게 남는다. 결국 좋은 원자료 검토는 책임을 묻기 위한 절차가 아니라, 연구 결과를 설명할 수 있는 기록의 길을 남기는 절차다. 이 기준이면 충분하다.

Sources For Editor Review

• U.S. FDA, "Data Integrity and Compliance With Drug CGMP: Questions and Answers", accessed 2026-07-03.
• UK MHRA, "'GXP' Data Integrity Guidance and Definitions", accessed 2026-07-03.
• WHO, "Guideline on data integrity", accessed 2026-07-03.
• 국가법령정보센터, "연구노트 지침", accessed 2026-07-03.
• K-MELLODDY, "연구수행과정 및 연구개발성과의 작성･기록･관리 등 안내", accessed 2026-07-03.
• 서울대학교 산학협력단, "연구노트 작성·관리 매뉴얼", accessed 2026-07-03.