AI로 PRD 작성하는 법: 무료 템플릿과 함께 시작하기

PRD는 실제로 무엇을 위한 문서인가

PRD에는 두 부류의 독자가 있고, 둘 모두를 염두에 두고 쓰는 것이 좋습니다.

첫 번째 독자는 제품을 만드는 사람입니다. 이 사람은 무엇을 해결하는지, 누구를 위한 것인지, 첫 릴리스에 무엇이 포함되고 무엇이 의도적으로 빠지는지 알아야 합니다. 매일 오후마다 질문을 들고 다시 찾아와야 한다면 그 문서는 제 역할을 하지 못하고 있는 것입니다.

두 번째 독자는 나중에 결과물을 검증하는 사람입니다. 여러분 자신일 수도 있고, 공동 창업자나 리뷰어, 출시 전 감사를 맡은 사람일 수도 있습니다. 이들은 문서를 한 줄씩 짚어 가며 “네, 완료됐습니다” 또는 “아니요, 아직입니다”라고 말할 수 있어야 합니다. 이는 요구사항이 실제로 동작하는 제품에 대해 참 또는 거짓을 판단할 수 있는 문장으로 쓰여 있을 때만 가능합니다.

대부분의 PRD 템플릿은 첫 번째 독자만을 위해 만들어져 있습니다. 두 번째 독자까지 고려한 템플릿은 드뭅니다. 그래서 수많은 제품이 “합의한 것”이 아니라 “만들어진 것”을 출시하게 됩니다.

꼭 필요한 섹션

첫 릴리스를 위한 쓸모 있는 PRD는 대략 열 개의 짧은 섹션으로 구성됩니다.

1. 개요. 이름, 담당자, 상태, 한 줄 요약. 무엇이고 누구를 위한 것인지 두 줄로 말할 수 없다면, 다른 내용을 쓰기 전에 더 고민해야 합니다.
2. 문제. 사용자가 실제로 겪는 문제, 지금은 대신 어떻게 해결하고 있는지, 그리고 그 사실을 어떻게 알게 되었는지. “클리닉 매니저 여섯 명과의 인터뷰”는 근거입니다. “다들 이걸 싫어한다”는 근거가 아닙니다.
3. 타깃 사용자. 주요 사용자 한 명, 그들이 새로운 해결책을 찾게 되는 계기, 그리고 이 제품이 누구를 위한 것이 아닌지.
4. 해결할 일(Jobs to be done). 세 개에서 다섯 개, 사용자의 언어로 작성합니다. 이런 상황이 되면, 이렇게 하고 싶다, 그래서 이런 결과를 얻고 싶다.
5. MVP 범위. 첫 릴리스가 하는 일을, 누군가 실제로 동작하는 모습을 볼 수 있는 문장으로 씁니다.
6. 요구사항. 번호가 매겨지고 검증 가능한 문장으로, 인수 조건(acceptance criteria)과 우선순위를 함께 적습니다.
7. 성공 지표. 무엇을, 어디서 측정하고 목표치는 얼마인지. 아직 목표치가 없다면 빈칸으로 둡니다.
8. 비목표(Non-goals). 이번 릴리스에서 의도적으로 하지 않는 것.
9. 미해결 질문. 각각 담당자와 기한을 붙입니다.
10. 승인. 누가 언제 합의했는지, 이후 변경은 어떻게 제안하는지.

모든 것을 바꾸는 건 여섯 번째 섹션이므로, 아래에서 따로 다루겠습니다.

검증할 수 있는 요구사항 쓰기

요구사항은 완성된 제품에 대해 참 또는 거짓으로 판단할 수 있는 하나의 문장입니다. “인증”은 주제입니다. “사용자는 이메일로 비밀번호를 재설정할 수 있다”는 요구사항입니다.

각 요구사항에는 네 가지를 붙입니다.

• 키. REQ-001 같은 식입니다. 키는 영구적입니다. 작업, 커밋, 감사가 모두 이 키를 참조하므로 번호를 다시 매기거나 재사용해서는 안 됩니다.
• 인수 조건. 실제로 동작하는 시스템에서 누군가 이를 어떻게 확인할지 설명합니다. “재설정을 요청하고, 1분 안에 이메일을 받고, 새 비밀번호를 설정한 뒤, 그 비밀번호로 로그인한다.” 이걸 쓸 수 없다면 요구사항은 아직 완성되지 않은 것입니다.
• 우선순위. 작은 팀이라면 MoSCoW로 충분합니다. Must(반드시 필요), Should(있어야 함), Could(있으면 좋음), Won't(이번에는 하지 않음)입니다. 5점 척도를 쓰면 3이냐 4냐를 두고 논쟁이 벌어지기 쉽지만, 정말 중요한 결정은 그것 없이 첫 릴리스를 출시하느냐 마느냐 하나뿐입니다.
• 유형. 기능(동작), 비기능(속도, 가동 시간, 접근성), 또는 제약(규제, 플랫폼, 예산) 중 하나입니다.

목록을 정직하게 유지하는 규칙은 두 가지입니다. 한 행에는 하나의 약속만 담습니다. 한 문장에 두 가지가 들어 있다면 나눕니다. 그리고 인수 조건이 없는 요구사항은 슬그머니 받아들이지 말고 미완성으로 표시합니다.

AI가 도움이 되는 곳과 그렇지 않은 곳

효과가 검증된 역할 분담은 다음과 같습니다.

모델에는 결정이 아니라 맥락을 넘기세요. 실제로 알고 있는 것을 붙여 넣습니다. 여러분의 언어로 쓴 문제, 고객과의 대화 메모, 지켜야 할 제약, 이미 배제한 것들입니다. 한 줄짜리 프롬프트로 초안을 쓰는 모델은 모든 빈틈을 그럴듯한 내용으로 채웁니다. 여기서는 그럴듯함이 적입니다. 합의된 것처럼 읽히기 때문입니다.

구조와 초안 작성은 맡기세요. 모델은 정리되지 않은 메모를 위의 열 개 섹션으로 바꾸고, 빠진 비목표를 찾아내고, “시스템은 빨라야 한다”를 측정 가능한 문장으로 다시 쓰는 데 능숙합니다. 지루한 부분을 빠르게 처리합니다.

범위 결정은 사람이 하세요. 첫 릴리스에 무엇이 들어가고 무엇이 빠지는지, 그리고 “완료”가 무엇을 뜻하는지는 비즈니스 결정입니다. 모델은 합리적이거나 일반적으로 보인다는 이유만으로 요구사항을 기꺼이 지어냅니다. 그것이 바로 아무도 합의하지 않은 범위이고, 몇 주 뒤 아무도 요청하지 않은 작업으로 드러나곤 합니다.

숫자는 절대 지어내게 두지 마세요. 목표치, 가격, 날짜를 모른다면 빈칸으로 남겨 두세요. PRD에 들어간 가짜 성공 지표는 약속으로 취급됩니다.

추출한 내용을 원문과 대조하세요. 서술형 문서를 요구사항 표로 바꾸는 데 모델을 쓴다면, 각 요구사항이 나온 원문 문장을 인용하게 하세요. 그러면 문서 전체를 다시 읽지 않고도 마흔 개의 행을 검토할 수 있고, 출처 문장이 없는 항목은 지어낸 것입니다.

오늘 바로 해 볼 수 있는 워크플로

범용 AI 어시스턴트로 직접 작업한다면 다음 순서를 따르세요.

1. PRD 템플릿을 에디터에 복사합니다.
2. 문제와 타깃 사용자 섹션은 직접 씁니다. 분량은 짧지만, 누구와 이야기했는지는 여러분만 알기 때문에 모델이 가장 취약한 부분입니다.
3. 메모를 붙여 넣고, 메모에 적힌 내용만 사용해 해결할 일, MVP 범위, 비목표의 초안을 쓰도록 요청합니다.
4. 키, 문장, 인수 조건, 우선순위, 유형을 담은 표로 요구사항을 제안하게 하고, 각 항목마다 출처 문장을 인용하도록 합니다.
5. 출처가 없는 항목은 삭제합니다. 빠진 인수 조건을 채웁니다. 우선순위는 직접 정합니다.
6. 승인을 받고 그 버전을 동결합니다. 이후의 변경은 조용히 수정하는 것이 아니라 제안하고 기록합니다.

Atrix AI 안에서 하기

Atrix AI는 같은 워크플로를 워크스페이스 안에서, 안전장치를 갖춘 채로 실행합니다.

Develop 모드에서 에이전트는 프로젝트에 이미 담긴 내용을 읽습니다. 프로젝트의 요약, 피치, 타깃 고객(프로젝트로 승격한 아이디어의 메모 포함)과 프로젝트 안의 문서들입니다. 그리고 문제, 타깃 사용자, 해결할 일, MVP 범위, 성공 지표, 비목표를 담은 PRD를 프로젝트 안의 문서로 작성합니다. 다시 요청하면 새 사본을 만드는 대신 그 문서 하나를 업데이트하고, 이전 내용은 버전으로 보관합니다.

이어서 Atrix는 PRD에서 요구사항을 추출해 키가 붙은 행으로 만듭니다. 각 행에는 인수 조건, MoSCoW 우선순위, 유형이 있고, 출처가 된 문장이 인용됩니다. 인용문을 문서에서 찾을 수 없는 행은 폐기됩니다. 나머지는 모두 제안 상태로 들어오며, 사람이 수락하기 전까지는 아무것도 확정되지 않습니다. Won't를 제외하고 인수 조건이 없는 요구사항은 표시되며, 모든 요구사항에 인수 조건이 갖춰지고 수락 대기 중인 항목이 하나도 없을 때까지 요구사항을 동결할 수 없습니다.

수락된 요구사항은 백로그 이슈로 나눌 수 있고, 각 이슈에는 해당 요구사항의 키가 명시됩니다. 덕분에 프로젝트 관리가 합의된 내용과 계속 연결됩니다. 코딩 에이전트에 개발을 넘길 때는 인계 번들에 문서와 요구사항 키가 함께 담기고, 커밋에 키를 참조하도록 요청합니다.

바로 이것이 마지막 단계를 가능하게 합니다. 수락된 요구사항을 기준선(baseline)으로 동결할 수 있고, 요구사항 감사는 각 요구사항에 대해 작업이 존재하는지, 진행 중인지, 완료되었는지, 그리고 승인 이후 어떤 요구사항이 변경되거나 제외되었는지를 보여 줍니다. 이 보고서는 모델의 의견이 아니라 여러분의 기록을 바탕으로 계산됩니다. 코드를 읽지는 않습니다. 합의된 각 요구사항에 대해 기록된 작업이 완료되었는지를 알려 줍니다.

요구사항 추출과 이슈 분할은 각각 AI 실행 1회를 사용하므로, 무료 플랜의 월 5회 실행으로 첫 PRD는 넉넉하게 처리할 수 있습니다.

PRD 완성 전 짧은 체크리스트

• 팀 밖의 누군가가 여러분에게 묻지 않고도 이 문서만으로 첫 릴리스를 만들 수 있나요?
• 모든 Must 요구사항에 인수 조건이 있나요?
• 모든 요구사항이 참 또는 거짓으로 판단할 수 있는 하나의 문장인가요?
• 비목표가 문서로 적혀 있나요?
• 모든 미해결 질문에 담당자와 기한이 있나요?
• 누군가 승인했고, 그 버전이 저장되어 있나요?

여섯 가지 모두 “예”라면, 두 독자 모두에게 도움이 되는 PRD를 갖춘 것입니다. 무료 템플릿으로 시작하거나, 에이전트에게 초안을 맡기고 여러분은 결정에 시간을 쓰세요.