솔직히 이건 예상 밖이었습니다. 클라이언트 SaaS에 ChatGPT를 붙이고 나서 D7, 즉 출시 7일 차에 "왜 이런 답이 나왔지?"라는 컴플레인이 12건이나 쌓였을 때, 처음엔 모델 문제인 줄 알았습니다. 그런데 원인은 전혀 다른 곳에 있었고, 그걸 알게 된 건 AI UX 설계를 다룬 한 발표 영상 덕분이었습니다. 5년 차 프리랜서로 일하면서 ChatGPT 통합 관점이 이렇게 크게 바뀐 건 처음이었습니다.
챗봇을 붙이면 끝이라고 생각했습니까
저도 처음엔 그렇게 생각했습니다. AI 기능을 붙이는 일은 그냥 챗 UI(Chat UI)를 심는 것, 즉 입력창 하나에 LLM 응답을 출력하는 구조로 충분하다고 봤습니다. 여기서 챗 UI란 사용자가 자연어로 질문하고 AI가 실시간으로 응답하는 대화형 인터페이스를 말합니다. 빠르게 배포할 수 있고, 클라이언트도 '우리 제품에 AI 들어갔다'고 말할 수 있으니 누이 좋고 매부 좋은 구조처럼 보였습니다.
그런데 실제 운영에 들어가면 이야기가 달라집니다. 제가 직접 운영해봤는데, 가장 자주 받는 컴플레인이 바로 "AI가 왜 이 답을 했는지 모르겠다"는 불신이었습니다. 사용자는 AI의 답을 받았지만 그 답이 어디서 왔는지, 얼마나 믿을 수 있는지 전혀 알 수 없는 상태였습니다. 챗봇이 컨텍스트(context)를 기억하지 못하는 문제도 반복됐습니다. 컨텍스트란 대화의 앞뒤 맥락 전체를 가리키는 말로, 이게 끊기면 사용자는 매번 처음부터 다시 설명해야 하는 상황에 놓입니다. 실제로 금융 앱에서 환불 요청을 하루 걸러 다시 설명해야 했다는 사례는 그 전형입니다.
그렇다면 단순 챗봇이 잘 작동하지 않는 상황은 어떤 경우일까요. 제 경험과 UX 연구를 종합해보면 다음 네 가지 상황에서 특히 문제가 됩니다.
- 사용자의 컨텍스트와 인텐트(intent)가 명확하지 않을 때. 인텐트란 사용자가 지금 이 순간 무엇을 달성하려 하는지를 가리키는 개념입니다.
- 복잡한 멀티스텝 작업을 순차적 채팅으로 처리해야 할 때
- 병렬 에이전트(agent) 작업 결과를 한 화면에서 비교해야 할 때. 에이전트란 특정 목표를 위해 자율적으로 작동하는 AI 모듈을 말합니다.
- 사용자가 AI 응답의 근거를 확인하고 싶을 때
챗봇을 '만능 해결사'처럼 붙여놓는 방식이 왜 실패하는지, 이 네 가지 상황이 설명해줍니다.
컨텍스트 분기 구조로 바꾸자 생긴 일
저는 12건의 컴플레인을 받은 뒤 구조 자체를 바꾸기로 했습니다. 발표에서 언급된 인텐트 기반 AI 패턴, 특히 '젠 앤 트윅(Gen and Tweak)' 패턴이 핵심 실마리였습니다. 젠 앤 트윅이란 전체 콘텐츠를 한 번에 생성한 뒤 사용자가 원하는 부분만 선택적으로 수정하는 방식입니다. Typeform의 폼 생성 기능이나 Apple Mail의 어조 조정 기능이 대표 사례입니다. 전체를 버리고 처음부터 다시 생성하는 것이 아니라, 일부만 정밀하게 교체하는 구조입니다.
저는 이 아이디어를 React 컴포넌트로 묶어서 적용했습니다. AI 응답 카드 하나에 네 가지 기능을 Variants로 정리했습니다. 출처 펼침, 신뢰도 배지, 재생성 버튼, 컨텍스트 요약 토글이 그것입니다. 여기서 신뢰도 배지란 AI 응답이 어떤 데이터나 규칙을 근거로 생성됐는지를 시각적으로 표시하는 UI 요소를 말합니다. 사용자가 응답을 보는 순간 '이 답이 어디서 왔는지'를 바로 확인할 수 있게 됩니다.
결과는 명확했습니다. 같은 D7 기준으로 컴플레인이 0건으로 떨어졌습니다. 이후 외주 3건에서 동일한 컴포넌트를 재사용 중이고, 지금도 제 라이브러리에서 가장 자주 꺼내 쓰는 구조입니다. AI 설계 연구를 다룬 Nielsen Norman Group의 보고서에서도 사용자가 AI 응답의 근거를 볼 수 있을 때 신뢰도와 재사용 의향이 함께 높아진다고 밝히고 있습니다(출처: Nielsen Norman Group).
ChatGPT 통합을 '챗 박스'로만 보던 시각이 이 시점에서 완전히 바뀌었습니다. 지금은 응답 흐름 전체를 컨텍스트 분기 그래프로 바라봅니다. 어떤 인텐트가 들어왔을 때 어떤 경로로 컨텍스트가 연결되고, 어느 지점에서 분기가 생기는지를 먼저 그린 뒤에 UI를 설계합니다.
인텐트 설계 없이 AI를 붙이면 무슨 일이 벌어지는가
발표에서 가장 인상 깊었던 부분이 있습니다. Expedia가 호텔 파트너를 위한 코칭 플랫폼을 만들 때, 파트너의 니즈(need)를 '예약 증가'로 단순화했던 이야기입니다. 니즈란 사용자가 궁극적으로 원하는 고수준의 목표를 가리킵니다. 문제는 니즈만 보면 AI에게 줄 수 있는 신호가 너무 추상적이라는 점입니다. AI가 실제로 작동하려면 인텐트, 즉 지금 이 순간 무엇을 하려는지를 포착해야 합니다.
예를 들어 '예약 늘리고 싶다'는 니즈보다, '지금 이 시즌에 경쟁 호텔 대비 가격 포지셔닝을 조정하고 싶다'는 인텐트가 AI에게 훨씬 구체적인 입력값이 됩니다. 추천 시스템(recommendation system)이 제대로 작동하려면 이 인텐트를 신호로 받아야 합니다. 추천 시스템이란 사용자의 행동 데이터를 분석해 다음에 취할 행동이나 관심 항목을 예측해 보여주는 알고리즘 구조를 말합니다.
제가 매 외주 시작 시 클라이언트와 함께 점검하는 ChatGPT 통합 함정 평가 시트를 노션에 정리해 운영 중인데, 그 중 핵심 항목 세 가지를 꼽자면 다음과 같습니다.
- 컨텍스트 연속성: AI가 이전 대화와 현재 요청을 연결할 수 있는 구조인가
- 인텐트 명시성: 사용자의 요청이 어느 인텐트 카테고리에 해당하는지 분기가 설계되어 있는가
- 설명 가능성: AI 응답이 왜 이렇게 나왔는지 사용자에게 보여줄 수 있는가
한국 시장에서 추가로 봐야 할 지점이 있습니다. 바로 톤 분기입니다. 한국 사용자는 첫 인사 톤이 '편한 친구'에서 '존댓말'로 바뀌면 같은 모델이라도 신뢰도를 다르게 느낍니다. 제 경험상 이건 실제로 컴플레인으로 이어집니다. 글로벌 발표에서 다루지 않은 부분이지만, 한국어 컨텍스트 유지 이슈는 별도로 반드시 설계해야 합니다. 실제로 LLM 모델별 한국어 토큰 효율 차이도 클라이언트 의사결정에 직접 영향을 미칩니다. 한국어는 영어 대비 토큰 소비량이 많기 때문에 같은 기능이라도 비용 구조가 달라질 수 있습니다. 이 부분은 Hugging Face의 토크나이저 벤치마크 데이터를 참고하면 모델별 비교가 가능합니다(출처: Hugging Face).
AI 통합을 처음 설계할 때 인텐트 구조를 먼저 그리지 않으면, 결국 운영 단계에서 사용자 불신이 쌓이는 구조가 됩니다. 이 순서를 거꾸로 뒤집어 사람의 인텐트에서 출발하는 것이 결국 더 빠른 길입니다.
5년 치 외주 경험을 통해 한 가지 확신이 생겼습니다. AI 기능을 잘 붙이는 개발자와 그냥 붙이는 개발자를 나누는 기준은 코드 실력이 아니라 인텐트 설계와 신뢰도 패턴을 얼마나 깊게 이해하느냐입니다. 챗봇을 넣기 전에 먼저 "이 사용자가 지금 무엇을 하려는가"를 한 번만 더 물어보는 습관, 그게 D7 컴플레인 12건을 0건으로 만든 가장 단순한 변화였습니다.