1) UI 변경을 “사용성 이슈”가 아니라 “안전 사건 흐름”으로 분류한다
UI 수정은 겉보기에는 화면 문구나 배치의 변화로 끝나지만, 실제로는 사용자의 인지–해석–행동 경로를 바꾸는 변경입니다. 따라서 변경관리에 연결하려면 “UI가 바뀌었다”라는 기술이 아니라, 어떤 사용자 행동이 달라지고 그로 인해 어떤 위해상황이 열릴 수 있는지를 먼저 정의해야 합니다. 실무에서 가장 많이 놓치는 구간은 ‘경미한 수정’으로 분류해 버린 UI 변경이 위험통제를 무력화하는 경우입니다. 예컨대 확인(confirmation) 단계의 버튼 위치 변경, 기본값 유지 정책 변경, 경고 문구의 표현 완화, 화면에서 안전 관련 정보의 강조도 감소는 사용자의 행동을 무의식적으로 바꿉니다. 이런 변화는 기능 요구사항을 직접 수정하지 않더라도, 위해 시나리오에서 “탐지/전달/해석 실패” 고리를 강화해 잔여위험을 키울 수 있습니다.
그래서 UI 변경은 먼저 안전 영향 기준으로 분류하는 규칙이 필요합니다. 실무적으로는 다음 네 가지 축이 유용합니다. (1) 결정 지점 변경: 사용자가 안전 관련 결론을 내리는 지점(환자 선택, 모드 선택, 임계값 입력, 결과 승인, 알람 확인)의 화면/흐름이 바뀌는가. (2) 가드레일 변경: 차단/강제/유도 통제(범위 제한, 단계 강제, 이중 확인, 위험 모드 진입 장벽)가 약화·강화되는가. (3) 신호 변경: 경고/알람/상태 표시의 가시성·우선순위·표현이 바뀌는가(알람 피로 또는 경고 무시를 유발할 수 있는가). (4) 기본값/자동화 변경: 자동 선택, 최근 항목 유지, 자동 전송 같은 자동화가 사용자 확인을 대체하는가. 이 네 축 중 하나라도 해당되면, UI 변경은 단순 미관 변경이 아니라 RMF 재평가 트리거로 자동 승격시키는 것이 안전합니다.
추가로, “문구만 바꿨다”는 주장도 그대로 받아들이면 위험합니다. 문구의 변화는 사용자의 해석을 바꾸고, 특히 ‘금지/주의/권고’의 강도, 조건의 범위, 행동 지침의 구체성이 달라지면 정보제공 통제가 사실상 변경됩니다. 즉 IFU/라벨과 동일하게 UI 문구도 위험통제의 일부로 취급해야 하며, 안전 관련 문구는 변경 시 반드시 위험관리 담당 검토와 근거(왜 안전성이 유지되는지)를 남기는 규칙이 필요합니다. 결론적으로 1단계 규칙은 “UI 변경을 화면 단위가 아니라 위해 시나리오의 사건 고리 단위로 분류하고, 결정 지점·가드레일·신호·기본값 변화는 RMF 재평가를 자동 트리거한다”입니다.
2) RMF 재평가 범위는 “영향 경로 길이”로 산정한다
UI 수정 시 RMF 재평가 범위를 정하는 핵심은 변경의 ‘크기’가 아니라 안전 영향 경로가 얼마나 길게 전파될 수 있는가입니다. 실무에서 효과적인 방법은 변경점(UI 요소)을 출발점으로, 요구사항–위해 시나리오–위험통제–검증의 추적성을 따라가며 범위를 확정하는 것입니다. 먼저 변경된 화면/흐름이 어떤 요구사항을 구현하는지(기능 요구사항뿐 아니라 사용성 요구사항, 안전 관련 요구사항)를 식별합니다. 그 다음 해당 요구사항이 연결된 위해 시나리오를 찾고, 그 시나리오에서 UI가 담당하는 사건 고리(인지/해석/행동/전달)를 표시합니다. 이 표시가 끝나면 “RMF에서 무엇을 다시 써야 하는지”가 자연스럽게 결정됩니다.
범위 산정 규칙은 보통 3단계로 정리하면 안정적으로 운영됩니다. 레벨 1(국소 재평가): 오타, 단순 레이아웃 정렬, 색상 변경처럼 안전 관련 정보의 가시성과 결정 지점에 영향이 없고, 가드레일·기본값·경고 의미가 변하지 않는 경우입니다. 이때도 “안전 무영향” 근거를 남겨야 하며, 최소한 관련 화면의 스크린샷 전후 비교와 체크리스트(결정 지점/가드레일/신호/기본값 영향 없음)를 변경관리 패키지에 포함시키는 것이 좋습니다. 레벨 2(시나리오/통제 재평가): 경고 문구, 알람 표시, 확인 단계, 환자/대상 식별 UI, 모드 전환 흐름처럼 사용자의 판단과 행동을 바꾸는 변경입니다. 이 경우 RMF에서 해당 위해 시나리오의 사건 흐름(특히 탐지/전달/해석 단계)을 업데이트하고, 위험통제가 UI에 의존하는 부분(정보제공 통제, 강제 기능, 유도 설계)의 적절성을 재평가해야 합니다. 레벨 3(안전 주장의 재평가): 의도된 사용 흐름 자체가 바뀌거나, 자동화로 인해 사용자 확인이 대체되거나, 기본값 정책이 안전 경계를 바꾸는 변경처럼 안전 개념(Safety Concept) 또는 핵심 통제 전략이 바뀌는 경우입니다. 이 경우는 RMF 일부 수정으로 끝내기 어렵고, 사용성 엔지니어링 파일과 검증 전략(회귀/사용성 검증)까지 확장되어야 합니다.
범위를 과소평가하지 않기 위한 실무 질문도 함께 규칙화하는 것이 좋습니다. 예를 들어 “이 UI 변경으로 사용자가 더 빨리 진행할 수 있게 되었는가(확인 단계가 사실상 약화되었는가)?”, “경고/상태가 한 화면 내에서 덜 보이게 되었는가?”, “기본값이 이전 상태를 더 오래 유지하는가?”, “사용자 입력 오류를 차단하던 제약이 완화되었는가?”, “오사용 발생 시 시스템이 이를 탐지해 되돌릴 수 있는가?” 같은 질문은 UI 변경이 위험통제를 무력화하는 전형적 패턴을 빠르게 드러냅니다. 결론적으로 2단계 규칙은 “UI 변경점에서 시작해 추적성을 따라 영향 경로를 펼치고, 레벨 1–2–3로 RMF 재평가 범위를 표준화한다”입니다.
3) 재평가 결과는 검증과 릴리스 게이트로 ‘증빙 패키지’화한다
RMF 재평가 범위가 정해졌다면, 다음은 그 재평가가 실제로 안전성을 유지한다는 것을 검증과 기록으로 닫는 단계입니다. 여기서 흔한 실수는 “UI 변경이니 사용성 문서만 업데이트” 또는 “기능은 그대로니 회귀시험만 수행”처럼 단선적으로 처리하는 것입니다. UI는 기능을 바꾸지 않아도 위해 경로를 바꾸므로, 검증은 “기능 동작”이 아니라 “통제가 위해 사건 고리를 끊는다”를 입증해야 합니다. 예컨대 확인 단계가 변경되었다면, 사용자가 시간 압박 상황에서 우회할 수 없는지(상태 전이/뒤로가기/세션 만료/재시도까지 포함)를 확인해야 하고, 경고 표시가 바뀌었다면 오탐·미탐뿐 아니라 과다 경고로 인한 무시(알람 피로) 가능성까지 검토해야 합니다.
실무에서는 변경 유형에 따라 검증을 세 묶음으로 나누면 효율적입니다. (1) 형상/기능 회귀 검증: 화면이 바뀌면서 연결된 기능이 깨지지 않았는지, 입력 검증·범위 제한·전환 로직이 그대로인지 확인합니다. (2) 위해 시나리오 기반 검증: UI가 담당하던 탐지/전달/해석 고리를 재현하는 조건에서 통제가 작동하는지 확인합니다. 예를 들어 환자/대상 식별 UI 변경이라면 동명이인, 긴 리스트, 바코드 실패, 수동 입력 우회, 세션 전환 조건을 포함해야 합니다. (3) 제한적 사용성 확인: 레벨 2 이상 변경에서는 대표 사용자·대표 환경·대표 과업으로 오사용 빈도 또는 오류 복구 가능성을 확인하는 것이 설득력 있는 근거가 됩니다. 모든 변경마다 대규모 사용성 시험이 필요한 것은 아니지만, “이 변경이 행동을 바꿀 수 있다”는 판단이 섰다면 최소한의 관찰 기반 근거를 남기는 편이 심사/감사 대응에서 강합니다.
마지막으로 이 모든 결과를 릴리스 승인 게이트에 올릴 수 있는 증빙 패키지로 묶어야 변경관리로서 완성됩니다. 패키지에는 최소한 (1) 변경 요약(전/후 화면, 변경 의도), (2) 영향평가(결정 지점/가드레일/신호/기본값 체크 + 레벨 판정), (3) RMF 업데이트 범위(어떤 위해 시나리오/통제가 수정되었는지), (4) 검증 요약(케이스 ID, 수용 기준, 결과), (5) 라벨/IFU/교육 자료 영향(필요 시)까지 포함시키는 것을 표준으로 두면 품질이 안정됩니다. 이렇게 해두면 “UI 수정이 반복되며 RMF가 뒤처지는” 구조적 문제가 사라지고, 오히려 UI 개선이 안전성 근거를 강화하는 방향으로 축적됩니다. 결론적으로 3단계 규칙은 “재평가를 문서 수정으로 끝내지 말고, 위해 시나리오 기반 검증과 릴리스 게이트 증빙 패키지로 닫아 변경관리 체계에 편입한다”입니다.