의료기기 시험원이 소프트웨어 밸리데이션 문서를 검토할 때 가장 경계해야 하는 것은 “시험 결과는 많은데, 안전 논리가 닫히지 않는 상태”입니다. 소프트웨어는 변경이 빠르고 기능이 복잡하며, 외부 라이브러리(SOUP: Software of Unknown Provenance) 의존도가 높을수록 리스크가 급격히 커집니다. 따라서 문서 검토의 목표는 단순한 테스트 통과 여부가 아니라, 요구사항–위험관리–아키텍처–검증/확인–형상/변경관리–SOUP 통제가 하나의 추적 체계로 일관되게 연결되어 있는지를 확인하는 데 있습니다. 이번 글에서는 시험원 관점에서 반드시 점검해야 할 소프트웨어 밸리데이션 문서와 SOUP 관리의 핵심 포인트를 구조적으로 정리합니다.
1. 소프트웨어 개발 생명주기 문서와 추적성 기반 검토
소프트웨어 밸리데이션 검토는 “어떤 표준과 절차로 개발·검증했는가”에서 시작합니다. 일반적으로 IEC 62304 기반의 소프트웨어 개발 생명주기(SDLC) 문서 체계가 있어야 하며, 최소한 소프트웨어 개발 계획, 요구사항 명세(SRS), 아키텍처/상세설계, 구현 산출물, 검증·확인 계획과 보고서, 릴리즈 노트, 형상관리(CM)·변경관리, 문제/결함 관리 기록이 서로 연결되어야 합니다. 시험원은 문서들이 개별적으로 존재하는지보다, 동일 버전(릴리즈) 기준으로 동기화되어 있는지를 먼저 확인해야 합니다. 예컨대 요구사항 문서 버전과 시험 보고서 버전이 다르거나, 위험관리에서 통제 대상으로 지정한 소프트웨어 기능이 시험 범위에서 누락되어 있다면 밸리데이션의 신뢰성이 흔들립니다.
추적성(Traceability)은 문서 검토의 핵심 도구입니다. 최소한 요구사항(시스템/소프트웨어) → 설계 요소(모듈, 컴포넌트, 인터페이스) → 구현(코드/빌드) → 시험(단위/통합/시스템/회귀) → 결과(로그, 리포트)로 이어지는 매트릭스가 있어야 하고, 안전 관련 요구사항은 위험관리의 위험 ID와 연결되어야 합니다. 이때 흔한 취약점은 “기능 요구사항은 추적되지만 안전 요구사항은 별도로 빠지는” 경우입니다. 예를 들어 알람 조건, 오류 처리, 안전상태 진입 로직, 데이터 무결성, 접근 권한, 통신 장애 시 동작 등은 안전 요구사항으로 분류되어 별도의 검증 강도가 필요합니다. 시험원은 이러한 항목이 단순 시스템 테스트 ‘몇 개’로 처리되지 않고, 설계 단계부터 명확한 요구사항으로 정의되어 있는지 확인해야 합니다.
또한 소프트웨어 안전등급(예: IEC 62304의 클래스 A/B/C)이 어떻게 결정되었는지도 점검 포인트입니다. 클래스 산정 근거가 위험관리의 유해사건과 일관되는지, 클래스가 낮게 책정되었을 때 그 이유가 “통제수단이 소프트웨어 외부에 있다”는 형태로 논리적으로 설명되는지 확인해야 합니다. 클래스가 낮으면 문서·검증 수준이 완화될 수 있으므로, 산정 근거가 빈약하면 전체 밸리데이션 체계가 과소평가될 가능성이 있습니다. 따라서 시험원은 클래스 산정표, 근거 시나리오, 외부 통제수단(하드웨어 인터록, 독립 보호회로 등)의 검증 근거까지 함께 확인하는 접근이 필요합니다.
2. 검증·확인(V&V) 설계의 완결성과 증적 신뢰성
소프트웨어 V&V는 “테스트 케이스 수”보다 “시험이 설계된 방식”이 중요합니다. 시험원이 확인해야 할 첫 번째 요소는 밸리데이션 계획서의 범위와 기준입니다. 어떤 릴리즈에 대해, 어떤 요구사항을, 어떤 시험 레벨(단위/통합/시스템/사용 환경)에서, 어떤 수용 기준으로 평가했는지 명시되어야 합니다. 특히 안전 관련 요구사항은 단순 정상 시나리오뿐 아니라 오류 주입(예: 통신 끊김, 센서 이상값, 파일 손상, 메모리 부족, 전원 변동)과 경계조건(최대/최소 값, 타이밍, 동시성) 시험이 포함되어야 신뢰성이 올라갑니다. 문서에 이러한 비정상 시나리오가 거의 없다면, 실제 현장에서 발생하는 문제에 취약할 가능성이 높습니다.
시험 증적의 신뢰성도 반드시 확인해야 합니다. 시험 로그가 자동 생성되었는지, 사람이 수동으로 작성한 표만 남았는지, 시험 환경(하드웨어, OS, 컴파일러, 라이브러리 버전, 설정)이 재현 가능하게 기록되어 있는지, 시험 데이터와 결과가 릴리즈 버전과 1:1로 대응하는지 점검하십시오. 소프트웨어 특성상 “다시 해보면 결과가 달라지는” 문제가 발생할 수 있으므로, 빌드 식별자(해시, 태그), CI 결과, 테스트 리포트 원본, 결함 추적 시스템의 티켓과 연결이 남아 있어야 합니다. 시험원은 요약 보고서만 보는 것이 아니라, 최소한 대표 테스트의 원시 로그나 스크린샷, 자동화 리포트의 생성 이력 등 핵심 증적이 존재하는지 확인하는 것이 좋습니다.
결함 관리(버그 트래킹)와 회귀 시험의 연결도 중요합니다. 발견된 결함이 위험관리 측면에서 어떤 영향이 있는지(안전 영향 평가), 수정 후 어떤 시험으로 재검증했는지(회귀 시험 범위), 릴리즈 노트에 어떤 형태로 반영되었는지까지 이어져야 합니다. “결함을 수정했다”는 문장만 있고, 재현 절차·원인 분석·수정 내용·검증 증적이 없으면 밸리데이션의 신뢰성이 떨어집니다. 특히 임상적으로 민감한 기능(투여량 계산, 진단 보조 알고리즘, 알람 로직)에서 결함이 있었다면, 시험원은 잔여 위험과 사용자 고지(라벨/IFU 변경)까지 고려했는지 확인해야 합니다.
사이버보안과 데이터 무결성은 최근 검토에서 빠지기 쉬운 영역입니다. 인증/권한, 로그 보존, 업데이트 무결성, 암호화, 통신 오류 처리 등이 소프트웨어 요구사항과 시험 케이스로 존재하는지 확인해야 합니다. 이 항목들은 규제 환경과 제품 특성에 따라 요구 수준이 달라질 수 있지만, 최소한 “위험관리에서 식별된 위협 시나리오가 소프트웨어 통제 요구사항과 시험 근거로 이어지는 구조”가 있어야 합니다. 시험원 입장에서는 보안이 별도 문서로만 존재하고 SDLC/테스트 문서와 단절되어 있으면 취약하다고 판단할 수 있습니다.
3. SOUP(외부 소프트웨어) 식별·평가·통제 및 변경관리
SOUP 관리는 “우리가 만들지 않은 코드가 의료기기 안전에 어떤 영향을 주는가”를 통제하는 활동입니다. 시험원이 가장 먼저 확인해야 할 것은 SOUP 목록(인벤토리)입니다. 제품에 포함된 운영체제, 미들웨어, 오픈소스 라이브러리, 상용 SDK, 드라이버, 런타임, 통신 스택, 암호 모듈 등 모든 외부 구성요소가 버전·공급처·라이선스·사용 목적과 함께 명확히 식별되어야 합니다. 여기서 목록이 불완전하면 이후 위험평가와 취약점 대응이 사실상 불가능해집니다.
다음으로 SOUP 평가 문서가 필요합니다. 각 SOUP 구성요소에 대해 (1) 사용 목적과 안전 관련성, (2) 알려진 문제/제한사항, (3) 공급자 품질 및 유지보수 상태, (4) 보안 취약점 대응 체계, (5) 대체 가능성, (6) 업데이트 시 영향 범위를 평가해야 합니다. 특히 오픈소스의 경우 CVE 등 공개 취약점의 관리가 핵심이며, 단순히 “검증된 라이브러리 사용”이라는 문구로는 부족합니다. 시험원은 최소한 취약점 모니터링 방식(정기 점검 주기, 책임자), 취약점 발견 시 의사결정 기준(즉시 업데이트 vs 완화 조치), 검증 범위(회귀 시험, 보안 시험)를 문서로 확인할 수 있어야 합니다.
SOUP는 “고정된 부품”이 아니라 “변경의 출발점”이기 때문에 변경관리와의 결합이 필수입니다. 라이브러리 버전 업데이트, OS 패치, 컴파일러 변경은 곧바로 기능 변경과 안전 영향으로 이어질 수 있습니다. 따라서 변경 요청서에 SOUP 변경이 포함될 경우 위험관리 영향평가(새로운 위해 시나리오, 확률 변화), 요구사항 변경 여부, 시험 범위(회귀/스트레스/보안) 재설계가 수행되어야 합니다. 시험원은 SOUP 업데이트 이력과 릴리즈 노트가 존재하는지, 업데이트가 있었을 때 어떤 시험을 추가로 수행했는지, 그리고 그 결과가 최종 밸리데이션 결론에 반영되었는지 확인해야 합니다.
마지막으로 라이선스 및 배포 통제도 간과하기 쉽지만 중요한 요소입니다. 오픈소스 라이선스(GPL 계열 등)에 따라 소스 공개 의무나 배포 조건이 달라질 수 있고, 이는 제품 배포·유지보수 정책과 충돌할 가능성이 있습니다. 물론 시험원이 법률 판단을 내릴 필요는 없지만, 최소한 라이선스 식별과 준수 계획이 존재하는지, 배포물에 라이선스 고지와 제3자 고지(Third-party notice)가 포함되는지 확인하는 것은 “품질 시스템 관점의 통제”로서 의미가 있습니다. 결과적으로 SOUP 관리는 보안·품질·안전이 동시에 걸린 영역이며, 시험원은 목록–평가–변경–검증으로 이어지는 닫힌 루프가 문서로 형성되어 있는지 확인해야 합니다.