PM/Article

[아티클 읽기] AI PRD는 무엇이 달라야 하는가?

growingtree 2026. 8. 4. 09:34
728x90

https://yozm.wishket.com/magazine/detail/3809/

 

AI PRD는 무엇이 달라야 하는가 | 요즘IT

집에서 쓰는 요리 노트는 '소금 약간'으로도 매번 맛있지만, 미슐랭 주방에선 '천일염 2.3g' 이라고 적혀야 누가 만들어도 같은 맛이 납니다. 기존 PRD는 전자에 가까웠습니다. 같은 입력에 같은 출

yozm.wishket.com

 

기존 소프트웨어 PRD의 핵심은 '행동의 정의' -> 동작을 빠짐없이 적어두는 문서 

이런 매커니즘 설계가 가능했던 이유는 기존 소프트웨어가 '결정론적 시스템' 이었기 때문임 

 

AI PRD에서는 '무엇이 일어나야 하는가?' 가 아니라 '어떤 답이 받아들여질만한가' 를 정의해야함 -> 그 받아들여질만 한가는 어떻게 판단할지 함께 설계해야함, 기존 PRD가 단일 행동을 정의했다면, AI PRD는 허용 가능한 답변의 범위를 정의한다 이 두 문서의 가장 근본적인 차이가 됨. 그래서 AI PRD에는 기존 PRD에는 없던 새로운 섹션이 필요하다 : Eval Plan 

 

AI PRD의 새로운 심장 : Eval Plan 

- Eval 은 Evaluation의 줄임말로 AI 기능이 '잘 동작하고 있는가' 를 판단하는 기준이자 도구 

 

- Eval 이 실제로 어떻게 쓰이는가?  : 테스트 케이스의 모음, 이를 쓸 때 사용자가 입력할 만한 질문들을 모아두고 각 질문에 대해 '이런 답이면 합격' , '이런 답이면 불합격' 기준을 적어둠 

 

- 처음에는 20~30개의 케이스로 시작하는데 시간이 지나면서 새로운 실패 케이스를 만나면 스프레드 시트에 한 줄씩 추가가 됨 나중에 6개월이 지나면 200줄 짜리 단단한 Eval 셋이 만들어지는데 이것이 팀의 자산이 됨 

 

- Eval 셋이 200개가 넘어가면 매번 사람이 200개를 다 읽고 채점할 수 없음 -> 실제 운영에서는 평가 방식을 피라미드 모양으로 조합

 

- 피라미드 맨 아래는 규칙 기반 평가 : 명확한 규칙으로 자동 채점하지만 답이 정말 사용자에게 도움이 되는가와 같은 미묘한 평가는 어려움

- 중간층은 LLM-as-a-Judge : 다른 LLM을 채점자로 써서 답의 품질을 평가하게 하는 방식, 사람보다 100배 빠르고 저렴하지만 편향이나 환각의 영향이 있음 

- 꼭대기는 사람의 평가 : 실제 사람이 답을 읽고 점수를 매김 , 이는 정확하지만 가장 느리고 비쌈, 그래서 가장 까다로운 케이스, 새로 발견된 실패 패턴에만 선별적으로 적용 -> 회귀 테스트의 기준점을 만들 때는 사람 평가가 필수적임 

 

 

회귀 테스트 : 프롬프트 수렁의 해결책 

- 어떤 케이스가 잘 안된다고 해서  프롬프트를 손봤더니 잘되던 다른 케이스까지 망가지는 경우 : 프롬프트의 수렁 

- 프롬프트 수렁의 근본 원인은 회귀 테스트의 부재임 -> 이는 코드를 수정할 때마다 기존 기능이 망가지지 않았는지 자동으로 확인하는 것으로 AI 기능의 구현에서도 똑같이 필요함 

 

 

AI PRD에 반드시 들어가야하는 8가지 

1. 기능 개요 : 이 AI 기능이 풀려는 사용자의 문제는 무엇인가? '이 문제는 AI가 가장 잘 풀기 때문에' 라는 답이 나와야함 

2. 입출력 명세 : 사용자가 어떤 형태의 입력을 보내고 시스템은 어떤 출력을 돌려주는가를 미리 정의해둬야함 

3. 시스템 프롬프트의 초안 : 엔지니어가 알아서 짤거다라고 미루지 않고 PM이 PRD에 초안 수준으로라도 명시해야함 

4. 품질 기준 : 이 정도면 합격의 기준 

5. 실패 정의 : 어떤 답이 나오면 실패인지 명시적으로 정의 

6. 평가 계획 : 어떤 입력에 어떤 답이면 합격인지, Eval 셋은 어떻게 관리할 것인지, 평가는 어떤 층으로 운영할 것인지, 회귀테스트는? 

7. 모니터링 계획 : 출시 후 이 기능이 잘 동작하고 있는지를 어떻게 추적할 것인가? 어떤 지표를 대시보드에 띄울 것인가, 어떤 신호가 보이면 알람을 받을 것인가와 같은 정의 

8. 리스크 및 제한 사항 :  이 기능이 가진 한계와 위험을 솔직하게 적어둠 

 

 

가격 전략도 PRD에 적어야한다 

- AI 프로덕트에서 가격 모델이 제품 설계와 분리될 수 없음. 사용자 한 명이 한 번 쓸 때마다 실제 비용이 발생하기 때문 

- 가격 모델과 성공 지표가 따로 노는 AI 프로덕트는 팀이 무엇을 최적화해야할지 모르는 상태로 출발하는 셈 

- AI PRD에서는 기능 정의, Eval Plan, 성공 지표, 가격 모델이 모두 하나의 시스템처럼 정합성을 가져야함 

- AI 시대의 PM은 기능을 정의하는 사람이 아니라 기능의 행동 범위와 판단 기준을 함께 정의하는 사람임 

 

인사이트

- 최종 프로젝트나 MVP 프로젝트에서 AI를 사용할 때 시스템 프롬프트와 품질 기준, 실패 정의 이런 걸 했던 기억이 나는데 우리가 했던 게 사실 꼭 필요한 과정이구나 라는 생각이 들었다 

 

반응형