제품 요구사항 문서(PRD, Product Requirements Document)

하이솝·2026년 5월 1일

3학년 1학기 소프트웨어공학

소프트웨어공학

목록 보기

10/16

1단계: 제품 명세서 작성

prd.md 작성

사람은

AI에게 기초적인 아이디어를 제공

AI는

기초적인 아이디어를 구체화하고, 요구사항을 논리적으로 정의
prd.md 파일을 완성할 수 있도록 상세한 가이드를 제공

2단계: 기술 설계서 작성

techspec.md (기술 설계 문서 또는 design.md) 작성
앞에서 만든 prd.md를 바탕으로 시스템의 뼈대를 잡는 과정
AI의 도움을 받아 시스템 구조와 데이터베이스, API 등을 설계
이 단계가 끝나게 되면 개발의 전체적인 청사진이 완성됨

3단계: 구현 계획 수립

tasks.md 파일이 준비됨
techspec.md를 바탕으로 실제 개발에서 해결해야 할 세부 작업들을 정의
AI는 복잡한 설계를 작은 단위의 태스크로 나누고, 우선순위를 정함

4단계: 티켓 주도 개발 진행

칸반 보드에 올라온 작업 티켓을 하나씩 해결
AI와의 협력으로 실제 코드를 구현하고 테스트
AI는 코드 작성 뿐만 아니라 버그 수정과 최적화까지 지원

0. 문서 정보

메타 데이터(Meta data)
이 문서가 언제 작성됐고, 누가 썼으며, 현재 확정된 버전인지
아니면 아직 고치고 있는 'Draft' 상태인지를 명시

1. 프로젝트 개요

1.1 배경 및 목적(Background)

프로젝트를 시작하는 이유
단순히 기능을 나열하는 것이 아닌, 현재 사용자가 겪는 고통(Pain Point)과
우리가 그것을 해결해야 하는 이유
이 문서 한장으로 '이 문서는 무엇이며, 우리는 왜 이 일을 하는가?'
에 대한 대답이 되어야 함

1.2 목표 및 가치(Goals)

목표: 프로젝트가 끝났을 때 도달해야 할 목적지
Core Goal: "이 제품을 통해 사용자에게 어떤 가치를 줄 것인가?"를
한 문장으로 정의

1.3 범위(Scope)

In-Scope: 이번 버전에서 반드시 개발할 기능
Out-Of-Scope: 이번 버전에서 제외된 기능

2. 유저 스토리

사용자 시나리오

사용자의 관점에서 소프트웨어가 제공해야 하는 기능을 짧고 명확하게 기술
3단 구성 공식: [누가, who]로서 [무엇, what]을 원한다.
왜냐하면 [이유, why] 때문이다.

AC(Acceptance Criteria)

인수 기준은 명확하고 구체적이어야 한다.
좋은 인수 기준은 "테스트할 수 있는가?"
예)
사용하기 편해야 한다 [X] - 편하다는 기준은 사람마다 다름
업로드 버튼을 누르고 1초 이내에 메시지가 떠야 한다 [O]
더 체계적이고 전문적으로 쓰고 싶을 경우
EARS(Easy Approach to Requirements Syntax) 문법을 활용
- 자연어 요구사항의 모호함을 제거하기 위해, 상황별 키워드를 사용하여
  시스템의 동작을 표준화된 템플릿 형태로 기술하는 작성 방법론
  할루시네이션을 방지하거나 줄이는 데에 핵심 도구

AI의 역할

스토리 생성: 모호한 아이디어를 표준 템플릿 문장으로 변환

우선순위(Prioritization)-중증도 분류(Triage): 기능 우선순위

P0 (Immediate)
"이게 없으면 제품이 아니다" 싶은 필수 기능
P1 (Urgent)
"있으면 정말 좋지만, 없어도 당장 죽지는 않는" 기능
P2 (Non-Urgent)
"여유가 생기면 추가할 사치품"

이러한 우선순위를 잘 정해놓아야, 마감 기한이 다가왔을 때
무엇을 버릴지 잘 결정할 수 있음

사용자 스토리 우선순위 정하기: MoSCoW 기법
우리가 가진 제한된 시간과 자원 내에서 사용자에게 최대의 가치를 전달하기 위해
무엇에 집중해야 할지 결정하는 나침반

3. 대상 사용자(Target-Audience)

"모두를 만족시키는 제품은 누구도 만족시키지 못하는 결과물이 됨"

주요 페르소나(Primary Persona)
핵심 타겟의 특성 및 행동 양식

사용자 세그먼트(User Segmentation)
그룹 분류 (숙련도, 연령 등)

사용자 니즈(User Needs)
제품을 통해 해결하고자 하는 요구사항

4. 핵심 성과 지표(KPIs)

4.1 비즈니스 지표(Business Metrics)

재방문률(Retension)
사용자가 얼마나 우리 앱에 자주 들어오는지 보여줌
전환율(Conversion Rate)
실제로 물건을 구매했는지 보여줌

4.2 기술 지표(Technical Metrics)

로딩 속도, 에러율 등의 목표 수치

북극성 지표(North Star Metric)

모든 지표 중 팀이 가장 우선적으로 바라봐야 할 단 하나의 목표
구체적이고 측정 가능하며, 달성 가능한 숫자로 적어야 함

5. 상세 기능 요건(Functional Requirements)

앞에서 무엇을 만들지를 결정했다면,
이제는 그 기능들이 실제로 어떻게 움직여야 하는지 시스템의 언어로 번역

5.1 기능 그룹

개발자가 코드를 짤 때, 오해의 소지가 없도록
아주 정밀하게 로직(Logic)을 정의하는 것이 핵심

상세 기능 요건을 작성할 때, 고려해야 할 조건 3가진

로직(Logic)
시스템이 동작하는 기본 원리와 알고리즘
밸리데이션(validation)
입력값의 유효성을 검사하는 규칙
엣지 케이스(Edge Case)
예외적이거나 극단적인 상황에서의 처리 방식

우선 순위와 기능 요건의 연결

각 요건에는 F-01, F-02와 같은 고유한 ID를 부여해야 함

비즈니스 우선 순위가 높은 것 부터 시스템의 언어로 풀어가는 과정임

6. UI/UX 상세 요건

예쁜 그림을 보여주는 곳이 아닌,
사용자가 어떤 경로로 이동하고 화면이 어떤 논리적 구조를 갖는지 정의
디자인의 느낌보다 컴포넌트의 배치와 동작 규칙을 전달

1. 사용자 흐름(User Flow)

사용자가 서비스에 접속해서 목적을 달성할 때 까지 거치는 모든 단계

2. 와이어프레임(Wireframe)

정밀한 디자인 파일이 없더라도,
헤더에는 무엇이 들어가고, 메인 영역은 몇개의 열로 구성되는지 등의 정의

3. 인터랙션 규칙(Interaction Rules)

버튼을 눌렀을 때 로딩 표시를 어떻게 할 지 등

7. 기술적 제약

품질 속성 (Qualiy Attributes)

비기능 요구사항(Non-Functional Requirements, NFR)

기능이 무엇을 하는지(what)라면,
품질 속성은 그것을 얼마나 잘 하는지(How Well)
시스템의 기능이 수행되는 동안 만족해야 하는 운영적 특성이나 제약 사항
예)
개발자가 코드를 짤 때, 기능은 구현할 대상
품질 속성은 구현의 범위와 한계를 정하는 제약 조건
품질 속성은 반드시 측정 가능, measureable 해야 함