IEC 62304 의료기기 소프트웨어 생명주기: 한국 디지털헬스 기업이 FDA·CE 제출 전에 갖춰야 할 것
IEC 62304는 의료기기 소프트웨어 개발·유지보수의 국제 표준으로, FDA 510(k)와 EU MDR CE 마킹 기술문서에서 사실상 필수 참조 기준이다. 2026년 제2판 개정(안전분류 3단계→2단계, 건강소프트웨어 범위 확장, AI/ML 조항 신설)을 앞두고, 한국 디지털헬스·SaMD 기업이 지금 정리해야 할 요구사항과 문서를 정리했다.
IEC 62304가 왜 한국 디지털헬스 기업에 해당하는가
한국의 디지털치료기기(DTx), AI 진단 보조 소프트웨어, 수술 로봇 제어 소프트웨어, 환자 모니터링 앱—이 모든 제품이 의료기기 소프트웨어에 해당한다. 그리고 이 소프트웨어가 FDA 510(k), De Novo, PMA, 또는 EU MDR CE 마킹 기술문서에 포함되려면, IEC 62304 준수가 사실상 필수다.
IEC 62304는 의료기기 소프트웨어의 개발, 검증, 유지보수에 대한 국제 표준이다(2006년 최초 발행, 2015년 개정). FDA는 IEC 62304를 "인정 합의 표준(Recognized Consensus Standard)"으로 채택했고, EU는 EN 62304를 MDR/IVDR 조화 표준(Harmonized Standard)으로 지정했다. 두 규제기관 모두 IEC 62304를 따르면 소프트웨어 생명주기 요건을 충족한 것으로 간주한다.
2026년 중순, IEC 62304 제2판이 발행될 예정이다. 주요 변화:
- 안전 분류 3단계(Class A/B/C) → 2단계(Process Rigor Level I/II)
- 적용 범위가 의료기기 소프트웨어에서 **건강 소프트웨어(Health Software)**로 확장
- AI/ML 기반 소프트웨어에 대한 조항 신설
- SOUP(Software of Unknown Provenance) 관리 강화
이 글은 현재 유효한 IEC 62304:2006+A1:2015의 핵심 요구사항을 중심으로, 제2판 변화를 포함하여 한국 디지털헬스 기업이 실무에서 갖춰야 할 것을 정리한다.
소프트웨어 안전 분류: 모든 것의 시작점
IEC 62304의 핵심 원칙은 **위험 기반 엄격도(Risk-based rigor)**다. 소프트웨어 결함이 환자에게 미칠 수 있는 위해의 심각도에 따라 요구사항이 달라진다.
현재 기준(제1판): Class A, B, C
| 분류 | 정의 | 위해 심각도 | 요구 활동 수준 |
|---|---|---|---|
| Class A | 소프트웨어 결함이 불가능하거나 경미한 부상 | 경미 또는 없음 | 최소 요구사항 |
| Class B | 결함이 비심각한 부상 가능 | 비심각 | 중간 요구사항 |
| Class C | 결함이 사망 또는 심각한 부상 가능 | 심각 또는 사망 | 전체 요구사항 |
분류 결정은 **ISO 14971(의료기기 위험관리)**과 연동된다. 소프트웨어가 위험통제조치(risk control measure)를 구현하는 경우, 해당 소프트웨어는 자동으로 상위 분류로 올라간다.
제2판 예정 변경: Process Rigor Level I, II
제2판은 세 단계를 두 단계로 단순화한다:
| 제2판 분류 | 해당(제1판) | 의미 |
|---|---|---|
| Level I | Class A | 최소 프로세스 요구 |
| Level II | Class B + C | 전체 프로세스 요구 |
중요한 변화: 위험통제조치를 구현하는 소프트웨어는 무조건 Level II다. 외부 통제조치가 있어도 소프트웨어 자체가 위험통제 역할을 하면 Level II에서 벗어날 수 없다. 이는 제1판에서 팀이 부적절하게 분류를 낮추는 것을 방지하는 개정이다.
한국 기업이 자주 겪는 분류 문제
사례: 환자 모니터링 앱이 서버에서 알고리즘을 실행하고, 의사에게 알림을 보내는 경우.
- 알림이 "정보 제공만"이면 Class A/Level I일 수 있다
- 하지만 알림이 임상 결정에 직접 사용되거나, 알림이 없으면 환자가 위험한 상태라면 Class C/Level II다
- 분류를 낮추기 위해 "의사가 최종 판단"이라고 주장하는 경우가 많은데, FDA와 NB는 소프트웨어의 실제 역할을 기준으로 판단한다
해결책: 제품의 intended use와 risk analysis를 먼저 완성하고, 소프트웨어 분류는 risk analysis 결과에 따라 결정하라. 분류를 먼저 정하고 risk analysis를 맞추는 접근은 감사에서 지적받는다.
IEC 62304 소프트웨어 개발 생명주기: 8개 활동 영역
IEC 62304 Clause 5는 소프트웨어 개발의 8개 활동 영역을 정의한다. 각 활동의 요구 수준은 안전 분류에 따라 다르다.
| 활동 | Class A (Level I) | Class B | Class C (Level II) |
|---|---|---|---|
| 5.1 개발계획 | 필수 | 필수 | 필수 |
| 5.2 요구사항 분석 | 필수 | 필수 | 필수 |
| 5.3 아키텍처 설계 | — | 필수 | 필수 |
| 5.4 상세 설계 | — | — | 필수 |
| 5.5 단위 검증(Unit Verification) | — | 부분 | 필수 |
| 5.6 통합 테스트 | — | 필수 | 필수 |
| 5.7 시스템 테스트 | 필수 | 필수 | 필수 |
| 5.8 소프트웨어 출시 | 필수 | 필수 | 필수 |
한국 디지털헬스 기업이 놓치기 쉬운 부분
1. 아키텍처 설계(5.3)가 없는 경우
Class B/C에서 소프트웨어 아키텍처 설계가 필수다. 하지만 많은 한국 스타트업이 Agile 개발을 하면서 아키텍처 문서를 생략한다. IEC 62304는 Agile을 금지하지 않는다. 하지만 각 스프린트가 요구사항 추적성을 유지하고, 아키텍처 결정이 문서화되어야 한다. Agile + IEC 62304 병행이 가능하지만, 일반적인 Agile보다 문서화 요구가 높다.
2. 단위 검증(5.5)의 증거 부족
Class C에서 각 소프트웨어 단위(unit)에 대한 검증이 필수다. 자동화된 테스트 코드만으로는 충분하지 않다. 테스트 결과, 커버리지, 결함 추적이 문서화되어야 한다. FDA는 소프트웨어 검증 관련 CSA(Computer Software Assurance) 가이던스(2026년 2월 최종)에서 리스크 기반 접근을 허용하지만, IEC 62304의 기본 요구는 여전히 엄격하다.
3. SOUP(Software of Unknown Provenance) 관리
한국 디지털헬스 기업이 오픈소스 라이브러리, 클라우드 API, 서드파티 SDK를 사용하는 경우, 이 모든 것이 SOUP이다. IEC 62304는 SOUP에 대해:
- 각 SOUP의 버전, 출처, 기능을 문서화
- SOUP의 알려진 결함과 보안 취약점을 평가
- SOUP에서 발생할 수 있는 위험 시나리오를 risk analysis에 포함
SOUP 관리가 없으면 NB 감사에서 거의 확실히 지적받는다.
위험관리(Clause 7)와 ISO 14971 연동
IEC 62304의 Clause 7은 소프트웨어 위험관리를 ISO 14971과 연동하도록 요구한다. 핵심:
- 소프트웨어 원인의 위험 식별: 소프트웨어 결함이 어떤 위해로 이어질 수 있는지
- 위험통제조치: 아키텍처, 설계, 코드 수준에서 통제
- 통제조치 검증: 통제조치가 실제로 위험을 완화하는지 테스트로 증명
- 잔여위험 평가: 통제 후에도 남는 위험의 수용 가능성 판단
SaMD와 AI/ML 기기의 위험관리
AI/ML 기반 의료기기에서 소프트웨어 위험관리가 특히 중요한 이유:
- 모델 성능이 입력 데이터에 따라 달라짐(data drift)
- 새로운 오류 모드(기존 소프트웨어에 없는 유형의 결함)
- 업데이트 후 성능 변화 가능성
FDA의 AI/ML 의료기기 가이던스와 PCCP(사전변경관리계획)는 IEC 62304 위험관리를 기본 프레임워크로 삼는다. FDA PCCP, 한국 AI 의료기기가 모델 업데이트를 재심사 없이 하는 법에서 PCCP와 IEC 62304의 연결을 확인할 수 있다.
형상관리(Clause 8)와 문제해결(Clause 9)
형상관리 요구사항
| 항목 | 요구 내용 |
|---|---|
| 소프트웨어 버전 관리 | 각 릴리스의 소프트웨어 버전, 포함된 변경사항, 테스트 결과 |
| 변경 통제 | 변경 요청 → 영향 평가 → 승인 → 구현 → 검증의 추적 |
| 베이스라인 | 출시 시점의 소프트웨어 구성(SOUP 포함)을 재현 가능하게 기록 |
문제해결(Problem Resolution)
결함(defect) 관리는 IEC 62304에서 단순 버그 트래킹 이상을 요구한다:
- 결함을 위험에 미치는 영향에 따라 분류
- 결함 수정이 새로운 위험을 유발하지 않는지 평가(regression risk)
- 모든 결함의 원인, 영향, 수정, 검증을 추적
제2판(2026) 주요 변경이 한국 기업에 미치는 영향
1. 두 단계 분류로 전환
Class A/B/C → Level I/II. 기존 Class B였던 제품이 Level II가 되어, Class C와 동일한 수준의 프로세스 요구를 받게 된다. 이는 상당수의 디지털헬스 기기에 요구사항 증가를 의미한다.
대응: 현재 Class B로 분류된 제품의 개발 프로세스를 Class C 수준으로 상향 검토하라. 8fold Governance의 분석에 따르면, Class B에서 Level II로 이동하는 기기의 문서는 소프트웨어 업데이트 시점 또는 리스크 기반 접근으로 Level II 기준에 맞춰야 한다. 감사에서 관대하게 보지 않을 가능성이 높다.
규제 도입 시점: IEC 표준이 발행되더라도 규제기관이 채택하기까지 보통 23년이 소요된다. 제2판이 2026년 말 발행된다고 가정하면, **20282029년경부터 제2판 준수가 실질적으로 요구**될 것으로 예상된다.
2. 건강 소프트웨어(Health Software) 범위 확장
제2판은 "의료기기 소프트웨어(MDSW)"에서 "건강 소프트웨어(Health Software)"로 범위를 넓힌다. 의료기기로 분류되지 않는 웰니스 앱이나 건강관리 소프트웨어에도 IEC 62304를 자발적으로 적용할 수 있는 길이 열린다.
한국 기업에 미치는 영향: "웰니스 vs 의료기기" 경계에 있는 제품(예: 스트레스 관리 앱, 수면 추적 앱)이 향후 규제 변경 시 의료기기로 재분류될 가능성에 대비해, IEC 62304 프로세스를 미리 도입하는 것이 유리하다.
3. AI/ML 조항 신설
제2판은 AI/ML 기반 소프트웨어에 대한 요구사항을 명시적으로 포함할 예정이다:
- 데이터 관리: 학습 데이터의 품질, 대표성, 편향 평가
- 모델 검증: 성능 지표, 일반화 가능성, 한계 명시
- 모니터링: 출시 후 모델 성능 추적, drift 감지
- 업데이트 관리: 모델 업데이트 시 재검증 요구사항
대응: AI/ML 기반 의료기기를 개발 중인 한국 기업은, 이미 FDA PCCP 가이던스와 EU AI Act 요건에 맞추고 있을 것이다. IEC 62304 제2판의 AI 조항은 이와 정렬될 것이므로, PCCP와 AI Act 대응을 IEC 62304 문서 체계와 통합하는 접근이 효율적이다.
FDA와 EU에서 IEC 62304가 어떻게 요구되는가
| 규제 체계 | IEC 62304 위치 | 준수 방식 |
|---|---|---|
| FDA 510(k)/De Novo/PMA | 인정 합의 표준. 소프트웨어 설명서(Software Documentation)에 IEC 62304 준수 근거 포함 | 준수를 선언하면 별도 검증 없이 인정. 불일치 시 사유 설명 필요 |
| EU MDR CE 마킹 | 조화 표준(EN 62304). 기술문서에 적용 증빙 필수 | 조화 표준을 따르면 GSPR(일반안전성능요건) 충족으로 간주 |
| EU IVDR | 조화 표준(EN 62304). IVD 소프트웨어에 동일 적용 | MDR과 동일 |
| FDA QMSR(2026.2~) | ISO 13485 기반 QMSR에서 소프트웨어 검증은 IEC 62304 참조 | QMSR 전환과 무관하게 소프트웨어 표준은 동일 |
한국 디지털헬스 기업이 지금 해야 할 것
제품별 IEC 62304 적용 현황 점검
| 점검 항목 | 현재 상태 | 필요 액션 |
|---|---|---|
| 소프트웨어 안전 분류 완료 | Class A/B/C 분류 및 근거 문서화 | 분류 근거가 risk analysis와 연동되어 있는지 확인 |
| 개발계획(SDP) 문서화 | 범위, 참조 표준, 활동, 산출물 명시 | Agile 환경에서도 SDP의 각 요구사항을 어떻게 충족하는지 명시 |
| 요구사항 추적성 | SRS → 설계 → 코드 → 테스트 양방향 추적 | 추적 매트릭스(traceability matrix) 구축 |
| SOUP 목록 | 사용 중인 모든 오픈소스·서드파티 소프트웨어 목록 | 버전, 라이선스, 알려진 취약점, 위험 평가 포함 |
| 위험관리 파일 | 소프트웨어 원인의 위험 식별, 통제, 검증 | ISO 14971과 IEC 62304 Clause 7 연동 확인 |
| 형상관리 | 소프트웨어 버전, 변경이력, 베이스라인 | Git 기반 관리 + 출시 베이스라인 문서화 |
| 검증 증거 | 단위/통합/시스템 테스트 결과, 커버리지 | 테스트 계획 → 결과 → 결함 추적의 완전성 |
90일 실행 계획
| 주 | 액션 | 담당 |
|---|---|---|
| 1~2주 | 포트폴리오 내 소프트웨어 포함 기기 목록, 현재 IEC 62304 적용 현황 진단 | RA + 개발 |
| 3~4주 | 안전 분류 재검토, risk analysis와 연동 확인, SOUP 목록 작성 | RA + 개발 |
| 5~6주 | 요구사항 추적 매트릭스 구축, 개발 프로세스와 IEC 62304 요구 매핑 | 개발 + QA |
| 7~8주 | 위험관리 파일 소프트웨어 섹션 보완, 형상관리 절차 문서화 | QA + RA |
| 9~10주 | 제2판(Level I/II) 전환 준비, Class B 제품의 프로세스 상향 검토 | RA + 개발 |
| 11~12주 | FDA 제출용 Software Documentation / CE 기술문서 소프트웨어 섹션 작성 | RA |
관련 자료
- IEC 62304:2006+A1:2015 (현재 유효 버전)
- FDA Recognized Consensus Standards — IEC 62304
- EU MDR Harmonised Standards — EN 62304
- MDCG 2019-11 Rev.1 (2025) — Qualification and Classification of Software
- FDA CSA (Computer Software Assurance) Final Guidance (2026)
- EU AI Act 고위험 분류, 한국 AI 의료기기가 2026년 8월 전에 정리해야 할 것