오픈소스 STT 모델 비교 2026 — Whisper·Faster-Whisper·WhisperX 중 무엇을 고르나

「오픈소스 STT 뭐 쓰면 되나요」라는 질문에 Whisper · Faster-Whisper · WhisperX 세 이름이 같이 돌아오는 경우가 많다. 그런데 이 셋은 같은 층위의 선택지가 아니다. Whisper 는 모델이고, Faster-Whisper 는 그 가중치를 다른 엔진으로 돌리는 런타임이고, WhisperX 는 그 위에 전처리·정렬·화자분리를 얹은 파이프라인이다. 셋을 나란히 놓고 「정확도 비교」를 하면 애초에 같은 숫자가 나온다 — 가중치가 같으니까.

이 글은 그 층위를 먼저 가르고, 실제로 선택이 갈리는 축(라이선스 · 화자분리 지원 · 단어 타임스탬프 · 폐쇄망 반출 가능성)으로 비교한다. 그리고 공개된 WER 숫자를 우리 음원에 쓰면 안 되는 이유와, 대신 30분 음원으로 끝내는 측정 절차를 둔다. 설치·실행 순서는 한국어 STT 오픈소스 — Whisper 로컬 파이프라인 쪽에 있다.

세 이름은 같은 층위가 아니다

가장 먼저 정리할 것. 비교표를 보기 전에 이 구분이 되어 있지 않으면 표를 잘못 읽는다.

그래서 「Faster-Whisper 가 Whisper 보다 정확한가」는 성립하지 않는 질문이다. 같은 모델이다. 반대로 「WhisperX 로 바꾸면 전사가 좋아지나」도 대개 아니다 — 좋아지는 것은 몇 초에 무슨 말이 있었는지이고, 무슨 말이었는지는 그대로다.

비교표 — 선택이 실제로 갈리는 축

수치는 모델 카드와 저장소에서 확인한 값이다(2026-10-07 조회).

가중치 크기는 파라미터 × 2바이트로 바로 계산되는 값이고, 실제 점유 VRAM 은 런타임·배치·시퀀스 길이에 따라 이보다 붙는다. 여기서 중요한 것은 절대치가 아니라 비율이다 — turbo 로 내려가면 가중치가 절반이 되고, int8 로 내리면 또 절반이 된다.

라이선스 세 개가 다르다는 점은 실무에서 걸린다

세 가지가 전부 허용적 라이선스지만 같지 않다. Apache-2.0 은 특허 조항과 변경 고지 의무가 있고, MIT·BSD-2-Clause 는 저작권 표시 유지만 요구한다. 사내 제품에 넣어 배포하는 경우 법무 검토 항목이 달라지므로, 대개 가장 제약이 큰 구성요소가 전체 조건을 정한다. WhisperX 를 쓰면 BSD-2-Clause 가, 화자분리로 pyannote 를 붙이면 그쪽 조건이 같이 들어온다.

공개 WER 숫자를 우리 음원에 그대로 쓰면 안 된다

벤치마크에 적힌 한국어 WER 은 대개 낭독체 공개 코퍼스에서 나온 값이다. 우리가 넣으려는 음원은 통화·회의·현장 녹취다. 둘 사이에서 달라지는 조건이 한둘이 아니다.

세 번째가 가장 아프다. WER 은 전체 단어 기준 평균이라 고유명사가 다 틀려도 총점은 멀쩡하게 보인다. 100단어 중 고유명사가 5개이고 그걸 전부 틀렸다면 WER 은 5%다 — 훌륭한 숫자인데, 그 전사로는 어느 고객 이야기인지 알 수 없다. 이것은 화자 분리의 DER 과 같은 함정이다. 총합 지표 하나는 업무 가능 여부를 말해 주지 않는다.

그럼 무엇을 재나 — 30분 음원으로 끝내는 절차

모델을 고르기 전에 우리 음원 30분을 만든다. 하루면 된다. 이 30분이 이후 모든 비교의 기준이 된다.

1. 음원을 3구간으로 뽑는다 — 깨끗한 구간 10분, 평균적인 구간 10분, 최악 구간(소음·겹침) 10분. 최악 구간을 빼면 측정이 낙관 쪽으로 쏠린다.
2. 정답 전사를 사람이 만든다 — 30분이면 2~3시간 작업이다. 이게 자산이다. 모델을 바꿀 때마다 다시 쓰지 않는다.
3. 총 WER 이 아니라 네 칸으로 나눠 센다.

1. 런타임은 품질이 아니라 처리량으로 비교한다. 같은 가중치라면 Faster-Whisper 와 원본 구현의 전사 결과는 거의 같다. 비교 대상은 30분을 몇 분에 끝내는지, 그리고 그때 VRAM 이 얼마인지다.

이 절차를 거치면 선택이 대개 자동으로 정해진다. 고유명사 칸이 떨어지면 모델을 바꿀 문제가 아니라 사전(initial prompt·용어 치환)을 붙일 문제이기 때문이다.

처리량은 RTF 로 적는다 — 「빠르다」는 견적에 못 쓴다

속도 비교에서 「2배 빠름」 같은 표현은 범위를 정하지 못한다. 쓸 수 있는 단위는 RTF(Real-Time Factor), 음원 길이 대비 처리 시간의 비다.

RTF 0.1 은 1시간 음원을 6분에 끝낸다는 뜻이다. 이 숫자 하나로 기한이 바로 나온다.

표를 보면 결정이 단순해진다. 600시간을 주말에 끝내야 한다면 RTF 0.1 이하가 조건이고, 2주가 있다면 RTF 0.5 로도 된다. 후자라면 더 큰 모델을 쓸 여유가 있다는 뜻이다 — 처리량 요구가 느슨할 때 품질을 사는 것이 올바른 순서다.

RTF 는 기기·배치·음원 길이에 따라 달라지므로 공개 값을 옮겨 쓰지 않는다. 우리 30분 평가셋을 돌려 우리 장비에서의 RTF 를 한 번 재면, 그 숫자가 이후 모든 범위 산정의 입력이 된다.

large-v3 와 turbo — 8.09억이 무엇을 버렸나

turbo 는 large-v3 에서 디코더를 크게 줄인 모델이다. 15.4억 → 8.09억으로 내려간 것이 대부분 디코더 쪽이고, 그래서 디코딩이 빨라진다. 인코더는 유지되므로 「들은 것」의 표현력은 유지되고, 「그것을 문장으로 뽑는」 쪽이 얇아진다.

실무 판단은 이렇게 갈린다.

• 배치 전사(회의록·녹취 아카이브) — turbo 를 먼저 시도할 이유가 충분하다. 처리량이 체감으로 달라지고, 우리 음원 30분으로 품질 차이를 직접 확인할 수 있다.
• 번역까지 맡기는 경우 — turbo 는 전사 중심으로 다듬어진 모델이라 번역 품질은 따로 확인해야 한다.
• 라이선스를 보는 경우 — turbo 는 MIT, large-v3 는 Apache-2.0 이다. 제품에 넣는다면 이 차이를 법무가 먼저 본다.

「국내 공개 모델」 칸은 생각보다 비어 있다

한국어 전용 공개 모델을 찾는 요청이 자주 들어온다. 실제 사용량을 보면 이 칸의 상태가 드러난다(Hugging Face 누적 다운로드, 2026-10-07 조회).

읽는 법은 두 가지다.

첫째, 한국어 쪽 1위는 wav2vec2 계열인데 이 계열은 구두점과 대소문자를 내놓지 않는다. 회의록·자막처럼 사람이 읽는 산출물을 만들려면 후처리를 따로 붙여야 한다. 다운로드 수가 많은 이유는 품질 우위가 아니라 먼저 나왔고 파인튜닝 예제가 많기 때문으로 보는 것이 안전하다.

둘째, 한국어 Whisper 파인튜닝은 1천 단위에 머물러 있고, 같은 성격의 일본어 모델은 2만 단위다. 한국어 공개 파인튜닝 생태계가 아직 얇다는 뜻이다. 그래서 2026년 현재 한국어 실무의 현실적인 출발점은 「한국어 전용 모델 찾기」가 아니라 「베이스 Whisper + 우리 용어 사전 + 런타임 최적화」다. 전용 모델이 필요해지는 시점은 우리 30분 측정에서 일반 어휘 칸이 떨어질 때이고, 대개 떨어지는 칸은 고유명사다 — 그건 파인튜닝보다 싼 방법으로 해결된다.

용도별 선택 — 네 가지 경우

콜센터 칸이 가장 자주 틀리는 자리다. 채널이 분리돼 있으면 화자분리 모델이 아예 필요 없다 — 알고리즘으로 풀 문제가 아니라 녹음 설정으로 끝나는 문제이고, 이게 압도적으로 싸다. 견적서에 화자분리가 들어와 있다면 녹음 장비 설정부터 확인할 것.

온프레미스는 라이선스가 아니라 다운로드에서 막힌다

폐쇄망 구축에서 실제로 걸리는 것은 라이선스 문구가 아니다. 모델 가중치를 어떻게 망 안으로 들여오느냐다.

pyannote 의 사전학습 화자분리 모델은 저장소 코드가 MIT 이지만, 배포되는 가중치는 접근 조건에 동의해야 받을 수 있는 형태(gated)로 올라가 있다. 즉 런타임에 자동으로 내려받는 구성은 폐쇄망에서 그대로 실패한다. 반출 가능한 환경에서 토큰으로 미리 받아 내부 저장소에 넣어 두는 절차가 구축 범위에 들어가야 한다.

선택 한 건을 끝까지 — 2시간 회의 녹음 300건

실제로 들어오는 모양으로 한 번 전개한다. 사내 회의 녹음 300건, 1건 평균 2시간, 참석자 3~6명, 산출물은 요약과 결정사항.

1. 먼저 음원을 본다. 단일 마이크 1채널이면 화자분리가 필요하고, 이 조건이 전체 난이도의 절반을 정한다. 회의실 녹음은 콜센터와 달리 채널 분리로 피해 갈 수 없다.
2. 30분 평가셋을 만든다. 300건 중 깨끗한 회의 1건, 평균 1건, 최악(스피커폰 원격 참석) 1건에서 10분씩.
3. 런타임을 먼저 고정한다. 600시간을 처리해야 하므로 처리량이 범위를 정한다. 같은 가중치에서 처리량만 비교하면 되므로 품질 논쟁 없이 결정된다.
4. 화자분리는 참석자 수를 고정해 쓴다. 회의록은 참석자 명단이 있는 경우가 많다. 수를 지정하는 것만으로 결과가 크게 안정된다.
5. 검수 기준을 두 개로 쪼개 적는다.

마지막 줄이 빠진 검수 기준을 자주 본다. 품질만 적고 처리량을 안 적으면, 품질을 맞추려고 가장 느린 구성을 고른 뒤 기한을 못 맞춘다. 둘은 같이 적어야 한다.

업체 유형별 비용과 선택 기준은 AI 음성인식 STT 업체 추천 쪽에 정리해 뒀다.

FAQ

Q: Faster-Whisper 가 더 정확하다고 들었습니다.

같은 가중치를 쓰므로 전사 내용은 거의 같다. 체감 차이가 나는 경우는 대개 VAD(무음 제거) 설정이 다르게 걸려 환각 구간이 줄어든 것이다. 정확도 개선이 아니라 전처리 효과다.

Q: 한국어니까 한국어 전용 모델이 당연히 낫지 않나요?

우리 30분 평가셋에서 재 보지 않으면 모른다. 공개 한국어 모델의 다수는 wav2vec2 계열이라 구두점이 없고, 한국어 Whisper 파인튜닝은 아직 사용량이 얇다. 대개 실패하는 칸은 일반 어휘가 아니라 고유명사이고, 그건 용어 사전으로 더 싸게 해결된다.

Q: turbo 로 바꿨는데 품질이 떨어진 것 같습니다.

30분 평가셋으로 네 칸을 각각 비교해 본다. 총 WER 은 비슷한데 문장 경계나 긴 발화에서만 나빠지는 경우가 있고, 그렇다면 용도에 따라 수용 가능하다. 「느낌」으로 되돌리면 처리량 이득을 근거 없이 버리게 된다.

Q: 화자분리까지 하면 GPU 가 더 필요한가요?

전사와 화자분리는 보통 순차로 돌리므로 동시 점유가 아니라 최대값이 조건이다. 화자분리 모델은 전사 모델보다 작아서, 대개 전사 쪽이 VRAM 상한을 정한다.

Q: 오픈소스로 가면 비용이 0인가요?

가중치 비용이 0이다. 측정셋 제작, 용어 사전 구축, 처리 인프라, 모델 갱신 책임은 그대로 남는다. 300건 규모에서는 이쪽이 전체 비용의 대부분이다.

정리

오픈소스 STT 선택은 모델 비교보다 층위 구분과 우리 음원 측정이 먼저다. Whisper 는 모델, Faster-Whisper 는 런타임, WhisperX 는 파이프라인이고, 셋 중 둘은 품질을 바꾸지 않는다. 공개 WER 은 낭독체 기준이라 우리 통화·회의에 그대로 옮겨 오지 않으며, 총합 지표는 고유명사 전멸을 가려 준다. 30분 평가셋을 만들어 일반 어휘·고유명사·숫자·문장 경계 네 칸으로 나눠 세면, 대개 바꿔야 할 것이 모델이 아니라는 결론이 나온다.