1) 범위·의도된 사용목적 고정과 추적성 설계
RMF 품질은 “위험 항목을 많이 적었는가”가 아니라, 문서가 제품의 주장과 개발 산출물을 일관된 논리로 연결하는지에서 결정됩니다. 첫 번째 포인트는 범위와 의도된 사용목적(Indications for Use)을 초기에 고정하고, 그 범위를 변경관리와 연동하는 것입니다. 의료기기 소프트웨어든 하드웨어든 사용 환경·사용자·환자군·임상적 목적이 조금만 달라져도 위해 시나리오가 바뀌고, 그에 따라 위험통제의 우선순위와 검증 전략이 달라집니다. 실무에서는 기획서나 마케팅 문구가 RMF보다 먼저 바뀌는 경우가 많은데, 이때 RMF가 따라가지 못하면 “위험관리가 제품을 반영하지 않는다”는 치명적 평가를 받습니다. 따라서 RMF의 첫 장에는 제품/버전/구성(액세서리, 옵션, 서버 구성 포함), 의도된 사용목적, 사용자 프로파일, 사용 환경, 핵심 성능 주장, 적용 제외 범위를 명시하고, 이 항목이 바뀌면 어떤 절차로 RMF를 재평가하는지까지 규정해야 합니다.
두 번째로, 추적성(Traceability)은 RMF를 ‘규정 문서’가 아니라 ‘운영 문서’로 만드는 핵심 장치입니다. 최소한 위험원(또는 위해상황)–위해 시나리오–위험통제–검증/확인–잔여위험–정보제공(라벨/IFU/교육) 까지가 한 줄로 연결되어야 합니다. 여기서 자주 빠지는 부분이 “통제의 구현 증거”입니다. 통제를 ‘설계로 넣었다’고 적는 것과, 요구사항 ID·설계 산출물·코드/회로·시험 케이스로 구현이 확인된 것은 수준이 다릅니다. 실무적으로는 위험통제마다 (1) 통제 유형(내재 안전/보호장치/정보제공), (2) 설계 요구사항 ID, (3) 구현 위치(모듈/회로/설정), (4) 검증 케이스 ID, (5) 수용 기준을 명시해 두면, 변경 시 영향평가가 빨라지고 누락이 줄어듭니다.
마지막으로 버전 관리가 품질을 좌우합니다. RMF는 “최신 파일” 한 개가 아니라, 변경의 근거가 남아있는 이력 관리 체계여야 합니다. 특히 SaMD는 라이브러리 교체·OS 업데이트·알고리즘 튜닝처럼 기능은 같아도 위험이 달라질 수 있으므로, 구성관리(CM)와 RMF의 연결이 필수입니다. RMF 문서 상단에 해당 릴리스의 빌드/환경 정보와 변경 요약을 링크로 묶고, 변경 유형별로 어떤 위험 항목을 재평가했는지 기록하면 심사 대응이 아니라 일상 품질관리로 기능합니다. 요약하면 첫 포인트는 “범위를 고정하고, 바뀌면 반드시 다시 평가되도록 추적성 구조를 설계하는 것”입니다.
2) 위해 시나리오 중심 위험분석과 ‘근거 있는’ 위험평가
세 번째 포인트는 위험분석을 단어 나열이 아니라 시나리오(Sequence of Events) 로 구성하는 것입니다. RMF에서 흔히 보이는 약점은 “감전 위험”, “오작동 위험”처럼 추상적 위험원을 적어두고 끝내는 형태입니다. 그러나 심사 관점에서는 위해가 발생하기까지의 경로가 설명되어야 통제의 타당성을 평가할 수 있습니다. 예를 들어 ‘경보 미발생’이라는 위해상황이 있다면, 그 원인은 센서 오류일 수도 있고, 임계값 계산 로직일 수도 있고, 사용자 설정 UI의 혼동일 수도 있으며, 네트워크 지연으로 이벤트가 누락되는 구조일 수도 있습니다. 동일한 위해상황이라도 원인 경로가 다르면 효과적인 통제가 달라지기 때문에, 시나리오 기반으로 “어떤 조건에서, 어떤 실패가, 어떤 중간 사건을 거쳐, 어떤 위해로 연결되는지”를 구체화해야 합니다. 이 단계에서 FMEA, FTA 같은 기법은 도구일 뿐이고, 핵심은 ‘제품과 사용 환경을 반영한 경로가 빠짐없이 서술되었는가’입니다.
네 번째 포인트는 위험평가의 근거화입니다. 위험 수준(발생확률/심각도)을 표에 넣는 것만으로는 품질이 완성되지 않습니다. 발생확률을 “낮음”으로 두었다면 무엇을 근거로 낮음인지가 있어야 합니다. 제조 공정 관리 수준, 소프트웨어 결함 밀도 지표, 유사 제품의 PMS 데이터, 시험 결과, 사용성 평가에서의 오류율 등 근거 출처가 연결되어야 하며, 근거가 없으면 보수적으로 평가하고 그 이유를 명시해야 합니다. 심각도 또한 임상적 의미가 반영되어야 합니다. 단순히 “중간”이 아니라, 위해가 환자에게 미치는 영향(지연, 오진 가능성, 치료 중단, 불필요한 치료 유발 등)을 사용 목적과 사용자 숙련도를 고려해 기술해야 합니다. 특히 소프트웨어 의료기기는 데이터 무결성과 사이버보안이 위해로 이어지는 경로가 복합적이므로, ‘보안은 별도 문서’로 격리하기보다 RMF에서 안전 영향 경로를 명시하고 관련 통제와 검증을 연결하는 편이 품질이 높습니다.
또 하나의 실무 포인트는 위험평가가 ‘점수’가 아니라 의사결정 기록이라는 점입니다. 위험수준이 허용 가능한지 판단할 때, 단순히 허용 기준표에 대입하는 것으로 끝내면 설득력이 떨어집니다. 잔여위험이 남는 통제(예: 사용자 확인 절차, 경고 표시)는 오사용 가능성을 포함해 재평가해야 하고, 해당 위험을 사용자에게 어떻게 전달할지(라벨/IFU/교육/알람 설계)까지 연동해야 합니다. 결국 두 번째 섹션의 핵심은 “시나리오로 분석하고, 확률·심각도 판단을 근거와 함께 남겨 재현 가능한 평가로 만드는 것”입니다.
3) 통제의 실효성 검증, 잔여위험 커뮤니케이션, PMS 루프
다섯 번째 포인트는 위험통제가 ‘문서상 존재’가 아니라 실제로 구현·검증·유지되는지 증명하는 것입니다. 위험통제는 보통 내재 안전 설계(가능한 위해 자체 제거), 보호장치/알람(위해 발생 가능성 감소), 정보 제공(사용자 행동을 통한 통제)로 계층화됩니다. 품질 좋은 RMF는 통제 선택의 이유가 명확합니다. 예컨대 경고 문구로 통제할 수 있는 위험인지, 아니면 설계적으로 막아야 하는 위험인지가 구분되어야 하며, 정보 제공 통제를 선택했다면 사용성 관점에서 전달 가능성과 오사용 가능성까지 함께 평가해야 합니다. 특히 SaMD는 “설정 값”이나 “업데이트”가 통제의 일부인 경우가 많으므로, 기본값 정책·권한 관리·변경 이력·감사로그가 통제로서 어떻게 작동하는지까지 위험통제에 포함시키는 것이 안전합니다.
검증(Verification)과 유효성 확인(Validation) 연결도 중요합니다. 통제 구현을 확인하는 시험은 단순 기능 테스트를 넘어, 위해 시나리오에서 통제가 실제로 작동하는 조건을 재현해야 합니다. 예를 들어 알람 통제라면 임계 조건, 센서 입력 이상, 네트워크 지연, 사용자 설정 오류 등 실패 모드에서 알람이 누락되지 않는지 확인해야 하고, 동시에 알람 과다로 인한 ‘알람 피로’가 오사용을 유발하지 않는지(사용성/임상 워크플로우 관점)를 검토해야 합니다. 또한 시험 결과를 RMF에 “참조”로만 두지 말고, 통제별로 수용 기준과 결과 요약이 연결되도록 정리하면, 심사 시 ‘통제의 실효성’이 문서만 봐도 추적됩니다.
잔여위험(Residual Risk) 커뮤니케이션은 품질을 갈라놓는 지점입니다. 모든 위험을 0으로 만들 수 없기 때문에, 남는 위험을 사용자에게 정확히 전달하고 오해를 줄이는 설계가 필요합니다. 여기서 IFU/라벨은 단순 첨부물이 아니라 RMF의 통제 결과물입니다. 즉 잔여위험이 높은 항목은 경고의 위치·표현·행동 지침이 구체적이어야 하고, “주의” 같은 일반 문구 대신 상황–원인–행동을 명확히 제시해야 합니다. 또한 잔여위험이 남는 이유와 이익-위험(Benefit-Risk) 판단 근거를 남겨야 합니다. 이 기록이 없으면, 잔여위험을 ‘방치’한 것으로 보일 수 있습니다.
마지막으로 PMS(사후관리)와 변경관리를 RMF에 연결해야 합니다. 릴리스 후 불만, 오류 로그, CAPA, 사이버 취약점 제보는 RMF의 가정(발생확률, 통제 효과)을 검증하는 데이터입니다. 따라서 “PMS로 모니터링한다”로 끝내지 말고, 어떤 신호를 어떤 주기로 보고하며, 임계치(트리거)를 넘으면 어떤 위험 항목을 재평가하는지 절차를 구체화해야 합니다. 변경관리와 연결되면, 기능 변경·라이브러리 업데이트·UI 변경이 발생할 때 RMF 재평가가 자동으로 트리거되고, 그 결과가 배포 승인 게이트로 흘러가게 됩니다. 요약하면 세 번째 섹션의 결론은 “통제의 실효성을 시험으로 보여주고, 잔여위험을 사용자 정보와 PMS 루프로 관리하는 것”입니다.