제품 기획과 개발의 나침반 역할을 하는 PRD(Product Requirements Document, 제품 요구사항 정의서)는 성공적인 프로덕트를 만들기 위한 가장 핵심적인 문서입니다. 전통적인 IT 및 소프트웨어 개발 분야에서 PRD는 ‘어떤 기능을, 왜, 누구를 위해 만드는가’를 명확히 정의하고, 디자인 및 개발 팀이 동일한 목표를 향해 나아갈 수 있도록 돕는 커뮤니케이션의 기준점 역할을 해왔습니다.
하지만 챗봇, 추천 알고리즘, 생성형 AI 등 인공지능(AI) 기술이 제품의 핵심 가치로 자리 잡으면서, 기존의 소프트웨어 기획 방식만으로는 완벽한 PRD를 작성하기 어려워졌습니다. AI 제품은 본질적으로 불확실성을 내포하고 있으며, 코드가 아닌 데이터에 의해 동작 방식이 결정되기 때문입니다.
성공적인 AI 서비스 구축을 위해 제품 관리자(PM, PO)와 기획자는 기술의 한계와 가능성을 이해하고, 이를 PRD에 촘촘하게 녹여내야 합니다. 이 글에서는 기존 소프트웨어와 AI 제품의 차이점을 분석하고, AI 기반 서비스를 설계할 때 반드시 포함되어야 할 핵심적인 PRD 구성 요소와 작성 가이드를 상세히 안내합니다.
1. 전통적인 소프트웨어 PRD vs AI PRD의 결정적 차이
AI 서비스 기획이 어려운 이유는 기저에 깔린 작동 원리가 전통적인 소프트웨어와 완전히 다르기 때문입니다. 이 차이를 명확히 이해하는 것이 AI PRD 작성의 첫걸음입니다.
| 구분 | 전통적인 소프트웨어 기획 | AI / 머신러닝 기반 기획 |
| 결과물의 성격 | 결정론적 (Deterministic): 입력(A)이 주어지면 항상 동일한 결과(B)가 나옴 | 확률론적 (Probabilistic): 입력(A)이 주어질 때 결과(B)가 나올 확률이 가장 높은 것을 예측함 |
| 핵심 동력 | 로직과 코드 (Logic & Code): 개발자가 작성한 규칙에 따라 동작 | 데이터 (Data): 양질의 학습 데이터가 모델의 성능과 동작을 결정 |
| 예외 처리 방식 | 버그 수정 및 예외 조건(If-else) 추가를 통한 명확한 해결 | 모델 재학습, 데이터 보강, 프롬프트 엔지니어링을 통한 점진적 개선 |
| 사용자 경험(UX) | 예상된 경로(Happy Path)를 따라 완벽하게 통제된 경험 제공 | AI가 실수할 수 있음(Hallucination 등)을 전제로 한 통제 불가능성 대비 필요 |
| 완성 시점 | 배포(Release) 시점에 완성도가 가장 높음 | 배포 후 실제 사용자 데이터를 학습하며 지속적으로 발전(Continuous Learning) |
전통적인 소프트웨어는 '100% 작동하거나 오류가 나거나' 둘 중 하나입니다. 하지만 AI 서비스는 '95%의 정확도를 가지며 5%의 오작동 가능성'을 항상 내포합니다. 따라서 AI PRD는 "이 5%의 실패를 비즈니스와 사용자가 어떻게 수용하고 대처할 것인가?"에 대한 철저한 계획을 포함해야 합니다.
2. AI 서비스 설계를 위한 PRD 필수 구성 요소
일반적인 PRD에 들어가는 배경, 목적, 타깃 유저 정의 외에, AI 제품 개발을 위해 추가적으로 심도 있게 다뤄야 할 핵심 영역은 다음과 같습니다.
가. 문제 정의 및 AI 도입의 타당성 (Problem & Feasibility)
모든 문제에 AI가 필요한 것은 아닙니다. 때로는 단순한 규칙 기반(Rule-based) 알고리즘이 훨씬 저렴하고 빠를 수 있습니다. PRD의 서두에서는 왜 반드시 AI를 사용해야 하는지에 대한 비즈니스적 타당성을 증명해야 합니다.
- 해결하려는 핵심 문제: 사용자의 어떤 Pain Point를 해결하는가? (예: 방대한 문서에서 특정 정보를 찾는 데 시간이 너무 오래 걸림)
- AI 도입의 가치: AI가 이 문제를 해결함으로써 얻는 정량적 기대 효과는 무엇인가? (예: 작업 시간 80% 단축, 개인화된 경험을 통한 전환율 30% 향상)
- 대안 비교: AI를 쓰지 않고 기존 방식을 유지했을 때의 한계점 명시.
나. 데이터 요구사항 (Data Requirements) - AI PRD의 핵심
데이터는 AI 모델의 식량이자 본질입니다. "어떤 데이터를 기반으로 학습하고 작동할 것인가?"를 PRD에서 명확히 규정하지 않으면 개발팀은 모델 구축을 시작조차 할 수 없습니다.
- 데이터 소스(Source): 모델 학습 및 추론에 필요한 데이터는 어디서 가져오는가? (내부 DB, 외부 API, 크롤링, 오픈소스 데이터셋 등)
- 데이터의 양과 질: 최소한으로 필요한 데이터의 규모는 어느 정도인가? 결측치나 노이즈 데이터는 어떻게 처리할 것인가?
- 데이터 레이블링(Labeling) 계획: 지도학습(Supervised Learning)의 경우 정답지를 누가, 어떻게 만들 것인가? (내부 인력 활용, 크라우드소싱 업체 외주 등)
- 개인정보 보호 및 보안 (Compliance): 데이터에 민감한 개인정보(PII)가 포함되어 있는가? 비식별화(Masking) 처리는 어느 단계에서 수행할 것인가? (GDPR, 개인정보보호법 준수 여부)
다. 모델 성능 지표 및 비즈니스 성공 지표 (Metrics)
AI 모델의 성능이 좋다고 해서 무조건 비즈니스가 성공하는 것은 아닙니다. 기획자는 개발자가 보는 '기술적 지표'와 이해관계자가 보는 '비즈니스 지표'를 연결해야 합니다.
- 모델 평가 지표 (Model Metrics):
- 정확도(Accuracy): 전체 예측 중 맞춘 비율.
- 정밀도(Precision): AI가 '정답'이라고 예측한 것 중 실제 정답의 비율. (예: 스팸 메일 필터링에서 정상 메일을 스팸으로 걸러내면 안 될 때 중요)
- 재현율(Recall): 실제 정답 중 AI가 맞춘 비율. (예: 암 진단 AI처럼 병을 놓치지 않고 찾아내는 것이 훨씬 중요할 때 우선시됨)
- 기획자는 해당 서비스의 성격에 따라 Precision과 Recall 중 무엇을 더 타협하고 우선시할지 정의해야 합니다.
- 비즈니스 지표 (Business Metrics): AI 도입 후 사용자의 체류 시간 증가, 고객 센터 문의 응대율 증가, 이탈률 감소 등.
- 지연 시간(Latency) 및 리소스 요구사항: 사용자가 입력을 넣고 AI의 답변을 받기까지 허용되는 최대 대기 시간 (예: "99%의 요청은 2초 이내에 처리되어야 함").
라. 사용자 경험(UX) 및 불확실성 관리 (UX & Edge Cases)
AI는 완벽하지 않으며, 이 불완전성을 부드럽게 감싸는 것이 기획자와 디자이너의 역할입니다. AI PRD에는 예외 상황(Edge Case)에 대한 UX 시나리오가 반드시 포함되어야 합니다.
- 기대치 설정 (Managing Expectations): 사용자가 AI의 한계를 이해하도록 안내하는 문구. (예: "AI가 생성한 답변이므로 부정확할 수 있습니다.")
- 피드백 루프 (Human-in-the-Loop): 모델이 지속적으로 발전할 수 있도록 사용자로부터 피드백을 수집하는 장치. (예: 챗봇 답변 아래의 '좋아요/싫어요' 버튼, 번역 결과 수정 제안 기능)
- 대체(Fallback) 시나리오: 모델이 응답을 생성하지 못하거나 시스템 에러가 발생했을 때의 대처 방안. (예: "원하시는 답변을 찾지 못했습니다. 상담원 연결을 도와드릴까요?")
- 환각(Hallucination) 및 편향성 통제: 생성형 AI가 거짓 정보를 말하거나 윤리적으로 부적절한 발언을 했을 때 이를 필터링하는 가드레일 정책.
3. 성공적인 AI PRD 작성을 위한 3가지 실무 원칙
위의 구성 요소를 바탕으로 실제로 PRD를 작성할 때 기획자가 염두에 두어야 할 원칙입니다.
첫째, 투명한 커뮤니케이션을 위한 '블랙박스' 해소입니다.
AI는 종종 왜 그런 결과가 나왔는지 설명하기 어려운 '블랙박스' 특성을 가집니다. 사용자에게 이 추천/결과가 왜 제공되었는지 최소한의 설명(Explainability)을 제공하는 방안을 고민해야 합니다. (예: "고객님이 최근 시청한 A 콘텐츠를 기반으로 한 추천입니다.")
둘째, 운영 비용(Cost)과 확장성(Scalability) 고려입니다.
GPT-4와 같은 거대 언어 모델(LLM) API를 사용하거나 고성능 GPU를 사용할 경우, 트래픽이 늘어날수록 엄청난 비용이 발생할 수 있습니다. PRD에는 예상 트래픽과 허용 가능한 API 호출 비용의 한계선, 토큰(Token) 수 제한 등에 대한 기준이 명시되어야 합니다.
셋째, 유연한 '애자일(Agile)' 접근입니다.
기존 소프트웨어는 기획-디자인-개발-QA의 폭포수(Waterfall) 모델로도 어느 정도 관리가 가능했지만, AI 제품은 개발팀이 초기 데이터로 모델을 돌려보기 전까지는 성능을 장담할 수 없습니다. 따라서 초기 PRD는 완벽한 바이블이라기보다는, 데이터 검증(PoC) 결과에 따라 목표 지표나 기능이 언제든 수정될 수 있는 '살아있는 문서(Living Document)'로 다루어져야 합니다.
4. [실전 예시] AI 기반 사내 문서 검색 어시스턴트 PRD 요약
이론을 바탕으로 실제 PRD의 핵심 섹션이 어떻게 작성되는지 간단한 예시를 살펴보겠습니다.
1. 제품 개요 및 목표 (Overview & Goals)
- 목표: 방대한 사내 규정 및 기술 문서를 자연어 질의응답(QA) 형태로 쉽게 찾아주는 생성형 AI 검색 어시스턴트 구축.
- 성공 지표: 사내 직원의 정보 검색 소요 시간 주당 3시간 단축, 답변 만족도(Thumbs up) 80% 이상 달성.
2. 데이터 요구사항 (Data Requirements)
- 학습/참조 데이터: 사내 Confluence 페이지 5만 건, Google Drive 내 규정 PDF 파일. (매일 자정 동기화)
- 보안: 부서별 접근 권한(RBAC)이 연동되어야 하며, 인사/재무팀의 기밀문서는 권한이 없는 직원의 AI 답변 생성에 참조되어서는 안 됨.
3. AI 모델 성능 및 제약 (Model & Constraints)
- 방식: RAG (검색 증강 생성) 기반 아키텍처 사용.
- 평가 지표 (Metric): > * 환각(Hallucination) 방지를 위해 Precision(정밀도)을 최우선으로 함. 모르는 내용은 억지로 지어내지 않고 "문서에서 찾을 수 없습니다"라고 답변하도록 프롬프트 설계.
- 지연 시간: 질문 입력 후 첫 글자 생성(TTFB)까지 3초 이내.
4. 사용자 경험 및 예외 처리 (UX & Edge Cases)
- 출처 표기 의무화: 생성된 답변 하단에 반드시 참조한 사내 문서 링크 1~3개를 칩(Chip) 형태로 제공하여 사용자가 팩트 체크를 할 수 있게 유도.
- Fallback: 2회 이상 연속으로 답변에 실패할 경우, 해당 키워드로 사내 그룹웨어 기존 검색창으로 연결하는 버튼 제공.
결론: AI 시대, 기획자의 역할은 '통제'가 아닌 '조율'
과거의 IT 기획이 완벽한 톱니바퀴를 설계하는 일이었다면, 인공지능 시대의 기획은 살아 움직이는 생태계를 가꾸는 일과 같습니다. AI 모델은 완벽할 수 없으며, 예측하지 못한 변수와 사용자 패턴에 끊임없이 노출됩니다.
따라서 훌륭한 AI PRD는 모든 것을 완벽하게 정의하고 통제하려는 강박에서 벗어나야 합니다. 대신 AI의 한계를 명확히 인정하고, 데이터 파이프라인을 견고하게 설계하며, 비즈니스 목표와 모델의 기술적 지표 사이의 균형을 맞추는 '조율'에 집중해야 합니다.
명확한 데이터 요구사항, 정교한 성능 지표, 그리고 인간 중심의 예외 처리 시나리오가 촘촘히 엮인 PRD야말로, 불확실한 AI 기술을 성공적이고 안정적인 '제품'으로 탈바꿈시키는 가장 강력한 무기가 될 것입니다.