5분 이내에 부동산 잠재 고객에게 전화하는 AI 음성 에이전트를 구축했습니다. 그 방법을 소개합니다.

리드 대응 속도(Speed to lead)는 실제로 대규모로 해결하려고 시도하기 전까지는 단순하게 들리는 문제 중 하나입니다.

구매자가 부동산 양식을 작성합니다. 업계 데이터에 따르면 첫 5분이 지난 후 연락 성공률(contact rate)은 400% 급감합니다. 대부분의 영업 팀은 한 시간이나 지나서 리드에게 전화를 겁니다. 그때쯤이면 구매자는 이미 다른 곳으로 떠난 상태입니다.

명백한 답은 더 빨리 전화하는 것입니다. 하지만 진짜 답은 대량의 리드를 대상으로 이를 수동으로 수행할 수는 없다는 것입니다. 시스템이 필요합니다.

우리는 시스템을 구축했습니다. 이 포스트에서는 아키텍처(architecture), 그 뒤에 숨겨진 결정들, 그리고 우리가 배운 점들을 다룹니다.

문제를 쉽게 설명하자면

클라이언트는 부동산 리드 생성(lead generation) 기업이었습니다. 그들은 Meta, Google, TikTok 광고를 통해 구매 리드를 생성하고, 이 리드들을 부동산 중개인들에게 판매합니다.

세 가지 문제가 계속해서 발생했습니다.

중개인들이 리드에게 충분히 빠르게 전화하지 않았습니다. 어떤 이들은 아예 전화를 하지 않기도 했습니다. 그리고 중개인들이 리드와 연락이 닿지 않는다고 보고할 때, 그들이 실제로 시도를 했는지 확인할 방법이 없었습니다.

리드 생성 → CRM → 중개인 배정 → 중개인 전화 (아마도, 언젠가)
                                               ↓
                                    리드는 이미 식어버림 (went cold)

해결책은 "리드가 CRM에 진입하는 시점"과 "중개인이 개입하는 시점" 사이에서 이루어져야 했습니다. 그 시간적 간극(window)은 자동화되어야 했습니다.

우리가 구축한 것

새로운 리드가 CRM에 도달하는 즉시 실행되는 AI 음성 및 SMS 자격 확인(qualification) 시스템입니다.

리드가 CRM(GoHighLevel)에 진입
        ↓
자동화 트리거 (Make.com)
...

서류상으로는 단순한 흐름입니다. 각 계층(layer)에서 파헤쳐 볼 만한 몇 가지 사항들이 있습니다.

기술 스택 (Tech Stack)

계층 (Layer)	도구 (Tool)	역할 (Role)
CRM	GoHighLevel	리드 저장, 파이프라인, 트리거
...

특별한 스택은 아닙니다. 흥미로운 작업은 프롬프트 엔지니어링 (prompt engineering), 자격 확인 로직 (qualification logic), 그리고 CRM 상태 관리 (state management)에 있었습니다.

트리거 계층 (The Trigger Layer)

트리거 계층 (The Trigger Layer)

GoHighLevel이 CRM 측면을 처리합니다. 새로운 잠재 고객(lead)이 특정 파이프라인 단계에 도달하면, Make.com으로 웹훅(webhook)을 발생시킵니다.

Make.com은 오케스트레이션 계층(orchestration layer) 역할을 합니다. 이 플랫폼은 웹훅을 수신하고, 잠재 고객 데이터를 추출한 다음, 적절한 컨텍스트를 첨부하여 VAPI 호출을 실행합니다.

{
  "lead_id": "12345",
  "name": "Rahul",
...

이 컨텍스트는 통화 설정의 일부로 AI 음성 에이전트에게 전달됩니다. 에이전트는 자신이 누구에게 전화하는지, 그리고 대화가 시작되기 전에 어떤 정보가 이미 수집되었는지 알고 있습니다.

음성 에이전트 설계 (The Voice Agent Design)

에이전트의 이름은 Sarah입니다. 이 통화는 단 하나의 목표를 가집니다: 3분 이내에 잠재 고객을 자격 검증(qualify)하는 것입니다.

통화에서 확인하는 세 가지 사항:

1. 구매자가 여전히 구매에 관심이 있는지?
2. 다른 에이전트와 구매자 대리점 계약서(buyer representation agreement)를 체결했는지?
3. 파트너 에이전트와의 후속 통화를 위해 언제 시간이 되는지?

그게 전부입니다. 홍보성 발언(pitch)도 없고, 부동산 상세 정보도 없고, 길게 읽는 자격 검증 양식도 없습니다.

자격 검증 로직은 결정론적(deterministic)입니다:

IF still_buying == true AND no_existing_agent == true
  → QUALIFIED로 표시
  → 시간 가능 여부 수집
...

로직을 단순하게 유지한 것은 의도적인 선택이었습니다. 조건을 많이 추가할수록 대화 흐름에서 더 많은 엣지 케이스(edge cases)를 만듭니다. 3분 이내라는 것은 에이전트가 진입하여 답변을 얻고, 깔끔하게 빠져나와야 한다는 의미입니다.

프롬프트 엔지니어링 노트 (Prompt Engineering Notes)

통화 품질에 실제로 큰 차이를 만든 몇 가지 사항들.

페르소나 일관성(Persona consistency). Sarah는 매번 자신을 같은 방식으로 소개합니다. 이름, 회사, 전화하는 이유. 변동이 없습니다. 전화를 받는 구매자들은 자신이 누구와 통화하고 있는지, 그리고 그 이유가 무엇인지 즉시 알게 됩니다.

짧은 질문. AI는 한 번에 하나의 것만 묻습니다.

거절 상황의 자연스러운 처리 (Natural handling of objections). 구매자는 때때로 "제 번호를 어떻게 아셨죠?" 또는 "이미 다른 사람과 통화했습니다"와 같은 말을 할 수 있습니다. 프롬프트(Prompt)에는 일반적인 응답에 대한 처리 로직이 포함되어 있어, 예상치 못한 상황이 발생하더라도 대화가 끊기지 않습니다.

강제 종료 조건 (Hard stop conditions). 만약 구매자가 연락하지 말라고 말하면, 에이전트는 즉시 통화를 종료하고, 결과를 기록하며, 해당 잠재 고객(Lead)을 DNC(Do Not Contact, 연락 금지)로 표시합니다. 재시도 없음. SMS 발송 없음. 즉시 중단됩니다.

SMS 폴백 (The SMS Fallback)

전화를 받지 않을 경우, Make.com이 몇 분 이내에 SMS를 트리거합니다.

"안녕하세요 [Name]님, Home Front Connect의 Sarah입니다. 
최근 주택 구매에 관한 정보를 요청하셨습니다. 
저희 파트너 에이전트가 언제쯤 연락드리면 좋을까요?"

짧고, 직접적이며, 판매 목적이 강해 보이지 않습니다. 목표는 무언가를 성사시키는 것이 아니라, 응답을 받아내는 것입니다.

구매자가 답장을 보내면, 그 응답은 다시 GoHighLevel로 전달되어 배정된 에이전트에게 알림을 트리거합니다. 에이전트는 통화 시도와 SMS 교환 내용 모두에서 얻은 문맥(Context)을 바탕으로 후속 조치를 취합니다.

CRM 상태 관리 (CRM State Management)

모든 결과는 GoHighLevel의 특정 파이프라인 단계(Pipeline stage)에 매핑됩니다.

Qualified (적격)           → "Qualified Leads" 파이프라인으로 이동
Not Interested (관심 없음)      → "Closed - Not Interested"로 이동
Has Existing Agent (기존 에이전트 있음)  → "Closed - Has Agent"로 이동
...

이는 두 가지 이유로 중요합니다. 첫째, 에이전트는 적격(Qualified) 파이프라인에 있는 잠재 고객만 확인합니다. 결과값을 수동으로 분류할 필요가 없습니다. 둘째, 누군가 수동으로 업데이트할 필요 없이 모든 연락 시도의 전체 이력이 잠재 고객 기록에 표시됩니다.

책임 소재(Accountability) 문제가 해결되었습니다. 모든 통화 시도에는 타임스탬프(Timestamp), 결과, 그리고 녹음 파일이 남습니다.

2단계(Phase 2)의 모습

1단계는 첫 연락과 자격 확인(Qualification)을 처리합니다. 2단계는 실시간 연결(Live transfer) 기능을 추가합니다.

구매자가 전화를 받아 자격이 확인되면, 단순히 콜백(Callback) 시간을 예약하는 대신, AI가 실시간으로 배정된 에이전트에게 전화를 직접 연결할 수 있습니다.

구매자 응답 → AI 자격 확인 → 에이전트에게 실시간 연결
↓
에이전트가 웜 트랜스퍼 (Warm Transfer) 수신
...

이를 위해서는 에이전트 라우팅 (Agent Routing) 로직이 필요합니다. 각 리드 (Lead)는 Make.com의 CRM 태그와 조건부 로직 (Conditional Logic)을 기반으로 특정 에이전트에게 매핑됩니다. 만약 정의된 시간 내에 에이전트가 전화를 받지 않으면, 통화는 음성 사서함(Voicemail)이나 대체 에이전트로 폴백 (Fallback) 됩니다.

전송 시도, 에이전트의 응답, 그리고 통화 녹음은 모두 로그 (Log)로 기록됩니다. 만약 에이전트가 나중에 리드와 연락이 닿지 않았다고 주장하더라도, 전송 로그를 통해 정확히 어떤 일이 일어났는지 확인할 수 있습니다.

초기에 실수했던 점들

SMS 발송 타이밍은 처음에 생각했던 것보다 더 많은 고민이 필요했습니다.

우리의 첫 번째 버전은 부재중 전화가 발생한 직후 거의 즉시 SMS를 보냈습니다. 일부 구매자들은 이것이 너무 빠르다고 느꼈습니다. 도움이 되는 후속 조치라기보다는 몰아붙이는 느낌을 주었습니다.

우리는 부재중 전화 발생 후 SMS가 발송되기 전까지 짧은 지연 시간을 두도록 조정했습니다. 작은 변화였지만, 응답률이 눈에 띄게 좋아졌습니다.

우리가 과소평가했던 또 다른 점은 대화 흐름에서의 예외 케이스 (Edge Cases)였습니다. 구매자들은 예상치 못한 말들을 합니다. "동생 대신 작성했어요.", "이미 현장을 방문했습니다.", "개발사에서 전화하신 건가요?"와 같은 말들입니다. 이러한 상황들은 각각 처리가 필요하며, 그렇지 않으면 대화가 어색하게 중단됩니다. 우리는 가장 흔한 예외 상황들을 커버하기 위해 예상보다 더 많이 프롬프트 (Prompt)를 반복 수정했습니다.

간직할 만한 교훈들

통화는 짧고 집중력 있게 유지하세요. 너무 많은 질문을 던지고 싶은 욕구를 참는다면 3분 이내의 통화는 충분히 가능합니다. 의도를 확인(Qualify)하고, 가능 시간을 파악한 뒤, 인계(Hand off)하세요.

결정론적 자격 확인 로직 (Deterministic Qualification Logic)이 모호한 AI 판단보다 낫습니다. AI는 대화를 이해해야 하지만, 자격 확인 결정은 명확한 규칙을 따라야 합니다. 이 두 가지를 혼합하면 일관성이 깨집니다.

CRM 상태 (State)가 전부입니다. 모든 통화의 결과가 CRM으로 깔끔하게 다시 흘러 들어가지 않는다면, 시스템은 빠르게 붕괴됩니다. CRM 업데이트 단계는 통화 자체만큼이나 중요합니다.

초기에 실제 전화번호로 테스트하세요. 음성 품질 (Voice quality), 통화 수락률 (Call pickup rates), 그리고 대화 흐름 (Conversation flow)은 테스트 환경과 실제 운영 (Production) 환경에서 모두 다르게 작동합니다. 개발 초기 단계에서 가능한 한 빨리 실제 통화가 이루어지도록 하세요.

SMS 문구는 예상보다 더 중요합니다. SMS 폴백 (SMS fallback)은 구매자가 귀하로부터 읽게 되는 첫 번째 메시지인 경우가 많습니다. 짧고, 인간적이며, 부담을 주지 않는 방식으로 작성하세요.

맺음말

이 시스템을 구축하는 것은 기술적으로 복잡하지 않았습니다. 기술 스택 (Stack)은 관례적이며, 통합 지점 (Integration points)은 문서화가 잘 되어 있고, 통화 로직 (Call logic)은 설계상 단순합니다.

이 시스템을 구축할 가치가 있었던 이유는 문제의 명확성 때문입니다. 잠재 고객 (Lead)은 생성되는 순간 가장 가치가 높습니다. 지연되는 매 분마다 그 가치는 감소합니다. 그 간극을 자동으로, 일관되게, 어떤 시간대나 어떤 규모에서도 메워주는 시스템은 실제적인 문제를 해결합니다.

이를 위한 기술은 이미 한동안 사용 가능했습니다. 대부분의 부동산 기업들은 단지 아직 이를 구축하지 않았을 뿐입니다.

Built by the team at CIZO. We build AI systems, mobile apps, and IoT solutions. Say hi: hello@cizotech.com