PRD 뜻, 제품 요구사항 문서에 들어가는 8가지와 작성 예시
3줄 요약
PRD 뜻은 Product Requirements Document, 우리말로 제품 요구사항 문서예요. 무엇을 왜 만드는지 팀이 한 장으로 맞추는 문서예요.
아틀라시안 가이드는 목표, 배경, 가정, 사용자 스토리, 디자인, 질문, 하지 않는 일을 넣으라고 권해요.
AI 코딩 도구도 같은 구조를 써요. 키로(Kiro)는 기능마다 requirements.md, design.md, tasks.md 세 파일을 만들어요.
PRD는 만들 제품의 목적과 기능, 동작을 적어 둔 문서예요. 아틀라시안은 PRD를 디자이너와 개발자, 이해관계자가 같은 방향을 보게 하는 단일 정보 출처라고 설명해요. 길게 쓰는 사양서가 아니에요. 왜 만드는지와 어디까지 만드는지를 먼저 정하는 문서죠.
요즘 PRD를 찾는 사람은 기획자만이 아니에요. 바이브 코딩으로 앱을 만들거나 해커톤에서 AI 코딩 도구를 쓰는 팀도 PRD부터 쓰라는 말을 자주 들어요. 이 글은 처음 PRD를 쓰는 사람이 빈 문서 앞에서 막히지 않을 만큼만 정리했어요.
아틀라시안 PRD 가이드가 권하는 항목을 한 장에 쌓은 모습이에요. 위에서 아래로 갈수록 구체적이에요.
PRD 뜻은 무엇인가요?
PRD(Product Requirements Document)는 제품 요구사항 문서예요. 만들려는 제품이나 기능의 목적, 핵심 기능, 사용자 요구, 성공 기준을 한곳에 적어 팀이 같은 그림을 보게 해요.
단어를 풀어 보면 쉬워요. Product는 만들 제품, Requirements는 그 제품이 갖춰야 할 조건, Document는 문서예요. 아틀라시안 가이드는 PRD가 제품 로드맵 역할을 한다고 적고 있어요. 아이디어를 실제 기능으로 옮길 때 길잡이가 된다는 뜻이에요.
해커블 에디터팀이 보기에 PRD의 핵심은 범위예요. 무엇을 만들지보다 이번에 무엇을 안 만들지를 적어 둔 PRD가 일정이 덜 밀려요. 이틀짜리 해커톤처럼 시간이 정해진 자리에서는 더 그래요.
PRD에는 무엇을 쓰나요?
아틀라시안 가이드는 프로젝트 세부 사항, 목표, 배경과 전략적 적합성, 가정, 사용자 스토리, 사용자 상호작용과 디자인, 질문, 하지 않는 일 8가지를 넣으라고 권해요.
| 항목 | 적는 내용 |
|---|---|
| 프로젝트 세부 사항 | 참여자, 현재 상태, 목표 출시일 |
| 팀 목표·비즈니스 목적 | 짧고 분명한 목표. 읽는 사람이 추측하지 않게 |
| 배경·전략적 적합성 | 왜 지금 이걸 만드는지, 회사 목표와 어떻게 맞는지 |
| 가정 | 기술·사업·사용자 행동에 대해 팀이 믿고 있는 것 |
| 사용자 스토리 | 누가 무엇을 하려는지, 성공을 재는 지표 |
| 상호작용·디자인 | 와이어프레임, 디자인 시안 링크 |
| 질문 | 아직 정하지 못한 것과 조사할 것 |
| 하지 않는 일 | 이번 범위에서 뺀 것, 나중에 볼 것 |
출처: Atlassian, 제품 요구 사항 문서를 만드는 방법(PRD). 2026년 11월 1일 확인
가이드가 반복해서 하는 말은 길게 쓰지 말라는 거예요. 팀이 이해하기에 겨우 충분한 맥락만 담고, 세부 자료는 링크로 붙이라고 해요. 고객 인터뷰, 이전 논의, 데모 영상 같은 것들이요.
PRD와 기획서, 요구사항 정의서는 무엇이 다른가요?
PRD는 왜 만들고 무엇을 만들지를 정하는 문서이고, 요구사항 정의서는 기능을 어떻게 동작시킬지 자세히 적는 문서예요. 회사마다 이름을 섞어 쓰기도 해요.
네이버와 구글에서 PRD 뜻을 검색하면 두 곳 AI 답변이 모두 이 차이를 먼저 설명해요. PRD는 문제와 목표, 사용자 가치를 다루고 요구사항 정의서는 화면별 기능과 예외 조건을 다룬다는 식이에요. 정해진 국가 표준이 있는 말은 아니에요. 그래서 팀 안에서 어떤 문서를 PRD라고 부를지 먼저 맞추는 편이 덜 헷갈려요.
| 문서 | 답하는 질문 | 쓰는 시점 |
|---|---|---|
| 사업계획서 | 이 사업이 돈이 되나요? | 지원사업·투자 준비 |
| PRD | 무엇을 왜 만들고 어디까지 만드나요? | 기능을 만들기 전 |
| 요구사항 정의서 | 기능은 정확히 어떻게 움직이나요? | 개발 착수 직전 |
AI 코딩 도구에도 PRD가 필요한가요?
필요해요. AI 코딩 도구는 짧은 한 줄 지시보다 요구사항과 범위가 정리된 문서를 받을 때 덜 헤매요. 키로 같은 도구는 아예 요구사항 문서를 먼저 만들게 설계돼 있어요.
아마존이 만든 AI 개발 도구 키로의 공식 문서를 보면 구조가 PRD와 닮았어요. 기능 하나를 만들 때마다 세 파일을 만들어요. requirements.md에는 사용자 스토리와 수용 기준을, design.md에는 구조와 흐름도를, tasks.md에는 실행할 작업 목록을 적어요. 요구사항을 먼저 정하고 설계와 작업으로 내려가는 순서예요.
requirements.md
사용자 스토리와 수용 기준. PRD의 목표·사용자 스토리 칸에 해당해요.
design.md
기술 구조, 순서도, 오류 처리와 테스트 방법. PRD의 디자인 칸보다 한 단계 깊어요.
tasks.md
하나씩 실행하고 추적하는 작업 목록. 키로는 서로 의존하지 않는 작업을 묶어 동시에 돌려요.
출처: Kiro 공식 문서, Specs (페이지 갱신 2026년 10월 15일). 2026년 11월 1일 확인
클로드 코드나 커서를 쓴다면 같은 내용을 마크다운 파일 하나로 두고 작업을 시킬 때마다 참고하게 하면 돼요. 해커블 에디터팀은 PRD의 하지 않는 일 칸이 AI에게 특히 쓸모 있다고 봐요. 안 만들 기능을 적어 두지 않으면 AI가 로그인이나 결제 같은 기능을 알아서 덧붙이는 경우가 있거든요.
PRD 한 장은 어떻게 쓰나요?
빈칸부터 채우지 말고 문제 한 줄, 사용자 한 줄, 이번에 만들 기능 3개, 하지 않는 일 3개를 먼저 적으세요. 나머지 칸은 그다음에 채워도 돼요.
아래는 해커톤 팀을 가정한 예시예요. 실제 팀 사례가 아니라 칸을 어떻게 채우는지 보여 주려고 만든 예시예요.
| 칸 | 예시 |
|---|---|
| 문제 | 동아리 회비를 누가 냈는지 총무가 엑셀로 일일이 맞춘다 |
| 사용자 | 회원 30명 안팎 동아리의 총무 |
| 목표 | 입금 내역을 붙여 넣으면 미납자 목록이 1분 안에 나온다 |
| 만들 기능 | 입금 내역 붙여 넣기, 회원 명단 대조, 미납자 목록 복사 |
| 하지 않는 일 | 은행 계좌 연동, 회원 로그인, 결제 기능 |
| 질문 | 입금자 이름이 명단과 다를 때 어떻게 맞출까 |
여섯 줄이면 심사위원에게 설명할 때도 그대로 쓸 수 있어요. 발표 시간에 왜 이 기능만 만들었는지 물으면 하지 않는 일 칸이 답이 돼요.
PRD를 한 번 쓰고 끝내면 금방 실제 제품과 어긋나요. 아틀라시안 가이드도 오래된 문서가 되는 것을 가장 큰 문제로 꼽아요. 기능을 바꿀 때마다 PRD의 해당 줄도 같이 고치세요.
자주 묻는 질문
PRD는 누가 쓰나요?
보통 제품 관리자(PM)나 기획자가 초안을 쓰고 개발자, 디자이너와 같이 고쳐요. 아틀라시안 가이드도 PRD를 혼자 쓰지 말고 개발자와 함께 쓰라고 권해요. 작은 창업 팀이나 해커톤 팀이라면 대표나 팀장이 쓰면 돼요.
PRD 양식은 정해져 있나요?
법이나 표준으로 정해진 양식은 없어요. 아틀라시안 컨플루언스의 PRD 템플릿처럼 회사마다 쓰는 틀이 있을 뿐이에요. 팀 안에서는 한 가지 틀을 정해 계속 쓰는 편이 피드백 받기 쉬워요.
PRD는 얼마나 길게 써야 하나요?
정해진 분량은 없어요. 아틀라시안은 팀이 이해하기에 겨우 충분한 맥락만 담고 세부 자료는 링크로 붙이라고 해요. 기능 하나짜리 PRD라면 한 페이지로도 충분해요.
참고 자료
해커블 한마디
해커톤 첫날 밤에 기능을 하나 더 넣고 싶어지면 PRD의 하지 않는 일 칸을 다시 읽어 보세요. 데모가 끝까지 돌아가는 팀이 결국 점수를 가져가요.
2026년 11월 1일 작성. 해커블 에디터팀이 아틀라시안 PRD 가이드와 키로 공식 문서 원문을 확인해 썼어요. 자료 정리와 초안 구성에 AI 도구를 썼고, 항목과 날짜는 원문으로 다시 확인했어요.
PRD 한 장으로 나가 볼 해커톤을 찾고 있다면
해커블은 마감 전인 해커톤과 AI 공모전을 골라 보내드릴 준비를 하고 있어요. 미리 신청해 두면 정식 오픈 소식을 먼저 받아요.
