안녕하세요 DEV 독자 여러분 — 저는 SkipCalls의 창립자이자 엔지니어인 Nikita입니다. 저희는 두 명의 공동 창업 팀과 함께 이 서비스를 구축하고 있습니다. 왜냐하면 작은 사업체들은 고객 전화가 응답되지 않을 때마다 실제 수익을 잃기 때문입니다.

SkipCalls는 AI 전화 리셉셔니스트로, 걸려오는 전화를 받고, 잠재 고객(lead)의 자격을 검증하며, 구조화된 메시지를 기록하고, 약속을 예약하며, 필요할 때 전화를 연결하고, 마지막으로 사장님에게 깔끔한 요약본을 보내줍니다. 또한 후속 조치나 캠페인을 위해 아웃바운드 콜도 걸 수 있습니다.

이곳에 처음 글을 쓰게 되어 제품과 그 뒤에 숨겨진 몇 가지 엔지니어링 교훈들을 소개하고자 합니다.

우리가 선택한 문제점

웹사이트 채팅은 놓쳐도 괜찮습니다. 하지만 전화 통화는 종종 그렇지 않습니다.

배관공, 법률 사무소, 전기 기술자, 부동산 중개인, 미용실 또는 의료 사무소를 운영하는 사람에게 있어, 전화를 건 사람이 아무도 받지 않으면 다음 사업체로 이동해 버릴 수 있습니다. 기존의 음성 사서함(voicemail)은 문제를 기록할 뿐 해결하지 못합니다. 전화를 건 사람은 여전히 모든 것을 설명하고, 기다리고, 누군가 다시 전화하기를 바랄 뿐입니다.

저희는 전화 경험이 유능한 프런트 데스크 팀원과 가깝게 느껴지기를 원했습니다: 24시간 연중무휴로 이용 가능하고, 유용한 후속 질문을 할 수 있으며, 사업체에 대한 이해도가 높고, 자신이 무엇을 할 수 있고 무엇을 할 수 없는지에 대해 솔직할 수 있는.

통화 중 발생하는 과정

일반적인 인바운드(inbound) 흐름은 다음과 같습니다:

1. 고객이 사업체의 기존 번호로 전화를 겁니다.
2. 응답하지 않거나 업무 시간 외의 전화는 SkipCalls 번호로 전달됩니다.
3. AI 리셉셔니스트가 사업체의 인사말과 맥락을 가지고 전화를 받습니다.
4. 통화 내용을 처리하고, 사장님이 실제로 필요로 하는 세부 정보를 수집하며, 설정에 따라 예약하거나 연결할 수 있습니다.
5. 사장님은 녹취록(transcript), 요약본(summary), 그리고 다음 조치 사항을 즉시 받게 됩니다.

설정은 의도적으로 간단합니다. 사업체 사장님이 놓치는 잠재 고객을 막기 위해 SIP, 실시간 오디오(realtime audio), 프롬프트 디자인(prompt design) 또는 웹훅 인프라(webhook infrastructure)를 이해할 필요는 없어야 합니다.

그 뒤에 숨겨진 스택

저는 공동 창업 팀의 유일한 엔지니어이므로, 시스템은 여러 매우 다른 영역을 다루면서도 이해하기 쉬워야 합니다:

그 뒤에 숨겨진 스택

저는 공동 창업 팀의 유일한 엔지니어이므로, 시스템은 여러 매우 다른 영역을 다루면서도 이해하기 쉬워야 합니다:

• 백엔드 및 제품 API를 위한 TypeScript와 NestJS
• 실시간 음성 에이전트를 위한 Python
• 웹 및 모바일 앱을 위한 React와 React Native
• 실시간 음성 인프라를 위한 LiveKit
• 영구 상태, 큐, 제한, 조정(coordination)을 위한 PostgreSQL과 Redis
• 통화 후 발생하는 액션들을 위한 웹훅(Webhooks) 및 캘린더 통합(calendar integrations)

진짜 어려운 부분은 모델이 전화 연결을 통해 말을 하게 만드는 것이 아닙니다. 진짜 어려운 부분은 발신자가 끼어들거나, 방향을 바꾸거나, 배경 소음이 있거나, 비즈니스에서 한 번도 설정하지 않은 것을 묻거나, 실제 사람이 필요할 때 전체 시스템이 신뢰성을 갖도록 만드는 것입니다.

프로덕션 음성 AI 구축에서 얻은 교훈

1. 지연 시간(Latency) 자체가 개성이 된다

너무 늦게 도착하는 정확한 답변은 고장 난 것처럼 느껴집니다. 음성 에이전트는 빠른 턴 감지(turn detection), 신중한 스트리밍, 그리고 중단 처리(interruption handling)가 필요합니다. 채팅에서는 눈에 띄지 않는 작은 지연도 통화에서는 불편한 침묵이 됩니다.

2. 비즈니스 사실이 일반적인 기발함보다 중요하다

최고의 프롬프트라도 영업시간, 서비스 지역, 가격 정책, 또는 이관 정책을 만들어낼 수는 없습니다. 우리는 접수원이 추측하지 않고도 유용할 수 있도록 비즈니스 프로필과 명시적인 소유자 설정을 일급 제품 데이터(first-class product data)로 취급합니다.

3. 실패 모드는 숨기는 것이 아니라 설계되어야 한다

통화는 통신사, SIP, 실시간 세션, 모델, 도구(tool), 큐, 또는 다운스트림 API 계층에서 실패할 수 있습니다. 프로덕션 시스템은 관찰 가능한 핸드오프(handoff)와 안전한 폴백(fallback)이 필요합니다. “모델이 보통 처리해 줄 거야”라는 것은 운영 전략이 아닙니다.

4. 통화 후 워크플로우가 제품의 절반이다

자연스러운 대화는 가치가 있지만, 비즈니스 결과가 더 중요합니다. 발신자의 이름과 긴급성을 포착했습니까? 약속을 만들었습니까? 소유자가 간결한 요약을 얻었습니까? CRM이나 자동화 시스템이 워크플로우를 계속할 수 있습니까? 우리는 그 결과로부터 거꾸로 설계합니다.

5. AI는 언제 인계해야 하는지 알아야 한다

접수원은 자신의 역할 내에 머무름으로써 신뢰를 얻습니다. 인계 규칙(Transfer rules), 콜백 경로(callback paths), 명시적 확인(explicit confirmations), 그리고 투명한 한계점(transparent limitations)은 음성 품질만큼이나 중요합니다.

우리가 만들고자 하는 것

우리의 목표는 간단합니다. 소규모 사업체에 몇 분 만에 설정하고 자신 있게 운영할 수 있는 전화 접수원을 제공하는 것입니다. 이는 더 나은 신뢰성, 심층적인 스케줄링 및 CRM 워크플로우, 비즈니스 소유주를 위한 더 명확한 제어 기능, 그리고 모든 통화를 실행 가능한(actionable) 도구를 의미합니다.

제품은 skipcalls.com에서 확인하실 수 있습니다.

음성 AI, 실시간 에이전트, 전화 시스템(telephony), 또는 소규모 비즈니스 자동화에 대해 작업하는 다른 빌더들의 이야기를 듣고 싶습니다. 에이전트를 데모 환경에서 프로덕션으로 옮길 때 가장 놀랐던 실패 모드(failure mode)는 무엇이었나요?