MEDISW-01. IEC 62304의 개념 체계: 프로세스, 활동, 태스크

IEC 62304는 의료기기 소프트웨어의 오작동으로 인한 환자 안전사고를 방지하기 위해, 개발부터 폐기까지 전 수명주기에 걸쳐 요구되는 프로세스를 정의한 핵심 국제 표준입니다. 이 표준은 "무엇을 해야 하는가(What)"에 초점을 맞추며, 구체적으로 "어떻게 할 것인가(How)"는 조직의 재량에 맡깁니다. 표준의 요구사항은 다음과 같은 계층적 구조를 통해 체계적으로 관리됩니다.

• 프로세스 (Process): 가장 큰 단위의 목적별 집합 (예: 소프트웨어 개발)
• 활동 (Activity): 프로세스를 구성하는 주요 단계 (예: 소프트웨어 요구사항 분석)
• 태스크 (Task): 활동을 완료하기 위한 구체적인 과업 (예: 기능 요구사항 문서화)

1. 프로세스 (Process)

프로세스는 소프트웨어 수명주기의 주요 단계를 나타내는 가장 상위 레벨의 집합입니다. IEC 62304는 다음과 같은 핵심 프로세스를 정의합니다.

• 소프트웨어 개발 프로세스 (Clause 5): 새로운 소프트웨어를 기획하고, 개발하고, 테스트하고, 릴리스하는 전 과정입니다.
• 소프트웨어 유지보수 프로세스 (Clause 6): 이미 릴리스된 소프트웨어의 문제를 수정하거나 기능을 변경할 때, 새로운 위험을 유발하지 않고 안전성을 유지하도록 체계적으로 관리하는 과정입니다.
• 소프트웨어 위험 관리 프로세스 (Clause 7): 소프트웨어와 관련된 잠재적 위험을 식별, 분석, 통제하는 과정입니다. (ISO 14971과 밀접하게 연관됨)
• 소프트웨어 형상 관리 프로세스 (Clause 8): 소프트웨어 개발 과정에서 발생하는 모든 산출물(소스 코드, 설계 문서, 테스트 케이스 등)의 변경 이력을 체계적으로 추적하고 관리하여, 특정 시점의 버전을 정확하게 재현할 수 있도록 보장하는 과정입니다.
• 소프트웨어 문제 해결 프로세스 (Clause 9): 사용자와 시장으로부터 피드백 및 문제 보고를 접수하고, 분석하여 처리하는 과정입니다.

2. 활동 (Activity)

활동은 각 프로세스를 구성하는 논리적인 작업 단위입니다. 하나의 프로세스는 여러 개의 활동으로 나뉩니다. 예를 들어, 가장 핵심적인 소프트웨어 개발 프로세스(Clause 5)는 다음과 같은 활동들로 구성됩니다.

• 5.1 소프트웨어 개발 계획 (Software development planning): 개발에 필요한 활동, 책임, 산출물을 계획합니다.
• 5.2 소프트웨어 요구사항 분석 (Software requirements analysis): 소프트웨어가 수행해야 할 기능, 성능, 인터페이스 등을 정의합니다.
• 5.3 소프트웨어 아키텍처 설계 (Software architectural design): 요구사항을 만족시키기 위한 소프트웨어의 전체적인 구조를 설계합니다.
• 5.4 소프트웨어 상세 설계 (Software detailed design): 아키텍처를 기반으로 각 소프트웨어 단위를 더 상세하게 설계합니다.
• 5.5 소프트웨어 단위 구현 및 검증 (Software unit implementation and verification): 상세 설계를 바탕으로 코드를 작성하고(구현), 각 단위가 올바르게 동작하는지 검증합니다.
• 5.6 소프트웨어 통합 및 통합 시험 (Software integration and integration testing): 개발된 단위들을 결합(통합)하고, 통합된 시스템이 올바르게 상호작용하는지 시험합니다.
• 5.7 소프트웨어 시스템 시험 (Software system testing): 완성된 소프트웨어 시스템이 모든 요구사항을 만족하는지 최종적으로 시험합니다.
• 5.8 소프트웨어 릴리스 (Software release): 시험이 완료된 소프트웨어를 사용자에게 배포하기 위한 절차를 수행합니다.

3. 태스크 (Task)

태스크는 활동을 수행하기 위해 실행해야 하는 가장 구체적인 행동 또는 요구사항으로, 마치 '체크리스트'의 각 항목과 같습니다. 표준은 각 활동별로 '제조사는 ~을(를) 문서화해야 한다(shall document)'와 같은 구체적인 태스크를 의무 조항(shall)으로 명시하며, 이는 개발 과정에서 반드시 준수해야 할 법적 요구사항이 됩니다.

예를 들어, 5.2 소프트웨어 요구사항 분석 활동에는 다음과 같은 태스크들이 포함될 수 있습니다.

• 소프트웨어의 기능 및 성능 요구사항을 명세화한다.
• 위험 통제 조치로부터 도출된 요구사항을 포함한다.
• 요구사항이 검증 가능한 방식으로 작성되었는지 확인한다.
• 사용자 인터페이스(UI) 및 시스템 인터페이스 요구사항을 정의한다.

소프트웨어 안전 등급(Software Safety Classification)의 역할

IEC 62304의 핵심 특징은 소프트웨어 안전 등급(Class A, B, C)에 따라 요구되는 태스크의 범위와 문서화의 깊이가 달라진다는 점입니다.

• Class A (상해 가능성 없음): 가장 낮은 등급으로, 최소한의 태스크 수행이 요구됩니다.
• Class B (심각하지 않은 상해 가능성): 중간 등급으로, Class A보다 더 많은 태스크와 문서화가 필요합니다.
• Class C (사망 또는 심각한 상해 가능성): 가장 높은 등급으로, 표준에 명시된 거의 모든 태스크를 수행하고 이를 상세히 문서화해야 합니다.

예를 들어, '소프트웨어 아키텍처 설계(5.3)' 활동에서 외부 소프트웨어(SOUP) 목록을 문서화하는 태스크는 Class B와 C에만 요구됩니다. 또한, '소프트웨어 상세 설계(5.4)' 활동 자체는 가장 위험도가 높은 Class C 소프트웨어에만 의무적으로 요구됩니다. 이처럼 위험 등급에 따라 활동 전체 또는 특정 태스크의 적용 여부가 결정됩니다.

이러한 체계적인 구조를 통해 제조사는 소프트웨어의 잠재적 위험 수준에 맞춰 합리적이고 효율적으로 개발 프로세스를 관리할 수 있습니다.

4. 결론

IEC 62304는 '프로세스-활동-태스크'라는 명확한 계층 구조와 위험 기반의 '소프트웨어 안전 등급'을 통해 의료기기 소프트웨어 개발의 복잡성을 관리합니다. 이 구조를 이해하고 적용하는 것은 불필요한 절차는 줄이면서도 환자 안전과 직결된 부분은 더욱 엄격하게 관리하여, 궁극적으로 안전하고 효과적인 의료기기를 시장에 출시하기 위한 필수적인 첫걸음입니다.