브라우저에서 완전히 대규모 신경망 모델을 실행하는 꿈 — 서버 없음, API 호출 없음, 완전한 개인정보 보호, 완전한 오프라인 기능 — 은 정말 매력적입니다. 컨퍼런스 슬라이드에서 깔끔해 보이는 종류입니다. 그러면 실제로 구현하려고 하고 브라우저가 생각보다 무겁고 계산에 호스틸한 환경이라는 것을 발견합니다.
이것은 우리의 Whisper 브라우저 통합 실험의 기록된 이야기입니다: 우리가 시도한 것, 구체적인 실패 모드, 다른 사용 사례에서 실제로 작동한 것, 그리고 우리의 Labs 섹션의 베타 기능이 "프로덕션"이 아닌 "실험"으로 표시된 이유입니다.
브라우저의 Whisper가 합리적으로 보이는 이유
OpenAI Whisper는 트랜스포머 기반 음성 인식 모델입니다. 아키텍처는 비교적 간단합니다: 음향 인코더가 Mel 스펙트로그램 기능을 처리하고, 텍스트 디코더가 토큰을 자동 회귀적으로 생성합니다. 모델 가중치는 여러 크기로 제공됩니다: Tiny(39M 파라미터), Base(74M), Small(244M), Medium(769M), Large(1.5B), 최적화된 더 최신 Large-v3-Turbo(809M).
브라우저에서 신경망을 실행하는 것은 점점 더 가능해졌습니다. WebAssembly(WASM)는 계산 집약적 작업을 거의 네이티브 실행 속도로 제공합니다. ONNX Runtime Web 라이브러리는 브라우저에서 내보낸 ONNX 모델을 실행할 수 있습니다. Whisper.cpp는 Whisper에 최적화된 CPU 추론 같은 프로젝트가 있습니다. Hugging Face의 Transformers.js는 브라우저에서 전체 추론 파이프라인을 실행합니다. 이론적 기초는 견고합니다.
우리는 실험을 시작한 지 며칠 안에 브라우저에서 Whisper를 실행했습니다. 하지만 "실행"과 "프로덕션 준비"는 매우 다른 것으로 밝혀졌습니다.
실험 1: Whisper Turbo를 사용한 ONNX Runtime Web
우리의 첫 번째 시도는 ONNX Runtime Web을 Whisper Large-v3-Turbo 모델로 사용했습니다. 모델 파일은 약 1.6GB입니다. 바로 거기서, 문제 번호 1: 첫 로드 시 1.6GB 다운로드는 웹 애플리케이션에 완전히 받을 수 없습니다. 캐싱(Cache API 또는 IndexedDB)을 사용하더라도 첫 사용자는 기능을 사용할 수 있게 되기 전에 여러 분을 기다립니다.
대신 Tiny 및 Base 모델을 시도했습니다. 다운로드 크기: Tiny는 ~40MB(받을 수 있음), Base는 ~80MB(경계선). Tiny의 한국어 정확도: 대략적으로 좋은 날의 평범한 Web Speech API 결과와 비슷하고, 나쁜 날의 Web Speech API보다 상당히 나쁩니다. 전체 요점은 더 높은 정확도를 사용하는 것이었습니다. 정확한 모델은 너무 크습니다. 빠른 모델은 정확하지 않습니다. 이것이 기본적인 긴장입니다.
SharedArrayBuffer가 필요합니다. SharedArrayBuffer에는 페이지가 특정 HTTP 헤더로 제공되어야 합니다: Cross-Origin-Opener-Policy: same-origin 및 Cross-Origin-Embedder-Policy: require-corp. 이 헤더는 크로스 오리진 리소스 로드에 영향을 미칩니다. 우리의 기존 CDN 소스 폰트, 외부 스크립트, 광고 네트워크 코드 모두 깨졌습니다. 우리는 모두 로컬에 공급하거나 스레딩을 비활성화해야 했습니다.
CORS 문제는 한 주를 소비했습니다. 커밋 "ONNX Runtime 페이지의 CORS 문제 수정"은 ONNX Runtime Web 라이브러리 전체를 로컬로 공급하는 것(저장소에 ~15MB 추가)으로 이어졌습니다. 필수 헤더를 주입하는 사용자 정의 로컬 server.py를 만들고, 영향을 받은 모든 페이지를 로컬 라이브러리 경로를 사용하도록 업데이트합니다. 이것은 로컬 개발에는 작동했지만 배포 복잡성을 생성했습니다: Cloudflare Pages는 기본적으로 사용자 정의 HTTP 헤더 없이 정적 파일을 제공합니다. 우리는 WASM 페이지를 위해 구체적으로 _headers 파일을 구성해야 했습니다.
실험 2: 스트리밍 ASR을 위한 Sherpa-ONNX
Sherpa-ONNX는 Next-gen Kaldi 프로젝트의 프로덕션 품질 음성 인식 프레임워크입니다. 이것은 WASM으로 컴파일되고 스트리밍 추론을 지원합니다. 즉, 사용자가 말하기를 마칠 때까지 기다릴 필요가 없습니다. 이것은 Whisper의 핵심 제한을 해결합니다: Whisper는 근본적으로 배치 프로세서이며 완전한 오디오 세그먼트를 전사하도록 설계되었습니다.
우리는 Sherpa-ONNX 스트리밍 모델을 실행했습니다. 스트리밍 기능은 실제이고 지연 시간에서 진정으로 인상적이었습니다. 하지만 한국어용 Sherpa-ONNX 모델은 영어 모델보다 덜 성숙하고, WASM 번들 크기가 다시 문제가 되었습니다. sherpa-onnx WASM 바이너리는 ~8MB, 모델 파일 추가. 우리는 SharedArrayBuffer 헤더 요구사항으로 돌아갔습니다.
성능 벤치마크: 꿈을 죽인 숫자
몇 주의 테스트 후, 중급 노트북(2021 MacBook Pro M1)과 일반적인 Android 전화(Samsung Galaxy S21)에서의 정직한 숫자는 다음과 같습니다:
| 모델 | 플랫폼 | 첫 토큰 지연 | 실시간 계수 | 한국어 WER (대략) |
|---|---|---|---|---|
| Whisper Tiny (WASM) | MacBook M1 | 1.2초 | 0.4배(오디오보다 빠름) | ~32% |
| Whisper Base (WASM) | MacBook M1 | 2.1초 | 0.8배 | ~24% |
| Whisper Large-v3-Turbo (WASM) | MacBook M1 | 11초 | 4.2배(오디오보다 느림) | ~12% |
| Whisper Tiny (WASM) | Galaxy S21 | 3.8초 | 1.9배(오디오보다 느림) | ~35% |
| Web Speech API | 모두 | <0.2초(스트리밍) | 실시간 | ~15-20% |
테이블이 이야기를 명확히 말합니다. 데스크톱에서 Whisper Base는 Web Speech API와 비슷한 정확도를 달성하며 허용 가능한 지연 시간입니다. 하지만 데스크톱에서만, 스레딩이 활성화된 경우에만(SharedArrayBuffer 요구사항), 모델 다운로드 후에만. 모바일에서는 Whisper Tiny도 실시간보다 느리며, 오디오를 청크 단위로 처리하고 배치 단위로 처리해야 합니다. 사용하기에 충분할 정도로 정확한 것의 지연 시간은 세그먼트당 여러 초입니다. 실시간 회의 전사의 경우 작동 불가능합니다.
한국어에 대한 구체적인 문제
한국어 전사는 자체 섹션을 받을 자격이 있습니다. 왜냐하면 모델 동작이 직관적이지 않기 때문입니다. Whisper는 인터넷 오디오에 대해 학습되었고, 인터넷의 한국어 오디오는 특정 콘텐츠 유형으로 과대 대표됩니다: YouTube 동영상, 팟캐스트 스타일 음성, 전문 내레이션. 캐주얼 회의 음성 — 겹치는 문장, 필러 단어, 주제 중간 전환 — 학습 데이터와 다르게 패턴입니다.
더 비판적으로, 한국어 기술 및 비즈니스 어휘는 기본적으로 기본 Whisper 모델에 대해 어휘 외입니다. "GCP Kubernetes 클러스터 배포"에 대한 회의 논의는 유사한 소리의 한국어 구절의 환각 혼합으로 돌아올 것입니다. Web Speech API는 Google의 거대한 한국어 음성 데이터셋으로 뒷받침되며 기술 컨텍스트에서 훨씬 더 좋습니다.
이것은 또한 우리의 TextCorrector 모듈이 존재하는 이유입니다: Web Speech API를 사용하더라도 도메인 특화 용어는 수정이 필요합니다. Whisper의 경우 문제가 더 근본적입니다. 오인식된 기술 용어가 아니라 전체 문장을 다시 생성해야 합니다.
브라우저의 Whisper가 실제로 좋은 것
우리는 브라우저 기반 Whisper가 쓸모없다고 결론내리지 않았습니다. 우리는 다양한 도구에 대한 다양한 사용 사례라고 결론내렸습니다:
- 오프라인/프라이빗 사전 녹음 오디오 처리: 녹음 업로드, Whisper가 몇 분에 걸쳐 처리하도록 합니다. 지연 시간은 실시간 출력을 기다리지 않으면 괜찮습니다.
- 높은 정확도 배치 전사: 속도보다 정확도가 더 중요하고 브라우저를 남기는 오디오를 원하지 않으면 Whisper Turbo도 우수한 결과를 제공합니다.
- 전용 GPU를 갖춘 데스크톱급 하드웨어: WebGPU가 성숙하고 있습니다. ONNX Runtime Web과 WebGPU 백엔드는 WASM CPU보다 3~5배 추론 시간을 감소시킵니다. MacBook M1의 WebGPU를 갖춘 Whisper Large-v3-Turbo는 약 1.8배 실시간으로 오디오를 처리합니다. 여전히 라이브 스트리밍에 충분히 빠르지 않지만 격차를 좁히고 있습니다.
우리가 정착한 곳: Labs를 정직한 실험 섹션으로
VORA의 Labs 섹션은 특히 현재 상태에 대해 정직한 방식으로 이러한 실험을 포함하기 위해 존재합니다. Whisper Beta 페이지는 명확하게 실험적으로 표시됩니다. 오프라인 처리나 최대 개인정보 보호가 필요한 사용자는 시도하고 피드백을 줄 수 있습니다. 주 VORA 앱은 Web Speech API를 계속 사용합니다. 이는 2026년 실시간 회의 전사를 위한 올바른 도구이기 때문입니다.
우리는 Hybrid ASR 테스트 페이지를 구축했습니다. 접근 방식을 결합합니다: 스트리밍 실시간 출력을 위한 Web Speech API, 백그라운드에서 동일한 오디오를 처리하는 Whisper를 위해. 이 조합은 흥미로운 속성을 가지고 있습니다. 실시간성을 Web Speech API에서 얻고, 정확도를 Whisper에서 얻고, 정확한 버전이 몇 초 후 스트리밍 전사를 대체합니다. 우리는 여전히 이 UX 모델이 실제 사용자에게 작동하는지 평가하고 있습니다.
정직한 요약: 브라우저 기반 대규모 모델 추론은 빠르게 개선되고 있는 기술이며 1~2년 내에 가능한 것을 변환할 가능성이 있습니다. 특히 WebGPU가 성숙함에 따라. 오늘 실시간 음성 인식을 위해, 특히 모바일 사용자나 즉각적인 결과가 필요한 모든 사람에게는 아직 거기에 있지 않습니다. 하지만 Labs에 두고 증분 개선하고 하드웨어와 브라우저 기능이 따라잡을 준비가 되어 있을 가치가 있습니다.