IEC 62366-1 사용적합성 공학 — 위해 관련 사용 시나리오에서 형성 평가·총괄 평가까지

개념

사용 오류는 사용자의 탓이 아니다

모듈 16 레슨 11에서 사용성 테스트를 배웠다. "되긴 되는데 아무도 못 쓰는 화면"을 찾아 불편을 줄이는 일이었다. 의료기기의 사용적합성 공학은 목적이 조금 다르다. 불편함이 아니라 위해로 이어지는 사용 오류 를 찾아 설계로 통제하고, 그 통제가 효과적이라는 증거 를 남긴다.

전제가 되는 관점 하나. 사용자가 인슐린 용량 단위를 잘못 선택했다면, 그것은 "사용자 부주의"로 닫히지 않는다. IEC 62366-1은 이것을 사용 오류(use error) 로 보고, 사용 오류를 유발한 사용자 인터페이스 설계 를 위험관리 대상으로 본다. 레슨 2의 위해 사슬에서 "사용자가 확인 없이 승인"이라는 화살표를 끊는 일이다.

구분해 둘 용어가 하나 있다. 비정상 사용(abnormal use) 은 제조사가 합리적으로 통제할 수 없는 고의적 오용이나 안전 정보 무시다. 사용 오류와 비정상 사용의 경계를 넓게 잡으면 설계 책임을 사용자에게 넘기게 되므로, 비정상 사용으로 분류할 때는 근거를 기록한다.

사용적합성 공학 프로세스 — QA가 만드는 산출물

IEC 62366-1:2015(2020년 개정 포함)의 프로세스를 산출물 기준으로 따라가 보자. 전체 기록을 모은 것이 사용적합성 공학 파일 이다.

모듈 38 레슨 1의 검증 기준 쓰기와 가장 가까운 것이 6단계 UI 사양 이다. "경고가 눈에 잘 띄어야 한다"가 아니라 시험 가능한 형태로 쓴다.

[UI 사양 — 투여 확인 화면]
UIS-14  추천 투여량은 확인 화면에서 가장 큰 글꼴(최소 32pt 상당)로, 단위와 함께 표시한다
UIS-15  직전 투여량 대비 50% 이상 증가한 추천값은 색상 외에 아이콘·문구로 구분 표시한다 (색각 이상 사용자)
UIS-16  승인 버튼은 추천값 표시 후 1.5초 동안 비활성 상태로 둔다 (습관적 연타 방지)
UIS-17  단위 선택 컨트롤은 투여 흐름 화면에서 변경할 수 없다 (설정 화면에서만)
위험 연결: R-031 / RC-08, R-052 / RC-15

UIS-16 같은 사양은 레슨 2의 통제 조치가 만드는 새 위험(긴급 상황의 지연) 검토 대상이 된다. 사용적합성과 위험관리는 같은 추적표를 공유한다.

위해 관련 사용 시나리오 — 시험 케이스의 원천

위해 관련 사용 시나리오는 사용적합성 시험의 테스트 케이스 목록 이다. 좋은 시나리오 목록은 UI 관점의 고장 모드 목록처럼 읽힌다. 무엇이 잘못될 수 있고, 어떤 조건에서, 어떤 피해로 이어지는가.

[위해 관련 사용 시나리오 HRUS-07]
사용자:     제1형 당뇨 성인 환자 (사용 사양 사용자 그룹 U1)
환경:       외출 중, 밝은 야외, 한 손 사용
과업 순서:  1) 식사량 입력 2) 추천 투여량 확인 3) 승인 4) 투여 완료 확인
위해 요인 연결: 3) 에서 소수점 위치를 오인해 10배 값 승인
위해 상황:  과다 인슐린 노출 (R-031)
심각도:     심각
관련 UI:    UIS-14, UIS-15, UIS-16
총괄 평가:  포함 (심각도 심각)

시나리오를 만들 때 알려진 사용 문제 를 반드시 입력으로 쓴다. 같은 계열 제품의 불만·사고 보고, FDA 사고 보고 데이터베이스, 문헌에 나온 사용 오류는 "예측 가능한" 오류의 가장 강한 근거다. 모듈 5의 탐색적 테스팅에서 오류 추정 체크리스트를 만들던 방식이 여기서 규제 산출물이 된다.

형성 평가와 총괄 평가 — 목적이 다르다

QA가 가장 조심할 점은 형성 평가 결과를 총괄 평가로 쓰는 것 이다. 형성 평가는 프로토타입으로 했고, 그 뒤 화면이 바뀌었으며, 참여자도 개발팀 동료였다면 총괄 평가의 증거가 될 수 없다. 모듈 31 레슨 2의 "시험 대상 식별" 원칙 — 어떤 버전을 시험했는가 — 이 사용적합성 평가에도 그대로 적용된다.

반대로 총괄 평가를 문제 발견의 첫 기회로 쓰는 것 도 위험하다. 총괄 평가에서 심각한 사용 오류가 나오면 설계 변경 후 총괄 평가를 다시 해야 하고, 인허가 일정이 몇 달 밀린다. 형성 평가를 충분히 반복해 총괄 평가에서는 확인만 하도록 계획한다.

FDA 인간공학 가이던스에서 가져올 것

미국 인허가를 준비한다면 FDA의 인간공학 가이던스(2016)를 함께 본다. IEC 62366-1과 구조가 비슷하지만 실무 판단에 자주 인용되는 기준이 있다.

"15명"은 통계적 합격선이 아니라 문제를 발견할 확률을 충분히 높이기 위한 표본 크기다. 15명 중 1명이 핵심 과업에서 사용 오류를 냈다면 "93% 성공이니 합격"이 아니다. 그 한 건의 근본 원인을 분석해야 한다. 이 점을 모르면 사용적합성 시험 결과를 성능 시험처럼 합격률로 보고하는 실수를 한다.

사용 오류의 근본 원인 분석

총괄 평가에서 관찰된 사용 오류는 모듈 32 레슨 5의 원인 분석처럼 구조까지 내려가서 분석한다. "참여자가 부주의했다"로 끝나면 분석이 아니다.

[사용 오류 분석 — 총괄 평가 UE-S-04, 참여자 P11 (U1 그룹)]
관찰:       추천 투여량 12.0 단위를 1.20 으로 읽었다고 사후 인터뷰에서 진술. 승인은 하지 않음 (근접 오류)
과업:       HRUS-07 단계 3 — 핵심 과업
인지 단계:   지각 (표시값을 잘못 읽음)
UI 원인 후보: 야외 조도에서 소수점 대비 부족, ".0" 의 소수점이 글꼴에서 작게 렌더링
관련 사양:   UIS-14 (글꼴 크기는 충족, 소수점 가독성 기준 없음)
재발 가능성: 다른 참여자 2명이 "소수점이 잘 안 보였다" 진술 (오류는 없음)
판단:       잔존 위험 수용 불가 → UIS-14a 추가(정수 투여량은 소수점 미표시), 해당 시나리오 총괄 평가 재수행

오류 분석을 인지 단계(지각·인지·행동)로 나누면 원인이 설계 요소로 연결되기 쉽다. 그리고 오류가 없었던 참여자의 어려움 진술 이 같은 원인을 가리키면, 그것이 근본 원인의 강한 근거가 된다.

식약처 — 독립형 디지털의료기기소프트웨어 사용적합성

국내에서는 디지털의료제품법 체계에 맞춰 식약처가 독립형 디지털의료기기소프트웨어 사용적합성 허가·심사 가이드라인 을 제정해 2025년 초 안내했다. 독립형 소프트웨어의 허가·인증 신청 시 사용적합성 자료를 제출하도록 하는 방향이다. 가이드라인은 IEC 62366-1의 프로세스를 바탕으로 하므로, 위 산출물 체계를 갖추면 국내·해외 제출 자료를 같은 증거에서 만들 수 있다. 제출 범위·형식·면제 조건 같은 세부는 최신 민원인 안내서 판본 으로 확인하고 기준 문서에 판본을 적는다(레슨 6).

소프트웨어 사용적합성에서 QA가 특히 볼 것

독립형 소프트웨어(앱·웹)는 하드웨어 의료기기보다 사용 환경의 변수 가 훨씬 많다. 사용 사양에 따라 총괄 평가와 시스템 시험에 넣을 조건을 정한다.

마지막 줄은 인슐린·약물 용량을 다루는 앱에서 실제로 치명적이다. 소수점을 쉼표로 쓰는 로캘에서 "1,5"가 "15"로 읽히는지 반드시 확인한다.

실무에서 왜 필요한가

의료기기 사고 분석에서 사용 관련 원인은 꾸준히 큰 비중을 차지하고, 규제 당국은 이를 이유로 사용적합성 자료를 점점 엄격하게 요구해 왔다. 국내에서도 독립형 디지털의료기기 소프트웨어에 사용적합성 자료 제출이 요구되면서, 소프트웨어 회사가 이 프로세스를 처음 갖추는 사례가 늘고 있다.

사용성 테스트 경험이 있는 QA는 유리한 출발점에 있다. 다만 두 가지 전환이 필요하다. 하나는 불편을 찾는 시험 에서 위해로 이어지는 사용 오류를 증명하는 시험 으로, 다른 하나는 합격률 보고 에서 관찰된 오류 한 건 한 건의 근본 원인 분석 으로. 면접에서는 "15명 중 1명의 근접 오류를 어떻게 분석하고 설계를 바꿨는가"가 이 전환을 보여준다.

실습 과제

과제 1 — 사용 사양 (15분)

"보호자가 쓰는 소아 해열제 용량 계산 앱"의 사용 사양(의학적 목적·환자군·사용자 그룹·사용 환경·작동 원리)을 쓰고, 총괄 평가에서 사용자 그룹을 몇 개로 나눌지와 이유를 적는다.

과제 2 — 위해 관련 사용 시나리오 (20분)

과제 1의 앱에 대해 위해 관련 사용 시나리오 네 개를 본문 형식으로 쓴다. 적어도 하나는 알려진 사용 문제(체중 kg·lb 혼동, 시럽 농도 선택 오류 등)에서 출발한다.

과제 3 — UI 사양 (15분)

과제 2의 시나리오를 통제하는 UI 사양 다섯 개를 시험 가능한 형태로 쓰고, 각 사양이 만들 수 있는 새 위험을 한 줄씩 적는다.

과제 4 (선택) — 근본 원인 분석 (15분)

"참여자 15명 중 2명이 시럽 농도를 잘못 선택(160mg/5mL 대신 80mg/5mL)했으나 결과 화면을 보고 스스로 수정했다"는 관찰에 대해 본문 형식의 분석을 쓴다. 근접 오류의 판단과 설계 변경 여부를 포함한다.

자가 체크리스트

• 사용 오류를 사용자 부주의가 아니라 설계가 통제할 위험으로 보는 이유를 설명할 수 있다
• 사용 오류와 비정상 사용을 구분하고 분류 근거를 남기는 이유를 안다
• IEC 62366-1 프로세스 아홉 단계의 산출물을 말할 수 있다
• UI 사양을 시험 가능한 형태로 쓰고 위험 추적표와 연결할 수 있다
• 알려진 사용 문제를 입력으로 위해 관련 사용 시나리오를 쓸 수 있다
• 형성 평가와 총괄 평가의 목적·조건·결과 처리 차이를 설명할 수 있다
• FDA 가이던스의 핵심 과업·사용자 그룹별 15명·근접 오류 관찰의 의미를 안다
• 사용적합성 결과를 합격률이 아니라 근본 원인 분석으로 다뤄야 하는 이유를 안다
• 독립형 소프트웨어의 사용 환경 변수를 총괄 평가·시스템 시험 조건으로 옮길 수 있다

흔한 실수

사용 오류를 "사용자 교육 부족"으로 닫는다. 교육은 가장 약한 통제 조치다.

형성 평가 결과를 총괄 평가로 제출한다. 최종 설계·대표 사용자·실제 조건이 아니면 증거가 되지 않는다.

총괄 평가에서 처음으로 문제를 찾는다. 형성 평가를 반복해 총괄 평가는 확인이 되게 한다.

15명 중 14명 성공을 합격으로 보고한다. 핵심 과업의 오류 한 건은 분석 대상이다.

근접 오류와 어려움 진술을 기록하지 않는다. 근본 원인의 가장 강한 근거다.

로캘·글꼴 확대·알림 권한 조건을 시험하지 않는다. 독립형 소프트웨어의 사용 오류가 가장 많이 숨는 곳이다.

참고 자료

• Applying Human Factors and Usability Engineering to Medical Devices (FDA 가이던스 PDF)
• Formative evaluation: What the FDA and IEC 62366 require (Johner Institute)
• Usability Engineering for Medical Devices according to IEC 62366-1 (Custom Medical)
• IEC 62366 Templates (OpenRegulatory)
• 식약처 독립형 디지털의료기기소프트웨어 사용적합성 허가심사 가이드라인 제정 안내 (한국디지털헬스산업협회)
• 이 커리큘럼 안: 모듈 5 「탐색적 테스팅」, 모듈 16 레슨 7 「접근성」·레슨 11 「사용성 테스트」, 모듈 31 레슨 2 「시험 대상 식별」, 모듈 32 레슨 5 「원인 분석」, 모듈 38 레슨 1, 모듈 40 레슨 2·6