Microsoft 실시간 음성 AI 3종: 빠른 전사와 빠른 대답은 다른 문제다

Microsoft는 10월 1일 MAI-Transcribe-2-Streaming, MAI-Voice-2.1, MAI-Voice-2.1-Flash를 발표했다. 첫 모델은 음성을 실시간으로 글로 옮기는 전사에, 나머지 두 모델은 텍스트를 음성으로 만드는 작업에 쓰인다. 회사는 이 조합을 대화형 음성 에이전트의 구성 요소로 소개했다. 세 이름이 비슷해도 입력과 출력, 과금 단위까지 같은 제품은 아니다.

한국어 독자가 먼저 구분할 질문은 자막을 빨리 보고 싶은지, 대답을 빨리 듣고 싶은지다. 강의 자막에서는 전사 결과가 화면에 나타나는 시점이 중요하다. 상담 에이전트라면 말을 이해한 뒤 자료를 조회하고 답을 결정하는 시간도 포함된다. 전사 모델의 속도만 보고 전체 상담이 그만큼 빨라졌다고 계산하면 중간의 다른 단계를 놓치게 된다.

공식 스트리밍 안내는 연속 음성을 보내면 말하는 동안 점진적으로 전사 결과를 받는 방식이라고 설명한다. 중간 결과는 현재 내용을 갱신하고, 최종 결과는 각 구간을 확정한다. Realtime API 방식과 Azure Speech SDK 방식이 안내돼 있다. 따라서 처음 표시된 단어와 확정된 문장을 동일한 상태의 자료로 처리해서는 안 된다.

가상의 예약 통화에서 사용자가 날짜를 말하다가 바로 정정하는 장면을 생각해 보자. 중간 결과로 일정을 검색하는 준비는 할 수 있어도, 첫 날짜를 들은 순간 예약을 확정하면 뒤의 정정이 반영되지 않을 수 있다. 실제 서비스에서는 내용을 미리 준비하는 단계와 외부에 영향을 주는 실행 단계를 분리하는 설계가 필요하다. 이 예시는 제품을 직접 시험한 사례가 아니라 동작 방식을 설명하기 위한 가정이다.

화면에 중간 자막을 표시하는 방식도 읽기 경험을 바꾼다. 단어가 자주 바뀌면 지연이 짧아도 사용자가 문장을 따라가기 어려울 수 있다. 반대로 모든 결과를 늦게 확정하면 수업이나 회의 흐름을 놓치기 쉽다. 중간 결과의 갱신과 확정 결과의 표시를 구분하고, 실제 독자가 내용을 이해하는지를 함께 확인하는 것이 단순한 시간 측정보다 유용하다.

MAI-Voice 공식 문서에는 ko-KR 음성이 있으며 MAI-Voice-2.1과 MAI-Voice-2.1-Flash를 지원 대상으로 표시한다. Haena, Junho 등의 한국어 음성도 나열돼 있다. 다만 한국어 음성 지원과 한국 계정의 배포 가능 지역은 별개다. 실제 업무 문장의 발음과 자연스러움도 직접 들어 보고 판단해야 한다.

한국어 서비스를 준비한다면 음성이 존재하는지 다음으로 실제 문장을 읽혀 볼 필요가 있다. 회사명, 영문 약어, 제품 번호, 단위가 들어간 금액 등은 일반적인 인사말과 다른 난도를 가질 수 있다. 같은 문장에서도 어색한 끊김이나 강조가 의미를 바꿀 수 있으므로 정답 문장을 눈으로 확인하는 것만으로 충분하지 않다. 최종 이용자가 듣는 상황에서 검토하는 절차가 필요하다.

전사와 음성 생성의 평가 자료는 따로 만드는 편이 좋다. 전사는 실제로 말한 내용을 정확히 옮겼는지 확인하고, 생성은 의도한 내용을 듣는 사람이 올바르게 이해하는지 확인한다. 둘을 한 번에 묶어 시험하다 실패하면 어느 단계의 문제인지 찾기 어렵다. 먼저 각 구성 요소를 확인한 뒤 전체 대화를 시험하면 수정해야 할 지점을 더 명확하게 찾을 수 있다.

발표된 스트리밍 전사 출시 가격은 음성 1시간당 0.54달러이며 연말까지 적용되는 조건이다. 음성 생성은 MAI-Voice-2.1이 100만 문자당 22달러, Flash가 15달러로 소개됐다. 이 가격은 미국 달러 기준으로 발표된 단가다. 전사의 시간과 생성의 문자 수를 같은 축에 놓아 더 저렴한 모델 순위를 만들 수는 없다.

가상의 예산 계산에서 스트리밍 전사만 10시간 사용했다면 발표 단가로 5.40달러다. 하지만 이것이 10시간짜리 양방향 상담 서비스의 전체 비용은 아니다. 답변을 만드는 언어 모델, 음성 생성, 다른 시스템을 조회하는 과정이 추가될 수 있다. 이 계산은 단가를 이해하기 위한 예시이며 실제 사용량을 측정하거나 서비스를 실행한 결과가 아니다.

음성 생성 비용을 음성 길이로 바꾸고 싶어도 문자 수와 말하는 시간의 비율을 임의로 고정해서는 안 된다. 언어와 문장, 읽는 속도에 따라 달라지기 때문이다. 운영 전 예상 대본의 분량을 확인하고, 실제 과금에 집계되는 단위를 공급자의 최신 문서에서 확인하는 것이 낫다. 서로 다른 과금 단위를 합칠 때는 먼저 서비스 한 건이 어떤 처리를 거치는지부터 정리해야 한다.

Microsoft Learn은 MAI-Transcribe-2-Streaming을 공개 미리보기로 안내한다. 서비스 수준 계약인 SLA 없이 제공되며 운영 환경의 작업에는 권장하지 않는다고 설명한다. 기능을 시험해 볼 수 있다는 것과 안정적인 상용 운영을 보장한다는 것은 다른 조건이다.

팀이 이 단계에서 할 수 있는 일은 제한된 시험으로 가능성과 실패 조건을 파악하는 것이다. 연결이 끊겼을 때 화면이 어떻게 보이는지, 중간 결과가 끝내 확정되지 않으면 어떻게 처리하는지, 작업을 다시 시작했을 때 중복 기록이 생기는지 확인할 수 있다. 평소 잘 되는 짧은 문장만 시험하면 서비스 이용 중 생기는 장애를 놓치기 쉽다.

사람에게 넘기는 경로도 시험할 필요가 있다. 음성을 잘못 알아들었을 때 사용자가 다시 말하거나 내용을 수정할 수 있어야 하고, 반복 실패 시에는 다른 입력 수단으로 이어질 수 있어야 한다. 사용자는 전사 엔진의 이름보다 자신의 요청이 정확히 전달되는지를 경험한다. 따라서 실패를 처리하는 방식은 주변 기능이 아니라 전체 대화 품질의 일부다.

Microsoft 발표는 중간 전사, 최종 전사, 음성 생성에 관한 속도와 평가 결과를 제시한다. 다만 이번 취재에서는 해당 수치를 독립적으로 재현하지 않았고 동일 조건의 전체 대화 비교도 하지 않았다. 따라서 회사가 제시한 부분 지연 수치를 한국 사용자의 종단 간 응답 시간으로 제시하거나 경쟁 제품 전체의 순위를 만들지 않았다.

측정 계획에서는 시작과 끝을 구체적으로 정해야 한다. 사용자가 말을 시작한 시점부터 첫 자막까지인지, 말을 마친 시점부터 첫 답변 소리까지인지, 최종 답변이 끝날 때까지인지에 따라 숫자의 의미가 달라진다. 네트워크와 내부 자료 조회 시간이 포함되는지도 적어야 한다. 이 기준이 없으면 서로 다른 단계의 빠른 숫자를 모아 실제로 경험할 수 없는 속도를 만들게 된다.

평균만 보는 것보다 이용자가 특히 오래 기다린 경우도 살피는 편이 좋다. 대화에서는 가끔 발생하는 긴 침묵이 인상에 큰 영향을 줄 수 있기 때문이다. 또한 사용자가 말을 끊었을 때 기존 응답이 계속 나오는지, 새 요청을 반영하는지처럼 시간 하나로 표현하기 어려운 동작도 있다. 수치 기록과 함께 짧은 실패 사례를 남기면 개선해야 할 경험을 더 잘 설명할 수 있다.

짧은 음성 파일에서 잘 되는 결과가 긴 대화에서도 같은 방식으로 유지되는지는 따로 살펴야 한다. 중간에 연결이 끊기거나 사용자가 오래 침묵했을 때 기록이 이어지는지, 다시 연결한 음성이 앞선 내용과 중복되는지 확인할 수 있다. 서비스 화면에는 현재 듣고 있는 상태와 처리를 기다리는 상태가 구분돼야 사용자가 같은 말을 불필요하게 반복하는 일을 줄일 수 있다.

중간 결과가 수정될 때마다 내용을 누적 저장하면 같은 발화를 여러 문장으로 남길 수 있다. 반대로 최신 중간 결과로 모든 기록을 덮으면 앞서 확정된 문장이 사라질 수 있다. 전사 결과가 임시인지 확정인지 구분하는 규칙은 자막 화면뿐 아니라 저장 과정에도 필요하다. 이 설계는 모델의 정확도 순위와 별개로 제품이 올바른 기록을 만드는 데 영향을 준다.

사용자가 음성 대신 글로 정정했을 때 처리도 정해 둘 수 있다. 상담 중 읽힌 주소나 상품명이 틀렸다면 사용자가 직접 입력한 내용을 이후 답변의 기준으로 삼아야 한다. 같은 대화 안에 음성 인식 결과와 사용자의 수정이 함께 남을 때 어느 쪽이 최신 확정 정보인지 알아볼 수 있어야 한다. 평가 자료에도 이런 교차 입력 상황을 넣으면 단순 낭독 시험에서 보이지 않는 문제를 찾을 수 있다.

음성 선택에는 발음 외의 운영 요소도 있다. 안내 문구가 바뀌었을 때 기존 음성과 새로 생성한 음성이 어색하게 이어지는지, 짧은 알림과 긴 설명에 같은 말투가 적절한지를 들어 볼 수 있다. 이는 특정 음성이 더 우수하다는 일반 순위를 매기는 작업이 아니다. 서비스가 전달하려는 내용과 청취 환경에서 이해하기 쉬운지 확인하는 편집 과정이다.

시험 기록에는 원문, 전사 결과, 수정 사항을 연결해 남기되 평가에 꼭 필요한 자료만 사용하는 편이 좋다. 실제 고객 대화를 쓰기 전에 가상의 업무 문장으로 설계 오류를 먼저 찾을 수 있다. 이런 자료로 확인 가능한 문제와 실제 환경에서만 드러나는 문제를 구분하면 평가의 범위도 명확해진다. 최종 도입 판단에서는 어떤 조건을 시험했고 어떤 조건은 아직 남았는지 함께 설명해야 한다.

개발자는 한국어 숫자, 고유명사, 배경 소음, 말 고침을 포함한 작은 평가 묶음을 준비할 수 있다. 업무 특성에 따라 어떤 오류가 허용되지 않는지도 정해야 한다. 회의 초안의 띄어쓰기 오류와 주문 수량을 바꾸는 오류는 같은 중요도로 다루기 어렵다. 기술적으로 인식한 단어 비율과 업무에서 잘못된 행동을 일으키는지라는 기준을 나누어 보면 도입 판단이 구체화된다.

이번 발표가 보여 주는 변화는 실시간 대화를 구성하는 듣기와 말하기 도구가 함께 확장됐다는 점이다. 그러나 자연스러운 서비스는 모델 두 개를 연결했다는 사실만으로 완성되지 않는다. 잠정 내용을 언제 믿을지, 답을 언제 실행할지, 실패했을 때 어떻게 사람에게 돌려줄지가 남는다. 한국 이용 조건과 실제 대화 품질을 함께 확인해야 발표된 속도가 자신의 서비스에서 어떤 의미인지 알 수 있다.