요구사항 추적성 매트릭스(RTM)로 PRD 변경을 통제하는 법
가벼운 RTM으로 PRD 드리프트를 막고 요구사항-스토리 연결과 변경 승인 근거를 확보하세요.
PRD 드리프트는 로드맵을 조용히 무너뜨립니다
"이건 작은 변경이에요. 이번 스프린트에 넣어주세요."
이 한 문장이 일정 붕괴의 시작이 됩니다.
PRD 드리프트는 거창하게 폭발하지 않습니다.
작은 변경이 여러 채널에서 누적되고, 어느 순간 로드맵이 무너집니다.
PM에게 필요한 것은 “문서”가 아니라 변경 통제 시스템입니다.
그 역할을 하는 도구가 바로 **요구사항 추적성 매트릭스(RTM)**입니다.
PRD 드리프트가 생기는 이유
- 채널 분산 — 슬랙, 이메일, 회의록, 문서가 제각각
- 승인 없는 ‘소규모 변경’ — 승인 로그가 없음
- 모호한 요구 표현 — “가능하면,” “좋을 듯”
- 스토리 연결 부재 — 영향 범위가 보이지 않음
RTM은 요구사항에 ID, 상태, 스토리 연결을 부여해 이 문제를 정리합니다.
RTM은 문서가 아니라 통제 장치입니다
RTM이 제공하는 핵심 가치:
- 승인된 요구사항을 한눈에
- 변경 요청의 영향 범위를 즉시 확인
- 책임과 버전 히스토리 확보
요구사항 ID가 없으면 기억으로 협의하는 셈입니다.
최소 RTM 컬럼(30분 세팅)
아래 정도만 있어도 충분합니다.
| ID | 요구사항 | 출처 | 연결 스토리 | 상태 | 근거 |
|---|---|---|---|---|---|
| REQ-012 | 관리자 CSV 내보내기 | PRD v2 §3 | ST-24 | 승인 | “월간 리포트 필요” |
| REQ-019 | 역할별 대시보드 권한 | 01/03 회의 | ST-29 | 초안 | 액션 아이템 문서 |
여유가 생기면 Owner, 수락 기준, 리스크/가정 컬럼을 추가하세요.
PM을 위한 RTM 5단계 구축법
- 소스 수집 (PRD, 메모, 정책 문서, 스테이크홀더 이메일)
- 요구사항 정규화 (짧고 검증 가능한 문장)
- ID + 상태 부여 (Draft / Approved / Deferred)
- 스토리 + 수락 기준 연결
- 변경 요청 로그 운영 (새 행 또는 버전)
가볍게 시작하고, 꾸준히 유지하는 것이 핵심입니다.
변경 요청 흐름: RTM 전 vs 후
| RTM 전 | RTM 후 |
|---|---|
| 변경이 슬랙으로 흩어짐 | 변경이 요구사항 ID로 기록됨 |
| 기억에 의존한 협의 | 스토리 연결로 영향 범위 확인 |
| 일정이 조용히 밀림 | 변경 근거가 기록됨 |
핵심 포인트
RTM은 속도를 늦추는 게 아니라, 변경을 통제해 속도를 지켜줍니다.
새 문서가 들어오면 섹션별 변경량부터 확인하세요
uDocit은 새 소스를 기존 기준과 비교해 개요 → 사용자 유형 → 스토리 → 타임라인의 변경 건수를 요약합니다. Project Completion에서 변경 섹션이 표시되어, 적용 전에 diff를 빠르게 검토할 수 있습니다.
한 줄 RTM 템플릿 (복사/붙여넣기)
Requirement ID | Requirement | Source | Story Link | Status | Evidence | Last Updated
구글 시트, 노션, 어떤 툴이든 충분합니다.
uDocit이 RTM을 자동화하는 방식
PM이 수동으로 하던 일을 자동화합니다:
- 문서에서 리스크/가정 추출
- 문서 항목 → 스토리 커버리지 매핑
- Document Change Analysis로 개요·사용자·스토리·타임라인 diff 표시
RTM을 기준으로 두면, 업데이트는 훨씬 쉬워집니다.
마무리
무거운 스펙 프로세스가 필요하지 않습니다.
필요한 것은 추적성입니다.
가벼운 RTM만으로도 PRD 드리프트를 예방하고, 변경을 근거 기반으로 통제할 수 있습니다.
