실습 노트
Gemini 3.5 Transcribe 공식 공개: Live API와 녹음 전사 워크플로우 설계
Google의 Gemini 3.5 Transcribe 공개 내용을 기준으로 실시간 Live API와 녹음용 Interactions API, smart·verbatim 전사, ko-KR 설정, 화자 분리와 타임스탬프 설계 기준을 정리했습니다.
Google은 2026년 8월 26일 Gemini 3.5 Transcribe를 공개했습니다.
이 글은 Google 공식 발표, Gemini API 전사 문서, Live 전사 문서를 기준으로 정리한 기술 메모입니다. 직접 성능을 측정한 사용기는 아닙니다.
Gemini 3.5 Transcribe는 공개 발표와 문서 기준으로 public preview 상태입니다.
먼저 결론
Gemini 3.5 Transcribe를 검토할 때의 핵심은 모델 이름보다 입력 흐름을 먼저 나누는 것입니다.
- 마이크나 통화처럼 진행 중인 음성을 처리하려면
gemini-3.5-transcribe-live와 Live API를 검토합니다. - 회의 녹음, 콜 로그, 업로드 파일처럼 이미 끝난 오디오는
gemini-3.5-transcribe와 Interactions API를 검토합니다. - 읽기 좋은 문장이 필요하면 smart transcription을, 발화 그대로의 기록이 필요하면 verbatim을 선택합니다.
- 한국어 중심 전사에서는
ko-KR을language_codes힌트로 두고, 제품명·인명·약어는 custom vocabulary로 분리해 관리합니다. - 화자 분리와 단어 타임스탬프는 검수와 편집에는 유용하지만, 문서상 smart transcription과 함께 쓸 수 없고 단어 타임스탬프는 정확도를 낮출 수 있습니다.
Google은 공식 발표에서 85개 이상 언어, 코드 스위칭, smart cleanup, custom vocabulary를 공개했습니다. 성능 수치로는 Artificial Analysis 기준 WER 4.0% streaming, 2.6% non-streaming, FLEURS 기준 5.50% streaming, 5.04% non-streaming을 제시했습니다. 이 수치는 Google이 인용한 제공자 발표 수치이며, 이 글의 독립 테스트 결과가 아닙니다.
Live API와 Interactions API 선택
공식 발표 기준 Gemini 3.5 Transcribe는 두 흐름으로 나뉩니다.
| 구분 | Live API | Interactions API |
|---|---|---|
| 모델 | gemini-3.5-transcribe-live |
gemini-3.5-transcribe |
| 입력 형태 | 실시간 음성 스트림 | 녹음 파일, 회의, 통화 기록 |
| 처리 방식 | 양방향 스트리밍 | 업로드한 오디오를 요청으로 처리 |
| 공식 발표의 지연 특성 | Google이 sub-second latency를 주장 | 실시간 응답보다 후처리 품질과 구조화에 초점 |
| 적합한 화면 | 실시간 자막, 음성 인터페이스, 진행 중인 대화 | 회의록 초안, 콜 로그 정리, 녹취 검수 |
| 문서상 주요 기능 | Live transcription | 화자 attribution, 단어 타임스탬프 |
실시간 화면은 최종 문장만 중요한 것이 아니라 중간 상태가 계속 바뀌는 UX가 중요합니다. 따라서 Live API를 쓸 때는 사용자가 임시 전사와 확정 전사를 구분할 수 있게 설계해야 합니다.
반대로 녹음 파일은 처리 시간이 조금 더 걸리더라도 검수, 화자 구분, 특정 구간 재생, 후처리 저장 구조가 더 중요합니다. 회의록이나 통화 기록은 처음부터 Interactions API 결과를 사람이 검토할 수 있는 데이터 구조로 저장하는 편이 현실적입니다.
용어 주석
- WER: Word Error Rate의 줄임말로, 음성 인식 결과의 단어 오류율을 나타내는 지표입니다.
- 코드 스위칭: 한 발화 안에서 둘 이상의 언어가 섞이는 상황입니다.
- 화자 attribution: 전사된 발화가 어느 화자에게 속하는지 붙이는 처리입니다.
smart와 verbatim을 먼저 정한다
전사 결과는 크게 읽기 좋은 문서와 원발화 기록으로 갈립니다.
| 기준 | smart transcription | verbatim |
|---|---|---|
| 목적 | 읽기 좋은 문장 생성 | 실제 발화 보존 |
| 처리 | 필러, 반복, 잘못 시작한 말 등을 제거하고 포맷팅 | 필러, 반복, false start를 보존 |
| 적합한 예 | 회의록 초안, 공유용 요약 전 단계, 메모 정리 | 녹취 검수, 발화 분석, 법적·감사성 기록의 원문 확인 |
| 함께 쓰기 어려운 기능 | 문서상 타임스탬프와 화자 분리와 호환되지 않음 | 원발화 보존이 필요한 기능 설계에 적합 |
smart transcription은 사람이 읽는 문서에 가깝게 정리하는 기능입니다. 회의 내용을 빠르게 훑거나 내부 메모 초안을 만들 때는 유용할 수 있습니다.
하지만 녹취 검수나 발화 분석처럼 "어떻게 말했는가"가 중요한 작업에서는 원문성이 중요합니다. 이때는 verbatim을 기준으로 저장하고, 별도 후처리 단계에서 요약이나 문장 정리를 붙이는 구조가 더 분명합니다.
특히 화자 분리나 단어 타임스탬프가 필요한 워크플로우라면 smart transcription을 기본값으로 두기 어렵습니다. 공식 문서는 smart transcription이 timestamps, diarization과 호환되지 않는다고 설명합니다.
한국어 ko-KR과 custom vocabulary
공식 전사 문서는 ko-KR을 지원 언어 코드로 안내합니다. 한국어 음성을 주로 처리한다면 language_codes 힌트에 ko-KR을 넣는 방식으로 설계를 시작할 수 있습니다.
다국어 회의나 한국어·영어가 섞이는 녹음에서는 코드 스위칭 지원을 기대할 수 있지만, 모든 고유명사가 자동으로 안정적으로 맞는다고 가정하면 안 됩니다. 제품명, 팀명, 사람 이름, 약어, 기술 용어는 custom vocabulary로 따로 관리하는 편이 낫습니다.
공식 문서 기준 custom vocabulary는 최대 1,000개까지 넣을 수 있지만, 문서는 일반적으로 최대 100개까지가 더 좋은 결과를 내는 경우가 많다고 안내합니다. 따라서 처음부터 가능한 모든 단어를 넣기보다, 실제 검수에서 반복적으로 틀리는 단어를 우선순위로 관리하는 방식이 적합합니다.
language_codes: ["ko-KR"]
custom_vocabulary:
- "Gemini 3.5 Transcribe"
- "Interactions API"
- "Live API"
- "ko-KR"
custom vocabulary는 정답 사전이 아니라 힌트에 가깝게 다루는 것이 안전합니다. 전사 후 검수 화면에서는 원문 오디오, 전사 텍스트, 용어 후보를 함께 보여줘야 사람이 최종 판단을 할 수 있습니다.
화자 분리와 단어 타임스탬프
녹음 파일 처리에서 중요한 기능은 speaker diarization과 word-level timestamps입니다.
공식 문서는 diarization을 최대 8명까지 설정할 수 있다고 안내합니다. 다만 3명 이상은 experimental로 표시되어 있으므로, 회의 참석자가 많을수록 검수 절차를 더 분명히 둬야 합니다.
단어 타임스탬프는 전사 텍스트와 오디오 재생 위치를 연결할 때 유용합니다. 회의록 편집 화면에서 문장을 클릭하면 해당 오디오 구간으로 이동하거나, 콜 로그에서 문제 구간만 다시 듣는 식으로 쓸 수 있습니다.
다만 공식 문서는 word timestamps가 정확도를 낮출 수 있다고 설명합니다. 모든 작업에 기본으로 켜기보다, 실제로 시간 축 검수가 필요한 화면에만 적용하는 편이 낫습니다.
| 기능 | 유용한 경우 | 설계 시 주의점 |
|---|---|---|
| speaker diarization | 회의, 인터뷰, 상담 기록처럼 화자 구분이 필요한 녹음 | 3명 이상은 experimental로 보고 검수 UI를 둔다 |
| word-level timestamps | 문장 클릭 재생, 구간 편집, 자막 검수 | 정확도 저하 가능성을 고려해 필요한 작업에만 켠다 |
| smart transcription | 읽기 좋은 텍스트가 우선인 메모 | diarization, timestamps와 함께 쓰지 않는 구조로 분리한다 |
공식 Python 예제
녹음 파일 전사의 기본 흐름은 파일을 업로드한 뒤 client.interactions.create에 오디오 URI와 MIME type을 넘기는 방식입니다.
from google import genai
client = genai.Client()
audio_file = client.files.upload(file="path/to/sample.mp3")
interaction = client.interactions.create(
model="gemini-3.5-transcribe",
input=[
{
"type": "audio",
"uri": audio_file.uri,
"mime_type": audio_file.mime_type,
}
],
)
print(interaction.output_text)
이 예제는 녹음 파일용 Interactions API 패턴입니다. 실시간 마이크 입력이나 진행 중인 통화에는 Live API와 gemini-3.5-transcribe-live를 별도로 검토해야 합니다.
워크플로우 설계
전사 기능을 제품이나 내부 도구에 붙일 때는 모델 호출보다 앞단의 의사결정이 더 중요합니다.
- 입력을 분류합니다. 실시간 스트림이면 Live API, 업로드 녹음이면 Interactions API로 나눕니다.
- 결과 목적을 정합니다. 공유용 문서면 smart, 원발화 보존이면 verbatim으로 시작합니다.
- 언어 힌트를 정합니다. 한국어 중심이면
ko-KR을 기본 힌트로 두고, 다국어 상황에서는 코드 스위칭 검수 기준을 둡니다. - 용어 목록을 관리합니다. custom vocabulary는 자주 틀리는 고유명사와 약어부터 넣고, 너무 큰 목록으로 시작하지 않습니다.
- 화자와 시간 정보를 분리합니다. diarization과 timestamps가 필요한 화면은 smart transcription과 별도 경로로 둡니다.
- 검수 상태를 저장합니다. 원본 오디오, 모델 출력, 사람이 수정한 최종본, 용어 수정 이력을 구분합니다.
실무 설계에서는 "전사를 한 번에 완성한다"보다 "전사 결과를 사람이 빠르게 확인하고 고칠 수 있게 만든다"가 더 안정적인 목표입니다. 특히 회의나 통화처럼 책임 소재가 남는 기록은 모델 출력과 사람이 확정한 기록을 같은 값으로 덮어쓰지 않는 편이 좋습니다.
한계와 확인해야 할 점
이 글에서 다룬 내용은 공식 발표와 문서에 근거한 기능 정리입니다. 비용, 요청 한도, 실제 한국어 정확도, 특정 산업 용어 인식률은 여기서 판단하지 않습니다.
- public preview 상태이므로 운영 적용 전 문서 변경 여부를 다시 확인합니다.
- Google이 인용한 WER 수치는 제공자 발표 수치로만 읽고, 자체 음성 샘플로 따로 평가합니다.
ko-KR힌트를 넣은 결과와 자동 감지 결과를 같은 샘플로 비교합니다.- custom vocabulary는 100개 이하의 핵심 용어부터 시작해 오탐과 누락을 함께 봅니다.
- 3명 이상 diarization은 experimental로 보고 화자 수정 기능을 준비합니다.
- word timestamps를 켠 결과와 끈 결과를 비교해 정확도 변화를 확인합니다.
- smart transcription을 쓸 때는 timestamps와 diarization이 필요한 요구사항이 없는지 먼저 확인합니다.
- 최종 기록으로 저장하기 전에는 사람이 원본 오디오와 전사 결과를 대조합니다.