현대 DevOps 파이프라인에서 IEC 62304 구현 방법 (추적성, SOUP, 위험 제어, CI/CD 증거)

Source: Dev.to

If you’re building SaMD or software inside a medical device, you’ve probably searched:

“How do I implement IEC 62304 in an Agile/DevOps workflow?”

The real challenge isn’t learning the standard—it’s operationalizing it while still feeling like modern engineering: PRs, CI/CD, IaC, containers, SBOMs, automated tests, and rapid releases.

IEC 62304 요약

• 목적: 의료기기 소프트웨어를 위한 소프트웨어 수명주기 프로세스를 정의합니다.
• 절대적인 요구사항: 소프트웨어 위험 제어가 구현·검증되고, 변경이 관리되고 있음을 끝‑끝으로 증명할 수 있어야 합니다.
• 증거 파이프라인 = 추적성 그래프.

안전 등급

등급에 따라 단위 검증 깊이, 독립성, 추적 깊이, 검토 엄격성, 이상 처리 등이 결정됩니다.

공학적 번역: 등급 및 기능 위험에 따라 변경되는 **“준수 프로파일”(문서 + CI 규칙)**을 정의합니다.

Source:

최소 실행 가능 추적성 그래프

Hazard (ISO 14971) → Risk control → Software requirement → Design element
      → Code change → Test case → Test result → Release

이것은 단순한 잡일이 아니라, 위험 통제가 효과적임을 입증하고 영웅적인 노력 없이도 감사에 통과할 수 있는 방법입니다. (IEC 62304와 ISO 14971은 바로 이 매핑을 위해 흔히 함께 구현됩니다.)

권장 레포지토리 레이아웃

/docs                # compliance docs, risk analyses, etc.
/src                 # source code
/.github   (or /ci)  # CI/CD pipelines, GitHub Actions, etc.

왜 이렇게 작동하는가

1. Lifecycle alignment – 계획 → 요구사항 → 설계 → 검증 → 릴리스.
2. CI enforces evidence – 나중에 수동으로 추적할 필요가 없음.
3. Tool‑agnostic – GitHub, GitLab, Bitbucket 등과 함께 사용할 수 있음.
4. No heavyweight tooling needed day 1 – 안정적인 식별자와 기계가 확인할 수 있는 링크만 있으면 됨.

Source: …

권장 패턴: Typed IDs + PR 게이팅

식별자 체계

강제 규칙 (CI / PR 템플릿을 통해)

• PR 설명에는 최소 하나의 SRS-###가 포함되어야 합니다.
• PR이 안전‑중요 모듈에 영향을 미치는 경우, 연결된 RC-###가 필요합니다.
• 테스트는 메타데이터나 docstring에 연관된 SRS-###를 참조해야 합니다.
• CI는 추적성 보고서를 생성하고, 필수 링크가 누락되면 실패합니다.

PR 템플릿 예시 스니펫

### Linked items
- **Requirements:** `SRS-041`, `SRS-044`
- **Risk controls:** `RC-012`
- **Tests:** `TST-201`, `TST-205`
- **Anomalies (if any):** `ANOM-033`

이제 “추적성”을 강제 가능한 계약으로 전환했습니다.

Source: …

위험 관리에서 엔지니어링 산출물로

일반적인 컴플라이언스 격차: 위험 관리가 PDF에만 존재하고 엔지니어링 워크플로에 포함되지 않음.

위험 관리를 다음과 같이 표현하기:

1. 요구사항 (수용 기준 포함)
2. 설계 제약 (아키텍처 결정)
3. 자동 검증 (테스트 + CI 증거)

예시: 알람‑타이밍 위험 관리

• 위험 관리 RC-012 – “알람은 2 초 이내에 트리거되어야 함.”
• 요구사항 SRS-041 – 타이밍 사양.
• 설계 SDS-010 – 이벤트 루프 + 우선순위 지정.
• 테스트 – TST-201 (통합), TST-202 (시스템).
• 릴리즈 증거 – CI 테스트 보고서 + 성능 로그를 아티팩트로 보관.

이렇게 하면 위험 → 검증의 명확한 체인이 구축됩니다.

SOUP 관리 (Software of Unknown Provenance)

IEC 62304는 SOUP(오픈‑소스 라이브러리, OS 구성 요소, 서드‑파티 SDK 등)를 안전성 영향의 일부로 취급합니다—출하하면 책임이 귀하에게 있습니다.

최소 SOUP 제어 전략

1. 종속성 인벤토리를 유지(SBOM이 이상적).
2. 버전을 고정하고 lockfile을 사용.
3. 업데이트 규칙 정의 – 일정에 따라, 검토 및 테스트.
4. 핵심 종속성에 대한 안전성 영향 검증.
5. 보완 제어 추가 – 샌드박싱, 타임아웃, 재시도, 워치독.

CI “SOUP 게이트”

새로운 종속성이 다음 없이 도입될 경우 빌드를 실패시킵니다:

• 기록된 목적
• 소유자
• 버전 고정
• 위험 메모(간단한 경우라도)

이는 “우리는 오픈 소스를 사용한다”와 “우리는 SOUP을 제어한다”를 구분합니다.

IEC 62304에서 요구하는 검증 증거

CI가 감사 친화적인 산출물을 생성하도록 만들기

CI 파이프라인에서:

• 테스트 요약 내보내기 (JUnit XML, HTML 보고서).
• 버전이 지정된 로그 보관 (성능, 커버리지, 정적 분석).
• 빌드 메타데이터 삽입 (커밋 해시, 환경, 도구 버전).

모든 빌드가 재현 가능한 “미니 릴리스 패키지”가 됩니다.

추가 읽을 거리

IEC 62304, 안전 등급 및 일반적인 산출물에 대한 심층적인 내용은 여기에서 확인할 수 있습니다:

IEC 62304란? – CitrusBits

Change Management & Release Documentation

IEC 62304는 통제된 변경 관리와 유지보수를 기대합니다.

Engineering Translation

당신의 Git workflow는 바로 변경‑제어 시스템입니다—올바르게 구조화한다면 말이죠.

Regulated PR Checklist (lightweight but powerful)

• 무엇이 바뀌었고 왜 바뀌었나요?
• 영향을 받은 요구사항 (SRS-###)?
• 영향을 받은 위험 통제 (RC-###)?
• 회귀 테스트 범위 (다시 실행할 테스트는?)
• 새로운 이상 현상?
• SOUP 변경 사항?

Automating the Boring Parts

• 수정된 모듈 → 필요한 테스트 스위트 매핑.
• 안전‑중요 영역에 대한 필수 리뷰어 강제.
• 추적 링크가 없으면 병합 차단.

CI‑Generated Release Bundle

문서를 수동으로 조립하는 대신 CI가 다음을 생성하도록 합니다:

• 추적 보고서 (요구사항 ↔ 테스트 ↔ 결과)
• SBOM / 의존성 인벤토리
• 테스트 요약 + 환경 메타데이터
• 알려진 이상 현상 목록 (위험‑평가 메모 포함)
• 버전 ID 및 아티팩트 해시

이들을 불변의 아티팩트 스토어에 저장합니다 (서명된 릴리스, 제어된 저장소).

이는 감사를 “스토리텔링”에서 “증거 번들 제공”으로 전환시켜, 가장 흔한 감사 실패 원인인 문서 누락·불일치를 없애줍니다.

컴플라이언스를 만족하는 코딩을 즐기세요!

결론

IEC 62304는 한 번만 수행하는 것이 아닙니다. 지속적으로 내재화하는 것입니다:

• 추적성은 PR + CI를 통해 강제됩니다
• 위험 통제는 요구사항 + 테스트로 구현됩니다
• SOUP은 의존성 엔지니어링의 일부로 관리됩니다
• 릴리스는 재현 가능한 증거와 함께 패키징됩니다

IEC 62304를 현대적인 소프트웨어 제공 방식(Agile, CI/CD, 클라우드)과 동일하게 구현하도록 도와줄 팀을 원한다면, 여기에서 CitrusBits를 확인해 보세요:

https://citrusbits.com/