156. 요구사항 추적성 (Traceability) - 수직적/수평적 추적성

핵심 인사이트 (3줄 요약)

본질: 요구사항 추적성(Traceability)은 요구사항이 어디서 왔는지(원천), 그리고 개발 단계(설계 ➔ 코딩 ➔ 테스트)를 거치며 어떻게 물리적 산출물로 구체화되어 뻗어 나갔는지를 양방향으로 1:1 매핑하여 추적할 수 있는 꼬리표(ID) 시스템이다.

가치: 프로젝트 막바지에 고객이 "신용카드 결제 로직 싹 다 갈아엎어!"라고 변심했을 때, 개발자가 수만 줄의 소스코드를 쌩눈으로 다 뒤지는 재앙을 막고 "어느 설계도와 어느 자바 클래스와 어느 테스트 코드를 고쳐야 하는지" 단숨에 영향도(Impact Analysis)를 뽑아내어 리스크를 틀어막는다.

융합: 과거 엑셀(RTM)에 손으로 화살표를 그리던 노동을 넘어, 현대에는 JIRA(요구사항/에픽 티켓) ➔ Confluence(설계도) ➔ Github Commit(코드) ➔ Jenkins/JUnit(테스트) 파이프라인이 하나의 **디지털 스레드(Digital Thread)**로 자동 연결되는 ALM 툴 체인 아키텍처로 융합 폭발했다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 추적성(Traceability)은 소프트웨어 수명 주기(SDLC) 내에서 생성되는 모든 산출물(문서, 코드, 테스트 케이스) 간의 논리적 연관성을 수립하는 것이다. 고객의 입에서 나온 말 한마디(요구사항)가 최종 소프트웨어에 누락 없이 반영되었는지, 반대로 쓸데없이 구현된 코드 조각(Gold-plating)은 없는지 감시하는 내비게이션이다.
필요성: 차세대 은행 시스템 프로젝트 오픈 전날. 테스터가 헐레벌떡 뛰어온다. "버그 났어요! 비밀번호 3번 틀리면 계정이 잠겨야 하는데 안 잠겨요!" 개발팀장이 소리친다. "야, 그 코드 누가 짰어? DB 테이블은 어디 있어? 테스트 시나리오는 애초에 있었어?" 100명의 개발자가 서로 얼굴만 쳐다본다. 문서 수백 장과 소스 코드 수십만 줄이 어디서 어떻게 연결되어 있는지 아무도 모른다. 요구사항 1개가 시스템의 핏줄을 타고 어디로 흘러갔는지(Forward), 이 수상한 코드는 도대체 누구의 요구로 짠 건지(Backward) 역학 조사(역학 추적)를 10분 만에 끝내지 못하면 유지보수와 기능 변경은 지옥의 철야 작업으로 직행한다. 거대한 복잡성을 통제할 '바코드 꼬리표'가 절실했다.
💡 비유: 추적성은 대형 병원의 '환자 팔찌(바코드)' 시스템과 같습니다. "홍길동"이라는 환자(요구사항)가 입원하면 손목에 팔찌(ID)를 채웁니다. 그가 피검사(설계)를 하든, 수술(코딩)을 하든, 약을 타든(테스트) 모든 차트와 엑스레이 필름에 그 바코드 번호가 찍힙니다. 만약 나중에 문제가 생기면, 의사는 그 바코드 하나만 띡 찍어서 홍길동이 어느 병실에 있었고, 무슨 약을 먹었고, 누가 수술했는지 한 큐에 완벽한 동선을 쫙 뽑아낼 수 있습니다.
등장 배경:
1. 소프트웨어의 거대화와 인력 파편화: 기획자, 아키텍트, 백엔드 개발자, QA 테스터가 각자의 부서에서 사일로(Silo)를 치고 일하면서 산출물 간의 연결 고리가 끊어지는 대참사가 일상화되었다.
2. CMMI 및 ISO 인증의 강제화: 미국 국방부 같은 거대 기관이 "추적표(RTM) 없이는 너희 소프트웨어를 믿고 사지 않겠다"며 공학 품질 관리의 0순위 증빙 자료로 강제 채택했다.

┌─────────────────────────────────────────────────────────────┐
│          추적성의 양방향(수직적/수평적) 아키텍처 생태계 맵 (Map)          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ 1️⃣ [ 수직적 (Vertical) 추적성 - 생명주기(SDLC)를 관통하는 파급력 ]  │
│                                                             │
│   (Backward 역추적) ◀────────────────────────▶ (Forward 정추적)│
│                                                             │
│  [고객의 요구] ➔ [SRS 명세서] ➔ [설계도/DB] ➔ [소스코드] ➔ [테스트]  │
│  "카드결제해줘" ➔ REQ-PAY-01 ➔ UML_PAY_01 ➔ Pay.java ➔ TC-005  │
│                                                             │
│  🌟 정추적 (가시성): REQ-PAY-01이 끝까지 누락 없이 구현/테스트되었나?    │
│  🌟 역추적 (정당성): Pay.java라는 코드는 도대체 왜 짠 건가? (근원 파악)    │
│                                                             │
│                                                             │
│ 2️⃣ [ 수평적 (Horizontal) 추적성 - 같은 단계 안에서의 얽힘과 충돌 ]  │
│                                                             │
│  [ REQ-PAY-01 (결제 기능) ] ◀─ (충돌) ─▶ [ REQ-SEC-05 (보안 암호화) ] │
│   - "결제 로직은 무조건 1초 이내에 끝나야 한다."                     │
│   - "결제 데이터는 10번 암호화해서 무겁게 처리해야 한다."                │
│                                                             │
│  🌟 아키텍트 판단: 추적성은 단순히 앞뒤(수직)만 잇는 게 아니다. 옆에 있는    │
│     요구사항끼리 서로 논리적 모순(Conflict)을 일으키는지 거미줄(수평)을 쳐서 │
│     스펙 간의 종속성과 충돌을 관리하는 극강의 의존성(Dependency) 매핑이다.│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 기술사 시험에서 단골로 묻는 수직(Vertical)과 수평(Horizontal)의 차이다. 수직적 추적성은 폭포수 계단을 타고 내려가거나 올라가는 '시간/산출물'의 핏줄이다. 무언가 바뀌었을 때 파도타기(Ripple Effect)를 계산하는 데 쓴다. 수평적 추적성은 같은 명세서(문서 1장) 안에서 1번 요구사항과 5번 요구사항이 서로 어떤 관계를 맺고 있는지 따지는 '공간/논리'의 핏줄이다. 결제 버튼(1번)을 누르면 반드시 재고 차감(5번)이 실행되어야 한다는 의존성을 묶어두어, 나중에 하나를 삭제할 때 남은 하나가 고아(Orphan)가 되어 시스템이 붕괴하는 것을 막는 방어 기제다.

📢 섹션 요약 비유: 수직적 추적성은 조상의 족보를 캐는 것입니다. "내(소스코드)가 태어난 원인인 할아버지(고객 요구)는 누구지?"(역추적). 반대로 "우리 할아버지가 낳은 자손(테스트 코드)들이 안 죽고 다 살아있나?"(정추적)를 보는 겁니다. 수평적 추적성은 같은 동네(명세서)에 사는 이웃사촌 간의 관계입니다. "내가 이사를 가면 옆집(연관 요구사항) 담벼락이 무너지진 않을까?"를 미리 묶어두는 끈입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 요구사항 추적 매트릭스 (RTM: Requirements Traceability Matrix)

추적성을 눈에 보이게 물성화(Physicalize)한 절대적 산출물이 바로 RTM 엑셀표다.

RTM의 뼈대: 가장 좌측 열(Column)에 고유 ID(REQ-001)를 적고, 우측으로 갈수록 설계문서 ID, 소스코드 클래스명, 단위 테스트 ID, 인수 테스트(UAT) 결과를 한 줄로 쭉 매핑한다.
RTM의 3가지 무결점 증명:
1. 누락(Omission) 검출: REQ-005는 있는데 우측에 맵핑된 소스코드가 빈칸(NULL)이다! ➔ "아, 개발자가 까먹고 코딩 안 했구나!"
2. 잉여(Gold-plating) 검출: 클래스 파일은 있는데 좌측에 매핑된 REQ(요구사항) ID가 없다! ➔ "개발자가 고객이 시키지도 않은 쓸데없는 오지랖(기능)을 짜 넣었네. 당장 지워!"
3. 테스트 커버리지 100% 증명: 모든 REQ-ID 우측 끝에 '테스트 성공(Pass)' 딱지가 채워져 있으면, 감리사가 태클을 걸 수 없는 무적의 프로젝트 종료(Sign-off) 인증서가 완성된다.

2. Forward 추적 vs Backward 추적

방향성에 따라 용도가 완전히 다르다.

전방 추적 (Forward Traceability / 명세 ➔ 코드 ➔ 테스트)
- "이 요구사항이 진짜 시스템으로 잘 구워졌나?" (구현의 완전성 검증).
- 설계 누락 방지와, 고객이 "이거 다 만들었어?"라고 물어볼 때 진행률(Progress) 대시보드로 쓴다.
후방 추적 (Backward Traceability / 테스트 ➔ 코드 ➔ 명세)
- "이 코드나 테스트가 도대체 왜 존재하는 거지?" (산출물의 정당성 검증).
- 에러가 터졌을 때 버그의 근원지(원래 기획 의도)를 찾아 올라가거나, 쓸데없이 들어간 불필요한 예산 낭비(Over-engineering) 요소를 색출하여 가지치기할 때 쓴다.
📢 섹션 요약 비유: RTM은 거대한 **'택배 배송 추적 전광판'**입니다. 중국 공장(요구사항)에서 출발한 택배 상자 100개가 배(설계)를 타고, 트럭(코딩)을 타서, 우리 집 문 앞(테스트)까지 중간에 분실된 거 없이 100개 다 잘 도착했는지 한눈에 쫙 보여주는 완벽한 마스터 엑셀 장부입니다.

Ⅲ. 융합 비교 및 다각도 분석

딜레마: 엑셀(Manual) RTM의 유지보수 파국 (문서와 코드의 싱크 오차)

전통적 폭포수(Waterfall)의 가장 크고 치명적인 약점이다. RTM을 엑셀(Excel)로 사람이 손으로 치면 100% 파국을 맞는다.

아키텍처 환경	엑셀 수기 RTM의 붕괴 시나리오	해결을 위한 ALM 툴 체인(Tool-chain) 융합
코드 수정 시점	개발자가 밤새워 `Pay.java`를 `NewPay.java`로 파일명을 뜯어고침. 그런데 엑셀 RTM에 들어가서 파일명 고치는 걸 까먹음.	JIRA(티켓)와 Git(소스) API 연동. 코드를 커밋할 때 무조건 `[REQ-001] fixed` 라고 쓰면, Git이 JIRA를 찔러 자동으로 RTM 표가 갱신됨!
요구사항 팽창 (Scope Creep)	고객이 "이거 빼고 저거 넣어"라고 100번 변심함. RTM 엑셀표 관리하던 기획자 멘탈 터지고 업데이트 포기.	Confluence(위키) 페이지에서 기획을 뜯어고치면, 이와 연결된 하위 테스트 케이스(Zephyr)가 자동으로 붉은색(재검토 요망) 알림으로 바뀜.
품질 결론	문서(엑셀)와 진짜 시스템(코드)이 따로 놀아 RTM은 오픈 전날 밤새서 가짜로 써내는 쓰레기 페이퍼워크로 전락함.	추적성은 사람이 화살표를 긋는 게 아니라, 기계가 파이프라인에서 뿜어내는 메타데이터(Meta-data)로 자동 직조(Digital Thread)되어야 한다.

과목 융합 관점

테스트 및 품질 (QA - 테스트 주도 개발 TDD): 추적성의 가장 위대한 성과는 TDD와 융합될 때 터진다. TDD는 아예 테스트 코드의 이름 자체를 요구사항 명세로 지어버린다(예: test_UserShouldBeLockedAfter3Fails). 엑셀 RTM 표를 따로 만들 필요 없이, 1,000개의 테스트 코드가 매일 서버에서 윙 돌아가고 1,000개의 녹색 불(Pass)이 켜지는 것 자체가 "우리의 요구사항 1,000개가 소스코드와 100% 엮여서 완벽히 추적 및 검증되고 있다"는 '살아 숨 쉬는 RTM' 대시보드로 격상된다.
클라우드 및 마이크로서비스(MSA): 모놀리식 1통짜리 서버에선 엑셀 RTM이 가능했다. 하지만 지금은 기능 하나가 수백 개의 MSA 컨테이너(Docker) 조각으로 찢겨있다. 고객이 결제를 눌렀을 때, 이 트랜잭션이 어떤 서버들을 뚫고 지나갔는지 추적하려면, 더 이상 엑셀이 아니라 클라우드 아키텍처 단에 **분산 추적 시스템(Distributed Tracing - Zipkin, Jaeger)**을 깔고 요청마다 고유 ID(Trace ID)를 헤더에 쑤셔 넣어 모니터링해야 한다. 즉, 요구사항 추적성(문서)의 철학이 클라우드 트래픽 추적성(런타임) 인프라로 모양을 바꿔 완벽히 계승된 것이다.
📢 섹션 요약 비유: 엑셀로 만든 RTM은 '손으로 그린 보물 지도'입니다. 시간이 지나서 강이 마르고 산이 깎이면 지도는 엉터리가 되어 아무 짝에도 쓸모없어지죠. 현대의 JIRA+Git 연동 RTM은 **'GPS 실시간 내비게이션'**입니다. 도로가 막히거나 공사 중(코드 변경)이면 0.1초 만에 화면에서 경로(추적표)가 쫙 바뀌어서 절대 길을 잃지 않게 지켜줍니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 임팩트 분석(Impact Analysis) 실패로 인한 파도타기 버그 폭발: 대형 오픈마켓 시스템. 오픈 1주일 전 고객이 "배송비 계산 무료 쿠폰 로직을 추가해 줘"라고 변심(CR, Change Request)을 때렸다. 추적표(RTM)가 없던 개발팀은 대충 '결제 모듈'만 눈으로 찾아서 코드를 수정했다. 그런데 이 배송비 로직이 '환불/취소 모듈'과 '포인트 적립 모듈'에 교차로 연결(수평적 의존성)되어 있는 걸 몰랐다. 오픈 날 환불 금액이 마이너스로 찍히고 포인트가 무한 증식하는 핵폭탄이 터졌다.
- 판단: 추적성이 빛을 발하는 단 하나의 이유, **영향도 분석(Impact Analysis)**이 붕괴한 참사다. 만약 RTM이 잘 짜여 있었다면, 기획자는 고객의 말을 듣자마자 엑셀의 REQ-DELIVERY-01 줄을 찍었을 것이다. 그 줄을 따라가면 Payment.java, Refund.java, Point.java 라는 3개의 소스 코드가 걸려있음(Forward Traceability)을 1초 만에 뽑아낸다. "고객님, 배송비를 건드리면 환불과 포인트 모듈 2개도 같이 다시 짜고 테스트해야 하므로 일정 1주일 연기되고 추가금 3천만 원입니다"라고 당당하게 디펜스(방어)하고 견적서를 날릴 수 있는 무기가 바로 추적성이다.
시나리오 — 금감원 감리와 잉여 기능(Gold Plating) 적발: 은행 보안 시스템 감사가 떴다. 감리사가 소스 코드를 까보더니, 기획서(명세서)에는 없는 "특정 관리자 아이디로 로그인 시 비밀번호 2차 인증(OTP) 패스"라는 이상한 뒷문(백도어) 코드가 박혀있는 걸 발견했다. 개발자는 "아, 나중에 필요할까 봐 제가 센스 있게 편의 기능(Gold Plating)으로 짜넣은 건데요?"라고 해명했지만, 금감원은 악의적 백도어 혐의로 회사를 영업 정지시켰다.
- 판단: 개발자의 무지성 오지랖(Gold Plating)을 색출하는 **역추적(Backward Traceability)**의 위력이다. 감리사는 소스코드(Auth.java)를 잡고 왼쪽으로 역추적을 타고 올라갔다. 매핑된 설계도가 없고, 최상단의 요구사항 ID도 없었다(Orphan Code). 요구사항 명세서에 합의되지 않은 코드가 시스템에 들어가는 것은 보안과 유지보수의 최악의 쓰레기(리스크)다. 철저한 RTM 검문소를 세워두면, "족보(요구사항) 없는 코드 조각"은 운영 서버 빌드 파이프라인에서 즉시 적발되어 쓰레기통으로 소각 처리된다.

  ┌─────────────────────────────────────────────────────────────┐
  │         실무 아키텍처: 디지털 스레드(Digital Thread) 기반 ALM 자동 추적망   │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ 1️⃣ [ 기획팀: JIRA (요구사항 티켓) ]                            │
  │     [ISSUE-101] "카카오페이 결제 연동 추가" (Story)             │
  │          │                                                  │
  │          ▼ (Jira 티켓 번호를 가지치기해서 브랜치 생성)           │
  │                                                             │
  │ 2️⃣ [ 개발팀: Github (소스코드 버전관리) ]                      │
  │     - 브랜치명: `feature/ISSUE-101-kakaopay`                 │
  │     - 커밋 로그: `[ISSUE-101] Kakao API 호출 로직 추가`         │
  │          │ (Git이 Jira API를 찔러서 자동으로 진행률 상태 갱신!)  │
  │          ▼                                                  │
  │                                                             │
  │ 3️⃣ [ QA팀: Zephyr / Jenkins (자동화 테스트) ]                │
  │     - 테스트 케이스: `TC-KPay-01 (Linked to ISSUE-101)`      │
  │     - 밤새 Jenkins 빌드가 돌고, 결제 성공(Pass) 녹색 불이 뜸!      │
  │                                                             │
  │ 🌟 아키텍트의 예술 (단일 대시보드 뷰):                             │
  │ 사장님이 JIRA의 [ISSUE-101] 티켓 딱 1개만 열면, 화면에 엑셀 표(RTM) 대신  │
  │ "이 기획이 ➔ 어느 Github 코드 20줄로 짜였고 ➔ 오늘 새벽 테스트 100점 맞음"│
  │ 이라는 생명주기 전체의 파이프라인 핏줄(Traceability)이 0.1초 만에 증명된다!│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 워드 문서와 엑셀표에 화살표를 그리며 야근하던 1990년대 폭포수(Waterfall) 추적성 관리의 종말이다. 모던 소프트웨어 공학에서 추적성은 사람이 관리하는 행정 노동이 아니다. 서로 다른 이기종 SaaS 툴(Jira, Github, Jenkins)을 웹훅(Webhook)과 REST API로 엮어버린 툴 체인(Tool-chain) 생태계다. 개발자가 코드를 커밋할 때 이슈 티켓 번호(ISSUE-101) 하나만 타이핑해주면, 그 바코드 번호를 타고 기획-개발-테스트의 모든 데이터가 하나의 '디지털 스레드(가상의 실)'로 관통되어 영구적으로 묶여버리는, 인간의 실수를 원천 봉쇄하는 무결점 형상 관리 아키텍처다.

도입 체크리스트

기술적: 개발팀이 Github에 소스 코드를 Push 하거나 Pull Request(PR)를 날릴 때, 커밋 메시지 첫머리에 JIRA 티켓 번호(예: [REQ-55])를 적지 않으면 아예 Git 서버가 수신을 거부하고 튕겨내 버리는 **Git Pre-receive Hook 통제(Commit Message Linting)**가 커널 단에 강제 적용되어 있는가? 이 강제성이 없으면 추적성의 고리가 단 하루 만에 다 끊어져 버린다.
운영·보안적: RTM이 아무리 잘 짜여있어도, 그 원본인 요구사항 문서(SRS) 자체가 수시로 몰래 바뀌면 추적성은 무너진다. 요구사항 스펙이 고객과 합의되어 1차 고정되는 순간, 베이스라인(Baseline) 스냅샷 도장을 찍고 이후의 모든 스펙 변경(수정/삭제)은 철저한 **변경 통제 위원회(CCB)**의 결재를 거쳐야만 RTM 맵에 반영되도록 형상 관리 프로세스의 거버넌스(Governance) 락이 걸려 있는가?

안티패턴

과도한 추적성 집착 (Traceability Overhead): "추적성이 중요하대!"라며 흥분한 PM이, 버튼의 '픽셀 색깔 변경'이나 '오타 수정' 같은 10분짜리 자잘한 마이크로 태스크들까지 몽땅 요구사항 ID를 부여하고 RTM 엑셀표에 맵핑하라고 개발자들을 닦달하는 짓. 코딩하는 시간 10분에 문서 업데이트(행정 노동) 하는 시간이 50분이 걸리는 배보다 배꼽이 더 큰 재앙이 터진다. 추적성은 코어 비즈니스 로직과 컴플라이언스(보안/결제) 등 리스크가 높은 중요 기능에 대해서만 깐깐하게 적용하는 위험 기반(Risk-based) 테일러링(Tailoring) 완급 조절이 생명이다.
📢 섹션 요약 비유: 추적성 시스템은 복잡한 서버 뒷면의 '전선 이름표 묶기(케이블 타이)'와 같습니다. 선마다 "이 선은 마우스 선, 저 선은 키보드 선"이라고 꼼꼼히 이름표를 붙여둬야, 나중에 모니터가 고장 났을 때 어떤 선(영향도)을 뽑아서 고칠지 1초 만에 알 수 있습니다. 이름표 없이 그냥 100가닥을 쑤셔 넣어두면 고장 났을 때 선을 일일이 당겨보다가 멀쩡한 전원 선까지 뽑아버려서 서버 전체가 다 죽게 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	파편화된 문서/코드 관리 (Silo)	RTM / ALM 기반 추적성(Traceability) 확보	개선 효과
정량	고객 변심(요구 변경) 시 사이드 이펙트 버그 속출	영향도 분석(Impact Analysis)을 통한 정확한 격리 수정	요구사항 변경에 따른 아키텍처 붕괴 및 재작업 공수 80% 이상 사전 방어
정량	구현 안 하고 넘어간 기능 오픈 날 적발	Forward 추적을 통한 테스트 100% 커버리지 강제 검증	요구사항 누락 결함(Omission Bug) 제로(0)화 달성 및 인수 테스트 1차 통과
정성	"이 이상한 코드 누가 짰어?" 혼돈과 추궁	Backward 추적을 통한 오버엔지니어링/백도어 색출	소스 코드의 정당성 확보 및 잉여 산출물 제거를 통한 린(Lean) 엔지니어링 실현

미래 전망

AI 기반의 의미론적(Semantic) 자동 추적성 링크 생성: 지금까지는 인간이 Jira 티켓 번호와 커밋 번호를 억지로 손으로 타이핑해 묶어야 했다. 하지만 LLM(대형 언어 모델)이 소스 코드를 읽어버리는 시대가 오며 판이 뒤집혔다. 개발자가 그냥 코드를 짜면, AI가 코드를 분석해 "이 로직은 '장바구니 할인'을 위한 거네? 기획서 10페이지에 있는 3번 요구사항이랑 매핑시켜 줄게!"라며 인간 개입 없이 자동으로 거미줄 RTM 핏줄을 0.1초 만에 이어주는 소름 돋는 AI 자동 맵핑(Auto-traceability) 솔루션이 ALM 시장의 판도를 뒤흔들고 있다.
블록체인(Web3) 융합 불변성 감리(Immutable Audit): 우주 항공, 국방, 자율주행 의료 기기 등 사람 목숨이 달린 초고위험 소프트웨어는 추적성이 곧 법적 책임(감옥)과 직결된다. 이 RTM 매핑 데이터를 중앙 서버 DB에 두면 관리자가 몰래 조작할 수 있으므로, 요구사항-코드-테스트 통과 이력의 연결 사슬 자체를 블록체인 스마트 컨트랙트(Smart Contract) 원장에 박아버려, 해커와 감리기관조차 영원히 조작할 수 없는 절대적 무결성 추적(Immutable Traceability) 시스템으로 고도화되고 있다.

참고 표준

CMMI (Capability Maturity Model Integration): 기업 소프트웨어 개발 성숙도의 가장 기초적인 레벨 2를 통과하기 위한 절대 요건 중 하나가 바로 "요구사항과 하위 산출물 간의 양방향 추적성(Bidirectional Traceability)이 수립되어 있는가?"이다.
ISO/IEC 29148: 요구공학 프로세스 국제 표준. 요구사항의 고유 식별, 속성 관리, 형상 관리와의 연동 등 추적성 구축의 뼈대를 규정.

"보이지 않는 핏줄(Link)이, 보이는 살점(Code)보다 시스템을 더 강하게 지탱한다." 수백만 줄의 코드가 아름답게 돌아간다고 해도, 그 코드가 왜 그 자리에 존재해야 하는지 뿌리(근원)를 대답할 수 없다면 그 소프트웨어는 모래 위에 지은 웅장한 쓰레기일 뿐이다. 요구사항 추적성(Traceability)은 기획자의 아이디어라는 무형의 구름을, 코드라는 단단한 실리콘 블록에 쇠사슬로 묶어두는 가장 위대하고도 고통스러운 닻(Anchor)이다. 비록 끊임없이 ID 번호를 달고 엑셀(Jira)을 업데이트해야 하는 이 귀찮은 행정 노동에 수많은 개발자가 불평을 쏟아내지만, 런타임 서버가 붕괴하고 비즈니스 룰이 뒤집히는 아비규환의 밤이 왔을 때, 엔지니어들이 유일하게 믿고 멱살을 잡아당기며 생존의 탈출구를 찾아 올라갈 수 있는 구원의 아리아드네의 실타래, 그것이 바로 추적성이다.

📢 섹션 요약 비유: 추적성은 거대한 뜨개질 스웨터의 **'올(실가닥)'**입니다. 어느 날 사장님이 "어깨 쪽에 빨간 실(요구사항) 하나만 파란색으로 바꿔줘"라고 했을 때, 추적성이 없으면 가위로 스웨터를 다 찢어발기다(버그 폭발) 옷을 버리게 됩니다. 하지만 추적성(실가닥 동선)이 완벽히 짜여있으면, 딱 그 빨간 실의 끄트머리만 잡고 살살 당기면 다른 부분은 하나도 안 다치게 하면서 예쁘게 파란 실로 완벽히 바꿔 끼울 수 있는 정밀한 수정의 마법입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
RTM (요구사항 추적 매트릭스)	추적성의 영혼을 엑셀 표로 실체화한 도구. 좌측의 요구사항 번호가 우측의 설계도, 소스코드, 테스트 결과까지 빵꾸 없이 이어지는지 감시하는 척추다.
형상 관리 (Configuration Mgt)	1번 요구사항이 2번 요구사항으로 바뀌었을 때(버전 업), 옛날 RTM 사슬을 보존하면서 새로운 RTM 사슬을 병렬로 안전하게 통제해 주는 금고 시스템이다.
영향도 분석 (Impact Analysis)	추적성을 100% 빡세게 구축하는 단 1개의 이유. 고객이 변심했을 때 "아 이 기능 건드리면 저기 폭파되겠네요"라고 도미노 효과를 1초 만에 꿰뚫어 보는 통찰력.
ALM (애플리케이션 수명주기 관리)	낡은 워드/엑셀 기반의 수동 추적성을 부수고, Jira-Git-Jenkins를 API로 묶어 개발자가 코드만 치면 자동으로 핏줄이 연결되게 해주는 디지털 툴 체인 플랫폼.
TDD (테스트 주도 개발)	아예 테스트 코드 함수의 이름 자체를 요구사항 이름으로 박아버려서, 테스트가 성공(Pass)하는 순간 그것이 곧 요구사항 추적성 검증 100%를 증명하는 우아한 코딩 철학.

👶 어린이를 위한 3줄 비유 설명

공장에서 로봇 장난감을 만들 때, 사장님이 "빨간 버튼 1개, 로켓 주먹 1개 달아줘!"라고 주문서(요구사항)를 썼어요.
**추적성(Traceability)**은 그 주문서 글씨 옆에 고유한 '바코드 번호'를 딱 붙이고, 진짜 만들어진 빨간 버튼 부품과 로켓 주먹 부품에도 똑같은 바코드 스티커를 착착 붙여놓는 꼼꼼한 룰이에요.
나중에 "어? 로켓 주먹이 고장 났네?" 할 때, 부품의 바코드만 찍어보면 "아하! 이 주먹을 설계한 사람, 조립한 사람, 불량 검사한 사람"을 1초 만에 한 묶음으로 쫙 찾아내서 빨리 고칠 수 있게 해주는 엄청난 끈이랍니다!