결론 먼저 — 음성 상담에서 latency는 품질이다
| 축 | Pro 계열 | Flash 계열 |
|---|---|---|
| 응답 latency (체감) | 높음 | 낮음 |
| 긴 문맥 (32k+) 추론 품질 | 우수 | 충분 |
| function calling 안정성 | 우수 | 충분 |
| 토큰 단가 | 높음 | 낮음 |
| 음성 대화의 적합성 | 지연이 UX 깬다 | 적합 |
“답이 좋아도 1.5초 침묵 뒤에 나오면, 사용자는 답이 좋다는 걸 못 느낀다.” 음성 대화에서는 latency가 품질을 가린다.
왜 음성 대화는 텍스트 대화보다 latency에 민감한가
텍스트 채팅에서는 “타이핑 중…” 인디케이터가 사용자의 기대치를 길게 늘려준다. 1~2초 정도의 지연은 자연스럽게 느껴진다. 음성 대화는 그렇지 않다.
- 인간 대화의 평균 turn-taking gap은 200ms 안팎이다 (Stivers et al., 2009 — 아래 인용).
- 1초 침묵 = “내 말이 안 들렸나?”
- 1.5초 침묵 = “이 시스템 고장 난 것 같다”
이 임계가 음성 상담에서는 절대적이다. 모델 응답 품질이 아무리 좋아도 그 임계를 넘으면 사용자는 곧바로 “이건 못 쓰겠다”고 판단한다.
Pro vs Flash — 의사결정 축
Google의 Gemini 모델군은 크게 두 가지 결을 가진다 (공식 문서 기준).
- Pro 계열 — 더 큰 추론 깊이, 긴 문맥, 어려운 reasoning에 강점.
- Flash 계열 — 응답 latency와 비용 효율에 최적화. 일상적 대화·요약·간단한 도구 호출에 적합.
음성 상담은 대부분의 turn이 “공감 + 질문 1개” 또는 “정보 1개 + 후속 질문”의 짧은 구조다. 모델에게 요구되는 추론 복잡도가 낮은 대신, latency는 이미 위에서 본 것처럼 절대적이다. 이 분포가 Flash 계열을 자연스러운 선택으로 만든다.
간이 측정 — 같은 prompt, 모델만 바꿔서
품질 차이를 일반화된 벤치마크 점수로만 보지 않고, 실제 도메인 prompt 5–10개로 측정해 보면 결정이 빨라진다. 측정 축은 셋이면 충분하다.
- p50 / p95 first-token latency (스트리밍 시작까지)
- 전체 응답 완성까지의 latency
- 응답 품질 점수 (1–5점 자체 평가)
실측 시 Flash 계열의 first-token latency가 일반적으로 Pro의 1/2~1/3 수준으로 들어왔다. 품질 점수는 prompt 카테고리에 따라 다르지만, 공감/짧은 안내 문구에서는 차이가 거의 보이지 않았다. 결정의 근거는 단순했다 — Flash가 만든 1초 안의 응답이, Pro의 1.8초짜리 응답보다 음성 상담에서는 항상 좋게 들렸다.
보완 전략 — Flash로 부족한 순간만 Pro를 호출
모델을 한 가지로 못 박을 필요는 없다. 라우팅 한 단계만 추가하면 latency 우위와 품질 우위를 둘 다 가져갈 수 있다.
- 일반 대화 turn — Flash로 즉응
- 긴 문맥 요약 / 보고서 / 복잡한 reasoning — Pro로 비동기 호출 후 결과 전달
- 사용자가 “잠깐만 정리해 줘” 같은 명시적 요청 → Pro로 전환
이 라우팅은 system prompt 안에서 LLM 자체로 분기하는 방법도 있고, 별도 router 함수가 직전 발화를 분류하는 방법도 있다. 음성 대화에서는 router 자체가 추가 latency를 일으키므로, 가장 간단한 keyword 매칭부터 시작하는 편이 안전하다.
개인 메모 — “느린 좋은 답”보다 “빠른 충분한 답”
처음에는 더 똑똑한 모델일수록 무조건 좋은 줄 알고 Pro 계열로 데모를 만들었다. 텍스트 콘솔에서 응답을 받을 때는 그 선택이 맞는 것처럼 보였다. 그런데 같은 prompt를 음성 turn으로 옮겨 직접 듣는 데모로 바꾸자 인상이 완전히 달라졌다 — 답은 잘 만들었는데, 첫 음성이 시작되기까지의 침묵이 듣는 입장에서 답답하게 느껴졌다.
그 뒤로 본인 안에서 “느린 좋은 답”보다 “빠른 충분한 답”이라는 기준이 자리 잡았다. 모델 선택을 벤치마크 점수가 아니라 직접 듣는 turn-taking 자연스러움으로 평가하기 시작했고, 그 시점에 Flash 쪽으로 결정이 갔다. 도메인이 음성이라면 latency는 단순한 성능 지표가 아니라 사실상의 품질 지표라는 걸 직접 듣고 나서야 인정하게 됐다.
답글 남기기