요구사항 추적성 매트릭스는 왜 금방 낡을까
요구사항 추적성 매트릭스, 곧 RTM은 그 자체로 충분히 쓸모가 있습니다. 요구사항마다 연결된 설계와 구현, 테스트를 찾을 수 있고 빠진 항목도 표에서 드러납니다. 문제는 표를 처음 작성한 시점의 연결을 지금의 연결이라고 믿을 때 생깁니다.
REQ-AUTH-014의 비밀번호 정책이 버전 2에서 버전 3으로 바뀌었다고 하겠습니다. 테스트 TC-AUTH-007이 여전히 REQ-AUTH-014와 연결돼 있다는 사실만으로 커버리지가 유지됐다고 볼 수는 없습니다. 새 길이 제한과 예외 조건, 오류 메시지를 그 테스트가 반영했는지 확인하지 않았다면 링크는 존재하지만 낡은 링크입니다.
NASA SWE-071도 추적성 매트릭스를 시점 고정 문서로 보지 않습니다.[2] 프로젝트가 변하는 동안 계속 갱신하며 요구사항이 바뀌면 어떤 테스트 절차와 케이스, 스크립트, 데이터가 영향을 받는지 찾는 도구로 씁니다. 그래서 추적성 설계에는 세 가지가 함께 있어야 합니다. 무엇을 연결할지 정하는 객체 모델, 연결의 의미를 구분하는 링크 유형, 변경이 일어날 때 연결을 다시 검토하는 운영 절차입니다.
무엇을 추적 객체로 삼아야 하나
추적성은 모든 업무 데이터를 한곳에 복제하는 작업이 아닙니다. 각 시스템에 남아 있는 객체를 안정적인 식별자와 버전으로 참조하면 됩니다. 아래 일곱 객체가 최소 단위입니다.
Release / Baseline Reference는 출시 승인 표시가 아닙니다. 이 표가 어느 요구사항과 코드, 테스트 버전 위에서 만들어졌는지 다시 재현하기 위한 좌표에 가깝습니다.
객체 | 역할 | 최소 필드 | 이 객체가 답해야 하는 질문 |
|---|---|---|---|
| Requirement | 구현하고 검증해야 할 현재 요구 | id, version, statement, source, acceptance_criteria, status, owner, updated_at | 지금 유효한 요구는 무엇이며 어느 버전인가 |
| Change | 요구가 왜, 무엇에서 무엇으로 바뀌었는지 기록 | id, reason, before_ref, after_ref, status, owner, captured_at | 어떤 변경이 발생했고 변경 전후는 무엇인가 |
| Implementation Artifact | 요구를 구현하는 코드와 API, DB 스키마, 설정, 문서 | id, kind, location, revision, status, owner | 어떤 산출물이 이 요구를 구현하는가 |
| Test | 요구를 어떤 조건과 결과로 검증하는지 기록 | id, revision, objective, preconditions, test_data_ref, expected_result, status, owner | 어떤 테스트가 어느 요구 버전을 검증하는가 |
| Defect | 검증 또는 운영 중 발견된 불일치 | id, summary, state, severity, source_ref, fix_ref, owner | 무엇이 어떤 근거로 발견됐고 어디와 연결되는가 |
| Release / Baseline Reference | 특정 시점의 요구와 구현, 테스트 집합을 재현하는 참조 | id, requirement_set_revision, implementation_revision, test_catalog_revision, created_at | 이 추적 상태가 어느 버전 집합을 기준으로 하는가 |
| Change Package | 변경 한 건의 영향 검토와 링크 갱신을 묶는 운영 단위 | id, change_ref, target_baseline, impacted_objects, dispositions, orphan_result, freshness_result, reviewer, state | 이 변경에서 무엇을 확인했고 무엇이 남아 있는가 |
요구사항에서 승인까지 이어지는 근거 — 요구사항과 테스트, 결함 조치와 승인 기록을 연결해 같은 기준으로 품질을 판단합니다.
표 대신 연결 구조로 보면 무엇이 달라지나
인증 요구사항이 바뀐 상황을 그래프로 그려 보겠습니다. REQ-AUTH-014@v3은 supersedes로 v2를 대체합니다. IMPL-auth-api@8f2a는 implements로, TC-AUTH-007@v4는 verifies로 각각 v3을 가리킵니다. 요구와 구현, 테스트 셋은 모두 affected_by로 CHG-042에 연결됩니다. DEF-088은 found_by로 TC-AUTH-007@v4를 가리키고 blocks로 CP-042를 붙듭니다. CP-042는 CHG-042를 대상 변경으로, BASE-2026.08.3을 대상 베이스라인으로 삼고, 그 베이스라인은 requirements@v3과 리비전 8f2a, tests@v4를 묶습니다.
이 그래프에서 중요한 것은 도구의 화면이 아닙니다. 각 연결이 어떤 관계인지, 어느 버전끼리의 연결인지, 어떤 변경에서 마지막으로 검토됐는지를 읽어 낼 수 있어야 합니다.
링크에 이름을 붙이면 무엇을 설명할 수 있나
링크 유형이 없으면 연결은 선 하나에 지나지 않습니다. 이름이 붙어야 그 선을 따라 무엇을 확인해야 하는지가 정해집니다.
모든 결함이 테스트에서 발견되지는 않습니다. 고객 문의와 모니터링, 코드 검토에서 나온 결함에 가짜 found_by 링크를 만들면 안 됩니다. 이런 경우에는 source_ref에 실제 발견 근거를 남기고 변경 패키지의 영향 객체에 연결합니다.
blocks도 출시 차단 판정이 아닙니다. 여기서 blocks는 해당 결함의 처리 상태가 정리되기 전까지 변경 영향 검토 패키지를 완료 처리하지 못한다는 뜻으로만 씁니다.
링크 유형 | 방향 | 의미 | 검토할 내용 |
|---|---|---|---|
| implements | Implementation Artifact → Requirement | 해당 산출물이 요구를 구현한다 | 구현 리비전이 현재 요구 버전과 맞는가 |
| verifies | Test → Requirement | 해당 테스트가 요구를 검증한다 | 조건과 데이터, 기대 결과가 현재 요구를 실제로 확인하는가 |
| affected_by | Requirement·Implementation·Test·Defect → Change | 해당 객체가 변경의 영향 검토 대상이다 | 변경 패키지에 처리 결과와 근거가 있는가 |
| found_by | Defect → Test | 결함이 해당 테스트에서 발견됐다 | 재현 가능한 테스트와 결함이 연결돼 있는가 |
| supersedes | 새 Requirement 또는 Test 버전 → 이전 버전 | 새 객체가 이전 객체를 대체한다 | 이전 객체가 폐기·대체 상태로 정리됐는가 |
| blocks | Defect → Change Package | 결함 처리가 기록되기 전에는 변경 패키지를 닫을 수 없다 | 수정·재현 불가·별도 이관 등의 상태와 근거가 기록됐는가 |
양방향 추적성은 역방향 링크를 하나 더 만드는 일이 아니다
양방향 추적성은 같은 관계를 앞뒤 어느 쪽에서도 조회한다는 뜻입니다. TC-AUTH-007@v4가 verifies로 REQ-AUTH-014@v3을 가리키는 링크가 있다면 두 질문에 모두 답할 수 있어야 합니다. 이 요구사항을 검증하는 테스트는 무엇인가, 그리고 이 테스트는 어떤 요구사항과 버전을 근거로 만들어졌는가입니다.
정방향용 행과 역방향용 행을 따로 저장할 필요는 없습니다. 두 행을 나눠 관리하면 한쪽만 갱신되는 순간 연결이 서로 모순됩니다. 링크 하나를 저장하고 조회 방향만 바꾸는 편이 안전합니다.
관계가 일대일일 필요도 없습니다. 요구사항 하나를 여러 테스트가 검증할 수 있고, 통합 테스트 하나가 여러 요구사항을 함께 검증하기도 합니다. NASA의 양방향 추적성 지침도 이런 다대다 관계와 고아 객체의 검토를 함께 명시합니다.[1]
변경 한 건을 어디까지 확인했다고 말할 수 있나
변경 패키지는 파일 압축 묶음이나 배포 패키지가 아닙니다. 변경 하나가 요구사항과 구현, 테스트, 결함과 링크에 남긴 영향을 끝까지 따라가기 위한 검토 단위입니다.
변경이 들어오면 먼저 변경 전후 요구사항 버전을 기록합니다. 그다음 기존 링크를 따라 영향 후보를 모으고 후보마다 처리 결과를 지정합니다. 내용을 고쳐야 하면 update, 다시 검토했지만 그대로 두면 retain, 더 이상 유효하지 않으면 retire, 후보로 발견됐지만 영향이 없으면 not_impacted입니다. retain과 not_impacted에도 근거가 있어야 합니다. 아무 기록 없이 상태만 유지하면 검토해서 남긴 것과 검토하지 않은 것이 구분되지 않습니다.
NASA의 요구사항 관리 체계도 변경 영향 분석 결과와 관련 문서 갱신 조치를 변경 패키지에 담고 갱신이 끝날 때까지 추적하도록 합니다.[4] 바뀐 요구사항뿐 아니라 관련 설계와 코드, 테스트, 문서, 추적 정보까지 최신 상태로 유지하라는 요구입니다. 다만 변경 패키지가 닫혔다는 것은 변경 영향과 링크를 정해진 절차로 검토했다는 뜻입니다. 그 자체가 출시 가능 여부를 말하지는 않습니다.
확인 항목 | 완료 조건 |
|---|---|
| 변경 식별 | change_id와 변경 이유, 요청자와 소유자가 기록됨 |
| 변경 전후 요구 | before_ref와 after_ref가 버전까지 식별됨 |
| 영향 후보 탐색 | 요구에서 구현·테스트·결함 방향으로, 구현·테스트에서 요구 방향으로 탐색함 |
| 구현 산출물 검토 | 모든 후보에 update, retain, retire, not_impacted 중 하나와 근거가 있음 |
| 테스트 검토 | 변경된 요구를 검증하는 테스트의 리비전과 조건, 기대 결과를 검토함 |
| 결함 검토 | 연결된 미해결 결함의 상태와 변경 패키지에 미치는 영향이 기록됨 |
| 링크 갱신 | 추가·수정·삭제·대체된 링크와 검토자가 기록됨 |
| 고아 탐지 | 정의된 고아 규칙을 실행하고 결과를 처리함 |
| 최신성 검토 | 관련 링크가 present, reviewed, stale 중 하나로 분류됨 |
| 베이스라인 고정 | 요구와 구현, 테스트 집합의 기준 리비전이 기록됨 |
| 검토 기록 | 소유자와 검토자, 검토 시점, 미해결 후속 작업이 남음 |
연결되지 않은 항목은 어떻게 다뤄야 하나
고아 항목이 무조건 잘못된 데이터인 것은 아닙니다. 다만 사람이 설명해야 할 연결 공백입니다. 자동 검사는 고아를 지우거나 임의의 링크를 만들지 말고 검토 대기열에 올려야 합니다.
NASA SWE-052도 출처가 없는 설계나 구현 같은 고아 요소를 자동으로 불필요하다고 단정하지 않습니다.[1] 팀이 필요성을 먼저 검토한 뒤 빠진 상위 근거를 추가하거나 객체를 정리하게 합니다.
고아 규칙 | 탐지 조건 | 왜 문제인가 | 필요한 조치 |
|---|---|---|---|
| 테스트 없는 변경된 요구사항 | 현재 변경 패키지에서 바뀐 active·검증 가능 요구에 reviewed 상태의 verifies 링크가 없음 | 새 요구가 검증 체계에서 빠질 수 있음 | 테스트 추가·수정 또는 검증 불필요 근거 기록 |
| 근거 없는 테스트 | active 테스트가 현재 유효한 요구나 승인된 별도 근거와 연결되지 않음 | 무엇을 확인하는 테스트인지 알 수 없고 유지보수 비용만 남음 | 요구와 연결하거나 근거를 보완하고 불필요하면 폐기 |
| 연결되지 않은 결함 | 결함에 실제 발견 근거가 없고 관련 변경·테스트·영향 객체도 식별되지 않음 | 재현과 수정, 재검증 경로를 찾기 어려움 | 실제 source_ref와 found_by, 영향 객체를 보완 |
| 영향 검토 없는 변경 | 승인 또는 구현된 변경에 변경 패키지가 없거나 영향 후보의 처리 결과가 미완료 | 일부 코드와 테스트, 문서가 변경에서 빠질 수 있음 | 변경 패키지 생성 및 양방향 영향 검토 |
| 폐기된 요구를 계속 검증하는 테스트 | active 테스트가 retired 또는 superseded 요구에만 연결됨 | 테스트는 실행되지만 현재 요구 충족을 설명하지 못함 | 새 요구 버전에 재연결·갱신하거나 테스트 폐기 |
출시 판단까지 이어지는 검증 — 핵심 흐름을 검증하고 실행 결과와 남은 조건을 출시 판단의 근거로 연결합니다.
링크가 있다는 것과 믿을 수 있다는 것은 다르다
링크 상태를 참·거짓 하나로 관리하면 참으로 표시된 낡은 링크가 정상 연결처럼 보입니다. 최소한 세 상태를 나누는 편이 낫습니다.
다음 중 하나가 벌어지면 링크를 낡은 상태로 옮깁니다. 요구사항이 새 버전으로 대체됐을 때입니다. 테스트의 조건과 데이터, 기대 결과가 수정됐을 때입니다. 구현 산출물의 리비전이 바뀌었을 때입니다. 연결 대상이 폐기 또는 삭제됐을 때입니다. 현재 변경 패키지가 링크의 끝점을 영향 대상으로 지목했지만 링크 재검토가 끝나지 않았을 때입니다. 새 베이스라인이 만들어졌지만 그 베이스라인에서 해당 링크가 검토되지 않았을 때입니다.
낡음을 날짜만으로 판단할 필요는 없습니다. 여섯 달 전에 만들어졌어도 양쪽 객체가 그대로이고 현재 베이스라인에서 다시 검토됐다면 유효합니다. 반대로 어제 만든 링크도 오늘 요구사항이 대체됐다면 낡은 링크입니다. 링크 기록 하나에는 link_id와 from, type, to, 생성 정보, 최신성 상태, 검토 시점과 검토자, 검토 맥락, 양 끝점의 버전, 낡음 사유 정도면 충분합니다.
- present
- present는 양쪽 객체와 링크 유형이 존재하는 상태입니다. 증거는 from과 type, to, 생성 시점입니다.
- reviewed
- reviewed는 현재 변경 또는 베이스라인에서 양쪽 버전과 관계의 의미를 검토한 상태입니다. 증거는 양 끝점의 버전과 reviewed_at, reviewed_by, review_context입니다.
- stale
- stale은 링크가 가리키는 객체나 검토 맥락이 바뀌어 현재 상태를 설명하지 못하는 상태입니다. 증거는 stale_reason과 바뀐 끝점, 마지막 검토 맥락입니다.
추적 커버리지와 테스트 통과율은 무엇이 다른가
추적 커버리지는 구조의 완전성을 봅니다. 테스트 통과율은 특정 실행의 결과를 봅니다. 검토 완료 추적 커버리지는 검증 가능한 변경 요구사항 가운데 reviewed 상태의 verifies 링크가 하나 이상 있는 요구사항의 비율입니다. 테스트 통과율은 이번 실행에서 수행한 테스트 가운데 통과한 실행의 비율입니다.
검증 가능한 변경 요구사항이 10개이고 검토 완료된 테스트 링크가 있는 요구사항이 8개라면 추적 커버리지는 80%입니다. 한편 테스트 20개를 실행해 18개가 통과했다면 통과율은 90%입니다. 90%라는 통과율은 연결되지 않은 두 요구사항을 설명하지 못합니다. 반대로 추적 커버리지가 100%여도 테스트가 실행됐거나 통과했다는 뜻은 아닙니다. 링크 하나가 그 요구를 충분히 검증하는지도 따로 검토할 일입니다.
작은 팀은 무엇부터 시작하면 되나
처음부터 전용 요구사항 관리 플랫폼을 들일 필요는 없습니다. NASA Software Engineering Handbook도 소규모 프로젝트에서는 스프레드시트나 경량 매트릭스로 요구사항과 테스트, 변경을 관리하도록 안내합니다.[3] 중요한 것은 도구보다 고유 식별자와 버전, 관계, 유지 책임입니다.
최소 구현은 여섯 단계입니다. 먼저 객체 식별자를 고정합니다 — 요구사항은 REQ-, 변경은 CHG-, 테스트는 TC-, 결함은 DEF-처럼 도구가 바뀌어도 살아남는 형태를 씁니다. 다음으로 객체와 링크를 나눕니다. 요구사항 행 안에 테스트 식별자를 문자열로 계속 붙이는 대신 from-type-to 형태의 링크 표를 따로 둡니다. 승인된 변경마다 변경 패키지를 하나씩 엽니다. 규모가 작다면 이슈 템플릿이나 YAML 파일 한 개여도 됩니다. PR과 테스트, 결함에 관련 식별자를 남겨 실제 작업 위치에서도 요구와 변경을 찾게 합니다. 존재하지 않는 식별자, 허용되지 않은 객체 유형 조합, 변경된 요구의 테스트 링크 누락, 폐기된 요구를 가리키는 테스트를 보는 간단한 자동 검사를 붙입니다. 마지막으로 재검토 주기를 날짜가 아니라 사건에 맞춥니다. 요구사항 변경과 테스트 리비전 변경, 변경 패키지 종료, 베이스라인 생성이 검토를 부르는 사건입니다.
여러 역할을 한 사람이 맡아도 됩니다. 다만 owner와 reviewer, reviewed_at 필드는 없애지 않는 편이 좋습니다. 역할이 같은 사람에게 몰려 있더라도 어떤 책임으로 무엇을 확인했는지는 남아야 합니다.
도구에 매이지 않는 최소 등록부
등록부 하나는 네 블록으로 충분합니다. 첫째는 베이스라인입니다. 식별자와 요구 집합 리비전, 구현 리비전, 테스트 카탈로그 리비전, 생성 시점을 담습니다. 둘째는 객체 목록입니다. 대체된 요구와 현재 요구, 변경, 구현 산출물, 테스트, 결함에 각각 유형과 상태, 소유자를 붙입니다. 셋째는 링크 목록입니다. from과 type, to에 최신성 상태와 검토 맥락을 함께 적습니다. 넷째는 변경 패키지입니다. 대상 변경과 대상 베이스라인, 영향 객체별 처리 결과와 근거, 고아 검사 결과, 최신성 집계, 검토자와 검토 시점을 담습니다.
실제 저장소에서는 객체 정보가 각 업무 도구에 남아 있어도 됩니다. 이 파일은 모든 원문을 복제하는 데이터베이스가 아니라 객체 식별자와 링크 기록을 잇는 최소 등록부로 쓰면 됩니다.
추적성이 끝내 내놓는 것은 무엇인가
잘 설계된 추적성은 요구사항마다 테스트 식별자가 하나씩 들어 있는 표보다 많은 것을 보여 줍니다. 어떤 변경이 발생했는가. 어떤 구현과 테스트, 결함이 영향 후보로 발견됐는가. 각 후보를 수정·유지·폐기·영향 없음으로 판단한 근거는 무엇인가. 연결되지 않은 객체는 무엇인가. 존재하지만 이번 변경에서 다시 검토되지 않은 링크는 무엇인가. 어느 요구와 구현, 테스트 버전 위에서 이 결과를 재현하는가입니다.
여기까지 확인하면 팀은 변경 때문에 살펴봐야 할 범위를 설명합니다. 그 후보 가운데 어떤 회귀 테스트를 실제로 실행할지는 별도의 선택 규칙이 정합니다. 추적성만으로 출시 여부가 결정되지도 않습니다. 추적성은 출시 판단에 필요한 증거 가운데 변경 영향과 검증 연결의 구조를 맡습니다.
