의료 기기 소프트웨어 개발은 소스 코드 그 이상을 생성합니다. 요구사항(Requirements), 아키텍처 파일(Architecture files), 리스크 관리(Risk controls), 테스트 증거(Test evidence), 릴리스 기록(Release records), 그리고 변경 승인(Change approvals)도 함께 생성됩니다.

만약 이러한 산출물(Artifacts)들이 Git, Jira, 공유 드라이브, 테스트 플랫폼 등에 흩어져 있다면, 팀은 어떤 버전이 검토되었고, 테스트되었으며, 릴리스되었는지를 증명하는 데 어려움을 겪을 수 있습니다.

바로 이 지점에서 의료 기기 문서 관리(Document control)가 엔지니어링 워크플로(Engineering workflow)의 일부가 됩니다.

Git만으로는 충분하지 않은 이유

Git은 강력한 버전 이력(Version history)을 제공하지만, 문서가 공식적으로 검토, 승인, 릴리스되었으며 효력이 발생했음을 자동으로 증명하지는 못합니다.

커밋(Commit)을 통해 무엇이 변경되었는지는 보여줄 수 있지만, 규제 대상 팀(Regulated teams)은 다음과 같은 사항도 보여줘야 할 수 있습니다:

• 누가 변경을 승인했는가
• 왜 변경이 필요했는가
• 어떤 리스크(Risks)가 영향을 받았는가
• 어떤 테스트를 재실행했는가
• 어떤 소프트웨어 릴리스(Software release)에 포함되었는가
• 이전 버전이 폐기되었는가

Git은 문서 관리를 지원해야 하는 것이지, 대체해서는 안 됩니다.

어떤 개발 산출물(Artifacts)에 관리가 필요한가?

의료 기기 및 SaMD(Software as a Medical Device) 프로젝트의 경우, 관리 대상인 기술 산출물에는 주로 다음이 포함됩니다:

• 소프트웨어 요구사항 (Software requirements)
• 아키텍처 문서 (Architecture documents)
• API 사양 (API specifications)
• 리스크 관리 매핑 (Risk control mappings)
• 검증 프로토콜 (Verification protocols)
• 테스트 보고서 (Test reports)
• 사이버 보안 기록 (Cybersecurity records)
• 릴리스 노트 (Release notes)
• 알려진 이상 현상 목록 (Known anomaly lists)
• 배포 지침 (Deployment instructions)
• 빌드 및 구성 기록 (Build and configuration records)

각 산출물은 소유자(Owner), 버전(Version), 승인 상태(Approval status), 그리고 명확한 기록 시스템(System of record)을 가져야 합니다.

요구사항, 리스크, 코드, 그리고 테스트의 연결

규정을 준수하는 개발 워크플로(Development workflow)는 최초의 사용자 니즈(User need)부터 최종 릴리스(Final release)까지의 추적성(Traceability)을 제공해야 합니다.

예를 들어:

사용자 니즈 (User Need)
↓
시스템 요구사항 (System Requirement)
↓
소프트웨어 요구사항 (Software Requirement)
↓
리스크 관리 (Risk Control)
↓
코드 변경 (Code Change)
↓
검증 테스트 (Verification Test)
↓
릴리스 버전 (Release Version)

요구사항이 변경되면, 팀은 영향을 받는 코드, 리스크, 테스트 및 문서를 즉시 식별할 수 있어야 합니다.

이는 영향 평가 (Impact Assessment) 누락을 줄이고 불완전한 릴리스 (Release)를 방지합니다.

CI/CD를 증거로 활용하기

CI/CD 파이프라인 (Pipelines)은 다음과 같은 가치 있는 통제된 증거 (Controlled Evidence)를 생성할 수 있습니다:

• 빌드 로그 (Build logs)
• 단위 테스트 결과 (Unit test results)
• 코드 커버리지 (Code coverage)
• 정적 분석 보고서 (Static analysis reports)
• 의존성 스캔 (Dependency scans)
• SBOM 파일 (SBOM files)
• 릴리스 매니페스트 (Release manifests)

각 출력물은 특정 커밋 (Commit), 빌드 번호 (Build number), 그리고 소프트웨어 버전 (Software version)과 연결되어야 합니다.

릴리스 패키지 (Release package)는 다음과 같은 형태일 수 있습니다:

release-v2.4.0/
├── build-manifest.json
├── sbom.json
├── verification-summary.pdf
├── risk-traceability-report.pdf
├── known-anomalies.csv
└── approval-record.pdf

이는 감사 (Audit), 유지보수 (Maintenance), 그리고 향후 업데이트를 위한 재현 가능한 베이스라인 (Baseline)을 생성합니다.

풀 리퀘스트 (Pull Requests)에 변경 제어 (Change Control) 추가하기

풀 리퀘스트 (Pull requests)가 코드 리뷰 (Code review) 이상의 정보를 담는다면 규제 준수 워크플로우 (Regulated workflows)를 지원할 수 있습니다.

의료 기기 소프트웨어의 풀 리퀘스트 (Pull request)에는 이상적으로 다음 항목들이 포함되어야 합니다:

• 변경 사유 (Reason for the change)
• 연결된 요구사항 (Linked requirement)
• 연결된 리스크 제어 (Linked risk control)
• 수행된 테스트 (Testing performed)
• 사이버 보안 영향 (Cybersecurity impact)
• 문서화 영향 (Documentation impact)
• 릴리스 대상 (Release target)
• 리뷰어 승인 (Reviewer approval)

이는 개발 팀이 일상적인 엔지니어링 작업에 컴플라이언스 (Compliance)를 통합하는 데 도움을 줍니다.

통제된 문서화 (Controlled documentation), 버전 관리 (Versioning), 승인 (Approvals), 그리고 감사 준비성 (Audit readiness)에 대한 더 광범위한 분석은 의료 기기 문서 관리 (Medical device document control) 가이드를 참조하십시오. [https://citrusbits.com/medical-device-document-control/]

마치며

의료 기기 문서 관리 (Medical device document control)는 개발 프로세스 외부에 존재해서는 안 됩니다.

Git, 요구사항 (Requirements), 테스트 (Testing), 리스크 관리 (Risk management), CI/CD, 그리고 릴리스 승인 (Release approval)을 하나의 추적 가능한 워크플로우 (Traceable workflow)로 연결해야 합니다.

문서 관리가 소프트웨어 생명주기 (Software lifecycle) 내에 구축되면, 팀은 더 빠르게 움직이고, 재작업 (Rework)을 줄이며, 규제 검토 (Regulatory review)를 위한 더 강력한 증거를 생성할 수 있습니다.

CitrusBits에서 의료 기기 소프트웨어 및 헬스케어 제품 개발에 대한 더 많은 인사이트를 확인해 보세요: [https://citrusbits.com/]