개념
QA 가 설계 관리를 알아야 하는 이유
레슨 1~6 은 소프트웨어 쪽 규격 을 따라갔다. IEC 62304 의 안전 등급과 산출물, ISO 14971 의 위험관리, IEC 62366-1 의 사용적합성, 밸리데이션, 사이버보안, 인허가.
그런데 이 모든 활동이 어디에 담기는가 를 정하는 것은 품질경영시스템이다. ISO 13485 의 설계 관리가 그 틀이고, 시험 활동은 그 틀 안의 한 칸으로 들어간다. QA 가 이 틀을 모르면 두 가지가 생긴다.
첫째, 시험 결과가 어디에도 연결되지 않는다. 열심히 시험하고 보고서를 썼는데 설계 출력과 입력 중 무엇을 확인한 것인지 추적이 안 된다. 감사에서 "이 시험이 어느 설계 입력을 검증한 것입니까" 라는 질문에 답할 수 없다.
둘째, 검증과 밸리데이션을 섞는다. 두 단어가 둘 다 "확인" 으로 번역되기도 해서 현장에서 자주 섞인다. 섞이면 한쪽이 비어 있는 채로 출시 된다.
그래서 이 레슨은 규격 조문을 외우는 레슨이 아니다. 설계 입력 하나가 어떻게 시험 케이스가 되고 기록이 되고 감사 증거가 되는지, 한 제품으로 끝까지 따라가는 레슨이다.
조항 번호는 본문에서 쓰지 않는다. 설계 관리의 하위 조항 번호는 자료마다 다르게 인용되는 경우가 있어, 여기서는 활동 이름 으로 쓰고 번호는 규격 원문에서 확인하게 한다(조항 번호 — 원문 확인). 2016년판에서 설계·개발 파일 에 관한 요구가 새로 들어왔다는 점은 여러 자료가 공통으로 전한다.
설계 관리의 활동 — 이름으로 외운다
설계 관리를 활동 순서로 늘어놓으면 이렇다. 번호가 아니라 무엇을 하는 활동인가 로 기억하는 것이 실무에 쓰인다.
[계획] ──→ [입력] ──→ [출력] ──→ [검증] ──┐
│ ↑ │ │
│ └──추적성───┘ ├──→ [이관] ──→ 생산·출시
│ │
└──→ [검토] (각 단계마다) ───────────────┘
[밸리데이션]
[변경 관리] ── 전 구간에 걸쳐 작동
[설계·개발 파일] ── 위 전부를 담는 그릇| 활동 | 묻는 질문 | QA 의 자리 |
|---|---|---|
| 계획 | 어느 단계에서 무엇을 하고 누가 책임지는가 | 시험 활동의 시점과 자원을 여기서 확보 |
| 입력 | 이 제품은 무엇을 해야 하는가 | 검증 가능한 문장인지 검토 |
| 출력 | 무엇을 만들었는가 | 출력이 입력과 대응되는지 확인 |
| 검토 | 지금까지가 적절한가 | 참석하고 지적을 기록으로 남긴다 |
| 검증 | 출력이 입력을 충족하는가 | 주된 작업 영역 |
| 밸리데이션 | 의도한 사용에서 사용자 요구를 충족하는가 | 설계와 수행 |
| 이관 | 생산·배포에 넘길 준비가 되었는가 | 이관 전 확인 항목 |
| 변경 관리 | 이 변경이 무엇에 영향을 주는가 | 영향 분석과 재시험 범위 산정 |
| 설계·개발 파일 | 위 전부가 어디에 있는가 | 꺼낼 수 있는 상태로 유지 |
설계 입력 — 검증 가능하지 않으면 입력이 아니다
이 레슨에서 QA 가 가장 큰 가치를 더하는 지점이다.
설계 입력에는 의도한 사용에 따른 기능·성능·사용적합성·안전 요구, 적용되는 규제 요구와 규격, 위험관리의 출력, 이전 유사 설계에서 얻은 정보, 그 밖에 설계에 필수적인 요구가 들어간다. 그리고 요구는 완전하고 모호하지 않으며 검증 또는 밸리데이션이 가능하고 서로 충돌하지 않아야 한다. 정확한 요구 문장과 항목 구성은 규격 원문에서 확인한다(원문 확인).
여기서 "검증 또는 밸리데이션이 가능해야 한다" 가 QA 의 권한 근거다. 모호한 입력을 지적하는 것이 선의의 참견이 아니라 규격이 요구하는 검토 라는 뜻이다.
실무에서 지적해야 하는 문장의 전형은 이렇다.
| 나쁜 입력 | 왜 나쁜가 | 고친 방향 |
|---|---|---|
| "측정 결과를 신속히 표시한다" | '신속' 이 판정 불가 | 시간 상한을 수치로 — 값은 임상·사용 요구에서 가져온다 |
| "사용하기 쉬워야 한다" | 판정 주체·방법이 없다 | 사용적합성 평가의 과업·판정 기준으로(레슨 3) |
| "오류를 적절히 처리한다" | '적절' 이 판정 불가 | 오류 유형별 기대 동작을 열거 |
| "안전해야 한다" | 무엇에 대해 안전한가 | 위험관리 출력의 특정 위험 통제로 연결(레슨 2) |
| "최신 브라우저를 지원한다" | 대상이 시간에 따라 변한다 | 지원 목록을 판본으로 고정 |
수치가 필요한 자리에 QA 가 숫자를 넣지 않는다. 숫자는 의도한 사용과 임상 요구에서 와야 하고, QA 는 "이 자리에 숫자가 필요하다" 를 지적하고 누가 정할지를 묻는다. 이것이 모듈 31 레슨 3 의 판정 기준 선언 원칙과 같다.
그리고 위험관리 출력이 설계 입력으로 들어온다 는 점이 중요하다. 레슨 2 에서 위험 통제를 시험으로 잇는 작업을 다뤘는데, 그 통제가 입력에 들어와 있지 않으면 출력·검증으로 이어지지 않는다. QA 가 입력 검토에서 "위험관리 파일의 통제가 모두 입력에 반영되었는가" 를 대조하는 것이 가장 실질적인 점검이다.
검증과 밸리데이션 — 다른 질문이다
가장 자주 섞이는 둘이다. 질문으로 가르면 섞이지 않는다.
검증 — "만든 것이 명세한 대로인가" 설계 출력이 설계 입력 요구를 충족하는지 확인한다. 기준은 우리가 쓴 입력 문서 다. 단위 시험, 통합 시험, 요구 기반 시험, 코드 검토, 정적 분석이 여기 들어간다. 검증 계획에는 방법과 수용 기준이 들어가고, 필요하면 표본 크기의 근거를 함께 문서화한다.
밸리데이션 — "그것이 실제 사용에서 쓸 만한가" 의도한 사용 조건에서 사용자 요구를 충족하는지 확인한다. 기준은 의도한 사용 이다. 대표 제품으로 수행하고, 사용자에게 제공하기 전에 완료한다.
차이를 예로 보면 분명하다. 설계 입력에 "경고음은 70 dB 이상" 이 있다고 하자.
- 검증 — 측정했더니 72 dB 다. 입력 충족. 통과
- 밸리데이션 — 실제 사용 환경(기계 소음이 있는 병동) 에서 간호사가 그 경고음을 듣지 못한다. 사용자 요구 미충족. 입력 자체가 틀렸다
검증만 하고 밸리데이션을 빠뜨리면 "명세대로 만들었는데 쓸 수 없는 제품" 이 출시된다. 반대로 밸리데이션만 하면 왜 되는지·안 되는지를 설명할 수 없다.
소프트웨어 의료기기에서 혼동이 하나 더 있다. IEC 62304 의 소프트웨어 검증 과 ISO 13485 의 설계 검증 은 범위가 다르다. 전자는 소프트웨어 개발 생애주기 안의 활동이고, 후자는 기기 전체의 설계 출력이 설계 입력을 충족하는지 를 본다. 소프트웨어만 검증하고 기기 수준 검증을 빠뜨리는 경우가 실제로 있다. 두 규격의 관계는 레슨 1 에서 다룬 범위다.
검토 — 기록이 없으면 하지 않은 것이다
설계 검토는 각 단계에서 수행하고 기록으로 남는다. 그리고 검토에는 설계 작업에 직접 참여하지 않은 사람 이 포함되어야 한다는 요구가 있다. 정확한 요구 문장은 원문에서 확인한다(원문 확인).
QA 실무로 옮기면 세 가지다.
- 참석자 명단에 독립적 관점이 보여야 한다. 설계자들만 모인 검토는 요구를 충족하지 못할 수 있다
- 지적과 조치가 추적되어야 한다. "검토했고 승인함" 한 줄짜리 기록은 감사에서 약하다. 무엇을 지적했고 어떻게 처리했는지가 남아야 한다
- QA 의 미결 항목이 기록에 들어가야 한다. 구두로 우려를 말하고 기록에 없으면, 나중에 그 문제가 터졌을 때 QA 가 지적했다는 사실이 사라진다
세 번째는 조직 정치의 문제가 아니라 체계의 문제 다. 미결 항목이 기록되지 않으면 다음 단계로 넘어갈 때 아무도 그것을 다시 보지 않는다.
이관 — 넘기기 전에 확인할 것
설계 이관은 설계 출력을 생산(소프트웨어라면 빌드·배포·배포 채널) 에 넘기는 활동이고, 절차가 문서화되어 있어야 하며 결과와 결론이 기록된다.
소프트웨어 의료기기에서 이관 전 확인할 항목은 이렇다.
- 출시 대상 형상이 검증·밸리데이션을 받은 형상과 같은가 — 가장 자주 틀어진다
- 빌드가 재현 가능한가(같은 소스에서 같은 산출물이 나오는가)
- 배포 절차가 문서화되어 있고, 배포 후 확인 방법이 있는가
- 설치·설정 지침이 실제 절차와 일치하는가
- 사용자 문서(사용설명서·경고) 가 최종 동작과 일치하는가
- 알려진 이상(known anomalies) 이 목록화되고 각각 평가되었는가
- 되돌리기 경로가 있는가
첫 번째 항목 이 핵심이다. 검증은 v1.4.2 로 했는데 출시가 v1.4.3 이면
그 검증 결과는 출시 제품에 대한 증거가 아니다. 모듈 33 레슨 7 의 인증 버전 대장,
모듈 35 레슨 8 의 식별 연결과 같은 문제다.
알려진 이상 항목도 소프트웨어 특유의 것이다. 고치지 않고 출시하는 결함이 있을 수 있고, 그때 요구되는 것은 "없다" 가 아니라 목록과 각각의 위험 평가 다. 평가되지 않은 미결 결함을 안고 출시하는 것이 문제다.
변경 관리 — 설계가 끝난 뒤에도 돈다
출시 후에도 소프트웨어는 바뀐다. 설계 변경은 절차로 통제 되고, 변경의 중요도(기능·성능·사용적합성·안전·규제 요구와 의도한 사용에 미치는 영향) 를 판정한다. 정확한 요구는 원문 확인.
QA 가 만들 것은 변경 영향 판정 양식 이고, 축은 이렇다.
| 축 | 질문 |
|---|---|
| 기능·성능 | 설계 입력의 어느 요구에 영향을 주는가 |
| 사용적합성 | 사용자 인터페이스·절차가 바뀌는가(레슨 3) |
| 안전·위험 | 위험관리 파일의 어느 통제를 건드리는가(레슨 2) |
| 규제 | 인허가 범위를 벗어나는가(레슨 6) |
| 사이버보안 | 공격면이나 보안 통제가 바뀌는가(레슨 5) |
판정 결과가 재시험 범위를 정한다. 그리고 "작은 수정이니 영향 분석 생략" 이 없다 는 점이 이 영역의 성격이다. 같은 구조를 모듈 35 레슨 8(R155·R156), 모듈 63 레슨 6(CC) 에서 다뤘다 — 규제 환경의 변경 관리는 전부 같은 모양이다.
설계·개발 파일 — 꺼낼 수 있어야 파일이다
설계 관리의 모든 산출물은 하나의 파일(묶음) 로 모인다. 감사·심사에서 열리는 것이 이 파일이고, 그때 평가되는 것은 내용만이 아니라 꺼내 오는 속도 다. 모듈 32 레슨 8 에서 기록 인출 시간을 재 본 이유와 같다.
파일이 갖춰야 할 상태는 넷이다.
- 목록이 있다. 무엇이 어디에 있는지 적힌 색인
- 판본이 명확하다. 각 문서의 판본과 승인 상태
- 추적이 걸려 있다. 입력 ↔ 출력 ↔ 검증 ↔ 결과가 식별자로 연결
- 최신 상태다. 변경이 반영되어 있고, 과거 판본도 보존되어 있다
세 번째가 QA 의 기여가 집중되는 곳이다. 추적은 양방향 이어야 한다 — 모든 입력이 검증되었는지(위→아래), 모든 시험이 어느 입력에 근거하는지(아래→위). 어느 입력에도 근거하지 않는 시험은 범위 밖 작업이거나 입력 누락의 신호다. 모듈 63 레슨 2 에서 같은 논리를 다뤘다.
실무에서 왜 필요한가
의료기기 소프트웨어 조직에서 QA 가 겪는 전형적 좌절이 하나 있다. 시험은 충실히 했는데 감사에서 지적을 받는 것 이다. 지적 내용은 대개 셋 중 하나다.
"이 시험이 어느 요구를 검증한 것인지 불명확하다." 추적이 없다. "설계 입력에 검증 불가능한 요구가 있다." 입력 검토가 없었다. "밸리데이션 증거가 확인되지 않는다." 검증만 하고 밸리데이션을 빠뜨렸다.
세 지적 모두 시험을 더 많이 해서 해결되지 않는다. 설계 관리의 자리를 알고, 입력 단계에 들어가고, 추적 식별자를 처음부터 붙이면 해결된다. 그리고 이 셋은 사업 후반에 고치기가 매우 어렵다 — 추적을 나중에 복원하려면 기억에 의존하게 되고, 밸리데이션을 뒤늦게 하려면 대표 제품과 사용자 참여를 다시 조직해야 한다.
반대로 이 틀을 아는 QA 는 설계 초기에 발언할 근거 를 갖는다. "이 입력은 검증 가능하지 않습니다" 는 개인 의견이 아니라 규격이 요구하는 검토이고, "위험관리 파일의 통제 세 개가 입력에 반영되지 않았습니다" 는 추적 대조의 결과다. 이 두 발언은 설계 단계에서 나와야 효과가 있고, 그래서 QA 가 설계 회의에 들어가야 하는 이유 가 된다.
채용시장에서의 위치
이 레슨이 겨냥하는 자리는 의료기기 제조사·소프트웨어 의료기기 기업의 품질보증(QA)·규제 업무(RA) 담당 이다. 공고에는 "ISO 13485", "설계 관리", "DHF", "V&V", "인허가 대응", "QMS 운영" 같은 말이 적힌다.
이 시장의 특징은 QA 와 RA 의 경계가 흐리다 는 점이다. 작은 조직에서는 한 사람이 둘을 겸하고, 큰 조직에서도 둘이 같은 문서를 본다. 그래서 시험만 할 수 있는 사람보다 문서 흐름을 아는 사람 의 폭이 넓다. 반대로 진입 장벽은 규격 체계에 익숙해지는 데 걸리는 시간이다.
경쟁력이 되는 것은 셋이다. 첫째, 검증과 밸리데이션을 정확히 가르는 능력 이다. 면접에서 가장 자주 나오는 질문이고, 섞어 답하는 지원자가 의외로 많다. 둘째, 설계 입력을 검토할 수 있는 능력 이다. 모호한 요구를 찾아내 고칠 방향까지 제시하는 사람은 설계 단계부터 불려 간다. 셋째, 추적성을 운영할 수 있는 능력 이다. 추적표를 만들어 본 사람과 "있다고 들었다" 는 사람의 차이가 실무에서 바로 드러난다.
자격·이력 축에서는 ISO 13485 내부심사원 교육, ISTQB CTFL·CTAL-TA 가 공통 언어로 쓰이고, 인허가 실무 경험 자체가 가장 강한 이력이 된다. 다만 최종적으로 평가되는 것은 "심사를 받아 봤는가" 다. 이 모듈의 실습 과제는 그 경험 없이 해당 산출물을 미리 만들어 두는 방향으로 설계했다.