요구사항 정의서(PRD)가 중요한 이유

PM이 수행 계획서를 통해 프로젝트의 구조와 운영 방식을 정리해 놓으면, 그 다음부터는 프로젝트의 ‘내용’을 채우는 작업이 시작됩니다. 그 중심에 있는 사람이 바로 기획자입니다. 그리고 기획자가 가장 먼저 만들어야 하는 문서가 요구사항 정의서(PRD)입니다.

요구사항 정의서는 단순히 “고객이 이렇게 말했습니다”를 정리하는 문서가 아닙니다. 프로젝트에서 실제로 구현해야 할 범위를 확정하고, 이후 설계와 구현의 기준이 되는 공식 문서입니다. 다시 말해, 프로젝트의 방향이 아니라 ‘실체’를 정의하는 문서라고 보시면 됩니다. 많은 분들이 제안서와 PRD를 비슷하게 생각하시지만, 실제 현장에서는 완전히 다른 문서로 취급됩니다. 제안서는 “우리가 이런 방향으로 개선하겠습니다”라는 전략적 선언에 가깝습니다. 수행 계획서는 “이 프로젝트를 이런 구조와 일정으로 운영하겠습니다”라는 운영 약속입니다.

그러나 요구사항 정의서는 다릅니다. 이 문서는 “결국 무엇을 만들 것인가”를 명확히 적시합니다. 그리고 이 문서에 적힌 내용은 이후 설계, 구현, 검수의 기준이 됩니다. 이 기준이 흔들리면 프로젝트 전체가 흔들립니다.

 

요구사항 정의 단계에서 가장 중요한 것: 정리와 확정

요구사항은 보통 여러 경로를 통해 흘러 들어옵니다. RFP 문서에 적혀 있던 항목, 제안 과정에서 논의된 사항, 킥오프 미팅에서 나온 요청, 실무 담당자의 추가 의견 등 출처가 매우 다양합니다. 이때 기획자의 역할은 단순히 받아 적는 것이 아니라, 이 요구들을 다음과 같이 정리하는 것입니다.

• 어떤 영역에 속하는지 분류하고
• 중복 여부를 확인하고
• 충돌되는 항목은 없는지 검토하고
• 출처와 제안자를 기록하고
• 실제 구현 범위에 포함할 것인지 판단 근거를 마련하는 것

특히 출처 기록은 굉장히 중요합니다. 나중에 프로젝트가 진행되다 보면 “이건 당연히 포함된 거 아니었나요?”라는 질문이 반드시 나옵니다. 이때 요구사항의 출처와 수용 여부가 명확히 기록되어 있다면, 감정적인 논쟁을 피할 수 있습니다. 요구를 접수하는 사람은 기획자이지만, 최종 수용 여부를 결정하는 사람은 PM입니다. 그래서 요구사항 정의 단계에서는 기획자와 PM의 긴밀한 협업이 필요합니다. 기획자는 요구를 단순 전달하는 사람이 아니라, 해결 방안을 함께 제시하는 사람입니다. 그리고 그 근거가 바로 리서치입니다.

 

리서치가 요구사항 정의에서 가지는 의미

요구사항 정의 단계에서 기획자의 전문성이 드러나는 지점은 ‘대안 제시’입니다. 예를 들어, “정기 배송 기능을 넣어 달라”는 요구가 들어왔다고 가정해 보겠습니다. 이때 기획자가 해야 할 일은 “가능합니다”라고 답하는 것이 아니라, 다음을 고민하는 것입니다.

• 국내 주요 커머스는 어떤 정기 배송 모델을 쓰고 있는지
• 구독형 모델인지, 예약형 모델인지
• 사용자 관점에서 어떤 구조가 이탈을 줄이는지
• 운영 측면에서 어떤 방식이 부담이 적은지

이러한 내용을 벤치마킹하고 정리한 것이 리서치 리포트입니다. 이 리서치 결과를 근거로 A안과 B안을 제시하고, 그 중 어떤 안이 프로젝트의 방향성과 맞는지 협의하게 됩니다.
즉, 요구사항 정의서는 기획자의 직관이 아니라, 근거 기반 판단 위에서 완성되는 문서입니다.

 

요구사항 ‘확정’의 진짜 의미

요구사항 정의서가 작성되고 협의가 끝나면, 반드시 확정 절차를 거쳐야 합니다. 확정 날짜를 명시하고, 그 시점 이후로는 새로운 요구는 변경 요청으로 관리해야 합니다. 이 과정이 중요한 이유는 단 하나입니다. 설계를 안정적으로 진행하기 위해서입니다. 요구사항이 확정되지 않은 상태에서 설계에 들어가면 어떻게 될까요? 설계 중간에 요구가 바뀌고, 이미 그려놓은 화면을 다시 수정하고, 일정은 밀리고, 비용은 증가하게 됩니다. 결과적으로 처음에 시간을 아끼려던 선택이 오히려 더 많은 시간을 소모하게 됩니다.

그래서 프로젝트에서는 이런 말이 있습니다.

착수의 시작은 계약 또는 지시이지만,
착수의 끝은 요구사항의 확정이다.

요구사항이 확정되어야만 설계로 넘어갈 수 있고, 설계는 반드시 요구사항 정의서 범위 내에서만 진행되어야 합니다.

 

'설계' 단계로 넘어가면 무엇이 달라지는가

요구사항이 확정되면 설계 단계로 진입합니다. 이때 설계는 크게 두 갈래로 나뉩니다. 하나는 정보 설계이고, 다른 하나는 화면 설계입니다.
정보 설계는 기존 데이터를 어떻게 재구성하여 새로운 서비스 구조를 만들 것인지 고민하는 단계입니다. 그 산출물이 정보구조도(IA)입니다. 이는 사이트를 페이지 단위로 나누고, 각 페이지가 어떤 기능과 정보를 담는지를 구조적으로 정리한 문서입니다. 화면 설계는 그 구조를 실제 사용자 화면 단위로 구체화하는 작업입니다. 여기서 화면 설계서가 만들어집니다.

이 과정에서 기획자는 As-is를 분석하고, 요구사항을 반영한 To-be를 제시합니다. 이때 To-be를 하나로 고집하는 것보다 A안과 B안을 제시하고 판단 근거를 설명하는 방식이 훨씬 설득력이 있습니다.  “저는 A안이 더 적합하다고 판단합니다. 다만 B안도 운영 측면에서는 장점이 있습니다.” 이렇게 설명할 수 있어야 기획자는 단순 문서 작성자가 아니라, 의사결정을 돕는 사람으로 자리 잡게 됩니다.