개념
법이 바뀌면 제출 서류의 이름이 바뀐다
한국에서 의료기기는 오랫동안 「의료기기법」과 「체외진단의료기기법」으로 관리됐다. 인공지능·로봇·가상융합 기술이 적용된 제품이 늘면서, 이런 제품의 특성에 맞춘 「디지털의료제품법」 이 제정되어 2025년 1월 24일 시행됐다. 디지털의료·건강지원기기 관련 규정은 2026년 1월 24일 부터 시행됐다. 하위 고시와 민원인 안내서가 2025년에 대거 제·개정되었고, 식약처는 2025년 5월 7일 디지털의료기기 관련 가이드라인 6종을 제·개정하면서 디지털의료기기소프트웨어 허가·심사 가이드라인 을 새로 제정했다.
QA에게 중요한 사실은 요구하는 검증의 실질은 IEC 62304·ISO 14971·IEC 62366-1과 크게 다르지 않지만, 제출 양식·용어·판단 기준이 새 체계로 정리됐다 는 것이다. 레슨 1~5에서 만든 증거를 새 양식에 정확히 옮기는 것이 이 레슨의 목표다. 이 분야의 안내서는 개정이 잦으므로 모든 판단은 신청 시점의 법령·고시·민원인 안내서 판본 으로 하고, 프로젝트 문서에 판본을 적는다.
디지털의료제품의 범위
디지털의료제품법은 세 가지를 다룬다.
| 구분 | 요지 |
|---|---|
| 디지털의료기기 | 지능정보·로봇·정보통신 등 디지털기술이 적용된 의료기기(체외진단의료기기 포함)로서 질병의 진단·치료·예후 관찰, 치료 반응·결과 예측, 치료 효과·부작용 모니터링, 재활 보조 등의 목적 |
| 디지털융합의약품 | 디지털의료기기 등과 조합된 의약품 |
| 디지털의료·건강지원기기 | 디지털의료기기에 해당하지 않지만 의료·건강 지원 목적의 기기 (2026.1.24 시행) |
디지털의료기기소프트웨어는 형태로 두 가지다.
- 독립형 — 하드웨어에 결합되지 않고 범용 컴퓨터·태블릿·스마트폰 같은 환경에서 운영되며, 그 자체로 디지털의료기기에 해당하는 소프트웨어 (예: 영상 분석 AI, 디지털치료기기)
- 내장형 — 디지털의료기기에 설치되거나 연결되어 제어·구동하거나 데이터를 저장·처리하는 소프트웨어
가이드라인은 별도 표시 기능·사용자 화면 없이 기기를 제어하는 펌웨어 수준의 소프트웨어, 제조·개발용 소프트웨어, 품질관리용 소프트웨어를 적용 범위에서 제외한다. 품질관리용 소프트웨어는 인허가 제출 대상은 아니지만 품질관리기준 차원의 밸리데이션 대상이라는 점(레슨 4)을 기억하자.
제품코드·등급 결정에 소프트웨어 안전성 등급이 들어간다
디지털의료기기는 「디지털의료제품의 분류 및 등급 지정 등에 관한 규정」에 따라 제조사가 먼저 제품코드와 등급을 판단 해서 신청한다. 제품코드는 주된 사용목적(검사·진단· 치료·임상적 관리 유도·정보제공 등), 적용된 디지털기술 유형(독립형 소프트웨어·인공지능·지능형 로봇·초고성능컴퓨팅·가상융합), 기본 유형과 형태로 구성된다.
등급은 사용목적의 의료적 영향과 성능 저하·오작동 시 직·간접 피해 수준 을 함께 고려한다. 식약처 업무 안내서는 이 피해 수준을 소프트웨어 안전성 등급 으로 판단하도록 안내한다.
| 소프트웨어 안전성 등급 | 정의 | 등급 결정 시 조정 |
|---|---|---|
| A | 부상이나 신체적 피해가 발생할 가능성이 없음 | 피해 없음 (−1) |
| B | 심각하지 않은 부상(경상)이 발생할 가능성이 있음 | 변동 없음 |
| C | 심각한 부상 또는 사망이 발생할 가능성이 있음 | 심각한 부상은 변동 없음, 사망 가능성은 +1 |
정의는 IEC 62304의 A·B·C와 같은 방향이다(레슨 1). 가이드라인의 안전성 등급 판단 예시는 기능별로 위해 요인·위해·심각도·발생 가능성·위험을 적고 소프트웨어 오류로 인한 위험의 발생 가능성은 100%로 간주 한다. 레슨 1·2에서 본 "소프트웨어는 고장 난다고 가정한다"가 국내 안내서에도 그대로 들어가 있다.
여기서 QA가 챙길 실무 포인트가 있다. 안내서는 여러 판본과 여러 문서에 걸쳐 같은 정의를 반복하는데, 본문 서술과 표의 표현이 어긋나 보이는 곳이 생길 수 있다. 이럴 때는 정의 표와 상위 규정(허가·인증·신고·심사 및 평가 등에 관한 규정의 별표)을 기준으로 삼고, 판단이 제출 자료에 영향을 주면 담당 부서에 확인해 그 기록을 남긴다. 등급 판단 근거는 적합성 확인보고서에 들어가므로 판단의 출처 가 중요하다.
디지털의료기기소프트웨어 적합성 확인보고서
허가 심사 시 소프트웨어에 대해 제출하는 핵심 서류가 디지털의료기기소프트웨어 적합성 확인보고서 (규정 별지 서식)와 소프트웨어 검증 및 유효성확인 자료 다. 적합성 확인보고서는 개발 당시 작성된 문서를 확인하기 위한 보고서로, 항목마다 내용을 요약하고 「디지털의료기기 제조 및 품질관리기준」에 따른 제조소의 해당 문서 관리번호 를 함께 적는다. 가이드라인이 안내하는 항목을 QA 산출물과 대응시키면 이렇다.
| 적합성 확인보고서 항목 | 요약할 내용 | 레슨 1~5의 산출물 |
|---|---|---|
| 명칭 등 정보, 소프트웨어 명칭·버전 | 제품명·제품코드·등급, 대표 모델 소프트웨어 버전 | 형상관리 식별 |
| 소프트웨어 형태·기능적 특성 | 내장형·독립형·기타, 제어·측정·분석·진단·데이터 전송·표시 기능 | 아키텍처 문서 |
| 소프트웨어 안전성 등급 | 등급과 판단 근거 | 레슨 1 등급 판정, 레슨 2 위험 분석 |
| 사용목적 | 기능별 사용목적 | 사용 사양 (레슨 3) |
| 운영환경 | 하드웨어·OS·SOUP의 운영환경 | 레슨 1 SOUP 목록, 레슨 5 SBOM |
| 소프트웨어 개발 — 개발 계획 | 개발 규격·방법·도구, 검증·위험관리·형상관리 계획 | 개발 계획서, 시험 계획서 |
| 소프트웨어 개발 — 요구사항 분석 | 요구사항 수립, 위험통제수단, 요구사항 검증 방법 | SRS, 위험 추적표 |
| 소프트웨어 개발 — 구현 | 아키텍처·상세 설계 | SDS |
| 소프트웨어 개발 — 검증 및 유효성확인 | 제출하는 V&V 자료 요약 | V&V 보고서 |
| 소프트웨어 개발 — 배포 | 검증 결과, 잔여 이상 목록 평가 결과, 배포 버전·개발 환경·보관 | 레슨 1 잔존 이상 평가 |
| 유지보수 및 문제해결 | 유지보수 계획, 문제 보고·수정 분석·해결 검증 | 레슨 1 문제 해결 프로세스 |
| 위험관리 | 위해 상황·위험통제수단·위험통제수단의 검증·변경의 위험관리 | 레슨 2 구현·효과 검증 |
| 형상관리 | 소프트웨어 식별·변경관리·상태 기록 | 형상관리 계획·기록 |
표를 보면 IEC 62304의 5~9장 구조가 그대로 들어 있다. 레슨 1의 산출물 체계를 갖춘 조직이라면 적합성 확인보고서는 문서 관리번호를 찾아 요약하는 일 이다. 체계가 없는 조직은 이 서식을 채우다가 산출물이 없다는 것을 처음 발견한다.
"위험관리" 항목의 위험통제수단의 검증 과 "배포" 항목의 잔여 이상 목록 평가 결과 가 QA가 가장 직접적으로 쓰는 칸이다. 요약에 "검증 완료"만 쓰지 말고, 구현 검증과 효과 검증이 각각 어느 보고서의 어느 절에 있는지 관리번호로 가리킨다.
검증 및 유효성확인 보고서 — 무엇이 들어가야 하나
가이드라인은 검증 및 유효성확인(V&V) 보고서 예시를 제공한다. 예시에서 읽어 낼 수 있는 구조는 이렇다.
| 구성 | 내용 | QA 포인트 |
|---|---|---|
| 개요·대상 | 제품·소프트웨어 버전, 주요 변경과 주요 변경이 아닌 변경의 정의 | 시험 대상 버전과 제출 버전 일치 |
| 추적표 | 요구사항(SRS) → 설계(SDS) → 단위·통합·시스템 시험 ID, 위험(SRM) 연결 | 레슨 1 추적표, 레슨 2 위험 ID |
| 시험 결과 | 시험별 결과와 수행자 | 반복 가능성 (레슨 1) |
| 분석적 성능 시험 | 평가 지표(AUROC·민감도·특이도 등)와 정의, 시험 환경, 데이터, 결과 | 모듈 36 레슨 3 분류 성능 평가 |
| 시험 환경 | 하드웨어 사양, 소프트웨어 환경(GPU 드라이버·런타임·라이브러리 버전), 전처리 조건 | 모듈 31 레슨 2 환경 기재 |
| 학습·시험 데이터 정의 (AI 제품) | 수집 데이터 중 학습·검증·테스트로 쓰는 항목, 분할 | 데이터 누수·분포 |
AI 기반 소프트웨어에서 가장 자주 보완 요구를 받는 곳이 시험 환경과 데이터 정의 다. 분석적 성능 시험 결과가 "AUROC 0.93"이라도, 어느 버전의 모델을 어떤 런타임과 라이브러리 버전에서 어떤 데이터로 쟀는지 없으면 재현할 수 없다. 모델 학습에 쓴 데이터와 시험 데이터가 같은 기관·같은 기간에서 나와 분리가 불충분하면 성능이 부풀려진다.
[분석적 성능 시험 기록 — 요약 형식]
대상: ○○ 예측 소프트웨어 v1.03.12 (모델 가중치 해시 기록)
평가 지표: AUROC (95% 신뢰구간), 민감도·특이도 (임계값 고정: 설계 문서 SDS-035)
시험 데이터: 기관 3곳, 수집 기간 2023~2024, 학습 데이터 기관과 **다른** 기관 1곳 포함
환자 단위 분할 확인(같은 환자의 영상이 학습·시험에 동시에 없음)
시험 환경: GPU 모델·메모리, 드라이버·CUDA 버전, 추론 런타임, 전처리 라이브러리 버전
→ 운영환경(적합성 확인보고서)과 일치 여부
결과: AUROC 0.91 (0.88~0.94), 민감도 0.87, 특이도 0.84
하위군: 연령대·성별·장비 제조사별 결과 (모듈 36 레슨 4 편향)
수행자·일시: 시험자 2인, 날짜"환자 단위 분할"과 "하위군 결과"는 규정 양식에 칸이 없더라도 심사관이 질의하는 단골 항목이다. 인공지능기술이 적용된 디지털의료기기의 임상시험방법 설계 가이드라인(2025)도 함께 확인한다. 성능 평가 지표 표현(예: ROC 곡선 대신 AUC 수치로 표준화) 같은 세부가 그 안내서에서 정리되었다.
임상시험 자료가 필요한가 — 분석적 성능으로 갈음되는 경우
디지털의료기기는 원칙적으로 임상시험 등 평가에 관한 자료가 필요하지만, 가이드라인은 제출 면제·대체가 가능한 경우를 안내한다. 예를 들어 임상적 유효성을 표방하지 않는 기능이나, 식약처장이 인정하는 임상표준데이터 등을 활용한 분석적 성능 검증 으로 갈음할 수 있는 경우가 있다. 이때 V&V 자료의 분석적 성능 시험이 임상적 사용 환경을 고려했는가 가 판단 근거가 된다.
QA에게 이것은 분석적 성능 시험의 설계 품질이 임상시험 수행 여부 — 즉 몇 달~몇 년의 일정과 큰 비용 — 를 좌우할 수 있다는 뜻이다. 실제 사용 환경의 영상 장비·입력 품질· 환자 분포를 시험 데이터가 반영하는지를 초기부터 설계한다.
변경허가 — 어떤 소프트웨어 변경이 심사를 부르는가
출시 후 소프트웨어는 계속 바뀐다. 모든 변경이 변경허가 대상은 아니다. 가이드라인은 허가 항목의 기재사항이 변경되는지 로 판단하도록 안내한다.
| 변경 유형 | 변경허가가 필요한 경우 (가이드라인 예시 요지) | 해당하지 않는 경우 |
|---|---|---|
| 사용목적·핵심 성능 | 기능이 추가·변경되어 '모양 및 구조'·'부분품 또는 구성요소'·'성능(기능) 또는 특성'·'사용목적'·'시험규격' 기재사항이 바뀜 (예: 폐결절 검출에 폐암 예측·진단 성능 추가) | 단순 오기 수정, 핵심 성능이 아닌 기재사항 |
| 알고리즘(분석 방법) | 분석 대상·기법이 바뀌어 작용원리·성능·시험규격이 바뀜 (예: 규칙 기반 → 딥러닝, CT → CT+MRI 입력 추가) | 분석 기법과 무관한 '사용방법' 기재 변경 |
| 개발언어·운영환경 | '부분품 또는 구성요소' 기재사항이 바뀜 (예: 운영환경 Windows → Android) | 같은 운영체계 안의 버전 변경 (예: Windows 7 → 10) |
| 통신 | 통신 기술·목적 추가로 '정보통신체계도' 기재사항이 바뀜 (예: Android → Android·iOS, 제어 → 제어·유지보수·업데이트) | 단순 오기 |
| 사용적합성에 영향을 주는 UI | 변경허가(인증) — 독립형 소프트웨어 사용적합성 가이드라인 참조 (레슨 3) | — |
QA가 할 일은 모든 변경에 대해 이 판단을 기록으로 남기는 것 이다. 모듈 38 레슨 5의 게이트에 "인허가 영향 검토" 경고 규칙을 넣고, 모듈 39 레슨 9의 인증 영향 판정과 같은 방식으로 운영한다.
[변경의 인허가 영향 판단 기록 — v1.04.0]
변경 내용: 전처리 라이브러리 버전 업그레이드, 결과 화면 색상 변경, 모델 재학습(같은 구조·데이터 12% 추가)
허가 기재사항 영향:
부분품 또는 구성요소 — 라이브러리 버전은 기재 수준 확인 → 기재 버전 형식(1.03.XX)상 영향 없음
성능(기능) 또는 특성 — 재학습으로 성능 수치 변동, 기재 성능 하한 충족 여부 확인 필요 → 분석적 성능 재시험 FT-104
작용원리·시험규격 — 구조·분석 대상 동일, 영향 없음
사용적합성 — 색상 변경이 경고 표시 구분에 영향 → 레슨 3 변경 영향 분석 UE-CI-07
판단: 변경허가 대상 아님 (근거: 가이드라인 판본, 재시험 결과)
단, 재학습 성능이 기재 하한 미달 시 변경허가 검토로 전환
확인: RA 담당, QA 리드모델 재학습 이 인공지능 제품에서 가장 어려운 판단이다. 구조와 분석 대상이 같아도 성능이 달라지면 기재 성능과의 관계를 확인해야 하고, 학습 데이터가 크게 바뀌면 작용원리 변경으로 볼 여지도 생긴다. 재학습 절차와 판단 기준을 사전에 문서화 해 두는 것이 안전하다.
우수 관리체계 인증과 전자적 침해행위 보안지침
디지털의료제품법은 두 가지 제도를 새로 두었다.
우수 관리체계 인증 — 식약처는 품질관리체계, 안전관리, 전자적 침해행위 보호 조치 등을 평가해 디지털의료기기 제조업자 등에 우수 관리체계 인증을 할 수 있다. 인증을 받으면 제조·수입 허가·인증·신고에 필요한 자료의 일부를 면제하거나 제출 시기·방법을 달리 할 수 있다. 인증 유효기간은 3년이다. QA 관점에서 이 인증은 레슨 1~5의 체계를 조직 수준에서 평가받는 것 이고, 평소 산출물 체계가 갖춰져 있으면 제품마다 반복되는 제출 부담을 줄이는 길이다.
전자적 침해행위 보안지침 — 해킹·데이터 유출·서비스 거부 공격 같은 전자적 침해행위로부터 디지털의료기기를 보호하는 조치와, 침해 발생 시 신고·조치, 취약점 감시 등을 정한 고시다. 업무 안내서는 침해행위 발생을 인지한 경우의 의무 보고사항 과 취약점을 확인한 경우의 권고사항 을 구분해 안내한다. 레슨 5의 출시 후 취약점 대응 계획이 국내에서는 이 지침과 연결된다. 사이버보안 허가·심사 가이드라인(레슨 5)의 요구사항별 적용·검증 근거 표와 함께, 침해 신고·조치 절차가 실제로 동작하는지 (연락 경로·판단 기준· 기록)를 모의 훈련으로 시험해 두면 좋다.
국내·해외 제출을 같은 증거에서 만든다
국내 인허가와 미국·유럽 제출을 동시에 준비하는 회사는 증거를 따로 만들면 안 된다. 모듈 39 레슨 9의 증거 대응표 방식을 쓴다.
증거 식약처 적합성 확인보고서 항목 FDA 제출 EU MDR 기술문서
SRS·추적표 요구사항 분석 Software Requirements —
위험 추적표 (구현·효과 검증) 위험관리 Risk Management File ISO 14971 파일
잔존 이상 평가 배포 Unresolved Anomalies —
분석적 성능 시험 V&V 보고서 Performance Testing 성능 평가
사용적합성 총괄 평가 사용적합성 자료 Human Factors Report IEC 62366-1 파일
SBOM·보안 시험 사이버보안 자료 Cybersecurity (524B) EN IEC 81001-5-1용어와 서식은 다르지만 증거는 같다. 이것이 레슨 1에서 "62304는 무엇을 하라고 하지, 어떻게 하라고 하지 않는다"로 시작한 이유다. 산출물 체계를 표준에 맞춰 두면 제출처별 서식은 번역의 문제가 된다.
실무에서 왜 필요한가
국내 디지털 헬스 기업, 특히 AI 영상 분석·디지털치료기기 회사가 인허가 일정에서 가장 자주 막히는 곳은 기술이 아니라 제출 자료의 구조와 판단 근거 다. 적합성 확인보고서의 관리번호가 가리키는 문서가 없거나, V&V 보고서의 시험 환경이 운영환경과 다르거나, 모델 재학습 후 변경허가 판단 기록이 없는 경우다. 법 체계가 새로 바뀐 시기에는 회사마다 해석이 엇갈려 보완 요구가 늘어난다.
QA가 이 자료를 RA(인허가) 담당과 함께 만들면, 인허가 문서가 실제 개발·시험 기록과 일치 하게 된다. 의료기기 QA 채용 공고에서 "인허가 대응 경험", "V&V 문서 작성", "IEC 62304 기반 문서화"가 반복되는 이유다. 면접에서는 "모델 재학습 후 변경허가 대상인지 어떻게 판단하고 무엇을 재시험했는가"가 실무 경험을 가장 잘 드러내는 질문이다.