AI 프로덕트 매니지먼트

기존의 프로덕트와 달리 AI 프로덕트는 deterministic 하지않고 확률에 의존한다. 당연한 소리지만 이를 염두하지 않으면 프로덕트를 제대로 이해할 수 없다.
토큰은 단어와 비슷하지만 정확히 일치하지 않는다. 그리고 개별 model마다 토큰을 나누는 기준도 제각각이다. 같은 길이의 텍스트라도 언어에 따라 토큰 수가 크게 달라지며, 글로벌 서비스를 만드는 PM이라면 이 부분을 비용 설계 시 반드시 고려해야 한다.
에이전트는 모델 그 자체가 아니다. 모델 위에 얹힌 모든 것-도구 정의, 컨텍스트 파일, 가드레일, 피드백 루프, 관찰 가능성-이 합쳐져야 비로소 에이전트가 된다.
이밸의 실제 구현은 엔지니어링 팀이 담당하지만, 이밸 플랜을 설계하는 것, 즉 무엇을 평가할지, 합격 기준은 어떻게 정의할지, 평가 주기를 어떻게 설정할지는 PM이 주도해야 하는 영역이다. 이밸의 기준은 기술적 판단이 아니라 제품적 판단이기 때문이다.
AI product, 즉 llm 기반의 프로덕트는 기존 소프트웨어 비용 구조가 아니라 제조업에 가까운 구조다. 성장이 곧 비용 증가다.
LLM 위에만 얹혀 있는 스타트업은 차별화 포인트가 UX와 워크플로 설계뿐인데 그것만으로는 경쟁자를 막기 어렵다. UX와 워크플로의 구현이나 베끼는 비용도 값싸졌기 때문이겠지. 그럼 차별화는 무엇으로 두어야 할까. 단순히 LLM 위에만 얹혀있는 것만으로는 경쟁자를 물리치기 어렵다. cursor나 claude처럼 압도적인 기술 경쟁력을 지녀야 한다.
햄릿의 "To be, or not to be" 이 대사가 400년이 지난 지금도 살아남은 이유는, 그 텍스트가 어떻게 읽혀야 하는지에 대한 풍부한 주석이 함께 살아 있기 때문이다. AI PRD도 마찬가지로, 기능 요구 사항을 아무리 잘 작성해도 "잘 동작한다"는 것이 무엇을 의미하는지를 정의한 주석인 이밸 플랜이 없으면 팀 내에서 저마다 다른 기준으로 기능을 만들고 평가하게 된다.
AI 프로덕트의 유저 경험은 아래 두 질문에 달렸다.
- 불확실성을 어떻게 표현할 것인가.
- AI가 틀렸을 때 사용자가 어떻게 회복하게 할 것인가.
AI 시스템은 자신이 잘 모르는 영역에서 "모르겠다"고 말할 수 있어야 한다. 이것이 장기적으로 시스템 전체의 신뢰도를 높이지만(정말?), 대부분의 AI 프로덕트는 모른다는 대답을 하지 않는다. 또한 모른다의 등급을 나누고, 각각에는 다른 표현이 필요하다.
- 완전히 모르는 것
- 부분적으로 아는 것
- 알지만 불확실한 것
PM이 실패 시나리오를 설계할 때 "평균적인 사용자"가 아닌 "가장 취약한 사용자"를 먼저 생각해야 한다. 그들의 위한 안전망이 모든 사용자에게 더 나은 경험이 된다.
AI 툴을 필요할 때만 꺼내 쓰는 것과 업무 흐름 안에 내장시키는 것은 다르다. 전자는 편의 도구고 후자는 시스템이다. 시스템이 되어야 생산성이 달라진다. 시스템화는 아래 세가지를 의미한다.
- 루틴화: 매주 반복하는 업무에 AI 단계를 고정적으로 포함
- 축적: 잘 동작하는 프롬프트를 문서화하고 팀과 공유. 개인의 노하우를 팀의 자산으로 만든다.
- 검토: 매월 AI 활용 방식을 회고. 어디서 리소스가 절약됐는지, 어디서 오히려 복잡해졌는지. 툴은 빠르게 변하고, 나의 워크플로도 함께 변화해야 한다.

그럼 AI 스타트업은 어떻게 해야하는가?

LLM 그 자체가 아닌 LLM 위에 쌓이는 것에서 가치를 만들어내야 한다.

특정 도메인에서 특화된 데이터 자산을 쌓는 것, 범용 LLM이 처리하기 어려운 법률, 의료, 금융, 제조 도메인의 전문 데이터를 확보하고 파인튜닝하면 LLM벤더가 직접 복제하기 어려운 차별화 요소가 생긴다.
워크플로 통합의 깊이를 높이는 것. AI 기능이 고객의 핵심 업무 프로세스(ERP, CRM, 사내 데이터베이스)와 깊이 결합될수록 전환 비용이 높아진다. LLM을 단독으로 붙이는 것이 아닌 고객의 데이터 위에서 동작하는 시스템을 만들어야 한다.
모델 독립성 확보. 특정 LLM 벤더에 종속되지 않도록 멀티 모델 아키텍처를 설계해야 한다. 벤더A의 가격이 오르거나 성능이 떨어지면 벤더 B로 전환할 수 있는 구조가 있어야 한다.