Maya 구축하기: 부동산 리드 캡처 (Lead Capture)를 위한 AI 어시스턴트

부동산 중개업소가 리드 (Leads)를 놓치는 이유는 매물이 좋지 않아서인 경우가 드뭅니다. 그 이유는 누군가가 밤 11시에 매물에 대해 문의 메시지를 보냈는데, 중개인이 다음 날 아침에 답장을 보낼 때쯤이면 그 사람은 이미 다른 세 곳의 중개업소로 넘어가 버렸기 때문입니다. UPSERA에서의 프리랜서 업무의 일환으로, 저는 가벼운 AI 어시스턴트가 그 간극을 메울 수 있을지 확인하고 싶었고, 그렇게 Maya가 탄생했습니다.

제가 해결하고자 했던 문제

대부분의 중소규모 부동산 중개업소는 24시간 내내 문의를 모니터링할 인력이 없습니다. 또한 채팅 자동화 기능이 내장된 엔터프라이즈 CRM을 도입할 예산도 없습니다. 그들에게 필요했던 것은 더 단순한 것이었습니다. 웹사이트에 상주하며 기본적인 매물 질문에 즉각 답변하고, 무엇보다 중요한 것은 영업시간 외에도 누군가 관심을 보이는 즉시 리드 (Lead) 상세 정보를 캡처할 수 있는 챗봇이었습니다.

Next.js와 Groq의 LLaMA를 선택한 이유

저는 Maya를 Next.js로 구축했습니다. 부분적으로는 별도의 서버를 구축하지 않고도 프론트엔드(Frontend) 채팅 위젯과 백엔드(Backend) API 라우트를 하나의 코드베이스에서 배포할 수 있었기 때문입니다. 언어 모델 (Language Model) 자체의 경우, 더 무거운 API 대신 Groq에서 호스팅하는 LLaMA 모델을 선택했습니다. Groq의 추론 속도 (Inference speed)는 제가 처음에 예상했던 것보다 더 중요하게 작용했습니다. 방문자가 챗봇이 "실제"인지 아니면 단순히 스크립트로 짜인 FAQ인지 테스트할 때, 응답 지연 시간 (Response latency)은 그들이 계속 타이핑을 할지 아니면 이탈할지를 결정하는 결정적인 요인이 되는 경우가 많기 때문입니다.

CRM 없이 리드 캡처하기

데모 단계의 제품을 위해 데이터베이스를 포함한 전체 백엔드 (backend)를 구축하는 대신, 저는 Maya의 리드 캡처 (lead capture) 기능을 Google Sheets에 직접 연결했습니다. 대화가 방문자가 연락처 정보를 공유하거나 특정 매물에 대해 문의하는 지점에 도달할 때마다, 해당 정보는 공유된 시트의 새로운 행으로 실시간 기록되었습니다. 소규모 에이전시의 경우, 이는 소유자가 새로운 대시보드 (dashboard)를 배우는 대신 이미 익숙한 스프레드시트를 열어볼 수 있음을 의미했습니다. 가장 "엔터프라이즈 (enterprise)"적인 솔루션은 아닐지라도, 이는 이러한 비즈니스들이 실제로 작동하는 방식과 일치했으며, 기술적인 우아함보다 그것이 더 중요했습니다.

예상치 못한 UI 지연 (lag) 해결하기

테스트 중에 발생한 문제 중 하나는 메시지가 전송된 직후 채팅 인터페이스가 느릿하게 느껴지는 것이었습니다. 타이핑 표시기 (typing indicator)가 나타나기 전까지 눈에 띄는 일시 정지가 있었습니다. 원인은 모델의 응답을 기다리는 동안 동기식 API 호출 (synchronous API call)이 UI 스레드 (UI thread)를 차단하고 있었기 때문으로 밝혀졌습니다. 저는 호출 방식을 백그라운드 요청 (background request)으로 실행되도록 재구성하여, 네트워크 왕복 시간 (network round trip)을 기다리는 대신 사용자가 메시지를 보내는 즉시 인터페이스를 낙관적으로 업데이트 (optimistically updating)하도록 했습니다. 실제 모델 지연 시간 (latency)은 전혀 변하지 않았음에도 불구하고, 그 작은 변화 덕분에 채팅이 눈에 띄게 더 반응성이 좋아졌습니다. 이는 체감 성능 (perceived performance)과 실제 성능 (actual performance)이 서로 다른 문제라는 점을 상기시켜 주는 좋은 사례였습니다.

외부 트리거를 위한 커스텀 이벤트

대행사들은 종종 자신의 사이트 내 다른 곳에 배치된 버튼(예: 매물 페이지의 "Maya와 대화하기" 버튼)을 통해 챗봇을 여는 방법을 원했습니다. 이때 해당 버튼이 채팅 위젯의 내부 상태(internal state)에 대해 아무것도 알 필요가 없어야 했습니다. 저는 이를 window 객체에 발송되는 커스텀 브라우저 이벤트인 open-maya를 통해 해결했습니다. 페이지 어디에 있는 버튼이든 이 이벤트를 발생시킬 수 있었고, 독립적으로 리스닝(listening)하고 있던 채팅 위젯은 이에 반응하여 열렸습니다. 이를 통해 두 UI 요소는 완전히 디커플링(decoupled, 결합 해제)된 상태를 유지할 수 있었습니다. 즉, 매물 페이지는 프롭(prop), 공유 상태 관리자(shared state manager), 또는 챗봇이 컴포넌트로서 존재한다는 사실조차 알 필요가 없었으며, 단지 이벤트 이름만 알면 되었습니다.

이 과정에서 배운 점

Maya를 단순한 과제 프로젝트가 아닌 프리랜서로서 구축한 경험은 트레이드오프(trade-offs, 절충안)에 접근하는 방식을 바꾸어 놓았습니다. 대학 과제는 "정답"인 아키텍처(architecture)에 보상을 주지만, 클라이언트 데모는 실제 대행사가