AI/AI Product

예약 서비스의 AI 기능, 어디까지 맡길지 자동화 수준 정하기

예약 서비스 기획을 하다 보면 AI 기능 이야기가 나올 때마다 같은 질문에 부딪힙니다."그래서 AI가 어디까지 알아서 하게 할 건가요?"라는 질문이에요.처음에는 이걸 "할 수 있다 / 없다"의 문제로 생각했어요.그런데 공부하고 정리하다 보니 진짜 질문은 "할 수 있느냐"보다 "알아서 하게 둬도 되느냐"에 가깝더라고요.모델이 예약을 바꾸는 일 자체는 기술적으로 어렵지 않아졌지만, 바꿔도 되는 일인지는 전혀 다른 문제입니다.이번 글은 AI 기능의 자동화 수준을 단계로 나눠 보고, 예약 서비스의 기능별로 어느 단계가 어울리는지 정리해본 메모입니다.실제로 만들어 운영한 결과를 쓰는 글은 아니고, 기획하면서 공부한 내용을 바탕으로 한 가설에 가깝습니다.예시에 나오는 업장과 숫자는 모두 설명을 위해 가정한 것이에요..

예약 시스템에 AI 에이전트를 붙인다면, 설계 원칙

예약 시스템 기획을 하다 보면 "AI가 대신 예약해주면 되지 않나요?"라는 이야기를 자주 듣게 됩니다.말로 하면 간단한데, 막상 설계하려고 하면 따져볼 것이 한두 가지가 아니에요.이번 글은 예약 시스템에 AI 에이전트를 붙인다고 가정했을 때, 제가 기획자로서 지켜야 한다고 생각하는 설계 원칙을 정리한 것입니다.실제로 만들어서 운영한 경험을 쓰는 글은 아니고, 그동안 예약 도메인과 AI를 함께 공부하며 정리한 가설에 가깝습니다.그래서 확정된 정답이라기보다 "이런 선을 먼저 그어두면 좋겠다"는 메모로 읽어주시면 좋겠습니다. 에이전트를 붙인다고 하면 모든 걸 맡기고 싶은 마음이 먼저 듭니다.하지만 처음에는 할 일을 아주 좁게 정하는 것이 안전하다고 생각해요.예를 들어 가상의 반려동물 미용실이 있다고 해보겠습니..

챗봇으로 예약 받기, 자연어 예약 시나리오 기획

예약 서비스를 기획하다 보면 한 번쯤 이런 상상을 하게 됩니다.고객이 폼을 채우는 대신 "다음 주 목요일 저녁에 두 명 자리 있어요?"라고 말하면 알아서 예약까지 이어지면 좋겠다는 상상이에요.LLM을 공부하면서 이 상상이 꽤 현실적인 범위에 들어왔다고 느꼈고, 그래서 시나리오를 기획 문서 수준으로 한 번 그려봤습니다.이 글은 제가 정리한 구조와, 그 과정에서 가장 중요하다고 느낀 책임 분리에 대한 기록입니다. 자연어로 예약을 받는 일을 분해해보면, 결국 필요한 정보를 모으는 일입니다.예약 한 건이 성립하려면 최소한 어떤 서비스인지, 날짜와 시간은 언제인지, 몇 명인지, 누구에게 연락하면 되는지가 필요해요.이 필요한 항목들을 흔히 슬롯이라고 부르고, 고객 발화에서 슬롯을 채워 나가는 방식을 슬롯 채우기라고..

LLM의 환각, 기획 단계에서 정해둘 것들

ChatGPT를 쓰다 보면 그럴듯하지만 사실이 아닌 답을 만나는 순간이 반드시 옵니다.없는 논문을 실제 있는 것처럼 인용하거나, 존재하지 않는 기능을 자신 있게 설명하는 식이에요.흔히 이런 현상을 환각(hallucination)이라고 부릅니다.개인이 대화창에서 쓸 때는 "확인해보면 되지" 하고 넘어갈 수 있지만, 서비스 안에 넣는다면 이야기가 달라집니다.이 글에서는 제가 공부하면서 "개발에 들어가기 전에 기획이 먼저 정해둬야 한다"고 느낀 것들을, 예약 안내 챗봇을 가정해서 정리해봅니다. 환각이 있다는 사실 자체보다, 어디에서 그것이 문제가 되는지를 구분하는 게 먼저라고 생각했습니다.모델이 지어낸 말이 "무해한 틀림"인지, 사용자의 돈이나 시간에 영향을 주는 "해로운 틀림"인지가 다르기 때문이에요.예약 ..

AI 기반 개인화, 어디까지 해야 하나

개인화 추천 기능을 담당하면서 가장 많이 받는 질문이 "이거 좀 무섭지 않아요?"라는 반응입니다.사용자가 검색한 적도 없는데 딱 필요한 걸 추천해주면 신기하다는 반응이 나오다가, 그게 조금만 더 나가면 "내 걸 다 알고 있는 것 같아서 불편하다"는 반응으로 바뀝니다.저희 서비스에서도 이 경계선을 두 번쯤 넘었다가 다시 되돌아온 경험이 있어서, 이 주제에 대해 좀 길게 정리해보고 싶었습니다. 개인화가 잘 작동하면 효과는 확실합니다.저희가 홈 화면에 개인화 추천 위젯을 처음 도입했을 때, 클릭률이 기존 인기순 노출 대비 40% 가까이 올랐어요.사용자가 원하는 걸 더 빨리 찾게 해준다는 점에서 개인화는 분명 사용자에게도 이득입니다.그런데 이 효용에는 대가가 따릅니다.개인화를 잘하려면 더 많은 데이터가 필요하고..

챗봇 UX 라이팅 - 톤앤매너 정하기

챗봇 프로젝트를 진행하면서 가장 과소평가됐던 작업이 UX 라이팅이었습니다.개발 일정과 NLU 정확도에는 다들 신경을 쓰는데, "이 챗봇이 어떤 말투로 말할 것인가"는 회의 마지막에 잠깐 다뤄지고 넘어가는 경우가 많았어요.저희도 초반엔 그랬다가, 런칭하고 나서 사용자들이 "챗봇이 너무 딱딱하다"는 피드백을 꽤 많이 남기는 걸 보고서야 이 문제를 제대로 다루기 시작했습니다. 톤앤매너 가이드 없이 여러 사람이 답변 스크립트를 쓰면, 같은 챗봇인데 문장마다 말투가 다 달라집니다.어떤 답변은 "확인해드리겠습니다"로 끝나고, 어떤 답변은 "확인해볼게요!"로 끝나는 식이었어요.사용자 입장에서는 이게 같은 챗봇이 하는 말인지 헷갈릴 수 있습니다.저희는 결국 "친절하지만 과하게 캐주얼하지 않은, 신뢰감 있는 톤"이라는 ..

AI 프로덕트의 신뢰(Trust) 설계

AI 기능을 기획하면서 요즘 가장 자주 떠올리는 단어가 "신뢰"입니다.정확도나 속도만큼, 혹은 그 이상으로 중요한 게 사용자가 이 AI 결과를 얼마나 믿을 수 있느냐는 문제였어요.이번 글에서는 저희 팀이 AI 기능을 만들면서 신뢰를 어떻게 설계에 반영했는지, 그리고 그 과정에서 겪은 시행착오를 정리해보려 합니다. 처음엔 정확도가 높으면 신뢰도 자연스럽게 따라올 거라고 생각했습니다.그런데 실제로는 정확도가 90%인 기능인데도 사용자가 안 믿는 경우가 있었고, 정확도가 70%대인 기능인데 사용자들이 잘 활용하는 경우도 있었어요.차이를 들여다보니, 사용자가 "왜 이런 결과가 나왔는지"를 이해할 수 있느냐가 정확도보다 신뢰에 더 큰 영향을 주고 있었습니다.근거를 보여줄 수 있는 기능은 정확도가 조금 낮아도 사용..

AI 챗봇 페르소나 설계 노트

챗봇을 기획하면서 가장 뒤로 밀리기 쉬운 작업이 페르소나 설계입니다."일단 답변이 잘 나오게만 하자"가 우선이 되기 쉬운데, 저희도 처음엔 그렇게 접근했다가 나중에 크게 후회했어요.페르소나 없이 만든 챗봇의 말투가 화면마다 미묘하게 달라져서, 사용자 입장에서는 마치 서로 다른 사람이 응대하는 것처럼 느껴졌던 거죠. 초기 버전에서 챗봇은 어떤 답변에서는 "죄송하지만 확인이 어렵습니다"라고 하고, 다른 답변에서는 "그건 안 돼요!"라고 했습니다.답변 스크립트를 여러 사람이 나눠서 작성했기 때문이었어요.사용자 피드백 중에 "챗봇이 갑자기 반말로 답해서 놀랐다"는 항의가 몇 건 들어왔는데, 확인해보니 한 담당자가 급하게 스크립트를 추가하면서 톤을 못 맞춘 거였습니다.이 문제를 겪고 나서야 저희는 "이 챗봇은 누..