01 / PROCESS

음성 인식과 기기 제어는 어떻게 연결될까

자동 음성 인식(Automatic Speech Recognition, ASR)은 소리를 문자로 바꾸는 기술이다. “거실 에어컨을 24도로 맞춰줘”라는 음성을 같은 내용의 문장으로 변환했다면 받아쓰기는 성공한 셈이다. 그러나 문장 안의 ‘거실 에어컨’이 실제로 어느 기기인지, ‘맞춰줘’가 어떤 기능을 뜻하는지는 추가로 해결해야 한다.

요청을 해석하는 과정에서는 사용자가 원하는 동작과 필요한 정보를 구분한다. 이 예시의 동작은 온도 설정이고, 대상은 거실 에어컨이며, 입력값은 24도다. 이어지는 실행 과정에서는 시스템에 등록된 기기를 찾고, 사용할 수 있는 제어 기능과 허용 범위를 확인한 뒤 명령을 보낸다. 마지막 응답은 이러한 실행의 결과에 근거해야 한다.

Home Assistant의 공식 개발 문서는 음성 파이프라인, 대화 처리, 의도 실행의 역할을 구분한다. 이 구분은 음성 제어를 이해하는 데 유용하지만 모든 제품에 동일한 모듈 구성을 요구하는 것은 아니다. 한 모델이 여러 역할을 함께 처리하더라도, 소리를 이해하는 문제와 외부 상태를 바꾸는 문제는 개념적으로 구분할 수 있다.[3]

이 구분은 오류를 찾을 때도 중요하다. 음성은 정확히 인식했는데 다른 방의 기기가 바뀌었다면 대상 연결의 문제일 수 있다. 올바른 명령을 만들었는데 기기가 오프라인이었다면 실행의 문제다. 결과를 확인하지 않고 성공했다고 답했다면 응답을 만드는 기준의 문제다. 이들을 모두 ‘음성 인식이 나빴다’고 설명하면 실제 원인을 놓치게 된다.

02 / ARCHITECTURE

음성 AI가 소리를 처리하는 방식

전체 과정을 이해했다면 첫 번째로 살펴볼 것은 소리가 시스템에 들어오는 방식이다. 음성의 문자 변환(Speech-to-Text, STT), 요청 처리, 문자의 음성 변환(Text-to-Speech, TTS)을 연결하는 연쇄형 구조가 있고, 실시간 모델이 음성을 입력받아 음성으로 출력하는 구조도 있다. OpenAI의 음성 에이전트 가이드는 이러한 구성 경로를 설명한다.[1]

연쇄형에서는 음성 인식 결과가 명시적인 문자로 다음 단계에 전달된다. 개발자는 잘못 들은 문장인지, 올바른 문장을 잘못 해석한 것인지 중간 결과를 보고 살펴볼 수 있다. 각 구성요소를 따로 선택하거나 교체할 수도 있다. 대신 여러 구성요소의 처리 시간과 데이터 전달이 전체 응답 시간에 영향을 줄 수 있다.

직접 음성 입출력형에서는 음성을 받아쓴 문장인 전사문이 외부 처리 흐름의 필수 입력으로 드러나지 않을 수 있다. 그렇다고 문자 정보가 어느 곳에서도 사용되지 않는다는 뜻은 아니다. 전사나 도구 호출 등 함께 제공하는 기능은 모델과 서비스에 따라 다르며, 내부 구현을 사용자 인터페이스만으로 단정할 수 없다.

전이중(Full-Duplex)은 동시에 듣고 말하는 통신·상호작용 특성이다. 이는 음성을 문자로 바꾸는지와 별개의 문제다. 음성 처리를 구성하는 방식과 대화 차례를 운영하는 방식을 나눠 살펴보면 비교가 명확해진다. 사용자 발화가 시작되면 기존 음성을 멈추는 방식과, 입력·출력을 동시에 처리하는 방식도 구현상 구분할 필요가 있다.

구조의 이름만으로 성능의 우열을 정할 수도 없다. 음성 응답이 빨리 시작되더라도 연결된 기기 제어가 오래 걸릴 수 있고, 모델 처리보다 네트워크 지연이 더 클 수도 있다. 비교할 때는 첫 응답이 나오는 시간과 실제 작업이 끝나는 시간을 분리해야 한다.

03 / TURN DETECTION

AI는 언제 사용자의 말이 끝났다고 판단할까

소리를 처리하는 기능만으로는 언제 요청을 실행해야 하는지 알 수 없다. 시스템은 먼저 어떤 발화를 자신에게 하는 요청으로 받을지, 언제까지 들어야 할지를 결정해야 한다. 깨우는 말(Wake Word)은 시스템을 호출하는 표현이다. 음성 활동 감지(Voice Activity Detection, VAD)는 입력된 소리에 말소리 활동이 있는지 판단한다. 발화 종료 판단(Turn Detection)은 사용자의 차례가 끝나 반응을 시작해도 되는지를 결정한다.[4]

침묵을 기준으로 종료를 판단하는 방식에서는 일정 시간 말소리가 없으면 사용자 차례가 끝났다고 볼 수 있다. 짧게 기다리면 반응이 빨라지는 대신 생각하는 동안의 쉼을 종료로 오인할 가능성이 생긴다. 오래 기다리면 사용자의 말을 더 받아들일 수 있지만 응답이 늦게 느껴질 수 있다. 발화 내용의 완결성을 고려하는 방식도 있으며, 지원 여부와 설정은 서비스에 따라 다르다.[6]

이 문제는 마이크의 음질만 높여서는 해결되지 않는다. 모든 단어를 정확히 들어도 사용자가 아직 말을 이어갈지 판단해야 하기 때문이다. 버튼을 누르고 말하는 방식에서는 버튼을 놓는 동작이 종료 신호가 될 수 있고, 대화형 시스템에서는 음향 정보와 발화 내용 등을 활용해 종료를 판단할 수 있다.

화면에 나온 받아쓰기가 확정된 결과는 아닐 수 있다

스트리밍 음성 인식은 문장이 끝나기 전에 부분 결과를 전달할 수 있다. Amazon Transcribe 문서는 뒤의 문맥이 추가되면서 이 결과가 수정될 수 있다고 설명한다. 빠르게 표시되는 문자와 최종적으로 판단에 사용할 문자를 구분해야 하는 이유다.[8]

예를 들어 “에어컨을 켜…”까지 보였는데 뒤에 “지 말아줘”가 이어지면 동작의 의미가 달라진다. 중간 결과로 관련 기기를 찾는 준비 작업과 상태를 실제로 바꾸는 실행은 영향이 다르다. 둘을 분리하는 것은 오류를 줄이기 위한 설계 방법이 될 수 있다. 다만 언제 실행을 허용할지는 작업의 성격과 구현에 따라 정해야 하며, 모든 음성 시스템에 하나의 대기 규칙을 적용할 수는 없다.

04 / INTENT AND TARGET

자연스러운 표현을 실행 가능한 요청으로 바꾸는 과정

요청을 처리할 시점이 정해지면 말의 내용을 실행에 필요한 정보로 바꿔야 한다. 요청의 의도(Intent)는 사용자가 수행하려는 동작이고, 슬롯(Slot)은 그 동작에 필요한 변수다. “거실 에어컨을 24도로 맞춰줘”에서 온도 설정은 의도에, 거실·에어컨·24도는 입력 정보에 해당한다. Alexa의 상호작용 모델도 의도와 슬롯을 구분하고 여러 표현을 같은 요청으로 연결한다.[13]

의도와 입력값을 다루는 기능은 생성형 AI 이전의 음성 시스템에도 존재했다. 생성형 모델을 활용하는 시스템에서는 요청과 이어지는 대화, 제공된 도구 설명 등을 함께 해석하도록 구성할 수 있다. 그러나 표현을 유연하게 이해하는 능력과 실행 정보를 충분히 확보하는 것은 다르다. “좀 시원하게 해줘”라는 말을 이해해도 어떤 기기를 사용할지, 어떤 상태를 목표로 할지는 남아 있다.

시스템이 값을 정하는 근거도 구분해야 한다. 사용자가 이번 문장에서 직접 말한 값인지, 앞선 대화에서 확인된 값인지, 사용자가 지정한 기본 설정인지, 모델이 추정한 값인지에 따라 확실성이 다르다. 불명확한 상태에서 실행하면 같은 문장에 서로 다른 결과가 나올 수 있다.

문장 안의 이름을 실제 환경의 대상으로 연결하는 것도 별도의 문제다. ‘거실 에어컨’이라는 말이 데이터에서 어떤 기기 식별자를 뜻하는지 알아야 한다. 기기 이름이 중복되거나 사용자가 별명을 쓰면 후보를 좁히는 과정이 필요하다. 문자열을 추출한 것만으로 대상 연결이 끝났다고 볼 수 없다.

확인 질문은 부족한 정보를 정확히 드러내는 방식으로 구성할 수 있다. “무엇을 원하시나요?”보다 “거실 에어컨과 침실 에어컨 중 어느 기기인가요?”가 사용자가 해결해야 할 모호성을 명확하게 보여준다. 이는 모든 명령에 확인 질문을 추가하라는 의미가 아니다. 요청과 환경에서 충분히 결정된 값까지 반복해서 묻는 것은 대화를 불필요하게 길게 만들 수 있다.

05 / FUNCTION CALLING

함수 호출은 실제 실행과 어떻게 이어질까

동작과 대상, 값이 구체화됐다고 기기가 곧바로 움직이는 것은 아니다. 이를 실제 기능에 연결하는 과정이 필요하다. 함수 호출(Function Calling)은 모델이 정의된 함수와 입력값을 선택해 외부 기능과 연결하는 방식이다. 도구 호출(Tool Calling)은 검색·조회·계산·실행 등 외부 기능을 사용하는 더 넓은 표현으로 쓰인다. Gemini의 공식 가이드에서는 애플리케이션이 함수의 이름·설명·입력 구조를 제공하고, 모델이 제안한 호출을 애플리케이션이 실행하며, 그 결과를 다시 모델에 전달한다.[2]

따라서 자연어를 이해하는 모델과 기기 제어 인터페이스(Application Programming Interface, API)를 호출하는 애플리케이션의 책임을 분리해서 봐야 한다. 모델이 ‘온도 설정’ 기능을 선택했다는 사실은 실제 기기의 온도가 바뀌었다는 사실이 아니다. 애플리케이션은 호출을 받아 자신의 실행 규칙에 따라 검사하고 전달해야 한다.

{
  "tool": "set_temperature",
  "arguments": {
    "device_id": "living_room_ac",
    "temperature": 24,
    "unit": "celsius"
  }
}

위 데이터는 역할을 설명하기 위한 가상 형식이다. 특정 업체의 SDK나 기기 API에 그대로 사용할 수 있는 코드가 아니다.

이 명령에는 세 가지 중요한 값이 담겨 있다. 기기 식별자는 실행 대상을, 온도는 목표 설정값을, 단위는 숫자의 해석 방법을 정한다. 설명에 필요한 정보가 분리돼 있으므로 애플리케이션은 누락된 항목이나 잘못된 자료형을 검사할 수 있다. 그러나 형식이 맞는 것만으로 실제 환경에서 유효한 요청이 되지는 않는다.

구조화 출력(Structured Output)은 정해진 데이터 형식에 맞는 결과를 얻는 데 쓰인다. 예를 들어 온도를 숫자로 받고 기기 식별자를 문자열로 받도록 정의할 수 있다.[14] 그와 별개로 해당 식별자의 기기가 존재하는지, 온도 설정을 지원하는지, 값이 허용 범위에 있는지, 사용자가 실행할 권한이 있는지는 애플리케이션의 데이터와 규칙으로 확인해야 한다.

모델에 어떤 기능을 제공하는지도 해석에 영향을 준다. 읽기 전용 조회와 상태를 바꾸는 실행을 명확하게 구분하고, 필요한 입력값과 기능의 의미를 설명해야 한다. 이름만 다른 비슷한 기능이 많으면 선택이 모호해질 수 있다. 여기서 설명하는 검증은 실행 연결의 문제이며, 실행 환경 자체의 격리 원리는 AI 에이전트 샌드박스 글에서 따로 다룬다.

06 / RESULT VERIFICATION

명령을 보낸 뒤 무엇을 확인해야 할까

명령을 전달한 다음에는 결과를 해석해야 한다. 서버가 요청을 받았다는 응답, 실행이 완료됐다는 응답, 기기의 상태를 조회한 결과는 의미가 다를 수 있다. 예를 들어 비동기 작업에서는 요청을 먼저 접수하고 실제 처리를 나중에 수행할 수 있다. 이때 접수 응답을 완료로 해석하면 사용자가 듣는 안내와 기기의 상태 사이에 차이가 생긴다.

성공 조건도 요청에 맞게 정해야 한다. 에어컨 설정을 바꾸는 작업이라면 설정값의 변경이 조건이 될 수 있고, 특정 실내 온도에 도달했는지 묻는 요청이라면 온도 측정값이 필요하다. 무엇을 확인할지 정하기 전에 단순히 ‘성공’이라는 상태만 붙이면 서로 다른 결과를 같은 의미로 취급하게 된다.

Home Assistant의 대화 API는 작업 완료·조회 응답·오류를 구분하며, 요청의 성공 대상과 실패 대상을 표현할 수 있다.[5] 이를 통해 여러 기기를 함께 제어할 때 전체 성공과 일부 성공을 나눠 이해할 수 있다. 아래 표는 원리 설명을 위한 결과 분류이며, 모든 API가 사용하는 공통 상태 코드는 아니다.

에어컨 예시에서는 설정 온도와 현재 실내 온도를 구분해야 한다. 설정값이 24도로 바뀌었다고 해서 방이 이미 24도가 된 것은 아니다. 앞의 결과는 제어 설정의 변경이고, 뒤의 결과는 물리적인 환경의 변화다. “24도로 설정했어요”와 “방 온도가 24도예요”는 서로 다른 확인 근거가 필요한 문장이다.

상태 정보가 어디에서 오는지도 중요하다. Google Home의 Report State는 연동 시스템이 기기의 상태를 보고해 저장된 정보를 갱신하는 구조이며, 보고한 상태와 조회한 상태 사이의 불일치를 다룬다.[12] 저장된 상태를 활용하는 시스템에서는 정보의 최신성과 갱신 실패가 결과 해석에 영향을 줄 수 있다.

이를 종합하면, 상태 조회를 한 번 추가했다고 모든 결과가 완전히 검증되는 것은 아니다. 조회 정보가 명령의 접수 상태인지, 기기가 보고한 설정값인지, 별도 센서가 측정한 물리 상태인지 구분해야 한다. 시스템은 확인하지 못한 사실까지 완료 응답에 포함하지 않도록 구성해야 한다.

실행 과정을 화면에 전달하는 방법과 결과 자체의 의미도 구별된다. AG-UI 같은 상호작용 규격으로 진행 상황을 표시하더라도, 실제 기기가 동작했는지 판단하는 근거는 연결된 실행 시스템에서 마련해야 한다.

07 / INTERRUPTION AND RETRY

말을 정정하거나 취소하면 어떻게 될까

사용자는 AI가 답하는 동안 말을 끊거나 요청을 바꿀 수 있다. 실시간 음성 시스템은 이러한 끼어들기(Barge-In)를 처리하면서 진행 중인 음성 응답을 중단할 수 있다. OpenAI의 실시간 대화 문서는 응답 취소와 사용자가 듣지 않은 음성 부분을 대화 기록에서 처리하는 방식을 설명한다.[7]

하지만 음성 출력과 외부 작업은 서로 다른 흐름이다. 다음 구분은 응답 취소 기능과 외부 실행 구조를 연결한 설계상의 해석이다. AI가 말을 멈춘 것만으로 이미 기기에 전달한 명령이 자동으로 취소되거나 되돌아간다고 볼 수는 없다.

“24도로 맞춰줘” 뒤에 “아니, 26도로”가 이어지면 어떤 요청이 이미 실행됐는지 알아야 한다. 첫 명령을 아직 보내지 않았다면 새 값으로 대체할 수 있지만, 이미 보냈다면 두 번째 명령의 실행 순서와 결과를 관리해야 한다. 정정된 문장을 대화 기록에 반영하는 일과 기기의 최종 상태를 맞추는 일은 함께 해결해야 한다.

두 요청을 동시에 처리하는 구현에서는 나중에 도착한 결과가 사용자의 마지막 의도와 같은지도 확인해야 한다. 새 명령을 보냈다는 사실만으로 오래된 작업의 영향을 제거할 수는 없다. 작업마다 식별자와 상태를 연결해 두면 어떤 요청의 응답인지 구분할 수 있고, 순차 처리나 이전 요청 취소 같은 정책을 해당 기능의 특성에 맞춰 적용할 수 있다.

응답을 받지 못했다고 실행되지 않은 것은 아니다

연결이 끊기거나 시간 초과가 발생하면 시스템은 작업 결과를 모를 수 있다. 명령이 서버에 도달하지 않았을 수도 있지만, 기기가 동작한 뒤 응답만 유실됐을 수도 있다. 이 상태에서 같은 명령을 다시 보내면 중복 실행이 발생할 가능성이 있다.

멱등성(Idempotency)은 같은 작업을 반복해도 정의된 효과가 반복해서 추가되지 않는 성질이다. Stripe는 동일 요청의 재시도를 식별하는 멱등성 키를 제공해 중복 작업을 방지하는 실제 API 사례를 보여준다.[11] 기기 제어에도 중복 방지와 재시도 설계가 중요하지만, Stripe의 기능이 모든 기기 API에 제공되는 것은 아니다.

“24도로 설정”과 “2도 내려”를 비교하면 차이가 보인다. 후자를 두 번 실행하면 설정값이 누적해서 바뀔 수 있다. 같은 값으로 설정하는 명령도 부수효과까지 모두 안전하게 반복된다고 단정할 수는 없다. 재시도 여부는 요청 식별자, 처리 기록, 현재 상태와 해당 API의 동작 계약을 함께 보고 결정해야 한다.

08 / LOCAL AND CLOUD

온디바이스와 클라우드는 어디에서 나뉠까

온디바이스(On-Device)는 해당 처리를 기기 안에서 수행한다는 의미다. 그러나 마이크가 기기에 붙어 있거나 호출어를 기기에서 감지한다는 사실만으로 전체 음성 AI가 로컬에서 작동한다고 볼 수 없다. 음성 입력부터 실제 기기 제어까지 각 단계의 처리 위치를 살펴봐야 한다.

Home Assistant는 음성 인식·대화 처리·음성 합성 등을 로컬로 구성하는 경로를 안내한다.[9] 여기서 로컬 처리는 반드시 작은 기기 하나 안에서 모든 기능을 수행한다는 뜻은 아니다. 집 안의 다른 서버를 활용하는 구성도 로컬 환경에 포함될 수 있다. 기기 내부 처리와 로컬 네트워크 처리를 구분하면 데이터 이동 경로를 더 정확히 이해할 수 있다.

표는 단계별 조합을 설명하기 위한 예시이며, 특정 제품의 실제 구성이나 권장 구성을 뜻하지 않는다.

인터넷 없이 작동하는 범위도 같은 방식으로 판단할 수 있다. 음성을 로컬에서 인식해도 기기 제어가 제조사 클라우드에 의존하면 연결이 끊긴 상태에서 해당 작업을 수행하지 못할 수 있다. 반대로 기기 제어가 로컬이어도 외부 정보를 조회하는 요청은 인터넷이 필요할 수 있다.

처리 위치를 비교할 때는 연결 의존성, 지연, 지원 기능, 필요한 자원, 데이터 이동을 함께 살펴봐야 한다. 로컬이라는 단어만으로 모든 데이터가 저장되지 않는다거나 보안 문제가 없다고 결론 내릴 수는 없다. 보관·전송·접근 정책은 실제 구현과 서비스 정책에 따라 확인해야 한다.

09 / EVALUATION

음성 AI의 품질은 무엇으로 평가할까

음성 AI의 품질은 받아쓰기 정확도와 작업 수행 품질을 나눠 평가해야 한다. 단어 오류율(Word Error Rate, WER)은 기준 문장에 비해 대체·삭제·삽입된 단어 수를 기준 문장의 단어 수로 나눈 값이다. AWS의 음성 인식 설명도 이 정의와 함께 입력 조건에 따른 인식의 차이를 다룬다.[10]

하지만 단어 오류의 개수가 같아도 작업에 미치는 영향은 다를 수 있다. ‘거실’을 ‘침실’로 인식한 오류는 대상 기기를 바꾼다. 숫자나 부정 표현을 틀리면 설정값이나 실행 여부가 달라질 수 있다. 반면 표현이 달라도 요청의 의미가 유지되는 경우도 있다. 받아쓰기 점수만으로 기기 제어의 성공률을 대신할 수 없는 이유다.

아래 표는 음성 제어의 품질을 나눠 살펴보기 위한 평가 항목이다. 특정 서비스의 공식 종합 점수나 모든 시스템에 적용되는 합격 기준은 아니다. 실제 측정에서는 성공의 정의, 비교 조건, 실패의 분류를 먼저 정해야 한다.

시간을 측정할 때도 기준점을 통일해야 한다. 사용자가 말을 시작한 시점부터 재는지, 말을 마친 시점부터 재는지에 따라 같은 시스템의 수치가 달라진다. 첫 음성 응답이 접수 안내인지 실제 완료 안내인지도 구분해야 한다. 하나의 ‘응답 속도’ 수치로 모든 상호작용을 비교하면 빠른 안내와 빠른 실행을 혼동할 수 있다.

평가용 요청에는 명확한 문장뿐 아니라 자기 정정, 생략된 대상, 여러 기기, 오프라인 상태, 응답 유실 같은 조건도 포함할 수 있다. 같은 시나리오를 반복하면 우연히 성공한 사례와 일관되게 처리되는 동작을 구분하는 데 도움이 된다. 한국어 받아쓰기를 비교할 때는 띄어쓰기와 숫자 표기 등 전처리 기준도 일정하게 맞춰야 한다.

FAQ / 자주 묻는 질문

음성 AI 기기 제어에 관한 질문

음성 AI는 어떻게 기기를 제어하나요?

음성 요청을 동작·대상·입력값으로 구체화하고, 연결된 애플리케이션이 기기 기능을 호출한다. 이후 실행 응답이나 상태 정보를 바탕으로 확인된 결과를 사용자에게 전달한다. 구체적인 처리 구조는 서비스에 따라 다르다.

음성 인식이 정확하면 기기 제어도 정확한가요?

정확한 받아쓰기는 전체 과정의 일부다. 대상 연결, 입력값 검증, 실행, 결과 확인 중 어느 단계에서도 오류가 생길 수 있다. 인식 정확도와 실제 작업 성공을 따로 평가해야 한다.

모든 음성 AI가 먼저 음성을 문자로 바꾸나요?

문자 변환을 거쳐 요청을 처리하는 연쇄형과 음성을 직접 입출력하는 구조가 있다. 별도의 전사문이 모든 시스템의 필수 중간 입력인 것은 아니다.

함수 호출은 모델이 기기를 직접 움직인다는 뜻인가요?

대표적인 함수 호출 구조에서는 모델이 함수와 인자를 제안하고 애플리케이션이 실제 실행을 담당한다. 호출 정보 생성과 실행 성공은 별도로 확인해야 한다.

“취소해”라고 말하면 이미 실행한 작업이 되돌아가나요?

음성 응답 중단과 작업의 취소·되돌리기는 다르다. 작업이 어느 단계에 있는지와 연결 기능이 취소나 복원을 지원하는지에 따라 결과가 달라진다.

온디바이스 음성 AI는 인터넷 없이 모든 기능을 사용할 수 있나요?

전체 처리 경로에 따라 다르다. 음성 인식이 로컬이어도 기기 제어나 외부 정보 조회가 클라우드에 의존할 수 있다. 단계별 처리 위치와 연결 의존성을 확인해야 한다.

GLOSSARY / 용어집

본문의 주요 용어

자동 음성 인식(Automatic Speech Recognition, ASR)

입력된 소리에서 말의 내용을 인식해 문자로 표현하는 기술.

음성의 문자 변환(Speech-to-Text, STT)

음성을 문자로 바꾸는 기능을 가리키는 표현. 본문에서는 연쇄형 시스템의 입력 변환 단계에 사용한다.

문자의 음성 변환(Text-to-Speech, TTS)

문자로 작성된 응답을 재생할 수 있는 음성으로 만드는 기능.

음성 활동 감지(Voice Activity Detection, VAD)

입력된 오디오에 말소리 활동이 있는지 판단하는 기술.

발화 종료 판단(Turn Detection)

사용자의 말이 끝나 시스템이 다음 반응을 시작할 수 있는지 판단하는 과정.

전이중(Full-Duplex)

입력과 출력을 동시에 처리하는 특성. 음성 시스템에서는 동시에 듣고 말하는 동작과 관련된다.

의도(Intent)와 슬롯(Slot)

의도는 사용자가 원하는 동작이고, 슬롯은 동작에 필요한 대상·장소·수치 등의 변수.

함수 호출(Function Calling)

정의된 함수와 입력값을 모델이 선택·제안해 애플리케이션의 외부 기능에 연결하는 방식.

구조화 출력(Structured Output)

미리 정한 데이터 형식에 맞춰 출력하는 방식. 실제 기기의 존재나 실행 가능 여부는 별도로 검증해야 한다.

끼어들기(Barge-In)

시스템이 응답하는 동안 사용자가 새 발화를 시작하는 상황과 그 처리.

멱등성(Idempotency)

같은 작업을 반복해도 정의된 효과가 반복해서 추가되지 않는 성질. 재시도와 중복 실행을 다룰 때 중요하다.

온디바이스(On-Device)

해당 처리를 기기 내부에서 수행하는 방식. 시스템 전체의 처리 위치는 단계별로 확인해야 한다.

REFERENCES / 참고 자료

공식 문서와 관련 읽을거리

각 문서는 해당 서비스의 구조를 설명하는 1차 자료다. 사례의 세부 기능을 모든 음성 AI의 공통 기능으로 일반화하지 않는다. 취소·검증·평가에 관한 일부 설명은 문서의 구조를 연결한 기술적 해석이며, 본문의 표와 가상 사례는 이해를 돕기 위한 종합 설명이다.

1. OpenAI — Voice agents
   음성 에이전트의 구성 경로와 시스템 설계.
2. Google — Gemini Function calling
   함수 정의, 모델의 호출 제안, 애플리케이션 실행과 결과 전달.
3. Home Assistant — Voice overview
   음성 파이프라인·대화 처리·의도 실행의 역할.
4. Home Assistant — Assist pipelines
   호출과 음성 처리 단계 및 이벤트.
5. Home Assistant — Conversation API
   작업·조회·오류 응답과 성공·실패 대상.
6. OpenAI — Voice activity detection
   침묵 및 발화 내용을 고려하는 종료 판단.
7. OpenAI — Realtime conversations
   끼어들기, 응답 취소와 음성 재생 기록 처리.
8. AWS — Streaming and partial results
   부분 인식 결과의 수정과 안정화.
9. Home Assistant — Local voice assistant
   로컬 음성 처리 구성과 구성요소 선택.
10. AWS — Transcribe responsible AI service card
    단어 오류율과 음성 인식의 평가 조건.
11. Stripe — Idempotent requests
    멱등성 키를 통한 재시도와 중복 작업 방지의 API 사례.
12. Google Home — Report State
    기기 상태 보고와 조회, 상태 불일치.
13. Amazon Alexa — Voice interaction models
    의도·슬롯과 다양한 발화의 연결.
14. Google — Structured outputs
    정해진 데이터 형식의 출력.

함께 읽기: AG-UI란? AI Agent와 사용자 화면이 통신하는 원리와 구조 · AI 에이전트 샌드박스란? 실행 권한을 격리하는 보안 기술