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

①AI는 왜 자꾸 틀리는가
②PM은 LLM을 어디까지 이해해야 할까?
③AI 기능은 프롬프트가 아니라 시스템으로 만든다
④ AI PRD는 무엇이 달라야 하는가
⑤ 시장에서 이기는 AI 프로덕트를 위한 지표와 운영법

1908년에 출시된 자동차인 포드 모델 T의 계기판을 본 적이 있으신가요? 이 계기판은 거의 비어 있습니다. 표준 패키지에는 전류계(ammeter, 전기가 충전되고 있는지 방전되고 있는지를 보여주는 계기) 하나만 달려 있으며, 우리가 당연하게 여기는 속도계조차 추가 비용을 내야 받는 옵션이었습니다. 연료 게이지는 아예 없었죠. 운전자는 막대기를 연료 탱크에 직접 꽂아서 기름이 얼마나 남았는지를 쟀습니다. 그때는 차량이라는 기계가 단순했기에 계기판도 단순했습니다.

100년이 지난 지금, 테슬라 모델 Y의 운전석에 앉으면 16인치 화면이 운전자를 맞이합니다. 속도, 배터리 잔량, 추정 주행 거리, 회생 제동률, 자율주행 모드 상태, 충전소 위치, 에너지 효율 그래프, 실시간 카메라 영상 등등. 운전자는 한눈에 수십 개의 정보를 동시에 볼 수 있습니다. 차가 더 복잡해진 만큼, 봐야 할 지표도 폭발적으로 늘어난 것입니다.

AI 프로덕트의 KPI도 똑같은 진화의 길을 걷고 있습니다. 기존 SaaS의 KPI는 모델 T의 계기판처럼 단순했습니다. DAU, MAU, 전환율, 매출. 이 몇 가지만 봐도 프로덕트가 잘 굴러가는지 판단할 수 있었습니다.

문제는 지금이 전환기라는 데 있습니다. 마치 운전자가 모델 T의 계기판으로 테슬라를 몰려고 하는 상황처럼, 어디선가 과거의 지표 기준으로 프로덕트를 판단하는 상황이 펼쳐진 것입니다. “우리 챗봇 잘 동작하고 있어요?”라는 질문에 “DAU가 어제보다 5% 늘었어요”라고 답하는 식입니다. 그 답으로는 챗봇이 환각을 일으키고 있는지, 비용이 폭주하고 있는지, 답변 품질이 떨어지고 있는지를 전혀 알 수 없습니다.

AI 시대의 PM은 새 계기판을 만들어야 합니다. 그리고 그 계기판이 충분히 잘 만들어졌다면, 출시 후에는 그 계기판을 보면서 살아남기까지 해야 합니다. 이번 글에서는 두 가지를 함께 다룹니다. 전반부에서는 기존 KPI를 어떻게 다시 쓸지, AI 고유 지표는 무엇이 있는지를 봅니다. 후반부에서는 그 지표들을 갖고 출시된 AI 프로덕트가 어떻게 살아 움직이며, PM이 그 살아 움직임을 어떻게 추적하는지를 봅니다.

1. 기존 KPI가 깨지는 지점

기존 SaaS의 가장 흔한 KPI는 DAU(Daily Active Users, 일간 활성 사용자)입니다. 매일 얼마나 많은 사람이 우리 서비스를 쓰는가. 인스타그램, 카카오톡 같은 일상 앱은 매일 쓰는 게 정상이니까 이 지표가 자연스럽게 의미를 가졌습니다. 그런데 AI 프로덕트에서는 이 가정이 깨집니다.

ChatGPT를 한번 떠올려봅시다. 여러분은 ChatGPT를 매일 쓰시나요? 어떤 분은 그렇겠지만, 많은 사용자는 “필요할 때만” 씁니다. 일주일에 두세 번, 한 번 쓸 때는 깊게 30분씩. 이 패턴을 DAU로 측정하면 사용자들의 진짜 가치를 과소평가하게 됩니다. 그래서 OpenAI도 공식 지표를 WAU(Weekly Active Users, 주간 활성 사용자)로 옮겼습니다. “매일 쓰지는 않지만, 매주는 쓴다”가 AI 도구의 진짜 사용 패턴이라는 걸 인정한 것입니다.

이건 단순한 지표 변경이 아닙니다. AI 프로덕트가 기존 앱과 본질적으로 다른 사용 패턴을 만들어낸다는 사실을 받아들이는 일입니다. 기존 KPI를 그대로 쓰면, 우리는 잘못된 그림을 보기 쉽습니다. “DAU가 낮으니 이 기능은 실패다”라고 판단할 수도 있지만, 사실은 깊이 잘 쓰이고 있는 기능일 수 있다는 뜻입니다.

그래서 AI PM에게 가장 먼저 필요한 일은, 기존 KPI 중 무엇이 여전히 유효한지, 무엇은 다시 정의해야 하는지, 무엇은 아예 새로 만들어야 하는지를 한 번씩 다시 짚는 것입니다.

2. 기존 프레임워크를 AI 맥락에서 다시 쓰는 법: RICE의 진화

PM이라면 RICE 프레임워크를 들어보셨을 겁니다. 어떤 기능을 먼저 만들지 결정할 때 쓰는 우선순위 계산 도구입니다. Reach(영향 범위), Impact(임팩트), Confidence(확신), Effort(노력/공수) 네 가지를 본다고 해서, 개별 단어의 머리글자를 따 만든 이름입니다. 각 항목에 점수를 매겨서 곱하고 나누면 우선순위 점수가 나옵니다.

이 프레임워크 자체는 AI 시대에도 여전히 유효합니다. 그런데 각 항목의 의미가 미묘하게 달라집니다.

Reach는 기존엔 “이 피처를 보게 될 사용자 수”였습니다. 그러나 AI 프로덕트의 맥락에서는 “AI 기능이 실제로 트리거되는 빈도”로 보는 편이 더 정확합니다. 사용자가 100명이라도, 그중 5명만 AI 기능을 쓴다면 Reach는 100이 아니라 5입니다.

Impact는 “사용자 행동을 얼마나 바꾸는가”였습니다. AI 프로덕트에서는 한 겹 더 들어가야 합니다. “AI의 출력 품질이 비즈니스 결과로 이어지는가”가 낫습니다. 정확한 답을 줘도 사용자가 그것으로 행동을 바꾸지 않으면 Impact는 0입니다.

Confidence가 가장 흥미로운 변화를 겪습니다. 기존엔 “우리 팀이 이 피처가 효과 있을 것이라는 확신”이었습니다. AI 프로덕트에서는 여기에 한 겹이 더 붙습니다. 모델 자체의 확률적 불확실성을 따져보는 겁니다. 우리 인간은 이 기능이 잘 동작할 거라고 확신하지만, 모델이 매번 같은 품질로 답을 줄지는 다른 문제입니다. 그래서 AI에서의 Confidence는 “팀의 확신 × 모델의 일관성”으로 두 겹이 됩니다.

Effort는 기존엔 개발 공수였습니다. AI 프로덕트에서는 데이터 준비, 모델 학습 혹은 프롬프트 튜닝, Eval 셋 구축, 그리고 출시 후 모니터링 체계 구축까지 포함한 총 공수로 산정합니다. 코드 쓰는 시간이 아니라 “이 기능 전체를 운영 가능한 상태로 만드는” 데 드는 모든 노력입니다.

어떤 분들은 이걸 RICE-A(RICE with AI)라고 부르기도 합니다. 같은 프레임이지만 각 항목을 AI 맥락에 맞춰 다시 채우는 것이죠. 기존 SaaS 시대의 RICE 점수와 AI 시대의 RICE-A 점수 기반 측정은 같은 기능에 대해 다른 결론을 내릴 수 있습니다.

3. AI 고유 지표: 기존엔 없었던 새 계기

DAU와 WAU, RICE-A의 탄생처럼 기존 지표를 다시 쓰는 것 외에, AI 프로덕트에는 기존에 아예 없었던 새 지표들 역시 등장합니다. 큰 카테고리로 세 가지가 있습니다.

첫째, 모델 품질 지표

환각률(Hallucination Rate)이 대표적입니다. AI가 사실과 다른 답을 내놓는 비율이죠. RAG 기반 시스템이라면 근거 충실도(Groundedness, 응답이 실제로 제공된 출처(검색된 문서)에 기반하고 있는가)가 핵심 지표가 됩니다. 그 외에 답변 적합도(Answer Relevancy, 응답이 사용자의 질문 의도에 부합하는가), 사실 일치도(Faithfulness, 응답이 주어진 출처 내용을 왜곡 없이 반영했는가) 등이 있습니다.

둘째, 운영·비용 지표

인터랙션 당 토큰 비용(Token Cost per Interaction)은 AI 프로덕트의 수익성을 좌우하는 핵심 지표입니다. 한편 응답 속도(Latency)는 P95로 측정해야 합니다. 평균값(P50)은 “느린 케이스”를 감추기 때문입니다. 즉, 100번 중 95번이 빠르더라도 5번이 5초씩 걸린다면, 그 5번을 만난 사용자는 “이 AI 느리다”고 기억합니다. P95는 그 “최악의 경험”을 측정하는 기준이 됩니다.

셋째, 신뢰·안전 지표

모델 드리프트(Model Drift, 시간이 지나면서 모델 성능이 변하는 정도), 사용자 개입률(Human Override Rate, 사용자가 AI 답을 무시하거나 수정하는 비율), 작업 완료율(Task Completion Rate, 에이전트가 주어진 작업을 끝내는 비율) 같은 것들을 볼 수 있습니다. 이 지표들은 “AI가 사용자에게 정말로 도움이 되고 있는가”를 답해줍니다. 정확도가 99%라도 사용자가 매번 답을 수정한다면, 그 기능은 실질적으로 실패한 것입니다.

이 새 지표들을 어떻게 묶어 볼 것인가도 AI PM이 해야할 새로운 일입니다. 고객 지원 챗봇이라면 해결률(Resolution Rate)이 가장 위에 오고, 그 아래에 사용자 개입률과 환각률이 받치는 구조가 자연스럽습니다. 코딩 어시스턴트라면 코드 채택률(Code Acceptance Rate, 생성된 코드를 사용자가 그대로 채택하는 비율)이 핵심 지표가 되고, 그 아래 지연 속도와 토큰 비용이 비용·성능 균형을 봅니다. 어떤 지표를 “우리 피처의 북극성(North Star)”으로 잡을지가 팀 전체의 방향을 결정합니다.

그와 함께 RAG 기반 시스템을 위한 RAGAS(Retrieval-Augmented Generation Assessment) 같은 평가 프레임워크도 등장하고 있습니다. 근거 충실도, 사실 일치도, 답변 적합도를 종합적으로 측정해주는 도구입니다. 무엇보다 중요한 건 이런 프레임워크가 등장한다는 것 자체가, AI 프로덕트의 측정이 “한두 개의 숫자”가 아니라 “여러 개의 신호를 종합한 판단”으로 바뀌고 있다는 신호라는 점입니다.

이 새 지표들은 AI 프로덕트가 출시될 때 PRD에 미리 명시되어 있어야 합니다. 4편에서 다룬 “AI PRD의 모니터링 계획” 항목이 바로 이걸 미리 정해두는 영역입니다. 출시 후에 “무엇을 측정할지” 고민하기 시작하면 늦습니다.

4. 출시 후 첫 72시간: 가장 많은 것이 드러나는 시간

새 계기판을 만들었으니 이제 운전을 시작합니다. 그런데 AI 프로덕트의 운전은 기존 SaaS의 운전과 결이 다릅니다. 기존 소프트웨어는 출시 후 큰 사고가 없으면 그대로 굴러갔습니다. 반면 AI 프로덕트는 출시 후가 더 바쁩니다. 모델은 살아 움직이고, 사용자는 우리가 예상 못한 입력을 던지고, 비용은 우리가 모르는 사이에 폭주합니다.

그래서 출시 후 첫 72시간이 특히 중요합니다. 이 짧은 시간에 가장 많은 것이 드러나기 때문입니다.

1. 첫 24시간은 “읽는 시간”입니다.

대시보드를 보기 전에 실제 대화를 직접 읽어야 합니다. 사용자가 어떤 질문을 던지는지, 어떤 답에 “좋아요”보다 “싫어요”를 누르는지. 숫자가 아니라 언어에서 먼저 패턴이 보입니다. 이 시기에 가장 값진 정보는 대시보드에 없습니다.

2. 24~48시간 사이에는 “비용”을 봅니다.

PRD에서 추정했던 토큰 비용과 실제 소비량을 비교합니다. 추정의 두 배가 나왔다면 즉시 엔지니어링팀에 알려야 합니다. 조용히 넘어가면 월말 청구서에서 충격을 받습니다.

3. 48~72시간 사이에는 “속도”를 봅니다.

응답 시간 P95가 특정 시간대나 입력 유형에서 급증하는 패턴이 있는지 확인합니다. 응답 품질의 분포에도 변화가 생기기 시작하는 시점이라, 이 흐름을 초기에 잡아두는 것이 이후 안정화의 출발점이 됩니다.

기존 소프트웨어 PM의 출시일은 “기능이 완성된 날”이었습니다. 그러나 AI 프로덕트의 PM에게 출시일은 “진짜 일이 시작된 첫째 날”입니다.

5. 4계층 모니터링: 하나의 대시보드로 보지 마라

AI 프로덕트의 모니터링은 하나의 대시보드로 다 볼 수 없습니다. 인프라가 멀쩡해도 품질이 무너질 수 있고, 품질이 괜찮아도 비용이 폭주할 수 있기 때문입니다. 각 영역이 독립적으로 문제를 일으키기 때문에, 네 가지 층에 시선을 두고 동시에 모든 것을 봐야 합니다.

1계층: 인프라

API 응답 시간, 오류율, 가용성. 기존 소프트웨어 모니터링과 가장 비슷한 영역입니다. 다만 위에서 말한 대로, P95 지연 속도가 P50보다 훨씬 중요합니다. 사용자가 경험하는 “최악의 순간”은 P95에 있습니다.

2계층: 비용

세션당 토큰 비용, 일간·월간 누적 비용, 비용 이상값. “얼마 썼나”를 넘어 “왜 갑자기 올랐나”를 추적할 수 있어야 합니다. 세션 단위, 기능 단위, 사용자 코호트 단위로 비용을 분해해서 봐야 이상값의 원인을 찾을 수 있습니다.

3계층: 품질

환각률, 근거 충실도, 사용자 개입률. 가장 다루기 어려운 영역입니다. 기술적 에러는 로그에 잡히지만, 환각은 잡히지 않습니다. 자동화 평가(LLM-as-judge)와 샘플링 기반 사람 평가를 병행해서 이 계층을 지속적으로 추적해야 합니다.

4계층: 사용자 경험

좋아요/나빠요 비율, 세션 이탈률, 재질문 비율, 명시적 피드백 텍스트. 가장 직접적인 신호입니다. 사용자가 같은 질문을 여러 번 다르게 바꿔서 다시 묻는다면, 그건 "처음 답이 충분하지 않았다"는 신호입니다. 이런 암묵적 신호를 포착하도록 로그를 설계해야 합니다.

다시 한 번 강조하지만, PM은 이 네 계층을 동시에 봐야 합니다. 어느 한 계층만 보면 사각지대가 생깁니다. 특히 알림을 설계할 때에는 한 가지 원칙을 지키시기 바랍니다. “액션 없는 알림은 소음이다.” 알림이 울렸을 때 PM이나 엔지니어가 무엇을 할 수 있는지 정해져 있지 않다면, 그 알림은 의미가 없습니다. 처음 한 달은 알림을 일부러 적게 설정하고, 진짜 행동이 필요한 신호만 골라내는 게 좋습니다.

그리고 한 가지 더, AI 프로덕트의 모니터링에서 중요한 개념이 “옵저버빌리티(Observability)”입니다. 모니터링이 “지금 문제가 있는가”를 보여준다면, 옵저버빌리티는 “왜 그렇게 동작했는가”까지 추적할 수 있게 해줍니다. 사용자가 “답이 이상해요”라고 신고했을 때, 그 답이 어떤 입력에서 출발해서, 어떤 RAG 자료를 참조했고, 어떤 시스템 프롬프트와 결합되었으며, 모델이 어떤 토큰들을 거쳐 그 답에 도달했는지를 추적할 수 있어야 합니다. LangSmith, Langfuse, Arize Phoenix 같은 도구들이 이런 추적 기능을 제공하므로, AI 프로덕트 운영의 필수 도구로 자리 잡고 있습니다.

6. 드리프트: 코드는 그대로인데 성능이 떨어진다

출시 후 몇 달이 지나면 어김없이 일어나는 일이 있습니다. 코드는 한 줄도 안 바꿨는데, AI 답변의 품질이 슬슬 떨어지기 시작하는 것입니다. “3개월 전에는 잘 답하던 챗봇이 요즘은 이상한 답을 한다”는 보고가 들어오기 시작합니다.

이를 “모델 드리프트(Model Drift)”라고 부릅니다. 원인은 다양합니다. 모델 제공사가 모델을 업데이트해서 동작이 미묘하게 달라졌을 수 있습니다. 또는, 사용자가 던지는 질문의 분포가 시간에 따라 변했을 수도 있습니다. 그도 아니면 회사의 정책이 바뀌었는데 모델이 학습한 정보는 그대로 남아 있을 수도 있습니다. 어쨌든 결과는 같습니다. “AI 기능은 가만히 둬도 성능이 변한다.”는 사실입니다.

드리프트의 또 다른 형태로 “컨텍스트 비대화(Context Bloat)”가 있습니다. 출시 초기에는 시스템 프롬프트가 깔끔하고 짧았는데, 시간이 지나면서 “이 케이스도 고쳐야 해”, “저 예외도 처리해야 해” 하며 프롬프트에 한 줄씩 추가되다 보면, 어느새 시스템 프롬프트가 수천 단어로 부풀어 오르는 현상입니다. 그 결과 비용이 늘고, 응답이 느려지고, 때로는 모델이 너무 많은 지시 사이에서 길을 잃습니다. PM이 정기적으로 시스템 프롬프트를 “가지치기”해야 하는 이유입니다.

이게 기존 소프트웨어와 AI 프로덕트의 가장 결정적인 차이입니다. 기존 소프트웨어는 배포하면 그대로 굴러갑니다. 그런데 AI 프로덕트는 배포 이후에도 살아 움직입니다. 그래서 PM은 출시 후에 더 바빠집니다. 정기적으로 Eval 셋을 다시 돌려서 점수가 떨어진 케이스가 없는지 확인해야 하고, 새로운 실패 패턴이 발견되면 Eval 셋에 추가해서 다음 버전부터는 잡아내야 합니다. 이것이 4편에서 다룬 “회귀 테스트”가 출시 후 프로덕트의 생존과 이어지는 포인트입니다.

드리프트가 감지됐을 때의 대응은 보통 네 가지 선택지가 있습니다. (1) 프롬프트를 손본다(가장 가볍지만, 회귀 테스트로 다른 케이스가 망가지지 않는지 꼭 확인해야 합니다), (2) RAG의 참조 자료를 업데이트한다, (3) 모델 자체를 다른 버전으로 바꾼다, (4) 일시적으로 해당 기능을 인간 담당자에게 넘긴다. 어느 선택지로 갈지는 드리프트의 원인과 비용에 따라 다르며, 이 의사결정이 AI PM의 일상 업무가 됩니다.

마치며: AI 프로덕트의 “운전자”는 PM이다

포드 모델 T의 운전자는 단순한 계기판으로 충분했습니다. 차가 단순했기 때문입니다. 그러나 요즘 테슬라의 운전자는 수십 개의 지표를 동시에 보면서 운전해야 합니다. 차가 복잡해진 만큼, 운전 자체가 더 정교한 일이 됐습니다.

AI 프로덕트의 PM도 마찬가지입니다. 기존 SaaS 시대에는 DAU·MAU·전환율 같은 지표 몇 개로 충분했습니다. 반면 AI 시대에는 환각률·근거 충실도·토큰 비용·P95 지연 속도·사용자 개입률이 동시에 떠 있는 계기판을 봅니다. 끝이 아닙니다. 출시 후에는 그 계기판을 매일 들여다보면서 4계층 모니터링을 운영하고, 드리프트가 감지되면 즉시 대응합니다.

지금까지 시리즈에서 짚어본 지식 모두가 하나의 그림으로 이어지는 겁니다. 1편에서 우리는 “AI는 확률 시스템이다”라는 큰 그림을 봤습니다. 4편에서는 그 시스템을 PRD에 어떻게 정의할지를 봤습니다. 그리고 오늘 5편에서, 그 시스템이 비로소 어떻게 측정되고 운영되는지를 봤습니다. AI 프로덕트는 PRD에서 정의되고, 출시 후에는 KPI로 측정되며, 4계층 모니터링과 드리프트 대응으로 살아남습니다.

결국 AI 시대의 PM은 “기능을 만드는 사람”이 아니라 “기능이 살아 움직이는 동안 운전대를 잡고 있는 사람”입니다. 운전대를 한 번 잡으면 내려놓을 수 없습니다. 6개월 후에도, 1년 후에도, 그 운전은 계속됩니다. 그리고 그 운전을 위해 필요한 것이 새 계기판이며, 운전 감각이며, 무엇보다 새로운 차원의 책임감입니다.