AI 프로덕트는 왜 자꾸 그럴듯하게 틀리는가

AI 제품은 ‘가끔 틀리는 앱’이 아니라 동작 방식이 다른 앱임

• 에어캐나다 챗봇 사건은 AI 제품 리스크를 설명하기 딱 좋은 사례임

  • 한 고객이 할머니 장례식 때문에 급히 항공권을 예약하면서 챗봇에게 사별 할인(death certificate) 적용 여부를 물었음
  • 챗봇은 먼저 정가 항공권을 사고, 발권일로부터 90일 안에 소급 신청하면 된다고 안내함
  • 실제 정책은 정반대였음. 사별 할인은 여행 전에 신청해야 했고, 이미 다녀온 항공권에는 적용되지 않았음

• 문제는 챗봇이 그냥 “틀렸다”로 끝나지 않았다는 점임

  • 고객은 챗봇 답변을 믿고 항공권을 샀고, 환불을 거절당하자 대화 캡처를 근거로 항의함
  • 에어캐나다는 공식 안내 페이지에는 정확한 정책이 적혀 있으니 챗봇 답변보다 그게 우선이라고 주장함
  • 재판소 판단은 달랐음. 챗봇도 회사 웹사이트의 일부이므로 회사가 책임져야 한다고 봤고, 에어캐나다는 812달러를 지급하게 됨

기존 소프트웨어는 계산하고, LLM은 생성함

• 기존 소프트웨어의 기본값은 결정론적(deterministic) 동작임

  • 은행 앱에서 10만 원을 이체하면 정확히 10만 원이 빠져야 함
  • 같은 코드와 같은 입력이면 같은 출력이 나와야 하고, 다르면 그건 대체로 버그임
  • 자동화 테스트도 이 전제 위에서 돌아감. 입력 A를 넣으면 출력 B가 나오는지 확인하면 됨

• LLM은 이 전제와 맞지 않음

  • 챗GPT나 제미나이에 같은 질문을 100번 던지면 문장, 길이, 뉘앙스가 매번 조금씩 달라질 수 있음
  • 가끔은 사실관계까지 흔들림. 그런데 이건 단순 고장이 아니라 모델 구조상 자연스러운 결과임
  • LLM은 정답을 계산한다기보다 다음에 올 단어를 확률적으로 예측하면서 답변을 만들어냄

• 그래서 AI 제품의 품질 기준은 “정답 여부” 하나로 끝나지 않음

  • 사실에서 벗어나지 않는지, 말투가 맞는지, 답변이 너무 길거나 짧지 않은지, 위험한 조언을 하지 않는지 봐야 함
  • 업계에서 이런 평가 작업을 Eval(evaluation)이라고 부르고, 일부 조직은 아예 Eval 엔지니어 역할까지 따로 두기 시작함

AI의 실패는 조용하고 그럴듯해서 더 까다로움

• 기존 장애는 보통 티가 남

  • 페이지가 안 열리고, 결제가 실패하고, 에러 로그가 찍히고, 모니터링 알람이 울림
  • 사용자도 “뭔가 고장 났다”고 느끼고, 개발팀도 비교적 빨리 감지할 수 있음

• AI 장애는 멀쩡한 말투로 찾아옴

  • 에어캐나다 챗봇은 오류 화면을 띄운 게 아니라 자신 있게 틀린 안내를 했음
  • 시스템은 정상 응답했고, 응답 시간도 괜찮았고, UI도 문제없었음. 다만 내용이 틀렸을 뿐임
  • 이런 패턴이 환각(hallucination)이고, AI 제품에서 제일 골치 아픈 실패 모드 중 하나임

• 더 무서운 건 틀렸다는 사실이 늦게 발견된다는 점임

  • 사용자가 답변을 믿고 행동한 뒤에야 문제가 드러날 수 있음
  • 로그에는 “성공적으로 응답함”만 남고, “틀린 정보를 줌”은 자동으로 기록되지 않을 수 있음
  • 결국 사후 검증, 사용자 신고, 샘플링 평가 같은 운영 장치가 필요해짐

비용 모델도 기존 SaaS랑 다르게 터짐

• 일반 SaaS 인프라 비용은 대체로 사용자 수와 트래픽에 비례해서 예측 가능함

  • 동시 접속자가 늘면 서버를 늘리고, 대략적인 비용 곡선을 잡을 수 있음
  • 물론 예외는 있지만, 그래도 선형에 가까운 감각으로 운영할 수 있음

• AI 제품은 토큰(token) 때문에 비용 감각이 확 달라짐

  • 어떤 사용자는 한 줄 질문을 던지고 한 줄 답을 받음
  • 어떤 사용자는 PDF 전체를 붙여 넣고 “요약해 줘”라고 함
  • 두 요청은 겉보기엔 같은 “질문 1회”지만 비용 차이가 100배 이상 날 수 있음

• 비용 폭증은 출시 후에야 보이는 경우가 많음

  • 전체 사용자 수는 그대로인데 특정 사용자가 긴 입력과 긴 출력을 반복하면서 한 달에 수천 달러어치 토큰을 쓸 수 있음
  • 그래서 AI 제품은 기능 출시 전에 토큰 한도, 사용량 모니터링, 과금 정책, 입력 제한을 같이 설계해야 함

AI 제품의 핵심은 오류를 없애는 게 아니라 피해를 줄이는 것임

• “환각 0%”를 KPI로 잡으면 팀이 끝없이 삽질할 가능성이 큼

  • 어떤 LLM도 환각을 100% 없애지 못함
  • 제품이 해야 할 일은 오류를 완전히 없애겠다는 선언이 아니라, 오류가 났을 때 피해가 커지지 않게 설계하는 것임

• 도메인마다 허용 가능한 오류 수준도 다름

  • 의료, 금융, 법률처럼 틀리면 피해가 큰 영역은 훨씬 엄격한 검증과 사람 개입이 필요함
  • 추천, 요약, 초안 작성처럼 회복 가능한 영역은 상대적으로 더 유연하게 운영할 수 있음
  • 결국 AI 품질은 맞다/틀리다의 이분법보다 “얼마나 자주, 얼마나 크게 틀리는가”의 분포로 봐야 함

• 신뢰 설계는 이제 AI UX의 핵심 영역임

  • 답변의 출처(sources)를 보여주고, 확신도(confidence)를 드러내고, 필요하면 인간 담당자에게 넘기는 경로(escalation)를 제공해야 함
  • “실수할 수 있습니다” 같은 작은 문구도 그냥 면피 문구가 아니라, 사용자가 답변을 맹신하지 않게 만드는 UX 장치에 가까움
  • 에어캐나다 챗봇이 정확한 정책 링크와 확인 안내를 함께 보여줬다면 결과는 꽤 달라졌을 가능성이 큼

출시 후 운영이 더 중요해짐

• 기존 소프트웨어는 배포한 코드가 그대로 있으면 동작도 대체로 그대로 유지됨

  • 물론 데이터나 외부 API 때문에 변할 수는 있지만, 기본적으로 코드를 바꾸지 않으면 결과도 크게 바뀌지 않는다는 감각이 있음

• AI 제품은 시간이 지나면서 품질이 흔들릴 수 있음

  • 모델 자체가 업데이트될 수 있고, 사용자 질문 패턴도 바뀜
  • 처음에는 “제품 설명해 줘”만 묻던 사용자가 나중에는 “경쟁사랑 비교해 줘”, “회사 망하면 환불되냐” 같은 민감한 질문을 던질 수 있음
  • 출시 전에 모든 질문 분포를 예측하기 어렵기 때문에 운영 중 관찰이 필수임

• AI PM은 출시 후에 오히려 더 바빠짐

  • 답변 품질이 떨어지는지, 비용이 어디서 새는지, 사용자들이 시스템을 어떤 식으로 우회하거나 확장해서 쓰는지 계속 봐야 함
  • 기존 PM의 사용자 중심 사고, 가설 검증, 데이터 기반 의사결정은 그대로 필요하지만, 이제 그 대상이 확률적으로 움직이는 시스템임

---

기술 맥락

• 여기서 가장 큰 기술적 선택은 AI 답변을 기존 API 응답처럼 “정확한 출력”으로 볼지, 확률적 생성물로 볼지예요. 이걸 헷갈리면 테스트도, 장애 대응도 전부 기존 방식에 갇히거든요.

• LLM은 같은 입력에도 다른 답을 만들 수 있으니, 단위 테스트 하나로 품질을 보장하기 어려워요. 그래서 Eval처럼 여러 샘플을 보고 사실성, 톤, 길이, 위험도를 평가하는 방식이 필요해져요.

• 환각 대응도 모델만의 문제가 아니에요. 출처 표시, 확신도, 상담원 연결 같은 UX 장치를 같이 둬야 사용자가 틀린 답을 100% 확정 정보처럼 받아들이는 일을 줄일 수 있어요.

• 비용 쪽에서는 토큰이 핵심이에요. 요청 1회가 같은 요청 1회가 아니라, 입력과 출력 길이에 따라 비용이 크게 달라지기 때문에 제품 레이어에서 사용량 제한과 모니터링을 같이 설계해야 해요.