R&D 설계관리에서 추적성 매트릭스는 “요구사항 번호와 시험 번호를 붙여 둔 표”로 끝나면 안 됩니다. 요구사항이 어디에서 왔는지, 어떤 설계 산출물로 구현됐는지, 어떤 검증시험이 그 산출물을 확인했는지, 실제 사용 목적은 어떻게 확인했는지, 변경이 생겼을 때 어떤 행을 다시 열어야 하는지가 같은 흐름으로 보여야 합니다. 이 연결이 없으면 시험은 통과했는데 원래 요구사항을 만족했는지 알 수 없고, 변경은 승인됐는데 이전 시험 결과를 그대로 써도 되는지 판단하기 어렵습니다.
이 글은 특정 산업의 인허가 통과나 ISO 인증을 보장하는 문서가 아닙니다. FDA의 QMSR 전환 자료, 설계관리 교육 자료, ISO 13485와 ISO/IEC/IEEE 29148의 공개 설명, NASA 시스템공학 핸드북, ISO/IAF 설계개발 감사 지침을 R&D 운영 문서 관점으로 재구성합니다[S1][S2][S4][S5]. 핵심 질문은 하나입니다. “임의의 요구사항 하나를 골랐을 때 출처, 설계 출력, 시험, 밸리데이션, 변경 이력, 미해결 조치를 10분 안에 따라갈 수 있는가?”
**빠른 결론**
R&D 설계관리 추적성 매트릭스는 파일 보관표가 아니라 설계 판단 연결표입니다. 최소 필드는 `요구사항 ID`, `요구사항 출처`, `설계 입력`, `설계 출력`, `검증 방법`, `시험 ID와 수용 기준`, `밸리데이션 근거`, `변경 요청 ID`, `영향 재평가`, `현재 상태`, `책임자`, `승인 기록`입니다. 이 중 하나라도 “별도 확인”, “담당자 기억”, “폴더 참고”로 남아 있으면 매트릭스가 아니라 추적성 후보 목록입니다.
R&D 설계관리 추적성 매트릭스는 요구사항 행을 중심으로 시작합니다
설계관리 추적성 매트릭스의 첫 열은 시험 항목이 아니라 요구사항이어야 합니다. ISO/IEC/IEEE 29148은 시스템과 소프트웨어의 생애주기 전반에서 요구사항 공학 프로세스와 산출물을 다루는 표준으로 소개됩니다[S5]. 이 관점에서 보면 매트릭스는 시험 담당자가 만든 결과표가 아니라 요구사항을 설계와 검증으로 흘려보내는 관계표입니다.
요구사항 행에는 최소 세 가지 출처가 있어야 합니다. 첫째, 사용자 요구 또는 사업 요구입니다. 둘째, 규격, 표준, 계약, 안전, 사용성 같은 외부 제약입니다. 셋째, 위험관리 또는 이전 시험에서 새로 발견된 설계 입력입니다. FDA QMSR 설계개발 교육 자료는 2026년 QMSR이 ISO 13485:2016의 설계개발 요구를 통합하며, 설계 입력에는 기능, 성능, 사용성, 안전 요구, 적용 가능한 규제와 표준 요구, 위험관리 산출물이 포함된다고 설명합니다[S1]. 일반 R&D 팀도 이 원칙을 “요구사항이 왜 생겼는지”를 남기는 기준으로 사용할 수 있습니다.
따라서 “배터리 지속 시간이 길어야 한다”는 행은 부족합니다. “휴대 사용 시나리오 UR-03에서 8시간 이상 동작해야 하며, 실온 조건에서 시료 3대 이상 시험한다”처럼 출처, 조건, 수치, 검증 가능성이 있어야 합니다. 요구사항이 검증 가능한 문장으로 닫히지 않으면 뒤의 시험 행도 흔들립니다. 이 문제는 [R&D 사용자 요구사항 명세 체크리스트](/guide/rnd-user-requirement-spec-checklist)에서 먼저 고치고, 이 글의 매트릭스는 그다음 단계에서 연결성을 확인하는 용도로 쓰는 편이 좋습니다.
요구사항-설계 산출물-검증시험 연결은 PASS보다 trace gap을 먼저 봅니다
시험 결과가 PASS라고 해서 추적성이 완성되지는 않습니다. FDA 설계관리 교육 자료는 설계 출력이 설계 입력 적합성을 평가할 수 있는 형태로 정의되고, 측정 가능한 수용 기준을 참조해야 한다고 설명합니다[S2]. 또 설계 검증은 설계 출력이 설계 입력을 만족한다는 객관적 증거 확인으로 설명됩니다[S2]. 즉 매트릭스의 질문은 “시험을 했나”가 아니라 “이 시험이 이 설계 출력과 이 요구사항을 확인하는가”입니다.
아래 표는 R&D 설계관리 추적성 매트릭스 초안에서 바로 점검할 수 있는 최소 필드입니다.
| 필드 | 확인 질문 | 누락될 때 생기는 문제 |
|---|---|---|
| 요구사항 ID | 요구사항이 고유하고 변경 이력을 추적할 수 있는가 | 같은 문장이 여러 문서에서 다르게 수정됩니다 |
| 요구사항 출처 | 사용자 요구, 표준, 위험관리, 계약 중 무엇에서 왔는가 | 왜 필요한 요구인지 설명하지 못합니다 |
| 설계 입력 | 기능, 성능, 안전, 사용성, 제약 조건으로 분리됐는가 | 시험 가능성이 낮은 문장이 남습니다 |
| 설계 출력 | 도면, 사양서, 알고리즘, BOM, 공정 조건 중 무엇으로 구현됐는가 | 요구사항이 실제 설계물에 닿지 않습니다 |
| 검증 방법 | 분석, 검토, 시험, 시연 중 어느 방식인가 | 불필요한 시험 또는 부족한 문서검토가 생깁니다 |
| 시험 ID와 수용 기준 | 시험계획서, 프로토콜, 합격 기준이 연결됐는가 | PASS의 근거를 재현하기 어렵습니다 |
| 밸리데이션 근거 | 실제 또는 모의 사용 조건에서 사용자 필요를 확인했는가 | 제품을 올바르게 만들었는지와 올바른 제품인지가 섞입니다 |
| 변경 요청 ID | 변경 후 이 행을 다시 열었는가 | 이전 시험 결과를 잘못 재사용합니다 |
| 상태와 책임자 | open, verified, validated, changed, deferred 중 무엇인가 | 회의 때 누구도 행을 닫지 못합니다 |
이 표의 중심은 “파일 링크를 많이 붙이는 것”이 아닙니다. 산출물 ID가 있어도 요구사항과 연결되지 않으면 단순 인덱스입니다. 시험 ID가 있어도 수용 기준이 없으면 결과 해석이 사람마다 달라집니다. 변경 요청 ID가 있어도 어떤 요구사항과 시험을 다시 봐야 하는지 없으면 변경관리 로그와 매트릭스가 서로 다른 현실을 갖게 됩니다.
검증시험과 밸리데이션은 같은 칸에 넣지 않는 편이 안전합니다
R&D 문서에서 자주 생기는 오류는 검증시험과 밸리데이션을 한 칸에 넣는 것입니다. FDA 설계관리 교육 자료는 설계 검증을 출력이 입력을 만족하는지 확인하는 활동으로, 설계 밸리데이션을 사양이 사용자 필요와 의도한 사용에 맞는지 객관적 증거로 확인하는 활동으로 구분합니다[S2]. 간단히 말하면 검증은 “정해진 대로 만들었는가”, 밸리데이션은 “정말 필요한 것을 만들었는가”에 가깝습니다.
예를 들어 “기기는 1m 낙하 후 정상 동작해야 한다”는 요구사항은 낙하시험 프로토콜과 연결됩니다. 이것은 설계 출력이 입력 요구를 만족하는지 보는 검증입니다. 반면 현장 사용자가 장갑을 낀 상태에서 실제 사용 흐름을 완료할 수 있는지는 사용 조건에서의 밸리데이션에 가깝습니다. 둘 다 필요할 수 있지만 같은 증거는 아닙니다.
매트릭스에는 `verification_evidence`와 `validation_evidence`를 분리하는 것이 좋습니다. 검증 칸에는 시험계획서, 분석 결과, 도면 검토, 시뮬레이션, 계산 검토를 넣습니다. 밸리데이션 칸에는 사용자 시나리오, 모의 사용 조건, 대표 시료, 현장 피드백, 사용성 평가 근거를 넣습니다. 아직 밸리데이션이 이른 단계라면 “해당 없음”으로 지우지 말고 `planned_after_prototype`, `covered_by_user_test_UT-02`, `not_required_for_this_internal_research_stage`처럼 이유를 남겨야 합니다.
변경 이력은 별도 로그가 아니라 매트릭스 행을 다시 여는 트리거입니다
변경관리 로그가 따로 있어도 추적성 매트릭스가 업데이트되지 않으면 설계관리 기록은 끊깁니다. ISO/IAF의 ISO 9001 설계개발 감사 지침은 설계개발 변경에서 변경 요청의 출처, 영향 평가, 추가 검증 또는 시험, 이미 인도된 제품이나 서비스에 대한 영향, 승인, 문서화와 추가 조치를 검토해야 한다고 설명합니다[S8]. R&D 매트릭스에서는 이 내용을 “변경이 어느 행을 다시 열었는가”로 바꿔야 합니다.
**변경 후 추적성 위험 신호**
설계 사양은 바뀌었는데 시험 ID가 그대로입니다. 수용 기준은 바뀌었는데 이전 PASS가 유지됩니다. 위험관리 산출물은 수정됐는데 요구사항 출처 열이 비어 있습니다. 변경 요청서는 승인됐지만 영향을 받은 설계 출력과 밸리데이션 근거가 표시되지 않습니다. 이런 경우 변경은 닫힌 것이 아니라 매트릭스 밖에 숨어 있는 상태입니다.
변경 이력 열에는 날짜만 쓰지 말고 네 가지를 남겨야 합니다. 첫째, 변경 요청 ID와 사유입니다. 둘째, 영향받은 요구사항과 설계 출력입니다. 셋째, 기존 시험 결과를 유지할지, 부분 재시험할지, 전체 재시험할지, 문서 검토로 충분한지에 대한 판단입니다. 넷째, 변경 후 닫힌 상태와 승인자입니다. [R&D 변경 영향평가 체크리스트](/guide/rnd-change-impact-assessment-checklist)는 이 판단을 더 깊게 다루고, 이 글에서는 그 결과가 매트릭스 행에 반영됐는지만 봅니다.
NASA 시스템공학 핸드북은 요구사항 추적성이 보통 요구사항 매트릭스나 요구사항 모델링 애플리케이션으로 기록된다고 설명하고, 기준선이 잡힌 요구사항 문서는 요구사항 매트릭스의 추적 관계와 연결된다고 설명합니다[S6]. 이 관점에서 보면 변경 이력은 부록이 아니라 기준선과 현재 상태를 잇는 연결입니다. 설계 산출물이 바뀌면 요구사항 행도, 시험 행도, 밸리데이션 행도 함께 확인되어야 합니다.
설계 산출물 관리는 파일명보다 승인 가능한 산출물 ID가 먼저입니다
설계 산출물 관리가 약한 팀은 파일명으로 추적합니다. `final_v3_reviewed_last.xlsx` 같은 파일명은 사람이 보기에는 익숙해도 매트릭스의 키가 될 수 없습니다. 산출물에는 유형, 버전, 승인 상태, 적용 범위가 있어야 합니다. ISO 13485의 공개 설명은 의료기기 조직이 설계, 생산, 설치, 서비스 등 여러 생애주기 단계에 관여할 수 있고, ISO 13485가 의료기기 산업의 품질경영시스템 요구를 다루는 표준이라고 설명합니다[S4]. 의료기기가 아닌 R&D라도 생애주기 단계별 산출물 분리는 그대로 유용합니다.
설계 산출물 ID는 최소한 `DO-도면`, `SP-규격`, `SW-소프트웨어`, `PROC-공정조건`, `BOM-자재`, `RISK-위험관리`, `TEST-시험계획`, `VAL-밸리데이션`처럼 유형을 드러내야 합니다. 요구사항 하나가 여러 산출물로 구현될 수 있고, 산출물 하나가 여러 요구사항을 만족할 수도 있습니다. 그래서 매트릭스는 일대일 연결만 가정하면 안 됩니다. 한 요구사항이 도면과 펌웨어와 시험치구에 동시에 영향을 주면 같은 요구사항 ID 아래 복수 산출물을 명시해야 합니다.
산출물 관리에서 특히 빠지는 필드는 세 가지입니다. 첫째, 승인 전 산출물과 승인 후 산출물의 구분입니다. 둘째, 외주 산출물의 원본 위치와 승인 책임자입니다. 셋째, 시험에 사용된 산출물 버전입니다. 시험은 최신 도면으로 했다고 생각했지만 실제로는 이전 치구 버전으로 수행한 경우, PASS 결과를 그대로 쓸 수 없습니다. 이 문제는 [R&D 시험치구 교정 체크리스트](/guide/rnd-test-fixture-calibration-checklist)나 [R&D 수용기준·시험계획 체크리스트](/guide/rnd-acceptance-criteria-test-plan-checklist)로 이어집니다.
요구사항-시험-변경 연결을 30분 안에 점검하는 순서
회의 직전에는 모든 파일을 다시 열기보다 대표 행을 뽑아 추적 경로를 확인해야 합니다. NASA 핸드북의 검증 매트릭스와 밸리데이션 매트릭스 예시는 검증 또는 밸리데이션 활동, 방법, 수행 조직, 결과 같은 정보를 행 단위로 다루는 방식을 보여줍니다[S6]. R&D 팀은 이 구조를 간단한 30분 점검으로 바꿀 수 있습니다.
1. 위험이 높은 요구사항 3개와 최근 변경된 요구사항 2개를 고릅니다.
2. 각 요구사항의 출처 문서와 설계 입력 문장을 확인합니다.
3. 연결된 설계 출력 ID와 버전이 시험 당시 사용된 버전과 같은지 봅니다.
4. 검증시험 ID, 수용 기준, 원자료 위치, 결과 상태를 확인합니다.
5. 밸리데이션이 필요한 행인지, 아직 계획 단계인지, 제외 사유가 있는지 봅니다.
6. 최근 변경 요청이 이 행을 다시 열었는지 확인합니다.
7. 미해결 이슈, 편차, 재시험 조건, 승인자가 남아 있는지 봅니다.
이 7단계를 통과하지 못한 행은 “문서가 없다”보다 “연결이 없다”고 표현하는 편이 정확합니다. 연결이 없으면 새 문서를 쓰기 전에 매트릭스 행부터 고쳐야 합니다. 새 시험계획서, 새 변경 요청서, 새 회의록을 만들어도 요구사항 행에 돌아오지 않으면 설계관리 증거는 계속 흩어집니다.
기존 rndatlas 설계·품질 글과 이 체크리스트의 경계
이 글은 요구사항 문장을 처음 쓰는 방법을 다루지 않습니다. 문장이 모호하다면 [R&D 사용자 요구사항 명세 체크리스트](/guide/rnd-user-requirement-spec-checklist)를 먼저 봅니다. 이 글은 수용 기준과 시험계획을 설계하는 글도 아닙니다. 시험 조건, 샘플, 원자료, 재시험 기준이 문제라면 [R&D 수용기준·시험계획 체크리스트](/guide/rnd-acceptance-criteria-test-plan-checklist)로 분리하는 편이 낫습니다.
또한 이 글은 일반 증거 저장소를 만드는 글이 아닙니다. 요구사항-시험-증거 관계표 자체를 다루는 폭넓은 주제는 [R&D evidence traceability matrix checklist](/guide/rnd-evidence-traceability-matrix-checklist)가 더 맞습니다. 여기서는 설계관리 관점에서 사용자 요구, 설계 입력, 설계 출력, 검증시험, 밸리데이션, 변경 이력이 한 행에서 끊기지 않는지만 봅니다. 설계 동결 이후 변경 요청과 승인권자가 문제라면 [R&D design freeze change control checklist](/guide/rnd-design-freeze-change-control-checklist)로 넘어가야 합니다.
마지막으로 이 체크리스트는 품질시스템 전체 절차서가 아닙니다. FDA QMSR과 ISO 13485 자료를 참고했지만, 모든 R&D 조직에 동일한 규제 의무를 적용한다는 뜻은 아닙니다[S1][S4]. 실제 인허가, 인증, 고객 감사, 정부과제 평가에 쓰려면 조직의 품질시스템, 계약 조건, 관할 규정, 고객 요구를 별도로 확인해야 합니다. 이 글의 역할은 그 전에 내부 설계관리 표가 스스로 설명 가능한지 점검하는 것입니다.
R&D 설계관리 추적성 매트릭스의 마지막 합격 기준
좋은 매트릭스는 예쁘게 정렬된 표가 아니라 질문에 빨리 답하는 표입니다. “이 요구사항은 왜 생겼나”, “무엇으로 구현됐나”, “어떤 시험이 확인했나”, “실제 사용 목적은 어떻게 닫혔나”, “변경 후에도 이전 결과가 유효한가”, “누가 이 행을 닫았나”에 답해야 합니다. 답이 파일 폴더, 회의 기억, 담당자 메신저에만 있으면 아직 설계관리 추적성이 부족합니다.
최종 점검은 다섯 문장으로 끝낼 수 있습니다. 요구사항마다 출처와 검증 가능한 문장이 있다. 설계 입력과 설계 출력이 분리되어 있다. 검증시험과 밸리데이션 근거가 다른 칸에 있다. 변경 요청은 영향받은 요구사항, 산출물, 시험 결과를 다시 열었다. 미해결 행에는 책임자, 다음 조치, 재검토 날짜가 있다. 이 다섯 문장이 참이면 R&D 설계관리 추적성 매트릭스는 단순 문서 목록을 넘어 설계 의사결정 도구가 됩니다.
R&D 설계관리 추적성 매트릭스 체크리스트 참고 출처
- [S1] FDA, QMSR Design and Development, accessed 2026-07-03.
- [S2] FDA, Design Controls training material, accessed 2026-07-03.
- [S3] FDA, Quality Management System Regulation (QMSR), updated 2026-02-02, accessed 2026-07-03.
- [S4] ISO, ISO 13485 - Medical devices, accessed 2026-07-03.
- [S5] ISO, ISO/IEC/IEEE 29148:2018 Systems and software engineering - Requirements engineering, accessed 2026-07-03.
- [S6] NASA, Systems Engineering Handbook Rev 2, accessed 2026-07-03.
- [S7] NASA, System Engineering Handbook Appendix, accessed 2026-07-03.
- [S8] ISO/IAF Auditing Practices Group, Auditing Design and Development, accessed 2026-07-03.