PRD와 Tech Spec 매핑

PRD와 Tech Spec의 관계

PRD와 Tech Spec의 매핑 관계를 이해하면 SDD의 절반은 이해한 것이다.

• PRD (Product Requirements Document): What — 무엇을 만들 것인가
• Tech Spec (Technical Specification): How — 어떻게 만들 것인가

핵심 매핑 관계

PRD의 각 항목이 Tech Spec에서 무엇으로 변환되는지 정확히 이해해야 한다.

매핑 테이블

PRD (What)	Tech Spec (How)	예시
기능 요구사항	구현 명세	"할 일 추가" → addTodo() 함수
사용자 스토리	API Endpoint	"사용자가 할 일을 추가" → POST /api/todos
수용 기준	테스트 케이스	"빈 값이면 에러" → 입력값 검증 테스트
비기능 요구사항	성능/보안 설정	"1초 이내 응답" → 캐시, DB 인덱스

구체적 예시: 할 일 관리 앱

PRD에서 정의한 것 (What)

[기능 요구사항]
- 할 일을 추가, 조회, 수정, 삭제할 수 있다
- 완료 체크를 토글할 수 있다
- 카테고리별로 필터링할 수 있다

[사용자 스토리]
- 직장인으로서, 업무 할 일을 등록하고 추적하고 싶다

[수용 기준]
- 빈 제목으로는 할 일을 추가할 수 없다
- 삭제 시 확인 과정이 있어야 한다

[비기능 요구사항]
- 데이터는 JSON 파일로 로컬 저장
- 반응형 디자인

Tech Spec에서 정의한 것 (How)

[구현 명세]
- addTodo(), getTodos(), updateTodo(), deleteTodo() 함수
- toggleComplete() 로 완료 상태 토글
- filterByCategory() 로 필터링

[API Endpoint]
- GET /api/todos - 목록 조회
- POST /api/todos - 추가
- PUT /api/todos/:id - 수정
- DELETE /api/todos/:id - 삭제

[테스트 케이스]
- 빈 제목 입력 시 에러 반환 검증
- 삭제 API 호출 전 확인 다이얼로그 검증

[기술 구현]
- 저장소: /data/todos.json (Node.js fs 모듈)
- CSS: 미디어 쿼리 기반 반응형

매핑의 흐름

왜 이 매핑이 중요한가?

1. 추적 가능성 (Traceability)

PRD의 모든 기능이 Tech Spec에 있고, Tech Spec의 모든 명세가 코드에 구현되어 있으면 → 빠짐없이 구현되었다는 것을 보장할 수 있다.

2. 검증 자동화

수용 기준이 테스트 케이스로 변환되므로, "잘 만들었는지"를 자동으로 검증할 수 있다. 감이 아닌 체크리스트 기반 판정이다.

3. Tech Spec 없이 PRD만으로는 불가

PRD는 "무엇을"만 정의한다. "어떻게"가 없으면 AI가 매번 다른 방식으로 구현할 수 있다. Tech Spec이 있어야 파일명, 함수명, API 경로까지 동일하게 구현할 수 있다.

정리