안녕하세요, 유유테이진 건강지킴이입니다.

의료 AI 도입 제안서를 검토할 때 초기 성능, 설치 일정, 계약 금액만으로 운영 가능성을 판단하기는 어렵습니다. 의료 AI가 의료기기에 해당하는 경우, 소프트웨어와 연결된 디지털 구성요소의 지원 종료는 보안 취약점, 장애 대응 공백, 병원 시스템과의 호환성 문제로 이어질 수 있습니다. 구매·정보보안·의공·진료 부서가 계약 전에 함께 확인해야 할 핵심은 “언제까지, 무엇을, 어떤 방식으로 지원하는가”입니다.

TL;DR

• 제품의 EOL(End of Life, 제품 생애주기 종료) 과 EOS(End of Support, 지원 종료) 날짜를 구분해 문서로 받습니다.
• AI 프로그램뿐 아니라 운영체제와 제3자 소프트웨어 구성요소의 지원 상태를 별도로 확인합니다.
• 취약점 발생 시 통지 주체·통지 시점·패치 방식·설치 책임을 계약서 또는 부속 문서에 명확히 둡니다.
• SBOM 제공 가능 여부와 버전·업데이트 이력 관리 방식을 확인합니다.
• 지원 종료 뒤에도 자동으로 보안 지원이 지속된다고 가정해서는 안 됩니다.

EOL과 EOS, 계약서에서 따로 읽어야 하는 이유

IMDRF는 제조사가 공표한 사이버보안 EOL까지 현행 위협에 대한 합리적인 보호를 위한 지원을 지속하는 원칙을 제시합니다. EOL이 가까워지면 남은 제한 지원 내용을 고객에게 알리고, 사이버보안 EOS 날짜도 명확히 안내해야 한다고 설명합니다. 정해진 EOS 이후에는 지원이 계속될 것으로 기대해서는 안 된다는 점도 중요합니다.

두 용어를 같은 뜻으로 처리하면 위험합니다. EOL은 제품 생애주기 종료를 가리키는 기준으로 사용될 수 있고, EOS는 기술지원이나 보안 패치가 끝나는 시점을 뜻합니다. 따라서 계약 검토 시에는 “제품 판매 또는 공급 종료일”만 보지 말고, 보안 패치·취약점 대응·장애 접수·원격 또는 현장 지원이 각각 언제 종료되는지 분리해 확인해야 합니다.

식품의약품안전처의 의료기기 사이버보안 허가·심사 가이드라인을 참고하면, 의료 AI가 의료기기에 해당하는 경우 해당 제품의 허가·심사 관련 사이버보안 문서와 적용 소프트웨어 버전을 제조사에 요청해 대조하는 절차를 고려할 수 있습니다. 제안서의 제품명, 계약 대상 버전, 제출 문서의 버전이 다르면 차이와 적용 범위를 확인해야 합니다.

계약 전 확인표: 날짜와 책임을 빈칸 없이 채우기

다음 항목은 구매 부서만의 질문이 아니라 정보보안·의공·진료 부서가 함께 검토할 내용입니다.

1. 지원 종료일

• 제품 전체의 EOL 날짜는 언제인가?
• 사이버보안 EOS 날짜는 언제인가?
• 일반 기술지원, 장애 접수, 보안 패치, 기능 업데이트의 종료일이 각각 다른가?
• 제한 지원 기간이 있다면 제공 범위와 제외 범위는 무엇인가?
• 종료 일정이 변경되면 누가, 어떤 채널로, 언제 병원에 통지하는가?

날짜는 “향후 안내”처럼 포괄적으로 적기보다 제품명·모델·소프트웨어 버전과 연결해 기록하는 편이 좋습니다. 계약 기간이 남아 있어도 EOS가 먼저 도래할 수 있는지 반드시 확인해야 합니다.

2. 의존 소프트웨어와 호환성

IMDRF의 레거시 의료기기 사이버보안 지침은 의료기관이 구매·설치 전에 제조사와 알려진 EOL·EOS 날짜, 운영체제·제3자 소프트웨어·응용 소프트웨어를 포함한 업그레이드 전략을 교환하도록 제시합니다. 특히 기기 자체보다 내부 소프트웨어나 디지털 구성요소가 먼저 EOL 또는 EOS에 도달할 수 있습니다.

확인표에는 최소한 다음 항목을 별도로 두는 것이 좋습니다.

• AI 응용 소프트웨어의 현재 버전과 지원 종료일
• 운영체제의 버전과 지원 종료일
• 제3자 소프트웨어 구성요소의 이름·버전·지원 상태
• 병원 시스템과 연동되는 구성요소의 버전 호환성 확인 주체
• 구성요소 지원 중단 시 제조사의 위험 평가와 가능한 완화조치 안내 방식

“최신 버전 제공”이라는 표현만으로는 충분하지 않습니다. 업데이트 전후 어떤 버전이 허가·심사 관련 문서의 적용 대상인지, 업데이트가 단순 패치인지 구성 변경인지, 병원은 어떤 검증 또는 운영 절차를 거쳐야 하는지 확인해야 합니다.

3. 취약점 통지와 패치 배포 절차

IMDRF는 취약점이 발견된 경우 제조사가 관련 정보와 완화조치(예: 소프트웨어 패치)를 제공하고, 고위험 취약점은 환자 위해나 기기 중단을 막기 위한 적시 통지를 우선하도록 제시합니다. 이에 따라 계약에는 다음 질문의 답을 남기는 것이 바람직합니다.

• 취약점 통지는 제조사, 공급사, 병원 중 누가 담당하는가?
• 통지 대상은 정보보안 부서, 의공 부서, 진료 부서 중 누구인가?
• 고위험 취약점의 판단 기준과 통지 시점은 문서화되는가?
• 패치는 무선 업데이트, 원격 지원, 서비스 인력 방문 중 어떤 방식으로 배포되는가?
• 설치와 적용 확인은 누가 맡고, 장애 발생 시 되돌리기 또는 중단 절차가 있는가?
• 업데이트 이행을 위한 운영자 지침은 제공되는가?

패치를 받는 것과 안전하게 적용하는 것은 다른 업무입니다. 병원 내부에서 접수·영향 검토·설치 승인·적용 기록·장애 연락 경로를 정해 두어야 책임 공백을 줄일 수 있습니다.

SBOM과 버전 이력: 무엇이 포함돼 있는지 확인하기

SBOM(Software Bill of Materials)은 소프트웨어에 포함된 구성요소와 구성요소 간 관계, 관련 정보를 정리한 목록입니다. IMDRF는 의료기기 소프트웨어 업데이트에 패치와 구성 변경이 포함될 수 있다고 설명합니다.

계약 전 제조사에 SBOM 제공 가능 여부를 묻고, 제공 범위와 갱신 시점을 확인해 보세요. 모든 세부 정보를 즉시 제공받을 수 있는지는 별도 확인이 필요하지만, 적어도 병원은 취약점 공지가 발생했을 때 도입 버전이 영향을 받는지 판단할 수 있는 연락·확인 절차를 확보해야 합니다.

버전 이력에는 변경 날짜, 변경된 구성요소, 업데이트 목적, 적용 대상 버전, 병원 측 적용 여부를 남기는 방식을 검토할 수 있습니다.

지원 종료 뒤 데이터와 운영 책임도 확인하세요

서비스 종료는 단순히 화면이나 기능이 멈추는 문제에 그치지 않을 수 있습니다. 계약 검토 단계에서 종료 후 데이터 접근 가능 여부, 보관 또는 반환 방식, 삭제 요청과 책임 주체, 계정·원격접속 권한의 처리 방법을 확인해야 합니다. 구체적인 데이터 처리 조건은 제품과 계약에 따라 달라질 수 있으므로 제조사 문서와 병원 내부 정책을 함께 대조해야 합니다.

의료 AI의 보안 업데이트나 기술지원 상태는 의료진의 임상적 판단을 대체하지 않습니다. 실제 진료에서 결과 해석과 환자 안전에 관한 판단은 의료진의 책임 있는 검토가 필요하며, 환자에게 영향을 줄 수 있는 장애·오류 상황은 관련 전문의 또는 담당 의사와 상의해 대응해야 합니다.

자주 묻는 질문

Q. 계약 기간이 남아 있으면 보안 패치도 계속 제공되나요?

반드시 그렇다고 볼 수 없습니다. IMDRF는 정해진 EOS 이후에는 지원을 기대해서는 안 된다고 설명합니다. 계약 기간, EOL, 보안 EOS, 일반 기술지원 종료일을 각각 문서로 확인하세요.

Q. AI 소프트웨어만 확인하면 되나요?

아닙니다. 운영체제와 제3자 소프트웨어 구성요소가 더 먼저 지원 종료에 도달할 수 있습니다. 구성요소별 지원 상태와 업그레이드 전략을 확인해야 합니다.

Q. 취약점 공지를 받으면 병원이 바로 업데이트해야 하나요?

취약점의 영향, 제조사가 제시한 완화조치, 패치 방식, 병원 운영 환경을 함께 검토해야 합니다. 제조사의 이행 지침과 병원 내부 변경관리 절차를 확인하고, 환자 진료에 영향을 줄 수 있는 경우 담당 의료진과 전문의의 판단을 구해야 합니다.

본문에 언급된 타사 의료 AI 제품·서비스는 정보 제공 목적의 사례이며, 유유테이진의 판매·임대·상담 대상이 아닙니다. 제품·도입 문의는 해당 제조사·공식 판매처 또는 의료기관에 확인해 주세요.