1) FMEA 항목을 위해 시나리오 요소로 매핑하기
FMEA는 고장모드(Failure Mode)를 중심으로 “무엇이 어떻게 망가질 수 있는가”를 체계적으로 분해하는 데 강점이 있습니다. 반면 위해 시나리오(Sequence of Events)는 “망가짐이 실제 사용 상황에서 어떤 사건의 연쇄를 통해 위해(Harm)로 이어지는가”를 설명하는 데 초점이 있습니다. 따라서 FMEA를 위해 시나리오로 변환할 때는 FMEA 표의 각 칼럼을 그대로 옮겨 적기보다, 시나리오의 구성 요소로 재배치해야 품질이 올라갑니다. 실무에서는 이 매핑 규칙을 팀 표준으로 정해두면, 사람마다 문서 스타일이 달라져도 논리 구조가 일관되게 유지됩니다.
매핑의 핵심은 ‘효과(Effect)’를 단순히 결과로 두지 않고, 위해상황(Hazardous Situation)과 위해(Harm)로 분리하는 것입니다. FMEA의 Effect는 종종 “기기 동작 이상” 수준에서 멈추는데, 위해 시나리오에서는 기기 이상이 곧 위해가 아닙니다. 예를 들어 “알람 미발생”은 기기 효과(effect)이지만, 위해상황은 “사용자가 이상 상태를 인지하지 못한 채 사용을 지속하는 상태”이고, 위해는 “치료 지연 또는 부적절한 처치”처럼 환자/사용자 관점의 결과로 정의되어야 합니다. 이 분리가 되면, 정보제공(라벨/교육) 통제가 왜 필요한지, 알람 설계가 왜 통제인지, 사용성 검증이 왜 들어와야 하는지가 자연스럽게 연결됩니다.
실무에서 유용한 최소 매핑 세트는 다음과 같습니다. FMEA의 기능/요구사항은 시나리오의 “사용 장면과 의도된 사용 흐름”을 고정하는 기준이 됩니다. 고장모드는 “시작 사건(initiating event) 또는 핵심 실패 사건”으로 배치하고, 원인(Cause) 은 사건 연쇄에서 “직접 원인과 기여 요인(촉진 조건)”으로 분해합니다. 현행 통제(Current Controls) 는 장벽(Barrier)로 두되, ‘존재’가 아니라 “어떤 사건 고리를 끊는 통제인지”를 명시해야 합니다. 검출(Detection) 은 단순 점수 항목이 아니라 “탐지 실패/전달 실패/해석 실패”를 드러내는 단서로 사용합니다. 마지막으로 S/O/D 점수는 시나리오의 신뢰도를 높이는 보조 자료일 뿐, 점수 자체가 시나리오를 대신하지 못한다는 원칙을 유지해야 합니다. 요약하면 1단계의 목적은 FMEA 정보를 버리지 않으면서도, 위해 시나리오가 요구하는 사람-기기-환경의 사건 구조로 정보를 재배치하는 것입니다.
2) 고장모드에서 사건 연쇄로 확장하는 작성 절차
변환 절차는 “고장모드 1개 = 위해 시나리오 1개”로 단순화하지 않는 데서 시작합니다. 하나의 고장모드가 여러 사용 장면에서 서로 다른 위해상황을 만들 수 있고, 반대로 서로 다른 고장모드가 동일한 위해상황으로 수렴할 수도 있습니다. 따라서 실무에서는 먼저 FMEA에서 RPN이 높거나 안전 관련 특성이 큰 항목을 우선 대상으로 선정한 뒤, 각 항목에 대해 사용 장면을 1개씩 고정해 시나리오를 씁니다. 동일 고장모드라도 “초기 설정 중”인지, “사용 중 모니터링 단계”인지, “데이터 전송/저장 단계”인지에 따라 사건 연쇄가 달라지기 때문입니다.
작성은 문장 길이를 늘리는 작업이 아니라, 사건을 최소 단위로 쪼개어 연결하는 작업입니다. 추천하는 문법은 “조건 → 실패 사건 → 시스템 반응 → 사용자 인지/행동 → 위해상황 → 위해” 순서입니다. 예를 들어 FMEA에 ‘임계값 계산 오류’가 있다면, 시나리오는 “특정 입력 범위(조건)에서 연산 오버플로우 발생(실패 사건) → 값이 정상 범위로 클램핑됨(시스템 반응) → 화면에는 정상 수치로 표시되어 사용자가 이상을 인지하지 못함(사용자 인지 실패) → 알람이 발생하지 않은 상태로 사용 지속(위해상황) → 이상 상태 대응 지연으로 치료 지연(위해)”처럼 구성합니다. 이때 ‘시스템 반응’과 ‘사용자 인지/행동’을 반드시 분리하면, 단순 기능 오류가 실제 위해로 이어지는 경로가 명확해지고, 통제의 위치가 선명해집니다.
여기서 자주 빠지는 요소가 “탐지 가능성”입니다. FMEA의 Detection 점수가 낮다고 해서 시나리오에서 자동으로 ‘잘 탐지된다’고 결론 내리면 위험합니다. 위해 시나리오에서는 탐지를 (1) 시스템 내부 탐지, (2) 사용자에게 전달, (3) 사용자의 해석과 행동으로 나눠야 합니다. 알람이 울려도 임상 워크플로우 상 무시될 수 있고, 표시가 있어도 UI에서 묻힐 수 있으며, 로그가 남아도 현장에서 확인 불가할 수 있습니다. 따라서 시나리오에 “탐지 실패 또는 전달 실패 또는 해석 실패” 중 적어도 하나의 가능성을 명시적으로 포함시키고, 어떤 조건에서 그 실패가 강화되는지(소음 환경, 야간 근무, 동시 알람 과다, 화면 밝기, 네트워크 혼잡 등)를 촉진 조건으로 적어두면 누락이 줄어듭니다.
마지막으로, 사건 연쇄는 “가능한 모든 사건”을 쓰는 게 아니라, 위해를 만들 만큼 중요한 경로를 선택해야 합니다. 선택 기준은 (1) 위해로 직접 연결되는지, (2) 통제가 개입할 수 있는지, (3) 검증으로 재현 가능한지입니다. 이 세 기준을 통과하는 사건만 남기면 시나리오가 과도하게 비대해지지 않으면서도, 심사 관점에서 설명 가능한 수준의 구체성이 확보됩니다. 2단계의 결론은 고장모드를 문장으로 늘리는 것이 아니라, FMEA 정보를 사용 장면 위에서 사건의 연쇄로 재구성하는 것입니다.
3) 통제·검증·잔여위험까지 시나리오로 닫기
FMEA를 위해 시나리오로 바꾸는 목적은 “문서 형태를 바꾸는 것”이 아니라, 통제와 검증을 위해 경로에 정확히 걸어두는 것입니다. 그래서 3단계에서는 시나리오의 각 사건 고리에서 “어디를 끊을 것인가”를 먼저 표시하고, 그 지점에 통제를 배치합니다. 통제는 일반적으로 내재 안전 설계, 보호장치/알람, 정보제공의 우선순위를 따르되, 소프트웨어 의료기기에서는 설정 정책, 권한 관리, 변경관리, 감사로그도 통제로서 의미가 크기 때문에 시나리오에 포함시키는 편이 실무적입니다. 예를 들어 “설정값 변경”이 위해 경로를 여는 고리라면, 권한 분리와 기본값 고정, 변경 이력 기록, 변경 시 경고와 확인 단계가 통제로 연결되어야 합니다.
검증(Verification) 역시 “기능 동작 확인”에서 끝나면 위해 시나리오 문서로서 설득력이 약해집니다. 시나리오 기반 검증은 통제가 끊어야 할 사건 고리를 재현하는 조건을 시험으로 구성합니다. 예를 들어 네트워크가 촉진 조건이라면 정상 통신만 시험할 것이 아니라 지연, 단절, 재연결, 패킷 손실에서 이벤트 처리와 상태 전이가 안전하게 유지되는지 확인해야 합니다. UI 해석 실패가 사건 고리라면 단순 스크린샷 검토가 아니라, 경고의 가시성, 용어의 오해 가능성, 작업 흐름에서 경고가 등장하는 타이밍이 실제로 행동 변화를 만드는지(필요 시 제한적 사용성 검증)까지 확인해야 합니다. 즉 검증 케이스는 “고장모드가 발생한다”를 보여주는 것이 아니라, “통제가 위해 경로를 끊는다”를 입증해야 합니다.
잔여위험(Residual Risk)은 시나리오의 마지막에서 반드시 닫아야 하는 요소입니다. 통제가 있어도 남는 위험은 사용자에게 전달되어야 하고, 전달 방식이 ‘탐지/해석 실패’ 고리를 줄이는 방향이어야 합니다. 따라서 시나리오마다 “잔여위험이 남는 이유”, “사용자에게 요구되는 행동”, “라벨/IFU/교육/현장 공지에 반영되는 문구 또는 위치”를 연결합니다. 이때 흔한 실수는 “주의하십시오” 같은 일반 문구로 통제를 끝내는 것인데, 시나리오 관점에서는 상황-원인-행동이 구체적이어야 합니다. 예컨대 어떤 화면에서 어떤 경고가 뜨면 사용자가 무엇을 중단하고 무엇을 확인해야 하는지까지 연결되어야 정보제공 통제가 통제로 기능합니다.
마지막으로 PMS(사후관리)와 변경관리 트리거를 함께 붙이면 문서가 살아 움직입니다. 릴리스 후 불만/오류 로그/현장 피드백에서 어떤 신호가 관측되면 해당 시나리오의 발생확률 가정이나 통제 효과를 재평가할지, 임계치와 담당 부서를 정해 두면 시나리오는 ‘작성’에서 ‘운영’으로 전환됩니다. 정리하면 3단계의 목표는 통제·검증·정보제공·PMS를 시나리오의 사건 흐름 위에 올려, 한 줄로 추적 가능한 근거 체계로 완성하는 것입니다.