Canonical note: this is a technical companion to Sabbaq. No credentials, keys or internal endpoints are included.
Sabbaq은 두바이 부동산 중개업소를 위한 WhatsApp 우선 리드 데스크입니다. 제품의 약속은 간단합니다:
모든 Property Finder 및 Bayut 리드를 기존 WhatsApp 번호에서 아랍어 또는 영어로 몇 초 만에 답변해 드립니다. 중앙값 5분 미만, 그렇지 않으면 월 사용료를 돌려드립니다.
답변 시간에 돈을 거는 것은 흥미로운 엔지니어링 결정을 강요합니다. 이 글에서는 높은 수준에서 아키텍처(ingestion, 대화 엔진, 가드레일, 인간 핸드오프, 테넌시, 메트릭)를 설명합니다.
제약 사항 (The constraints)
- 채널: 고객 자신의 WhatsApp Business 계정에서 사용하는 WhatsApp Business Platform (Cloud API).
- 언어: 영어와 걸프 아랍어이며, 종종 하나의 채팅에 혼합되어 있습니다.
- 지연 시간 (Latency): 첫 답변은 몇 초 이내여야 하며, 비즈니스 지표는 리드 도착 시점부터의 '중앙값' 첫 답변까지의 시간이 핵심입니다.
- 안전성 (Safety): 어시스턴트는 절대로 가격을 추측하거나 법적 또는 모기지 조언을 제공하거나 협상해서는 안 됩니다.
- 다중 테넌트 (Multi-tenant): 많은 중개업소가 사용하며, 데이터가 엄격하게 분리되어야 합니다.
- 포털 API 없음: 포털 API에서 데이터를 가져오지 않습니다. 리드는 중개업소가 이미 통제하는 채널을 통해 들어옵니다.
1. 수집 (Ingestion): 두 가지 리드 소스
WhatsApp Cloud API webhook ──┐
├──► Lead normaliser ──► Conversation engine
Inbound lead email (parsed) ─┘
WhatsApp. 연결된 번호로 들어오는 모든 인바운드 메시지는 리드가 되거나(또는 업데이트됩니다). 웹훅 핸들러는 Meta 시그니처를 검증하고, 메시지 ID(Meta 재시도)를 기반으로 중복을 제거하며, 원본 이벤트를 영속화하고 작업을 큐에 넣은 후 빠르게 200을 반환합니다. 웹훅 핸들러는 가볍게 유지하고, 느린 작업은 비동기적으로 처리해야 합니다.
솔직한 한계점: 일반 WhatsApp 메시지로는 해당 리드가 어느 포털에서 왔는지 알 수 없습니다.
이메일(Email). 포털 사이트들은 리드 알림 이메일을 보냅니다. 각 워크스페이스는 고유한 수신 주소를 가지며, 중개업소들은 Property Finder, Bayut 및 Dubizzle의 리드 이메일을 그곳으로 전달합니다. 포털별 파서(parser)가 이름, 전화번호, 매물 참조 번호 및 메시지를 추출하고, 해당 리드를 어떤 포털에서 왔는지 태그하며, Meta 승인 템플릿을 사용하여 WhatsApp 소개 메시지(24시간 창문 외부의 비즈니스 시작 메시지는 템플릿이 필요함)를 트리거합니다.
2. 대화 엔진 (The conversation engine)
들어오는 모든 메시지는 파이프라인을 거칩니다:
- 컨텍스트 로드(Load context): 워크스페이스 설정, 리드의 기록, 중개업소의 매물 및 지식 기반.
- 언어 감지(Language detection): 리드가 사용하는 언어로 답장합니다.
- 가드레일 사전 검사(Guardrail pre-check): 어떤 내용이든 생성하기 전에 인계 주제로 분류합니다 (§3 참조).
- 생성(Generate): 검색된 매물 및 지식에 근거한 LLM 호출을 수행합니다.
- 가드레일 사후 검사(Guardrail post-check): 초안을 출처 데이터와 비교하여 유효성을 검증합니다.
- 실행(Act): 실시간으로 전송하거나 섀도 모드에서 초안으로 저장합니다.
자격 심사는 의도적으로 한 번에 하나의 질문만 합니다: 구매 또는 임대, 예산, 지역, 침실 수, 시기, 현금 또는 모기지. 각 답변은 단순히 대화 기록에 남는 것이 아니라 구조화된 리드 필드에 작성되어 라우팅 및 보고서 작성이 이를 활용할 수 있게 합니다.
가장 첫 번째 메시지에서 이것이 AI 어시스턴트임을 공개합니다. 이는 제품 결정이자 Meta의 정책 하에서 좋은 관행입니다. 우리는 이것을 일반적인 목적의 봇이 아니라 중개업소 자체 리드를 위한 중개업소 고유의 어시스턴트로 포지셔닝합니다.
3. 가드레일: 모델이 제공하는 사실에 대해서는 아무것도 신뢰하지 마라 (Guardrails: trust nothing the model says about facts)
부동산에서 가장 큰 위험은 자신감 넘치지만 잘못된 정보입니다. 우리의 규칙은 다음과 같습니다:
- 사실 확인 (Grounding check). 초안에 있는 모든 사실(가격, 크기, 가용성)은 리스팅이나 지식 기반과 일치해야 합니다. 가격은 출처 대비 2%의 엄격한 허용 오차 범위 내에 있어야 합니다. 그렇지 않으면, 해당 초안은 "중개인에게 확인해 보겠습니다."로 대체됩니다.
- 고정 응답 핸드오프 (Fixed-reply handoffs). 다음 상황에 대해 영어와 걸프 아랍어(Gulf Arabic)로 고정된 답변이 준비되어 있습니다: 가격 협상 및 할인; 법률 주제(계약서, SPA, 등기권리증, POA); 모기지 자문; 명시적인 인간 요청("AGENT", «وكيل»); 방문 확인; 그리고 리드에게 전송하지 않도록 안내받은 신분증이나 카드 번호.
- 출력 필터 (Output filters). 금지된 문구와 조작된 링크는 차단됩니다.
- 경고 알림 (Alerts). 불만 사항, 사기성 문구, 그리고 매우 높은 예산은 관리자에게 통보합니다.
- 동의 (Consent). STOP / «إيقاف»과 START / «ابدأ»는 자동으로 처리되고 기록됩니다. 거부(opt-out) 후 또는 24시간 창 밖에서는 수동 전송이 차단됩니다.
배울 점: LLM을 초안 작성자처럼 취급하고, 양쪽에 결정론적 검사(deterministic checks)를 적용해야 합니다.
4. 첫 번째 등급 상태로서의 Shadow mode
모든 워크스페이스는 **섀도우 모드 (shadow mode)**로 시작합니다: 엔진은 처음부터 끝까지 실행되지만, 출력물은 중개인이 승인(인라인 편집 포함)하거나 폐기하는 초안 형태로 나타납니다. 이것이 우리가 내린 최고의 결정이었습니다:
- 소유자는 어떤 것이 전송되기 전에 실제 리드에 대한 실제 답변을 확인할 수 있습니다.
- 편집 내용은 지식 기반의 부족한 부분을 알려주는 신호가 됩니다.
- 이는 안전한 대체 방안입니다: 체험 기간이 끝나면 워크스페이스는 섀도우 모드로 돌아가고 데이터는 유지됩니다.
구현 관점에서 볼 때, "전송(send)"은 워크스페이스와 채팅마다 선택하는 전략입니다. 테이크오버/핸드백 토글(take-over/hand-back toggle)은 중개인이 개입할 때 단일 대화 동안 어시스턴트를 일시 정지시킵니다.
5. 핸드오프와 SLA 알람
대화가 인간의 도움이 필요할 경우, 지역, 언어 또는 리스팅별로 요약과 함께 라우팅됩니다. 핸드오프는 지연 시간 위험(latency risk)을 모델에서 사람으로 옮기므로 다음과 같은 이점이 있습니다:
- 인계된(handed-off) 리드는 받은 편지함에 카운트다운이 표시됩니다.
- 정해진 시간 내에 아무도 이를 인지하지 못하면(기본 5분), 관리자에게 WhatsApp 알림이 전송되고 해당 리드는 자동 재할당됩니다(지역, 언어 순으로, 이후 라운드 로빈 방식).
- 알림 피로를 방지하기 위해 미인지된 리드 건당 한 번만 경보가 발생합니다.
6. 멀티테넌시 (Multi-tenancy)
각 부동산 중개업소는 독립적인 작업 공간(workspace)입니다. 이 작업 공간은 서명된 세션으로 바인딩되며, 멤버십 여부는 모든 요청마다 재확인되고, 쿼리 계층은 작업 공간 범위가 없는 테넌트 테이블 쿼리를 거부합니다. 테스트를 통해 격리가 구현되었음을 확인할 수 있습니다. 요약하자면: 각 중개업소의 데이터는 작업 공간별로 논리적으로 분리되며 모든 요청에서 강제됩니다.
역할은 계층화되어 있습니다: 에이전트(Agent) (받은 편지함, 답장, 승인, 현장 방문 예약 확인), 관리자(Admin) (설정, 매물 정보, 지식 기반, 측정 지표 등 추가 기능), 그리고 소유주(Owner) (청구서, WhatsApp 연결 및 사용자 관리 등 추가 기능).
7. 통합 (Integrations)
'리드 자격 확인 완료(lead qualified)' 및 '현장 방문 예약 확정(viewing confirmed)'과 같은 이벤트 발생 시 아웃바운드 서명 웹훅(signed webhook) POST를 지원하여, 중개업소가 모든 CRM 시스템으로 데이터를 전송할 수 있습니다. 리드 및 동의서 CSV 내보내기 기능은 셀프 서비스로 제공됩니다.
8. 측정 지표: 약속을 측정하다 (Metrics: measuring the promise)
저희가 보장하는 핵심 측정 지표는 **리드가 도착했을 때부터 첫 답장이 오기까지의 중앙값 시간(median time to first reply)**입니다. 누가 답장을 하든 상관없습니다(어시스턴트 또는 에이전트). 평균보다 중앙값이 더 정확합니다: 한 가지 막힌 채팅으로 인해 빠른 응답들이 가려질 수 없으며, 반대로 아주 빠른 몇 번의 응답만으로는 좋지 않은 주간을 포장할 수 없습니다.
주간 보고서(일요일부터 월요일까지, 두바이 시간 기준)에는 리드 건수, 업무 외 시간대 리드, 답장 완료 건수, 중앙값 첫 답장 시간, 5분 이내 답장 건수, 자격 확인 완료 건수, 현장 방문 요청 및 확정 건수, 인계(handoffs), 옵트아웃(opt-outs) 및 유출된 리드 정보가 포함됩니다. 소유주와 관리자는 모든 요금제에서 중앙값 데이터를 확인할 수 있습니다.
9. 이중 언어 UI 세부 사항 (Bilingual UI details)
아랍어 지원은 모델 자체만의 기능이 아닙니다. 에이전트 받은 편지함은 메시지 버블별로 방향을 렌더링하며, 숫자, 가격 및 매물 참조 번호는 오른쪽에서 왼쪽으로(right-to-left) 작성되는 텍스트 내부에서도 뒤집히지 않도록 격리됩니다. 사소한 것 같지만 에이전트에게는 엄청난 차이를 만드는 기능입니다.
요약 (Takeaways)
- 웹훅(webhooks)은 가볍고멱등성(idempotent)을 유지하며, 비동기적으로 처리하세요.
- 모든 사실에 근거를 두고(Ground), 모델의 앞뒤에 결정론적 검사(deterministic checks)를 배치하세요.
- '초안 작성 후 전송 안 함(draft, don't send)' 기능을 디버그 플래그가 아닌 핵심 기능으로 만드세요.
- 사람 간 인계(human handoffs)에는 타이머를 설정하세요. 지연 시간(latency)은 그곳에 숨어있기 때문입니다.
- 정직한 측정 기준 하나를 선택하고, 그것을 중심으로 제품을 구축하세요.
두바이에서 부동산 중개업소를 운영하든, 아니면 실제 리드(leads)에서 어떻게 작동하는지 궁금할 뿐이든, **Sabbaq at getsabbaq.com**을 확인해 보세요.