SaaS 플랫폼에 AI 어시스턴트를 더한 방법 — 망가뜨리지 않고

우리가 이야기를 나누는 모든 SaaS 팀은 결국 같은 문장을 소리 내어 말합니다. "여기에 AI 어시스턴트를 넣어야 해." 이사회의 압박일 때도 있고, 경쟁사의 출시가 계기일 때도 있으며, 진심에서 나올 때도 있습니다. 흥미로운 부분은 결코 아이디어 자체가 아닙니다. 아이디어는 거의 모두가 가지고 있으니까요. 흥미로운 것은 그 문장과, 실제 사용자가 진짜로 의지하는 기능 사이의 간극입니다. 이것은 그 간극을 건넌 한 팀의 이야기이자, 그들을 거기까지 이끈 화려하지 않은 결정들의 기록입니다.

시작하기 전에 한마디. 고객사는 익명 처리했고 숫자는 반올림했습니다. 그들은 작지만 흑자를 내는 B2B SaaS 회사로, 직원은 스무 명 미만이며, 운영 팀을 위한 워크플로 도구를 판매합니다. 알아보지 못하도록 세부 사항을 충분히 바꿨지만, 프로젝트의 윤곽은 실제로 일어난 그대로입니다. 숫자는 예시일 뿐 감사를 거친 것이 아닙니다. 도표를 그럴듯하게 꾸미기보다 그 패턴을 보여드리고 싶습니다.

이 프로젝트를 정리해 쓰는 이유는, 이런 일이 실제로 어떻게 흘러가는지에 대한 거의 완벽한 사례이기 때문입니다. 킥오프 자료가 말한 대로 흘러가지 않았습니다. 오히려 더 잘 됐습니다. 다만 그것은 첫 번째 버전을 기꺼이 버렸기 때문입니다.

상황: 하나의 의상을 걸친 두 개의 문제

창업자가 처음 연락해 왔을 때 요청은 간단했습니다. "앱에 AI 챗봇을 원합니다." 대부분의 프로젝트가 여기서 시작하고, 대부분이 조용히 어긋나기 시작하는 지점이기도 합니다. "AI 챗봇"은 목표가 아니라 형태입니다. 그래서 우리의 첫 번째 일은, 그 챗봇이 풀어야 할 문제가 무엇인지, 그리고 그것이 애초에 하나의 문제이긴 한지를 알아내는 것이었습니다.

하나가 아니었습니다. 그 하나의 요청 아래에는 완전히 다른 두 가지 고통이 자리하고 있었습니다. 첫 번째는 지원 부하였습니다. 두 명의 고객 성공 팀이 반복되는 문의에 허우적대고 있었습니다. "이걸 어떻게 내보내나요", "그 설정은 어디 있나요", "제 리포트가 왜 실행되지 않았나요". 들어오는 티켓의 약 60%는 이미 도움말 문서 어딘가에 답이 있는 질문이었습니다. 두 번째 고통은 더 조용했고 더 비쌌습니다. 바로 활성화(정착)였습니다. 그들의 제품에는 세 번의 클릭 뒤에 묻혀 있는 정말 강력한 기능이 있었는데, 거의 아무도 스스로 발견하지 못했습니다. 그 기능을 찾은 사용자는 몇 년을 머물렀고, 찾지 못한 사용자는 첫 두 달 안에 이탈했습니다.

같은 의상, 두 개의 문제. 그리고 그것들은 서로 다른 방향으로 잡아당겼습니다. 지원 봇은 질문을 비껴가고 물러나려 합니다. 활성화 어시스턴트는 대화를 시작하고, 사용자가 묻지도 않은 것 쪽으로 넌지시 이끌려 합니다. 만약 이것들을 분리하지 않고 "AI 챗봇"을 만들었다면, 두 가지 일을 모두 어설프게 하는 무언가를 만들었을 것입니다.

끝낼 수 있는 규모로 좁히기

두 개의 문제를 마주하면, 첫날부터 둘 다 처리하는 거창한 어시스턴트를 만들고 싶은 유혹이 생깁니다. 우리는 팀을 설득해 그만두게 했습니다. 비전이 틀렸기 때문이 아닙니다. 6개월짜리 "만능 어시스턴트"야말로 정확히 납기를 넘기고, 밋밋하게 안착하며, 이후 2년간 모두가 AI에 대해 불안해하게 만드는 그런 프로젝트이기 때문입니다.

그래서 하나를 골랐습니다. 지원 문의 감소를 먼저 택한 것은 지루하지만 결정적인 세 가지 이유 때문입니다. 명확하고 측정 가능한 목표가 있었습니다 — 티켓 수. 이미 존재하는 콘텐츠를 썼습니다 — 도움말 문서와 과거 티켓. 그리고 성과가 미흡해도 손실이 작았습니다 — 좋은 답을 얻지 못한 사용자는 그저 하던 대로 티켓을 열면 그만이었습니다. 낮은 위험, 빠른 피드백, 정직한 지표. 이것은 언제나 좋은 첫 AI 기능입니다.

활성화 어시스턴트가 사라진 것은 아닙니다. 서류상으로, 명확한 메모와 함께 보류했습니다. 2단계, 검색 계층이 검증된 뒤에라고. 그 하나의 결정이 아마도 프로젝트를 구했습니다. 분기 단위가 아니라 몇 주 안에 실제로 도달할 수 있는 결승선을 팀에게 준 것입니다.

우리가 만들었다가 — 삭제한 첫 프로토타입

여기가 대부분의 사례 연구가 빼놓는 부분입니다. 우리의 첫 번째 작동하는 프로토타입은, 좋게 말해도 좋지 않았습니다. 우리는 뻔한 것을 했습니다. 제품의 도움말 글을 대규모 언어 모델에 연결하고, 채팅 상자를 붙이고, 사용자가 질문하게 했습니다. 데모에서는 마법처럼 보였습니다. 그러나 실제 테스트에서는 매우 구체적이고 매우 교훈적인 방식으로 무너졌습니다.

모델은 당당하게 틀렸습니다. 여섯 달 전에 이름이 바뀐 설정에 대해 물으면, 명랑하게 옛 메뉴 경로를 지어냈습니다. 상위 요금제의 기능에 대해 물으면, 그것에 접근할 수 없는 고객에게 사용법을 설명했습니다. 모든 답이 권위 있게 들렸고, 그것이 틀린 답을 아예 답이 없는 것보다 더 나쁘게 만들었습니다. 정중하게 거짓말하는 지원 봇은 티켓을 줄이지 않습니다. 더 화난 문의를 만들 뿐입니다.

프롬프트 손질로 대충 덮을 수도 있었습니다. 대신 우리는 한 걸음 물러서는 것처럼 느껴졌지만 결국 승부의 전부였던 일을 했습니다. 첫 프로토타입을 버리고, 엄격한 규칙을 중심으로 다시 만들었습니다 — 어시스턴트는 출처를 인용할 수 있는 자료에서만 답할 수 있으며, 그렇지 않으면 "모르겠습니다"라고 말해야 한다는 규칙.

우리가 실제로 만든 것

출시한 버전은 시도하는 범위를 의도적으로 겸손하게, 행동 방식을 엄격하게 했습니다. 내부적으로는 검색에 근거한 어시스턴트였습니다. 사용자가 무언가를 물으면, 시스템은 먼저 정돈된 최신 지식 베이스를 검색하고, 그다음 모델에게 찾은 내용만으로, 출처로 돌아가는 링크와 함께 답하도록 요청했습니다. 출처가 없으면 자신 있는 답도 없습니다 — 그저 사람에게 깔끔하게 넘기는 것뿐입니다.

세 가지 설계 선택이 힘든 일의 대부분을 해냈고, 그중 어느 것도 흥미롭지 않습니다. 그것이 핵심입니다. AI 기능이 신뢰받을지 아니면 조용히 꺼질지를 결정하는 것은 대개 지루한 선택들입니다.

영리함보다 근거

모든 답은 실재하는 최신 문서에 묶여 있었습니다. 우리는 모델을 튜닝하는 것보다 지식 베이스를 정리하고 구조화하는 데 더 많은 시간을 썼습니다. 화려하지 않지만, 프로젝트에서 단연 레버리지가 가장 높은 작업이었습니다. 훌륭하고 잘 관리된 콘텐츠 위의 평범한 모델은, 낡고 엉망인 자료 위의 뛰어난 모델을 이깁니다.

우아한 인계

어시스턴트는 확신이 없을 때 추측하지 않았습니다. 그렇다고 말하고, 클릭 한 번으로 사람에게 가는 길을 내밀었습니다 — 대화 맥락을 함께 넘겨주어 사용자가 같은 말을 반복할 필요가 없게 했습니다. 직관과 반대로, 이것이 봇에 대한 신뢰를 높였습니다. 한계를 인정하는 어시스턴트는 정직하게 느껴지고, 사용자는 봇이 어려운 40%에서 물러서기에 오히려 쉬운 60%를 안심하고 의지했습니다.

누가 묻는지를 아는

제품 안에 존재했기에, 어시스턴트는 사용자의 요금제, 역할, 앱 안에서의 위치를 알고 있었습니다. 그래서 접근할 수 없는 기능을 설명하는 일이 없었고, "찾으시는 버튼은 지금 보고 계신 화면에 있습니다"라고 말할 수 있었습니다. 이 제품 인식이야말로 마케팅 사이트에 갖다 붙인 범용 챗봇에 대한, 인앱 어시스턴트의 진짜 강점입니다.

1. 1
   지식 베이스 정리 및 구조화

   모든 도움말 문서를 점검하고, 낡은 것을 없애고, 나머지를 요금제와 기능별로 태그했습니다. 이것이 1주 차였고 가장 중요한 주였습니다.
2. 2
   검색 계층 구축

   먼저 검색, 그다음 답변. 모델은 언제나 검증된 최신 콘텐츠만 보았고, 출처에 근거할 수 없는 것은 거부하도록 지시받았습니다.
3. 3
   제품 맥락 연결

   어시스턴트를 사용자의 요금제, 역할, 현재 화면에 연결해 답을 맞춤화하고 쓸 수 없는 기능을 가리키지 않게 했습니다.
4. 4
   정직한 대체 경로 설계

   '확실하지 않아요 — 담당자를 연결해 드릴게요' 경로를 일급 기능으로 만들고, 전체 대화 맥락을 지원팀에 넘겼습니다.
5. 5
   플래그 뒤에서 사용자 10%에게 출시

   일부 계정에 조용히 배포하고, 실제 대화를 2주간 지켜보며 깨진 것을 고친 뒤 배포를 넓혔습니다.

결과 — 그리고 우리를 놀라게 한 하나

어시스턴트가 모두에게 공개된 지 약 3개월 뒤, 그림은 분명해졌습니다. 반올림한 예시 수치를 드리겠습니다 — 소수점보다 방향이 더 중요합니다.

지원 수치는 우리가 약속한 것이었고, 그대로 이뤄냈습니다. 반복 티켓의 절반 남짓이 아예 들어오지 않게 되었고, 두 사람의 팀은 진짜로 사람이 필요한 사례를 다룰 한 주를 되찾았습니다. 좋은 결과, 정확히 범위대로입니다.

그러나 창업자를 진짜로 놀라게 한 결과는 우리가 전혀 최적화하지 않은 것이었습니다. 어시스턴트가 하루 종일 "X를 어떻게 하나요" 질문에 답하다 보니, 자연스럽게 그 묻혀 있던, 정착으로 이어지는 기능 쪽으로 사용자를 계속 이끌었습니다 — 리텐션과 연결된 바로 그 기능으로. 우리는 아직 활성화 어시스턴트를 만들지 않았습니다. 지원 봇이 그저 도움이 되고 제품을 이해한다는 것만으로, 그 일의 일부를 부작용처럼 조용히 해내고 있었던 것입니다. 신규 사용자들이 예전보다 몇 주 일찍 그 기능을 찾고 있었습니다.

다음 팀에게 전하고 싶은 것

만약 당신이 같은 "AI 어시스턴트를 추가해야 해"라는 문장을 바라보는 SaaS 팀이라면, 이 프로젝트에서 그 범위를 훌쩍 넘어 잘 들어맞는 것들이 몇 가지 있습니다.

• 만들기 전에 문제를 분리하세요. "AI 챗봇"은 거의 언제나 서로 다른 설계를 원하는 두세 가지 별개의 일을 숨기고 있습니다.
• 틀린 답의 비용이 가장 적은 사용 사례부터 시작하세요. 지원 문의 감소는 거의 완벽한 첫수입니다. 실패해도 현상 유지로 돌아갈 뿐입니다.
• 노력의 대부분을 모델이 아니라 콘텐츠에 배정하세요. 깨끗하고 최신인 데이터에 대한 근거가 어시스턴트를 믿을 만하게 만듭니다.
• "모르겠습니다"를 실패가 아니라 기능으로 만드세요. 정직한 인계는 봇이 잘하는 부분을 사용자가 의지하게 만드는 신뢰를 쌓습니다.
• 먼저 플래그 뒤에서 작은 일부에게 출시하세요. 실제 대화는 어떤 데모도 가르쳐 주지 못하는 것을 가르쳐 줍니다.

자주 묻는 질문