지난 2년 동안 구축된 거의 모든 기업 웹사이트를 열어보면 오른쪽 하단에 작은 원형 아이콘이 나타납니다. "안녕하세요! 오늘 무엇을 도와드릴까요?"

이 상황이 어떻게 흘러갈지는 이미 알고 계실 겁니다. 당신이 실제 질문을 입력하면, 봇은 당신이 이미 찾아냈을 법한 고객 센터 링크를 건네주고, 결국 당신은 어차피 고객 지원팀에 이메일을 보내게 됩니다.

우리는 집단적으로 모든 웹사이트에 챗봇이 필요하다고 결정해 왔습니다. 저는 우리가 잘못된 이유로 챗봇을 추가했다고 생각합니다. 그리고 그 이유는 불만 사항보다 더 흥미롭습니다.

우리 모두가 인지하는 패턴

일반적인 사이트 봇에는 세 가지 문제가 있으며, 이는 외관상의 문제가 아니라 구조적인 문제입니다.

첫째, 그것은 오직 당신의 사이트만 알고 있습니다. 그것은 당신의 콘텐츠 중 아주 좁은 부분만을 학습(trained)하거나 인덱싱(indexed)했기 때문에, 질문이 그 범위를 벗어나는 순간 아무것도 알지 못합니다. 인간 고객 지원 상담사가 두 가지 사실을 결합하여 한 문장으로 대답할 만한 질문을 던지면, 봇은 멈춰버립니다.

둘째, 실제적인 능력이 없습니다. 그것은 당신의 실제 주문을 확인할 수 없고, 실시간 재고를 볼 수 없으며, 당신이 하러 온 일을 수행할 수 없습니다. 그것은 텍스트를 검색(retrieves)하고 재구성(reformats)할 뿐입니다.

셋째, 방해를 합니다. 그것은 당신과 페이지 사이에 놓인 하나의 층(layer)이며, 대부분의 경우 당신은 그냥 페이지를 읽고 싶어 합니다.

이것은 특정 벤더(vendor)를 비난하는 것이 아닙니다. 봇들이 이렇게 행동하는 이유는 그것들이 근본적으로 무엇인지 때문입니다. 그리고 바로 그 부분이 살펴볼 가치가 있는 지점입니다.

왜 어디에나 있는가

제 주장은 이렇습니다. 챗봇이 웹 전반에 퍼진 이유는 사용자가 그것을 원해서가 아니라, 웹사이트에 "AI"를 넣을 수 있는 유일한 방법이었기 때문입니다.

실제 사건의 순서를 생각해 보십시오. 한 기업이 AI 스토리가 필요하다고 결정합니다. 그때 바로 사용할 수 있고(off-the-shelf), 스크립트 태그(script-tag)만 삽입하면 되는 옵션은 챗봇 위젯입니다. 그래서 챗봇 위젯이 설치됩니다. 이 기술은 마케팅 질문 — "우리가 AI를 보유하고 있음을 어떻게 보여줄 것인가?" — 에 답한 것이지, 사용자 질문 — "어떻게 하면 내 질문에 더 빨리 답을 얻을 수 있는가?" — 에 답한 것이 아닙니다.

이것이 바로 임시방편(workaround)의 정의입니다. 적절해서가 아니라, 사용 가능하기 때문에 선택하는 것 말입니다.

이것들이 실제로 작동하는 방식

최근 저는 한 유명 챗봇 업체에 — 그들의 일반적인 지원 채널을 통해 — 그들의 시스템이 웹사이트의 데이터를 어떻게 수집(ingest)하고 답변하는지 자세히 설명해 달라고 요청했습니다. 답변은 정중하고 전문적이었으며, 진정으로 통찰력을 주었습니다. 특정 업체를 비난하려는 것이 아니라 현재 이 카테고리 전체가 작동하는 방식에 대한 것이므로, 업체명은 익명으로 유지하겠습니다.

세 가지 사항이 눈에 띄었습니다.

사용자의 라이브 사이트가 아닌 스냅샷(snapshot)을 기반으로 답변합니다. 사용자가 질문을 할 때, 봇은 그 순간 귀하의 웹사이트를 읽지 않습니다. 대신 이전에 인덱싱(indexed)해 둔 복사본을 읽습니다. 이 복사본은 일간, 주간 또는 월간 단위의 일정에 따라 갱신됩니다. 블로그라면 괜찮습니다. 하지만 가격, 재고 현황, 약관처럼 변경되는 내용이 있는 경우라면, 봇은 사용자에게 오래된 사진을 보고 있다는 신호를 전혀 주지 않은 채 몇 주나 지난 정보를 자신 있게 인용하게 된다는 것을 의미합니다.

페이지가 나뉜 피드(paginated feed)를 따라갈 수 없습니다. 저는 여러 페이지로 구성된 구조화된 카탈로그를 어떻게 탐색하는지 물었습니다. 하지만 봇은 그렇게 하지 못합니다. 권장된 임시방편(workaround)은 모든 것을 별도의 정적 URL 목록으로 평탄화(flatten)한 뒤 XML 사이트맵(sitemap)을 전달하는 것이었습니다. 다시 말해, 수집기(ingester)가 피드를 탐색할 수 없기 때문에, 현대적인 구조화된 소스를 수집하려면 20년 전의 '페이지당 문서 하나' 모델로 돌아가야 한다는 뜻입니다.

필요한 기능들은 모두 업셀(upsell, 추가 판매) 항목입니다. 쿼리 스트링(query-string) URL 보존, 페이지가 나뉜 피드 수집, 구조화된 카탈로그의 적절한 처리와 같은 기능들은 표준 사양이 아니었습니다. 그것들은 유료 플랜을 사용하는 고객들을 위해 구축을 고려해 볼 만한 기능들로 설명되었습니다.

이 점을 곱씹어 보십시오. 전체 아키텍처(architecture)가 라이브 소스를 보지 않도록 설계되어 있습니다. 스냅샷, 예정된 재크롤(recrawl), 평탄화된 사이트맵 — 모든 요소는 질문이 던져지는 순간 귀하의 사이트를 읽는 것을 피하기 위해 존재합니다. 봇은 귀하의 웹사이트를 읽지 않습니다. 빛바랜 복사본을 가지고 그것을 바탕으로 답변할 뿐입니다.

사용자가 실제로 원했던 것

질문을 입력하는 사람에게로 다시 시선을 돌려보십시오. 그들은 결코 _귀하의 웹사이트 안에 거주하는 어시스턴트_를 원한 것이 아닙니다. 그들은 답변을 원했습니다. 그리고 점점 더 많은 사람들이 귀하의 페이지에 도달하기도 전에, 이미 열어둔 어시스턴트에게 질문함으로써 완전히 다른 곳에서 그 답변을 얻고 있습니다.

그것이 바로 챗봇이 완전히 놓치고 있는 변화입니다. 챗봇은 AI가 귀하의 사이트 위에 존재해야 한다고 가정합니다. 하지만 사용자들이 실제로 의존하는 AI는 그 누구의 사이트 위에도 존재하지 않습니다. 그것은 그들의 주머니 속에 있는 범용 어시스턴트(general assistant)입니다. 그리고 그 어시스턴트는 정보가 읽을 수 있는 방식으로 노출되어 있다면, 실제의 최신 정보를 읽고 추론할 수 있는 완벽한 능력을 갖추고 있습니다.

"내 사이트 위의 AI"에서 "AI가 읽을 수 있는 내 사이트"로

이것이 제가 중요하다고 생각하는 재정의(reframing)입니다.

챗봇 방식은 약하고 샌드박스화된(sandboxed) AI를 귀하의 페이지 안으로 가져옵니다. 반대의 접근 방식은 사용자가 이미 사용 중인 강력한 범용 AI가 귀하의 콘텐츠를 읽을 수 있게 만듭니다. 하나는 형편없는 어시스턴트를 귀하의 사이트에 가두는 것이고, 다른 하나는 귀하의 콘텐츠가 훌륭한 어시스턴트에 의해 읽힐 수 있도록 자유롭게 풀어주는 것입니다.

그리고 두 번째 방식이 플랫폼들이 조용히 나아가고 있는 방향입니다. 구조화된, 기계가 읽을 수 있는(machine-readable) 콘텐츠. 에이전트(agent)가 사이트가 제공하는 것을 발견하고 읽을 수 있도록 하는 표준 프로토콜. 이 변화는 페이지를 인간의 눈(그리고 검색 크롤러)에 최적화하는 것에서 나아가, 한 사람을 대신하여 행동하는 에이전트가 읽을 수 있도록 만드는 것으로의 전환입니다. 즉, 한 달 전의 복사본이 아니라 _현재_의 데이터를 읽고, 실제 구조를 따르며, 정말로 그곳에 있는 내용에 대해 추론하도록 만드는 것입니다.

이것은 스냅샷 및 사이트맵(snapshot-and-sitemap) 모델의 정확한 역방향입니다. 이제 에이전트는 소스(source)를 직접 읽습니다. 복사본이 아니라 말입니다.

이것은 공짜가 아닙니다

에이전트가 읽을 수 있는 방향이 순수하게 이점만 있다고 가장하고 싶지는 않습니다. 그것은 문제를 제거하는 것이 아니라 어려운 문제들을 이동시키는 것이며, 그중 두 가지는 솔직하게 언급할 가치가 있습니다.

첫 번째는 비즈니스 모델 (business model)입니다. 만약 고객의 어시스턴트 (assistant)가 귀하의 데이터를 읽고 질문을 해결하거나 — 심지어 구매까지 완료하여 — 고객이 귀하의 페이지에 전혀 접속하지 않게 된다면, 그 페이지가 수행하던 모든 기능은 어떻게 될까요? 교차 판매 (cross-sell), 브랜드 경험 (brand experience), 관련 제품, 그리고 귀하가 보여주려 했던 광고 등이 말입니다. 검색 엔진 (search engines)은 이미 제로 클릭 답변 (zero-click answers)을 통해 이를 시작했으며, 에이전트 (agents)는 이를 더욱 가속화합니다. 외부 어시스턴트가 읽을 수 있도록 콘텐츠를 만드는 것은 정보 문제를 해결하지만, 아직 누구도 명확한 답을 내놓지 못한 수익화 문제 (monetization problem)를 더욱 날카롭게 부각시킵니다.

두 번째는 책임 (liability) 문제입니다. 만약 어시스턴트가 귀하의 데이터를 잘못 읽는다면 — 귀하가 신중하게 구조화하고 올바르게 공개한 데이터일지라도 — 그리고 사용자에게 잘못된 정보를 전달한다면, 그 책임은 누구에게 있을까요? 데이터를 게시한 사이트인가요, 그것을 해석한 어시스턴트인가요, 아니면 어시스턴트 뒤에 있는 벤더 (vendor)인가요? 법적으로나 실무적으로나 아직 확립된 답은 없습니다.

저는 여기서 이 문제들을 해결하지 않을 것이며, 이를 해결할 수 있다고 주장하는 사람이 있다면 의심스러울 것입니다. 하지만 주목해야 할 점은, 이 문제들이 챗봇 (chatbot)을 구원해주지 않는다는 사실입니다. 오래된 스냅샷 (stale snapshot)을 바탕으로 답변하는 봇은 더 나쁜 정보를 가지고 동일한 노출 문제 (exposure problems)를 겪을 뿐입니다. 어려운 질문들은 실재합니다. 다만 그것들은 잘못된 방향이 아닌, 올바른 방향에서 마주하게 될 어려운 질문들일 뿐입니다.

시사점 (The takeaway)

만약 귀하가 웹사이트를 책임지고 있고 AI에 대해 고민하고 있다면, 본능적으로 챗봇을 추가하고 싶을 것입니다. 저는 그 본능에 반대합니다.

귀하의 페이지에 갇혀서 귀하의 콘텐츠를 오래된 복사본으로 답변하는 봇은, 사용자들이 겪고 있지 않은 문제를 해결하고 있는 것입니다. 사용자들이 실제로 겪고 있는 문제는 그들이 '이미' 대화하고 있는 어시스턴트가 아직 귀하의 사이트를 명확하게 읽을 수 없다는 점입니다.

따라서 질문은 "어떤 챗봇을 설치해야 할까?"가 아닙니다. "사람들이 이미 사용하고 있는 에이전트들이 내 콘텐츠를 읽을 수 있는가?"가 되어야 합니다.

페이지 구석에 박혀 있는 챗봇을 위해 최적화하는 것을 멈추십시오. 사람들이 직접 가지고 다니는 에이전트들이 읽을 수 있도록 콘텐츠를 만드는 일을 시작하십시오.