R&D 변경관리 기록 체크리스트의 목적은 변경을 많이 통제하는 것이 아니라, 변경 요청서에서 승인 후 실행 확인까지 같은 사건으로 추적되게 만드는 것입니다. 많은 팀은 변경 승인 회의록은 남기지만 정작 승인 이후 무엇이 바뀌었는지, 어느 문서와 시험이 다시 열렸는지, 누가 실제 적용을 확인했는지를 흩어 둡니다. 그러면 나중에 “그 변경은 승인됐나요?”라는 질문에는 답할 수 있어도 “승인된 대로 실행됐나요?”에는 답하기 어렵습니다. 좋은 변경관리 기록은 요청, 영향평가, 승인, 실행, 확인, 잔여 위험을 한 줄로 이어 줍니다.
이 글은 변경 영향평가의 세부 산정법이나 규제 제출 전략을 대신하지 않습니다. 영향 범위를 깊게 따져야 한다면 [R&D 변경 영향평가 체크리스트](/guide/rnd-change-impact-assessment-checklist)를 먼저 보는 편이 맞습니다. 프로토콜 변경처럼 승인 시점과 기존 데이터 적용 범위가 핵심이면 [R&D 프로토콜 변경 체크리스트](/guide/rnd-protocol-amendment-checklist)가 더 가깝습니다. 여기서는 변경관리 기록 자체를 닫기 위해 변경 요청서, 영향평가, 승인 후 실행 확인을 어떤 순서와 필드로 남길지에 집중합니다.
**빠른 결론**
R&D 변경관리 기록은 `change_request_id`, `request_reason`, `current_state`, `proposed_change`, `impact_assessment`, `approval_decision`, `implementation_evidence`, `post_implementation_check`, `open_items`가 한 묶음으로 남아야 합니다. 승인 문서만 있고 실행 증거가 없으면 기록은 완료가 아니라 승인 대기 이후 상태입니다. 실행은 했지만 어떤 영향평가 결론을 근거로 했는지 보이지 않으면, 변경은 되었어도 관리되었다고 말하기 어렵습니다. 전자 기록을 쓰는 팀은 감사추적, 권한, 서명 의미, 이전 기록 보존까지 함께 확인해야 합니다[S1].
변경 요청서는 해결책보다 변경 전 상태를 먼저 고정합니다
변경 요청서의 첫 번째 역할은 “무엇을 바꾸고 싶은가”를 쓰는 것이 아닙니다. 바꾸기 전 상태를 고정하는 것입니다. 현재 요구사항, 설계값, 시험 조건, 원재료 규격, 분석 스크립트, 장비 설정, 문서 버전이 무엇인지 남겨야 제안된 변경의 크기를 판단할 수 있습니다. “센서 사양 변경 요청”은 너무 넓습니다. “REQ-TEMP-04의 표시 오차 기준을 유지하되, 공급사 A의 센서 로트 단종으로 공급사 B 센서 모델 B-17을 적용하고 보정 테이블을 새로 생성하려는 요청”처럼 현재 상태와 제안 상태가 같이 있어야 합니다.
요청서에는 최소 여섯 가지가 필요합니다. 첫째, 변경 출처입니다. 고객 요청, 시험 실패, 공급망 이슈, 원가 개선, 규제 또는 표준 변경, 내부 설계 개선 중 무엇인지 분리합니다. 둘째, 현재 기준입니다. 요구사항 ID, SOP, 시험계획서, 도면, 코드 버전, 원재료 규격처럼 변경 전 기준을 적습니다. 셋째, 제안 변경입니다. 문장 수정인지, 부품 대체인지, 시험법 변경인지, 데이터 처리 로직 변경인지 구체화합니다. 넷째, 요청 사유의 증거입니다. 시험 리포트, 공급사 통지, 고객 이슈, 위험 검토, 회의 결정이 어디에 있는지 링크합니다. 다섯째, 긴급도와 적용 희망 시점입니다. 여섯째, 요청자가 생각하는 영향 범위입니다. 이 마지막 항목은 확정 결론이 아니라 영향평가의 출발점입니다.
요청서에서 피해야 할 문장은 “품질 개선을 위해 변경”, “일정 단축을 위해 변경”, “현장 편의를 위해 변경”입니다. 이런 표현은 의도는 말하지만 증거와 기준을 말하지 않습니다. 요청서는 승인자를 설득하는 문서가 아니라 영향평가자가 확인할 출발점을 제공하는 문서입니다. ICH Q10은 제품과 공정 지식이 개발 단계부터 제품 수명주기 전반에 걸쳐 관리되어야 하며, 변화관리 활동도 지식의 출처가 된다고 설명합니다[S2]. R&D 변경 요청서도 같은 원리로 보면 됩니다. 변경 요청은 단순 결재 안건이 아니라 나중에 다시 쓸 수 있는 지식 기록이어야 합니다.
| 요청서 필드 | 기록 질문 | 빠지면 생기는 문제 |
|---|---|---|
| 변경 전 기준 | 지금 승인된 기준은 무엇인가 | 변경 크기와 재시험 범위를 산정할 수 없다 |
| 변경 사유 | 왜 지금 변경해야 하는가 | 일정 편의와 품질 필요가 섞인다 |
| 제안 변경 | 정확히 무엇이 바뀌는가 | 승인자는 다른 변경을 상상한다 |
| 근거 위치 | 요청 사유를 뒷받침하는 증거는 어디 있는가 | 구두 요청이 기록처럼 남는다 |
| 적용 희망 시점 | 언제부터 반영하려는가 | 승인 전 적용과 승인 후 적용이 뒤섞인다 |
| 예상 영향 | 요청자가 본 영향 범위는 무엇인가 | 영향평가가 처음부터 빈칸으로 시작한다 |
영향평가는 승인 여부가 아니라 승인 조건을 만드는 기록입니다
영향평가를 “영향 있음/없음”으로 끝내면 변경관리 기록은 약해집니다. 영향평가의 실제 목적은 승인 조건을 만드는 것입니다. 변경을 승인할 수 있는지, 보류해야 하는지, 어떤 시험을 다시 해야 하는지, 어떤 문서를 고쳐야 하는지, 어느 릴리스부터 적용해야 하는지, 잔여 위험을 누구에게 알려야 하는지 결정할 수 있어야 합니다. 따라서 영향평가 표에는 영향 영역과 함께 필요한 조치가 들어가야 합니다.
ICH Q9(R1)은 위험평가가 잘 정의된 문제 설명 또는 위험 질문에서 시작하며, “무엇이 잘못될 수 있는가, 발생 가능성은 어떤가, 결과의 심각도는 어떤가”라는 세 질문을 제시합니다[S3]. 변경관리 기록에 이 원칙을 적용하면, 영향평가의 첫 줄은 “중대/경미”가 아니라 “이 변경으로 무엇이 잘못될 수 있는가”가 됩니다. 예를 들어 부품 공급사를 바꾸는 변경은 기능 요구사항에는 직접 영향이 없어 보여도, 보정값, 장기 안정성, 시험 샘플 대표성, 구매 규격, 라벨링, 공급사 승인 상태에 영향을 줄 수 있습니다.
영향평가 표는 적어도 여덟 칸으로 나누는 것이 좋습니다. `requirements`, `design_output`, `test_plan`, `data_integrity`, `supplier_or_material`, `regulatory_or_claim`, `schedule_cost`, `training_or_sop`입니다. 각 칸에는 “해당 없음”만 쓰지 말고 왜 해당 없는지 적습니다. 예를 들어 “규제 영향 없음”보다 “외부 제출용 성능 주장 문구와 라벨 문구를 바꾸지 않으며, 기술파일 색인에는 내부 부품 대체 이력만 추가”가 더 안전합니다. 해당 없음도 결론이므로 근거가 있어야 합니다.
이 글의 독자는 모든 변경에 대형 위험평가를 붙일 필요는 없습니다. ICH Q10은 품질시스템 설계와 문서화가 명확해야 하며, 제품 수명주기 단계와 회사 활동의 규모와 복잡성에 비례해 적용되어야 한다고 봅니다[S2]. 작은 문서 오탈자에는 짧은 영향평가가 맞습니다. 그러나 시험 조건, 데이터 처리, 원재료, 공급사, 요구사항, 고객 사용조건을 바꾸는 변경은 간단한 요청서만으로 닫지 말고 승인 조건을 남겨야 합니다.
**영향평가에서 바로 보류해야 할 신호**
변경 전 기준이 확인되지 않는다. 기존 시험 결과를 계속 쓸 수 있는지 판단하지 않았다. 변경이 적용될 버전과 샘플 범위가 없다. 승인자가 확인할 문서 목록이 없다. 실행 후 확인 방법이 없다. 전자 기록에서 누가 무엇을 언제 바꿨는지 감사추적이 남지 않는다. 이 중 하나라도 남아 있으면 변경 승인보다 기록 보완이 먼저입니다.
승인은 결재자가 아니라 결정 의미를 기록해야 완성됩니다
승인 기록에서 흔한 공백은 서명은 있는데 서명의 의미가 없는 경우입니다. 누군가 “승인” 버튼을 눌렀다는 사실만으로는 어떤 판단을 승인했는지 알 수 없습니다. 승인 기록에는 결정 유형, 승인 범위, 조건, 적용 시점, 책임자가 들어가야 합니다. 조건부 승인이라면 조건을 완료하기 전에는 무엇을 할 수 없고 무엇은 할 수 있는지 분리해야 합니다. 보류라면 보류 사유와 다음 제출 조건을 적어야 합니다. 반려라면 반려된 변경이 현장에 적용되지 않았다는 확인도 필요합니다.
전자 서명을 쓰는 팀은 이 부분이 더 중요합니다. 21 CFR Part 11은 적용 대상 전자 기록과 전자 서명에 대해 신뢰성, 무결성, 기록 보호, 권한 제한, 시간 기록이 있는 감사추적, 서명자의 이름과 날짜·시간, 서명 의미 같은 통제를 요구합니다[S1]. 모든 R&D 기록이 Part 11 적용 대상은 아닐 수 있습니다. 그래도 “누가 승인했는가”보다 “무엇을 어떤 의미로 승인했는가”를 남기라는 원칙은 일반 R&D 기록에도 유용합니다.
승인 기록은 다음 네 가지 유형으로 나누면 관리가 쉬워집니다. 첫째, `approve_as_requested`입니다. 요청한 변경을 그대로 승인하고 정해진 실행 계획으로 넘어갑니다. 둘째, `approve_with_conditions`입니다. 특정 시험, 문서 개정, 고객 확인, 공급사 증거 보완이 완료되어야 실행됩니다. 셋째, `defer_pending_evidence`입니다. 영향평가 근거가 부족해 보류합니다. 넷째, `reject_or_close_no_change`입니다. 변경하지 않는 결정을 내리고 기존 기준을 유지합니다. 이 네 유형을 쓰면 회의록 문장보다 기록 상태가 선명해집니다.
| 승인 유형 | 기록해야 할 조건 | 실행 가능 상태 |
|---|---|---|
| 그대로 승인 | 승인된 변경 범위, 적용 버전, 실행 책임자 | 즉시 실행 가능 |
| 조건부 승인 | 완료해야 할 시험, 문서, 검토, 기한 | 조건 완료 전 제한 실행 |
| 근거 보류 | 부족한 증거, 재제출 기준, 다음 리뷰 시점 | 실행 금지 |
| 반려 또는 무변경 종료 | 반려 사유, 현장 적용 금지 확인 | 기존 기준 유지 |
승인 후에는 승인 회의록과 실행 작업표가 같은 ID를 공유해야 합니다. 변경관리에서 가장 위험한 상태는 승인 문서와 실제 실행 티켓이 서로 다른 이름으로 존재하는 것입니다. 예를 들어 CCB-2026-014가 승인되었는데 개발 티켓은 FW-392, 시험 티켓은 QA-117, 문서 개정은 DOC-88로 흩어져 있고 서로 연결되지 않으면 변경은 중간에 새어 나갑니다. 변경관리 기록의 중심 ID를 하나 정하고 모든 실행 증거에 그 ID를 붙여야 합니다.
승인 후 실행 확인은 “했음”이 아니라 산출물 대조로 닫습니다
승인 후 실행 확인은 변경관리 기록에서 가장 많이 빠지는 단계입니다. “개발 완료”, “문서 개정 완료”, “시험 완료” 같은 문장만으로는 충분하지 않습니다. 승인 조건과 실제 산출물을 대조해야 합니다. 승인된 변경 범위와 구현된 범위가 같은지, 문서 버전이 올라갔는지, 시험이 지정된 조건으로 수행됐는지, 기존 데이터 재사용 판단이 지켜졌는지, 릴리스 노트나 고객 안내가 필요한 경우 작성됐는지 확인합니다.
EU GMP Chapter 4는 문서의 정확성, 무결성, 가용성, 판독성을 확보하기 위한 통제를 요구하고, 기록 보존 기간 동안 기록 무결성이 유지되어야 한다고 설명합니다[S4]. FDA GLP의 비임상시험 기록 조항도 최종보고서에 승인된 프로토콜의 목적과 절차, 원 프로토콜 변경, 데이터 품질 또는 무결성에 영향을 줄 수 있는 상황, 원자료와 최종보고서 보관 위치 등을 포함하도록 요구합니다[S5]. 특정 규제 연구가 아니더라도 이 구조는 R&D 변경관리 기록에 중요한 힌트를 줍니다. 실행 확인은 “완료 보고”가 아니라 변경 전후 증거와 보관 위치를 확인하는 일입니다.
실행 확인표에는 `approved_condition`, `actual_output`, `evidence_location`, `verified_by`, `verified_date`, `mismatch_or_exception`, `closure_decision`을 넣습니다. 승인 조건이 “TP-07 저온 시험 재수행”이었다면 실제 산출물은 시험 성적서 번호와 샘플 ID, 장비 ID, 시험 일자여야 합니다. 승인 조건이 “SOP-12 개정”이었다면 실제 산출물은 개정 버전, 승인일, 배포일, 교육 대상자여야 합니다. 승인 조건이 “기존 데이터 사용 금지”였다면 실제 산출물은 분석 파일에서 기존 데이터가 제외되었음을 보여 주는 로그여야 합니다.
OECD GLP 원칙은 연구계획서의 수정은 정당화되고 날짜가 있는 서명으로 승인되어 연구계획서와 함께 보관되어야 하며, 연구계획서 일탈은 설명·인정·날짜 기록 후 원자료와 함께 유지되어야 한다고 설명합니다[S7]. 일반 R&D 변경관리에서도 같은 구분이 필요합니다. 승인된 변경은 amendment에 가깝고, 승인된 계획에서 벗어난 실행은 deviation에 가깝습니다. 실행 중 계획과 다르게 처리한 항목이 있으면 변경을 닫기 전에 별도 예외 기록으로 남겨야 합니다.
데이터와 전자기록 변경은 감사추적과 원본 보존을 따로 봅니다
소프트웨어, 분석 스크립트, 실험 데이터, 전자 문서관리 시스템을 쓰는 R&D 팀은 변경관리 기록에서 전자기록 통제를 따로 확인해야 합니다. 코드가 바뀌었는지, 데이터 처리 로직이 바뀌었는지, 전자 양식 템플릿이 바뀌었는지, 서명 워크플로가 바뀌었는지에 따라 실행 확인 항목이 달라집니다. 화면에서 최신 버전만 보이는 시스템은 편리하지만, 이전 기록이 보이지 않거나 변경 이유가 남지 않으면 변경관리 증거로 약합니다.
WHO 데이터 무결성 가이드라인은 데이터와 기록이 attributable, legible, contemporaneous, original, accurate에 더해 complete, consistent, enduring, available해야 한다는 ALCOA+ 원칙을 제시합니다[S6]. 변경관리 기록에 적용하면 누가 변경을 요청했고, 누가 영향평가를 했고, 누가 승인했으며, 누가 실행 확인을 했는지 추적되어야 합니다. 또한 변경 전 기록이 지워지지 않아야 하고, 변경 후 기록만 남기지 않아야 하며, 나중에 읽을 수 있고 검색할 수 있어야 합니다.
전자기록 변경 체크는 세 줄이면 시작할 수 있습니다. 첫째, 원본 보존입니다. 변경 전 요구사항, 시험계획서, 분석 스크립트, 원자료, 승인 기록이 보존되는지 확인합니다. 둘째, 감사추적입니다. 생성, 수정, 삭제, 승인, 반려, 배포가 시간순으로 남는지 확인합니다. 셋째, 권한과 서명 의미입니다. 요청자, 평가자, 승인자, 실행자, 확인자가 같은 사람이어도 되는지, 분리가 필요한지, 전자 서명의 의미가 검토인지 승인인지 책임 수락인지 구분되는지 확인합니다.
30분 변경관리 기록 자체점검
최종 저장 전에는 긴 회의보다 짧은 대조가 더 효과적입니다. 0~5분에는 변경 요청서를 봅니다. 변경 전 기준, 제안 변경, 요청 사유, 근거 위치가 모두 있는지 확인합니다. 5~10분에는 영향평가를 봅니다. 요구사항, 설계, 시험, 데이터, 문서, 공급사, 일정, 교육 중 해당 없음으로 처리한 항목에 근거가 있는지 확인합니다. 10~15분에는 승인 기록을 봅니다. 승인 유형, 조건, 적용 시점, 책임자, 보류 또는 반려 사유가 명확한지 확인합니다.
15~25분에는 실행 증거를 봅니다. 승인 조건마다 실제 산출물, 증거 위치, 확인자, 확인일이 있는지 봅니다. 문서 개정이면 개정 번호와 배포 기록, 시험이면 시험 성적서와 샘플 ID, 데이터 변경이면 분석 로그와 스크립트 버전, 공급사 변경이면 공급사 승인 또는 입고검사 증거가 연결되어야 합니다. 25~30분에는 종료 문장을 고칩니다. “변경 완료” 대신 “요청 CR-2026-014는 조건부 승인 항목 3건 중 3건의 실행 증거가 확인되어 종료하며, 잔여 위험 1건은 다음 릴리스 리뷰에서 추적한다”처럼 씁니다.
마지막으로 내부 링크 흐름을 정리합니다. 영향 범위 산정이 부족하면 [R&D 변경 영향평가 체크리스트](/guide/rnd-change-impact-assessment-checklist)로 이동합니다. 승인 후 데이터와 원자료 보존이 문제라면 [R&D 데이터 보존·아카이브 체크리스트](/guide/rnd-data-retention-archive-checklist)를 봅니다. 변경이 시험 기준을 흔든다면 [R&D 수락기준·시험계획 체크리스트](/guide/rnd-acceptance-criteria-test-plan-checklist)를 연결합니다. 부적합에서 출발한 변경이라면 [R&D 부적합·CAPA 체크리스트](/guide/rnd-nonconformance-capa-checklist)와 함께 닫아야 합니다. 변경관리 기록은 단독 문서가 아니라 요청, 영향, 실행, 증거 보존을 이어 주는 색인입니다.
참고 출처
- [S1] eCFR, *21 CFR Part 11 - Electronic Records; Electronic Signatures*, https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
- [S2] ICH, *Q10 Pharmaceutical Quality System*, https://database.ich.org/sites/default/files/Q10%20Guideline.pdf
- [S3] ICH, *Q9(R1) Quality Risk Management*, https://database.ich.org/sites/default/files/ICH_Q9%28R1%29_Guideline_Step4_2025_0115_0.pdf
- [S4] European Commission, *EudraLex Volume 4, Chapter 4: Documentation*, https://health.ec.europa.eu/system/files/2016-11/chapter4_01-2011_en_0.pdf
- [S5] eCFR, *21 CFR Part 58 Subpart J - Records and Reports*, https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-58/subpart-J
- [S6] WHO, *Guideline on data integrity*, https://cdn.who.int/media/docs/default-source/medicines/norms-and-standards/guidelines/inspections/trs1033-annex4-guideline-on-data-integrity.pdf
- [S7] OECD, *OECD Principles on Good Laboratory Practice*, https://one.oecd.org/document/C%2897%29186/FINAL/en/pdf