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

PM이 알아야 할 확률 시스템의 사고법

2022년 11월, 캐나다 밴쿠버에 살던 제이크 모팻(Jake Moffatt)은 갑작스러운 할머니의 부고를 접합니다. 그는 급히 토론토로 가는 항공편을 예약하려고 에어캐나다 웹사이트에 접속해 챗봇에게 물었습니다. “가족의 사별로 인한 항공권 할인이 있나요?” 챗봇은 친절하게 답했습니다. “즉시 여행이 필요하면 정상 요금으로 항공권을 먼저 구매한 다음, 발권일로부터 90일 이내에 사별 할인(death certificate)을 소급 신청할 수 있습니다.”

할머니의 장례식까지는 시간이 촉박했고, 챗봇의 답변은 명확했습니다. 그는 정가로 토론토 왕복 항공권을 구매했고, 돌아온 뒤 챗봇이 알려준 대로 환불 신청서를 보냈습니다.

그러나 환불은 거절되었습니다. 에어캐나다의 진짜 정책은 “사별 할인은 여행 전에 신청해야 하며, 이미 다녀온 항공권에는 적용되지 않는다”였기 때문입니다.

모팻은 챗봇과 나눈 대화 캡처를 증거로 보내며 항의했지만, 담당자는 기대와 다른 답을 내놓습니다. 챗봇이 “오해를 불러일으키는 표현”을 쓴 건 인정하지만, 회사의 공식 사별 여행 안내 페이지에는 정확한 정책이 적혀 있으니 그쪽 규정이 우선이라는 것이었습니다. 사실상 “챗봇의 오류는 우리도 알지만, 환불은 안 된다”는 뜻이었죠. 소송이 시작되었고, 재판소는 “챗봇이 회사 웹사이트의 일부인 이상, 실제 정책이 적힌 곳이 정적 페이지든 챗봇이든 회사는 책임을 져야 한다.”라는 판결을 내립니다. 에어캐나다는 환불금 812 달러를 지불했고, 얼마 지나지 않아 챗봇은 조용히 사라졌습니다.

<참고 기사: CBC, Air Canada found liable for chatbot's bad advice on plane tickets, 2024>

이 사건이 흥미로운 건, 단순히 “AI가 실수했다”로 책임을 단정지을 이야기가 아니라는 점입니다. 에이캐나다의 챗봇은 의도적으로 거짓말을 한 게 아니고, 누가 일부러 잘못 학습시킨 것도 아닙니다. 그저 “가장 그럴듯한 답변”을 생성해 냈는데, 그게 회사의 실제 정책과 달랐을 뿐입니다. 그런데 그 한 줄의 답변이 회사를 법정에 세웠습니다.

이게 바로 AI 프로덕트와 기존 소프트웨어가 다른 지점입니다. 그리고 이 차이를 모른 채 AI 프로덕트를 만들기 시작하면, 우리도 머지않아 비슷한 상황을 마주하게 될 겁니다.

같은 질문, 다른 답

기존 소프트웨어를 한 줄로 정의하면 이렇습니다. “같은 입력에는 같은 출력이 나온다.”

여러분이 은행 앱에서 10만 원을 이체하면 정확히 10만 원이 빠져나갑니다. 이체 금액은 9만 9천 원도, 10만 1천 원도 아닙니다. 만약 어쩌다 9만 9천 원이 빠져나간다면 그건 “기능”이 아니라 “버그”입니다. 우리는 이걸 결정론적(deterministic) 시스템이라고 부릅니다. 코드가 같고 입력이 같으면, 몇 번을 돌려도 결과가 똑같이 나와야 합니다. 지난 수십 년간 우리가 만들고 써 온 거의 모든 소프트웨어가 이 원칙 위에 서 있습니다.

그런데 챗GPT나 제미나이는 다릅니다. 이 LLM에 질문을 100번 던져보세요. 100번 다 다른 답이 돌아옵니다. 문장이 약간씩 다르고, 어떤 답은 더 길고 어떤 답은 더 짧습니다. 가끔은 사실관계까지 미묘하게 달라집니다. 그렇다고 그 LLM이 “고장 났다”고 말할 수는 없습니다. 원래 그렇게 동작하도록 만들어졌으니까요.

LLM이 작동하는 공간은 답을 “계산”하는 시스템이 아니라 “생성”하는 시스템입니다. 더 정확히 말하면, 다음에 올 단어를 확률적으로 예측하는 시스템입니다. “오늘 날씨는” 다음에 어떤 단어가 올 확률이 가장 높은지를 거대한 학습 데이터 기반으로 추정해서, 한 단어 한 단어 이어 붙여 문장을 만듭니다. 그러므로 “가장 가능성 높은 답”을 만들어내지만, 그게 “항상 맞는 답”이라는 보장은 없습니다.

결정론(Deterministic)시스템은 답을 계산합니다. 확률론(Probabilistic)시스템은 답을 생성합니다. 이 차이가 AI 프로덕트를 만들 때 알아야 할 모든 것의 출발점입니다.

“같은 질문, 다른 답”이 만들어내는 세 가지 문제

PM 입장에서 결정론과 확률론의 차이는 단순한 기술적 디테일의 차원이 아닙니다. 프로덕트의 기획, 측정, 운영 방식이 통째로 달라지는 변화의 시작입니다. 세 가지 측면에서 짚어보겠습니다.

1) 테스트가 깨진다

결정론적 소프트웨어의 테스트는 단순합니다. “입력 A를 넣으면 출력 B가 나와야 한다.” 이를 검증할 때는 자동화 테스트를 짜고, 매번 같은 결과가 나오는지 확인하면 됩니다. 결제 금액이 맞는지, 로그인이 되는지, 페이지가 제대로 렌더링되는지는 모두 “기댓값과 일치 여부”로 판단합니다.

AI 프로덕트는 어떨까요? “이 질문에 반드시 이 답이 나와야 한다”는 식의 테스트는 처음부터 성립하지 않습니다. 답이 매번 다르니까요. 그래서 AI 프로덕트의 테스트는 “정답 맞히기”가 아니라 “허용 범위 안에 있는가”를 봐야 합니다. 사실관계에서 벗어나지 않는지, 톤은 적절한지, 너무 길거나 짧지 않은지를 여러 각도에서 살펴봐야 하죠. 이 작업을 업계에서는 Eval(이밸, evaluation의 줄임말)이라고 부릅니다. AI 프로덕트가 등장하면서 새로 생긴 직무 영역이기도 합니다. 조직에 따라 아예 “Eval 엔지니어”라는 포지션을 따로 두기 시작한 곳도 있습니다.

2) 실패가 조용히, 그럴듯하게 일어난다

기존 소프트웨어의 실패는 대체로 눈에 띕니다. 페이지가 안 열린다, 에러 메시지가 뜬다, 결제가 안 된다. 사용자도 알고, 우리도 압니다. 모니터링 도구가 알람을 보내고, 슬랙에 빨간 메시지가 뜨고, 누군가가 새벽에 출동합니다.

AI 프로덕트의 실패는 조용히, 그럴듯하게 옵니다.에어캐나다 챗봇은 “오류”라는 문구를 화면에 띄우지 않았습니다. 그 대신 자신만만하게 잘못된 답을 했죠. 사용자는 그 답을 믿고 행동했고, 문제는 한참 뒤에 드러났습니다. 이 패턴을 환각(hallucination)이라고 부르는데, AI 프로덕트가 가진 가장 까다로운 실패 모드입니다. 코드는 잘 돌아가고, 시스템은 멀쩡하고, 응답 시간도 빠른데, 내용이 틀렸을 뿐입니다. 그리고 “틀렸다”는 사실은 누군가가 사후에 발견해 주기 전까지는 어디에도 기록되지 않습니다.

3) 비용이 예측 안 된다

기존 SaaS의 인프라 비용은 어느 정도 예측이 됩니다. 동시 접속자가 N명일 때 서버가 얼마나 필요한지 계산할 수 있고, 한 번 계산해 두면 크게 안 바뀝니다. 사용자가 늘면 비용도 늘지만, 그 관계가 비교적 선형적입니다.

AI 프로덕트는 다릅니다. 사용자가 한 번 질문할 때마다 토큰 단위로 과금이 들어가기 때문입니다. 어떤 사용자는 한 줄 질문으로 한 줄 답을 받지만, 어떤 사용자는 PDF를 통째로 붙여 넣고 “이거 요약해 줘”라고 합니다. 두 요청의 비용 차이는 100배 이상 날 수 있습니다.

문제는 그 비용이 우리가 청구서를 받기 전까지 잘 안 보인다는 겁니다. 실제로 AI 기능을 출시한 회사들이 가장 자주 겪는 “숨겨진 사고”가 바로 이 비용 폭증입니다. 어떤 사용자가 시스템을 “창의적으로” 활용하기 시작하면, 한 명이 한 달 만에 수천 달러어치 토큰을 써버리는 일도 일어납니다. 전체 사용자 수는 그대로인데 비용 그래프만 수직으로 올라가는 식이죠. 기존 SaaS PM은 거의 겪어볼 일이 없던 종류의 문제입니다.

그래서, PM은 무엇을 어떻게 봐야 하는가

여기까지 읽으셨다면 이런 생각이 들 수 있습니다. “그럼 AI 프로덕트는 도대체 어떻게 만들지?” 이 질문은 책 한 권으로도 모자라는 주제지만, 출발점이 되는 직관 세 가지만 짚고 가겠습니다.

1) “정확도 100%”를 KPI로 쓰지 않는다

기존 프로덕트의 이상적인 상태는 “버그 0건”입니다. AI 프로덕트는 다릅니다. 모델이 항상 맞히는 건 불가능하고, 그걸 KPI로 잡으면 팀이 끝없이 헛수고만 하게 됩니다. 어떤 LLM도 환각을 100% 없애지 못합니다. 그게 모델 구조 자체의 한계입니다.

대신 우리는 “어느 정도의 오류는 받아들이되, 어떻게 그 오류가 사용자에게 큰 피해를 주지 않도록 만들 것인가”를 물어야 합니다. 의료나 금융처럼 오류 비용이 큰 도메인에서는 더 엄격한 기준을, 추천이나 요약처럼 “틀려도 회복 가능한” 도메인에서는 좀 더 너그러운 기준을 적용합니다. AI 프로덕트의 품질은 맞다/틀리다의 이분법이 아니라, 얼마나 자주 그리고 얼마나 크게 틀리는지의 분포로 봐야 합니다.

2) 사용자가 “틀릴 수 있다”는 걸 알 수 있게 한다

에어캐나다 챗봇의 가장 큰 문제는 답이 틀렸다는 것이 아니라, 그게 틀릴 수도 있다는 신호가 어디에도 없었다는 점입니다. 그 때문에 모팻은 챗봇의 답을 100% 믿고 행동했고, 그게 회사에 책임으로 돌아왔습니다. 만약 챗봇이 “이 답변은 정확하지 않을 수 있으니, 정확한 정책은 여기서 확인하세요”라는 링크 한 줄을 함께 보여주었다면 어땠을까요? 결과는 완전히 달랐을 겁니다.

성숙한 AI 프로덕트는 답을 던지고 끝내지 않습니다. “이 답은 어디서 가져왔는지(sources)”, “얼마나 확신하는지(confidence)”, “인간 담당자에게 넘어갈 수 있는 경로(escalation)”를 함께 보여줍니다. ChatGPT나 클로드나 챗윈도우나, 답변 끝에 작은 글씨로 “실수할 수 있습니다”라고 적어두는 것도 이런 맥락입니다. 업계에서는 이걸 신뢰 설계라고 부르고, 그 설계 구조는 AI 프로덕트의 UX에서 핵심 영역으로 자리 잡고 있습니다.

결과에 대한 기대치를 설정하고, 소스를 공개하는 것은 AI 프로덕트에서 매우 중요하다. <출처: Gemini, Claude 앱 캡처>

3) 출시가 끝이 아니라 시작이다

기존 소프트웨어는 배포하면 그대로 동작합니다. 코드를 안 건드리면 결과도 안 바뀝니다. AI 프로덕트는 다릅니다. 모델 자체가 업데이트되기도 하고, 사용자가 던지는 질문의 분포가 시간에 따라 변하기도 합니다. 그래서 6개월 전에는 잘 동작하던 챗봇이 이제 와 이상한 답을 하기 시작할 수 있습니다.

예를 들어, 출시 직후에는 사용자들이 정중하게 “이 제품에 대해 알려주세요” 같은 질문만 하다가, 시간이 지나면 “경쟁사 제품과 비교해 줘”, “이거 너희 회사 망하면 환불받을 수 있어?” 같은 예상 못한 질문을 던질지도 모릅니다. 모델이 어떤 답을 내놓을지 출시 전에는 알기 어렵습니다.

그래서 AI 프로덕트의 PM은 출시 후에 더 바빠집니다. 답변 품질이 어떻게 변하고 있는지 매일 들여다보고, 비용이 어디서 새는지 추적하고, 사용자들이 시스템을 어떤 식으로 쓰기 시작했는지 관찰해야 합니다. 출시 후의 운영이 기존 소프트웨어보다 훨씬 더 “살아 있는” 작업이 됩니다.

AI 프로덕트의 PM이 된다는 것

AI 프로덕트를 만들고 운영한다는 건, 결정론의 세계에서 살아온 PM이 확률론의 세계로 이주하는 일과 비슷합니다. 이 두 세계는 다른 규칙으로 움직입니다. 어떤 KPI를 봐야 하는지, 어떻게 테스트해야 하는지, 어떤 실패를 예상해야 하는지, 사용자에게 어떻게 신뢰를 주어야 하는지가 모두 달라집니다.

그런데 이 새로운 세계가 무섭기만 한 건 아닙니다. 기존 소프트웨어를 운영하며 PM이 익혀온 사용자 중심 사고, 가설 검증, 데이터 기반 의사결정 같은 근육들은 그대로 쓰입니다. 다만 그 근육을 "확률적으로" 움직이는 시스템 위에서 어떻게 새로 써야 하는지 익힐 필요는 있습니다.

이 새로운 세계의 지도를 한 장씩 그려보려고 합니다. 다음 글에서는 LLM이 도대체 어떻게 동작하는지, PM이 가져야 할 “최소한의 직관”이 무엇인지 다뤄볼 예정입니다. 그리고 시리즈 후반부에는 “AI 프로덕트의 KPI는 무엇이 달라야 하는가”를 본격적으로 풀어보겠습니다.

기존 소프트웨어의 PM은 “버그를 0으로 만드는 사람”에 가까웠습니다. 반면, AI 프로덕트의 PM은 “확률과 함께 사는 법을 설계하는 사람”입니다. 이 차이를 받아들이는 순간부터, AI 프로덕트는 무서운 신기술이 아니라 다룰 만한 시스템이 됩니다. 그리고 그 출발점은, 오늘 함께 본 “같은 질문에 다른 답이 나오는 시스템”을 자연스럽게 여기는 일에서 시작합니다.