PRD(제품 요구사항 문서), ADR(아키텍처 결정 기록), TDD(기술 설계 문서), 태스크 리스트

PRD, ADR, TDD, 태스크 리스트가 필요한 이유

지속 가능한 제품 개발을 위한 문서화 전략

소프트웨어 개발 조직이 성장할수록 공통적으로 겪는 문제가 있다. 의사결정이 기록되지 않고, 요구사항이 모호하며, 설계 의도가 사라지고, 작업 흐름이 단절되는 문제다. 초기에는 구두 소통이나 간단한 메모만으로도 개발이 가능하지만, 팀 규모가 커지고 제품이 복잡해질수록 체계적인 문서화가 필수적이 된다.

이때 중요한 역할을 하는 것이 **PRD(Product Requirement Document), ADR(Architecture Decision Record), TDD(Technical Design Document), 그리고 태스크 리스트(Task List)**이다. 이 문서들은 단순한 기록이 아니라 제품 개발의 의사결정과 실행을 연결하는 구조를 만든다.

---

1. PRD: 무엇을 만들 것인가를 정의한다

**PRD(Product Requirement Document)**는 제품이 해결하려는 문제와 사용자 요구사항을 정의하는 문서다. 쉽게 말해 **“왜 이 기능을 만들고 무엇을 만들어야 하는가”**를 설명한다.

PRD에는 일반적으로 다음 내용이 포함된다.

• 제품 목표 및 배경
• 해결하려는 사용자 문제
• 주요 기능 요구사항
• 성공 지표 (KPI)
• 제약 조건
• 사용자 시나리오

PRD의 가장 중요한 역할은 제품 방향성을 팀 전체에 공유하는 것이다.

예를 들어 PRD 없이 개발이 시작되면 다음과 같은 문제가 발생한다.

• 개발자마다 기능 해석이 다름
• 기획 의도가 개발 과정에서 변질됨
• 우선순위가 계속 흔들림

PRD는 이러한 문제를 방지하고 제품 개발의 기준점(Single Source of Truth) 역할을 한다.

---

2. ADR: 왜 이런 아키텍처를 선택했는가

개발 과정에서는 수많은 기술적 선택이 이루어진다.

예를 들어 다음과 같은 결정들이 있다.

• REST vs GraphQL
• Monolith vs Microservices
• PostgreSQL vs MongoDB
• Event-driven architecture 도입 여부

하지만 시간이 지나면 대부분의 팀은 “왜 이런 선택을 했는지”를 잊어버린다.

이 문제를 해결하기 위해 사용하는 것이 **ADR(Architecture Decision Record)**이다.

ADR은 아키텍처 의사결정을 기록하는 짧은 문서다. 일반적으로 다음 구조를 가진다.

Title: Use PostgreSQL for primary database

Status: Accepted

Context:
서비스는 트랜잭션 일관성이 중요하며 관계형 데이터 구조를 가진다.

Decision:
Primary database로 PostgreSQL을 사용한다.

Consequences:
+ 강력한 ACID 지원
+ SQL 기반 분석 가능
- 스키마 변경 시 migration 필요

ADR의 핵심 가치는 **결정의 이유(Context)**를 기록하는 것이다.

이 문서가 있으면 다음과 같은 장점이 있다.

• 새로운 팀원이 아키텍처 의도를 빠르게 이해
• 과거 결정을 재검토 가능
• 동일한 논쟁 반복 방지

즉 ADR은 기술적 의사결정의 히스토리 시스템이다.

---

3. TDD: 어떻게 구현할 것인가를 설명한다

여기서 말하는 TDD는 Test Driven Development가 아니라 Technical Design Document를 의미한다.

TDD는 PRD에서 정의된 요구사항을 실제 시스템 설계로 변환하는 문서다.

PRD가 제품 관점이라면, TDD는 엔지니어링 관점이다.

보통 다음 내용이 포함된다.

• 시스템 아키텍처
• 데이터 모델
• API 설계
• 컴포넌트 구조
• 주요 알고리즘
• 성능 고려사항

예를 들어 PRD에 다음 요구사항이 있다고 가정해보자.

"사용자는 실시간으로 주문 상태를 확인할 수 있어야 한다."

TDD에서는 이를 다음과 같이 설계한다.

• WebSocket 기반 이벤트 시스템
• Order status event stream
• Redis Pub/Sub
• Notification service

즉 TDD는 요구사항을 코드로 구현하기 전의 설계 단계라고 볼 수 있다.

이 문서가 없으면 다음 문제가 생긴다.

• 개발자마다 설계가 달라짐
• 코드 리뷰에서 설계 논쟁 발생
• 시스템 구조가 일관성을 잃음

TDD는 팀의 기술적 합의를 만드는 문서다.

---

4. 태스크 리스트: 실행 가능한 단위로 쪼갠다

PRD와 TDD가 준비되었다면 이제 실제 개발 작업으로 넘어가야 한다.

이때 필요한 것이 **태스크 리스트(Task List)**다.

태스크 리스트는 설계를 실행 가능한 작업 단위로 분해한 것이다.

예시:

Epic: Real-time Order Tracking

Tasks
- WebSocket 서버 구현
- Order status event schema 정의
- Redis Pub/Sub 설정
- Order service 이벤트 발행
- Frontend 실시간 상태 UI 구현

태스크 리스트의 목적은 다음과 같다.

• 작업 범위 명확화
• 병렬 개발 가능
• 일정 관리
• 진행 상황 추적

좋은 태스크는 다음 특징을 가진다.

• 1~2일 내 완료 가능
• 명확한 완료 기준
• 의존 관계 정의

즉 태스크 리스트는 설계를 실제 개발로 연결하는 브리지다.

---

5. 이 문서들이 연결되는 구조

이 네 가지 문서는 서로 독립적이지 않다.
하나의 흐름을 구성한다.

PRD
↓
TDD
↓
ADR
↓
Task List
↓
Implementation

조금 더 정확하게 표현하면 다음과 같다.

• PRD → 무엇을 만들 것인가
• TDD → 어떻게 만들 것인가
• ADR → 왜 이런 기술 결정을 했는가
• Task List → 실제로 어떤 작업을 할 것인가

이 구조가 갖춰지면 다음 효과가 생긴다.

• 의사결정 추적 가능
• 커뮤니케이션 비용 감소
• 온보딩 속도 향상
• 유지보수 용이

결국 이 문서들은 개발 속도를 늦추기 위한 것이 아니라, 오히려 장기적으로 개발 속도를 높이기 위한 장치다.

---

6. 문서화의 핵심 원칙

많은 팀이 문서화를 시도하다가 실패하는 이유는 문서를 너무 크게 만들기 때문이다.

효과적인 문서화의 원칙은 다음과 같다.

1. 짧게 작성한다

ADR은 보통 1페이지 이내다.

2. 살아있는 문서로 유지한다

문서는 저장소(Git) 안에 있어야 한다.

3. 의사결정 중심으로 기록한다

설명보다 결정과 이유가 중요하다.

4. 코드와 함께 관리한다

문서는 코드와 같은 lifecycle을 가져야 한다.

---

마무리

좋은 개발 조직은 단순히 코드를 잘 작성하는 조직이 아니다.
의사결정을 기록하고 지식을 축적하는 조직이다.

PRD, ADR, TDD, 태스크 리스트는 그 구조를 만드는 기본적인 도구다.

• PRD는 제품의 방향을 정의하고
• TDD는 기술 설계를 만들며
• ADR은 아키텍처 의사결정을 기록하고
• 태스크 리스트는 실행을 관리한다.

이 네 가지 문서가 연결될 때, 팀은 개인의 기억이 아니라 시스템으로 개발을 운영할 수 있게 된다.