PRD 작성법: AI에게도 개발사에게도 통하는 요구사항 정의서 만들기

이 글 요약

• AI는 PRD 초안을 빠르게 만들지만, 기능 범위와 제외 범위까지 결정해주지는 않습니다.
• 개발사나 AI 코딩 도구에 전달하려면 화면, 조건, 데이터, 예외 상황 기준으로 다시 정리해야 합니다.

AI로 작성한 PRD는 잘 정리된 것처럼 보입니다. 문제 정의, 사용자 흐름, 기능 목록, 검수 기준이 한 번에 정리되어 있습니다.

그러나 이 PRD를 AI 코딩 도구에 입력하면 기대와 다른 결과물이 생성되는 경우가 많습니다. 잘 쓰인 PRD와 잘 작동하는 PRD는 다르기 때문입니다.

AI로 PRD 초안을 만드는 건 좋은 출발입니다

초안 작성에는 AI를 적극적으로 활용하세요. ChatPRD, Miro AI PRD, Keeborg 같은 도구는 흩어진 자료를 PRD 구조로 정리하고, 빠뜨리기 쉬운 항목까지 제안합니다.

다만 AI는 정해지지 않은 항목까지 채웁니다. 아직 결정하지 않은 범위가 문장 안에서는 이미 정해진 것처럼 보입니다.

예를 들어 AI가 이렇게 써줬다고 가정해보겠습니다.

사용자는 관심사와 이용 데이터를 기반으로 개인화된 상품 추천을 받을 수 있다.

글로는 완성된 듯 보이지만, 결정해야 할 항목이 다음과 같이 남아 있습니다.

• 추천에 사용할 데이터가 이미 있나요?
• AI 모델을 새로 만드나요, 규칙 기반으로 시작하나요?
• 추천 결과가 없을 때는 무엇을 보여주나요?

이 항목들이 비어 있는 PRD로는 개발 범위를 정할 수 없습니다. 추천 기준, 제외 기능, 예외 화면이 아직 정해지지 않았기 때문입니다.

PRD를 맡기기 전에 입력해야 할 5가지 정보

AI가 만드는 PRD 초안은 입력한 정보만큼 구체적입니다. “중고거래 앱 PRD 작성해줘”라고만 쓰면 AI는 일반적인 중고거래 앱을 상상합니다. 다음 다섯 가지를 함께 입력하면 초안이 현실적인 방향으로 좁혀집니다.

항목	입력해야 할 내용
1. 타깃 사용자	누구를 위한 서비스인지
2. 핵심 문제	사용자가 어떤 상황에서 무엇 때문에 불편한지
3. 비즈니스 목표	가입, 구매 전환, 운영 부담 감소 등 무엇을 보고 싶은지
4. 현실적 제약	예산, 일정, 보유 데이터, 운영 인력
5. 제외할 기능	이번 버전에서 빼고 갈 기능

처음에는 이 정도면 충분합니다.

너는 앱 서비스 기획자다.
아래 아이디어를 PRD 초안으로 정리해줘.

- 서비스: 동네 기반 중고거래 앱
- 타깃: 육아용품을 자주 사고파는 30대 부모
- 핵심 문제: 새 제품을 사기엔 부담스럽지만, 기존 중고거래 앱은 검색과 신뢰 확인이 번거롭다
- 1차 목표: 상품 등록과 문의 흐름을 2주 안에 검증한다
- 제약: 앱 푸시와 실시간 채팅은 1차 범위에서 제외한다
- 필요한 출력: 핵심 사용자 흐름, 필수 기능, 제외할 기능, 검수 기준, 예외 상황

중요한 것은 문장의 완성도가 아니라 맥락입니다. AI가 일반론으로 채우지 않도록 실제 조건을 알려줘야 합니다.

짧은 요청은 일반적인 기능 목록에 그치기 쉽고, 사용자·문제·목표·제약을 함께 입력하면 검토 가능한 PRD 초안에 가까워집니다.

조심해야 할 기능 단어 6가지

AI 초안에 아래 단어가 보이면 범위를 다시 확인하세요. 문서에서는 한 줄이지만, 개발 단계에서는 결정해야 할 항목이 여러 개입니다.

• 추천: 어떤 데이터를 기준으로 추천하는지, 추천 결과가 없으면 무엇을 보여줄지 정해야 합니다.
• 결제: 단건 결제인지 정기결제인지, 환불·부분취소·쿠폰·포인트가 포함되는지 확인해야 합니다.
• 채팅: 실시간 채팅인지 단순 문의 메시지인지, 이미지 첨부와 읽음 표시가 필요한지 나눠야 합니다.
• 관리자: 조회만 하는지, 수정·승인·권한 관리까지 필요한지 정해야 합니다.
• 검색: 키워드 검색만 할지, 필터·정렬·자동완성까지 넣을지 확인해야 합니다.
• 위치 기반: 위치 권한, 지도, 거리순 정렬, 길찾기, 권한 거부 시 대체 흐름을 나눠야 합니다.

요구사항 정의서에서는 이 단어들을 네 가지 기준으로 다시 적어야 합니다. 어느 화면에 들어가는지, 어떤 조건에서 동작하는지, 무엇을 보여주는지, 이번 버전에서 무엇을 제외하는지를 정해야 합니다.

이 단어를 그대로 둔 채 AI 코딩 도구에 PRD를 넘기면 문제가 더 커집니다. “추천”이라고만 적힌 PRD를 받으면 도구는 자기 기준으로 임의의 추천 UI를 만듭니다. 이후에 다시 만들거나 더 큰 비용을 들여 수정해야 합니다.

AI 초안에서 먼저 확인할 5가지

기능 단어를 다듬었다면, 다음은 PRD 전체를 점검할 차례입니다. 검토할 때는 표현보다 범위를 먼저 봅니다.

• 이 문제가 실제 고객 문제와 맞는가?
• 이번 버전에서 꼭 필요한 기능과 나중에 해도 되는 기능이 나뉘어 있는가?
• 개발이 끝났을 때 완료 여부를 판단할 수 있는 검수 기준이 있는가?
• 데이터가 없거나, 권한이 없거나, 결제가 실패하는 상황이 빠져 있지 않은가?
• 개발사나 AI 코딩 도구가 화면과 기능 단위로 나눠 작업할 수 있는가?

AI PRD 도구는 검수 기준과 예외 상황을 잘 제안합니다. 다만 그 기준이 우리 서비스의 운영 방식과 맞는지는 사람이 확인해야 합니다. AI가 제안한 기준은 그대로 확정하지 말고, 실제 운영 방식과 개발 범위에 맞춰 다시 검토합니다.

AI 초안을 요구사항 정의서로 다듬는 법

AI 초안은 보통 기능을 한 문장으로 정리합니다. 개발사 전달용 요구사항은 그 문장을 화면, 조건, 제외 범위, 검수 기준으로 나눕니다. 자세히 쓰는 것이 아니라, 판단해야 할 항목을 분명히 드러내는 것이 목표입니다.

예를 들어 개인화 추천이라고 쓰면 좋아 보이지만, 개발사 입장에서는 정해진 것이 거의 없습니다. 사용자가 고른 관심 카테고리를 보여주는 수준인지, 실제 구매 이력을 분석하는 것인지, 별도 AI 모델을 만드는 것인지에 따라 범위가 달라집니다.

AI 초안:

사용자는 개인화된 상품 추천을 받을 수 있다.

정리 후:

사용자는 회원가입 시 선택한 관심 카테고리와 최근 조회 상품을 기준으로 추천 상품을 확인할 수 있다. 추천 결과가 없는 경우 기본 인기 상품을 보여준다. 1차 범위에서는 AI 모델, 구매 이력 기반 추천, 실시간 랭킹 추천을 제외한다.

이때 AI에게 후속 질문을 하면 시나리오를 빠르게 늘릴 수 있습니다. “추천 결과가 없을 때 대체 화면을 3가지 시나리오로 제안해줘”라고 입력하면 AI는 일반적인 시나리오를 제시합니다. 그중 어떤 시나리오가 우리 서비스의 운영 방식과 맞는지는 기획자가 판단해야 합니다.

결제 기능도 같은 방식으로 다듬습니다.

AI 초안:

사용자는 앱에서 상품을 결제할 수 있다.

결제는 결정해야 할 항목이 많습니다. 결제 수단, 주문 생성, 결제 성공과 실패, 환불, 부분취소, 쿠폰, 포인트, 정산, 관리자 주문 관리 중 어디까지 포함할지 정해야 합니다.

정리 후:

사용자는 상품 상세 화면에서 단건 결제를 진행할 수 있다. 결제 수단은 신용카드와 간편결제를 포함한다. 결제 성공 시 주문 상세 화면으로 이동하고, 결제 실패 시 주문 실패 화면을 노출한다. 1차 범위에서는 쿠폰, 포인트, 정기결제, 부분취소, 자동 정산 기능을 제외한다. 관리자는 주문 목록에서 결제 상태를 확인할 수 있다.

검수 기준은 더 짧게 정리합니다.

• 사용자는 상품 상세 화면에서 결제를 시작할 수 있어야 한다.
• 결제 성공/실패 결과에 따라 각각 다른 화면이 노출되어야 한다.
• 관리자는 주문 목록에서 결제 완료, 결제 실패 상태를 확인할 수 있어야 한다.

결제 기능은 포함 여부가 아니라 어떤 결제 시나리오까지 책임질지 정해야 합니다. AI에게 “이 결제 흐름에서 빠질 수 있는 예외 상황을 알려줘”라고 물으면 일반적인 예외 목록을 받을 수 있습니다. 그중 우리 서비스에서 실제로 발생하는 상황은 운영 데이터와 정책을 아는 사람이 골라야 합니다.

PRD, 요구사항 정의서, 기능정의서의 차이

PRD, 요구사항 정의서, 기능정의서는 조직이나 개발사마다 조금씩 다르게 부릅니다. 중요한 것은 이름이 아니라 문서가 쓰이는 목적입니다.

PRD는 보통 제품이나 기능의 목적, 사용자, 문제, 성공 기준을 설명합니다. 요구사항 정의서는 그 내용을 바탕으로 개발사와 논의할 기능 범위, 화면 흐름, 데이터, 예외 상황, 제외 범위를 정리합니다. 기능정의서는 기능별 상세 동작과 입력값, 권한, 검수 기준까지 더 세밀하게 나눕니다.

AI 코딩 도구를 함께 쓰면 이 경계가 흐려집니다. 하나의 문서가 사람에게는 합의 자료가 되고, AI 코딩 도구에는 작업 지시가 되기 때문입니다. 이럴수록 추상적인 기능 이름보다 검토 가능한 범위와 완료 기준이 중요합니다.

요구사항 정의서가 막혔을 때

AI로 만든 PRD 초안을 개발사에 보내기 애매하다면, 표현이 부족한 것이 아니라 화면과 조건을 덜 정한 경우입니다. AI는 초안을 빠르게 만들지만, 어떤 결정이 필요한지까지 알려주지는 않습니다.

스무타트는 이 단계에서 그 결정을 함께 합니다. 어떤 결정이 필요하고 어떤 선택이 유리한지 함께 판단하며 PRD를 구체화하고, 그 결과를 UX 디자인까지 이어 만듭니다.

앱이나 서비스 개발처럼 예외 상황이 많은 프로젝트는 문서만 다듬기보다 피그마 프로토타입으로 실제 동작을 먼저 검증해보면 아직 정하지 않은 화면과 조건이 눈에 들어옵니다.

이 문서를 보고 무엇을 만들고, 무엇은 만들지 않아야 하는지 알 수 있는가?

이 질문에 답하기 어렵다면, 아직 문장을 더 늘릴 때가 아니라 범위를 정리할 때입니다. 좋은 PRD는 더 많이 쓰는 것이 아니라 더 분명히 정하는 것입니다.