Gemini 3.5 Transcribe API 리뷰(2026): 대규모 적용 전 반드시 테스트해야 하는 이유

검색할 때는 “3-5”로 입력하는 경우가 많지만, Google의 실제 모델 ID는 gemini-3.5-transcribe와 gemini-3.5-transcribe-live다. API 자체는 실제로 제공되고 가격도 저렴하다. 다만 최종 선택은 깔끔하게 다듬어진 문장이 필요한지, 발화를 추적 가능한 형태로 남겨야 하는지, 실시간 자막이 필요한지에 따라 달라진다.

Gemini 3.5 Transcribe API 리뷰 결론을 한눈에 보기

Gemini 3.5 Transcribe는 녹음 파일, 받아쓰기, 짧은 실시간 자막 기능을 프로토타이핑할 때 충분히 검토할 만하다. 하지만 정확한 축어록이나 장시간 실시간 기록의 기본 선택지로 삼기에는 이르다. Smart transcription은 발화를 편집하고, 실시간 세션에는 화자 라벨과 단어 단위 타이밍이 없으며, 서비스도 아직 공개 프리뷰 단계이기 때문이다.

이 글은 통제된 WER 벤치마크가 아니라, 근거를 바탕으로 API를 검토한 글이다. Gemini 3.5 Transcribe API 설정 및 가격 가이드에서 요청 흐름을 다뤘다면, 여기서는 첫 호출에 성공한 뒤 실제로 마주하게 되는 문서화된 트레이드오프를 살펴본다.

모델은 하나가 아니라 서로 다른 두 API 계약이다

gemini-3.5-transcribe는 Interactions API를 통해 업로드된 오디오나 사전 녹음 파일을 처리한다. 반면 gemini-3.5-transcribe-live는 Live API로 스트리밍 오디오를 처리한다.

녹음 파일 변환: gemini-3.5-transcribe

보관 가능한 트랜스크립트가 필요하다면 녹음용 경로가 더 많은 기능을 제공한다. Google 문서에 따르면 오디오 트랜스크립션 문서에서 85개 이상의 언어 자동 감지, 사용자 지정 어휘, Smart 또는 축어 출력, 화자 분리, 단어 단위 타임스탬프를 지원한다.

일반 오디오의 길이 제한은 최대 1시간이다. 화자 분리나 단어 단위 타임스탬프를 활성화하면 제한이 30분으로 줄어든다. 또한 Google은 3명 이상의 화자 식별을 실험적 기능으로 표시하고 있다. 모델 레퍼런스에는 최대 8명의 화자가 기재돼 있지만, 이것이 대규모 회의에서의 안정성을 보장하는 것은 아니다.

따라서 이 경로는 받아쓰기, 인터뷰, 짧은 통화에 잘 맞는다. 화자 식별과 시간 정렬이 필요한 긴 회의는 애플리케이션에서 여러 구간으로 나눈 뒤 다시 이어 붙여야 한다.

실시간 변환: gemini-3.5-transcribe-live

실시간 경로는 녹음용 API를 WebSocket으로 그대로 옮긴 것이 아니라, 순차적으로 생성되는 자막을 위한 기능이다. Google의 Live transcription 문서에는 중간 및 최종 트랜스크립트 이벤트, 자동 언어 감지, 사용자 지정 어휘, Smart 모드, 자동·하이브리드·수동 음성 활동 감지가 설명돼 있다.

연속 실시간 세션은 10분 동안만 유지된다. 실시간 스트리밍에서는 화자 분리와 단어 단위 타임스탬프를 사용할 수 없으며, 오디오는 raw 16-bit PCM, 16 kHz, 모노, little-endian 형식이어야 한다. 짧은 자막 미리보기에는 충분하지만, 장시간 통화를 녹음하려면 재연결과 구간 병합, 확정 전 텍스트 처리 로직을 별도로 구현해야 한다.

이번 리뷰의 결론을 좌우하는 기능 간 트레이드오프

Gemini 3.5 Transcribe의 차별점은 발화를 “지능적으로” 다듬는 기능이다. 문제는 이 기능이 정확성의 의미 자체를 바꾼다는 데 있다. 다듬어진 문장은 받아쓰기에는 더 유용할 수 있지만, 발화를 그대로 보존해야 하는 기록에는 덜 적합하다.

Smart 모드는 원본 기록이 아니라 편집 기능이다

Google의 Smart 모드는 필러 워드, 더듬거림, 말하다가 중단한 표현을 제거하고, 말로 한 정정을 반영한다. 구두점, 숫자, 목록, 문단 형식도 자동으로 정리한다. 예를 들어 “화요일에 만나자, 아니 수요일에”라는 말은 중간의 정정을 그대로 남기지 않고 “수요일에”로 출력될 수 있다.

초안 이메일, 음성 메모, 읽기 쉬운 회의록이라면 유용한 동작이다. 하지만 머뭇거림이나 처음에 한 오류, 정확한 발화 순서 자체가 의미를 갖는 상황에서는 위험하다.

공식 트랜스크립션 가이드도 이 경계를 명확히 밝힌다. Smart 모드는 화자 분리나 단어 단위 타임스탬프와 함께 사용할 수 없다. 결국 API는 읽기 좋은 텍스트와 추적 가능한 주석 중 하나를 선택하도록 만든다.

원본 기록은 축어 트랜스크립트로 보존하고, 독자에게 보여줄 문서는 Smart 모드나 후처리로 별도 생성하는 방식이 안전하다. 이 호환성 문제는 프롬프트로 해결할 수 없다. 출력 계약 자체의 제약이기 때문이다.

타임스탬프와 화자 라벨은 추적성을 높이지만 사용 범위를 좁힌다

녹음 오디오는 축어 모드로 설정했을 때 단어 텍스트, 오프셋, 화자 식별자가 포함된 word_info 주석을 반환할 수 있다. 이 정보는 자막, 특정 시점으로 이동하는 재생 기능, 화자별 발화 시간 계산, 증거 검토에 활용할 수 있다.

따라서 “타임스탬프를 지원한다”는 말만으로 구매 결정을 내려서는 안 된다. 기능 자체는 존재하지만 파일 길이 제한이 줄어들고 인식 정확도와 맞바꿀 수도 있다. 문서에 적힌 최대 화자 수를 대규모 회의에서의 신뢰성 보장으로 받아들이지 말고, 실제 화자 식별 성능을 직접 테스트해야 한다.

사용자 지정 어휘와 언어 감지

두 경로 모두 자동 언어 감지와 사용자 지정 어휘를 지원한다. Google은 85개 이상의 언어와 코드 스위칭을 문서화했으며, 애플리케이션이 이미 언어를 알고 있다면 en-US 같은 힌트를 제공하라고 권장한다.

사용자 지정 어휘에는 최대 1,000개 용어를 넣을 수 있지만, Google의 실용적인 가이드는 일반적으로 최대 100개일 때 결과가 가장 좋다고 설명한다. 제품명, 약어, 고유명사, 전문 용어에 활용하고 일반적인 단어는 넣지 않는 편이 좋다.

“지원한다”는 말이 억양, 방언, 시끄러운 공간, 문장 중간의 언어 전환에서도 동일한 품질을 보장한다는 뜻은 아니다. 초기 Reddit 논의 중에는 실시간 경로가 혼합 언어를 처리할 수 있는지를 묻는 글도 있었다. 이는 실패의 증거라기보다 직접 검증해볼 만한 테스트 사례에 가깝다.

“영상이 말보다 조금 늦게 재생되더라도 자막이 실제 발화와 맞춰졌으면 좋겠다.” — u/WaterObjective5107, Reddit

이 댓글은 WER로는 측정하기 어려운 실시간 제품의 문제를 잘 보여준다. 자막이 언어적으로 정확하더라도 영상과 동기화되지 않으면 사용자는 제대로 작동하지 않는다고 느낄 수 있다.

정확도 수치가 실제로 말해주는 것

Google이 공개한 수치는 고무적이지만, Gemini 3.5 Transcribe의 보편적인 단일 점수를 의미하지는 않는다. 여러 평가 환경에서 나온 결과이므로, 사용 중인 마이크와 억양, 전문 용어, 화자 패턴을 직접 테스트하기 전까지는 진지한 파일럿을 뒷받침하는 근거 정도로 봐야 한다.

이 수치는 Google의 출시 발표에 등장한다. 발표문은 Chirp 3 대비 최종 트랜스크립션 도달 시간도 70% 개선됐다고 주장한다. 다만 이는 Google의 주장이지, 여러분의 실제 워크플로를 독립적으로 검증한 결과는 아니다.

2.6%와 5.50%의 차이는 모순이 아니다. 사용한 경로와 데이터셋, 언어 구성, 스트리밍 조건이 서로 다르기 때문이다. 전체 WER 하나만 보지 말고 이름, 주문 ID, 날짜, 금액, 제품 용어, 화자 전환처럼 오류가 실제 비용으로 이어지는 항목을 따로 평가해야 한다.

초기 커뮤니티 보고에서는 언어 전환, 화자 식별, 타임스탬프 동작, 장시간 녹음 완료 여부가 테스트 사례로 자주 언급됐다. 한 X 테스터는 20분짜리 클립을 넣었지만 5분만 반환됐다고 설명했다. 이는 방향성을 보여주는 일화일 뿐, 통제된 제품 사실로 받아들여서는 안 된다. (X 보고)

설정 가이드만으로는 알 수 없는 프로덕션 장애물

파일 업로드가 성공하거나 WebSocket 연결이 됐다고 해서 프로덕션 준비가 끝난 것은 아니다. 실제 위험은 데모 이후에 나타난다. 변경되는 실시간 텍스트, 경로별 제한, 인증 정보 관리, 프리뷰 상태, 신뢰할 수 있는 트랜스크립트를 보존하는 정책이 모두 운영 단계의 변수다.

실시간 자막에는 상태 관리가 필요하다

실시간 응답은 두 가지 역할로 나뉜다. interim_input_transcription은 자막 미리보기에 사용하는, 계속 바뀔 수 있는 추정 결과다. input_transcription은 확정된 구간이므로 영구 트랜스크립트 상태에 추가할 수 있다.

다음과 같은 상태 모델을 사용하면 된다.

1. 중간 업데이트가 들어올 때마다 화면에 표시된 자막을 교체한다.
2. 확정된 텍스트만 커밋된 트랜스크립트에 추가한다.
3. 10분 세션 경계에 도달하기 전에 세션을 갱신하거나 재연결한다.
4. 세션 사이에 명시적인 경계 표시와 중복 제거 로직을 두고 구간을 이어 붙인다.
5. 확정 전 텍스트가 되돌릴 수 없는 작업을 실행하지 않도록 한다.

브라우저와 모바일 클라이언트에서는 임시 토큰을 사용해 장기 API 키가 프론트엔드 코드에 노출되지 않도록 해야 한다. 토큰을 발급하고 권한 범위를 제한하려면 백엔드가 필요하다. 이런 아키텍처가 애플리케이션에 맞는다면 오디오는 클라이언트에서 Live API로 직접 흘려보낼 수 있다. 연결 오류, 최종 확정 지연 시간, 중복 구간도 모니터링해야 한다.

녹음 워크플로에는 원본 보존 정책이 필요하다

모드를 선택하기 전에 어떤 출력 계약이 필요한지부터 정해야 한다. 읽기 쉬운 문장이 목적이면 Smart 모드를, 정확한 발화와 화자 정보 또는 오프셋이 중요하면 축어 모드를 사용한다.

축어 결과와 주석을 저장한 뒤 검색, 요약, 고객용 메모에 사용할 정리된 트랜스크립트를 별도로 생성하는 방식이 좋다. 처리 단계가 하나 늘어나기는 하지만, 삭제된 필러 워드나 덮어써진 정정을 나중에 복원하려는 것보다 안전하다.

프리뷰 상태가 배포 판단을 바꾼다

Google은 2026년 8월 26일 Gemini 3.5 Transcribe를 공개 프리뷰 모델 제품군으로 발표했다. Google 모델 레퍼런스에는 기능과 제한이 정리돼 있지만, 프리뷰 단계인 만큼 마이그레이션 전에 가격, 할당량, 동작, 제공 가능 여부를 다시 확인해야 한다.

민감하지 않은 소규모 평가 세트와 저장된 기준 트랜스크립트로 시작하자. 핵심 엔터티 정확도, 화자 식별, 최종 확정 지연 시간, 재연결 동작, 검토자 수정률을 각각 측정하고, 테스트 전에 통과 기준을 문서로 정해두는 것이 좋다. 모든 기준을 충족했을 때만 다음 단계로 올려야 한다.

가격보다 중요한 것은 최종 승인된 트랜스크립트 비용

표시된 예상 비용만 보면 Gemini 3.5 Transcribe는 저렴하다. 하지만 과금은 분당 고정 요금이 보장되는 방식이 아니라 토큰 기반이다. Google 공식 가격표에는 녹음 오디오 입력이 분당 약 $0.003, 텍스트 출력이 $0.002로 기재돼 있으며, 합산한 예상 비용은 분당 약 $0.005다. Live는 분당 약 $0.009로 제시된다.

첫 예산은 녹음 100시간 기준 약 $30, 실시간 기준 약 $54다. 재시도, 저장 공간, 오디오 변환, 사람의 수정, 후속 요약 비용은 포함되지 않는다. 출력 길이와 추가 컨텍스트에 따라 실제 청구액이 달라질 수 있으므로 사용량 로그를 남겨야 한다.

Google 공개 가격 페이지를 캡처한 이미지다. 대규모 사용을 확정하기 전에 현재 가격표를 다시 확인하자. 자세한 내용은 공식 Gemini API 가격 문서를 참고하면 된다.

최종 승인된 트랜스크립트 비용은 API 사용료에 검토 시간, 검토자 단가, 재시도, 저장, 변환, 후속 처리 비용을 더해 계산해야 한다. Smart 모드 수정이나 두 번째 주석 처리 단계가 수작업 교정량을 줄여준다면, 더 비싼 API가 전체 비용에서는 오히려 저렴할 수 있다.

Gemini 3.5 Transcribe API 리뷰 FAQ

Smart transcription은 정확한 표현을 그대로 보존하나요?

아니다. Smart 모드는 말더듬이나 자기 정정을 편집하므로, 정확한 표현이 중요하다면 축어 모드를 원본으로 보존해야 한다.

Live API에서 화자 라벨이나 단어 타임스탬프를 제공하나요?

아니다. 화자 분리나 단어 단위 타임스탬프가 필요하다면 녹음 경로를 사용해야 한다.

Gemini 3.5 Transcribe로 긴 회의를 처리할 수 있나요?

일반 녹음 경로의 제한은 1시간이며, 화자 분리나 단어 단위 타임스탬프를 사용하면 30분으로 줄어든다. Live는 연속 세션당 10분으로 제한된다.

법률·의료·컴플라이언스 트랜스크립트에 적합한가요?

축어 출력, 핵심 필드 확인, 사람의 검토를 포함한 보조 계층으로만 사용해야 한다. Smart 출력을 고위험 기록의 유일한 원본으로 사용해서는 안 된다.

결론: 프로토타입은 좋지만, 어느 순간 원본이 되게 두지는 말 것

Gemini 3.5 Transcribe는 완벽하게 발화를 그대로 보존하는 것보다 저렴하고, 다국어를 지원하며, 맥락을 반영하는 트랜스크립션이 중요한 경우 유력한 후보가 될 수 있다. 먼저 녹음 경로로 시작해 자신의 오디오에서 Smart와 축어 출력을 비교하고, 30분 제한을 감수할 수 있을 때만 주석 기능을 추가하는 접근이 적절하다.

클라이언트가 필요한 PCM 형식으로 안전하게 스트리밍하고 중간 텍스트와 최종 확정 텍스트를 분리할 수 있을 때 자막이나 음성 UI를 위해 Live로 확장하면 된다. 민감한 기록이라면 원본 경로를 보존하고 사람의 검토를 승인 기준에 포함해야 한다. Smart 모드가 원본을 다시 써버린 뒤 긴급 복구책으로 검토를 꺼내 드는 방식은 피해야 한다.