음성 AI가 사람의 말을 알아듣고 자연스럽게 대답하는 문제는 빠르게 해결되고 있다. OpenAI가 9월 공개한 GPT-Live-1은 사람이 말을 끝낼 때까지 기다렸다가 답하는 방식에서 더 나아가, 듣고 말하는 일을 동시에 처리한다. 사람이 중간에 끼어들거나 잠시 망설여도 대화를 이어갈 수 있고, 필요한 작업은 뒤쪽의 AI 모델이나 도구에 넘길 수 있다.[^1] Mistral의 Voxtral Realtime도 음성 전사의 지연을 200ms 아래 (0.2초 미만)까지 낮출 수 있는 구조를 제공한다.[^2]
이러한 변화는 음성 에이전트를 훨씬 자연스럽게 만든다. 다만, 동시에 AX를 생각하는 기업에는 조금 다른 문제가 생긴다. AI가 고객의 말을 충분히 잘 알아듣는다면, 이제 어디까지 스스로 행동하게 할 것인가.
정보를 알려주는 AI라면 잘못된 답변을 정정하면 된다. 하지만 CRM을 수정하고, 예약을 취소하고, 카드를 정지하고, 환불을 실행할 수 있는 AI는 다르다. 대화를 잘하는 능력과 기업 시스템을 실제로 움직일 권한 사이에 운영 규칙이 필요해진다.
이 관점에서 음성 에이전트가 본격적인 AX 도구가 되는 과정에서 중요한 병목 중 하나가 여기에 있다. 모델의 인식률을 몇 % 더 높이는 것 만으로는 해결되지 않는다. 불확실한 상황에서 언제 행동하고, 언제 확인하고, 언제 멈출 것 인지를 정하는 정책이 필요하다.
같은 79% 정확도에서도 사용자 경험은 달라질 수 있다
이 문제를 꽤 직관적으로 보여주는 사례가 있다.
2026년 AI Engineer World's Fair에서 Roku의 Amit Desai는 음성 비서가 음악을 재생하는 상황을 예로 들었다.[^3]
1,000번의 음악 요청 가운데 시스템이 정확히 알아들은 요청이 790번, 잘못 알아들은 요청이 210번이라고 가정한다. 정확도는 79%다.
가장 단순한 음성 비서는 자신이 알아들은 내용을 매번 실행한다. 잘 들었으면 원하는 노래가 나오지만, 틀렸다면 사용자는 잘못된 노래를 듣고, 중단하고, 다시 말해야 한다.
Desai는 이 과정을 사용자가 지불하는 시간으로 환산했다. 잘못된 노래를 실행했을 때의 복구 비용을 약 10초, 시스템이 확신하지 못해 멈추고 다시 물었을 때의 비용을 약 4초로 놓았다.
흥미로운 부분은 그다음이다.
모델의 정확도는 79% 그대로 두고, 자신감이 낮은 요청에서는 행동하지 않도록 정책만 바꿨다. 직관적으로 65% 정도를 경계로 잡을 수도 있지만, 사용자 비용을 최소화하도록 계산해보면 이 사례의 act-or-stop 경계는 약 43%였다. 모델을 더 똑똑하게 만들지 않고도 사용자가 겪는 불편을 줄일 수 있었던 셈이다.[^3]
여기에 한 단계가 더 파고 들어가면 다음과 같다: 시스템이 확실하면 바로 재생하고, 애매하면 “Kiss라고 말씀하셨나요?”라고 확인하고, 확신이 아주 낮으면 다시 물어볼 수 있다.
즉 음성 AI의 행동은 크게 세 가지로 나뉠 수 있다
Act — 바로 행동한다.
Confirm — 행동하기 전에 확인한다.
Stop — 현재 정보로는 행동하지 않는다.
Confirm도 공짜는 아니다. 확인이 맞으면 대화가 조금 느려지고, 틀렸다면 사용자가 다시 설명해야 한다. Desai의 사례에서는 올바른 확인에 약 2초, 잘못된 확인을 정정하는 데 약 6초의 비용을 둔다. 결국 좋은 정책은 확인을 많이 넣는 정책이 아니라, 잘못된 실행과 불필요한 확인을 함께 줄이는 정책이다.[^3]
AX에서도 이 차이를 생각해볼 필요가 있다. 모델 성능이 충분히 좋아진 뒤에는 “얼마나 정확한가”와 함께 **“틀릴 가능성이 있을 때 어떻게 행동하는가”**가 제품 경험을 크게 좌우한다.
기업 업무에서는 오류마다 가격이 다르다
음악을 잘못 재생하는 데 드는 비용은 몇 초다. 반면, 기업 업무에서는 차이가 더 커진다.
“내 주문 어디 있어?”를 잘못 이해했다면 다시 질문하면 된다. 또한 “내일 회의를 오후 3시로 옮겨줘”를 잘못 처리했다면 일정을 원복할 수 있다.
하지만 고객 계좌에서 돈을 보내거나, 항공권을 취소하거나, 보험 청구를 승인하거나, 기업 시스템에서 권한을 변경하는 작업은 이야기가 달라진다. 모델의 정확도가 같더라도 실패했을 때 발생하는 비용은 업무마다 차이가 있다. 실제로 금융 서비스용 AI 에이전트를 만드는 Gradient Labs의 사례를 보면 이 차이가 분명하다.[^4]
고객이 전화를 걸어 카드를 도난당했다고 말하면 AI는 단순히 “카드를 정지해드리겠습니다”라고 답하는 데서 끝나지 않는다. 고객의 신원을 확인하고, 절차에 맞는지 판단하고, 카드를 정지한 뒤, 새로운 카드를 발급하는 과정까지 이어진다. 중간에 고객이 말을 끊거나 내용을 정정하더라도 현재 어느 단계에 있는지를 유지해야 한다.
Gradient Labs는 이런 금융 업무에서 매 상호작용마다 15개 이상의 guardrail을 병렬로 운영한다고 설명한다. 금융 조언 여부, 취약 고객 신호, 고객 불만, 본인 인증 우회 시도, 민감정보 접근 등을 별도로 감시한다.[^4]
여기서 중요한 것은 AI가 말을 얼마나 자연스럽게 하느냐가 아니다. 어떤 조건을 만족해야 다음 행동으로 넘어갈 수 있는가가 실제 운영의 중심이 된다.
그래서 Act, Confirm, Stop은 AX의 운영 모델에 가깝다
기업이 AI 에이전트를 도입할 때 모든 업무에 동일한 수준의 자율성을 줄 이유는 없다.
대략 다음처럼 생각할 수 있다.
| 업무 상황 | 예시 | 기본 행동 |
|---|---|---|
| 영향이 작고 조회 중심 | 주문 상태 조회, 사내 규정 검색 | Act |
| 영향은 있지만 쉽게 되돌릴 수 있음 | 일정 변경, 배송 전 주소 수정 | Act 또는 Confirm |
| 고객·금전·계정 상태를 변경 | 환불, 예약 취소, 카드 정지 | Confirm |
| 본인 확인 실패·정책 예외·높은 위험 | 송금, 권한 변경, 규정 밖 보상 | Stop / Human Handoff |
물론 이 표가 모든 기업에 그대로 적용되는 것은 아니다.
항공사와 은행의 기준이 다르고, 같은 은행에서도 잔액 조회와 송금의 기준은 달라진다. 환불조차 금액이나 고객 상태, 상품에 따라 다르게 처리할 수 있다. 그래서 음성 AI의 행동 전환을 위한 임계값을 단순히 AI의 confidence score 같은 하나의 KPI로 정하기도 어렵다.
실제 AX 환경에서는 최소한 네 가지를 함께 봐야 한다.
(1) AI가 사용자의 의도를 얼마나 확실하게 이해했는가.
(2) 틀렸을 때 발생하는 비용이 얼마나 큰가.
(3) 실행한 뒤 되돌릴 수 있는가.
(4) 현재 사용자와 AI에게 이 행동을 할 권한이 있는가.
같은 90%의 확신도라도 날씨를 조회하는 것과 계정을 해지하는 것은 다른 정책을 가져야 한다.
위 문제는 사실 음성에만 있는 것이 아니다
Air India가 최근 Salesforce Agentforce를 이용해 환불 프로세스를 자동화한 사례도 같은 구조를 보여준다.[^5] 항공사의 환불은 단순히 고객에게 답변을 생성하는 일이 아니다. 여러 조건을 확인하고, 회사 정책을 적용하고, 여러 시스템을 거쳐 실제 환불을 처리해야 한다. Air India는 이 프로세스에 AI 에이전트를 적용하면서 기존 약 14일이 걸리던 환불 처리 시간을 약 4시간으로 줄였다고 밝혔다.[^5]
AX가 만들어낼 수 있는 가치가 어디에 있는지 잘 보여주는 사례다. 동시에 AI가 실제 행동을 시작하면 무엇을 관리해야 하는지도 보여준다.
고객 요청을 이해했다고 바로 환불할 수는 없다. 예약 상태와 결제 정보를 확인하고, 환불 조건을 검증하고, 회사 정책에 맞는지를 판단한 뒤 시스템을 변경해야 한다.
이 사례는 음성 에이전트의 행동 임계값을 생각할 때도 중요하다.
고객의 요청이 전화로 들어오든, 채팅으로 들어오든, 이메일로 들어오든 실제 기업 시스템을 변경하는 단계에서는 동일한 정책을 적용할 수 있기 때문이다. 앞으로 기업의 Agent Architecture는 대략 이런 구조에 가까워질 가능성이 높다.
고객의 요청
↓
대화·의도 이해
↓
기업 정책 / 권한 / 위험 판단
↓
Act ─ Confirm ─ Stop / Handoff
↓
기업 시스템 실행 또는 사람에게 이관
↓
결과 기록·평가
음성 모델은 이 구조의 앞 부분을 매우 자연스럽게 처리하고 있다. 그러나 AX 관점에서 어려운 작업은 그 이후이다.
좋은 AX는 자율성을 최대화하는 것이 아니다
AI 에이전트 도입을 이야기하다 보면 automation rate나 autonomous resolution rate 같은 숫자에 관심이 쏠리기 쉽다.
몇 %의 고객 문의를 사람이 개입하지 않고 해결했는지, 몇 개의 프로세스를 end-to-end로 자동화했는지를 측정하는 방식이다.
중요한 지표지만 이것만 최적화하면 이상한 결과가 나올 수 있다.
AI가 확인해야 할 상황에서도 확인하지 않으면 자율 처리율은 올라간다. 사람에게 넘겨야 할 업무까지 처리하면 human handoff는 줄어든다.
동시에 운영 리스크도 함께 커진다. 그래서 agentic AX에서는 다른 KPI가 필요하다.
(1) 잘못된 실행률: 고객의 최종 의도와 다른 행동이 실제 시스템에서 실행된 비율을 본다.
(2) 불필요한 확인 비율: 충분히 안전한 작업인데도 AI가 계속 확인을 요구해 사용자 경험을 떨어뜨리고 있는지 본다.
(3) 중단 후 복구율: AI가 행동을 멈췄을 때 고객이 얼마나 쉽게 작업을 다시 이어갈 수 있는지를 본다.
(4) Human Handoff 품질: AI가 언제 사람에게 넘겼는지뿐 아니라, 필요한 맥락을 함께 전달했는지를 본다.
(5) Safe Completion Time: 첫 답변 속도가 아니라 필요한 확인과 인증까지 포함해 작업이 안전하게 완료되는 시간을 본다.
이런 지표가 있어야 AI의 자율성을 높이는 것과 운영 품질을 높이는 것을 구분할 수 있다.
모델의 정확도가 계속 좋아지면 실행 경계 문제도 사라질까
물론 모델 정확도는 계속 중요하다. 음성을 잘못 듣고, 이름과 숫자를 자주 틀리고, 고객 의도를 제대로 이해하지 못한다면 행동 정책을 잘 만드는 것만으로 좋은 서비스를 만들 수 없다.
정확도가 높아질수록 Confirm이나 Stop이 필요한 영역도 줄어들 가능성이 있다. 다만 완전히 없어지지는 않는다.
기업 업무에는 결과의 비용이 비대칭적인 경우가 많기 때문이다. 99번 정확하게 처리하고 한 번 잘못 처리하는 시스템이 있다고 해도, 그 한 번이 음악 재생 오류인지 대규모 환불 오류인지에 따라 평가가 달라진다.
더구나 음성은 화면보다 승인 여부가 모호해질 수 있다. “네”, “응”, “잠깐”, “아니 그게 아니라” 같은 짧은 표현이 대화 중 자연스럽게 섞인다. GPT-Live-1처럼 사람이 말하는 중간에도 듣고 반응하는 시스템이 늘어날수록 대화는 편해지지만, 어느 순간을 최종 승인으로 볼 것인지에 대한 설계는 오히려 중요해진다.[^1] 기술이 자연스러워질수록 사용자는 시스템을 덜 의식하게 되기 때문이다. 그래서 실행 경계는 더 명확해야 한다.
AX의 다음 질문은 ‘무엇을 할 수 있는가’에서 ‘언제 하게 할 것인가’로 간다
OpenAI의 Realtime Agents SDK에서도 도구를 호출하는 판단과 실제 실행을 분리할 수 있다. 특정 행동에는 사람의 승인을 요구하고, 승인되지 않으면 실행을 멈추도록 만들 수 있다.[^6]
OpenAI가 기업용 agent deployment 제품인 Presence에서 정책, 승인 조건, guardrail, human escalation을 별도의 운영 요소로 두는 것도 같은 이유다. 기업이 직접 AI가 무엇을 할 수 있는지, 언제 승인이 필요한지, 언제 사람이 개입해야 하는지를 정하도록 설계되어 있다.[^7]
이 흐름은 AX의 방향을 꽤 명확하게 보여준다. 초기 생성형 AI 도입에서는 좋은 답을 만드는 것이 중요했다. Agentic AI로 넘어가면 좋은 답변만으로는 충분하지 않다. AI가 실제 기업 시스템을 움직이기 때문이다. 그래서 앞으로의 AX 성숙도를 단순히 “얼마나 많은 일을 AI에게 맡겼는가”로 평가하는 것은 부족하다고 본다.
더 중요한 것은 어떤 업무를 어느 조건에서 스스로 처리하게 하고, 언제 확인을 요구하며, 언제 사람에게 돌려보낼지를 얼마나 명확하게 설계했는가다. 좋은 에이전트는 모든 요청을 스스로 처리하는 시스템이 아니다. 낮은 위험에서는 빠르게 움직이고, 중요한 순간에는 확인하며, 근거와 권한이 충분하지 않을 때는 멈출 수 있는 시스템이다.
음성 AI가 사람처럼 자연스럽게 말하는 단계까지 왔다면, 다음에는 사람처럼 망설여야 할 순간을 아는 시스템이 필요하다.
[^1]: OpenAI, “Build more natural voice experiences with GPT-Live-1 in the API,” September 10, 2026. https://openai.com/index/introducing-gpt-live-1-in-the-api/ [^2]: Mistral AI, “Voxtral transcribes at the speed of sound,” February 4, 2026. https://mistral.ai/news/voxtral-transcribe-2/ [^3]: Amit Desai, Roku, “Act, Confirm, or Stop? Smarter behavior for AI assistants, wearables & robots,” AI Engineer World's Fair 2026. https://ai.engineer/talks/Zd5b40Jbp_k-act-confirm-stop-smarter-behavior-ai-assistants [^4]: OpenAI, “Gradient Labs gives every bank customer an AI account manager,” April 1, 2026. https://openai.com/index/gradient-labs/ [^5]: Salesforce, “Air India Accelerates Customer Service Transformation with Salesforce Agentforce,” September 15, 2026. https://www.salesforce.com/in/news/press-releases/2026/09/15/air-india-accelerates-customer-service-transformation-with-agentforce/ [^6]: OpenAI Agents SDK, “Realtime Agents — Tools, approvals, handoffs, and guardrails.” https://openai.github.io/openai-agents-python/realtime/guide/ [^7]: OpenAI, “Introducing OpenAI Presence,” July 22, 2026. https://openai.com/index/introducing-openai-presence/