피자 데모가 큰 인기를 끌 것이라는 점은 알고 있었습니다.

AI가 식당에 전화를 겁니다. AI가 음식을 주문합니다. 모두가 그 클립을 게시합니다.

그러고 나서 저는 댓글을 읽었습니다.

OpenClaw 스레드를 뒤져보던 중, OpenClaw, Vapi, 그리고 Twilio를 사용하여 피자를 주문하는 것에 대한 게시물을 발견했습니다. 한 답변이 즉시 거품을 걷어냈습니다. 웹사이트에서 피자를 주문하는 것이 이미 더 쉬운데 왜 누군가가 그런 기능을 원하겠느냐는 것이었습니다.

가혹하지만, 맞는 말입니다.

피자는 소비자용 음성 에이전트 (voice agents)를 위한 나쁜 벤치마크 (benchmark)입니다. 왜냐하면 잘못된 문제를 해결하기 때문입니다. 대부분의 음성 에이전트 데모가 그렇습니다. 유용한 것은 훨씬 더 지루한 것임에도 불구하고, 그들은 참신함에 최적화되어 있습니다:

• 예약하기 (booking appointments)
• 매장 재고 확인하기 (checking store inventory)
• 가격 비교하기 (comparing prices)
• 전화 자동응답 시스템 (phone trees) 처리하기
• 직접 기다리지 않도록 대기 상태 유지하기

이것은 OpenClaw 음성 워크플로우 (voice workflows)를 연극이 아닌 소프트웨어처럼 느껴지게 만드는 제가 본 첫 번째 프레이밍 (framing)입니다.

진짜처럼 들리는 첫 번째 OpenClaw 유스케이스 (use case)

제 생각을 바꾼 스레드는 전혀 화려하지 않았습니다.

한 사용자가 OpenClaw를 사용하여 다음과 같은 작업을 수행한다고 설명했습니다:

• 이발 예약하기
• 치과 예약하기
• ElevenLabs 음성 API를 사용하여 지역 상점에 전화를 걸어 재고가 있는지 묻기
• 매주 여러 식료품점을 확인하고 가격 비교 내용을 이메일로 보내기

이것이 진짜 워크플로우 (workflow)입니다.

"내 인생의 모든 행정 스택을 대체해줘"가 아닙니다.
"나의 디지털 컨시어지 (digital concierge)가 되어줘"도 아닙니다.
그저: 몇 군데에 전화하고, 제한된 질문을 던지고, 구조화된 답변을 가져오는 것입니다.

이것이 작동하는 이유는 클릭 시간을 줄이는 것이 아니라 대기 시간을 제거하기 때문입니다.

피자 사이트를 클릭하는 것은 쉽습니다. 치과 사무실과 통화 대기를 하는 것은 쉽지 않습니다.

이 차이는 대부분의 에이전트 데모가 인정하는 것보다 더 중요합니다.

왜 전화 심부름이 피자 봇보다 더 효과적인가

전화 심부름은 보통 명확한 성공 기준을 가지고 있습니다.

예시:

• "화요일이나 수요일 오후 5시 이후로 이발 예약해줘."
• "Home Depot에 20x20x1 MERV 13 필터 재고가 있는지 물어봐줘."
• "이 치과가 신규 환자를 받는지 확인해줘."
• "상점 3곳에 전화해서 가장 저렴한 가격을 문자로 보내줘."

각각은 경계가 명확한 결과 (bounded outcome)를 가집니다.

예약이 존재하거나 존재하지 않거나.
물건이 재고가 있거나 없거나.
병원이 신규 환자를 받거나 받지 않거나.

이것이 에이전트 (Agent)에게 필요한 형태입니다.

가드레일 (Guardrails)의 유용한 버전은 "모델을 인간처럼 들리게 만드는 것"이 아닙니다. 그것은 "모델이 완료 (done)의 모습이 무엇인지 알게 만드는 것"입니다.

피자 주문은 보기보다 더 복잡합니다:

• 메뉴가 변경됨
• 옵션 (modifiers)이 변경됨
• 주소가 중요함
• 결제가 중요함
• 웹사이트가 이미 흐름 (flow)을 더 잘 처리함

따라서 Reddit의 회의론자들은 의도치 않게 유용했습니다. 그들은 이 카테고리 자체를 부정하는 것이 아니었습니다. 그들은 현실과 접촉했을 때 실제로 살아남을 수 있는 좁은 영역을 정의하고 있었던 것입니다.

OpenClaw 음성 플러그인이 게임의 모든 것을 보여줍니다

아키텍처 (Architecture)가 핵심을 말해줍니다.

OpenClaw 음성 통화 플러그인은 자율적인 쇼핑 봇의 형태가 아닙니다. 그것은 감독을 받는 전화 상담원 (supervised phone worker)의 형태를 띠고 있습니다.

전형적인 스택 (Stack):

• Twilio Programmable Voice
• Twilio Media Streams
• OpenAI Realtime API
• 승인, 결과, 그리고 에스컬레이션 (escalation)을 위한 OpenClaw 도구들

중요한 점은 그것이 말을 할 수 있다는 것이 아닙니다.

말을 할 수 있는 시스템은 많습니다.

중요한 점은 통화 제어 인터페이스 (call control surface)입니다.

실제로 중요한 도구들

이 플러그인은 다음과 같은 함수들을 노출합니다:

• press_phone_keys (전화 키 누르기)
• report_call_outcome (통화 결과 보고)
• end_call (통화 종료)
• ask_owner (소유자에게 문의)
• transfer_to_owner (소유자에게 연결)

이것은 데모용 인터페이스가 아니라 워크플로우 (workflow) 인터페이스입니다.

만약 제가 엔지니어로서 이것을 검토한다면, ask_owner가 제가 가장 먼저 동그라미를 칠 기능일 것입니다.

그 기능이야말로 시스템을 "귀여운 수준"에서 "어쩌면 사용 가능한 수준"으로 바꾸어 놓는 핵심입니다.

예시 흐름:

1. 에이전트가 이발소에 전화를 겁니다.
2. 이발사가 5시는 꽉 찼지만 5시 30분은 가능하다고 말합니다.
3. OpenClaw가 당신에게 SMS를 보냅니다.
4. 당신이 yes라고 답장합니다.
5. 그 답변이 실시간 통화에 다시 전달됩니다.
6. 예약이 완료됩니다.

이것이 정확히 올바른 경계입니다.

완전한 자율성도 아니고,
가짜 자신감도 아닙니다.
워크플로우를 계속 진행할 수 있을 만큼의 적절한 감독입니다.

실무에서 좋은 가드레일이란 어떤 모습인가

이러한 종류의 워크플로우에서 규칙 세트는 꽤 간단합니다:

1. 에이전트가 반복적인 경로를 처리하도록 합니다.
2. 선호도가 변경되면 일시 중지합니다.
3. 돈이나 신원(identity)이 연관된 경우 에스컬레이션(escalate)합니다.
4. 구조화된 결과(structured result)를 반환합니다.

이것이 제가 전화 심부름을 처리하는 모든 에이전트에게 원하는 것입니다.

모호한 자연어 요약만으로는 충분하지 않습니다. 마지막에는 기계가 읽을 수 있는(machine-readable) 무언가가 필요합니다.

예를 들어:

{
  "task": "book_haircut",
  "status": "booked",
...

그러한 출력은 n8n, Make, Zapier 또는 커스텀 워크플로우(custom workflow)의 다음 단계를 트리거할 수 있습니다.

통신망(on the wire)에서 일어나는 일

내부적으로 이 카테고리가 작동하는 이유는 Twilio Media Streams가 WebSockets를 통해 실시간 통화 오디오를 푸시할 수 있기 때문입니다.

이를 통해 통화를 블랙박스(black box)처럼 취급하는 대신, 전화 통화에 대한 이벤트 기반 제어(event-driven control)를 할 수 있습니다.

유용한 이벤트 유형은 다음과 같습니다:

• connected
• start
• media
• dtmf
• stop
• mark

마지막 항목은 들리는 것보다 더 중요합니다.

실시간 음성 시스템을 구축해 본 적이 있다면, 아주 작은 타이밍 버그가 데모를 순식간에 망가뜨린다는 것을 알고 있을 것입니다. 전화를 끊기 전에 mark 에코(echo)를 기다리는 것과 같은 세부 사항이 바로 "영상에서만 작동하는 것"과 "실제 운영 환경(production)에서 작동하는 것"을 가르는 차이입니다.

Media Streams를 처리하기 위한 최소한의 Node 서버는 대략 다음과 같습니다:

import WebSocket, { WebSocketServer } from 'ws';

const wss = new WebSocketServer({ port: 8080 });
...

그리고 실용적인 상태 머신(state machine)을 원한다면 다음과 같은 모습일 것입니다:

type CallState =
  | 'dialing'
  | 'ivr'
...

이것이 실제 구현을 위한 사고방식입니다: 상태(state), 재시도(retries), 에스컬레이션(escalation), 구조화된 결과(structured outcomes).

아무도 입 밖으로 꺼내고 싶어 하지 않는 비용 문제

음성 에이전트(Voice agents)는 멋집니다.

하지만 음성 에이전트는 청구서를 생성하는 데에도 매우 능숙합니다.

이 부분이 바로 많은 "그저 전화 통화를 자동화하겠다"는 데모들이 무너지는 지점입니다.

당신은 종종 여러 계층에 대해 동시에 비용을 지불하게 됩니다:

• 음성 플랫폼 분당 요금 (voice platform minutes)
• 모델 사용량 (model usage)
• 전화 통신 (telephony)
• 재시도 (retries)
• 대기 시간 (hold time)
• 동시성 (concurrency)

공개된 가격 책정(Public pricing)을 보면 이 문제가 꽤 명확해집니다.

이제 사람들이 실제로 원하는 워크플로우(workflow)를 살펴보겠습니다:

• 미용사 A에게 전화
• 응답 없음
• 나중에 재시도
• 미용사 B에게 전화
• 대기 상태 (hold)
• 다른 시간대 확보
• 승인을 위해 주인에게 문자 전송
• 예약 완료
• 실패 시, 내일 다시 시도

이것은 깔끔한 하나의 요청/응답(request/response) 사이클이 아닙니다.

이는 막다른 길, 재시도, 대기 음악, 그리고 부분적인 진행이 뒤섞인 복잡한 그래프(graph)입니다.

즉, 사용량 기반 과금(usage-based billing) 방식은 이 워크플로우를 유용하게 만드는 바로 그 동작에 대해 페널티를 부여하게 됩니다.

에이전트(agent)가 끈기 있게 행동하면 비용이 상승합니다.
에이전트가 책임감 있게 재시도하면 비용이 상승합니다.
현실 세계가 복잡해서 통화 시간이 길어지면 비용이 상승합니다.

이것이 바로 수많은 자동화(automation)를 실행하는 사람들에게 이 카테고리가 빠르게 기묘해지는 이유입니다.

실제로 이를 구축하고 있다면, 모델의 영리함보다 비용 예측 가능성이 더 중요합니다

이 지점에서 대부분의 팀은 잘못된 최적화에 집중합니다.

그들은 모델 품질을 끝없이 비교하지만, 자신들의 자동화 경제성(automation economics)이 망가져 있다는 사실은 무시합니다.

만약 n8n, Make, Zapier, OpenClaw 또는 커스텀 워크플로우 엔진(workflow engine) 내에서 AI 에이전트를 실행하고 있다면, 고통스러운 부분은 대개 음성 에이전트 하나를 작동시키는 것이 아닙니다.

토큰 소비(token spend)를 일일이 감시하지 않고 하루 종일 실행되도록 내버려 두는 것입니다.

그렇기 때문에 저는 정액제 컴퓨팅(flat-rate compute)이 여기서 더 흥미로운 인프라 계층(infrastructure layer)이라고 생각합니다.

Standard Compute를 사용하면, OpenAI 호환 API 부분이 핵심이 됩니다:

• 기존 OpenAI SDK 및 HTTP 클라이언트(HTTP clients)를 즉시 대체 가능
• 토큰당 비용에 대한 불안감 대신 예측 가능한 월간 가격 책정
• 재시도, 분기(branch), 지속적 실행이 필요한 자동화에 유용함
• GPT-5.4, Claude Opus 4.6, Grok 4.20 간의 동적 라우팅 (dynamic routing)

여러분의 워크플로우가 계속해서 전화를 걸고, 확인하고, 기다리고, 재시도하는 종류라면, 예측 가능한 비용이 이론적인 토큰 효율성보다 승리합니다.

이는 사람들이 인정하는 것보다 훨씬 더 중요한 문제입니다.

지금 당장 어떤 스택(stack)을 선택하시겠습니까?

그것은 당신이 얼마나 많은 제어권(control)을 원하는지에 달려 있습니다.

이 사용 사례(use case)에 대해, 저는 OpenClaw가 가장 흥미로운 옵션이라고 생각합니다.

그것이 가장 화려하기 때문이 아닙니다.
음성 에이전트(voice agents)에 대한 진실을 인정하기 때문입니다:

• 경계(boundaries)가 필요함
• 상태(state)가 필요함
• 재시도(retries)가 필요함
• 에스컬레이션 경로(escalation paths)가 필요함
• 자주 실행하려면 비용 제어(cost control)가 필요함

이는 일반적인 "내 AI가 점심을 주문하는 것을 지켜보세요" 식의 데모보다 실제 소프트웨어에 훨씬 더 가깝습니다.

내가 실제로 구축할 것

만약 제가 이것의 프로덕션(production)에 가까운 버전을 구축한다면, 범위를 좁게 유지할 것입니다.

입력 (Input):

이번 주 오후 5시 이후로 이발 예약해줘

워크플로우 (Workflow):

1. 요청을 구조화된 작업(structured task)으로 파싱(Parse)합니다.
2. 2~3곳의 후보 업체에 전화를 겁니다.
3. press_phone_keys를 사용하여 IVR(자동 응답 시스템)을 탐색합니다.
4. 실시간 음성 모델(realtime voice model)로 예약 관련 질문을 합니다.
5. 제안된 시간이 선호 사항을 벗어날 경우 ask_owner를 트리거합니다.
6. 응답이 없거나 콜백(callback) 요청이 오면 재시도합니다.
7. 구조화된 결과(structured result)를 반환합니다.

가능한 결과:

{
  "status": "booked",
  "business": "Northside Barbers",
...

그리고 운영(operationally) 측면에서, 기본적인 CLI 가시성을 원할 것입니다.

openclaw onboard
openclaw status --all
openclaw logs --follow

왜냐하면, 그렇습니다, 지루한 운영(ops)은 여전히 중요하기 때문입니다.

만약 이 시스템이 매주 수요일 아침마다 상점에 전화를 걸고 있다면, 저는 그것이 얼마나 "에이전트다운(agentic)" 소리를 내는지 신경 쓰기 전에, 일단 살아있는지부터 알고 싶을 것입니다.

소비자용 음성 에이전트의 비기믹(non-gimmick) 버전

사람들이 실제로 계속 실행할 것이라고 생각하는 버전은 다음과 같습니다:

• 요청을 텍스트로 보냅니다.
• OpenClaw가 몇 군데에 전화하도록 합니다.
• 제약된 대화(constrained conversation)에만 음성 AI를 사용합니다.
• 선호 사항이 변경되면 승인을 요청합니다.
• 신원 확인, 결제, 또는 예외 사례(edge cases)가 발생하면 사람에게 전달합니다.
• 구조화된 결과로 마무리합니다.

그게 전부입니다.

가짜 범용 지능(general intelligence)도 없습니다.
박수를 갈구하는 피자 로봇도 없습니다.

당신이 다른 일을 하는 동안 짜증 나는 전화 업무를 처리하는, 제약된 음성 작업자(voice worker)가 있을 뿐입니다.

그것이 훨씬 더 나은 제품의 형태입니다.

그리고 만약 이 카테고리가 계속 성장한다면, 승자는 가장 자율적인 (autonomous) 시스템이 아닐 것이라고 생각합니다.

제가 생각하는 승자는 다음과 같은 요소를 갖춘 시스템입니다:

• 가장 뛰어난 가드레일 (guardrails)
• 가장 깔끔한 재시도 (retries) 프로세스
• 가장 명확한 핸드오프 (handoffs)
• 가장 예측 가능한 경제성 (economics)

솔직히 말해서, 이는 AI가 페퍼로니 피자를 주문하는 것을 지켜보는 것보다 훨씬 더 유용하게 들립니다.

그리고 제가 치과에 전화를 걸 때 신뢰하고 사용할 수 있는 소프트웨어에 훨씬 더 가깝습니다.