개념
모듈 25에서 여기까지 온 길
모듈 25 레슨 4는 IEC 62304를 지도 로 봤다. 피해의 크기로 A·B·C를 나누고, 등급이 올라가면 요구 활동이 늘고, SOUP에도 책임을 지고, 검증·확인과 추적성이 규제 요건이 된다는 구조였다. 이 레슨은 그 지도를 들고 실제 프로젝트에 들어간다. 질문은 하나다. 이 등급의 이 프로젝트에서 QA는 무엇을 만들어야 심사를 통과하는가.
그 전에 전제 하나. IEC 62304는 무엇을 해야 하는지 (활동과 산출물)를 말하지, 어떻게 해야 하는지 (도구·양식·방법론)를 말하지 않는다. 애자일로 개발해도, 문서를 위키로 관리해도 된다. 심사에서 보는 것은 요구된 활동이 수행됐다는 증거 다. 그래서 QA의 일은 증거가 빠짐없이, 추적 가능하게 남는 체계를 만드는 것이다.
표준의 뼈대 — 다섯 개의 프로세스
| 장 | 프로세스 | QA가 주로 만드는 것 |
|---|---|---|
| 5 | 소프트웨어 개발 (5.1 계획 ~ 5.8 출시) | 시험 계획, 단위·통합·시스템 시험 절차와 기록, 추적표 |
| 6 | 소프트웨어 유지보수 | 변경 영향 분석에 따른 회귀 시험 범위와 기록 |
| 7 | 소프트웨어 위험관리 | 위험 통제 조치의 검증 기록 (레슨 2) |
| 8 | 소프트웨어 형상관리 | 시험 대상 버전·시험 환경 구성 식별 |
| 9 | 소프트웨어 문제 해결 | 결함 기록·조사·추세 분석 |
62304는 품질경영시스템(ISO 13485)과 위험관리(ISO 14971)가 이미 있다고 전제 한다. 품질경영시스템 없이 62304만 따로 적용할 수는 없다.
등급 판정 — 가장 자주 틀리는 세 곳
2015년 개정(Amendment 1)을 반영한 등급 기준은 이렇다.
| 등급 | 소프트웨어 고장이 기여할 수 있는 위해 상황 |
|---|---|
| A | 부상이나 건강 피해가 발생할 수 없음 |
| B | 심각하지 않은 부상 가능 |
| C | 사망 또는 심각한 부상 가능 |
틀리는 지점은 대개 셋이다.
1. 고장 확률을 낮게 잡는다. 소프트웨어 등급 판정에서는 소프트웨어가 고장 난다고 가정 한다(확률을 1로 본다). "이 코드는 잘 짜서 고장 날 일이 거의 없으니 B"는 통하지 않는다. 소프트웨어 결함의 발생 확률은 추정할 수 없기 때문이다.
2. 외부 위험 통제를 과대평가하거나 무시한다. 2015년 개정은 소프트웨어 밖의 위험 통제 조치(하드웨어 인터록, 독립적 경보 회로, 의료진의 확인 절차)를 고려해 등급을 낮출 수 있게 했다. 두 방향으로 틀린다. 외부 통제가 있는데 무시해 불필요하게 C로 가서 비용을 쓰거나, 외부 통제가 실제로 독립적이지 않은데 (같은 소프트웨어가 경보도 낸다) 그것을 근거로 등급을 낮춘다. 외부 통제를 근거로 등급을 낮췄다면 그 통제의 효과 검증 이 레슨 2의 필수 시험이 된다.
3. 시스템 전체에 한 등급만 매긴다. 소프트웨어 항목을 분리하고 분리가 효과적이라는 근거가 있으면 항목별로 다른 등급을 줄 수 있다. 예를 들어 인슐린 투여량 계산 모듈은 C, 사용 기록 내보내기 모듈은 A. 분리의 근거(메모리 보호, 프로세스 분리, 인터페이스 제한)가 없는데 등급을 나누면 심사에서 지적된다. 등급을 나눴다면 분리가 실제로 유지되는지 도 시험 대상이다.
등급이 켜고 끄는 조항 — QA 관점 요약
표준 부속서에는 조항별 적용 등급 표가 있다. 개발 프로세스 중 시험과 직결되는 부분만 요약하면 다음과 같다. 조항 세부는 반드시 표준 원문의 표로 확인한다.
| 조항 | 활동 | A | B | C |
|---|---|---|---|---|
| 5.1 | 개발 계획 (시험 계획·통합 계획·검증 계획 포함) | ✓ (일부 항목) | ✓ | ✓ |
| 5.2 | 소프트웨어 요구사항 분석 | ✓ | ✓ | ✓ |
| 5.3 | 아키텍처 설계 (SOUP 요구사항 포함) | — | ✓ | ✓ |
| 5.4 | 상세 설계 | — | ✓ (항목 수준) | ✓ (단위 수준까지) |
| 5.5.1 | 단위 구현 | ✓ | ✓ | ✓ |
| 5.5.2~5.5.3·5.5.5 | 단위 검증 절차·수용 기준·검증 수행 | — | ✓ | ✓ |
| 5.5.4 | 추가 단위 수용 기준 | — | — | ✓ |
| 5.6 | 통합과 통합 시험 | — | ✓ | ✓ |
| 5.7 | 소프트웨어 시스템 시험 | ✓ (2015 개정부터) | ✓ | ✓ |
| 5.8 | 출시 (잔존 이상 평가 등) | ✓ | ✓ | ✓ |
두 가지를 기억하자. 첫째, 2015년 개정부터 A등급도 시스템 시험이 필수 다. 개정 전 판본으로 준비한 프로젝트에서 A등급 시스템 시험 기록이 비어 있는 경우가 있다. 둘째, C등급에만 추가 단위 수용 기준 이 걸린다. 표준은 C등급 단위에 대해 이벤트 순서, 데이터·제어 흐름, 계획된 자원 할당, 오류 처리, 초기화, 자가 진단, 메모리 관리, 경계 조건 같은 관점의 수용 기준을 요구한다. 모듈 35 레슨 2에서 본 ISO 26262-6의 단위 검증 방법 조합과 발상이 같다.
단위 검증 — "테스트가 있다"가 아니라 "수용 기준이 있다"
B·C등급 단위 검증에서 심사가 보는 것은 단위 테스트 코드의 존재가 아니라 단위마다 수용 기준이 정의되고, 그 기준에 대해 검증했다 는 증거다. 검증 방법은 단위 테스트뿐 아니라 코드 리뷰·정적 분석도 인정된다.
[단위 검증 기록 — C등급 단위 dose_calculator]
단위: dose_calculator v3.4.1 (커밋 9f2e1a0)
수용 기준: UAC-DC-01 입력 체중 범위 0.5~250kg 밖이면 계산 거부, 오류 코드 반환
UAC-DC-02 계산 결과가 최대 투여량 초과 시 상한 적용 + 경고 플래그
UAC-DC-03 정수 오버플로 없음 (정적 분석 규칙 + 경계 입력 시험)
UAC-DC-04 초기화 전 호출 시 안전한 기본 동작 (거부)
UAC-DC-05 메모리 동적 할당 없음 (정적 분석)
검증 방법: 단위 시험 42건 / 정적 분석(규칙 세트 v2) / 코드 리뷰 1회
결과: 단위 시험 42/42 통과, 정적 분석 위반 0, 리뷰 지적 2건 조치 완료(PR #812)
추적: SRS-114, SRS-115 → UAC-DC-01~05 → 시험 ID UT-DC-001~042수용 기준 ID(UAC-)가 요구사항과 시험 사이에 있다는 점을 보자. 모듈 38 레슨 1~2에서 검증 기준에 ID를 붙여 테스트 이름에 넣었던 방식이 의료기기에서는
규제 증거의 뼈대 가 된다. 기준 ID가 없으면 "이 테스트가 무엇을 검증하는가"를 사람이 매번 해석해야 한다.
통합·시스템 시험과 시험 기록
통합 시험(B·C)은 통합 계획대로 항목을 합쳤을 때 인터페이스와 상호작용 이 설계대로 동작하는지 본다. 시스템 시험(A·B·C)은 소프트웨어 요구사항 전체 를 시험으로 확인한다. 시스템 시험에서 요구사항 하나에 시험이 하나도 연결되지 않으면 곧바로 지적 사항이다.
62304가 시험 기록에 요구하는 내용은 모듈 31의 시험성적서 원칙과 거의 같다. 기록이 갖춰야 할 것은 대략 이렇다.
| 항목 | 이유 |
|---|---|
| 시험 결과 (합격·불합격과 발견된 이상 목록) | 무엇이 확인되고 무엇이 안 됐는가 |
| 시험을 반복할 수 있을 만큼 의 기록 — 시험 대상 버전, 시험 환경 구성, 사용한 도구와 버전, 입력 데이터 | 재현성 (모듈 31 레슨 2) |
| 시험 수행자 식별 | 책임 |
| 시험 날짜 | 형상과의 대응 |
"반복할 수 있을 만큼"이 가장 자주 부족하다. "시스템 시험 전체 통과, 2026-08-30"만 있고 어느 빌드를 어느 장치·OS·시뮬레이터 구성으로 돌렸는지 없으면, 심사관은 그 기록이 출시 버전에 해당하는지 판단할 수 없다. 모듈 38 레슨 4의 판정 레코드(커밋·환경·기준 버전)가 이 요구를 자동으로 채운다.
회귀 시험 도 요구된다. 변경 후 시험을 다시 할 때 전체를 반복하지 않는다면, 왜 이 범위로 충분한지 변경 영향 분석으로 근거를 남긴다(6장 유지보수와 연결).
SOUP — 남이 만든 코드를 시험 대상으로
SOUP(Software Of Unknown Provenance)는 62304 준수를 전제로 개발되지 않은 기성 소프트웨어다. 오픈소스 라이브러리, 운영체제, 데이터베이스, 상용 SDK가 모두 해당한다. B·C등급에서는 아키텍처 설계 단계에서 SOUP마다 다음을 정한다.
| 요구 | QA가 만드는 증거 |
|---|---|
| SOUP 식별 (이름·제조사·버전) | SBOM과 일치하는 SOUP 목록 (레슨 5 사이버보안과 공유) |
| SOUP에 요구하는 기능·성능 요구사항 | "이 라이브러리가 우리 시스템에서 해야 하는 일" 명세 |
| SOUP가 올바르게 동작하는 데 필요한 시스템 하드웨어·소프트웨어 | 지원 OS·메모리 등 전제 조건 |
| 공개된 알려진 이상(known anomalies) 평가 | 해당 버전의 이슈 목록 중 우리 사용 방식에 영향 있는 것 검토 기록 |
"SOUP 기능·성능 요구사항"이 시험으로 이어진다. 예를 들어 날짜·시간 라이브러리를 쓴다면 "투약 일정 계산에서 서머타임 전환일을 올바르게 처리"가 SOUP 요구사항이 되고, 그것을 우리 시스템 수준에서 시험 한다. 라이브러리 자체의 테스트 스위트를 믿는 것이 아니라, 우리 용도에서 요구한 동작을 확인한다.
SOUP 버전을 올리면 알려진 이상 평가와 관련 시험을 다시 해야 한다. 의존성 자동 업데이트 도구가 병합한 라이브러리 버전 변경이 SOUP 목록·이상 평가·회귀 시험 없이 출시 빌드에 들어가는 것이 전형적인 지적 사항이다.
출시 — 잔존 이상을 평가하고 남긴다
출시(5.8) 단계에서 QA가 가장 무겁게 다루는 산출물은 잔존 이상 목록 이다. 해결하지 않고 출시하는 모든 알려진 결함에 대해 평가 기록을 남긴다.
[잔존 이상 평가 — 출시 v3.4.1]
이상 ID 요약 위해 기여 평가 결정
PR-2211 내보내기 CSV 의 날짜 형식이 로캘 무시 위해 상황 기여 없음 (진료 판단에 쓰지 않음) 출시 허용, v3.5 수정
PR-2230 경고 팝업이 화면 회전 시 1초 지연 위험 통제 조치 RC-07 의 효과에 영향 검토 → 출시 허용,
지연 1초가 사용자 대응 시간 기준 내 사용적합성 기록 참조모듈 4 레슨 5의 "미해결 결함은 왜 안 고쳤는지까지"가 규제 요건으로 바뀐 형태다. 두 번째 줄처럼 결함이 위험 통제 조치 에 닿으면 레슨 2의 위험관리 파일과 연결해 판단해야 한다.
문제 해결 프로세스 — 결함 관리가 규제 대상이 된다
9장 문제 해결은 모듈 6의 결함 관리와 거의 같지만 몇 가지가 필수가 된다.
- 문제 보고마다 조사 하고 원인을 기록한다
- 안전 관련성을 평가하고, 필요하면 위험관리 프로세스로 넘긴다
- 변경 후 문제가 해결됐는지 검증 한다
- 문제 보고의 추세를 분석 한다
마지막 항목이 모듈 38 레슨 6의 결함 흐름 지표와 이어진다. 같은 유형의 문제가 반복되면 프로세스 개선의 근거가 된다.
개정 2판의 방향
IEC 62304는 오랫동안 개정 작업 중이다. 공개된 초안 정보에 따르면 A·B·C 세 등급을 두 단계의 프로세스 엄격성 수준(I·II) 으로 바꾸는 방향이고(대체로 I은 기존 A, II는 기존 B·C), 의료기기뿐 아니라 건강 소프트웨어 전반 으로 범위를 넓히며, AI·머신러닝 수명주기와 사이버보안 요구를 더 명시하는 방향이다. 기존 B등급 소프트웨어의 영향이 가장 크다는 분석이 많다.
발행 시점은 출처마다 예측이 엇갈린다. 2026년 중 최종안 단계에 들어갔다는 보도도, 의견 반영으로 2028년 이후로 늦어진다는 보도도 있다. 발행 후에도 규제 당국이 요구하기까지 전환 기간이 있을 것으로 예상된다. 실무 판단은 IEC 웹스토어의 현재 단계와 인허가 대상 국가의 인정 판본으로 하고, 프로젝트 문서에 적용 판본을 명시한다.
실무에서 왜 필요한가
의료기기 소프트웨어 인허가에서 가장 흔한 보완 요구는 기능이 아니라 문서와 추적성의 빈칸 이다. 요구사항에 시험이 연결되지 않았다, 시험 기록이 출시 버전과 대응되지 않는다, SOUP 버전이 목록과 다르다, 잔존 이상에 위해 평가가 없다. 모두 개발이 끝난 뒤 채우려면 몇 주가 걸리고, 처음부터 체계를 갖추면 거의 비용이 들지 않는다.
QA 경력자가 의료기기 QA로 옮길 때 이 레슨의 산출물 목록은 이미 해 본 일의 이름을 바꾼 것 인 경우가 많다. 수용 기준·재현 가능한 시험 기록·결함 잔존 판단· 의존성 관리. 차이는 이것들이 선택이 아니라 필수이고, 빈칸 하나가 인허가 일정을 몇 달 미룬다는 점이다.