1) 변경 분류와 추적성 기준 설정
소프트웨어 의료기기에서 변경관리는 ‘업데이트를 잘하는 일’이 아니라, 변경으로 인해 환자·사용자·데이터에 미치는 영향을 예측하고 통제하는 체계입니다. 같은 기능 개선이라도 의도된 사용 목적, 임상적 주장, 사용자 인터랙션, 알람 로직, 데이터 처리 방식이 조금만 달라지면 위험 양상이 바뀔 수 있습니다. 따라서 실무에서는 먼저 변경을 ‘무엇이 달라졌는가’가 아니라 ‘무슨 위해 시나리오를 만들 수 있는가’ 관점으로 분류합니다. 예를 들어 버그 수정이라도 특정 조건에서만 발생하던 오동작을 고치면서 임계값 계산을 바꿨다면, 이는 단순 수정이 아니라 성능 특성의 변화로 취급해야 합니다. 반대로 UI 문구 수정처럼 기능·알고리즘·알람이 그대로라면 위험 영향이 제한적일 수 있지만, 사용성 관점의 오해 가능성은 별도로 점검해야 합니다.
변경 분류는 보통 기능 변경, 성능 변경, 임상 주장/사용 목적 변경, 위험통제 변경, 사이버보안 변경, 외부 인터페이스 변경, 플랫폼/라이브러리 변경으로 나눠 보면 누락이 줄어듭니다. 이때 핵심은 ‘규모’가 아니라 ‘규제적으로 의미 있는 기준점이 무엇인지’를 설정하는 것입니다. 기준점에는 요구사항(사용자 요구·시스템 요구), 위험관리 파일의 위해 시나리오, 임상평가에서의 주장 범위, 라벨·사용설명서의 핵심 경고, 소프트웨어 안전등급/클래스, 그리고 사이버보안 위협 모델이 포함됩니다. 변경이 이 기준점 중 하나라도 건드린다면, 그 변경은 자동으로 상위 수준의 영향평가와 검증 범위가 적용되도록 규칙을 만들어야 합니다.
실무에서 자주 발생하는 실패는 “릴리스 노트에 적었으니 충분하다”는 착각입니다. 심사나 내부 감사에서는 변경 사유와 설계 결정, 위험 영향, 검증 근거, 배포 통제가 한 줄로 연결되어야 합니다. 즉 변경요청서 하나로 끝내는 것이 아니라, 변경이 어느 요구사항을 수정했고 어떤 위험통제를 추가·삭제·완화했으며, 그에 따라 어떤 시험이 새로 필요해졌는지 추적 가능해야 합니다. 결국 변경 분류 단계의 목적은 ‘할 일을 줄이는 것’이 아니라, 해야 할 일을 빠짐없이 정의해 이후 단계의 비용 폭탄을 막는 것입니다.
2) 영향평가와 위험관리 근거 패키지
변경 영향평가의 산출물은 “영향이 없다”라는 문장이 아니라, 영향이 없다고 말할 수 있는 근거의 묶음입니다. 이를 위해서는 세 가지 축을 동시에 돌려야 합니다. 첫째는 요구사항·설계·코드·시험의 추적성입니다. 변경된 기능이 어느 요구사항에 매핑되는지, 해당 요구사항이 어떤 위험통제를 담고 있는지, 그 위험통제가 어떤 시험으로 검증되는지 ‘한 눈에’ 확인 가능해야 합니다. 둘째는 위험관리(ISO 14971 관점)입니다. 변경으로 위해 시나리오의 발생 확률이나 심각도가 바뀌지 않는지, 새로운 위험원이 추가되지 않는지, 기존 위험통제가 무효화되지 않는지를 평가해야 합니다. 셋째는 운영환경과 데이터입니다. 클라우드 연동, 로컬 저장, 로그 수집, 모델 업데이트처럼 환경 의존성이 있는 요소는 기능이 같아도 결과가 달라질 수 있으므로, 환경 변화까지 포함해 영향 범위를 확정해야 합니다.
실무적으로는 ‘변경 영향평가 체크리스트’를 만들되, 체크리스트를 답변형으로 끝내지 말고 증빙 링크를 강제하는 구조가 효과적입니다. 예를 들어 “알람/경보 로직 변경 여부” 항목을 ‘예/아니오’로 체크하는 대신, 로직이 정의된 요구사항 ID, 변경 전후 결정표(또는 상태전이 다이어그램), 관련 단위시험·통합시험 케이스 번호를 함께 기록하도록 템플릿을 설계합니다. UI 변경이라면 IEC 62366 관점에서 사용 오류 가능성, 경고 문구의 의미 변형, 작업 흐름의 단계 수 변화, 시각적 강조의 이동을 확인하고, 필요 시 제한적 사용성 검증을 계획합니다. 사이버보안 변경이라면 위협 모델(자산·공격면·완화책)에서 어떤 항목이 달라졌는지, 인증·암호화·키 관리·권한 모델이 변경되었는지, 취약점 스캔과 침투 테스트 범위가 달라져야 하는지를 명시해야 합니다.
또 하나의 핵심은 ‘규제 제출 여부 판단’입니다. 모든 변경을 외부에 보고하는 것이 목표가 아니라, 보고가 필요한 변경을 놓치지 않는 것이 목표입니다. 그래서 조직 내부에서는 변경을 ‘경미/중대’로만 나누기보다, 제출 필요성 관점의 트리 구조로 정의하는 편이 실무적입니다. 예를 들어 (1) 의도된 사용 목적·임상 주장·성능 지표 변경, (2) 위험통제의 추가/삭제/완화, (3) 외부 인터페이스·데이터 흐름·보안 아키텍처 변경, (4) 플랫폼(운영체제, 컴파일러, 주요 라이브러리) 변경, (5) 사용자 교육/라벨 변경을 트리의 상위 노드로 두고, 해당 노드에 걸리면 자동으로 심화 평가와 문서 업데이트가 트리거되도록 만듭니다. 이렇게 하면 담당자의 경험에 의존하던 판단이 규칙 기반으로 전환되어, 릴리스 속도와 규제 안전성이 동시에 개선됩니다.
3) 검증·배포 통제와 사후 모니터링 연계
검증·밸리데이션 단계에서 중요한 것은 ‘테스트를 많이 했다’가 아니라 ‘변경의 위험에 비례한 시험 설계를 했다’는 설명 가능성입니다. 기본은 회귀시험(regression) 범위 재설계입니다. 변경된 모듈만 시험하면 된다고 생각하기 쉽지만, 의료기기 소프트웨어는 공유 라이브러리·상태 관리·타이밍 이슈로 인해 비변경 영역에서도 위해가 발생할 수 있습니다. 따라서 영향평가에서 도출된 위해 시나리오와 요구사항을 기준으로, 필수 회귀 세트를 유지하고 변경에 따라 확장하는 구조가 안전합니다. 단위시험은 ‘정상 동작’뿐 아니라 경계값, 오류 처리, 타임아웃, 데이터 손상, 네트워크 단절 같은 실패 모드를 포함해야 하며, 통합시험은 센서/장비 연동, 데이터 변환, 알람 발생 조건, 기록·감사로그의 무결성까지 포함해야 합니다. 소프트웨어만으로 끝나지 않고, 필요 시 시스템 수준의 성능 검증이나 임상적 동등성 검토로 연결되어야 합니다.
배포 관리는 변경관리의 마지막이자 실제 위해가 발생하는 지점입니다. 따라서 배포는 기술팀의 권한이 아니라 품질 시스템의 통제 하에 있어야 합니다. 실무에서는 (1) 릴리스 승인 게이트, (2) 버전·형상(Configuration) 통제, (3) 롤백 계획, (4) 현장 적용 조건, (5) 고객 공지와 교육 자료 업데이트를 최소 구성요소로 둡니다. 릴리스 승인 게이트에서는 영향평가서, 위험관리 업데이트, 시험 요약 보고서, 미해결 이슈(known anomaly) 목록, 사이버보안 스캔 결과가 한 묶음으로 검토되어야 합니다. 버전·형상 통제는 소스코드 버전뿐 아니라 빌드 환경, 컴파일 옵션, 서드파티 라이브러리 해시, 배포 패키지 서명, 서버 설정까지 포함해야 재현성이 확보됩니다. 특히 클라우드 기반 기능이 있다면 서버 측 변경도 동일한 변경관리 절차를 거치도록 규정해야 하며, “서버는 제품이 아니다”라는 예외를 두는 순간 데이터 무결성과 보안 리스크가 커집니다.
마지막으로 사후관리(PMS)와 변경관리를 연결해야 합니다. 릴리스 후에는 단순히 오류 건수를 보는 것이 아니라, 변경 전후의 알람 빈도, 사용자 조작 패턴, 임상적 성능 지표(가능한 경우), 불만 유형 분포, 취약점 보고 동향을 비교해 ‘변경의 효과와 새로운 위험’을 조기에 포착해야 합니다. 이때 로그와 원격 업데이트를 활용하더라도 개인정보·의료정보 보호 원칙을 우선 적용하고, 수집 목적과 보관 기간, 접근 권한을 명확히 해야 합니다. 결국 소프트웨어 의료기기 변경관리의 목표는 업데이트 자체가 아니라, 업데이트가 안전하고 예측 가능한 방식으로 운영되도록 만드는 것입니다. 이 체계가 자리 잡으면 릴리스는 느려지는 것이 아니라, 불필요한 재작업과 리콜 리스크가 줄어 장기적으로 더 빨라집니다.