소프트웨어 시험은 통과, 어떤 요구사항을 확인했나요?
요구사항 번호와 시험 번호가 연결되어 있어도 확인 범위는 비어 있을 수 있습니다.
센서 단절의 가상 사례로 기대 동작, 시험 조건, 실제 기록과 버전을 연결하는 방법을 살펴봅니다.
통과 표시 옆에서 시작하는 질문
시험 보고서에 통과 표시가 채워져 있습니다.
개발자는 정상적으로 작동한다고 설명하고, 검토자는 어떤 요구사항을 확인했는지 묻습니다.
시험 번호는 있지만 그 시험이 확인한 조건과 요구사항의 범위가 맞는지 보려면 여러 파일을 다시 열어야 합니다.
오늘의 질문은 시험을 몇 개 했느냐보다 기대했던 동작과 실제로 확인한 결과 사이를 따라갈 수 있느냐입니다.
연결표가 있다는 사실과 그 연결이 내용을 충분히 설명한다는 판단은 다릅니다.
요구사항 번호를 한 칸에 적어두었더라도 시험 내용이 일부 조건만 다룬다면 나머지 부분은 여전히 남습니다.
이 글은 의료기기 소프트웨어를 개발하거나 시험자료를 검토하는 담당자를 위한 실무 해설입니다.
미국 FDA의 소프트웨어 제출자료 가이던스를 참고하되, 아래 메모·점검 순서·사례는 MedQraft가 제안하는 자체 구성입니다.
특정 제품의 완성된 검증 계획이나 국내 법정 제출 양식은 아닙니다.
업무용 규제 지원 소프트웨어가 자동으로 의료기기에 해당한다는 뜻도 아닙니다.
공식 자료에서 확인한 연결의 의미
FDA의 2023년 가이던스는 VI.D에서 소프트웨어 요구사항과 관련 문서 사이의 추적성을 설명합니다.
VI.H에서는 시험의 기대 결과·관찰 결과·판정과 관련 보고서를, VI.I에서는 시험한 소프트웨어 버전 이력을 다룹니다.
검증에는 시험 외에도 검토와 분석 활동이 포함되므로, 시험 통과만으로 전체 소프트웨어 밸리데이션을 설명하지는 않습니다.
FDA 공식 원문
이 문서는 미국의 비구속적 권고입니다.
현재 제공되는 PDF 앞부분에는 2026년 2월 2일 발효된 QMSR을 함께 확인하라는 안내가 있으므로, 본문의 과거 QSR 조문 표현을 현행 의무로 그대로 옮기지 않습니다.
여기서는 제출자료 전체를 요약하기보다 실무자가 근거를 읽는 방식에 초점을 맞춥니다.
다음 회의에서는 연결표의 한 줄을 골라 실제 파일을 열어보세요.
요구사항의 현재 개정과 시험이 참조한 개정이 같은지, 결과 파일에서 해당 동작을 찾을 수 있는지 확인합니다.
한 줄을 끝까지 읽어보면 연결표를 채우는 과정에서 빠진 정보가 드러날 수 있습니다.
요구사항을 관찰 가능한 동작으로 풀어봅니다
“문제가 생기면 사용자에게 알린다”는 문장은 방향은 있지만 무엇을 확인할지 정하기 어렵습니다.
어떤 상태를 문제로 보는지, 누가 어떤 표시를 보아야 하는지, 다른 화면이나 값은 어떤 상태로 남는지 나눠 적어볼 수 있습니다.
이는 모든 기기에 같은 문장을 적용하자는 뜻이 아니라, 팀이 같은 동작을 상상하고 있는지 확인하기 위한 질문입니다.
예를 들어 아래의 센서 사례에서는 ‘연결 단절 상태의 안내’와 ‘기존 측정값의 표시 방식’을 따로 검토합니다.
연결 상태를 표시하는 기능만 확인해 놓고 화면 전체의 의미까지 확인했다고 판단하면 질문 하나가 빠질 수 있습니다.
해당 기능의 위험과 사용 맥락에 따라 검토 범위는 달라집니다.
| 요구사항을 읽는 질문 | 시험을 읽는 질문 | 기록에서 찾을 것 |
|---|---|---|
| 언제 그 동작이 필요한가? | 같은 상태를 만들었는가? | 입력·사전 상태·환경 |
| 무엇을 표시하거나 처리해야 하는가? | 그 결과를 실제로 관찰했는가? | 기대 결과와 관찰 결과 |
| 어느 구성에 적용되는가? | 그 구성으로 실행했는가? | 모델·설정·소프트웨어 버전 |
| 남은 질문은 무엇인가? | 확인하지 않은 조건이 있는가? | 미실행·이상·후속 검토 |
표는 검토 대화를 위한 자체 도구입니다.
요구사항마다 반드시 시험 한 개를 붙이는 고정 구조가 아닙니다.
하나의 요구사항을 여러 시험으로 확인할 수도 있고, 한 시험에서 여러 요구사항을 다룰 수도 있습니다.
다만 여러 번호가 연결되어 있을 때는 각 내용을 어느 단계에서 확인했는지 읽을 수 있어야 합니다.
가상 사례: 센서 연결이 끊어졌습니다
가상 상황입니다.
센서의 값을 화면에 표시하는 기기를 개발하고 있습니다.
팀은 연결이 끊기면 사용자가 그 상태를 알아차려야 한다고 정했습니다.
검토 중 화면에 지난 측정값이 그대로 남는다는 사실을 발견했습니다.
단절 안내가 있더라도 사용자가 그 값을 현재 값으로 읽을 가능성을 검토할 필요가 있다는 질문이 생겼습니다.
이때 그림의 흐린 파형이 정답이라는 뜻은 아닙니다.
값의 표시 방식은 제품의 사용목적과 위험 검토를 바탕으로 정해야 합니다.
여기서는 승인된 동작을 시험 조건과 연결하는 과정을 살펴봅니다.
특정 지연시간이나 공통 합격 수치는 임의로 넣지 않습니다.
| 가상 검토 항목 | 현재 확보한 근거 | 아직 확인할 부분 |
|---|---|---|
| 연결된 상태의 표시 | 정상 연결 상태의 실행 기록 | 단절 상태를 다루지는 않음 |
| 단절 상태의 안내 | 단절 표시 화면 | 이전 값의 상태가 요구사항과 맞는지 |
| 재연결 이후의 동작 | 시험 초안만 작성됨 | 실제 실행과 새 데이터 표시 확인 |
이 표에는 일부러 미결 상태를 남겼습니다.
시험 초안이 있다는 것과 실행했다는 것은 다르고, 실행했다는 것과 기대 동작을 만족했다는 것도 다릅니다.
완료율을 높이기 위해 빈칸을 ‘통과’로 채우면 다음 사람이 무엇을 더 확인해야 하는지 알 수 없습니다.
판정과 관찰 기록을 함께 남깁니다
실무 메모에는 요구사항 ID와 개정, 시험 ID와 절차 개정, 시험한 소프트웨어의 식별정보를 한데 묶어볼 수 있습니다.
이어서 기대 결과, 실제 관찰, 판정, 근거 파일의 위치를 남깁니다.
긴 로그를 문서마다 복사하기보다 원본 기록의 해당 부분을 찾을 수 있게 연결하면 검토가 수월합니다.
예를 들어 ‘정상 표시 확인’이라고만 쓰기보다 어떤 사전 상태에서 어떤 조작을 했고, 어느 화면이나 로그에서 결과를 읽었는지를 남기는 편이 좋습니다.
화면 캡처가 필요하더라도 화면만으로 시간 순서나 내부 상태가 설명되는지는 별도로 봅니다.
반대로 로그가 많다는 이유만으로 사용자에게 보이는 동작까지 확인됐다고 가정하지 않습니다.
실행하지 못한 조건은 미실행으로, 해석이 필요한 결과는 추가 검토로 구분합니다.
실패한 기록을 새 통과 기록으로 덮어쓰기보다 무엇을 고쳤고 어떤 버전에서 다시 확인했는지 이어두면 변경 이유를 이해할 수 있습니다.
이 메모는 시험을 대신하는 문서가 아니라 시험 근거를 찾기 쉽게 만드는 안내 역할을 합니다.
한 줄이 바뀌면 연결된 시험을 다시 살펴봅니다
앞의 가상 사례에서 이전 값을 표시하는 규칙을 바꿨다고 생각해 보겠습니다.
팀은 관련 요구사항과 화면 설계를 수정하고, 그 변경이 단절 안내와 재연결 동작에도 영향을 줄 수 있는지 확인합니다.
이때 연결표는 수정된 문서 번호를 모아두는 목록을 넘어, 다시 검토할 범위를 찾는 출발점이 됩니다.
MedQraft의 제안은 다음과 같습니다.
먼저 변경된 의미를 짧게 적고, 연결된 설계·시험을 찾습니다.
다음으로 직접 연결되지 않았지만 같은 데이터나 상태를 사용하는 기능이 있는지 담당자와 확인합니다.
마지막으로 추가 확인이 필요한 이유와 필요하지 않다고 판단한 이유를 구분해 남깁니다.
기존 연결표가 완벽하다고 전제하면 새롭게 생긴 관계를 놓칠 수 있습니다.
시험을 무조건 전부 반복하거나 직접 연결된 시험만 기계적으로 반복하는 방식보다, 변경의 영향과 위험에 맞춰 검토 범위를 정하는 것이 이 메모의 목적입니다.
실제 회귀시험 범위는 개발·품질 담당자가 해당 제품과 변경을 검토해 결정해야 합니다.
검토 회의에서 한 줄을 끝까지 따라가세요
- 요구사항을 읽는 두 사람이 같은 입력·상태·출력을 떠올릴 수 있나요?
- 연결된 시험의 기대 결과가 요구사항의 어느 부분을 확인하나요?
- 정상 조건 외에 검토가 필요한 단절·복구 같은 상태가 남아 있나요?
- 결과 기록은 시험한 소프트웨어와 설정을 식별할 수 있나요?
- 미실행과 실패, 추가 검토가 통과와 구분되어 있나요?
- 요구사항이 바뀌었을 때 다시 확인할 범위를 설명할 수 있나요?
처음부터 거대한 양식을 만들기보다 중요 기능 하나를 골라 요구사항에서 실제 기록까지 열어보는 방식으로 시작해 보세요.
찾지 못한 근거, 서로 다른 개정, 설명이 부족한 조건을 정리한 뒤 팀의 문서 구조에 맞춰 보완할 수 있습니다.
관련 글: 의료기기 성능시험 결과를 비교할 때 확인할 조건, 의료기기 위험관리의 근거 연결.
소프트웨어 시험과 별개의 주제지만, 시험 범위와 근거를 읽는 질문을 함께 살펴볼 수 있습니다.
참고 자료와 작성 범위
- FDA, Content of Premarket Submissions for Device Software Functions, 2023년 6월 14일 발행.
정의 및 VI.D·VI.H·VI.I, 현재 PDF의 QMSR 안내를 확인했습니다.
공식 원문 - 확인일: 2026년 9월 28일.
미국 제출자료 권고를 참고한 해설이며 국가·제품별 법규 적용이나 전체 소프트웨어 개발 절차를 확정하는 글은 아닙니다. - 센서 사례와 표, 그림은 MedQraft 자체 구성입니다.
실제 제품의 시험 결과나 고객 수행 사례를 사용하지 않았습니다.
특정 제품 기능이나 인증·허가 성과를 광고하지 않습니다.