PRRC Korea

SPICE, 의료기기 소프트웨어 품질을 증명하는 보이지 않는 설계도

PRRC — Thu, 2 Jul 2026 15:49:41 +0900

소프트웨어 공학에서 SPICE(Software Process Improvement and Capability dEtermination)는 단순한 프로세스 평가 도구가 아니라, 품질을 구조적으로 담보하기 위한 국제 표준 체계입니다. 특히 의료기기 산업에서는 이 표준이 단순한 선택이 아닌 필수 요소로 자리 잡고 있습니다. 의료기기 소프트웨어의 오류는 환자의 안전과 직결되기 때문에, 개발 과정의 신뢰성과 추적 가능성이 법적 요구사항 수준으로 관리되어야 합니다.

SPICE는 ISO/IEC 15504에서 출발하여 현재 ISO/IEC 330xx 시리즈로 발전했으며, 프로세스의 성숙도를 객관적으로 평가할 수 있는 기준을 제공합니다. 의료기기 분야에서는 이를 기반으로 IEC 62304(의료기기 소프트웨어 생명주기 프로세스)와 연계하여, 개발·검증·유지보수 전 과정에서 일관된 품질 관리 체계를 수립합니다. 이는 단순한 문서화나 형식적 감사 대응을 넘어, 실제 위험 관리와 품질 향상을 위한 실질적 기반이 됩니다.

SPICE의 6단계 역량 수준 모델은 의료기기 제조사에게 단계적 개선 목표를 제시합니다. 예를 들어, Level 2의 ‘관리’ 단계에서는 프로세스 통제와 산출물 관리가 이루어지지만, Level 4 이상에서는 정량적 성과 분석과 예측이 가능해집니다. 이러한 정량적 품질 관리 체계는 규제기관 심사나 외부 감사에서 높은 신뢰를 얻는 핵심 요인이 됩니다.

결국 SPICE는 ‘품질 보증의 언어’를 국제적으로 통일시키는 역할을 합니다. 의료기기 제조사는 이를 통해 내부 개발 역량을 체계화하고, 외부 이해관계자에게 ‘이 제품은 프로세스부터 안전하다’는 신뢰를 전달할 수 있습니다. SPICE는 눈에 보이지 않지만, 의료기기 소프트웨어의 안전성과 품질을 떠받치는 가장 견고한 설계도입니다.

3줄 요약
1. SPICE는 소프트웨어 프로세스의 역량을 체계적으로 평가하고 개선하는 국제 표준입니다.
2. 의료기기 분야에서는 IEC 62304와 연계되어 안전성과 추적 가능성을 보장합니다.
3. SPICE는 규제 대응뿐 아니라 품질과 신뢰성을 구조적으로 강화하는 기반이 됩니다.

의료기기 개발, CMMI는 단순한 인증이 아니라 ‘프로세스의 근육’을 키우는 일!

PRRC — Wed, 1 Jul 2026 15:47:45 +0900

의료기기 산업에서 품질과 신뢰성은 생명과 직결됩니다. 이러한 산업적 특성 속에서 조직의 개발 역량을 객관적으로 평가하고 지속적으로 개선하기 위한 도구로 CMMI(Capability Maturity Model Integration)는 중요한 의미를 가집니다. 많은 기업이 이를 ‘인증’으로만 인식하지만, 실제로는 조직의 개발 프로세스를 성숙하게 만드는 ‘경영 시스템’에 가깝습니다.

CMMI는 미국 카네기 멜런 대학 소프트웨어공학연구소(SEI)가 국방성의 의뢰로 개발한 모델로, 현재는 소프트웨어뿐 아니라 의료기기, 항공, 국방, 자동차 등 다양한 분야에서 활용되고 있습니다. 특히 ISO 13485와 같은 품질경영시스템(QMS)과 병행할 때, 의료기기 개발 프로세스의 예측 가능성과 규제 대응력을 극대화할 수 있습니다.

CMMI는 성숙도 레벨을 1에서 5까지로 구분합니다. 초기 단계에서는 개인의 역량에 의존한 비체계적인 개발이 이루어지지만, 레벨 3 이상부터는 조직 차원의 표준화된 개발 프로세스가 자리 잡습니다. 레벨 4와 5에서는 정량적 분석과 지속적 개선이 핵심이 됩니다. 이는 단순히 문서를 잘 관리하는 수준을 넘어, 품질 문제의 원인을 통계적으로 파악하고 예방하는 문화를 정착시키는 것을 의미합니다.

의료기기 개발 환경에서 CMMI의 도입은 다음과 같은 효과를 가져옵니다.
첫째, 개발 과정에서의 오류와 재작업을 줄여 설계 변경으로 인한 규제 리스크를 최소화할 수 있습니다.
둘째, 프로젝트 일정과 비용 예측이 정밀해져 임상시험 및 허가 일정의 불확실성을 줄입니다.
셋째, 외부 심사기관이나 고객(특히 해외 파트너)에게 체계적인 개발 문화를 입증함으로써 신뢰성을 높일 수 있습니다.

결국, CMMI는 ‘개발 문화를 바꾸는 일’입니다. 의료기기 기업이 안전성과 혁신성을 동시에 추구하기 위해서는 기술력뿐 아니라 프로세스 관리 능력이 뒷받침되어야 합니다. CMMI는 그 기반을 과학적으로 강화하는 체계적 도구입니다.

3줄 요약
1. CMMI는 단순한 인증이 아닌 조직의 프로세스 성숙도를 평가·개선하는 국제 표준 모델입니다.
2. 의료기기 산업에서는 ISO 13485와 병행해 품질관리와 규제 대응력을 강화할 수 있습니다.
3. 정량적 관리와 지속적 개선을 통해 품질, 일정, 신뢰성을 모두 확보할 수 있습니다.

의료기기 설계개발 파일 구성과 규제 대응을 위한 문서 체계의 이해

PRRC — Mon, 9 Mar 2026 23:27:56 +0900

의료기기 개발 과정에서는 단순한 기술 개발뿐 아니라 규제 요구사항을 충족하기 위한 체계적인 설계개발 문서 관리가 필수적입니다. 국제 규격인 ISO 13485와 IEC 62304, IEC 62366, ISO 14971 등의 요구사항을 반영하면 설계개발 파일은 단순한 문서 목록이 아니라 설계 입력부터 검증·검증, 사용성, 사이버보안, 위험관리까지 전 과정을 연결하는 체계로 구성됩니다.

일반적으로 설계개발 파일은 Design & Development Plan을 기반으로 시작합니다. 해당 문서에서는 개발 단계, 책임, 검토 시점, 산출물 등을 정의합니다. 이후 Design & Development Input 문서를 통해 사용자 요구사항(User Requirement Specification), 소프트웨어 요구사항(Software Requirement Specification), 사용 환경, 규제 요구사항, 안전 관련 요구사항 등이 정리됩니다. 이 과정에서 Intended Use and Reasonably Foreseeable Misuse, Identification of Characteristics Related to Safety, Use Specification과 같은 문서가 중요한 역할을 합니다. 특히 IEC 62366에 따라 Hazard-related Use Scenario와 User Interface Characteristics related to Safety and Potential Use Error를 정의하는 과정은 사용성 위험을 체계적으로 관리하는 핵심 단계입니다.

소프트웨어 기반 의료기기의 경우 IEC 62304에 따라 Software Development Plan(SDP), Software Architecture Document, Software Design Specification 등이 작성되며, 소프트웨어 요구사항과 설계 간의 일관성이 확보되어야 합니다. 또한 최근 규제에서는 사이버보안 요구가 강화되고 있기 때문에 Cyber Security Checklist와 Cyber Security Report와 같은 문서를 통해 보안 요구사항의 반영 여부를 관리합니다.

설계 산출물 단계에서는 User Interface Specification, Service Manual, Installation Manual, Label Drawing, Admin Manual과 같은 사용자 및 서비스 관련 문서가 포함됩니다. 이러한 문서들은 단순한 설명 자료가 아니라 규제 요구사항에 따른 안전 정보 전달 수단이며, Labeling Requirement와 연결되어 관리됩니다.

검증 및 검증 단계에서는 Unit Test, Integration Test, System Test, Performance Test 등 다양한 시험 계획과 결과 문서가 작성됩니다. 또한 사용성 평가를 위한 Formative Evaluation과 Summative Evaluation은 IEC 62366에 따른 필수 절차이며, 실제 사용 환경에서 발생할 수 있는 사용 오류를 확인하는 과정입니다. 이러한 시험 결과들은 Design and Development V&V Report로 종합 정리됩니다.

위험관리는 ISO 14971에 따라 수행되며, 설계 단계에서 pFMEA와 같은 위험 분석 문서를 통해 위험 식별과 통제가 이루어집니다. 이때 위험관리 결과는 설계 입력, 설계 출력, 검증 활동과 상호 연계되어야 하며, Traceability Matrix를 통해 요구사항, 설계, 시험 간의 추적성이 확보됩니다.

마지막 단계에서는 Design and Development Completion Review를 통해 설계개발 과정 전체를 검토합니다. 이 과정에서 설계 입력이 설계 출력으로 적절히 구현되었는지, 검증 및 검증 활동이 충분히 수행되었는지, 위험관리와 사용성 평가가 규제 요구사항을 충족하는지 확인합니다. 이러한 체계적인 문서 관리가 이루어질 때 설계개발 파일은 단순한 기록이 아니라 의료기기의 안전성과 규제 적합성을 입증하는 핵심 근거 자료가 됩니다.

3줄 요약
1. 의료기기 설계개발 파일은 ISO 13485, IEC 62304, IEC 62366, ISO 14971 요구사항을 반영한 체계적인 문서 구조로 관리됩니다.
2. 설계 입력부터 설계 출력, 시험, 사용성 평가, 위험관리까지 모든 과정은 추적성 확보를 중심으로 연결됩니다.
3. 체계적인 설계개발 문서 관리가 의료기기 안전성 입증과 규제 승인 대응의 핵심 기반이 됩니다.

심사가 필요한 디지털의료기기소프트웨어 변경사항

PRRC — Sun, 8 Mar 2026 23:11:40 +0900

디지털의료기기 소프트웨어는 특성상 지속적인 업데이트와 개선이 이루어집니다. 개발자에게는 자연스러운 개선일 수 있지만, 규제 관점에서는 작은 수정 하나가 허가사항 변경으로 이어질 수 있습니다. 실제로 많은 제조사가 “기능 개선” 또는 “운영환경 업데이트” 정도로 생각했던 변경이 규제상 변경허가 또는 변경신고 대상이 되는 사례가 반복적으로 발생합니다. 문제는 대부분의 변경이 기술적으로는 작아 보이지만, 안전성·유효성 또는 사용적합성에 영향을 줄 가능성이 있는지 여부로 판단된다는 점입니다.

디지털의료기기 소프트웨어에서 가장 대표적인 변경은 성능 또는 기능의 변화입니다. 예를 들어 진단 보조 기능이 추가되거나, 기존 알고리즘의 판단 기준이 조정되거나, 새로운 분석 지표가 도입되는 경우에는 단순한 기능 개선으로 보지 않습니다. 특히 인공지능 기반 소프트웨어의 경우 학습 데이터의 추가, 모델 구조의 변경, 또는 알고리즘 방식이 변경되는 경우에는 성능 특성 자체가 달라질 수 있기 때문에 규제기관에서는 이를 중요한 변경으로 간주합니다. 반대로 단순한 사용자 설명 문구 수정이나 오탈자 수정과 같이 기능이나 성능에 영향을 미치지 않는 경우에는 변경허가 대상이 되지 않습니다.

개발 환경이나 운영 환경의 변화도 간과하기 쉬운 영역입니다. 예를 들어 소프트웨어 개발 언어가 변경되거나 특정 운영체제에서 다른 운영체제로 확장되는 경우, 또는 지원 플랫폼이 추가되는 경우에는 시스템 동작 방식이 달라질 수 있습니다. 다만 동일 운영체제 내에서의 일반적인 버전 업그레이드, 예를 들어 특정 OS의 세부 버전 변경과 같은 경우는 통상적으로 중대한 변경으로 보지 않는 경우가 많습니다. 그러나 플랫폼 추가나 운영환경 확장은 실제 사용 환경을 바꾸는 요소이기 때문에 규제 검토 대상이 될 가능성이 높습니다.

또 하나 중요한 영역은 통신 기능입니다. 최근 디지털의료기기는 네트워크를 통해 데이터를 송수신하거나 원격 업데이트 기능을 포함하는 경우가 많습니다. 이 과정에서 통신 방식이 변경되거나, 새로운 데이터 교환 기능이 추가되면 사이버보안 및 전자적 침해 대응 측면에서 평가가 필요합니다. 이는 단순한 기술 변경이 아니라 환자 데이터 보호와 시스템 안전성에 직접 연결되기 때문입니다.

마지막으로 사용적합성 역시 중요한 판단 기준입니다. 사용자 인터페이스 변경이 단순한 화면 구성 변경에 그치지 않고 사용자의 조작 방식이나 인지 과정에 영향을 준다면 이는 규제 관점에서 의미 있는 변경으로 판단될 수 있습니다. 특히 임상 판단을 지원하는 소프트웨어의 경우 인터페이스 변화가 의료진의 의사결정 흐름에 영향을 줄 수 있기 때문에 더욱 신중한 검토가 필요합니다.

결국 디지털의료기기 소프트웨어의 변경관리에서 핵심은 “개발자 관점의 작은 수정”이 아니라 “환자 안전과 임상적 성능에 영향을 줄 가능성”입니다. 변경의 크기가 아니라 영향의 범위를 중심으로 판단해야 하며, 사전에 규제 요구사항을 검토하는 체계적인 변경관리 전략이 필수적입니다. 디지털의료기기 시대에는 업데이트 속도보다 규제 이해도가 더 중요한 경쟁력이 됩니다.

3줄 요약
1. 디지털의료기기 소프트웨어는 작은 업데이트라도 안전성, 유효성, 사용적합성에 영향을 주면 허가사항 변경 대상이 될 수 있습니다.
2. 알고리즘 변경, 운영환경 확장, 통신기능 추가, UI 변화 등은 규제기관이 중요하게 보는 변경 요소입니다.
3. 변경의 크기가 아니라 환자 안전과 임상 성능에 미치는 영향을 기준으로 변경관리 전략을 수립해야 합니다.

IEC 62304 Class A/B/C 등급별 요구사항 정리

PRRC — Sat, 7 Mar 2026 21:41:49 +0900

5.1 Software Development Planning
Clause	내용	Class A	Class B	Class C
5.1.1	Software development plan	✔	✔	✔
5.1.2	Keep software development plan updated	✔	✔	✔
5.1.3	Reference to system D&D	✔	✔	✔
5.1.4	Development standards, methods, tools planning	✖	✖	✔
5.1.5	Integration & integration test planning	✖	✔	✔
5.1.6	Software verification planning	✔	✔	✔
5.1.7	Software risk management planning	✔	✔	✔
5.1.8	Documentation planning	✔	✔	✔
5.1.9	Configuration management planning	✔	✔	✔
5.1.10	Supporting items control	✖	✔	✔
5.1.11	Configuration item control before verification	✔	✔	✔
5.1.12	Avoid common software defects	✖	✔	✔


5.2 Software Requirement Analysis
Clause	내용	Class A	Class B	Class C
5.2.1	Define software requirements from system requirements	✔	✔	✔
5.2.2	Software requirements content	✔	✔	✔
5.2.3	Include risk control measures	✖	✔	✔
5.2.4	Re-evaluate medical device risk analysis	✔	✔	✔
5.2.5	Update requirements	✔	✔	✔
5.2.6	Verify software requirements	✔	✔	✔


5.3 Software Architectural Design
Clause	내용	Class A	Class B	Class C
5.3.1	Transform requirements into architecture	✖	✔	✔
5.3.2	Develop architecture for interfaces	✖	✔	✔
5.3.3	Specify SOUP functional/performance requirements	✖	✔	✔
5.3.4	Specify hardware & software required by SOUP	✖	✔	✔
5.3.5	Identify segregation for risk control	✖	✖	✔
5.3.6	Verify software architecture	✖	✔	✔


5.4 Software Detailed Design
Clause	내용	Class A	Class B	Class C
5.4.1	Subdivide into software units	✖	✔	✔
5.4.2	Develop detailed design for each unit	✖	✖	✔
5.4.3	Develop interface design	✖	✖	✔
5.4.4	Verify detailed design	✖	✖	✔


5.5 Software Unit Implementation
Clause	내용	Class A	Class B	Class C
5.5.1	Implement each software unit	✔	✔	✔
5.5.2	Establish unit verification process	✖	✔	✔
5.5.3	Unit acceptance criteria	✖	✔	✔
5.5.4	Additional acceptance criteria	✖	✖	✔
5.5.5	Software unit verification	✖	✔	✔


5.6 Software Integration & Integration Testing
Clause	내용	Class A	Class B	Class C
5.6.1	Integrate software units	✖	✔	✔
5.6.2	Verify integration	✖	✔	✔
5.6.3	Integration testing	✖	✔	✔
5.6.4	Integration testing content	✖	✔	✔
5.6.5	Evaluate test procedures	✖	✔	✔
5.6.6	Regression tests	✖	✔	✔
5.6.7	Integration test records	✖	✔	✔
5.6.8	Problem resolution process	✖	✔	✔


5.7 Software System Testing
Clause	내용	Class A	Class B	Class C
5.7.1	Establish tests for requirements	✔	✔	✔
5.7.2	Use problem resolution process	✔	✔	✔
5.7.3	Retest after changes	✔	✔	✔
5.7.4	Evaluate system testing	✔	✔	✔
5.7.5	System test record contents	✔	✔	✔


5.8 Software Release
Clause	내용	Class A	Class B	Class C
5.8.1	Ensure verification complete	✔	✔	✔
5.8.2	Document residual anomalies	✔	✔	✔
5.8.3	Evaluate residual anomalies	✔	✔	✔
5.8.4	Document released version	✔	✔	✔
5.8.5	Document build process	✖	✔	✔
5.8.6	Ensure tasks complete	✖	✔	✔
5.8.7	Archive software	✔	✔	✔
5.8.8	Assure delivery reliability	✖	✔	✔

EU MDR Class IIa로 분류되는 디지털치료제(디지털치료기기)

PRRC — Sat, 7 Mar 2026 21:32:47 +0900

EU 의료기기 규정(MDR)이 시행된 이후 디지털 헬스 업계에서는 자주 들리는 말이 있습니다. 이제 Class I 소프트웨어는 사실상 사라졌다는 이야기입니다. 특히 디지털 치료제(DTx)나 의료 소프트웨어 분야에서는 MDR Rule 11이 대부분의 제품을 Class IIa 이상으로 끌어올렸다는 해석이 널리 퍼져 있습니다. 그러나 규정의 실제 취지를 들여다보면, Class I이 사라졌다기보다 의료 소프트웨어의 정의와 역할이 보다 명확하게 정리되었다고 보는 것이 더 정확합니다.

과거 MDD 체계에서는 상당수의 의료 소프트웨어가 Class I으로 분류될 수 있었습니다. 특히 단순 건강관리 앱이나 데이터 기록용 소프트웨어도 의료 목적을 주장하는 경우가 있었고, 제조자가 스스로 적합성을 선언하는 방식으로 시장에 진입하는 사례도 많았습니다. 그러나 MDR은 소프트웨어가 의료 의사결정에 미치는 영향과 환자 위험도를 보다 엄격하게 평가하도록 설계되었습니다. 그 중심에 있는 규정이 바로 Rule 11입니다.

Rule 11은 소프트웨어가 진단 또는 치료 목적의 의사결정에 정보를 제공하는 경우 최소 Class IIa로 분류하도록 규정합니다. 또한 환자의 생리적 과정을 모니터링하고 그 결과가 임상적 개입으로 이어질 수 있는 경우에도 상위 등급으로 분류될 수 있습니다. 이 때문에 실제 디지털 치료제, 임상 의사결정 지원 소프트웨어, 환자 모니터링 애플리케이션 등은 대부분 Class IIa 또는 그 이상으로 분류됩니다. 업계에서 "소프트웨어의 업클래싱(up-classification)"이라는 표현이 등장한 이유도 여기에 있습니다.

다만 여기서 한 가지 중요한 점이 있습니다. Rule 11은 모든 소프트웨어를 자동으로 상위 등급으로 올리는 규정이 아닙니다. 의료 의사결정에 영향을 주지 않거나, 단순히 데이터를 저장하거나 표시하는 수준의 소프트웨어는 여전히 Class I으로 분류될 수 있습니다. 예를 들어 건강 데이터를 단순 기록하거나, 의료 데이터의 보관 및 표시 기능만 수행하며 임상적 판단을 유도하지 않는 소프트웨어는 여전히 낮은 위험도로 평가됩니다. 다만 이러한 기능만으로는 의료기기로 분류되지 않는 경우도 많기 때문에, 결과적으로 시장에서 Class I 의료 소프트웨어의 사례가 줄어든 것처럼 보이는 것입니다.

또한 디지털 치료제는 그 정의 자체가 치료 개입을 제공하거나 환자의 행동 변화를 유도하는 소프트웨어이기 때문에 대부분 의료 의사결정이나 임상적 관리에 영향을 미칩니다. 이러한 특성 때문에 실제로는 Class IIa 이상으로 분류되는 경우가 일반적이며, Notified Body 심사를 거쳐야 하는 구조가 됩니다. 결국 MDR이 만든 변화는 Class I의 소멸이 아니라, 의료 소프트웨어가 실제로 환자에게 미치는 영향을 규제 체계 안에서 보다 정밀하게 반영한 것이라고 볼 수 있습니다.

따라서 "Class I이 사라졌다"는 표현은 규정의 결과를 과장한 업계의 해석에 가깝습니다. MDR은 소프트웨어를 더 높은 등급으로 끌어올리기 위해 만들어진 규정이 아니라, 의료 목적과 임상적 영향도를 기준으로 위험 기반 분류를 명확하게 적용하기 위한 체계입니다. 그리고 그 과정에서 많은 디지털 헬스 제품들이 비로소 자신이 속해야 할 등급을 찾게 되었다고 보는 편이 더 타당합니다.

요약하자면 MDR Rule 11은 디지털 치료제와 의료 소프트웨어의 규제 환경을 크게 바꾸었지만, Class I이 사라진 것은 아닙니다. 다만 이제는 단순 기능 이상의 의료 소프트웨어가 더 이상 낮은 위험 등급에 머무르기 어려워졌을 뿐입니다.

3줄 요약
1. MDR Rule 11은 의료 의사결정에 영향을 주는 소프트웨어를 최소 Class IIa 이상으로 분류하도록 합니다.
2. 디지털 치료제와 임상 의사결정 지원 소프트웨어는 대부분 이 기준에 해당합니다.
3. Class I이 사라진 것이 아니라, 실제로 Class I에 해당하는 의료 소프트웨어의 범위가 매우 제한적일 뿐입니다.

의료기기 소프트웨어는 왜 ‘버그 수정’과 ‘알고리즘 변경’을 다르게 볼까?

PRRC — Sat, 7 Mar 2026 17:14:00 +0900

의료기기 소프트웨어를 개발하거나 운영하다 보면 “이 정도 수정은 그냥 업데이트 아닌가요?”라는 질문을 자주 듣습니다. 일반 IT 소프트웨어라면 단순 업데이트로 넘어갈 수 있는 변화도 의료기기 영역에서는 전혀 다른 의미를 가질 수 있기 때문입니다. 규제 관점에서 보면, 무엇이 단순 유지보수이고 무엇이 성능 변경인지 구분하는 일은 생각보다 훨씬 중요합니다.

먼저 소프트웨어 업그레이드로 보지 않는 대표적인 사례는 유지보수 수준의 변경입니다. 예를 들어 사용 중 발견된 결함이나 오류를 제거하거나 시스템 안정성을 개선하기 위한 수정은 일반적으로 기능이나 성능을 변화시키지 않기 때문에 경미한 변경으로 간주됩니다. 사용자 환경을 개선하기 위해 UI를 조정하거나 메뉴 구조를 변경하는 경우도 마찬가지입니다. 이러한 변경은 사용성 향상에 해당할 뿐 의료적 판단이나 분석 결과에 영향을 주지 않기 때문입니다. 또한 사이버보안 강화를 위해 보안 패치를 적용하거나 악성코드 대응 기능을 추가하는 것도 대부분 유지관리 범주에 포함됩니다. 최근 규제기관들도 의료기기 사이버보안을 중요한 요소로 보고 있지만, 진단 성능이나 임상적 기능이 변하지 않는다면 이는 업그레이드가 아니라 관리 차원의 조치로 판단하는 경우가 많습니다.

하지만 겉보기에는 비슷해 보여도 규제적으로 완전히 다른 의미를 갖는 변경도 있습니다. 예를 들어 의료영상을 분석해 의심 영역을 표시하는 소프트웨어에 병변의 심각도 분석 기능을 추가한다면 이야기가 달라집니다. 이는 단순한 표시 기능을 넘어 새로운 정보처리 기능이 추가되는 것으로, 의료적 의사결정에 영향을 줄 가능성이 있기 때문입니다. 또한 기존 알고리즘에 새로운 분석 방법을 추가하거나 분석 로직 자체를 다른 방식으로 변경하는 경우 역시 성능 변화가 발생할 수 있으므로 경미한 변경으로 보지 않습니다. 이런 변화는 사실상 제품 성능의 재정의를 의미할 수 있기 때문에 추가 허가나 심사가 필요할 수 있습니다.

결국 의료기기 소프트웨어에서 중요한 질문은 “코드가 얼마나 바뀌었는가”가 아니라 “의료적 기능이 달라졌는가”입니다. 개발자 입장에서는 작은 코드 변경처럼 보일 수 있지만, 규제기관은 그 변화가 임상적 판단에 영향을 주는지를 기준으로 평가합니다. 그래서 의료기기 소프트웨어 업데이트에서는 기능 변화 여부, 알고리즘 변경 여부, 임상적 의미의 변화 여부를 먼저 검토하는 것이 무엇보다 중요합니다.

이 차이를 이해하지 못하면 단순 업데이트라고 생각했던 변경이 허가 변경 대상이 되는 상황이 발생할 수 있습니다. 의료기기 소프트웨어에서 ‘작은 수정’이 때로는 가장 큰 규제 이슈가 되는 이유가 바로 여기에 있습니다.

3줄 요약
1. 버그 수정, UI 변경, 보안 패치 등은 일반적으로 소프트웨어 업그레이드가 아닌 유지보수 또는 경미한 변경에 해당합니다.
2. 알고리즘 변경이나 새로운 분석 기능 추가는 성능 변화로 간주되어 경미한 변경으로 보기 어렵습니다.
3. 의료기기 소프트웨어 규제에서는 코드 변경 규모가 아니라 의료적 기능 변화 여부가 판단 기준이 됩니다.

의료기기 소프트웨어의 밸리데이션 (화이트박스와 블랙박스 접근법)

PRRC — Sat, 7 Mar 2026 16:58:43 +0900

밸리데이션은 소프트웨어가 의도한 대로 유효하고 효과적으로 작동하는지 확인하는 과정입니다. 이 과정은 의료기기 소프트웨어의 안전성과 신뢰성을 보장하는 데 필수적입니다.

초기 단계 (화이트박스 접근법): 밸리데이션의 첫 단계는 소프트웨어의 설계 요건과 구조를 고려하여 코딩하는 것입니다. 이 단계에서는 개별 모듈이 의도대로 정확하게 작동하는지 확인합니다. 이 과정에서 화이트박스 접근법이 사용됩니다. 화이트박스 접근법은 소프트웨어의 내부 구조와 작동 방식을 상세히 이해하고 검증하는 방식입니다. 이를 통해 각 모듈이 정확하게 코딩되었는지 확인하며, 오류를 사전에 식별하고 수정합니다.

통합 및 최종 검증 (블랙박스 접근법): 모든 모듈의 검증이 완료되면, 이들을 통합하여 전체 소프트웨어를 구성합니다. 이후에는 전체 소프트웨어를 대상으로 다시 검증을 진행합니다. 이 단계에서는 블랙박스 접근법이 사용됩니다. 블랙박스 접근법은 소프트웨어의 내부 구조보다는 입력과 출력의 결과에 중점을 둡니다. 이 방법을 통해 전체 소프트웨어가 사용자의 요구 사항을 만족하며, 예상대로 작동하는지 확인합니다.

소프트웨어 의료기기 (SaMD) 위험관리 방법

PRRC — Sat, 7 Mar 2026 16:57:18 +0900

소프트웨어의 사용목적 및 안전성 관련 특성 식별
소프트웨어의 사용목적과 적용 범위를 명확히 정의해야 합니다.
소프트웨어가 사용목적을 달성하는 데 어떠한 역할을 하는지 파악해야 합니다.
이를 통해 필요한 소프트웨어의 기능적 특성을 식별하고, 이들 중 안전성에 영향을 미치는 요소를 파악해야 합니다.

위해요인 분석
제조자는 위험관리 프로세스에 따라 정상 및 고장 상태에서 발생 가능한 위해요인을 분석해야 합니다.
오작동, 측정 오류, 과도한 출력, 데이터 손실 등이 발생할 수 있는 위해요인을 파악하고 이에 대한 대책을 마련해야 합니다.
소프트웨어의 사용목적과 적용범위를 명확히 하여 이를 달성하기 위한 소프트웨어의 역할을 정확히 이해하고 위해요인을 분석하는 것이 중요합니다.

의료기기 소프트웨어의 가장 위험한 친구, SOUP를 아십니까

PRRC — Sat, 7 Mar 2026 16:30:15 +0900

의료기기 소프트웨어를 개발하다 보면 의외로 많은 기능이 외부에서 가져온 코드에 의존하고 있다는 사실을 발견하게 됩니다. 운영체제, 데이터베이스, 그래픽 라이브러리, 네트워크 모듈, 심지어 보안 라이브러리까지 대부분이 이미 존재하는 소프트웨어 위에서 동작합니다. 이러한 외부 소프트웨어를 IEC 62304에서는 SOUP(Software of Unknown Provenance)라고 부릅니다. 직역하면 출처를 알 수 없는 소프트웨어이지만, 실제 의미는 조금 다릅니다. 개발자가 직접 개발하지 않았거나 개발 과정에 대한 충분한 기록을 확보하지 못한 소프트웨어를 의미합니다.

많은 사람들이 SOUP를 단순히 오픈소스 소프트웨어로 이해하기도 하지만 이는 정확한 해석은 아닙니다. 상용 소프트웨어, 서드파티 라이브러리, 운영체제, 클라우드 서비스, 심지어 내부에서 과거에 개발되었지만 개발 기록이 충분히 남아있지 않은 레거시 코드까지도 SOUP로 분류될 수 있습니다. 즉 핵심 기준은 공개 여부가 아니라 개발 과정의 투명성과 문서화 수준입니다.

IEC 62304가 SOUP를 특별히 강조하는 이유는 명확합니다. 의료기기 제조사가 직접 통제하지 못하는 코드이기 때문입니다. 개발자가 직접 작성한 코드라면 설계 의도와 테스트 결과를 모두 파악할 수 있지만, 외부 소프트웨어는 그렇지 않습니다. 따라서 규격에서는 SOUP를 사용할 경우 반드시 해당 소프트웨어의 이름, 제조사, 버전, 사용 목적, 시스템 내 위치 등을 명확히 식별하고 문서화하도록 요구합니다. 최근에는 이러한 정보를 체계적으로 관리하기 위해 SBOM(Software Bill of Materials)을 활용하는 사례도 증가하고 있습니다.

하지만 단순히 목록을 만드는 것만으로는 충분하지 않습니다. IEC 62304의 핵심 요구사항은 위험 관리입니다. SOUP가 오동작하거나 보안 취약점이 발생했을 때 의료기기의 안전성에 어떤 영향을 미칠 수 있는지를 분석해야 합니다. 예를 들어 네트워크 라이브러리의 오류가 환자 데이터 손상으로 이어질 가능성은 없는지, 운영체제 업데이트가 장비의 실시간 동작을 방해할 가능성은 없는지 등을 검토해야 합니다. 이러한 분석은 ISO 14971 기반의 위험 관리 활동과 연계되어 수행됩니다.

또 하나 중요한 부분은 SOUP의 지속적인 관리입니다. 외부 소프트웨어는 시간이 지나면서 새로운 취약점이 발견되거나 업데이트가 발생합니다. 따라서 제조사는 패치와 버전 변경이 발생할 때마다 의료기기 안전성에 미치는 영향을 평가해야 합니다. 경우에 따라서는 업데이트 적용 전에 추가 검증이나 재시험이 필요할 수도 있습니다. 규제기관이 최근 사이버보안을 강조하는 것도 결국 이 SOUP 관리와 깊이 연결되어 있습니다.

흥미로운 점은 의료기기 소프트웨어에서 가장 안정적으로 보이는 구성 요소가 오히려 가장 큰 불확실성을 가지고 있을 수 있다는 사실입니다. 개발자가 직접 작성한 코드보다 수십만 줄의 외부 라이브러리가 더 많은 위험을 내포할 수 있기 때문입니다. 결국 SOUP 관리의 핵심은 외부 소프트웨어를 제거하는 것이 아니라, 그것을 얼마나 잘 이해하고 통제 가능한 형태로 관리하느냐에 달려 있습니다.

의료기기 소프트웨어 개발에서 SOUP는 피할 수 없는 존재입니다. 그러나 제대로 관리되지 않은 SOUP는 단순한 편의 기능이 아니라 규제 리스크와 환자 안전 리스크로 이어질 수 있습니다. 의료기기 규제의 관점에서 보면 SOUP는 기술적인 문제가 아니라 책임의 문제입니다. 외부에서 만들어진 코드라 하더라도, 의료기기 안에서 사용되는 순간 그 책임은 전적으로 제조사에게 있기 때문입니다.

3줄 요약
1. SOUP는 개발자가 직접 개발하지 않았거나 개발 과정 기록이 부족한 외부 소프트웨어를 의미합니다.
2. IEC 62304는 SOUP 식별, 문서화, 위험 분석, 지속적인 업데이트 관리를 요구합니다.
3. 외부 소프트웨어라 하더라도 의료기기에 사용되는 순간 모든 책임은 제조사에게 있습니다.