PRD

PRD란 무엇인가

PRD(Product Requirements Document, 제품 요구사항 문서)는 어떤 제품을 무엇 때문에, 누구를 위해, 어떤 가치를 목표로 만들지를 제품 관점에서 정의한 요구 문서다. 발주 단계에서 작성되는 RFP가 외주 계약과 과업 범위에 무게를 둔다면, PRD는 사용자 문제와 해결 가설, 성공 기준을 중심에 둔다.

즉 같은 발주 영역의 문서라도 PRD는 만들 대상의 본질을 먼저 합의하는 데 목적이 있다. 무엇을 만들지 나열하기 전에 왜 만들어야 하는지를 분명히 해야 이후의 모든 의사결정이 흔들리지 않는다.

왜와 무엇을 먼저 묶는다

PRD의 핵심은 문제 정의와 해결 방향을 한 흐름으로 연결하는 데 있다. 풀어야 할 사용자 문제, 그 문제가 비즈니스에 갖는 의미, 그리고 그것을 충족했을 때의 측정 지표를 함께 적는다.

기능 목록부터 채우면 각 기능이 무엇을 위한 것인지 근거가 사라지고, 개발 도중 우선순위 다툼이 끊이지 않는다. 반대로 목표와 성공 지표를 상단에 고정하면 개별 요구가 그 목표에 기여하는지로 취사선택할 수 있다.

이 구조가 명확할수록 후속 산출물의 일관성이 높아진다.

기능 명세와 다른 점

PRD는 상세 화면 설계나 기술 명세와는 추상 수준이 다르다. 기능 명세가 어떻게 구현할지를 다룬다면, PRD는 무엇을 충족해야 하는지와 그 우선순위를 다룬다.

그래서 PRD에는 사용자 시나리오, 범위에 포함·제외되는 항목, 제약과 가정이 담기되 구현 세부는 의도적으로 비워 둔다. 너무 이른 단계에서 구현을 못 박으면 더 나은 대안을 검토할 여지가 사라진다.

추상과 구체 사이의 적정 높이를 잡는 감각이 좋은 PRD를 가른다.

PO와 백로그를 잇는 다리

PRD는 작성으로 끝나는 정적 문서가 아니라 실행과 연결될 때 가치를 갖는다. 일반적으로 PO(Product Owner)가 PRD의 목표와 우선순위를 기준으로 제품 백로그(product-backlog)를 구성하고 항목을 정렬한다.

PRD가 무엇을 왜 만드는지를 정의하면, 백로그는 그것을 언제 어떤 순서로 만들지로 구체화한다. 이 연결이 약하면 문서 따로 개발 따로 흘러 합의의 효력이 사라진다.

PRD와 백로그가 같은 목표 위에서 맞물려야 제품 방향이 일관되게 유지된다.

살아 있는 문서로 다룬다

제품은 사용자 반응과 시장 변화에 따라 가설이 수정되므로 PRD도 고정된 계약서처럼 다루어선 안 된다. 검증으로 가설이 틀렸음이 드러나면 목표와 범위를 갱신하고 그 근거를 기록하는 편이 낫다.

다만 변경을 무제한 허용하면 범위가 통제 불능으로 늘어나므로, 무엇이 바뀌었고 왜 바뀌었는지를 남기는 절제가 필요하다. 합의된 성공 지표를 기준으로 추가 요구를 거를 수 있어야 한다.

이렇게 변경의 근거가 누적되어야 다음 제품의 판단 정확도가 올라간다.

애자일 환경에서의 PRD

애자일 방식에서는 두꺼운 사전 명세보다 반복 검증을 선호하므로 PRD도 얇고 자주 갱신되는 형태로 운용된다. 초기에는 목표와 핵심 가설, 성공 기준만 담고 세부는 이터레이션을 돌며 채워 가는 방식이 현실적이다.

이때 PRD는 무엇을 왜 만드는지에 대한 공유 기준선 역할을 하고, 구체적 실행은 백로그와 스프린트가 맡는다. 문서를 완벽히 끝낸 뒤 시작하려 들면 검증 기회를 놓친다.

작게 정의하고 빠르게 검증해 다시 갱신하는 순환이 PRD를 살아 있게 만든다.