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