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

① AI는 왜 자꾸 틀리는가

② PM은 LLM을 어디까지 이해해야 할까?

③ AI 기능은 프롬프트가 아니라 시스템으로 만든다

한 줄의 시나리오가 한 편의 영화가 되기까지

두 시간짜리 영화 한 편이 끝나고 나면, 관객들은 대부분 자리를 뜹니다. 그러나 그 자리에 그대로 앉아 화면을 끝까지 보는 사람들도 있습니다. 엔딩 크레딧 때문입니다. 영화의 모든 장면이 끝난 다음, 검은 화면 위로 흰 글씨가 끝없이 올라옵니다. 감독, 각본, 주연 배우, 조연. 거기까지는 우리도 잘 압니다. 하지만, 크레딧은 그 아래로도 계속 이어집니다. 촬영감독, 미술감독, 의상, 분장, 음향, 편집, 시각효과. 시각효과 안에서도 다시 갈라집니다. 모델링 아티스트, 텍스처 아티스트, 라이팅, 컴포지터. 끝나지 않을 것 같은 이름의 행렬이 5분 가까이 이어집니다.

그런데 우리는 그 영화를 "봉준호의 작품"이라고, "크리스토퍼 놀란의 영화"라고 부릅니다. 한 사람의 작품처럼 말하는 것입니다. 그러나 엔딩 크레딧이 보여주는 진실은 다릅니다. 한 편의 영화는 수백 명, 때로는 수천 명이 각자의 자리에서 만들어내는 거대한 시스템의 결과물입니다. 감독이 "파리의 한 카페에서 두 남녀가 만난다"는 한 줄을 시나리오에 적었다면, 그 한 줄을 한 장면으로 만들기 위해 카메라가 어디에 놓이고, 조명이 어떻게 떨어지고, 의상이 무엇이며, 카페 안의 작은 컵 하나로 무엇을 쓸지는 누군가 골라야 합니다.

AI 기능(feature)도 똑같습니다.사용자의 눈에는 "프롬프트 한 줄로 만든 챗봇"처럼 보이지만, 실제로 그 챗봇이 사용자 앞에 서기까지는 영화 엔딩 크레딧만큼이나 많은 시스템 요소가 작동합니다. 그런데 많은 PM이 "AI 기능 = 한 줄의 좋은 프롬프트"라는 생각을 갖습니다. 이 환상을 깨야, 공들여 출시한 AI 기능이 왜 자꾸 이상한 답을 내놓는지 비로소 보입니다.

이번 글에서는 AI 기능이 어떤 시스템으로 구성되는지, 그리고 그 시스템 안에 "틀릴 수 있다"는 LLM의 특성을 어떻게 새겨 넣어야 하는지를 함께 다룹니다.

1. "프롬프트 한 줄"이라는 환상

LLM이 등장하고 PM들이 흔히 하는 말이 있습니다. "이거 프롬프트로 되겠는데요?" 회사 내부의 어떤 자동화 과제를 보면서, 어떤 사용자 기능을 떠올리면서, 이 말이 자주 나옵니다.

그런데 막상 만들어보면 이상한 일이 벌어집니다. 데모에서는 잘 동작하던 프롬프트가, 실제 사용자 100명이 들어오자 무너지기 시작합니다. 어떤 사용자는 질문을 너무 길게 합니다. 어떤 사용자는 회사와 전혀 관계없는 농담을 던집니다. 어떤 사용자는 영어로 질문하고, 어떤 사용자는 오타를 잔뜩 보냅니다. 그런 혼란 속에 모델은 매번 다른 결과를 내놓고, 가끔은 회사의 정책과 어긋나는 답을 자신만만하게 합니다. 1편에서 본 에어캐나다 챗봇이 정확히 이런 모습이었습니다.

프롬프트 한 줄로만 구현한 기능이 무너지는 이유는 단순합니다. 프롬프트는 "모델에게 던지는 한마디"일 뿐, 그 한마디가 어떤 환경에서 어떤 사용자를 만나 어떤 결과로 이어질지에 대한 그 어떤 설계도 담지 않기 때문입니다. 그래서 데모는 잘 돌아가는데 프로덕트는 무너집니다. 데모는 우리가 보여주고 싶은 입력으로만 테스트하고, 프로덕트는 우리가 상상하지 못한 입력을 받기 때문입니다.

그러니 결론부터 말하면, AI 기능은 프롬프트가 아니라 시스템입니다. 프롬프트는 그 시스템의 한 부품일 뿐입니다. 좋은 AI 기능을 만들려면, 그 시스템이 무엇으로 구성되는지를 알아야 합니다.

2. AI 기능을 구성하는 네 가지 시스템 레이어

AI 기능을 만든다는 것은 4가지 시스템 레이어를 함께 설계하는 일입니다. 한 레이어라도 빠지면 기능이 무너지거나, 무너질 가능성을 안고 출시됩니다.

레이어 1. 입력 처리(Input Handling)

사용자가 던지는 입력은 우리가 상상한 것과 다릅니다. 너무 길고, 너무 짧고, 욕설이 섞여 있고, 회사와 무관한 질문이며, 개인정보가 포함되어 있거나, 다른 언어로 들어옵니다. 이 모든 "날것의 입력"을 그대로 모델에게 던지면 안 됩니다. 입력을 검증하고, 정리하고, 필요하면 차단하는 단계가 필요합니다. 의료 상담 챗봇이라면 "이건 우리 서비스 영역이 아닙니다"라고 미리 거를 줄 알아야 하고, 고객 지원 챗봇이라면 긴 질문을 적절히 압축할 줄 알아야 합니다.

레이어 2. 프롬프트(Prompt)

우리가 흔히 "프롬프트"라고 부르는 그 부분은 사실 시스템의 두 번째 레이어입니다. 잘 짜인 프롬프트는 단순히 "고객 질문에 답해줘" 같은 구성이 아닙니다. 모델에게 역할을 부여하고, 답변의 형식을 지정하고, 어떤 정보를 참고해야 하는지 알려주고, 어떤 답변은 하지 말아야 하는지 명시합니다. 그리고 이전 편에서 다룬 RAG를 적용한다면, 이 단계에서 "참고서"가 함께 들어갑니다. 좋은 프롬프트는 한 줄이 아니라 한 페이지에 가까운 정교한 문서의 형태를 띱니다.

레이어 3. 출력 처리(Output Handling)

모델이 답을 내놓았다고 끝이 아닙니다. 그 답이 그대로 사용자에게 가면 안 되는 경우가 많습니다. 답에 회사 기밀이 들어 있지는 않은지, 욕설이나 차별 표현이 섞여 있지는 않은지, 약속하지 말아야 할 것을 약속하지는 않았는지(에어캐나다 챗봇이 여기서 무너졌습니다), 형식이 정해진 대로 나왔는지를 검사합니다. 필요하면 답을 수정하거나, 다른 답을 다시 요청하거나, 사람에게 넘깁니다.

레이어 4. 오케스트레이션(Orchestration)

위 세 레이어가 한 번에 끝나면 단순한 기능입니다. 그런데 실제 AI 기능은 여러 번의 모델 호출이 이어지는 경우가 많습니다. 사용자 질문을 분석해서 어떤 자료가 필요한지 판단하고(1차 호출), 그 자료를 검색해, 검색 결과를 바탕으로 답을 생성하고(2차 호출), 그 답을 검증하는(3차 호출) 식입니다. 이 흐름을 지휘하는 것이 오케스트레이션 레이어입니다. 어떤 단계가 실패하면 어떻게 복구할 것인지, 비용이 폭발하지 않도록 어디서 멈출 것인지를 함께 설계해야 합니다.

이 네 개의 레이어가 다 있어야 진정한 의미의 AI 기능입니다. 프롬프트 한 줄만 있는 것은 데모이지 프로덕트가 아닙니다. PM이 AI 기능을 기획할 때, "프롬프트는 어떻게 쓸까"가 아니라 "이 네 개의 레이어를 어떻게 설계할까"를 먼저 묻기 시작해야 사고의 출발점이 달라집니다.

3. 시스템 프롬프트: 사용자가 보지 않는 설계자

두 번째 레이어인 프롬프트에 대해 한 가지 더 짚을 게 있습니다. AI 기능에는 보통 두 종류의 프롬프트가 있습니다. 사용자가 보내는 메시지(예. "가족 장례로 인한 할인 있나요?")가 하나, 그리고 사용자가 절대 보지 않는, 시스템 차원에서 모델에게 항상 주어지는 지시문이 또 하나입니다. 후자를 시스템 프롬프트라고 부릅니다.

시스템 프롬프트는 영화로 치면 감독이 모든 배우에게 "이 영화는 이런 톤이고, 이런 시대 배경이고, 이런 캐릭터입니다"라고 미리 알려주는 것과 같습니다. 배우는 그 디렉팅을 아주 잘 이해할 때, 감독이 원하는 모습을 그려내며 연기할 수 있습니다. 그렇기에 사용자 메시지가 아무리 다양하게 들어와도, 시스템 프롬프트가 잘 짜여 있으면 모델은 일관된 캐릭터를 유지합니다. 반대로 시스템 프롬프트가 부실하면, 한 챗봇이 어떤 사용자에게는 형님처럼, 어떤 사용자에게는 비서처럼, 어떤 사용자에게는 어린아이처럼 굴게 됩니다.

좋은 시스템 프롬프트에는 보통 다섯 가지가 들어갑니다.

모델의 역할: "당신은 ○○ 회사의 고객 지원 담당자입니다"
답변의 톤과 형식: "존댓말로, 5문장 이내로"
참고해야 할 정보의 출처: "아래 정책 문서를 근거로 답하세요"
하지 말아야 할 것의 목록: "가격을 임의로 약속하지 마세요"
막혔을 때의 출구: "확실하지 않으면 '담당자에게 연결해 드리겠습니다'라고 답하세요”

이 다섯 가지가 빠진 채 출시되는 반쪽짜리 AI 기능이 의외로 많습니다.

4. AI는 왜 틀리고, 왜 그것이 UX의 문제인가

여기까지는 시스템의 "뼈대"를 살펴보았습니다. 입력을 받고, 모델에게 잘 묻고, 답을 검증해서 내놓는 흐름. 그런데 이 뼈대를 아무리 잘 갖춰도 AI는 여전히 틀립니다. 모델이 확률적으로 답을 생성하는 한, 어떤 시스템도 환각을 0으로 만들 수 없습니다. 그렇다면 PM은 이 "틀림"을 어떻게 다뤄야 할까요?

여기서 결정적인 시각 전환이 필요합니다. AI가 틀린다는 사실을 "기술의 한계"가 아니라 "설계의 출발점"으로 보는 일입니다. 모델이 틀리는 것을 막을 수 없다는 사실을 인정한 다음, 그 틀림을 사용자가 어떻게 경험할지를 PM이 설계해야 합니다. 같은 환각이 일어나도, UX가 어떻게 설계되어 있느냐에 따라 사용자가 받는 충격은 천양지차입니다.

1편의 에어캐나다 챗봇 사건을 다시 봅시다. 챗봇은 "즉시 여행이 필요하시면 정상 요금으로 구매 후 90일 이내에 사별 할인을 소급 신청하실 수 있습니다"라고 답했습니다. 그 답은 “사별 할인은 사전에만 신청할 수 있다”는 회사의 진짜 정책과 달랐습니다. 그러나 사용자는 그 답을 100% 믿고 행동했고, 결국 회사가 법정에 서게 됐죠.

그런데 이 사건의 진짜 비극은 챗봇이 틀렸다는 현상 그 자체는 아닙니다. 챗봇이 "이건 정확하지 않을 수 있다"는 신호를 어디에도 주지 않은 채, 자신만만한 어조로 답해버렸다는 사실입니다. 만약 같은 답을 냈더라도 "정확한 정책은 여기서 확인해 주세요"라는 링크 한 줄, 혹은 "확실하지 않은 경우 상담사에게 연결해드리겠습니다"라는 옵션이 함께 떠 있었다면, 사용자는 그 답을 그대로 믿지 않거나 의심했을 테고, 법정 다툼도 일어나지 않았을 것입니다.

이게 "AI가 틀리는 것은 UX의 문제"라는 말의 의미입니다. 모델이 틀린 답을 내는 것은 막을 수 없습니다. 하지만 사용자가 그 답을 어떻게 받아들이는지는 PM이 설계할 수 있습니다. 그리고 그 설계의 책임을 회피하면 사고로 이어집니다.

AI 프로덕트의 UX 설계는 "틀리지 않는 척하는 법"이 아니라 "틀릴 수 있다는 사실을 정직하게 알리는 법"입니다. 역설적으로, 이 정직함이 사용자의 신뢰를 만들어냅니다. "100% 정확합니다"라고 호언장담하는 시스템보다, "이 답은 ○○ 자료를 근거로 만들었고, 확실하지 않다면 여기서 확인하세요"라고 말하는 시스템을 우리는 더 신뢰합니다.

5. 불확실성을 UX로 처리하는 법

그렇다면 "틀릴 수 있다"는 전제를 UX에 어떻게 새겨 넣을까요? 가장 먼저 손볼 곳은 "표현"입니다. AI가 내놓는 답의 어조, 형식, 강도가 사용자의 신뢰에 결정적으로 영향을 미치기 때문입니다.

확신형 표현 vs 확률형 표현

AI 답변을 화면에 띄울 때 가장 흔히 빠지는 함정은 "확신형 표현"입니다. 사용자가 "이게 정답이에요"라고 해석할 만한 톤으로 답을 던지는 것이죠. 에어캐나다 챗봇의 "네, ~한 절차로 신청하시면 됩니다"가 정확히 그런 표현이었습니다. 모델은 사실 확률 분포에서 가장 그럴듯한 답을 뽑은 것뿐인데, 확신 기반 설계는 그것을 "확정된 사실"인 것처럼 보여줍니다.

좋은 AI UX는 의도적으로 "확률형 표현"을 씁니다.같은 답을 하더라도 어조가 다릅니다. "네, 90일 이내 소급 신청 가능합니다" 대신 "안내해 드린 정보가 맞다면 90일 이내 소급 신청이 가능합니다. 다만 정확한 정책은 [공식 안내 페이지]에서 한 번 더 확인해 주세요"라고 말하는 식입니다. 답을 던지되, 그 답이 어디서 왔고 얼마나 확신할 수 있는지를 함께 보여줍니다.

이건 단순한 친절이 아닙니다. AI가 틀렸을 때 회사와 제품을 보호하는 방어선이기도 합니다. 동시에 사용자가 "이 시스템은 정직하다"고 느끼게 만드는 신뢰의 토대이기도 합니다.

신뢰 설계의 세 가지 패턴

성숙한 AI 프로덕트들이 공통적으로 채택하는 신뢰 설계 패턴이 세 가지 있습니다. 이 세 가지를 시스템의 출력 처리 레이어에 의식적으로 새겨 넣어야 합니다.

첫째, 출처 표시: 답이 어디에서 왔는지를 함께 보여줍니다. "이 답은 회사 정책 문서 v2.3을 근거로 작성되었습니다"라거나, RAG에서 참조한 문서의 링크를 답 옆에 함께 띄우는 식입니다. Perplexity 같은 서비스가 답변 옆에 항상 참조 URL을 보여주는 것이 대표적입니다. 출처가 있으면 사용자는 그 답을 검증할 수 있고, 검증할 수 있으면 신뢰가 쌓입니다.

둘째, 확신 정도: 모델이 얼마나 확신하는지를 표시합니다. 모든 답에 "확실해요!"라고 하기보다, 어떤 답에는 "확실합니다", 어떤 답에는 "~로 보입니다", 어떤 답에는 "잘 모르겠습니다"라고 톤을 다르게 가져갑니다. ChatGPT나 Claude가 채팅창 아래 작은 글씨로 "AI는 실수할 수 있습니다"라고 적어두는 것도 같은 맥락입니다. 사용자가 그 답을 얼마나 무게감 있게 받아들여야 하는지에 대한 신호를 주는 것입니다.

셋째, 사람에게로의 탈출구: AI가 풀 수 없는 상황에서 사용자가 막히지 않도록, 사람에게 넘어갈 수 있는 경로를 항상 만들어둡니다. "상담사 연결" 버튼이 어디에 있는가, 어떤 상황에서 그 버튼이 두드러져 보이는가를 의식적으로 설계합니다. 좋은 시스템을 갖춘 AI 기능은 결과에 대한 자신감이 떨어질 때 스스로 "이 부분은 담당자에게 연결해 드릴까요?"라고 먼저 제안하기도 합니다.

언제 "모르겠다"고 말해야 하는가

AI 프로덕트 UX에서 가장 어려운 결정 중 하나가 이것입니다.어떤 질문에는 답을 내고, 어떤 질문에는 답을 거부할 것인가? 이 경계를 잘 그어두지 않으면 모델은 모든 질문에 답을 만들어내려다 실패하고(환각), 그러한 오류는 위험한 영역까지 침투합니다.

이 경계를 정하는 것이 PM의 일입니다. 의료·법률·금융처럼 잘못된 답의 비용이 큰 영역에서는 시스템이 더 자주 "모르겠다"고 말하도록 설계해야 합니다. 반대로 추천이나 요약 같은 영역에서는 너무 자주 거부하면 도구로서의 가치가 떨어지므로 최대한 답변을 시도하는 쪽으로 기울일 수 있습니다. 어떤 영역에서는 "답을 안 하는 용기"가 "답을 내는 자신감"보다 더 큰 가치를 만듭니다.

6. 연착륙 설계: 좋은 실패와 나쁜 실패의 차이

이러한 시스템과 UX를 아무리 잘 설계해도 AI는 결국 어디선가 실패합니다. 모델이 답을 못 내놓거나, 답이 형식에 맞지 않거나, 정책에 어긋나거나, 비용이 한도를 넘어가거나. 이 모든 "실패의 순간"에 시스템이 어떻게 반응할지를 미리 설계해 두는 것이 연착륙 설계(Graceful Degradation)입니다.

같은 실패도 "나쁜 실패"와 "좋은 실패"가 있습니다. 나쁜 실패는 사용자에게 "이 AI가 망가졌네"라는 인상을 남기는 실패입니다. 갑자기 화면이 빈 채로 멈춰버린다거나, "오류가 발생했습니다"라는 메시지만 보여주고 끝나버리는 식입니다. 좋은 실패는 사용자가 "이건 사람이 도와줘야겠네"라고 자연스럽게 받아들이도록 만드는 실패입니다.

재시도 · 폴백 · 사람 연결의 흐름

좋은 연착륙 설계는 보통 세 단계로 흐릅니다.

첫 단계는 재시도(Retry): 같은 질문을 다른 방식으로 다시 모델에 던져봅니다. 프롬프트를 살짝 바꾸거나, 다른 모델로 한 번 더 시도하거나, 컨텍스트를 정리해서 다시 묻습니다. 사용자는 시스템이 한 번 흔들렸다는 것을 알아채지 못한 채 답을 받게 됩니다.

두 번째 단계는 폴백(Fallback): 재시도로도 안 되면, AI가 아닌 다른 방식으로 답을 제공합니다. 자주 묻는 질문 FAQ로 보여주거나, 검색 결과를 제시하거나, 미리 준비된 안내 페이지로 연결합니다. "AI가 답을 못 했다"가 아니라 "이 질문에는 이 자료가 도움이 될 것 같다"는 형식으로 사용자에게 가치를 계속 전달합니다.

세 번째 단계는 사람 연결(Escalation): 폴백도 부족할 때, 자연스럽게 사람에게 넘깁니다. "이 부분은 담당자가 도와드리는 것이 좋겠습니다"라고 안내하면서, 사용자가 다시 처음부터 설명하지 않아도 되도록 그동안의 대화 내용을 담당자에게 함께 전달합니다. 사용자 입장에서는 "AI에서 사람으로" 매끄럽게 이어지는 경험을 얻습니다.

신뢰는 정확도가 아니라 일관성과 정직함에서 온다

마지막으로, AI 프로덕트의 UX 설계에서 가장 흔히 하는 오해는 "정확도를 높이면 신뢰가 올라간다"는 생각입니다. 어느 정도까지는 맞지만, 어느 지점부터는 정확도를 1~2% 더 올리는 것보다 시스템이 일관되게 행동하고 정직하게 한계를 드러내는 것이 사용자 신뢰에 훨씬 큰 영향을 줍니다. 95% 정확하지만 정직한 시스템과 98% 정확하지만 자신만만하게 틀리는 시스템 중에서, 사용자는 전자를 압도적으로 더 신뢰합니다.

AI 프로덕트의 신뢰는 "틀리지 않음"이 아니라 "틀릴 때 어떻게 행동하느냐"에서 만들어집니다. 연착륙 설계는 그 "행동"의 구체적 형태입니다.

7. PM이 AI 기능을 기획할 때 챙겨야 할 것

정리하자면, AI 기능을 기획할 때 PM의 머릿속에 있어야 할 체크리스트는 다음과 같습니다. 시스템의 뼈대와 "틀릴 수 있다"를 새기는 UX 설계를 합쳐서 정리한 것입니다. "좋은 프롬프트 한 줄"보다 훨씬 길고 복잡하지만, 이것이 "AI 기능을 시스템으로 설계한다"는 말의 진짜 의미입니다.

입력 검증:사용자의 어떤 입력을 받을 것이고, 어떤 입력은 미리 거를 것인가?
시스템 프롬프트: 모델의 역할·톤·금지 사항·막혔을 때의 출구를 어떻게 정의할 것인가?
참고 자료(RAG):모델이 무엇을 보고 답하게 할 것인가? 그 자료는 어떻게 최신으로 유지할 것인가?
출력 검증:모델의 답을 그대로 보여줄 것인가, 검증 후 보여줄 것인가?
신뢰 신호(Sources, Confidence, Escalation):사용자가 답을 어디까지 믿을지 짐작할 신호는 어디에 어떻게 넣을 것인가?
연착륙 설계:실패 시 사용자가 어떤 경로로 빠져나갈 수 있는가? 재시도·폴백·사람 연결 중 어떤 조합으로 갈 것인가?
오케스트레이션:한 번의 모델 호출로 끝나는가, 여러 단계로 흐르는가? 비용이 폭발하지 않게 어디서 멈출 것인가?

이 일곱 가지에 망설임 없이 답할 수 있을 때, 비로소 "AI 기능을 시스템으로 설계했다"고 말할 수 있습니다. 이걸 PRD에 어떻게 담을지, 그리고 출시 후에는 어떻게 운영할지는 다음 글에서 따로 다루겠습니다.

AI 기능은 한 사람의 작품이 아니다

처음으로 돌아갑니다. 우리는 영화 한 편을 "봉준호의 작품"이라고 부르지만, 엔딩 크레딧이 보여주는 진실은 "수많은 사람의 시스템"이 영화를 만든다는 사실입니다. 그 시스템이 잘 돌아가야만 우리는 그 영화를 "봉준호의 작품"이라고 부를 수 있습니다. 시스템이 무너지면, 아무리 좋은 감독이라도 영화의 완성도는 무너집니다.

AI 기능도 이와 같습니다. 우리가 출시하는 챗봇은 "LLM의 작품"처럼 보이지만, 실제로는 입력 처리·프롬프트·출력 처리·오케스트레이션·신뢰 설계·연착륙 설계가 함께 만들어내는 거대한 시스템의 결과물입니다. 좋은 PM은 " LLM에 무엇을 물을까"가 아니라 "이 시스템 전체를 어떻게 짤까"를 묻습니다.

AI 시대의 PM은, LLM을 부리는 사람이 아니라 LLM이 일할 시스템을 짓는 사람입니다. 그리고 그 시스템 안에 "AI는 틀릴 수 있다"는 사실이 정직하게 새겨져 있을 때, 비로소 AI 프로덕트는 사용자의 신뢰를 얻게 됩니다.