R&D 인허가 제출자료 갭 체크리스트: 시험성적서, 라벨, 위험분석 누락 찾기

R&D 팀이 인허가 제출자료를 모을 때 가장 위험한 순간은 자료가 거의 다 모였다고 느끼는 때입니다. 시험성적서 폴더가 있고, 라벨 초안이 있고, 위험관리 파일도 있으니 제출 준비가 끝났다고 판단하기 쉽습니다. 그런데 실제 보완은 "자료가 없음"보다 "자료가 서로 맞지 않음"에서 더 자주 시작됩니다. 시험성적서의 모델명이 라벨의 모델명과 다르고, 사용목적 문구가 기술문서와 사용설명서에서 조금씩 다르며, 위험분석표에는 완화조치가 적혀 있지만 그 조치가 어떤 시험으로 확인됐는지 비어 있습니다.

이 글은 특정 제품의 허가 가능성이나 법적 판단을 대신하지 않습니다. 대신 의료기기, 디지털의료기기, SaMD 성격의 R&D 과제가 제출자료 패키지로 넘어가기 전에 스스로 찾을 수 있는 갭을 정리합니다. MFDS는 의료기기 허가·심사 첨부자료 가이드라인을 게시하고, eMEDI 허가 절차는 등급과 본질적 동등성에 따라 허가 대상이 달라질 수 있음을 안내합니다[S1][S2]. FDA eSTAR는 포괄적 의료기기 제출자료를 구조화하는 양식이고, FDA 510(k) RTA 정책은 제출자료가 실질 심사로 들어가기 위한 최소 수용성을 본다고 설명합니다[S4][S5]. 이 출처들을 R&D 실무 언어로 바꾸면 결론은 단순합니다. 제출자료 갭 체크는 문서 보유 여부가 아니라 시험성적서, 라벨, 위험분석, 기술문서가 같은 제품을 같은 근거로 설명하는지 확인하는 작업입니다.

빠른 결론

R&D 인허가 제출자료 갭 체크리스트는 세 묶음으로 시작합니다. 첫째, 시험성적서는 발급기관, 적용 규격, 시료·모델·버전, 시험 조건, 합격 기준, 변경 후 유효성을 봅니다. 둘째, 라벨과 사용설명서는 사용목적, 대상 사용자, 금기·주의, 보관·운송, 소프트웨어·사이버보안 문구가 기술문서와 같은지 봅니다. 셋째, 위험분석은 위해요인, 위험통제, 잔여위험, 검증 시험, 사용자 정보 제공이 한 줄로 이어지는지 봅니다. 세 묶음 중 하나라도 끊기면 "자료는 있지만 제출 패키지는 아직 닫히지 않은 상태"로 보는 편이 안전합니다.

R&D 인허가 제출자료 갭은 파일 부족보다 문서 간 불일치에서 먼저 드러납니다

제출자료 갭 리뷰의 시작점은 폴더 개수가 아닙니다. 제품 정의 한 줄을 먼저 고정해야 합니다. 제품명, 모델명, 소프트웨어 버전, 구성품, 사용목적, 대상 사용자, 사용 환경, 핵심 성능, 금기·주의, 위험통제 방식이 제출자료 전체에서 같은 기준으로 쓰여야 합니다. 이 기준이 흔들리면 시험성적서와 라벨, 위험분석은 각각 맞는 문서처럼 보여도 하나의 제출 패키지로는 약해집니다.

예를 들어 R&D 단계에서는 프로토타입 A, 시험성적서에는 Model-A2, 라벨에는 Atlas Monitor, 소프트웨어 문서에는 v0.9.8 clinical beta라고 적혀 있을 수 있습니다. 내부 구성원은 모두 같은 제품이라고 이해하지만 외부 검토자는 그렇게 읽지 않습니다. 모델명과 버전의 연결표가 없으면 시험 결과가 최종 제출 제품에 적용되는지 판단하기 어렵습니다. 특히 변경 후 재시험 여부가 남지 않으면 "이 성적서가 현재 설계에도 유효한가"라는 질문이 바로 생깁니다.

FDA의 RTA 정책은 510(k) 제출자료가 실질 심사로 넘어갈 최소 수용성을 평가하는 절차와 기준을 설명합니다[S5]. 이는 미국 제도에 한정된 문서이지만, R&D 팀의 사전 점검 원칙으로도 유용합니다. 제출 전 내부 리뷰는 심사관처럼 모든 문서를 다시 해석하는 자리가 아니라, 최소한의 완결성, 식별성, 추적성을 먼저 보는 자리여야 합니다. 자료가 고급스럽게 작성됐는지보다 제품 식별자, 적용 규격, 시험 조건, 라벨 문구, 위험통제 근거가 서로 충돌하지 않는지가 먼저입니다.

시험성적서 갭 체크는 원본성, 적용 범위, 변경 후 유효성을 함께 봐야 합니다

시험성적서가 있다는 말은 충분한 답이 아닙니다. 어떤 기관에서 발급했는지, 어떤 규격과 시험방법을 적용했는지, 시험 시료가 제출 제품과 같은지, 시험 일자 이후 설계나 원재료나 소프트웨어가 바뀌었는지 확인해야 합니다. MFDS 의료기기 허가·심사 첨부자료 가이드라인은 허가·심사에 필요한 첨부자료를 안내하는 공식 자료로 게시되어 있으며, eMEDI 허가도우미는 제품 개발 초기부터 시험기준 및 시험방법, 안전성·성능시험 설정에 관한 자문을 지원 대상으로 둡니다[S1][S3]. R&D 팀은 이 방향을 "시험을 했는가"가 아니라 "제출자료로 설명 가능한 시험인가"로 해석해야 합니다.

시험성적서 행에는 최소한 test_report_id, issuing_body, standard_or_method, sample_id, model_version, software_version, test_condition, acceptance_criteria, result, change_after_test, current_validity가 있어야 합니다. 특히 change_after_test 칸은 반드시 남겨야 합니다. 시험 이후 센서 사양, 알고리즘 임계값, 전원부, 포장재, 멸균 조건, UI 경고 문구, 데이터 저장 방식이 바뀌었다면 기존 성적서가 전부 무효라는 뜻은 아닙니다. 다만 어떤 항목은 영향 없음, 어떤 항목은 분석으로 대체 가능, 어떤 항목은 부분 재시험, 어떤 항목은 전체 재시험인지 판단 기록이 필요합니다.

제출 전 갭 질문	비어 있으면 생기는 문제	남길 증거
시험성적서의 시료·모델·버전이 제출 제품과 같은가	성적서가 현재 설계를 대표하는지 설명하기 어렵다	모델-시료-버전 매핑표
시험방법과 합격 기준이 요구사항과 연결되는가	PASS가 어떤 요구사항을 닫는지 보이지 않는다	요구사항 ID와 시험 항목 연결표
시험 이후 변경이 있었는가	변경 전 성적서를 현재 증거로 오인할 수 있다	변경 영향평가와 재시험 판단
발급기관과 원본 파일을 확인할 수 있는가	사본·요약본만 남아 보완 요청을 받을 수 있다	원본 PDF, 발급정보, 진위확인 경로
시험 조건이 실제 사용 환경을 설명하는가	라벨의 사용 환경과 시험 조건이 어긋난다	온도, 습도, 사용자, 사용 시나리오 근거

시험성적서 갭 리뷰에서 자주 놓치는 항목은 실패 결과입니다. 실패한 시험을 삭제하면 제출 패키지는 깔끔해 보이지만 위험분석과 변경 이력은 약해집니다. 실패 원인, 수정 조치, 재시험 결과가 이어져야 설계가 어떻게 안정됐는지 설명할 수 있습니다. 따라서 제출용 최종 성적서와 내부 실패 기록을 구분하되, 내부 추적성에서는 실패 기록을 유지해야 합니다.

라벨과 사용설명서 갭은 사용목적 문구가 기술문서와 다를 때 커집니다

라벨은 마지막에 디자인하는 포장 문구가 아닙니다. 인허가 제출자료에서는 제품이 누구에게, 어떤 목적으로, 어떤 조건에서, 어떤 제한을 두고 사용되는지 설명하는 핵심 증거입니다. IMDRF의 2024년 라벨링 원칙 문서는 의료기기와 IVD 의료기기의 조화된 라벨링 원칙을 다루고, EU MDR의 기술문서 구조도 라벨과 사용설명서를 기술문서의 구성 요소로 봅니다[S6][S8]. 즉 라벨은 마케팅 문구가 아니라 사용목적, 사용방법, 위험 정보, 보관·운송 조건을 제품 기술문서와 연결하는 문서입니다.

라벨 갭은 대부분 작은 표현 차이에서 시작합니다. 기술문서에는 "의료진이 병원 환경에서 측정값을 참고하는 소프트웨어"라고 되어 있는데 라벨에는 "가정에서 건강 상태를 확인"한다고 적혀 있으면 사용 환경과 대상 사용자가 달라집니다. 위험분석에는 오판 위험을 줄이기 위해 경고 문구를 넣었다고 되어 있지만 사용설명서에는 그 경고가 빠져 있을 수 있습니다. 소프트웨어 제품에서는 사이버보안, 계정관리, 업데이트, 데이터 백업, 네트워크 연결 제한 같은 정보가 기술문서에는 있으나 사용자 정보에는 충분히 반영되지 않는 경우도 있습니다.

FDA의 2026년 의료기기 사이버보안 가이던스는 사이버보안 위험이 있는 기기의 설계, 라벨링, 시판 전 제출 문서에 포함할 정보를 다룹니다[S9]. 모든 R&D 제품이 같은 수준의 사이버보안 자료를 내야 한다는 뜻은 아닙니다. 그러나 네트워크 연결, 계정, 원격 업데이트, 데이터 전송, 클라우드 연동이 있는 제품이라면 라벨과 사용설명서에서 사용자가 알아야 할 보안 조건이 빠졌는지 확인해야 합니다. "보안은 개발 문서에 있음"은 사용자 정보 제공 갭을 닫지 못합니다.

라벨 문구에서 바로 보류해야 할 신호

사용목적이 기술문서, 시험 계획서, 라벨, 웹 소개 문구에서 서로 다르다.

시험성적서는 전문가 사용 조건인데 사용설명서는 일반 사용자 사용처럼 읽힌다.

위험분석의 경고·주의·금기 문구가 라벨이나 사용설명서에 반영되지 않았다.

보관·운송 조건은 시험했지만 라벨에는 온도, 습도, 유효기간, 개봉 후 사용 조건이 없다.

소프트웨어 업데이트, 계정, 데이터 백업, 네트워크 연결 제한을 사용자에게 어떻게 알릴지 정하지 않았다.

라벨 체크는 문장 교정으로 끝내면 안 됩니다. 각 라벨 문구 옆에 근거 문서 ID를 붙여야 합니다. 사용목적은 기술문서의 intended use와 연결하고, 성능 주장은 시험성적서와 연결하며, 주의 문구는 위험분석의 위험통제와 연결합니다. 문구가 근거 문서와 연결되지 않으면 삭제하거나 근거를 보완해야 합니다. 이 원칙을 적용하면 라벨은 보기 좋은 문서가 아니라 제출자료 전체의 축약본이 됩니다.

위험분석 갭은 위험통제와 검증 시험 사이가 끊길 때 발생합니다

위험분석표가 있는 것만으로는 부족합니다. ISO 14971:2019에 대한 FDA 인정표준 프로필은 위해요인을 식별하고, 위험을 추정·평가하며, 위험을 통제하고, 통제 효과를 모니터링하는 프로세스를 설명합니다[S7]. IMDRF 필수원칙 문서도 알려진 위험과 예측 가능한 위험, 바람직하지 않은 부작용이 의도한 사용 조건에서 평가된 이익과 비교해 최소화되고 수용 가능해야 한다는 원칙을 제시합니다[S10]. R&D 제출자료 갭 리뷰에서는 이 원칙을 "위험 한 줄이 검증 한 줄로 닫혔는가"로 바꾸어 확인하면 됩니다.

좋은 위험분석 행은 hazard, hazardous_situation, harm, initial_risk, risk_control, verification_evidence, residual_risk, labeling_needed, owner를 포함합니다. 여기서 핵심은 verification_evidence입니다. 예를 들어 "알람을 추가한다"는 위험통제는 설계 조치입니다. 제출자료에서 이 조치가 닫히려면 알람이 실제 조건에서 작동한다는 시험, 사용자가 알람을 이해한다는 사용성 근거, 라벨의 알람 설명, 실패 시 대체 조치가 연결되어야 합니다. 위험통제가 소프트웨어 로직이라면 소프트웨어 검증 자료와도 연결되어야 합니다.

R&D 팀은 위험분석을 너무 늦게 작성하는 경향이 있습니다. 제출 직전 위험분석을 만들면 시험성적서와 라벨은 이미 작성되어 있어 서로 맞추는 작업이 보완으로 바뀝니다. 반대로 초기부터 위험분석 ID를 요구사항과 시험 ID에 붙이면 시험 계획이 더 선명해집니다. "전기적 안전 시험", "성능 시험", "사용성 시험"처럼 큰 묶음으로 끝내지 않고, 각 시험이 어떤 위해요인과 어떤 위험통제를 검증하는지 연결할 수 있습니다.

위험분석 행	연결해야 할 제출자료	갭 판정 기준
위해요인과 위해상황	사용 시나리오, 사용자 요구, 기술문서	실제 사용 환경과 다른 추상 문장만 있으면 갭
위험통제	설계 출력, 소프트웨어 요구사항, 라벨 경고	조치가 문서에만 있고 구현·문구 근거가 없으면 갭
검증 증거	시험성적서, 분석 보고서, 사용성 결과	시험 ID나 합격 기준이 없으면 갭
잔여위험	위험-이익 판단, 사용자 정보 제공	잔여위험 수용 근거나 승인자가 없으면 갭
라벨 필요 여부	라벨, 사용설명서, 교육자료	경고 문구가 위험분석과 다르면 갭

위험분석에서 특히 조심할 부분은 라벨을 위험통제로 사용할 때입니다. 경고 문구는 중요한 통제 수단일 수 있지만, 설계로 줄일 수 있는 위험을 모두 라벨로 떠넘기면 약한 패키지가 됩니다. 라벨 통제를 쓰는 경우에도 사용자가 그 정보를 언제, 어디서, 어떤 행동으로 바꾸는지 설명해야 합니다. 라벨 문구가 위험분석 ID와 연결되어 있으면 이 판단을 검토하기 쉽습니다.

소프트웨어와 디지털 자료는 시험성적서, 라벨, 위험분석을 다시 흔듭니다

소프트웨어가 포함된 제품은 제출자료 갭이 더 쉽게 생깁니다. 빌드 번호가 바뀌면 시험성적서의 유효성이 흔들리고, 알고리즘 임계값이 바뀌면 성능 결과와 위험분석이 흔들리며, 사용자 흐름이 바뀌면 라벨과 사용설명서가 바뀝니다. FDA의 2023년 장치 소프트웨어 시판 전 제출자료 가이던스는 의료기기 소프트웨어 기능의 안전성과 효과성 평가를 위한 권장 문서 정보를 설명합니다[S11]. 이 자료의 실무적 의미는 소프트웨어 문서를 별도 폴더로 떼어 놓지 말고 제출 패키지의 다른 증거와 연결하라는 것입니다.

소프트웨어 갭 체크는 네 줄이면 시작할 수 있습니다. 첫째, 제출 제품의 빌드와 시험 빌드가 같은지 봅니다. 둘째, 소프트웨어 요구사항이 위험통제와 연결되는지 봅니다. 셋째, 라벨과 사용설명서가 실제 UI, 알림, 제한사항, 업데이트 조건과 일치하는지 봅니다. 넷째, 사이버보안 위험이 있는 경우 보안 요구사항, 위협 모델, 취약점 대응, 사용자 보안 안내가 제출자료에서 분리되지 않았는지 봅니다[S9].

여기서 중요한 것은 모든 소프트웨어 자료를 두껍게 만드는 것이 아닙니다. 제품 위험, 기능 성격, 제출 경로에 맞게 필요한 수준을 정하되, 결정 근거를 남겨야 합니다. "해당 없음"도 근거가 필요합니다. 네트워크 기능이 없어서 사이버보안 자료가 제한적이라면, 어떤 기능이 없고 어떤 데이터 흐름이 없어서 그렇게 판단했는지 제품 정의서에 남깁니다. 반대로 클라우드 연동이 있는데 보안 라벨이나 사용자 안내가 비어 있으면 제출 전 갭으로 표시해야 합니다.

제출 전 60분 갭 리뷰는 세 파일을 한 줄로 맞추는 방식이 좋습니다

제출자료를 모두 다시 읽는 리뷰는 오래 걸리고 자주 실패합니다. 대신 60분 동안 제품 정의표, 시험성적서 목록, 라벨·사용설명서, 위험분석표를 같은 화면에 놓고 한 줄씩 맞추는 방법이 더 빠릅니다. 첫 10분은 제품 식별자를 고정합니다. 제품명, 모델, 버전, 사용목적, 대상 사용자, 사용 환경을 한 줄로 적고 모든 문서가 이 표현과 맞는지 표시합니다.

다음 20분은 시험성적서를 봅니다. 시험성적서마다 요구사항 ID, 위험분석 ID, 모델·버전, 시험 조건, 합격 기준, 변경 후 유효성 칸을 채웁니다. 빈칸이 있으면 통과가 아니라 gap-test로 표시합니다. 그 다음 15분은 라벨과 사용설명서를 봅니다. 사용목적, 대상 사용자, 경고·주의, 보관·운송, 소프트웨어·보안 문구가 기술문서와 위험분석에 연결되는지 확인합니다. 마지막 15분은 위험분석을 봅니다. 위험통제마다 검증 증거와 라벨 반영 여부가 있는지 확인하고, 잔여위험 승인자가 비어 있는 행을 따로 빼냅니다.

60분 제출자료 갭 리뷰 체크

제품 정의 1줄: 제품명, 모델, 버전, 사용목적, 사용자, 사용 환경이 모든 문서에서 같은가

시험성적서: 시험 ID, 요구사항 ID, 위험 ID, 시료·버전, 합격 기준, 변경 후 유효성이 있는가

라벨·사용설명서: 사용목적, 경고, 보관 조건, 소프트웨어 조건이 기술문서와 같은가

위험분석: 위험통제, 검증 증거, 잔여위험, 라벨 반영, 책임자가 한 줄에서 이어지는가

최종 판정: 제출 가능, 보완 후 제출, 사전 상담 필요, 범위 재정의 중 하나로 닫았는가

리뷰 결과는 pass, minor-gap, major-gap, scope-question 네 상태로 나누면 충분합니다. minor-gap은 파일명, 버전 표기, 근거 문서 링크처럼 빠르게 고칠 수 있는 항목입니다. major-gap은 시험 재수행, 라벨 문구 변경, 위험통제 검증 누락처럼 일정에 영향을 주는 항목입니다. scope-question은 제품 사용목적, 대상 사용자, 제출 경로, 임상자료 필요성처럼 내부 판단만으로 닫기 어려운 항목입니다. 이 항목은 MFDS 허가도우미, 시험기관, 규제 전문가, 해당 관할 공식 안내로 확인할 대상으로 분리합니다[S3].

rndatlas 내부 글과 함께 쓰는 제출자료 보완 경로

이 글의 체크리스트는 제출 직전 갭을 찾는 좁은 도구입니다. 문서 인덱스 자체가 약하다면 R&D 기술문서 인덱스 체크리스트로 요구사항, 시험성적서, 변경 이력을 먼저 묶는 편이 좋습니다. 품질시스템 증거가 흩어져 있다면 R&D 품질관리 QMS 증거 체크리스트에서 디자인 컨트롤, 변경 로그, 검증 기록을 분리합니다. 소프트웨어 검증 자료가 약하면 R&D 의료기기 소프트웨어 검증 체크리스트를 다음 단계로 봅니다. 위험과 일정 버퍼가 문제라면 R&D risk register contingency checklist에서 리스크 등록부와 대응 계획을 이어 붙입니다.

마지막 판단 기준은 단순합니다. 시험성적서가 현재 제품을 대표하고, 라벨이 기술문서와 같은 사용목적을 말하며, 위험분석의 각 통제가 시험 또는 라벨 근거로 닫히면 제출자료 패키지는 1차 검토를 통과할 수 있습니다. 반대로 세 문서 중 하나라도 다른 제품을 설명하고 있다면 아직 제출 직전이 아닙니다. 그때 필요한 작업은 문장 다듬기가 아니라 제품 정의, 시험 증거, 사용자 정보, 위험통제 사이의 끊어진 줄을 다시 연결하는 것입니다.