
ServiceNow, Now Assist for ITSM에 음성 에이전트 추가: ServiceNow Now Assist ITSM 음성 에이전트
요약
ServiceNow가 Now Assist for ITSM에 음성 에이전트 기능을 추가했다고 발표했습니다. 이번 업데이트는 텍스트 기반 채널을 넘어 음성 채널을 ITSM 프로세스에 통합하는 것을 목표로 합니다.
핵심 포인트
- ServiceNow Now Assist for ITSM에 음성 에이전트 기능 공식 추가
- 음성 채널 도입 시 발신자 식별, 상담원 전환, 녹음, 비용 효율성 검토 필요
- 릴리스 노트만으로는 음성 인식 품질이나 지원 언어를 확신할 수 없음
- 실제 도입 전 데이터와 전화 시스템을 활용한 파일럿 테스트 권장
2026년 7월 9일, ServiceNow는 한 가지 구체적인 변경 사항을 기록한 suite release note(스위트 릴리스 노트)를 발표했습니다: Now Assist for ITSM에 음성 에이전트가 추가되었습니다. 이는 독립적인 테스트나 구축 업체의 리뷰가 아닌, 벤더(Vendor)의 공식 기록입니다. 저는 이 글에서 릴리스를 통해 확인된 사실과 당신이 직접 확인해야 할 영역 사이의 경계를 엄격히 구분하고자 합니다.
만약 당신이 서비스 데스크(Service Desk)를 책임지고 있다면, 질문은 "이것이 멋진가"가 아니라 "고객의 실제 목소리를 티켓 프로세스에 들여보낼 가치가 있는가"가 될 것입니다. 그리고 별도의 벤더 라이선스를 구매하지 않고 다양한 모델을 통해 이러한 에이전트의 로직을 빠르게 가늠해 보고 싶다면, provod.ai를 통해 하나의 API로 유사한 프로토타입을 어떻게 구축하는지 살펴보십시오. 하지만 그전에 먼저 사실 관계부터 확인하겠습니다.
7월 9일 ServiceNow가 정확히 무엇을 발표했는가?
2026년 7월 9일자 suite release note에 따르면, 이번 업데이트는 Now Assist for ITSM 구성 요소에 음성 에이전트를 추가합니다. 이는 릴리스 사실에 대한 기록입니다: 스위트 출시 노트에 명시된 구체적인 한 줄입니다. "에이전트가 추가되었다"는 범위를 벗어나는 모든 사항은 릴리스 자체만으로는 증명되지 않습니다.
세 가지 계층을 구분하는 것이 중요합니다. 첫 번째는 벤더의 발표입니다: ServiceNow는 해당 기능이 존재한다고 말합니다. 두 번째는 독립적인 검증입니다: 릴리스 시점에는 검증된 바가 없으며, 오직 r/servicenow 커뮤니티에서 AI Agents에 대한 별도의 웨비나를 진행하고 있을 뿐이며, 이는 품질 측정이라기보다 방향성에 대한 논의입니다. 세 번째는 당신의 결론입니다: 이는 당신의 데이터, 당신의 전화 시스템, 그리고 당신의 언어로 파일럿 테스트를 거친 후에야 도출됩니다.
Release note(릴리스 노트)는 음성 인식의 품질을 증명하지 않습니다. 지원되는 언어를 명시하지 않으며, 전화 통합(Telephony Integration)을 설명하지 않고, 지역적 가용성을 확인해주지도 않습니다. 따라서 만약 누군가가 이 기록만을 근거로 "즉시 사용 가능한 러시아어 음성 지원"을 판매하려 한다면, 그것은 출처에서 나온 사실이 아니라 그 위에 덧씌워진 추측일 뿐입니다.
실질적인 의미는 간단합니다. 당신은 Now Assist for ITSM 내부에 해당 채널이 존재한다는 신호를 받았습니다. 하지만 효과를 계산할 때 근거로 삼을 수 있는 수치는 단 하나도 받지 못했습니다. 이어지는 섹션들은 이 신호를 경영진을 위한 발표 자료가 아닌, 검증 가능한 계획으로 전환하는 방법에 관한 것입니다.
서비스 데스크(Service Desk)에 음성 기능이 왜 필요한가?
ITSM에서의 음성 채널은 텍스트 채널과 네 가지 측면에서 다르며, 바로 이 요소들이 해당 기능의 성공 여부를 결정합니다: 발신자 식별(Identification), 상담원 전환(Handoff), 대화 녹음(Recording), 그리고 건당 처리 비용(Cost per interaction)입니다. 그 외의 모든 것은 이 요소들로부터 파생됩니다.
식별(Identification)은 당신이 음성만으로 작업을 수행하도록 신뢰할 수 있는지를 결정합니다. 에이전트가 단순히 인시던트(Incident)를 생성하는 단계라면 리스크가 낮습니다. 하지만 에이전트가 비밀번호를 변경하거나 직원을 대신하여 요청(Request)을 승인하기 시작하면, 신뢰할 수 있는 검증 절차가 필요합니다.
전환(Handoff)은 봇이 문제를 해결하지 못했을 때 짜증 난 고객이 어디로 가게 될지를 결정합니다. 잘못된 전환(Handoff)은 '1차 라인(First line)에서의 비용 절감'을 고객 이탈과 반복적인 문의 증가로 변질시킵니다.
녹음(Recording)은 개인정보 보호 및 분쟁 사례 분석 문제를 해결합니다. 음성은 개인 데이터이자 잠재적으로 민감한 콘텐츠입니다. 마지막으로 처리 비용(Cost per interaction)이 모든 것을 마무리합니다. 만약 음성 인식(STT) 및 합성(TTS)을 포함한 음성 봇의 1분당 비용이 텍스트 채팅보다 비싸다면, 경제성은 청구서를 받은 후가 아니라 사전에 계산되어야 합니다.
실제 음성 채널은 어떻게 작동하는가?
릴리스 노트(Release note)가 침묵하고 있는 부분과 그럼에도 불구하고 당신이 직접 결정을 내려야 하는 부분이 어디인지 명확히 알 수 있도록 전형적인 통화 경로를 분석해 보겠습니다.
전화가 전화 시스템(Telephony)으로 들어옵니다. 음성이 텍스트로 인식(Speech-to-Text)됩니다. 텍스트는 의도(Intent)에 따라 분류됩니다. 에이전트는 ITSM 내에서 답변하고 작업을 수행하거나, 사람(상담원)에게 전달합니다. 대화는 녹음됩니다. 각 단계마다 고유한 실패 요인이 존재합니다: 제대로 듣지 못함, 의도를 이해하지 못함, 식별 실패, 전달할 대상 없음 등입니다. 릴리스 노트는 에이전트의 존재 여부는 설명하지만, 이러한 각 노드(Node)에서의 동작을 보장하지는 않습니다. 이 부분은 당신이 파일럿 프로젝트를 통해 직접 해결해야 합니다.

식별(Identification): 누가 전화했으며, 무엇을 허용할 수 있는가?
음성 자체는 스스로를 식별하지 못합니다. 발신자 번호는 취약한 신호입니다. 번호를 위조할 수 있고, 동료가 해당 번호로 전화할 수도 있으며, 여러 사람이 하나의 번호를 사용할 수도 있습니다. 따라서 첫 번째 프로젝트 결정 사항은 강력한 검증 없이 어떤 동작을 허용할 것인가입니다.
합리적인 최소 기준은 다음과 같습니다. 신뢰할 수 있는 식별 없이는 에이전트가 문의 사항을 등록하고 이미 알려진 인시던트(Incident) 번호에 대한 상태를 전달하는 것만 허용합니다. 시스템 상태를 변경하거나 데이터를 공개하는 모든 작업은 기업용 메신저의 코드, 포털의 이미 인증된 세션을 통한 확인, 또는 확인된 연락처로의 전화와 같은 2차 인증(Second Factor)을 요구해야 합니다.
릴리스 노트(Release note)에는 음성 채널의 식별 메커니즘이 설명되어 있지 않으므로, "에이전트가 알아서 모두 확인할 것"이라고 맹신해서는 안 됩니다. 음성에 허용되는 작업 목록과 사람에게 에스컬레이션(Escalation)하거나 강력한 인증이 시작되는 명확한 경계선을 스스로 설계하십시오.
핸드오프(Handoff): 언제 봇이 사람에게 넘기며, 이를 어떻게 망가뜨리지 않을 것인가
핸드오프(Handoff)는 음성 ITSM에서 가장 비용이 많이 드는 지점입니다. 고객은 이미 봇에게 시간을 소비했습니다. 만약 문맥(Context)의 손실과 함께 전달이 이루어진다면, 고객은 모든 것을 처음부터 다시 반복해야 하며 분노는 두 배가 됩니다.
전달을 위한 세 가지 트리거를 설계하십시오. 첫 번째는 명시적 트리거로, 고객이 사람을 요청하는 경우입니다. 두 번째는 불확실성에 의한 트리거로, 분류 모델(Classification model)이 의도(Intent)를 확신하지 못하는 경우입니다. 세 번째는 작업 유형에 따른 트리거로, 민감하거나 정책에 맞지 않는 작업은 즉시 사람에게 전달됩니다. 전달 시 상담원은 빈 화면이 아니라 트랜스크립트(Transcript), 인식된 의도, 그리고 이미 생성된 티켓(Ticket)을 볼 수 있어야 합니다.
의도 분류 (Intent Classification) 로직은 전화 시스템 자체와 분리하여 순수하게 트랜스크립트 (Transcript)만으로 프로토타이핑하는 것이 편리합니다. 호환 가능한 하나의 API를 사용하면, 벤더 통합 비용을 지불하기 전에 동일한 텍스트를 다양한 모델에 통과시켜 어디에서 오탐 (False Positives)이 적은지 비교할 수 있습니다.
from openai import OpenAI
client = OpenAI(
...
이러한 테스트 과정이 ServiceNow를 대체하거나 음성 채널을 생성하는 것은 아닙니다. 이는 단지 봇이 대화를 사람에게 넘겨주어야 하는 임계값 (Threshold)을 사전에 파악하는 데 도움을 줄 뿐입니다.

음성 채널인가 텍스트 채널인가: 어떻게 선택할 것인가?
모든 서비스 데스크 (Service Desk)가 음성 채널을 통해 이득을 얻는 것은 아닙니다. 아래는 마케팅 약속이 아닌, 소스(Source)의 편집 관점 (Editorial Angle)에서 추출한 채널의 네 가지 속성에 기반한 결정적인 비교 표입니다. 이 표는 어디에 음성이 적절하고, 어디에 텍스트 채팅이 더 정직한지 빠르게 이해하는 데 도움을 줍니다.
| 기준 | 음성 에이전트 (Voice Agent) | 텍스트 에이전트 (Text Agent) |
|---|---|---|
| 식별 (Identification) | 전화번호 기반으로 취약함, 추가 인증 요소 필요 | 더 간편함: 포털에 이미 세션이 있는 경우가 많음 |
| ... |
표는 하나의 프레임워크일 뿐, 확정된 결론은 아닙니다. 만약 주요 유입 경로가 전화를 통해 이루어지고 사용자들이 물리적으로 타이핑하는 것을 불편해한다면, 비용에도 불구하고 음성 채널은 정당화됩니다. 반면, 문의가 이미 포털 채팅으로 들어오고 있다면, 단순히 릴리스 노트 (Release Note)에 이름을 올리기 위해 음성을 추가하는 것은 불필요한 지출입니다.
문의 한 건당 비용은 얼마이며, 비용은 어디에 숨어 있는가?
릴리스 노트 (Release Note)에는 가격이 명시되어 있지 않으므로, 발표 자료에 나오는 "1차 지원 단계에서 40% 절감"과 같은 문구는 소스에 명시된 사실이 아닙니다. 직접 계산해야 하며, 음성과 텍스트의 비용 구조는 다릅니다.
음성 채널에서는 최소 세 가지 항목에 대해 비용을 지불합니다: 음성 인식 (Speech Recognition), 언어 모델 (Language Model) 작동, 그리고 응답 합성 (Speech Synthesis)입니다. 여기에 전화 시스템, 녹음 저장, 그리고 상담원 전환 (Handoff) 시의 운영 비용을 더해야 합니다. 텍스트 에이전트는 인식이나 합성이 필요 없기 때문에 계층별 비용이 더 저렴합니다.

여기 프로토타입을 위한 인프라에 대한 솔직한 비교가 있습니다. 의도 분류 (Intent Classification) 및 대화 요약 (Summarization)을 위해 러시아에서 다양한 모델을 실행해야 한다면, 해외 카드 결제나 VPN 문제에 부딪히지 않는 것이 중요합니다. provod.ai는 루블화 잔액, 러시아 카드 결제, SBP(Fast Payment System) 또는 계좌 이체를 지원하며, 키와 base_url만 변경하면 OpenAI 및 Anthropic SDK와 호환되는 단일 API를 제공합니다. 이는 로직 프로토타이핑 단계에서 마찰을 줄여줍니다. 이것은 음성 채널이나 ServiceNow의 대체재가 아니라, 위 섹션에서 언급된 솔루션들을 자신의 트랜스크립트(Transcripts)로 저렴하게 테스트할 수 있는 방법입니다.
이 릴리스가 해결하지 못하는 것
근거 없는 계획을 세우지 않도록 솔직한 목록을 정리했습니다.
릴리스 노트(Release note)는 러시아어를 포함한 특정 언어 지원 여부를 확인해주지 않습니다. 사용 중인 언어와 억양에 대해 음성 인식 (ASR) 및 합성 (TTS) 성능을 별도로 확인해야 합니다.
전화 통합 (Telephone integration) 및 지역적 가용성에 대해 설명하지 않습니다. 기능이 스위트 (Suite)에 포함되어 있다고 해서, 귀하의 요금제나 지역에서 사용 가능하다는 의미는 아닙니다.
인식 품질에 대한 수치를 제공하지 않습니다. 실제 통화 데이터를 통한 파일럿 테스트 없이는 의도 파악의 정확도나 잘못된 전환 (Handoff) 비율을 전혀 알 수 없습니다.
신원 확인 설계, 녹음 정책 및 오디오 저장에 관한 법적 측면을 대체하지 않습니다. 이 부분은 귀하의 책임입니다.
도구에 대해 별도로 언급하자면: provod.ai와 같은 모델 애그리게이터 (Model aggregator)는 ServiceNow, 자동화 플랫폼, 프라이빗 또는 온프레미스 (On-prem) 인프라, 그리고 구독을 통해서만 사용할 수 있는 벤더 기능을 대체할 수 없습니다. 또한 GigaChat를 제공하지도 않습니다. 이는 완성된 음성 지원 솔루션이 아니라, 로직 프로토타입 단계에서 유용한 도구입니다.

단계별 파일럿 계획
첫째. 100~200개의 실제 문의 트랜스크립트 (transcripts)를 확보하여 전화 연결 없이 오프라인으로 의도 분류 (intent classification)를 실행하십시오. 이를 통해 음성 채널에 투자하기 전 이해도의 한계를 확인할 수 있습니다.
둘째. 강력한 본인 확인 없이 음성으로 허용되는 작업 목록과 에스컬레이션 (escalation) 경계 지점을 정의하십시오. 이를 인터페이스 설정이 아닌 정책 (policy)으로 기록하십시오.
셋째. 세 가지 핸드오프 (handoff) 트리거를 설정하고, 상담사가 트랜스크립트, 의도, 티켓을 모두 전달받는지 확인하십시오.
넷째. 명확한 보관 정책과 발신자 고지를 포함하여 녹음을 활성화하십시오. 오디오는 개인정보 (personal data)입니다.
다섯째. 비용 도식의 모든 계층을 바탕으로 문의당 비용을 계산하고, 현재의 텍스트 채널과 비교하십시오. 결정은 릴리스 노트 (release note)가 아닌 파일럿의 수치를 바탕으로 내려야 합니다.
FAQ
2026년 7월 9일자 릴리스 노트가 러시아어 인식 품질을 보장하나요? 아니요. 해당 기록은 Now Assist for ITSM에 음성 에이전트가 존재함을 기록할 뿐, 지원 언어를 설명하지 않습니다. 별도로 확인하십시오.
음성 에이전트가 1차 지원(first-line support)을 대체할까요? 출처에 따르면 그렇지 않습니다. 음성은 핸드오프 (handoff)와 본인 확인이 설계되어 있고, 문의 비용이 계산된 곳에서 적절합니다.
발신 번호를 본인 확인 수단으로 신뢰할 수 있나요? 아니요, 이는 취약한 신호입니다. 민감한 작업에는 2차 인증 (second factor)이 필요합니다.
해당 기능의 작동에 대한 독립적인 데이터가 있나요? 출시 시점 기준으로 없습니다. r/servicenow 커뮤니티에서 AI Agents에 관한 웨비나를 진행하고 있지만, 이는 방향성에 대한 논의이지 측정 데이터는 아닙니다.
provod.ai가 음성 채널 구축 자체를 도와주나요? 아니요. 이 도구는 Claude, GPT, Gemini, DeepSeek, Qwen을 하나의 채팅으로 통합하여 로직 프로토타입을 위한 단일 API를 제공합니다. 이는 ServiceNow, 온프레미스 (on-prem), 그리고 구독형 벤더 기능을 대체하지 않으며 GigaChat을 제공하지도 않습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기