49장. 추적 관계 구축

요구·설계·시험·변경 사이의 관계 유형·방향·버전을 기록해 필요성·충족·영향 질문에 답할 추적망을 만든다.

학습 목표

“프로젝트 산출물 사이에 변경 영향까지 설명하는 추적 관계를 어떻게 구축하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

추적성은 산출물 사이에 링크를 많이 붙이는 작업이 아니다. 필요에서 요구, 설계와 시험으로 내려가며 무엇이 실현되고 무엇이 빠졌는지 설명할 수 있어야 하고, 변경이 생기면 영향을 받는 관계를 반대 방향으로도 찾을 수 있어야 한다.

이 장에서는 종합 사례의 요구·설계·시험·변경 항목을 관계 유형과 방향, 버전을 갖춘 추적망으로 연결한다. 필요성·충족·검증·영향 질문에 실제로 답할 수 있는지 점검하며, 과도한 연결을 피하고 의사결정에 필요한 추적 범위를 정한다.

‘추적 관계 구축’ 장의 핵심 상황과 역할을 보여 주는 손그림 — ‘추적 관계 구축’에서 먼저 확인해야 할 문제와 판단 기준.

추적의 입력은 안정된 식별자와 상태가 있는 산출물이다. 먼저 목표 G-01, 업무 목표 BR-001과 요구 UR-001, SR-001, FR-001–FR-005, QR-001–QR-011, DR-001–DR-006, IR-001–IR-006을 가져온다. 여기에 규칙과 미결 항목, 48장의 기능·흐름·화면·API·데이터·컴포넌트·ADR·시험 후보를 연결한다. 이름이 비슷하다는 이유로 새 ID를 만들지 않고 기존 관리 키를 사용한다. 하나의 개념을 여러 번호로 부르면 변경할 때 일부 연결만 갱신되어 정보가 갈라진다.

먼저 추적 질문을 정한다. “어떤 문서가 연결됐는가?”보다 다음 질문이 실제 의사결정에 유용하다.

G-01과 UR-001은 어떤 요구와 사용자 접점에서 실현되는가?
FR-003의 상태·사유·다음 행동은 어느 기능·화면·계약·공식 데이터·시험에 할당됐는가?
API-RULE-01의 시간 초과 계약은 어느 안전 요구에서 나왔는가?
DATA-DECISION-01의 규칙 버전과 공개 사유는 어떤 판정 재현·사용자 결과를 지원하는가?
TC-CAP-001-01은 미정인 승자 정책을 시험하지 않으면서 어떤 불변조건을 검증하는가?
CR-003이 바뀌면 직접 수정, 재확인, 통지, 영향 없음과 판단 보류를 어떻게 구분하는가?

이 질문에 맞춰 관계 유형을 제한한다. 모든 연결을 관련 있음으로 저장하면 영향 분석에서 어느 방향으로, 어느 정도 전파해야 하는지 알 수 없다.

관계 유형	방향과 의미	사례	검토 질문
`derivesFrom`	하위 필요·요구가 상위 근거에서 도출됨	`FR-003→UR-001`	상위 목적과 범위를 보존하는가?
`decomposes`	상위 책임을 독립 하위 책임으로 분해	`SR-001→FR-001–FR-005`	하위 합이 상위의 정상·예외를 덮는가?
`dependsOn`	충족에 다른 데이터·계약·조건이 필요	`FR-001→IR-003·IR-004`	실패·대체 경로가 있는가?
`constrains`	품질·정책이 가능한 해결책을 제한	`QR-003→FEAT-ENROLL-01`	완화하면 어떤 안전 조건이 깨지는가?
`satisfies`	설계 요소가 요구의 일부 또는 전부를 실현	`SCR-STATUS-01→FR-003`	어느 책임을 얼마나 실현하는가?
`verifies`	시험·분석·검사가 요구 준수를 확인	`TC-FR-003-01→FR-003`	오라클·환경·버전이 맞는가?
`validates`	시나리오·사용자 확인이 실제 필요 적합성을 확인	`VAL-SCN-01→IR-001`	사용·운영 맥락을 확인하는가?
`conflictsWith`	두 조건이 동시에 충족되지 않거나 해석이 충돌	`RULE-004↔RULE-005`, 쟁점 `ISS-001`	결정권자·대안·해소 조건이 있는가?
`supersedes`	새 버전·항목이 이전 것을 대체	통합된 분석 카드 → `ADR-ENR-001`	과거 사용처와 전환 시점을 보존했는가?

관계 하나에는 출발 ID와 버전, 관계 유형, 도착 ID와 버전 또는 안정적인 참조 정보, 등록 근거, 소유자, 상태와 마지막 확인 시점을 둔다. FR-003v0.9 satisfiesSCR-STATUS-01처럼 방향을 문법에 맞지 않게 쓰지 않는다. 설계가 요구를 충족하므로 SCR-STATUS-01satisfiesFR-003이라고 기록하고, 화면은 상태 표현 부분만 담당한다는 기여 범위를 붙인다. API와 데이터가 공식 상태·사유·갱신 정보를 함께 담당하므로 화면 하나를 완전 충족으로 표시하지 않는다.

대표 전방 경로는 상위 필요에서 시작한다.

방향과 관계 유형을 구분한 상태 조회 요구의 양방향 추적망의 관계를 손그림으로 표현한 이미지 — 방향과 관계 유형을 구분한 상태 조회 요구의 양방향 추적망.

요청된 핵심 사슬은 FR-003→FEAT-STATUS-01→FLOW-ENR-01→SCR-STATUS-01→API-STATUS-01→DATA-DECISION-01→TC-FR-003-01이다. 각 화살표의 의미는 같지 않다. FEAT-STATUS-01은 FR-003을 기능 책임으로 할당하고, FLOW-ENR-01은 그 책임이 접수·보류·승인·거절·취소의 시간 순서에서 나타나는 위치를 제공한다. SCR-STATUS-01은 사용자 접점을, API-STATUS-01은 공식 상태 조회 계약을, DATA-DECISION-01은 판정 근거와 상태 재현을 맡는다. TC-FR-003-01은 이 조합이 본인 상태·공개 사유·갱신 시각·다음 행동을 제공하는지 검증할 시험 항목이다.

전방 경로를 읽을 때는 끝에 시험 ID가 있다는 사실보다 의미가 보존되는지 확인한다. TC-FR-003-01이라는 이름만 연결하고 실제 기대 결과가 상태 코드 하나뿐이면 공개 사유, 본인 인가, 갱신 시각과 다음 행동이 빠진다. SCR-STATUS-01이 승인과 접수를 같은 “완료”로 표시하면 연결은 존재해도 요구를 잘못 실현한다. API-STATUS-01이 알림 전달 성공을 공식 상태로 반환하면 IR-005와 충돌한다. 링크 완전성과 내용 정확성은 별도 검사다.

같은 사슬을 후방으로 읽으면 각 하위 항목의 존재 이유를 묻는다.

예를 들어 API-STATUS-01에 rankingScore 필드가 있다는 가상의 변경을 후방으로 따라가면 FR-003의 공개 사유 요구만으로는 그 노출을 정당화할 수 없다. 그것이 RULE-005의 내부 계산값이라면 정책 악용·공정성·개인정보 위험이 생길 수 있다. 승인된 공개 요구와 목적이 없으면 삭제 또는 보류해야 한다. 반대로 운영 장애 분석에 필요한 상관 ID가 현재 요구에 없다면 즉시 숨은 기능으로 구현하지 않고 보안·개인정보·지원 목적을 갖춘 요구 후보로 되돌려 검토한다.

후방 판정은 세 갈래로 남긴다. 첫째, 상위 요구를 실현하기 위한 정당한 설계 파생이며 대안·근거가 있는 항목이다. 둘째, 설계나 운영 분석에서 새 필요가 발견돼 요구 후보로 승격해야 하는 항목이다. 셋째, 상위 근거도 필수성도 없는 금도금·오래된 항목으로 제거 또는 보류할 대상이다. 기술이 이미 존재한다는 이유만으로 상위 필요가 생기지는 않는다.

요구-설계 추적은 목적별 작은 보기로 나눈다. 하나의 거대한 표는 빈칸과 관계 유형을 숨기기 쉽다.

2. 요구와 설계의 추적 보기를 만든다

‘요구와 설계의 추적 보기를 만든다’의 핵심 관계를 설명하는 손그림 — 요구와 설계의 추적 보기를 만든다: 핵심 대상과 판단 근거.

요구	기능·흐름	사용자 접점	계약·책임	데이터	상태·검토점
`FR-001`	`FEAT-ELIGIBILITY-01`, `FEAT-ENROLL-01`	결과는 `SCR-STATUS-01`	`API-RULE-01`, `CMP-RULE-01`, `CMP-ENROLL-01`	`DATA-DECISION-01`	규칙 출처·`ISS-001` 미해결
`FR-002`	`FEAT-ENROLL-01`, `FLOW-ENR-01`	`SCR-REVIEW-01`	`API-ENROLL-01`, `CMP-ENROLL-01`	`DATA-APPLICATION-01`	접수는 승인 아님
`FR-003`	`FEAT-STATUS-01`, `FLOW-ENR-01`	`SCR-STATUS-01`	`API-STATUS-01`, `CMP-STATUS-01`	`DATA-DECISION-01`	공개 범위·성능 환경 미해결
`FR-004`	`FEAT-ENROLL-01`, `FEAT-STATUS-01`	중복 제출 피드백	`API-ENROLL-01`, `CMP-ENROLL-01`	요청 ID·상태 이력	동일성 창 미정
`FR-005`	`FEAT-CANCEL-01`, `FLOW-ENR-01`	`SCR-CANCEL-01`, `SCR-STATUS-01`	`API-CANCEL-01`, `CMP-ENROLL-01`	신청·판정 이력	허용 상태·시점 미정
`IR-001`	자격·운영 흐름	`SCR-STATUS-01`의 처리 보류	`API-RULE-01`, `CMP-RULE-01`, `CMP-OPERATE-01`	원인·판정 이력	종료·좌석 정책 미해결

시험 추적은 설계 존재가 아니라 요구 충족 증거를 연결한다.

요구·위험	시험 후보	핵심 조건	현재 판정 가능한 오라클	아직 판정할 수 없는 것
`FR-001`, `RULE-001`	`TC-RULE-001-01`	선수 조건 충족·미충족·경계	유효 규칙 결과와 사유 기록	실제 예외·원문 정확성
`QR-003`, `RULE-004`, `RULE-005`	`TC-CAP-001-01`	마지막 좌석 동시 신청	정원 초과·중복된 승인·좌석 반영 없음	미정 우선 정책의 승자
`IR-001`, `DR-001`	`TC-IR-001-01`	실패·무효·시간 초과·늦은 응답	자동 승인 없음, 원인 보류·이력	최대 보류 시간
`FR-004`	`TC-DUP-001-01`	같은 의도 반복·응답 유실	기존 신청 연결, 중복 처리 없음	동일성 보존 기간
`FR-005`	`TC-CAN-001-01`	판정 중 취소·늦은 승인	더 새로운 유효 상태 보존	모든 취소 허용 정책
`QR-001`, `FR-003`	`PT-STATUS-001`	합의된 피크 환경	응답시간·오류·권한·신선도	환경 전 p95 합격 선언

시험 후보는 실행 결과가 아니다. 현재 사례에는 구현·시험 환경·실행 증거가 없으므로 모두 설계 후보 상태다. TC-CAP-001-01에 예상 승자를 임의로 적지 않고 정원 초과 0과 복수 승인 효과 0만 잠정 오라클로 둔다. VAL-SCN-01은 처리 보류가 학생과 운영 목적에 맞는지 확인하는 시나리오이고, TC-IR-001-01은 명시한 실패 반응을 구현이 지키는지 검증하는 시험이다. 검증과 확인을 한 관계로 합치지 않는다.

추적 품질 검사는 네 종류의 결함을 찾는다. 첫째는 상위 출처가 없는 고아 요구다. 둘째는 승인되거나 구현 대상으로 간주됐지만 하위 설계·검증 책임이 없는 미할당 요구다. 셋째는 요구 근거가 없는 설계·필드·시험이다. 넷째는 대상은 맞지만 유형·방향·버전·기여 범위가 틀린 관계다. 자동 도구가 존재하지 않는 ID와 구문을 찾을 수는 있지만 “이 화면이 요구를 충분히 실현하는가”는 내용 검토가 필요하다.

TRC-ENR-01 v0.1의 표본 점검 결과는 다음과 같다.

점검	결과 후보	조치
안정된 요구 ID 사용	`FR-001–FR-005`로 일관	별칭이 기준 ID를 대체하지 않게 검사
대표 상태 조회 사슬	위·아래 방향 모두 탐색 가능	`FR-003` 의미별 기여 범위 기록
보류 실패 경로	`IR-001→API-RULE-01→TC-IR-001-01` 연결	`DEF-001`, `ASM-003`은 미결 유지
좌석 경합 경로	`RULE-004`, `RULE-005`, `QR-003`, `TC-CAP-001-01` 연결	승자 오라클은 `ISS-001` 해소 전 차단
설계 결정 연결	`ADR-ENR-001`에 요구·재검토 조건 있음	이전 분석 카드의 통합 관계 보존
실제 실행 증거	없음	시험 통과·기준선 완료로 표시 금지

다음의 이중 ID 체계는 모든 프로젝트에 필요한 규칙이 아니라, 이미 별도 변경 대장이나 배포 작업표를 운영하는 조직에서 선택할 수 있는 도구 사례다. 단일 추적 저장소로 충분하다면 정식 ID와 대상 버전, 작업 상태만 사용하거나 CR-003-T01 같은 변경 요청 하위 작업 ID로 단순화한다. 두 체계를 사용해야 하는 환경에서는 의미를 나타내는 정식 ID와 프로젝트 전달 과정의 일련번호가 함께 존재할 수 있다. 예를 들어 정식 요구 ID는 FR-001, 화면은 SCR-STATUS-01, API는 API-RULE-01처럼 개념과 책임을 안정적으로 가리킨다. 한편 변경 영향 대장이나 배포 작업표는 접수 순서 때문에 REQ-014, SCR-007, API-012, TC-032 같은 숫자 ID를 사용할 수 있다. 두 체계를 합치거나 하나가 다른 하나를 대체하게 하면 안 된다.

숫자 ID는 특정 변경 묶음에서 수행할 작업을 가리키는 변경 대장 키이고, 정식 ID는 여러 변경과 버전에 걸쳐 의미를 유지하는 의미 키다. 따라서 REQ-014에는 어느 정식 요구의 어느 버전에 어떤 차이를 제안하는지, SCR-007에는 어느 화면 후보의 다음 버전을 수정하는지, API-012와 TC-032에는 각각 어떤 계약·시험군을 바꾸거나 재실행하는지 매핑한다. 숫자 경로만 보고 정식 요구를 새로 만들거나 기존 의미를 덮지 않는다. 다음 장에서는 이 원칙으로 CR-003의 조건부 영향 경로를 구성한다.

관계 레코드의 예를 보면 저장 규칙이 분명해진다.

출발	관계	도착	기여·근거	소유자 후보	상태
`FR-003` `v0.9`	`derivesFrom`	`UR-001` `v0.9`	자신의 결과·사유 확인을 시스템 반응으로 구체화	요구 책임자	검토 후보
`SCR-STATUS-01` `v0.1`	`satisfies`	`FR-003` `v0.9`	상태·사유·갱신·다음 행동의 사용자 표현	UX 책임자	검토 후보
`API-STATUS-01` `v0.1`	`satisfies`	`FR-003` `v0.9`	본인의 공식 상태 조회 계약	설계 책임자	검토 후보
`DATA-DECISION-01` `v0.1`	`satisfies`	`DR-001` `v0.9`	결과·사유·규칙 버전·상태 이력 근거	데이터 책임자	`ASM-002` 조건부
`TC-FR-003-01` `v0.1`	`verifies`	`FR-003` `v0.9`	정상·보류·거절·인가·갱신 정보 확인	시험 책임자	미실행
`VAL-SCN-01` `v0.1`	`validates`	`IR-001` `v0.9`	보류의 이해·운영 회복 적합성 확인	요구·운영 책임자	실제 참여자 확인 전

버전을 빠뜨리면 과거 증거가 새 요구에 자동 승계된다. FR-003의 공개 사유 범위가 바뀌었다면 이전 시험 결과가 여전히 유효한지 차이를 평가해야 한다. 설계 ID를 그대로 유지하더라도 내용 버전과 기준선 소속을 기록한다. 폐기된 버전으로 가는 링크는 삭제하기보다 superseded 상태와 대체 대상을 남겨 당시 결정과 결함을 재현할 수 있게 한다.

추적 갱신은 별도 정리 작업이 아니라 산출물 변경의 완료 조건에 포함한다. 요구 작성자는 상위 출처·같은 계층의 요구·미결 관계를, 설계 책임자는 satisfies와 ADR 근거를, 시험 책임자는 verifies와 실행 버전·결과를, 변경 책임자는 영향 판정과 기준선 차이를 등록한다. 요구 관리 책임자는 모든 링크를 대신 입력하는 사람이 아니라 관계 규칙, 품질 검사, 검토 주기와 예외를 관리한다.

갱신 사건도 미리 정한다. 요구의 상태·버전 변경, 설계 대안 선택, 화면·API·데이터 계약 수정, 시험 오라클 변경, 가정 확인·반증, 쟁점 해결, 변경 요청 결정과 기준선 배포가 일어나면 연결을 재검토한다. 임시 링크에는 만료 조건과 책임자를 둔다. 파일을 옮기거나 제목을 바꿨다고 안정 ID가 바뀌지는 않지만, 의미가 바뀌면 같은 ID의 새 버전으로 관리하고 영향 평가를 수행한다.

지표는 품질을 대신하는 점수가 아니라 검사 신호다. 상위 근거가 없는 요구 수, 하위 실현이 없는 고위험 요구 수, 검증 방법이 없는 수용 조건 수, 근거 없는 설계·시험 수, 존재하지 않는 대상과 과거 버전을 가리키는 링크 수, 변경 후 미갱신 경과시간을 본다. 추적 링크 연결률 100%를 맞추려고 빈칸에 아무 관계나 추가하면 오히려 잘못된 영향 경로가 늘어난다. 표본 사슬을 사람이 끝까지 따라가 의미와 오라클을 확인해야 한다.

TRC-ENR-01 v0.1의 검토 게이트는 다음과 같다. 안정 ID와 버전이 있는가, 관계 유형과 방향이 맞는가, 상위에서 설계·시험까지 내려가는가, 하위에서 근거와 목표로 올라가는가, 미결 정책이 완료된 링크로 보이지 않는가, 실제 실행하지 않은 시험이 증거로 표시되지 않는가, 변경 대장 ID와 의미 ID의 매핑이 있는가, 소유자와 갱신 사건이 정해졌는가를 본다. 자동 검사는 존재·구문·버전 참조를, 사람 검토는 의미·충족 범위·오라클을 맡는다.

이번 장의 출력은 관계 모델, 대표 전방·후방 사슬, 요구-설계와 요구-시험 보기, 결함 목록, ID 매핑 원칙과 갱신 책임이다. 추적 책임자는 관계 품질을 관리하고, 요구·설계·시험 책임자는 자신이 만든 산출물의 관계를 검토한다. 정책 소유자는 미결 규칙의 정확성만 결정하며 도구의 링크 수가 승인을 대신하지 않는다. 현재 결과는 후보 추적망이므로 실제 기준선 완료를 뜻하지 않는다.

다음 장에는 이 추적망과 CR-003을 넘긴다. 변경 요청을 받은 뒤 곧바로 요구·화면·API·시험을 고치는 것이 아니라, 먼저 현재 기준선과 제안 차이, 공식 자료와 승인 조건을 확인한다. 실제 경로는 증거 부족 때문에 보류될 수 있고, 교육을 위한 조건부 시뮬레이션은 그 상태와 분리해야 한다. 추적의 목적은 많은 수정 대상을 나열하는 것이 아니라 무엇을 왜 바꾸거나 재확인하고, 무엇은 바꾸지 않는지 결정할 수 있게 하는 데 있다.

2. 근거와 예외 표시

본문의 판단 질문으로 누락된 근거와 예외를 표시한다.

3. 다음 행동 기록

확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.

49장. 추적 관계 구축

이번 장에서 해결할 질문

학습 목표

핵심 개념

1. 추적 목적과 관계를 정한다

2. 요구와 설계의 추적 보기를 만든다

3. 변경 분석에 쓸 추적망을 넘긴다

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로