AI와 함께 제품 요구사항 문서 만들기

PRD는 혼자 일하는 사람에게 더 필요하다

제품 요구사항 문서, 즉 PRD는 큰 회사의 기획팀만 쓰는 문서가 아니다. 혼자 만드는 사람에게는 오히려 더 필요하다. 이유는 단순하다. 혼자 만들수록 말릴 사람이 없기 때문이다.

랜딩페이지를 만들고 대기자 명단을 받으면 자연스럽게 기능 아이디어가 늘어난다. "리뷰 답글도 자동으로 달아주면 좋겠다", "매장별 비교도 되면 좋겠다", "관리자 페이지에서 고객 상태를 보면 편하겠다", "팀원 초대 기능도 언젠가는 필요하지 않을까?" 같은 생각이 계속 나온다.

이때 바로 코드를 쓰기 시작하면 첫 버전은 금방 무거워진다. 처음에는 하루면 될 것 같던 기능이 인증, 권한, 데이터 구조, 예외 처리, 화면 상태를 줄줄이 끌고 온다. 결국 서비스의 핵심인 리뷰 분석 리포트는 늦어지고, 주변 기능만 늘어난다.

PRD의 목적은 멋진 문서를 만드는 것이 아니다. 이번 버전에서 무엇을 만들고, 무엇을 만들지 않을지 결정하는 것이다. 특히 1인 창업가에게 PRD는 미래의 나와 맺는 계약서에 가깝다. 나중에 마음이 흔들릴 때 "이번 버전은 여기까지"라고 다시 확인하게 해주는 기준선이다.

이 장에서는 지난 장의 검증 결과를 바탕으로 예제 서비스의 첫 제품 범위를 정한다. 서비스 흐름은 네 단계로 줄인다.

1. 리뷰 업로드

2. AI 분석

3. 액션 리포트 확인

4. 공유

이 네 단계에 들어가지 않는 기능은 일단 의심해야 한다. 좋은 아이디어라도 첫 버전에 필요하지 않으면 뒤로 보낸다.

AI 생성 이미지

검증된 신호만 요구사항으로 바꾼다

랜딩페이지 검증에서 우리가 확인하려 한 것은 세 가지였다.

• 음식점·카페 사장님이 리뷰 분석 문제를 자기 문제로 느끼는가

• 실제 리뷰 자료를 제공할 만큼 관심이 있는가

• 39,000원 수준의 1회 진단 리포트에 거부감이 어느 정도인가

이 신호가 어느 정도 확인되었다고 가정하자. 그렇다고 바로 "AI 리뷰 관리 SaaS 전체"를 만들면 안 된다. 검증된 것은 아직 작다. 고객은 "리뷰를 분석해 개선할 점을 알고 싶다"에 반응했지, 복잡한 대시보드나 팀 권한 기능에 반응한 것이 아니다.

그래서 요구사항은 고객의 실제 행동에서 출발해야 한다.

예를 들어 대기자 명단 신청자가 "리뷰를 어디에 붙여 넣으면 되나요?"라고 물었다면, 첫 버전에는 API 연동보다 복사한 리뷰 텍스트 업로드가 더 중요할 수 있다. "직원에게 보여줘야 한다"고 말했다면, 팀 계정 기능보다 공유 가능한 리포트 링크가 먼저일 수 있다. "AI가 이상한 말을 하면 어떡하죠?"라고 물었다면, 자동 실행보다 사장님이 검토할 수 있는 답글 초안이 맞다.

PRD는 이런 판단을 문장으로 고정한다.

우리는 음식점·카페 사장님이 최근 리뷰를 업로드하면, AI가 반복 불만과 칭찬 포인트를 정리하고, 오늘 실행할 수 있는 개선 액션과 답글 초안, 홍보 문구를 담은 리포트를 제공한다.

이 문장에 없는 기능은 첫 버전에 넣을 이유를 다시 설명해야 한다. "있으면 좋다"가 아니라 "없으면 첫 가치가 전달되지 않는다"라고 말할 수 있어야 한다.

첫 버전의 사용자 흐름

첫 제품은 다음 흐름으로 충분하다.

방문 → 매장 정보 입력 → 리뷰 업로드 → 분석 요청 → 리포트 확인 → 링크 공유

조금 더 풀면 이렇다.

1. 사용자는 서비스에 들어와 매장명, 업종, 지역, 리뷰 출처를 입력한다.

2. 최근 3개월 리뷰를 CSV, 엑셀, 또는 텍스트 붙여넣기로 업로드한다.

3. 시스템은 리뷰 개수와 형식을 확인한다.

4. AI는 리뷰를 긍정·부정·중립, 주요 주제, 반복 불만, 강점으로 분류한다.

5. 리포트는 개선 액션, 답글 초안, 마케팅 문구를 보여준다.

6. 사용자는 리포트 링크를 복사해 직원, 지인, 컨설턴트에게 공유한다.

여기서 중요한 것은 "SaaS처럼 보이는 모든 기능"이 아니라 "고객이 처음 가치를 느끼는 순간"이다. 이 서비스에서 첫 가치 순간은 로그인 성공도, 대시보드 진입도 아니다. 리뷰를 넣었더니 내 매장에 대한 구체적인 개선 제안이 나온 순간이다.

따라서 첫 버전의 모든 설계는 이 순간까지의 거리를 줄이는 방향이어야 한다. 가입 절차, 설정 화면, 관리자 기능이 아무리 그럴듯해도 이 순간을 늦춘다면 첫 버전에서는 다시 생각해야 한다.

MoSCoW로 기능을 자른다

기능 우선순위를 정할 때는 MoSCoW 방식을 사용할 수 있다. Must have는 없으면 이번 프로젝트가 실패하는 필수 요구사항이고, Should have는 중요하지만 첫 출시를 막지는 않는 기능이다. Could have는 여유가 있을 때 넣을 수 있는 기능이며, Won't have는 이번 범위에서 의도적으로 제외하는 기능이다¹.

예제 서비스에 적용하면 다음과 같다.

여기서 핵심은 Won't have다. 많은 사람이 우선순위표를 만들 때 Must와 Should만 쓴다. 하지만 혼자 개발할 때 진짜 힘은 "이번에는 만들지 않는다"를 문서에 쓰는 데서 나온다.

관리자 페이지, 팀 기능, 복잡한 권한 체계는 언젠가 필요할 수 있다. 하지만 첫 버전에서는 제외한다. 이유는 명확하다. 이 기능들은 고객이 리뷰 분석 리포트의 가치를 느끼기 전에 개발 시간을 많이 가져간다.

AI에게 맡길 일과 사람이 결정할 일

AI는 PRD 작성에 잘 맞는다. 정리되지 않은 메모를 구조화하고, 사용자 스토리를 뽑고, 빠진 예외 상황을 찾아내는 데 도움이 된다. 다만 AI가 만든 문서를 그대로 개발 기준으로 삼으면 위험하다. AI는 그럴듯한 기능을 추가하고, 검증되지 않은 가정을 사실처럼 쓸 수 있다.

AI를 제품 개발에 사용할 때도 사람의 검토 지점이 필요하다. 리서치 내용을 요약하고 PRD 초안을 쓰게 할 수는 있지만, 모호한 요구사항을 줄이고 기술적으로 가능한지 판단하며 최종 범위를 결정하는 일은 사람이 해야 한다².

실무 흐름은 이렇게 잡는다.

1. 검증된 사실과 아직 모르는 가정을 구분한다.

2. AI에게 PRD 초안을 만들게 한다.

3. AI에게 사용자 스토리와 수용 기준을 만들게 한다.

4. 사람이 Must 기능만 남기고 범위를 줄인다.

5. 예외 상황과 비용 위험을 다시 점검한다.

6. 개발할 순서로 재정렬한다.

AI에게 처음부터 "리뷰 분석 SaaS PRD 써줘"라고 하면 범위가 커진다. 대신 입력을 좁혀야 한다.

너는 1인 창업가의 제품 매니저다.
제품은 음식점·카페 사장님이 리뷰를 업로드하면 AI가 개선 액션과 답글 초안, 홍보 문구를 담은 리포트를 제공하는 서비스다.
검증된 사실:
- 목표 고객은 최근 3개월 리뷰가 30개 이상인 음식점·카페 사장님이다.
- 고객은 리뷰를 읽을 시간 부족과 반복 불만 파악에 어려움을 느낀다.
- 첫 버전은 리뷰 플랫폼 API 연동 없이 CSV, 엑셀, 텍스트 붙여넣기로 시작한다.
- 자동 답글 게시는 하지 않고 초안만 제안한다.

다음 형식으로 PRD 초안을 작성해줘.
1. 문제 정의
2. 목표 사용자
3. 핵심 사용자 흐름
4. Must/Should/Could/Won't 기능
5. 성공 지표
6. 주요 예외 상황
7. 아직 검증되지 않은 가정

검증되지 않은 기능을 새로 추가하지 말고, 추가하고 싶다면 '가정'으로 표시해줘.

이 프롬프트의 핵심은 "검증된 사실"과 "하지 않을 일"을 같이 넣는 것이다. AI에게 방향만 주지 말고 울타리를 줘야 한다. 그래야 AI가 만든 초안이 창의적인 아이디어 모음이 아니라, 지금 만들 제품의 경계 안에 머무른다.

사용자 스토리와 수용 기준으로 바꾼다

PRD가 방향을 정하는 문서라면, 사용자 스토리는 개발 단위를 작게 자르는 문장이다. 보통 다음 형식을 쓴다.

나는 [사용자]로서, [행동]을 하고 싶다. 그래서 [결과]를 얻고 싶다.

예제 서비스의 Must 기능을 사용자 스토리로 바꾸면 이렇다.

• 나는 음식점 사장님으로서 리뷰 파일을 업로드하고 싶다. 그래서 내 매장 리뷰를 분석받고 싶다.

• 나는 카페 사장님으로서 리뷰를 붙여넣고 싶다. 그래서 엑셀 파일이 없어도 분석을 시작하고 싶다.

• 나는 사장님으로서 분석 리포트를 보고 싶다. 그래서 반복 불만과 강점을 한눈에 파악하고 싶다.

• 나는 사장님으로서 답글 초안을 확인하고 싶다. 그래서 고객 리뷰에 더 빠르게 대응하고 싶다.

• 나는 사장님으로서 리포트 링크를 공유하고 싶다. 그래서 직원과 함께 개선할 내용을 논의하고 싶다.

여기서 끝내면 아직 개발하기 어렵다. 각 스토리에 "완료의 기준"이 필요하다. 이를 수용 기준이라고 한다. Given-When-Then 형식은 상황, 행동, 결과를 나눠 요구사항을 명확히 하는 데 유용하다³.

예를 들어 "리뷰 업로드" 스토리의 수용 기준은 이렇게 쓸 수 있다.

사용자 스토리:
나는 음식점 사장님으로서 리뷰 파일을 업로드하고 싶다.
그래서 내 매장 리뷰를 분석받고 싶다.

수용 기준:
1. Given 사용자가 CSV 파일을 선택했을 때,
   When 파일에 리뷰 내용 열이 있으면,
   Then 시스템은 업로드를 완료하고 다음 단계로 이동한다.

2. Given 업로드한 파일의 리뷰가 30개 미만일 때,
   When 사용자가 분석을 요청하면,
   Then 시스템은 "리뷰가 적어 분석 정확도가 낮을 수 있습니다"라는 안내를 보여준다.

3. Given 파일 형식이 지원되지 않을 때,
   When 사용자가 업로드하면,
   Then 시스템은 지원 형식과 해결 방법을 안내한다.

4. Given 리뷰 내용에 전화번호나 이름 같은 개인정보가 포함될 수 있을 때,
   When 분석을 요청하면,
   Then 시스템은 민감정보 포함 가능성을 안내하고 동의를 받는다.

이 정도로 쓰면 개발할 화면과 서버 처리, 에러 메시지가 보이기 시작한다. 다음 장에서 기술 스택을 고를 때도 이 문서가 기준이 된다. "무엇을 만들 수 있는가"보다 "이 흐름을 가장 적은 부담으로 만들려면 무엇을 선택해야 하는가"를 따지게 되기 때문이다.

예외 상황을 먼저 적어야 개발이 덜 흔들린다

초기 제품은 정상 흐름보다 예외 상황에서 더 많이 흔들린다. 특히 AI 기능은 결과가 항상 같지 않고, 입력 데이터 품질에 크게 영향을 받는다.

첫 버전 PRD에는 최소한 다음 예외를 적어둔다.

• 리뷰가 너무 적은 경우

• 리뷰 텍스트가 깨져 있는 경우

• 광고 문구나 메뉴판 설명처럼 리뷰가 아닌 내용이 섞인 경우

• 같은 리뷰가 중복으로 들어간 경우

• AI API 호출이 실패한 경우

• 분석 시간이 예상보다 길어진 경우

• 리포트가 생성됐지만 일부 섹션 품질이 낮은 경우

• 공유 링크를 받은 사람이 권한 없이 민감한 내용을 볼 수 있는 경우

예외를 모두 완벽하게 처리하자는 뜻이 아니다. 어떤 예외는 안내 문구로 충분하고, 어떤 예외는 처음부터 막아야 한다. 중요한 것은 개발 전에 위험을 보는 것이다.

예를 들어 공유 링크는 편리하지만 위험도 있다. 매장 운영 개선점, 고객 불만, 내부 대응 방향이 담길 수 있기 때문이다. 첫 버전에서는 복잡한 권한 체계를 만들지 않는 대신, 공유 링크 생성 시 "링크를 가진 사람은 리포트를 볼 수 있습니다"라는 안내를 명확히 보여줄 수 있다. 필요하면 링크 비활성화 기능만 작게 넣는다.

AI 분석 결과도 마찬가지다. 첫 버전에서 모든 결과를 완벽하게 보장할 수는 없다. 대신 "결과는 입력된 리뷰를 바탕으로 생성되며, 실제 고객 대응 전 검토가 필요합니다" 같은 안내를 넣을 수 있다. 제품이 책임져야 할 부분과 사용자가 확인해야 할 부분을 미리 나눠두면, 개발도 운영도 덜 흔들린다.

첫 PRD는 한 페이지면 충분하다

이 장의 결과물은 두꺼운 문서가 아니다. 아래 정도면 첫 버전 개발을 시작할 수 있다.

제품명: 리뷰 액션 리포트
목표 사용자: 최근 3개월 리뷰 30개 이상인 음식점·카페 사장님
문제: 리뷰는 쌓이지만 반복 불만과 개선 우선순위를 정리할 시간이 없다.
핵심 약속: 리뷰를 업로드하면 오늘 실행할 개선 액션, 답글 초안, 홍보 문구를 담은 리포트를 제공한다.

핵심 흐름:
매장 정보 입력 → 리뷰 업로드 → AI 분석 → 리포트 확인 → 링크 공유

Must:
매장 정보 입력, 리뷰 업로드, 기본 검증, AI 분석, 리포트 화면, 공유 링크

Won't:
리뷰 플랫폼 API 연동, 관리자 페이지, 팀 초대, 복잡한 권한, 자동 답글 게시

성공 지표:
- 업로드 시작 사용자 중 분석 요청 완료 비율
- 분석 완료 후 리포트 확인 비율
- 리포트 공유 링크 생성 비율
- 사용자가 선택한 개선 액션 수

주의 지표:
- 분석 실패율
- 리포트 생성 1건당 AI 비용
- 개인정보 관련 문의
- 결과가 부정확하다는 피드백

좋은 PRD는 기능을 많이 담지 않는다. 지금 만들 제품의 경계를 선명하게 만든다. 다음 장부터는 이 경계를 기준으로 기술 스택을 고르고 개발 환경을 세팅한다.

첫 버전의 목표는 "AI 리뷰 관리 SaaS의 모든 가능성"을 보여주는 것이 아니다. 사장님이 리뷰를 올리고, AI가 분석하고, 실행 가능한 리포트를 확인하고, 누군가에게 공유하는 것. 여기까지 끊기지 않게 만드는 것이다.

그 흐름이 작동하면 사업은 다음 질문으로 넘어갈 수 있다. 고객이 이 리포트를 다시 요청하는가. 돈을 내고 받을 만큼 중요하게 느끼는가. 직원과 공유한 뒤 실제 행동이 바뀌는가.

PRD는 그 질문에 도달하기 위한 길을 짧게 만든다.

참고

¹Understanding the MoSCoW prioritization | How to implement it into your project

²How to Use AI for Product Development in 2026

³30 AI Prompts for PRDs, User Stories & Roadmaps (2026)