의료기기 소프트웨어를 개발하다 보면 의외로 많은 기능이 외부에서 가져온 코드에 의존하고 있다는 사실을 발견하게 됩니다. 운영체제, 데이터베이스, 그래픽 라이브러리, 네트워크 모듈, 심지어 보안 라이브러리까지 대부분이 이미 존재하는 소프트웨어 위에서 동작합니다. 이러한 외부 소프트웨어를 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. 외부 소프트웨어라 하더라도 의료기기에 사용되는 순간 모든 책임은 제조사에게 있습니다.