개념
위험 기반 테스트가 규제 요건이 될 때
모듈 4 레슨 2에서 리스크 기반 테스트(RBT)를 배웠다. 리스크를 식별하고, 가능성과 영향으로 우선순위를 매기고, 우선순위가 높은 곳에 시험을 집중했다. 그때 리스크 분석은 QA가 시험을 배분하기 위한 도구 였다.
의료기기에서는 방향이 반대다. 위험관리는 제품 설계를 결정하는 규제 프로세스 이고, 시험은 그 결정이 실제로 작동한다는 증거 다. ISO 14971:2019는 의료기기 위험관리의 국제 표준이고, 유럽에서는 EN ISO 14971:2019+A11:2021로 조화 표준이 되어 있으며, 미국 FDA도 인정 표준으로 쓴다. 이 레슨의 질문은 위험관리 파일의 어느 줄에 어떤 시험 기록이 붙어야 하는가 다.
용어의 사슬 — 시험 가능한 단위로 쪼개기
ISO 14971은 위험을 한 단어로 보지 않고 사슬로 본다.
위해 요인(hazard) 피해의 잠재적 원천
↓ 사건의 연쇄
위해 상황(hazardous situation) 사람·재산·환경이 위해 요인에 노출된 상황
↓
피해(harm) 신체적 부상, 건강 피해그리고 위험(risk)은 피해의 발생 확률과 심각도의 조합 이다. 확률은 다시 둘로 나뉜다.
P1 = 위해 상황이 발생할 확률
P2 = 위해 상황이 피해로 이어질 확률
피해 발생 확률 = P1 × P2인슐린 펌프 앱으로 예를 들자.
| 사슬 | 내용 |
|---|---|
| 위해 요인 | 과다한 인슐린 에너지(약물) |
| 사건의 연쇄 | 사용자가 식사량 입력 → 앱의 단위 변환 결함으로 탄수화물 g을 10배로 계산 → 추천 투여량 과다 표시 → 사용자가 확인 없이 승인 → 펌프 투여 |
| 위해 상황 | 환자가 과다 용량 인슐린에 노출됨 |
| 피해 | 저혈당, 의식 저하 |
이 사슬에서 QA가 볼 것은 각 화살표가 시험 가능한 사건 이라는 점이다. "단위 변환 결함"은 단위 시험 대상, "확인 없이 승인"은 사용적합성 평가 대상(레슨 3), "펌프 투여"는 시스템 시험 대상이다. 위험 통제 조치는 이 사슬의 어느 화살표를 끊는가 로 설명된다.
소프트웨어 원인에서 확률을 다루는 법
모듈 25와 레슨 1에서 소프트웨어 고장 확률은 추정할 수 없다고 했다. 그렇다면 소프트웨어가 원인인 위험에서 P1을 어떻게 적는가.
실무에서 널리 쓰이는 접근은 소프트웨어 결함이 일어날 확률은 1로 두고, 확률 추정을 사슬의 나머지 부분 에서 하는 것이다. ISO/TR 24971:2020(ISO 14971 적용 지침)도 확률을 추정하기 어려운 경우 심각도 중심으로 평가하는 방식을 설명한다.
P1 의 소프트웨어 부분 = 1 (결함이 있다고 가정)
P1 의 나머지 = 결함이 발현되는 입력 조건이 실제로 쓰일 빈도, 다른 경로로 걸러지지 않을 확률
P2 = 과다 용량 노출이 실제 피해로 이어질 확률 (임상 근거)이 접근의 시험 함의는 분명하다. 소프트웨어 결함이 없다는 것을 시험으로 증명해 위험을 낮출 수는 없다. 시험으로 낮출 수 있는 것은 결함이 있어도 위해 상황까지 가지 않게 하는 통제 조치가 동작한다는 확신 이다. 그래서 위험관리 파일에서 시험 기록은 대개 "결함 없음"이 아니라 "통제 조치가 동작함"에 붙는다.
위험 통제 조치의 우선순위
ISO 14971 7.1은 통제 방법을 이 순서로 검토하라고 한다.
| 순위 | 방법 | 인슐린 앱 예 | 시험의 성격 |
|---|---|---|---|
| 1 | 설계에 의한 본질적 안전 | 단위 변환을 하지 않도록 입력 단위를 하나로 고정 | 설계 검증 — 그 경로가 존재하지 않음 |
| 2 | 의료기기 자체 또는 제조 공정의 보호 조치 | 추천 투여량이 체중 기반 상한을 넘으면 차단 + 경보 | 기능 시험 — 조건에서 차단·경보 동작 |
| 3 | 안전 정보 (경고·사용 설명·교육) | "투여 전 추천 값을 반드시 확인하세요" 표시 | 사용적합성 평가 — 사용자가 실제로 읽고 행동하는가 |
순서가 중요한 이유는 아래로 갈수록 효과를 증명하기 어렵기 때문이다. 경고 문구 하나 넣고 "위험 통제 완료"로 닫는 것이 가장 흔한 지적 사항이다. 경고 문구가 효과가 있다는 증거는 레슨 3의 총괄 평가에서 사용자가 실제로 경고를 보고 행동을 바꿨다는 관찰 기록이어야 한다. 위 순위를 건너뛰어 3순위만 쓴 경우, 1·2순위가 왜 실현 불가능했는지 를 기록으로 남겨야 한다.
구현 검증과 효과 검증은 다른 시험이다
ISO 14971 7.2는 각 위험 통제 조치에 대해 두 가지를 검증하라고 한다. 구현되었는가 와 효과가 있는가. 이 둘을 한 시험으로 뭉뚱그리는 것이 실무에서 가장 흔한 약점이다.
| 구현 검증 | 효과 검증 | |
|---|---|---|
| 질문 | 통제 조치가 명세대로 만들어졌는가 | 통제 조치가 실제로 위험을 줄였는가 |
| 상한 차단 예 | 체중 70kg, 상한 초과 입력 → 차단 + 경보 표시 확인 | 상한 값 자체가 저혈당을 막기에 적절한가, 경보가 사용자 행동을 멈추게 하는가, 차단을 우회하는 경로가 없는가 |
| 주 방법 | 요구사항 기반 시스템 시험, 코드 리뷰 | 경계·오류 주입 시험, 사용적합성 총괄 평가, 임상 근거·문헌, 위해 시나리오 재현 |
| 판정 | 명세 대비 합부 | 위해 사슬이 끊어지는지 |
효과 검증의 핵심은 위해 사슬을 다시 따라가 보는 것 이다.
[RC-07 체중 기반 상한 차단 — 효과 검증 계획]
사슬 재현: 단위 변환 결함을 시험 빌드에 주입(결함 주입) → 과다 추천 발생 → 상한 차단이 동작하는가
우회 경로: 수동 투여 입력 화면, 이전 투여 반복 기능, 오프라인 모드, 펌프 직접 조작 연동
경계: 체중 입력 없음·단위 lb 설정·체중 갱신 전 캐시 값
경보 효과: 총괄 평가에서 과다 추천 시나리오 12명 중 차단 후 재입력 행동 관찰 (레슨 3)
상한 적절성: 임상 자문 기록 CA-2026-04 의 근거 인용
결과 기록: 각 항목 합부 + 발견된 우회 경로와 조치첫 줄 결함 주입 이 효과 검증의 가장 강력한 방법이다. 통제 조치는 결함이 있을 때 동작해야 하므로, 결함이 없는 정상 빌드에서는 효과를 볼 수 없다. 모듈 39 레슨 7의 장애 주입이 의료기기 위험관리에서는 이런 형태로 쓰인다.
우회 경로 가 가장 자주 결함을 찾는다. 메인 투여 화면에는 상한 차단이 있는데 "지난 투여 반복" 버튼 경로에는 없는 식이다. 모듈 3의 유즈케이스 기반 테스트로 같은 결과에 도달하는 모든 경로를 나열하면 찾을 수 있다.
통제 조치가 만드는 새 위험
7.5는 위험 통제 조치가 새로운 위해 요인이나 위해 상황을 만드는지 검토하라고 한다. 소프트웨어 통제 조치에서 자주 생기는 새 위험이다.
| 통제 조치 | 만들 수 있는 새 위험 | 검증 |
|---|---|---|
| 상한 초과 시 차단 | 실제로 고용량이 필요한 환자의 치료 지연 | 의료진 해제 경로의 존재와 시험 |
| 반복 경보 | 경보 피로로 중요한 경보를 무시 | 경보 빈도 분석, 사용적합성 평가 |
| 입력 재확인 대화상자 | 반복 확인 습관화로 확인 없이 누름 | 총괄 평가에서 확인 행동 관찰 |
| 통신 두절 시 자동 중단 | 필요한 투여가 중단됨 | 중단 시 사용자 알림·대체 절차 시험 |
새 위험이 발견되면 위험관리 파일에 새 줄로 들어가고, 그 위험의 통제 조치와 검증이 다시 필요하다. 통제 조치 목록이 줄지 않고 늘어나는 것이 정상 이다.
위험 추적표 — 한 줄에 모든 연결
위험관리 파일의 핵심 산출물은 위험 분석과 통제·검증을 한 줄로 잇는 추적표다. QA가 가장 많이 채우는 오른쪽 열을 보자.
위험 ID 위해 상황 원인(소프트웨어) 심각도 통제 전 통제 조치 요구사항 구현 검증 효과 검증 잔존 위험 새 위험
R-031 과다 인슐린 노출 단위 변환 결함 심각 수용불가 RC-07 상한 차단(보호) SRS-221 ST-221-01~06 FI-07·UE-S-04·CA-04 수용 R-044
RC-08 추천값 확인 표시(정보) SRS-222 ST-222-01~03 UE-S-05
R-044 고용량 필요 환자 RC-07 의 차단 중간 수용불가 RC-12 의료진 해제 경로 SRS-240 ST-240-01~04 UE-S-09 수용 —
치료 지연ST- 는 시스템 시험, FI- 는 결함 주입 시험, UE-S- 는 사용적합성 총괄 평가 시나리오, CA- 는 임상 자문 기록이다. 효과 검증 열이 구현 검증 열과 같은 시험 ID로 채워져 있으면
두 검증을 구분하지 않은 것이다. 심사관이 가장 먼저 보는 열 중 하나다.
이 추적표는 레슨 1의 요구사항 ↔ 시험 추적표와 같은 ID를 공유 해야 한다. 위험관리 쪽 추적표와 소프트웨어 쪽 추적표가 따로 관리되면, 요구사항 SRS-221이 변경됐을 때 그것이 위험 통제 조치였다는 사실을 개발팀이 모를 수 있다. 요구사항에 "위험 통제 조치" 표시를 달고, 표시된 요구사항의 변경은 위험관리 검토를 거치게 한다.
잔존 위험과 출시 후 정보
통제 후에도 남는 위험(잔존 위험)은 수용 기준에 따라 평가하고, 모든 잔존 위험을 합친 전체 잔존 위험 을 의료적 이익과 비교해 평가한다(8장). 레슨 1의 잔존 이상 평가는 여기에 입력으로 들어간다.
10장은 생산 및 생산 후 정보 를 수집해 위험관리에 되먹이라고 한다. 출시 후 불만·사고 보고·서비스 기록·문헌에서 새 위해 요인이나 잘못 추정한 확률이 드러나면 위험관리 파일을 갱신한다. 모듈 37 레슨 3의 문제 관리가 의료기기에서는 이 환류의 입구가 된다. QA가 해야 할 일은 출시 후 결함이 위험 추적표의 어느 줄에 해당하는지 연결하고, 해당 줄이 없으면 새 위험으로 올리는 것이다. "효과 검증 완료"였던 통제 조치가 현장에서 뚫렸다면, 효과 검증 방법 자체가 부족했다는 뜻이다.
실무에서 왜 필요한가
의료기기 인허가 심사에서 위험관리 파일은 설계 문서만큼 중요하다. 그리고 위험관리 파일의 신뢰성은 통제 조치마다 붙은 검증 증거의 질 로 판단된다. 구현 검증만 있고 효과 검증이 없는 파일, 경고 문구로만 닫힌 위험, 통제 조치가 만든 새 위험이 검토되지 않은 파일은 보완 요구로 돌아온다.
QA에게 이 레슨의 기술은 리스크 기반 테스트 경험을 규제 언어로 번역 하는 일이다. 결함 주입으로 통제 조치를 시험하고, 같은 결과에 이르는 우회 경로를 찾고, 통제 조치의 부작용을 의심하는 습관은 QA가 이미 갖고 있는 감각이다. 의료기기 QA 면접에서 "구현 검증과 효과 검증을 어떻게 다르게 설계했는가"는 거의 반드시 나오는 질문이다.