Gemini 3.8 Live와 Gemini 3.8 Live Extended Thinking 중 무엇을 써야 할까? 짧은 음성 응답이 중심이라면 기본형부터, 여러 자료를 조사하거나 시간이 걸리는 도구를 조합해야 한다면 Extended Thinking부터 검토할 만하다. 다만 개발자에게 더 중요한 차이가 있다. Extended Thinking에서는 AI가 한 번 말을 마쳤다고 해서 전체 작업이 끝난 것은 아니다.
구글은 9월 15일 두 모델을 발표했고, 한국어 소개는 9월 16일 공개했다. 기본형은 비용 효율성과 자연스러운 실시간 대화에, Extended Thinking은 복잡한 다단계 추론에 초점을 맞췄다. 이번 글은 공식 발표와 API 문서를 읽고 정리한 선택 가이드다. 직접 수행한 성능 비교나 사용 후기는 아니다. 구글 한국어 발표
먼저, 어떤 대화를 만들려는가
영어 회화 연습 앱을 만든다고 해보자. 사용자가 한 문장 말하면 AI가 답하고, 바로 다음 문장을 주고받는다. 이런 서비스에서는 대답을 기다리는 시간이 대화의 리듬을 결정한다. 매번 깊게 생각하는 능력이 반드시 필요한 것은 아니다.
반대로 장애 대응 도우미라면 사정이 달라진다. “방금 배포한 뒤 결제가 실패한다”는 말을 듣고 배포 이력, 오류 로그, 결제 서비스 상태를 함께 살펴야 한다. 첫마디를 빨리 하는 것과 문제의 원인을 제대로 찾는 것은 서로 다른 일이다.
구글 문서의 구분을 개발 상황에 대입하면 다음과 같다.
| 판단할 항목 | Gemini 3.8 Live | Extended Thinking |
|---|---|---|
| 먼저 검토할 작업 | 빠른 문답, 직접적인 요청 | 여러 단계의 분석과 도구 조합 |
| 추론 수준 설정 | thinking_level 미지원 | low, medium, high 지원 |
| 도구 선언 | 동기·비동기 지원 | NON_BLOCKING 필요 |
| 완료 상태 처리 | turnComplete 중심 | interaction_status 별도 추적 |
이 차이는 Live API의 Thinking 문서에 명시돼 있다. 모델명만 바꾸고 기존 클라이언트를 그대로 두면 안 되는 이유이기도 하다.
둘 중 하나를 무조건 상위 모델로 정하기보다, 사용자가 기다리는 동안 어떤 일이 벌어져야 하는지부터 적어보면 선택이 쉬워진다. 기다릴 이유가 없는 짧은 문답에 복잡한 상태 관리를 추가할 필요는 적다. 반대로 조사 중인 서비스가 아무 설명 없이 조용해지면 사용자는 연결이 끊겼다고 생각할 수 있다.
“확인해볼게요” 다음에 앱이 멈추는 이유
Extended Thinking은 백그라운드에서 추론하거나 도구를 실행하면서 중간 안내를 말할 수 있다. 구글이 강조하는 변화는 작업을 기다리는 동안에도 대화를 이어갈 수 있다는 점이다. 구글 발표
그런데 앱이 “말이 끝났다”와 “요청이 끝났다”를 같은 상태로 취급하면 문제가 생긴다.
예를 들어 AI가 “배포 기록부터 확인할게요”라고 말한 직후 로딩 표시를 없앴다고 하자. 사용자는 결과가 오지 않는다고 느껴 같은 요청을 다시 보낼 수 있다. 화면에는 대기 중으로 보이지만, 뒤에서는 첫 번째 조회가 진행되고 있는 셈이다. 이것은 실제 제품에서 재현한 버그가 아니라, 잘못된 완료 처리로 생길 수 있는 상황을 설명한 예다.
공식 문서에서 Extended Thinking의 turnComplete: true는 개별 발화의 끝을 뜻한다. 전체 상호작용은 IN_PROGRESS와 IDLE로 구분한다. 따라서 화면에 보여줄 상태를 최소한 다음처럼 나눠 생각해야 한다.
- 지금 음성을 재생하고 있는가?
- 요청을 처리하는 중인가?
- 외부 시스템의 변경이 실제로 성공했는가?
마지막 질문은 모델의 상태값만으로 답할 수 없다. 가령 사용자가 예약 변경을 부탁했다면, AI가 대화를 끝냈는지와 예약 서버가 변경을 확정했는지는 별도로 확인해야 한다. 완료 안내는 서버의 성공 응답과 연결하는 편이 안전하다.
여기서 필요한 것은 더 화려한 음성 UI가 아니다. “말하는 중”, “확인 중”, “변경 완료”를 사용자가 헷갈리지 않도록 보여주는 작은 설계다.
처음 붙여본다면, 읽기 전용 작업부터
Live API는 음성·이미지·텍스트 스트림을 다루며, 백엔드를 거치는 연결과 클라이언트 직접 연결을 지원한다. 구글은 프로덕션의 클라이언트 직접 연결에서 일반 API 키 대신 임시 토큰 사용을 권장한다. 시작 경로는 공식 Live API 가이드에 정리돼 있다.
첫 실험으로는 실제 결제나 예약을 바꾸는 작업보다, 상태를 조회하는 작업이 적합하다. 다음은 필자가 제안하는 작은 평가 방법이다.
같은 질문을 두 모델에 주되, 외부 조회가 즉시 끝나는 경우와 몇 초 걸리는 경우를 준비한다. 그리고 일부 조회는 의도적으로 실패하게 만든다. 첫 응답까지 걸린 시간만 재면, 빨리 “확인하겠습니다”라고 말하는 모델이 좋아 보인다. 실제 결과까지 걸린 시간과 실패를 정확히 설명했는지도 함께 기록해야 한다.
사용자가 중간에 “아니, 어제 배포 말고 오늘 배포”라고 정정하는 상황도 넣어보자. 중요한 것은 답변의 유창함만이 아니다. 이전 조회 결과와 수정된 요청을 섞지 않는지, 끝난 작업과 진행 중인 작업을 화면에서 구분할 수 있는지가 제품 품질을 좌우한다.
한국어 서비스라면 한국어로 평가해야 한다. 영어 데모가 자연스럽다고 한국어 고객의 회사명, 제품명, 숫자 읽기까지 잘 처리한다고 볼 수는 없다. 특히 일반 음성 API 안내와 개별 모델 발표의 지원 범위가 다를 수 있으므로, 적용할 모델과 플랫폼 문서를 기준으로 확인해야 한다.
이번 발표를 보고 바로 Extended Thinking으로 교체할 필요는 없다. 기존 서비스가 짧은 문답을 잘 처리하고 있다면 그대로 기준점으로 남겨두자. 사용자가 실제로 기다리는 작업 하나를 골라 새 모델을 붙여보고, 대화가 이어지는 동안 결과도 정확히 도착하는지 확인하는 것부터면 충분하다.