새로운 시대의 AI 프로덕트가 기존의 프로덕트와 무엇이 다른지를 다룹니다. PM의 관점에서 말하지만, AI 프로덕트를 다루는 모두 참고할 만한 이야기를 묶었습니다. 필자가 출간할 예정인 〈AI Product Management(가제)〉 책의 일부를 요즘IT 독자의 시선에 맞춰 재가공했습니다.

① AI는 왜 자꾸 틀리는가
② PM은 LLM을 어디까지 이해해야 할까?
③ AI 기능은 프롬프트가 아니라 시스템으로 만든다
④ AI PRD는 무엇이 달라야 하는가

집에서 어머니가 쓰시는 요리 노트를 한 번 펼쳐봅시다. “소금 약간”, “국간장 한 큰술”, “불 줄여 한소끔 끓이기.” 우리는 이 익숙한 표현에 어색함을 느끼지 못합니다. 어머니는 “약간”이 얼마인지 손끝의 감각으로 재고, “한소끔”이 어느 정도인지 냄비의 소리로 짐작합니다. 그래도 결과는 매번 맛있습니다.

한편 미슐랭 별을 받은 셰프의 레시피를 보면 어떨까요? 같은 미역국이라도 표현이 다릅니다. “천일염 2.3g”, “국간장 15ml”, “75°C 유지하며 정확히 4분간 끓임.” 단위가 다르고, 단어가 다르며, 무엇보다 “읽고 그대로 따라 했을 때 같은 결과가 나오도록” 정밀하게 정의되어 있습니다.

두 레시피는 같은 음식을 만들기 위한 자료처럼 보이지만, 사실 전혀 다른 문서입니다. 어머니의 레시피는 “이미 요리를 아는 사람을 위한 참고서”이고, 셰프의 레시피는 “이 요리를 처음 보는 사람도 같은 결과를 만들어내도록 하는 설계도”입니다. 미슐랭 레스토랑 주방에서 어머니의 “소금 약간”으로 레시피를 운용한다면, 서로 다른 셰프가 만들었을 때 음식 맛이 완전히 달라질 것입니다. 그건 레스토랑의 지속성을 해치는 일입니다.

PRD(Product Requirements Document, 제품 요구사항 정의서)도 비슷합니다. 기존 소프트웨어의 PRD는 어머니의 레시피에 가까웠습니다. “버튼을 누르면 결제 페이지로 이동한다” 정도의 정의만으로도 엔지니어가 자기 손끝의 감각을 믿으며 만들어냈고, 결과는 매번 똑같았습니다. 그런데 AI 기능(feature)을 만들 때는 이 스타일로 PRD를 쓰면, 만든 사람마다 결과가 달라질뿐더러, 심지어 같은 사람이 만들어도 매번 결과가 달라집니다.

따라서 AI 시대의 PM에게는 “미슐랭 셰프의 레시피”가 필요합니다. 그게 바로 오늘 다룰 주제입니다. AI PRD는 기존 PRD와 무엇이 어떻게 달라야 할까요?

1. 기존 PRD는 왜 AI 기능에 안 맞는가

기존 소프트웨어 PRD의 핵심은 “행동의 정의”입니다. 사용자가 X를 하면 시스템은 Y를 한다. 사용자가 “결제” 버튼을 누르면 결제 페이지가 뜨고, 카드 정보를 입력하고 “확인”을 누르면 결제가 처리된다. PRD는 이런 동작들을 빠짐없이 적어두는 문서였습니다.

이런 메커니즘의 설계가 가능했던 이유는, 기존 소프트웨어가 결정론적(deterministic) 시스템이었기 때문입니다. 같은 입력에 같은 출력이 나오니까, “무엇이 일어나야 하는가”만 정의하면 충분했습니다. 행동이 정의되면 결과가 따라왔습니다.

AI 기능은 다릅니다. 1편의 에어캐나다 챗봇 사례처럼 사용자가 “가족 사별로 인한 할인이 있나요?”라고 물었을 때, 모델은 어떤 답을 낸다고 정의해야 할까요? PRD에 “고객 지원 챗봇은 사용자의 질문에 정확하게 답한다”라고 적어둔다고 그 답이 정확해질까요? “정확하다”의 기준은 무엇인가요? 90%만 맞히면 정확한 건가요, 99% 맞혀야 하나요? 어떤 질문에는 답하고 어떤 질문에는 답하지 말아야 하나요? 같은 질문에 매번 다른 답이 나오는 것은 버그인가요, 기능인가요?

AI PRD에서는 “무엇이 일어나야 하는가”가 아니라 “어떤 답이 받아들여질 만한가”를 정의해야 합니다. 그리고 그 “받아들여질 만한가”를 어떻게 판단할지 함께 설계해야 합니다. 기존 PRD가 “단일 행동”을 정의했다면, AI PRD는 “허용 가능한 답변의 범위”를 정의합니다. 이게 두 문서의 가장 근본적인 차이입니다.

그래서 AI PRD에는 기존 PRD에 없던 새로운 섹션들이 필요합니다. 그중 가장 중요한 것이 Eval Plan(평가 계획)입니다.

2. AI PRD의 새로운 심장: Eval Plan

Eval(이밸, evaluation의 줄임말)은 AI 기능이 “잘 동작하고 있는가”를 판단하는 기준이자 도구입니다. 그리고 Eval Plan은 그 기준과 도구를 PRD에 명시적으로 적어두는 문서입니다.

쉽게 말하면 이렇습니다. 음식점이 미슐랭 별을 받으려면 평가단이 무엇을 보고 별을 매기는지 알아야 합니다. “신선도”, “창의성”, “일관성” 같은 기준들이죠. AI 기능도 마찬가지입니다. 우리가 만든 챗봇이 “잘 동작하고 있다”고 말하려면, 무엇을 기준으로 그렇게 판단할지를 먼저 정해야 합니다. 기준이 없으면 “잘 동작한다”라는 말은 그저 느낌일 뿐입니다.

Eval은 실제로 어떻게 쓰이는가

Eval Plan이라고 하면 거창해 보이지만, 핵심은 단순합니다. “테스트 케이스의 모음”이라고 생각하면 충분합니다. 이를 쓸 때는 사용자가 입력할 만한 질문들을 모아두고, 각 질문에 대해 “이런 답이면 합격”, “이런 답이면 불합격”의 기준을 적어둡니다. 실제로 많은 팀이 스프레드시트 한 장으로 시작합니다.

예를 들어 고객 지원 챗봇의 Eval 스프레드시트는 이런 식으로 쓰입니다. 한 행에 입력(사용자 질문), 기대 출력(어떤 답이면 좋은가), 실제 출력(모델이 실제로 한 답), 점수, 합격 여부가 들어갑니다. “배송이 늦어요”란 입력에 대한 기대 출력이 “주문 번호 확인 후 배송 상태를 안내하고, 필요시 환불·교환 옵션 제시”라고 하겠습니다. 이때, 실제 출력이 “죄송합니다. 배송이 지연되고 있는 점 양해 부탁드립니다”로 끝나버린다면 그건 불합격입니다. 사용자가 진짜로 알고 싶은 “내 주문은 어떻게 되는가”에 답을 안 해줬으니까요.

처음에는 20~30개 케이스로만 시작해도 충분합니다. 그러다 시간이 지나면서 새로운 실패 케이스가 발견될 때마다 스프레드시트에 한 줄씩 추가합니다. 6개월쯤 지나면 200줄짜리 단단한 Eval 셋이 만들어집니다. 이게 팀의 가장 큰 자산이 됩니다.

Eval 피라미드: 어떻게 평가할 것인가

다만, Eval 셋이 200개가 넘어가면 새로운 문제가 생깁니다. 매번 사람이 200개를 다 읽고 채점할 수는 없다는 것입니다. 그래서 실제 운영에서는 평가 방식을 “피라미드” 모양으로 조합합니다.

피라미드의 맨 아래는 규칙 기반(Rule-based) 평가입니다. “답에 특정 단어가 포함되어야 한다”, “답이 100자를 넘으면 안 된다”, “답에 회사 기밀이 포함되면 안 된다” 같은 명확한 규칙으로 답변을 자동 채점합니다. 빠르고 비용이 거의 들지 않습니다. 대신 “답이 정말 사용자에게 도움이 되는가” 같은 미묘한 평가는 어렵습니다.

중간층은 LLM-as-a-Judge입니다. 다른 LLM을 “채점자”로 써서 답의 품질을 평가하게 하는 방식입니다. “이 답이 사용자 질문에 적절한가?”를 사람 대신 LLM이 판단합니다. 사람보다 100배 빠르고 훨씬 저렴하지만, 채점자 LLM 자체의 편향이나 환각이 영향을 줄 수 있어 완전히 믿을 수는 없습니다.

꼭대기는 사람 평가(Human Eval)입니다. 실제 사람이 답을 읽고 점수를 매깁니다. 가장 정확하지만 가장 느리고 비쌉니다. 그래서 가장 까다로운 케이스, 또는 새로 발견된 실패 패턴에만 선별적으로 적용합니다. 무엇보다 회귀 테스트의 “기준점”을 만들 때는 사람 평가가 필수입니다.

실제 운영 과정에서는 이 세 가지를 피라미드처럼 쌓아서 운영합니다. 일상적으로는 규칙 기반과 LLM-as-a-Judge로 빠르게 돌리고, 중요한 변경이 있을 때 사람 평가를 추가합니다. PM이 Eval Plan을 짤 때 “이 케이스는 어느 층으로 평가할 것인가”를 함께 정해두면, 출시 후 평가 비용이 통제됩니다.

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

AI 기능을 만들어 본 PM이라면 다들 한 번씩 겪는 일이 있습니다. 어떤 케이스가 잘 안된다고 해서 프롬프트를 손봤더니, 잘 되던 다른 케이스가 갑자기 망가지는 것입니다. A를 고치니 B가 깨지고, B를 고치니 C가 깨지고. 이걸 업계에서는 “프롬프트 수렁(Prompt Swamp)”이라고 부릅니다. 시간은 다 쓰는데 전체 성능은 그대로인 늪 같은 상태입니다.

프롬프트 수렁의 근본 원인은 회귀 테스트(regression test)의 부재입니다. 이 테스트는 소프트웨어에서 코드를 수정할 때마다 기존 기능이 망가지지 않았는지 자동으로 확인하는 것으로, AI 기능의 구현에서도 똑같이 필요합니다. 프롬프트를 수정할 때마다 그동안 누적된 Eval 셋 전체를 다시 돌려서, 점수가 떨어진 케이스가 없는지 확인하는 식입니다. 이게 안 되면 우리는 영원히 “이쪽 고치면 저쪽이 망가지는” 순환에 갇히고 맙니다.

Eval Plan이 PRD에 명시되어 있다는 건, 결국 “이 기능을 출시한 후에도 팀은 계속 같은 기준으로 성능을 측정할 것이며, 그 기준은 시간이 지나면서 더 단단해질 것”이라는 약속입니다. 이 약속이 PRD에 적혀 있느냐 없느냐가, 6개월 후 그 기능의 운명을 가릅니다.

3. AI PRD에 반드시 들어가야 할 8가지

그렇다면 Eval Plan을 포함해서, AI PRD에 빠뜨리지 말아야 할 것은 무엇일까요? 다음 여덟 가지가 기본 체크리스트입니다. 일반 PRD에도 있는 항목들이지만, AI 맥락에서는 채워야 할 내용이 다릅니다.

1. 기능 개요: 이 AI 기능이 풀려는 사용자 문제는 무엇인가? 여기에는 “AI를 쓰고 싶어서”가 아니라 “이 문제는 AI가 가장 잘 풀기 때문에”라는 답이 나와야 합니다. AI를 위한 AI는 가장 흔한 실패의 출발점입니다.

2. 입출력 명세: 사용자가 어떤 형태의 입력을 보내고, 시스템은 어떤 형태의 출력을 돌려주는가? 텍스트인가, 이미지인가, 길이는 어느 정도인가, 어떤 언어를 지원하는가. 입력의 범위와 출력의 형식을 미리 정의해두지 않으면, 모델이 받는 “날것의 입력”이 무엇이 될지 통제할 수 없습니다.

3. 시스템 프롬프트 초안: 3편에서 다룬 시스템 프롬프트를 PRD 단계에서 미리 짜둡니다. 모델의 역할, 답변의 톤과 형식, 참고해야 할 정보, 하지 말아야 할 것, 막혔을 때의 출구 등등. “엔지니어가 알아서 짤 거다”라고 미루지 않고, PM이 PRD에 초안 수준으로라도 명시합니다. 이게 곧 기능의 “인격”을 결정합니다.

4. 품질 기준: “이 정도면 합격”의 기준입니다. 사실관계는 어디까지 정확해야 하는가, 톤은 어떠해야 하는가, 답변의 길이는 어느 정도여야 하는가. 이 기준이 명확해야 다음에 나오는 Eval Plan을 짤 수 있습니다.

5. 실패 정의: 어떤 답이 나오면 “실패”인지를 명시적으로 정의합니다. 사실과 다른 정보를 자신만만하게 답한 경우(환각), 회사 정책과 어긋나는 약속을 한 경우, 사용자에게 위험한 조언을 한 경우 등등. 에어캐나다 챗봇 사고는 이 “실패 정의”가 PRD에 없었기 때문에 일어났습니다. 무엇이 실패인지 모르면 막을 수도 없습니다.

6. 평가 계획: 위에서 자세히 다룬 그 내용입니다. 어떤 입력에 어떤 답이면 합격인지, Eval 셋은 어떻게 관리할 것인지, 평가는 어떤 층(규칙 기반/LLM-as-a-Judge/사람)으로 운영할 것인지, 회귀 테스트는 어떻게 돌릴 것인지 다룹니다.

7. 모니터링 계획: 출시 후 이 기능이 잘 동작하고 있는지를 어떻게 추적할 것인가? 어떤 지표를 대시보드에 띄울 것인가, 어떤 신호가 보이면 알람을 받을 것인가, 어떤 주기로 Eval을 다시 돌릴 것인가 정의합니다. AI 프로덕트의 성공 지표는 다음 회에서 다루겠지만, 그 지표를 “어떻게 관찰할 것인가”는 이미 PRD에 들어가야 합니다.

8. 리스크 및 제한사항: 이 기능이 가진 한계와 위험을 솔직하게 적어둡니다. 어떤 도메인에서는 잘 동작하지 않는가, 비용은 어떤 시나리오에서 폭발할 수 있는가, 규제 측면에서 어떤 위험이 있는가. 흔히 PRD의 가장 짧은 섹션이지만, 위기 상황에서 가장 자주 들춰지는 부분입니다.

이 여덟 가지가 다 들어 있는 PRD라면, “미슐랭 셰프의 레시피”에 가깝습니다. 누가 만들든 비슷한 결과가 나오고, 만든 결과가 "잘 됐는지" 객관적으로 판단할 수 있습니다.

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

마지막으로 한 가지 더. AI 프로덕트의 PRD에는 기존 PRD에서는 잘 다루지 않았던 항목이 하나 더 있어야 합니다. 가격 모델입니다.

“가격은 비즈니스팀이 정하는 거 아닌가요?”라고 물으실 수 있습니다. 기존 SaaS에서는 그랬습니다.

그런데 AI 프로덕트에서는 가격 모델이 제품 설계와 분리될 수 없습니다. 왜냐하면 여기서는 사용자 한 명이 한 번 쓸 때마다 실제 비용(토큰 비용)이 발생하기 때문입니다. 기존 SaaS처럼 “한 명당 월 9,900원”으로 받았다가, 그 사용자가 PDF를 계속 붙여 넣고 요약을 시키면 한 달 만에 9,900원의 열 배가 넘는 비용이 나갑니다.

최근 AI 프로덕트의 가격 모델은 크게 세 방향으로 진화하고 있습니다.

첫째, 사용량 기반(Usage-based). 토큰이나 API 호출 단위로 과금. OpenAI의 토큰 과금이 대표적입니다.

둘째, 성과 기반(Outcome-based). “해결된 케이스 1건당” 같은 비즈니스 성과로 과금. Zendesk나 Intercom의 AI 고객 지원이 이 방식입니다.

셋째, 하이브리드(Hybrid). 기본료 + 사용량 추가. 실제로 가장 많이 채택되는 방식입니다.

PM이 PRD를 쓸 때 이 가격 모델을 어떻게 잡을지가 제품 설계에 직접 영향을 줍니다. 만약 성과 기반으로 간다면, PRD의 성공 지표도 성과 중심으로 설계되어야 합니다. “해결된 케이스” 단위로 과금하기로 했다면, 무엇이 “해결”인지를 Eval Plan에서 먼저 정의해야 하니까요. 가격 모델과 성공 지표가 따로 노는 AI 프로덕트는, 팀이 무엇을 최적화해야 할지 모르는 상태로 출발하는 셈입니다.

실제 시장에서도 이 정합성의 차이가 명백히 드러나고 있습니다. 세일즈포스는 Agentforce를 통해 고객사의 작업 시간을 큰 폭으로 줄이는 가치를 만들어내고, 그것을 Flex Credits라는 사용량 기반 과금으로 명확히 연결했습니다. 가치 창출과 가격 모델이 한 방향으로 정렬되니까 시장이 신뢰하기 쉽습니다. 반면 어도비는 같은 시기 Firefly로 AI 기능을 출시했지만 그 AI 투자가 어떻게 수익으로 이어질지를 시장에 명확히 설명하지 못했고, 주가는 큰 폭으로 떨어졌습니다. 같은 AI 기능을 출시해도, PRD 단계에서 가격 모델과 가치 정의를 함께 짠 회사와 그렇지 않은 회사의 결과는 다릅니다.

알아가야 할 핵심은 하나입니다. AI PRD에서는 기능 정의, Eval Plan, 성공 지표, 가격 모델이 모두 하나의 시스템처럼 정합성을 가져야 합니다. 어느 하나만 성격이 달라지면 그 PRD는 결국 작동하지 않습니다.

마치며: PRD는 약속이다

처음으로 돌아갑니다. 어머니의 “소금 약간”과 셰프의 “천일염 2.3g”의 차이는 단순히 정밀도가 아닙니다. 처음 레시피를 쓰는 시점부터 “누가 어떻게 만들든 같은 결과가 나오게 하겠다”는 약속의 강도가 다른 것입니다.

AI PRD도 마찬가지입니다. 기존 PRD가 “이 기능을 만든다”는 약속이었다면, AI PRD는 “이 기능이 어떻게 행동할지, 잘 동작하는지 어떻게 판단할지, 망가지면 어떻게 알아챌지, 비용이 폭발하지 않게 어떻게 막을지”까지 모두 약속하는 문서입니다. 약속의 범위가 훨씬 넓어진 만큼, 문서도 훨씬 정밀해져야 합니다.

그리고 그 약속의 한가운데에 Eval Plan이 있습니다. “잘 동작한다”는 말을 느낌이 아니라 측정 가능한 기준으로 바꿔주는 장치입니다.

시리즈의 가장 처음에서 본 에어캐나다 챗봇 사고도, 결국 “무엇을 답하지 말아야 하는가”가 PRD에 정의되어 있지 않았기 때문에 일어났습니다. 그 챗봇의 PRD에 Eval Plan이 있었다면, 출시 전에 “여행 후 사별 할인 신청” 같은 케이스가 테스트되었을 것이고, 그 답이 회사 정책과 다르다는 점 역시발견되었을 것입니다.

AI 시대의 PM은 “기능을 정의하는 사람”이 아니라 “기능의 행동 범위와 판단 기준을 함께 정의하는 사람”입니다. 그리고 그 정의가 한 장의 PRD에 담길 때, 비로소 AI 기능은 “운에 맡기는 기술”이 아니라 “관리 가능한 시스템”이 됩니다.