▲

럭셔리 자동차 정비소를 위한 AI 리셉셔니스트 구축기 - Part 1

 (itsthatlady.dev)
1P by GN⁺ 12시간전 | ★ favorite | 댓글 1개
  • 고급 정비소의 전화 응답 부재로 인한 매출 손실을 해결하기 위해, 실제 전화를 받는 AI 리셉셔니스트 ‘Axle’ 을 개발
  • AI는 Retrieval-Augmented Generation(RAG) 기반으로 구축되어, 웹사이트에서 수집한 실제 서비스·가격 정보를 근거로 정확한 답변을 제공
  • Vapi, Deepgram, ElevenLabs, FastAPI, MongoDB Atlas 등을 연동해 전화 연결, 음성 인식·합성, 대화 기록 저장 기능을 구현
  • 음성 품질은 자연스러운 톤과 짧은 문장 구조로 조정되어, 고객에게 친근하면서도 전문적인 응답을 제공
  • 향후 예약 시스템·SMS 알림·콜백 대시보드로 확장 예정이며, 비즈니스 특화 음성 에이전트는 지식 기반과 에스컬레이션 설계가 핵심임

AI 리셉셔니스트 구축 과정

  • 고급 자동차 정비소를 운영하는 오빠가 전화 응답 부재로 매달 수천 달러의 손실을 겪는 문제를 해결하기 위해 맞춤형 AI 리셉셔니스트 ‘Axle’ 을 구축
  • 단순 챗봇이 아닌, 실제 전화를 받을 수 있는 음성 기반 에이전트로 설계되어, 가격·운영시간·정책 등 실제 정보를 기반으로 고객 문의에 응답
  • 프로젝트는 세 단계로 구성: 지식 기반 구축(RAG 파이프라인) → 전화 연결 및 서버 연동 → 음성 품질 및 대화 톤 조정

Step 1: 두뇌 구축 (RAG 파이프라인)

  • Retrieval-Augmented Generation (RAG) 방식을 사용해 AI가 실제 데이터에 기반해 응답하도록 설계
    • 단순 LLM 사용 시 잘못된 가격 제시 등 환각(hallucination) 위험이 있어, 실제 정보만을 근거로 답변하도록 제한
  • 웹사이트 데이터 스크래핑을 통해 21개 이상의 문서를 수집, 서비스 종류·가격·소요 시간·운영시간·결제 방식·보증·대차 정책 등을 포함
  • MongoDB Atlas에 지식 베이스를 저장하고, Voyage AI (voyage-3-large) 모델로 1024차원 벡터 임베딩 생성
    • Atlas Vector Search 인덱스를 통해 의미 기반 검색 수행
  • 고객 질문이 들어오면 동일한 임베딩 모델로 쿼리를 변환해 의미적으로 유사한 상위 3개 문서를 검색
  • Anthropic Claude (claude-sonnet-4-6) 모델을 사용해 검색된 문서를 맥락으로 응답 생성
    • 시스템 프롬프트에 “지식 베이스 외 정보 금지, 간결하고 대화체 유지, 모르면 콜백 제안” 규칙 포함
  • 결과적으로 터미널에서 “오일 교체 비용은?” 같은 질문에 실제 가격과 서비스 내용을 정확히 응답 가능

Step 2: 실제 전화번호 연결

  • AI 두뇌를 실제 전화 시스템에 연결하기 위해 Vapi 플랫폼 사용
    • 전화번호 구매, Deepgram 기반 음성 인식, ElevenLabs 기반 음성 합성, 실시간 함수 호출 기능 제공
  • FastAPI 웹훅 서버 구축
    • Vapi가 고객 질문을 tool-calls 요청으로 /webhook 엔드포인트에 전달
    • 서버는 이를 RAG 파이프라인으로 전달해 Claude 응답을 받아 다시 Vapi로 전송
    • 자연스러운 대화 속도를 유지하기 위해 지연 최소화 필요
  • Ngrok을 이용해 로컬 서버를 외부 HTTPS URL로 노출, 개발 중에도 실시간 테스트 가능

  • Vapi 어시스턴트 설정

    • 인사말, 두 가지 도구(answerQuestion, saveCallback)를 웹훅에 연결
    • 질문에 답하거나, 모를 경우 이름과 전화번호를 받아 콜백 저장
    • 대화 메모리 기능으로 이전 대화 맥락 유지
    • “운영시간이 어떻게 되나요?” → “그럼 타이어 교체는 얼마인가요?” 같은 연속 질의 처리 가능

  • MongoDB에 통화 로그 저장

    • 발신번호, 질문, 응답, 인간 상담 전환 여부, 타임스탬프 기록
    • 콜백 요청은 별도 callbacks 컬렉션에 저장해 후속 연락 가능
    • 이를 통해 고객 문의 패턴과 콜량 분석 가능

Step 3: 음성 품질 조정

  • 텍스트 응답과 음성 응답의 차이를 고려해 음성 전달 최적화 필요
    • 글로는 자연스러운 문장도 음성으로 들으면 부자연스러울 수 있음

  • ElevenLabs 음성 선택

    • 약 20개의 음성을 테스트한 결과, ‘Christopher’ 음성이 가장 자연스럽고 정비소 분위기에 적합
    • 지나치게 로봇 같거나 과도하게 밝은 음성은 부적합

  • 시스템 프롬프트 수정

    • 짧은 문장, 마크다운 제거, “좋은 질문이에요!” 같은 불필요한 문구 삭제
    • 가격은 자연어로 발음 (“forty-five dollars”)
    • 응답은 2~4문장 이내로 제한
    • 목표는 친근하고 전문적인 인간 음성 구현

  • 에스컬레이션(콜백) 흐름 테스트

    • 지식 베이스에 없는 질문 시, AI가 모른다고 말하고 이름·번호 요청 후 MongoDB에 저장
    • 정비소 주인이 직접 후속 연락 가능

  • 통합 테스트 작성

    • RAG 파이프라인, 웹훅 처리, 전체 플로우 검증
    • 잘못된 요청, 검색 결과 없음, 콜백 번호 누락 등 엣지 케이스 처리 포함

기술 스택 구성

  • Vapi (Deepgram & ElevenLabs 통합) — 전화번호, 음성 인식, 음성 합성, 함수 호출
  • Ngrok — 로컬 개발용 HTTPS 터널
  • FastAPI + Uvicorn — 웹훅 서버
  • MongoDB Atlas — 지식 베이스, 벡터 검색, 통화 로그, 콜백 큐
  • Voyage AI (voyage-3-large) — 의미 기반 텍스트 임베딩
  • Anthropic Claude (claude-sonnet-4-6) — 지식 기반 응답 생성
  • Python — pymongo, voyageai, anthropic, fastapi로 구성
  • Copilot CLI — 빌드 자동화 도구

다음 단계

  • 현재 AI는 질문 응답과 콜백 수집 기능까지 완성
  • 다음 목표는 캘린더 연동을 통한 실시간 예약, SMS 알림, 콜백 관리 대시보드, 보안 강화, Railway 배포
  • 완성 시 24시간 운영 가능하며, 전화 응답 누락으로 인한 매출 손실 방지
  • 가장 어려웠던 부분은 코드가 아니라 정비소에 어울리는 음성 톤 구현
  • 핵심 교훈: 비즈니스 특화 음성 에이전트에는 원시 LLM을 그대로 사용하지 말 것
    • 실제 지식 베이스에 기반하고, 모를 때의 대응 흐름(에스컬레이션) 을 반드시 설계해야 함
    • 이는 예외가 아닌 핵심 기능임
▲
GN⁺ 12시간전  [-]
Hacker News 의견들

  • 예전에 서비스 어드바이저(접수 담당) 로 일했음. 기사에서 말하는 시스템은 현실적으로 작동하지 않을 것 같음

    1. 동일한 수리 이력이 없으면 견적이 틀릴 확률이 높음. 일부 주에서는 잘못된 견적이 법적으로 문제될 수 있음
    2. 부품 재고와 가격은 시시각각 변함. 시스템이 이를 반영하지 못하면 혼란만 초래함
    3. 새로운 작업은 부품 선정부터 복잡함. 고급 차량일수록 더 까다로움
    4. 유용한 부분은 차량 픽업 알림 정도뿐임. 완료 시점이나 진행 상황을 자동으로 알려주는 용도
      이런 개발은 단순한 오만을 넘어 위험함. 검증 없이 가정만으로 만들면 타인의 생계를 위태롭게 함
    • 나도 전문가가 아니지만, 이런 허세에는 공감함. 리셉셔니스트가 필요하다면 사람을 고용하는 게 자연스러움. 검증되지 않은 AI 솔루션에 사업을 맡기는 건 이해하기 어려움. 단순히 관리하기 싫어서인지, 유행을 좇는 건지 모르겠음
    • 사실 더 간단한 해결책이 있음. 차 밑에서 일하는 사람이 핸즈프리 스피커폰으로 전화를 받을 수 있게 하면 됨. 로컬 음성 인식 모델을 쓰면 신경망 기술도 언급할 수 있고, 비용도 마이크 포함해 200~300달러면 충분함
    • 하지만 원문을 보면, 이 정비소는 이미 고정된 서비스와 가격표를 가지고 있음. 그래서 맞춤 견적이 필요한 경우가 아니라면 위의 문제들은 해당되지 않음
    • “위험하다”는 평가는 과한 듯함. 개발자는 오빠의 사업을 돕는 중이고, 완벽하지 않아도 고객 전환율이 10%만 올라가도 충분히 가치 있음
    • 차량 완료 알림이나 진행 업데이트는 이미 TTS 시스템으로 수년 전부터 가능했음. 굳이 LLM이 필요하지 않음

  • 우리 지역 Subaru 딜러십은 전화 예약 시 AI 어시스턴트를 선택할 수 있음. 써보니 사람보다 정확하고 빠르게 작동했음. Taco Bell의 AI 주문도 마찬가지로 훌륭했음. 이런 경우엔 사람과 대화하지 않아도 손해가 없고, 필요하면 언제든 사람 연결도 가능함

  • 이런 블로그 글은 절반의 이야기일 뿐임. 실제로 매출이 늘었는지, 고객이 봇인지 신경 썼는지, 실패 사례가 있었는지 궁금함

    • 사실 이런 문제는 AI 이전에도 가상 비서 서비스로 해결 가능했음. 월 200~1000달러면 충분하고, 이미 잃고 있던 매출을 다시 회수하는 셈임. AI는 단지 더 복잡한 쥐덫일 뿐이고, 고급 서비스라면 인간 응대가 훨씬 신뢰감 있음
    • 아마 아직 실전 테스트가 충분히 이뤄지지 않았을 것 같음. 이메일 주소 같은 건 LLM이 정확히 받아적기 어려움. 실시간 음성 응답에서는 Anthropic이 느렸고, Groq은 200ms 이하로 매우 빠름
    • 예전에 급히 자동차 유리 교체를 해야 했는데, 자동 음성 시스템이 불필요한 정보를 계속 요구해서 끊었음. 단순 예약이라면 괜찮겠지만, 특수 상황에서는 결국 사람과 이야기해야 함
    • 이런 시도는 합리적임. 다만 실제 성능은 아직 미지수임. AI 낙관론자와 비관론자를 가르는 리트머스 시험지 같음

  • 나는 요즘 LLM 기반 전화 비서를 꽤 긍정적으로 봄. Mint Mobile 고객센터에 전화했을 때, LLM이 자연스럽게 이해하고 1분 만에 문제를 해결해줬음. 예전엔 20분 이상 대기했을 일임

    • LLM은 발음이 명확하고, 헤드셋 잡음도 없고, 이해하기 쉬움. 물론 eBay의 LLM 챗봇처럼 엉망인 경우도 있지만, 잘 구현된 시스템은 훌륭하게 작동함
    • Amazon의 채팅 지원도 비슷함. LLM이 주문 정보를 미리 정리하고, 사람은 마지막 승인만 함. 효율적임
    • 다만, 왜 앱에서 해결하지 못해 LLM을 써야 하는지는 의문임. 결국 개발 프로세스의 실패처럼 보임
    • 나도 비슷한 경험이 있음. 기술적인 질문을 했더니 LLM이 정확히 답했고, 이후 인간 상담원이 이어받았지만 오히려 덜 전문적이었음. 그래도 시간은 절약됨
    • 예전 로봇보다 훨씬 낫고, RAG 기반 챗봇은 문서 검색을 대체할 만큼 유용함. 예를 들어 manager.io의 챗봇은 문서 대신 바로 답을 줘서 편리했음

  • 글에 따르면, 정비소는 전화를 받지 못해 매달 수천 달러 손실을 보고 있음. 그렇다면 월 500달러 정도의 외주 리셉셔니스트를 두는 게 훨씬 높은 ROI임

    • 사실 음성사서함만으로도 일부 문제는 해결 가능함. AI든 사서함이든, 일부 고객은 어차피 끊을 것임
    • 게다가 이미 일이 너무 많아 전화를 못 받는다면, 추가 고객을 받아도 처리할 여력이 없을 가능성이 큼
    • 내 친구는 외주 리셉션 서비스를 쓰는데, 월 150파운드로 9시~5시까지 커버함. 본인은 저녁에 일정만 조정함. 만약 글의 내용이 사실이라면, 이미 정비소는 100% 용량으로 일하고 있을 것임
    • 좋은 서비스 라이터는 비싸지만 그만한 가치가 있음. 고객 신뢰도 높고, 나중엔 사업을 인수할 가능성도 있음
    • 결국 ROI는 블로그가 홍보하려는 AI 교육 과정의 광고 효과일 뿐임

  • 요즘은 로봇 응대라고 느껴지면 바로 끊는 편임. 하지만 곧은 AI 음성이 사람과 구분되지 않을 수준이 될 것 같음. 그때는 전화에 대한 신뢰가 무너질지도 모름. 이미 이메일과 LinkedIn은 AI 스팸으로 넘쳐서, 전화로 전환했는데 그것도 곧 사라질 듯함

    • 그래도 음성사서함으로 넘어가면 똑같이 끊을 테니 손해는 없음
    • AI가 내 말을 오해하고 결국 사람에게 연결되면, 같은 이야기를 두 번 해야 해서 피곤함
    • 최근 자동차를 알아보면서 여러 딜러와 연락했는데, 나중에야 모두 LLM 기반 가짜 이름 상담원이었다는 걸 깨달았음. 응답 속도가 너무 빨라서 이상했음

  • “이건 범용 챗봇이 아니다”라고 했지만, 사실상 2026년형 범용 챗봇에 불과함

  • 블로그의 “About” 페이지를 보니, 작성자가 코딩을 배워 부자가 됐다는 인플루언서에게서 영감을 받았다고 함. 하지만 이런 태도는 내가 바라는 엔지니어링 문화의 방향과는 거리가 있음

  • 사람들이 AI로 개인 블로그를 쓰는 것이 조금 우울하게 느껴짐

    • 그래도 솔직히 밝힌 점은 좋게 봄. 대부분은 글쓰기 경험이 부족하고, LLM을 통해 “잘 쓴 글”을 얻는다고 생각함. 그들에게는 인공지능이 쓴 글이 나쁘다고 느껴지지 않을 수도 있음

  • 여기서 RAG가 꼭 필요할까? 단순히 가격표와 영업시간 정도면 컨텍스트 윈도우에 다 들어감

    • 아마 학습 목적의 프로젝트였을 것임. 나도 개인 프로젝트에서 과도한 아키텍처를 써보며 배우는 경우가 있음
    • 음성 대화에서는 지연 시간(latency) 이 더 큰 문제임. 사이트에 여러 페이지가 있다면 RAG로 빠르게 일부만 불러오고 LLM이 세부 답변을 만드는 게 효율적일 수 있음
    • 그냥 웹사이트와 가격표 전체를 컨텍스트에 넣는 게 더 간단함
    • 나도 동의함. 이 정도 정보는 충분히 한 번에 처리 가능함
    • 전체적으로 이 아키텍처는 과도함
답변달기