Gemini Live API 음성 에이전트 설계법: 3.8 Live와 Extended Thinking 선택 기준

구글은 2026년 9월 15일 Gemini API 릴리즈 노트에서 Gemini 3.8 Live와 Gemini 3.8 Live Extended Thinking을 일반 제공(GA)한다고 밝혔다. 둘 다 Live API 기반의 실시간 audio-to-audio 모델이다. 차이는 목적이다. 3.8 Live는 낮은 지연 시간의 실시간 대화에 맞고, Extended Thinking은 음성 상호작용 중에도 더 높은 수준의 배경 추론이 필요할 때 쓰는 모델이다.

음성 에이전트를 만들 때 흔한 실수는 “가장 똑똑한 모델 하나”로 모든 대화를 처리하려는 것이다. 실제 제품에서는 지연 시간, 비용, 말 끊김, 도구 호출, 안전한 fallback이 더 중요하다. 고객은 모델이 3초 더 깊게 생각한 사실보다, 대화가 끊기지 않는지를 먼저 느낀다.

두 모델의 역할을 분리하라

Gemini 3.8 Live는 기본 음성 대화용 모델로 보는 게 맞다. 낮은 지연 시간이 중요하고, 사용자가 말하는 동안 자연스럽게 반응해야 하는 인터페이스에 적합하다. 구글은 이 모델이 interleaved reasoning, 기본 비동기 함수 호출, 전체 session client content update를 지원한다고 설명한다.

반면 Gemini 3.8 Live Extended Thinking은 더 높은 배경 추론이 필요한 상황에 맞다. 예를 들어 사용자가 “지난 3개월 CRM 데이터를 보고 이 고객에게 어떤 제안을 해야 할지 말해줘”라고 요청한다면 단순 대화가 아니다. 데이터를 가져오고, 조건을 비교하고, 위험을 판단하고, 말로 설명해야 한다. 이런 작업은 약간의 지연을 감수하더라도 추론 품질이 중요하다.

즉 모델 선택 기준은 이렇게 잡을 수 있다.

• 일반 대화, 안내, 예약, 간단한 질의응답: Gemini 3.8 Live
• 복잡한 분석, 장기 문맥, 여러 도구 호출, 의사결정 보조: Gemini 3.8 Live Extended Thinking
• 아주 단순한 음성 명령 인식: 별도 STT + 텍스트 모델 조합도 검토

모든 음성 입력을 Extended Thinking으로 보내면 비용과 응답성이 나빠질 가능성이 크다.

음성 에이전트의 병목은 모델이 아니라 턴 관리다

텍스트 챗봇은 사용자가 엔터를 누르면 턴이 끝난다. 음성 에이전트는 다르다. 사용자가 잠깐 멈춘 것인지, 말을 끝낸 것인지, 중간에 끼어들었는지 판단해야 한다. 이 부분이 흔들리면 아무리 좋은 모델을 써도 UX가 나쁘다.

설계할 때는 다음 상태를 명확히 나눠야 한다.

1. listening: 사용자가 말하는 중
2. partial transcript: 중간 인식 결과가 들어오는 중
3. thinking: 모델 또는 도구가 처리 중
4. speaking: 에이전트가 말하는 중
5. interrupted: 사용자가 에이전트 말을 끊은 상태
6. recovering: 네트워크나 세션을 복구하는 상태

Live API를 쓴다고 이 상태 관리가 사라지지 않는다. 오히려 더 중요해진다. 음성 제품은 사용자가 “기다려”라고 말했을 때 실제로 멈춰야 하고, “아니 그게 아니라”라고 끼어들면 이전 답변을 중단해야 한다.

도구 호출은 비동기로 설계하라

Gemini 3.8 Live는 기본 비동기 함수 호출을 특징으로 한다. 음성 에이전트에서 이건 중요하다. 사용자가 “내 다음 회의 준비해줘”라고 말했을 때 캘린더, 문서, CRM, 메일을 순서대로 기다리면 침묵 시간이 길어진다.

좋은 설계는 사용자에게 진행 상태를 짧게 말하면서 도구 호출을 병렬 또는 단계적으로 처리하는 것이다.

예시 흐름은 이렇다.

• 사용자: “내일 김민수님 미팅 준비해줘.”
• 에이전트: “캘린더와 최근 메일을 같이 확인할게요.”
• 도구 호출: calendar.search, email.search 병렬 실행
• 에이전트: “내일 오후 2시 미팅이고, 최근 메일에는 가격 조정 얘기가 있네요. 관련 문서도 볼까요?”
• 사용자 승인 후 문서 검색 실행

여기서 중요한 것은 침묵을 줄이는 것이다. 실제 처리가 5초 걸려도 사용자가 시스템이 멈췄다고 느끼지 않게 만들어야 한다.

세션 업데이트와 복구를 먼저 설계하라

릴리즈 노트는 full session client content updates를 언급한다. 음성 에이전트에서는 세션 상태가 제품 품질에 직접 연결된다. 사용자가 모바일 네트워크를 오가거나, 브라우저 탭을 잠깐 백그라운드로 보내거나, 블루투스 마이크가 바뀌는 일이 흔하다.

따라서 세션 복구 정책을 미리 정해야 한다.

• 네트워크가 3초 끊기면 재연결을 시도한다.
• 10초 이상 끊기면 사용자에게 짧게 상태를 알린다.
• 복구 뒤 마지막 사용자 발화와 도구 호출 상태를 재확인한다.
• 결제, 예약, 삭제 같은 작업은 복구 뒤 다시 승인받는다.

음성 UX에서 가장 위험한 것은 복구 후 맥락이 꼬인 상태로 고위험 작업을 계속 진행하는 것이다. 대화는 자연스러워야 하지만, 권한 작업은 끊어서 확인해야 한다.

비용을 줄이는 라우팅 구조

음성 에이전트는 토큰 외에도 오디오 처리, 세션 유지, 도구 호출, 재시도 비용이 붙는다. 그래서 처음부터 라우팅 구조를 둬야 한다.

추천 구조는 3단계다.

1. 빠른 intent 분류: 요청이 단순 명령인지 복잡한 분석인지 판단
2. 실시간 대화 처리: 대부분은 Gemini 3.8 Live로 처리
3. 깊은 추론 전환: 복잡한 요청만 Extended Thinking으로 넘김

예를 들어 “불 꺼줘”, “오늘 일정 알려줘”, “방금 말 다시 설명해줘”는 기본 Live로 충분하다. “이 고객의 최근 사용량과 계약 조건을 보고 이탈 가능성을 판단해줘”는 Extended Thinking 후보다.

또 하나의 팁은 음성 원문 전체를 매번 장기 컨텍스트에 넣지 않는 것이다. 대화 중간 요약을 유지하고, 필요한 도구 결과만 구조화해서 넣는 편이 비용과 품질 모두에 좋다.

출시 전 체크리스트

• 기본 모델과 깊은 추론 모델을 분리했는가
• 사용자의 말 끊김, 침묵, 재질문 상태를 처리하는가
• 도구 호출 중 진행 상태를 짧게 알려 주는가
• 예약, 결제, 삭제, 발송 같은 작업은 재승인을 받는가
• 네트워크 복구 뒤 마지막 발화와 도구 상태를 검증하는가
• 음성 원문을 무작정 저장하지 않고 개인정보 정책을 정했는가
• 테스트 케이스에 “말을 끊는 사용자”와 “중간에 주제를 바꾸는 사용자”가 포함되어 있는가
• Extended Thinking 사용 조건과 비용 상한을 설정했는가

Gemini 3.8 Live 계열의 등장은 음성 에이전트를 더 쉽게 만들 수 있다는 뜻이다. 하지만 제품 품질은 모델 이름보다 상태 관리에서 갈린다. 낮은 지연 시간, 비동기 도구 호출, 안전한 재승인, 세션 복구를 먼저 설계하면 음성 AI가 데모를 넘어 실제 업무 도구가 된다.