IEC 60601-1 14절은 프로그램 가능 전기 의료 시스템(PEMS)과 소프트웨어(소프트웨어 기반 제어 포함)가 기본 안전과 필수 성능을 훼손하지 않도록, 개발·검증·변경관리 체계를 요구하는 조항입니다. 많은 조직이 62304를 “소프트웨어 표준”, 60601-1을 “전기안전 표준”으로 분리해 생각하지만, 시험소 관점에서는 14절이 두 세계를 연결합니다. 즉 14절은 “소프트웨어가 안전 기능을 담당한다면, 그 안전 주장이 설계 문서·검증 기록·형상관리로 뒷받침되는가”를 확인하는 조항입니다. 그래서 14절 부적합은 코드 품질보다 근거 부족에서 자주 발생합니다. 기능은 동작하지만, 왜 안전한지 설명할 자료가 없거나, 업데이트 시 동일 안전성이 유지된다는 체계가 없으면 심사자는 보수적으로 판단합니다.
이 글에서는 전문가 관점에서 14절을 안전분류와 아키텍처 증빙, 검증 전략과 독립성, 형상·변경·사이버 연계 관리의 3축으로 정리합니다. 목표는 “시험소가 어떤 질문을 하고, 어떤 산출물이 그 질문을 닫아주는지”를 실무 언어로 정리하는 것입니다.
소프트웨어 안전분류와 아키텍처 증빙
14절 대응의 출발점은 PEMS의 범위를 정의하는 것입니다. 오늘날 대부분의 의료기기는 마이크로컨트롤러, SoC, OS, 네트워크 스택, FPGA, 앱, 서버까지 포함한 복합 시스템이며, “기기 본체 소프트웨어만”을 대상으로 삼으면 현실을 반영하지 못합니다. 시험소 관점에서 PEMS 범위는 ‘안전과 필수 성능에 영향을 줄 수 있는 모든 프로그램 가능 요소’입니다. 예를 들어 팬 제어, 과열 차단, 출력 제한, 인터록, 알람 우선순위, 재가동 제한(13절), 표시값 신뢰성(12절) 같은 기능을 소프트웨어가 관여한다면, 그 기능이 PEMS 범위에 포함됩니다. 이 범위를 문서로 고정해야 이후의 분류, 시험, 변경 영향 분석이 가능합니다.
다음은 안전분류입니다. 14절 자체는 “소프트웨어 안전분류”를 직접적으로 62304처럼 세 단계로 표현하지 않더라도, 실무에서는 62304의 안전분류(예: Class A/B/C) 또는 내부 위험기반 등급을 근거로 삼아 설명하는 것이 효율적입니다. 중요한 것은 라벨링이 아니라, 실제로 위해로 이어질 수 있는 소프트웨어 실패 모드를 정의하고, 그 실패가 허용 가능한지(위험 통제 존재 여부)를 설명하는 것입니다. 예컨대 UI 표시 오류가 단순 불편인지, 임상 판단 오류로 이어지는지에 따라 등급과 검증 깊이가 달라집니다. 또한 시스템에는 보통 혼합 등급이 존재합니다. 핵심 안전 기능(예: 과열 차단)은 높은 등급, 로그 저장이나 통계 기능은 낮은 등급으로 분리할 수 있습니다. 이 분리가 가능하려면 아키텍처가 분리되어 있어야 하고, 분리 근거(방화벽, 권한, 프로세스 격리, 독립 MCU 등)가 문서로 제시되어야 합니다.
아키텍처 증빙에서 시험소가 가장 자주 요구하는 것은 “안전 기능이 어떤 경로로 구현되는가”를 보여주는 도식입니다. 최소한 다음이 포함된 블록도를 준비하는 것이 실무적으로 안전합니다. 첫째, 하드웨어 구성(주요 MCU/CPU, 전원부, 센서, 구동부, 통신 모듈). 둘째, 소프트웨어 구성(OS, 프로세스/태스크, 드라이버, 안전 모듈, UI, 통신, 업데이트 모듈). 셋째, 안전 관련 데이터 흐름(센서 값→판단→출력 제한/차단, 알람 발생, 로그 기록). 넷째, 독립성 요소(워치독, 이중 센서 비교, 하드웨어 차단, 안전 릴레이, 서멀퓨즈 등). 이 도식은 12절·13절의 “상태 전이”를 기술적으로 뒷받침하는 핵심 증빙입니다.
또 하나의 포인트는 “하드웨어-소프트웨어 인터페이스(HW/SW interface)” 정의입니다. 안전 기능은 센서 입력의 단위, 샘플링 주기, 필터링, 임계치, 액추에이터 구동 방식, 실패 시 기본 상태(default state)에 의해 좌우됩니다. 따라서 인터페이스 문서가 없으면, 검증 결과가 특정 버전에서만 우연히 맞았는지 설명하기 어렵습니다. 실무적으로는 I/O 리스트(입력/출력 신호, 범위, 단위, 정상/고장 값, 진단 방식)와 안전 파라미터 테이블(임계치, 히스테리시스, 타임아웃, 디레이팅 곡선)을 별도 산출물로 관리하면 14절 대응이 단단해집니다.
검증 전략과 독립성 확보
14절에서 “시험”은 흔히 오해되는 단어입니다. 8절처럼 장비에 리드선을 물려 수치를 측정하는 시험만을 의미하지 않고, 소프트웨어가 안전 주장을 만족하는지 확인하는 검증(verification)과 확인(validation) 체계를 의미합니다. 따라서 시험소는 단지 테스트 결과표가 아니라, “어떤 위험 통제를 어떤 수준의 검증으로 커버했는지”를 묻습니다. 이 질문을 닫는 가장 효과적인 문서는 요구사항-위험-테스트의 추적성(traceability)입니다.
실무적으로 검증 전략은 계층형으로 구성하는 것이 좋습니다. 첫째, 정적 검토(리뷰)와 규칙 기반 검사입니다. 요구사항, 설계, 코드 리뷰를 통해 논리 오류를 줄이고, 코딩 규약, 정적 분석을 통해 결함 가능성을 낮춥니다. 둘째, 단위시험과 모듈시험입니다. 안전 관련 알고리즘(임계치 판단, 타임아웃, 센서 진단, 워치독 핸들링)을 모듈 단위로 검증합니다. 셋째, 통합시험입니다. 센서 입력부터 구동부 차단까지 end-to-end 경로를 확인하고, 타이밍과 전이 시간을 측정합니다. 넷째, 시스템 시험입니다. 실제 하드웨어에서 최악 조건(전원 변동, 온도, 통신 부하, 장시간 동작)에서 안전 기능이 유지되는지 확인합니다. 다섯째, 단일고장 시나리오 시험입니다. 센서 단선/단락, 통신 끊김, UI 프리즈, 프로세스 다운 등 현실적 결함을 주고 13절의 보호동작이 요구대로 수행되는지 검증합니다.
여기서 시험소가 특히 민감하게 보는 것이 “독립성”입니다. 안전 기능이 동일 CPU, 동일 태스크, 동일 메모리 공간에서만 실행되고, 그 CPU가 멈추면 모든 안전 기능이 함께 멈춘다면, 단일고장 가정에서 취약해질 수 있습니다. 따라서 워치독이 시스템을 리셋하는지, 리셋 후 안전 상태가 보장되는지, 리셋 동안 위험 출력이 유지되지 않는지, 하드웨어 차단 경로가 존재하는지 등 “단일고장에도 최악을 막는 구조”가 필요합니다. 독립성은 반드시 두 개의 MCU가 있어야만 확보되는 것은 아니지만, 최소한 ‘결함이 안전 기능에 즉시 전파되지 않도록’ 설계되어야 합니다. 예를 들어 안전 릴레이는 소프트웨어가 구동하더라도, 릴레이의 기본 상태가 안전 상태(출력 차단)로 설계되어 있으면 안전성이 올라갑니다.
검증 산출물의 구성에서 흔한 실패는 “테스트는 많지만, 무엇을 증명하는지 모호”한 경우입니다. 테스트 케이스가 수백 개여도, 위험 통제(예: 과열 차단)와 연결되지 않으면 심사자는 핵심을 찾기 어렵습니다. 따라서 안전 관련 기능은 최소한 다음 정보를 한 세트로 제시하는 것이 좋습니다. 요구사항(임계치/타임아웃/전이), 위험 통제 설명(왜 필요한가), 시험 방법(어떤 입력을 주는가), 합격 기준(시간/상태/출력), 결과(로그/스크린샷/측정값), 결함 처리(버그 티켓/수정 버전). 이 구조는 12절·13절의 시험 기록과도 자연스럽게 맞물립니다.
또한 PEMS는 업데이트가 필연적이므로, 재현성 확보가 중요합니다. 시험 결과가 특정 소프트웨어 빌드에서만 의미가 있다면, 이후 빌드에서 안전성이 유지된다는 보장이 약합니다. 따라서 빌드 ID, 컴파일 옵션, 라이브러리 버전, 구성 옵션(기능 플래그), 설정 파라미터를 시험 기록에 고정해야 합니다. 이 정보가 빠지면, 심사자는 “같은 시험을 다시 하면 같은 결과가 나오나?”라는 질문을 할 수밖에 없습니다.
형상관리·변경·사이버 연계 포인트
14절의 마지막 축은 개발보다 운영에서 흔히 무너집니다. 즉 형상관리(configuration management), 변경관리(change control), 문제관리(problem resolution), 그리고 사이버(네트워크) 요소가 안전에 미치는 영향입니다. 오늘날 의료기기는 네트워크 연결, 원격 서비스, 앱 연동이 흔하며, 이때 보안 사건이 안전 사건으로 전환될 수 있습니다. 60601-1 14절이 보안을 직접 규정하는 조항은 아니지만, PEMS가 안전에 영향을 주는 이상, “업데이트와 연결 기능이 안전을 깨지 않는다”는 체계를 요구받는 것은 매우 현실적입니다.
형상관리에서 핵심은 “무엇이 릴리스의 일부인가”를 명확히 하는 것입니다. 펌웨어, 애플리케이션, OS 이미지, 설정 파일, 파라미터 테이블, 데이터베이스, AI 모델, 인증서 같은 구성요소가 릴리스 단위로 관리되어야 합니다. 특히 안전 임계치와 디레이팅 곡선이 설정 파일로 존재한다면, 코드보다 설정 변경이 더 큰 안전 영향이 될 수 있습니다. 따라서 임계치/파라미터는 변경 이력을 남기고, 승인 절차를 거쳐야 하며, 변경 시 재검증 범위를 정의해야 합니다. 시험소는 “코드는 안 바뀌었다”는 주장보다 “안전 파라미터가 바뀌지 않았다/바뀌었으면 재검증했다”는 근거를 더 중요하게 볼 수 있습니다.
변경 영향 분석은 14절의 실무 핵심입니다. 제품이 업데이트되면 8절 누설전류가 갑자기 바뀌는 일은 드물지만, 12절 제어 정확도와 13절 보호동작은 소프트웨어 변경으로 쉽게 흔들립니다. 따라서 변경 시에는 위험관리 업데이트, 영향 범위 식별, 회귀 시험(regression) 계획이 필요합니다. 실무적으로는 “안전 관련 기능 리스트(안전 기능 레지스터)”를 만들어, 각 기능이 어떤 테스트 케이스로 커버되는지 매핑해두면, 업데이트마다 재시험 범위를 합리적으로 줄일 수 있습니다. 이 문서가 없으면 업데이트 때마다 ‘전체 재시험’ 또는 ‘근거 없는 생략’이라는 극단으로 흘러 비용과 리스크가 커집니다.
문제관리(버그 관리)도 심사에서 자주 질문이 들어옵니다. 특히 현장 이슈가 안전과 연계될 수 있는 경우, 결함을 어떻게 분류하고, 완화 조치(예: 사용 제한 공지, 핫픽스, 리콜 가능성)를 어떻게 결정하는지 체계가 필요합니다. 단순히 버그 트래커가 있다는 사실보다, 안전 관련 결함의 우선순위와 릴리스 게이트가 존재하는지가 중요합니다. 예컨대 과열 알람이 지연되는 결함은 기능 결함이 아니라 안전 결함일 수 있으므로, 릴리스 차단 조건으로 다뤄야 한다는 식의 기준이 문서로 존재하면 설득력이 올라갑니다.
사이버 연계 포인트는 “연결이 안전을 깨지지 않게”라는 관점으로 접근하면 된다. 예를 들어 원격 업데이트가 가능하다면 업데이트 중 전원 차단이나 통신 끊김에서 기기가 벽돌이 되지 않는지, 실패 시 안전 상태로 롤백되는지, 업데이트 무결성이 검증되는지, 업데이트 후 안전 기능이 정상인지 자가 테스트를 하는지 같은 항목이 실무적으로 중요합니다. 또한 네트워크가 과부하되거나 악의적 트래픽이 들어올 때 UI가 멈추고 출력이 계속되는 상태는 13절 위험상황으로 해석될 수 있으므로, 통신과 안전 기능의 자원 격리, 타임아웃, 워치독이 필요할 수 있습니다. 14절의 관점에서 이런 설계는 “PEMS의 안전성 유지”로 설명할 수 있습니다.
결론적으로 14절은 소프트웨어 개발팀만의 조항이 아닙니다. 하드웨어·시스템·품질·규제·시험이 함께 “안전 기능의 주장을 문서와 검증으로 닫는” 조항입니다. PEMS 범위를 정의하고, 안전분류와 아키텍처를 증빙하며, 위험 통제를 검증하고, 변경·업데이트에서도 동일 안전성을 유지하는 체계를 갖추면 14절은 오히려 인증의 불확실성을 크게 줄여주는 조항으로 작동합니다.