R&D 감사 대응 증거자료 체크리스트: 질문 로그, 근거 문서, 후속 조치

**빠른 결론**

R&D 감사 대응 증거자료 체크리스트의 핵심은 “자료가 어디 있는가”가 아니라 “감사 질문이 어떤 근거로 답변됐고, 남은 후속 조치가 언제 누구에 의해 닫혔는가”입니다. 질문 로그, 근거 문서 ID, 판단 기준, 증거 소유자, 전자기록 감사추적, CAPA 또는 변경관리 링크, 재제출 상태를 한 줄로 묶어야 내부 감사와 외부 심사 모두에서 같은 설명을 반복하지 않습니다.

R&D 감사가 시작되면 많은 조직이 먼저 폴더를 정리합니다. 시험성적서, 회의록, 요구사항표, 변경요청서, 설계 산출물, 연구노트, 지출 증빙을 한곳에 모으는 일은 필요합니다. 그러나 감사 현장에서 실제로 문제가 되는 지점은 폴더의 양이 아니라 답변의 추적성입니다. 감사인이 “이 시험은 어떤 요구사항을 확인했습니까”, “이 변경은 누가 승인했습니까”, “이 결함의 재발 방지 조치는 닫혔습니까”라고 물었을 때 담당자가 자료명을 외워서 답하면 위험합니다. 같은 질문이 다음 날 다른 감사인에게 다시 나오거나, 외부 심사에서 더 좁은 범위로 다시 제기되면 답변이 달라질 수 있기 때문입니다.

이 글은 R&D 내부/외부 감사 대응을 위한 증거자료 체크리스트를 다룹니다. 이미 다른 글에서 요구사항 추적 매트릭스, 최종보고 증빙, 데이터 보존, 품질경영 문서, 부적합 CAPA를 각각 다루었다면, 여기서는 그 문서들을 다시 설명하지 않습니다. 대신 감사 질문이 들어온 순간부터 답변 근거를 고르고, 근거 문서를 매핑하고, 미흡 사항을 후속 조치로 전환하고, 완료 증거까지 닫는 운영표를 제안합니다. 목표는 “감사 대응 파일을 많이 만든다”가 아니라 “질문 하나가 끝날 때마다 재현 가능한 답변 기록을 남긴다”입니다.

R&D 감사 대응은 질문 로그부터 시작해야 합니다

질문 로그는 회의록의 부속물이 아닙니다. 감사 대응의 원장입니다. ISO 19011은 경영시스템 감사에 대해 감사 원칙, 감사 프로그램 관리, 감사 수행 지침을 제공하는 표준이며, 2026년판은 기술, 디지털화, 가상 환경, 위험 분석과 완화의 중요성이 더 커진 환경을 반영합니다[S1]. 이 관점에서 감사 대응 로그는 단순 질의응답 메모가 아니라 감사 기준과 감사 증거를 연결하는 작업대가 됩니다. 감사 질문이 공식 부적합으로 이어지지 않았더라도, 질문이 반복되거나 보류된 근거가 있다면 추적할 수 있어야 합니다.

질문 로그에는 최소한 일곱 가지가 필요합니다. 첫째, 질문 ID입니다. `AUD-Q-2026-014`처럼 한 번 부여하면 바꾸지 않는 식별자가 있어야 합니다. 둘째, 질문 원문입니다. 담당자가 해석한 문장만 남기면 나중에 감사인의 의도가 바뀐 것처럼 보일 수 있습니다. 셋째, 감사 기준입니다. ISO 9001 절차, 내부 SOP, 계약 조항, 규제 요구사항, 연구개발 협약, 시험계획서 중 무엇을 기준으로 묻는지 적어야 합니다. 넷째, 답변 요지입니다. 다섯째, 근거 문서 ID입니다. 여섯째, 후속 조치 여부입니다. 일곱째, 상태값입니다. 상태값은 `answered`, `evidence_requested`, `pending_owner`, `follow_up_open`, `resubmitted`, `closed`, `withdrawn`처럼 제한된 값으로 관리해야 합니다.

질문 로그에서 가장 흔한 실패는 “답변 완료”와 “감사상 종료”를 같은 뜻으로 쓰는 것입니다. 담당자가 말로 설명했더라도 근거 문서가 제출되지 않았거나, 제출했더라도 감사인이 추가 자료를 요구했다면 종료가 아닙니다. 외부 인증심사나 규제 대응뿐 아니라 내부 감사에서도 같은 문제가 생깁니다. 질문에는 답했지만 근거 문서가 누락된 상태, 자료는 냈지만 CAPA가 열려 있는 상태, CAPA는 열렸지만 효과성 확인이 끝나지 않은 상태를 모두 구분해야 합니다. 질문 로그는 이런 중간 상태를 숨기지 않고 드러내는 표여야 합니다.

근거 문서는 파일명이 아니라 판단 기준과 연결해야 합니다

ISO의 ISO 9001 문서화 정보 안내는 조직이 필요한 문서화 정보의 양을 스스로 정하되, 계획, 운영, 통제, 개선이 실제로 수행됐음을 입증할 수 있어야 한다는 관점을 제시합니다[S2]. R&D 감사 대응에서도 같은 원리가 적용됩니다. “시험결과.pdf”라는 파일은 증거가 될 수 있지만, 그 자체로 충분한 답변은 아닙니다. 어떤 기준을 충족했는지, 어떤 시험 조건에서 생성됐는지, 어느 버전의 산출물에 적용됐는지, 누가 검토했는지가 함께 있어야 판단 근거가 됩니다.

근거 문서 매핑은 질문 로그의 하위 칸으로 두어도 되고 별도 표로 분리해도 됩니다. 중요한 것은 감사 질문 하나에 여러 증거가 붙을 수 있다는 점입니다. 예를 들어 “센서 모듈 변경 후 성능 영향평가를 했는가”라는 질문에는 변경요청서, 영향평가 회의록, 시험계획서, 시험결과, 결함 이슈, 승인 기록이 함께 필요합니다. 이때 파일을 한 번에 제출하는 것보다 각 문서가 어떤 판단을 지지하는지 나눠야 합니다. 변경요청서는 변경 사유를 설명하고, 영향평가는 범위 판단을 설명하고, 시험결과는 검증을 설명하고, 승인 기록은 책임 있는 의사결정을 설명합니다.

근거 문서 매핑의 최소 단위는 `evidence_id`, `document_type`, `source_system`, `version_or_timestamp`, `supports_claim`, `review_status`, `retention_location`, `access_note`입니다. 특히 `supports_claim`은 반드시 사람이 읽을 수 있는 문장이어야 합니다. “AUD-Q-014 답변 자료”라고 쓰면 충분하지 않습니다. “2026-05-18 변경요청 CR-021이 저전력 모드 열한계 때문에 응답시간 기준을 2초에서 3초로 조정했음을 설명한다”처럼 질문과 판단 사이의 다리를 써야 합니다. 이 한 문장이 있으면 감사 대응자가 바뀌어도 같은 근거를 같은 방식으로 설명할 수 있습니다.

**근거 문서 매핑표 예시**

<table>

<thead>

<tr><th>증거 ID</th><th>문서 유형</th><th>지지하는 판단</th><th>검토 상태</th></tr>

</thead>

<tbody>

<tr><td>EVD-014-01</td><td>변경요청서</td><td>변경 사유와 승인 범위를 확인합니다</td><td>reviewed</td></tr>

<tr><td>EVD-014-02</td><td>영향평가 회의록</td><td>성능, 안전, 일정 영향 범위를 확인합니다</td><td>reviewed</td></tr>

<tr><td>EVD-014-03</td><td>재시험 결과</td><td>변경 후 수용기준 충족 여부를 확인합니다</td><td>submitted</td></tr>

<tr><td>EVD-014-04</td><td>이슈 종료 기록</td><td>미해결 결함이 후속 조치로 닫혔는지 확인합니다</td><td>pending auditor response</td></tr>

</tbody>

</table>

근거 문서 매핑은 증거 추적 매트릭스와 비슷해 보이지만 목적이 다릅니다. 추적 매트릭스는 요구사항, 시험, 산출물의 관계를 관리합니다. 감사 대응 매핑은 질문, 답변, 제출 근거, 후속 조치의 관계를 관리합니다. 따라서 같은 시험결과가 두 표에 모두 등장할 수 있습니다. 추적 매트릭스에서는 “REQ-014를 TC-014가 검증했다”는 관계가 중요하고, 감사 대응표에서는 “AUD-Q-014에 대해 TC-014 결과를 제출했으며 감사인이 추가로 원시 로그를 요청했다”는 이력이 중요합니다.

전자기록은 감사추적과 접근권한까지 함께 봐야 합니다

R&D 증거자료가 전자기록으로 관리된다면 파일 원본만으로 충분하지 않은 경우가 많습니다. FDA 21 CFR Part 11은 적용 대상 전자기록에서 안전하고 컴퓨터가 생성한 시간기반 감사추적을 통해 생성, 수정, 삭제 행위의 날짜와 시간을 독립적으로 기록하도록 요구합니다[S3]. 모든 R&D 조직에 이 규정이 곧바로 법적 의무가 되는 것은 아닙니다. 그러나 전자기록 기반 감사 대응에서는 이 원리를 설계 기준으로 참고할 가치가 큽니다. 누가 언제 기록을 만들고 바꾸었는지, 변경 전 정보가 가려지지 않는지, 필요한 기간 동안 검토할 수 있는지가 감사 대응의 신뢰도를 좌우하기 때문입니다.

질문 로그에는 전자기록 증거에 대한 별도 표시가 필요합니다. `electronic_record=true`, `audit_trail_available=true`, `access_control_checked=true`, `export_format=pdf+csv+raw`, `hash_or_version=...` 같은 필드를 둘 수 있습니다. 감사인이 원본 시스템 접근을 요구하지 않더라도, 내부 대응자는 제출 자료가 원본에서 어떻게 추출됐는지 설명할 수 있어야 합니다. 화면 캡처만 제출한 경우에는 캡처 일시, 캡처자, 원본 시스템, 조회 조건, 원본 데이터 보존 위치를 남기는 편이 안전합니다. 캡처가 틀렸다는 뜻이 아니라, 캡처만으로는 재현성이 약할 수 있기 때문입니다.

NIST SP 800-92는 조직 전반에서 로그 관리 인프라와 강건한 로그 관리 프로세스를 개발하고 수행하는 실무 지침을 제공합니다[S8]. R&D 감사 대응에서는 보안 로그 자체를 모두 제출하라는 의미로 받아들이면 안 됩니다. 대신 원본 시스템, 접근권한, 로그 보존, 로그 검토 책임을 질문별 증거 관리에 반영해야 합니다. 예를 들어 시험 장비에서 나온 원시 로그, 분석 스크립트 실행 로그, 모델 학습 로그, 전자서명 로그, 파일 저장소 접근 로그는 서로 다른 위치에 있을 수 있습니다. 질문 로그가 이 위치를 연결하지 못하면 답변자는 “자료는 있습니다”라고 말하지만 검증자는 “그 자료가 원본인지 알 수 없습니다”라고 보게 됩니다.

전자기록 증거에서 특히 조심할 표현은 “최종본만 제출”입니다. 최종본은 필요하지만, 변경 이력이 쟁점인 질문에는 부족할 수 있습니다. 요구사항이 바뀌었는지, 시험 조건이 바뀌었는지, 결함이 재분류됐는지, 접근권한이 조정됐는지 묻는 질문에는 변경 전후 기록이 필요합니다. 감사 대응표에는 제출본, 원본 위치, 변경 이력 위치를 분리해 적어야 합니다. 이렇게 해야 최종본이 답변이고, 변경 이력이 그 답변의 신뢰 근거라는 구조가 보입니다.

후속 조치는 CAPA, 변경관리, 재제출을 구분해 닫습니다

감사 대응에서 후속 조치는 하나의 바구니가 아닙니다. ICH Q10은 의약품 품질시스템 맥락에서 공정 성능과 제품 품질 모니터링, CAPA, 변경관리, 경영검토를 핵심 요소로 제시하고, 감사와 규제 점검 결과에서 비롯된 시정 및 예방 조치를 구조적으로 조사하고 원인을 파악해야 한다고 설명합니다[S4]. 산업이 다르더라도 R&D 감사 대응에는 이 구분이 유용합니다. 모든 미흡 사항을 CAPA로 열 필요는 없지만, 모든 미흡 사항을 단순 재제출로 처리해서도 안 됩니다.

후속 조치는 먼저 네 갈래로 나눕니다. 첫째, 단순 보완입니다. 근거 문서는 이미 존재하지만 제출본에 누락된 경우입니다. 둘째, 설명 보완입니다. 문서는 있으나 판단 기준이나 연결 문장이 부족한 경우입니다. 셋째, 변경관리입니다. 요구사항, 시험조건, 산출물 버전, 승인 범위가 실제로 바뀐 경우입니다. 넷째, CAPA입니다. 절차 미준수, 반복 결함, 원인 분석 필요, 재발 방지 필요가 확인된 경우입니다. 이 네 가지를 구분하지 않으면 모든 조치가 “추가 자료 제출”로 보이고, 내부적으로는 실제 개선이 일어나지 않습니다.

후속 조치 표에는 `follow_up_type`, `root_cause_needed`, `action_owner`, `due_date`, `submitted_evidence`, `effectiveness_check`, `auditor_acceptance_status`를 둡니다. 특히 `auditor_acceptance_status`는 내부 완료와 외부 수용을 분리합니다. 내부적으로 자료를 냈더라도 감사인이 수용하지 않았으면 닫힌 것이 아닙니다. 반대로 감사인이 질문을 철회했더라도 내부적으로 절차 공백이 확인됐다면 개선 과제로 남길 수 있습니다. 감사 대응은 방어만을 위한 절차가 아니라 다음 감사에서 같은 질문을 줄이는 학습 절차가 되어야 합니다.

**후속 조치 분류에서 보류해야 할 신호**

• 근거 문서가 없는데 담당자 설명만으로 답변을 닫으려는 경우

• 시험 실패 또는 조건부 통과를 단순 재제출로 처리하려는 경우

• 변경관리 승인 전 자료를 최종 근거로 제출하려는 경우

• 동일 원인의 질문이 반복됐는데 CAPA 필요 여부를 검토하지 않은 경우

• 감사인이 수용했는지 확인하지 않고 내부 완료로만 닫은 경우

외부 감사와 내부 감사는 같은 표를 쓰되 공개 범위를 나눕니다

내부 감사 대응표와 외부 감사 제출표를 완전히 분리하면 나중에 설명이 달라질 수 있습니다. 반대로 내부 메모까지 외부에 그대로 제출하면 불필요한 위험이 생깁니다. 좋은 방식은 같은 질문 로그 원장을 쓰되 공개 범위를 나누는 것입니다. 내부 원장에는 원인 가설, 담당자 메모, 보류 사유, 내부 검토 의견까지 기록합니다. 외부 제출본에는 확정 답변, 제출 근거, 승인된 후속 조치, 완료 상태만 남깁니다. 원장은 하나이고 뷰가 두 개인 구조가 가장 안전합니다.

GAO Government Auditing Standards 2024 Revision은 정부 감사 맥락에서 2025년 12월 15일 이후 시작되는 여러 감사 유형에 적용되는 효력 시점을 제시하며, 품질관리에서 품질관리시스템으로 접근이 강화된 점을 설명합니다[S6]. 또한 감사인은 전문 기준과 다른 권위 있는 기준을 함께 사용할 수 있습니다[S6]. R&D 조직 입장에서는 감사인이 어떤 기준을 들고 오는지 미리 알 수 없다는 뜻입니다. 따라서 질문 로그의 `audit_criteria` 칸은 하나의 기준만 적는 고정 칸이 아니라 내부 절차, 외부 표준, 계약 요구사항, 법규 요구사항을 함께 기록할 수 있어야 합니다.

2 CFR 200.303은 미국 연방 보조금 맥락에서 수령자와 하위수령자가 효과적인 내부통제를 수립, 문서화, 유지해야 하며, 미준수 사례가 확인되면 신속한 조치를 취해야 한다고 규정합니다[S7]. 이 역시 모든 R&D 조직의 일반 법규로 확대하면 안 됩니다. 그러나 공공과제, 보조금, 공동연구, 외부 지원금을 다루는 조직에는 감사 대응표가 단순 자료 제출이 아니라 내부통제와 신속한 조치의 증거가 될 수 있다는 점을 보여줍니다. 질문 로그와 후속 조치 기록은 “우리가 대응했다”가 아니라 “우리가 통제하고 모니터링하고 조치했다”를 보여주는 기록입니다.

공개 범위를 나눌 때는 세 가지 표시를 둡니다. `internal_only`, `external_shareable`, `redaction_needed`입니다. 개인정보, 영업비밀, 미공개 특허, 보안 취약점, 공급사 계약 조건이 포함된 증거는 외부 제출 전에 비식별화나 요약본 전환이 필요할 수 있습니다. 그러나 이 표시가 근거를 숨기기 위한 장치가 되어서는 안 됩니다. 원장에는 원본 근거가 어디 있고, 외부 제출본에서는 무엇을 가렸으며, 누가 그 가림을 승인했는지 남겨야 합니다.

감사 대응 증거자료 체크리스트는 회의 후 24시간 안에 갱신합니다

감사 대응표는 감사 전날 한 번 만드는 문서가 아닙니다. 감사 회의가 끝난 뒤 24시간 안에 갱신해야 쓸모가 있습니다. 질문 원문은 기억이 흐려지기 전에 확정하고, 제출한 자료는 실제 제출본 기준으로 링크를 바꾸고, 보류 질문은 담당자와 기한을 배정합니다. 감사인이 회의 중 구두로 “이 정도면 됐다”고 말했더라도, 공식 종료 상태가 아니면 `closed`가 아니라 `verbal_no_further_question`처럼 별도 상태를 두는 편이 안전합니다.

24시간 갱신 순서는 단순해야 합니다. 먼저 질문을 확정합니다. 다음으로 답변 요지를 한 문장으로 씁니다. 그다음 제출한 증거 ID를 연결합니다. 이어서 부족한 증거를 후속 조치로 분류합니다. 마지막으로 다음 응답 기한과 수용 상태를 적습니다. 회의록을 예쁘게 다듬는 일보다 질문 로그를 닫는 일이 먼저입니다. 회의록은 전체 맥락을 남기지만 질문 로그는 감사 대응의 미완료 항목을 드러냅니다.

이 표에서 가장 중요한 칸은 “보류 사유”입니다. 보류 사유가 없으면 미완료 질문은 단순 지연처럼 보입니다. 그러나 보류 사유가 “원본 로그 추출 대기”, “공급사 확인 필요”, “변경관리 승인 전”, “CAPA 원인분석 진행 중”처럼 구체적이면 대응 우선순위를 정할 수 있습니다. 감사 대응에서 빠른 답변보다 중요한 것은 잘못 닫지 않는 것입니다. 특히 R&D는 불확실성과 변경이 많은 영역이므로, 확정되지 않은 결론을 확정처럼 제출하면 나중에 더 큰 수정이 필요합니다.

마감 전에는 샘플 질문으로 답변 경로를 걸어 봅니다

감사 대응표가 실제로 작동하는지는 샘플 질문으로 확인해야 합니다. 문서가 많아도 질문 하나를 끝까지 따라갈 수 없으면 표는 실패입니다. 샘플은 무작위로만 고르지 말고 위험 기반으로 고릅니다. 요구사항 변경, 시험 실패, 공급사 산출물, 전자기록 원본, 데이터 재분석, 비용과 산출물 연결, CAPA 종료 같은 항목을 포함합니다. GAO 기준이 강조하는 감사 품질과 충분한 근거의 사고방식을 조직 내부의 사전 점검으로 가져오는 것입니다[S6].

샘플 점검은 30분이면 충분합니다. 질문 하나를 고르고 원문을 읽습니다. 적용 기준을 확인합니다. 답변 요지를 읽습니다. 근거 문서 ID를 따라 원본 위치를 엽니다. 전자기록이면 감사추적 또는 버전 이력을 확인합니다. 후속 조치가 있다면 CAPA, 변경관리, 재제출 중 무엇인지 확인합니다. 마지막으로 내부 완료와 감사 수용 상태가 다르게 기록되어 있는지 봅니다. 이 과정을 세 질문에서 반복했을 때 막히는 지점이 같다면, 그 지점이 이번 감사 대응의 약한 고리입니다.

마감 전 체크리스트는 다음 열 가지로 정리할 수 있습니다. 첫째, 모든 질문에 고정 ID가 있는가. 둘째, 질문 원문과 내부 해석이 분리되어 있는가. 셋째, 감사 기준이 적혀 있는가. 넷째, 답변 요지가 한 문장으로 남아 있는가. 다섯째, 근거 문서가 판단 문장과 연결되어 있는가. 여섯째, 전자기록 증거의 원본 위치와 감사추적 가능성이 표시되어 있는가. 일곱째, 후속 조치 유형이 보완, 설명, 변경관리, CAPA로 구분되어 있는가. 여덟째, 담당자와 기한이 있는가. 아홉째, 내부 완료와 감사 수용 상태가 분리되어 있는가. 열째, 반복 질문과 절차 공백이 다음 개선 과제로 남았는가.

이 글의 체크리스트는 감사 합격이나 상위노출을 보장하지 않습니다. 대신 R&D 담당자가 감사 질문을 받았을 때 같은 답변을 같은 근거로 재현하도록 돕습니다. 요구사항과 시험의 관계는 [R&D evidence traceability matrix checklist](/guide/rnd-evidence-traceability-matrix-checklist)에서 더 깊게 보고, 과제 종료 제출물은 [정부 R&D 최종보고서 증빙 패키지 체크리스트](/guide/rnd-final-report-evidence-checklist)로 연결하면 됩니다. 데이터 보존과 접근권한은 [R&D 데이터 보존·아카이브 체크리스트](/guide/rnd-data-retention-archive-checklist), CAPA 분류는 [R&D 부적합 CAPA 체크리스트](/guide/rnd-nonconformance-capa-checklist)를 함께 보면 대응표의 빈칸을 줄일 수 있습니다.

감사 대응의 좋은 종료는 “질문이 없었다”가 아닙니다. 질문이 남긴 판단 근거와 후속 조치가 다음 프로젝트의 절차로 흡수되는 것입니다. 질문 로그가 닫히고, 근거 문서가 매핑되고, 후속 조치가 증거로 종료되면 감사는 방어 절차에서 학습 절차로 바뀝니다. 그때부터 증거자료 관리는 감사 때만 급히 찾는 파일 정리가 아니라 R&D 의사결정의 운영 기록이 됩니다.

R&D 감사 대응 증거자료 체크리스트 참고 출처

• [S1] [ISO 19011:2026 Guidelines for auditing management systems](https://www.iso.org/standard/19011)
• [S2] [ISO Guidance on the requirements for Documented Information of ISO 9001:2015](https://www.iso.org/iso/documented_information.pdf)
• [S3] [eCFR 21 CFR Part 11 Electronic Records; Electronic Signatures](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11)
• [S4] [ICH Q10 Pharmaceutical Quality System](https://database.ich.org/sites/default/files/Q10%20Guideline.pdf)
• [S5] [OECD Frascati Manual 2015](https://www.oecd.org/en/publications/2015/10/frascati-manual-2015_g1g57dcb.html)
• [S6] [GAO Government Auditing Standards 2024 Revision](https://www.gao.gov/assets/d24106786.pdf)
• [S7] [eCFR 2 CFR 200.303 Internal controls](https://www.ecfr.gov/current/title-2/subtitle-A/chapter-II/part-200/subpart-D/section-200.303)
• [S8] [NIST SP 800-92 Guide to Computer Security Log Management](https://csrc.nist.gov/pubs/sp/800/92/final)