"어떤 AI 받아쓰기가 제일 정확한가요?" 이 질문에 돌아오는 답은 거의 항상 숫자 하나입니다. 정확도 몇 퍼센트, 오류율 몇 퍼센트.
그 숫자는 대체로 도구를 고르는 데 쓸모가 없습니다. 틀려서가 아닙니다. 여러분이 실제로 가진 녹음과 전혀 다른 오디오에서 나온 값이기 때문입니다. 마이크 하나를 여럿이 나눠 쓰는 회의실, 말이 겹치는 인터뷰, 한국어 문장 사이에 영어 제품명과 약어가 계속 끼어드는 발표 — 공개된 점수는 이런 오디오에서 나오지 않았습니다.
저는 음성을 텍스트로 바꾸는 도구 Subanana를 운영합니다. 그래서 이 질문을 파는 일이 직업이기도 합니다. 이 글에서는 공개된 정확도 수치가 정확히 무엇에서 나오는지를 각 벤치마크의 공식 문서로 확인하고, 그 숫자가 무엇을 못 보는지 짚은 다음, 여러분이 가진 녹음으로 직접 품질을 확인하는 방법까지 정리하겠습니다.
요약
- 공개된 정확도 점수는 대부분 잘 정돈된 공개 말뭉치에서 측정됩니다. 여러분의 회의 녹음과는 녹음 환경도, 말하기 방식도 다릅니다. 이건 추측이 아니라 각 벤치마크가 스스로 밝혀 둔 사실입니다.
- 업계 표준 지표인 단어 오류율(WER)은 삽입·삭제·대체 오류를 같은 무게로 더합니다. 조사 하나를 빠뜨린 것과 회사 이름을 바꿔 쓴 것이 같은 점수를 받습니다.
- 가장 위험한 오류는 어색한 문장이 아니라 매끄러운 문장입니다. 읽기엔 완벽한데 고유명사나 숫자가 조용히 바뀐 문장이 그렇습니다.
- "정확하다"는 말에는 서로 다른 두 작업이 섞여 있습니다. 음성을 글자로 옮기는 단계와, 그 거친 글자를 읽을 수 있는 문서로 정리하는 단계입니다. WER은 앞의 것만 봅니다.
- 화자 구분과 자막 시간축은 오류율이 아예 건드리지 않는 영역입니다. 단어를 다 맞혀도 이 둘이 틀리면 결과물은 못 씁니다.
- 도구를 고를 때는 순위표를 보지 말고, 가진 것 중 가장 조건이 나쁜 녹음을 하나 골라 직접 돌려 보세요. 방법은 이 글 끝에 있습니다.
공개된 벤치마크 점수는 어떤 오디오에서 나올까요?
이건 추측할 필요가 없습니다. 공개 벤치마크는 자기가 어떤 음성을 쓰는지 스스로 문서에 적어 두고 있습니다.
음성 인식 연구에서 가장 자주 인용되는 말뭉치인 LibriSpeech는 자기 소개란에서 스스로를 약 1000시간 분량의 낭독된 영어 음성 말뭉치라고 밝히고, 그 데이터가 LibriVox 프로젝트의 낭독 오디오북에서 나왔다고 적어 두었습니다(LibriSpeech ASR corpus, 영문 페이지). 한 사람이, 원고를 보고, 조용한 곳에서 또박또박 읽은 음성이라는 뜻입니다. 같은 페이지는 데이터 묶음을 "clean"과 "other"로 나눠 두었는데, 여기서 말하는 "깨끗함"의 기준선 자체가 이미 낭독 음성입니다.
다국어 쪽도 사정은 비슷합니다. 여러 모델이 다국어 성능 근거로 인용하는 FLEURS는 논문 초록에서 이 데이터셋을 102개 언어를 아우르는 병렬 음성 데이터셋이라고 소개하면서, 기계 번역 벤치마크인 FLoRes-101 위에 구축했고 언어당 약 12시간 분량의 음성이 딸려 있다고 밝힙니다(FLEURS 논문, arXiv, 영문 페이지). 기계 번역 평가용 문장들을 읽어서 만든, 언어당 열두 시간 남짓한 데이터라는 뜻입니다.
공개 순위표가 무엇을 재는지도 문서에 그대로 적혀 있습니다. Open ASR Leaderboard 저장소는 다국어 벤치마크가 앞서 말한 FLEURS를 포함한 세 개의 공개 데이터셋으로 구성된다고 적고, 평가 스크립트가 실행을 마치면 단어 오류율과 RTFx(처리 속도 지표)를 출력한다고 설명합니다(Open ASR Leaderboard 저장소, 영문 페이지). 즉 순위표가 알려 주는 것은 정해진 공개 말뭉치에서의 단어 오류율과 처리 속도입니다. 화자를 제대로 갈랐는지, 자막 시간축이 영상에 맞는지는 그 숫자 안에 들어 있지 않습니다.
여기까지 아무도 속이지 않았습니다. 각 벤치마크는 자기가 무엇인지 정확히 밝히고 있습니다. 문제는 그 숫자가 제품 홍보 문구로 옮겨질 때, 어떤 오디오에서 나왔는지가 함께 옮겨지지 않는다는 데 있습니다.
WER은 무엇을 세고, 무엇을 못 보나
Microsoft의 음성 서비스 문서는 이 지표를 한국어로 명확하게 정의해 둡니다. "모델 정확도를 측정하기 위한 업계 표준은 WER(단어 오류 비율)입니다. WER은 인식 도중 식별된 잘못된 단어 수를 센 다음, 합계를 휴먼 레이블 대화 기록에 제공된 총 단어 수로 나눕니다"(사용자 정의 음성 모델 정확도 테스트).
같은 문서가 오류를 세 가지로 나눕니다.
- 삽입(I): 가설 전사에서 잘못 추가된 단어
- 삭제(D): 가설 전사에서 인식되지 않은 단어
- 대체(S): 기준 전사와 가설 전사 간에 교체된 단어
셋은 그대로 더해진 뒤 전체 단어 수로 나뉩니다. 여기에 이 지표의 한계가 드러납니다. 조사 하나가 빠진 것과, 회사 이름이 다른 회사 이름으로 바뀐 것이 똑같이 한 개로 계산됩니다. 회의록에서 앞의 오류는 아무도 눈치채지 못하고, 뒤의 오류는 문서를 못 쓰게 만듭니다. 그런데 점수는 같습니다.
같은 문서는 오류가 어디서 오는지도 알려 줍니다. "많은 삭제 오류가 발생하는 경우 일반적으로 오디오 신호 강도가 약하기 때문입니다. … 삽입 오류는 오디오가 시끄러운 환경에서 녹음되고 크로스토크가 표시되어 인식 문제가 발생할 수 있음을 의미합니다. 대체 오류는 도메인 특정 용어의 샘플이 인간이 라벨링한 전사나 관련 텍스트로 충분히 제공되지 않을 때 자주 발생합니다."
한국어 업무 녹음을 떠올려 보면 이 세 줄이 그대로 진단표가 됩니다. 회의실 끝자리 목소리가 작으면 삭제 오류가, 여러 명이 겹쳐 말하면 삽입 오류가, 사내 용어와 영어 제품명이 촘촘하면 대체 오류가 늘어납니다.
문서에는 이런 문장도 있습니다. "음성 인식 시나리오는 오디오 품질과 언어(어휘 및 말하기 스타일)에 따라 달라집니다." 이어지는 표는 콜 센터, 음성 도우미, 받아쓰기, 영상 자막을 나란히 놓고 각각 기대 품질과 주로 나는 오류 종류가 다르다고 정리합니다. 하나의 점수가 모든 상황을 대표할 수 없다는 걸 지표를 만든 쪽에서 먼저 말하고 있는 셈입니다.
WER이 못 보는 층이 하나 더 있습니다. 같은 문서는 문장 부호나 표기 형식까지 보려면 토큰 오류율(TER)이라는 별도 지표가 필요하고, TER는 "문장 부호, 대문자 표시 및 ITN과 같은 표시 형식 측면을 고려한다"고 설명합니다. 읽을 수 있는 문서를 만드는 일에서 문장 부호와 줄바꿈이 얼마나 중요한지 생각하면, 단어만 세는 지표가 왜 부족한지는 분명합니다.
가장 위험한 오류는 매끄러운 오류입니다
앞의 세 줄 중에서 실무자가 가장 신경 써야 할 것은 대체 오류입니다. Microsoft 문서가 짚은 대로 이 오류는 "도메인 특정 용어" 위에서 자주 납니다. 그리고 대체 오류의 결과물은 눈에 띄지 않습니다.
가정해 봅시다. 제품 회의에서 담당자가 "이번엔 LX-820 라인으로 갑니다"라고 말했는데, 받아쓰기 결과에는 제품 코드가 LX-8200으로 적혀 있습니다. 문장은 흠잡을 데가 없습니다. 문법도 깔끔하고, 문장 부호도 제자리에 있고, 구어체도 잘 정돈돼 있습니다. 단어 오류율로 보면 긴 문단 안의 한 개 — 거의 잡히지 않습니다. 하지만 이건 사실이 바뀐 것입니다. 다른 제품, 다른 결정.
거친 오류는 안전합니다. 읽는 사람이 바로 알아보고 원본을 다시 듣습니다. 매끄러운 오류는 그대로 회의록에 실려 공유되고, 몇 주 뒤에 문제가 됩니다. 그리고 이런 오류가 가장 잘 나는 오디오가 바로 한국어 업무 녹음입니다. 한국어 문장 사이에 영어 약어, 제품 코드, 회사명이 계속 끼어드는 회의와 인터뷰가 정확히 그 조건이기 때문입니다.
공개된 어떤 정확도 점수도 이 오류를 따로 알려 주지 않습니다. 순위표는 오류의 개수를 알려 주지, 그 오류가 여러분의 문서를 못 쓰게 만드는 종류인지 아닌지는 알려 주지 않기 때문입니다. 실무에서 이 격차를 줄이는 방법은 두 가지뿐입니다. 고유명사를 미리 도구에 등록해서 애초에 틀릴 여지를 줄이거나, 결과물에서 이름·숫자·제품명만 표적으로 훑어보는 것입니다.
"정확하다"는 말에는 두 가지 작업이 섞여 있습니다
대부분의 사람이 전사 정확도를 말할 때, 실은 완전히 다른 두 가지 작업을 하나로 묶어서 부르고 있습니다.
첫째, 음성을 글자로 옮기는 단계입니다. 오디오가 들어가고, 시간축이 붙은 거친 텍스트가 나옵니다. WER이 재는 층이 여기입니다.
둘째, 텍스트를 정리하는 단계입니다. 그 거친 텍스트를 사람이 읽을 수 있는 문서로 만드는 일입니다. 잘못 들은 단어를 고치고, 구어체를 정돈하고, 문장 부호와 띄어쓰기를 복원하고, 군더더기를 걷어내고 — 그러면서 사실은 하나도 건드리지 않는 것.
두 단계는 각자 다른 방식으로 실패합니다. 원본 텍스트는 좋은데 시간축이 밀려 자막으로 못 쓰는 경우가 있고, 시간축은 정확한데 브랜드명을 틀리는 경우가 있습니다. 정확도 백분율 하나로는 둘 중 어느 것도 잡히지 않습니다.
여기서 한 가지가 더 갈립니다. 같은 오디오라도 자막을 만들 때와 녹취록을 만들 때 좋은 출력의 모양이 다릅니다. 자막은 시간에 맞춰 짧게 끊긴 줄이 필요하고 관례상 문장 부호를 넣지 않습니다. 녹취록은 반대로 문장 부호와 문단이 있어야 읽힙니다. 그래서 "가장 정확한 모델"이라는 질문은 애초에 절반만 성립합니다. 무엇을 만들려는지를 먼저 정해야 답이 나옵니다.
그래서 우리는 모델을 어떻게 고르나
우리 쪽 방침은 단순합니다. 소스 언어와 사용 목적에 따라, 그때 가장 좋은 성능을 내는 음성 인식 모델로 전사를 보냅니다. 한 공급업체에 묶여 있지 않습니다. 앞 절에서 본 대로 좋은 출력의 모양이 자막이냐 녹취록이냐에 따라 달라지기 때문에, 라우팅은 언어만이 아니라 용도까지 함께 봅니다.
Subanana도 처음에는 음성 인식 모델을 하나만 썼습니다. 실제 오디오에서 없는 말을 지어내거나 있는 말을 놓치는 일이 관측되면서 여러 모델로 옮겼습니다. 단일 공급업체는 우리가 고른 선택지가 아니라, 운영 데이터가 밀어낸 선택지였습니다.
언어별 벤치마크는 내부적으로 유지합니다. 어떤 모델로 보낼지 정하는 데 쓰는 자료입니다. 그 수치를 블로그에 옮기지는 않습니다. 우리 샘플과 우리 기준에 묶인 값이라 다른 조건에서는 그대로 성립하지 않고, 결국 이 글이 처음부터 지적한 바로 그 문제 — 남의 조건에서 나온 숫자를 내 조건에 적용하는 문제 — 를 한 번 더 만드는 일이기 때문입니다. 대신 구조를 공개합니다.
- 품질 문제가 감지되면 자동으로 다른 모델로 다시 돌립니다. 한 모델의 출력에서 문제가 보이면 해당 구간을 평가를 거친 다른 모델로 보냅니다. 이 재시도는 여러분의 사용 시간에서 다시 차감되지 않습니다. 파일 하나는 내부적으로 몇 번을 다시 돌리든 한 번만 계산됩니다.
- 편집기의 교정 제안은 잘못 들은 단어와 동음이의 오표기로 범위가 한정돼 있습니다. 적용 여부는 사용자가 하나씩 고릅니다. 조용히 자동으로 바뀌는 일은 없습니다. 앞 절의 제품 코드 사례를 생각하면, 이 판단을 사람 손에 남겨 두는 것이 왜 중요한지 분명해집니다.
- 자막 한 줄에 글자가 너무 많거나 적은 자리는 규칙 기반으로 표시합니다. AI가 자신 없어 하는 곳을 알려 주는 기능이 아니라, 읽는 속도를 계산해 걸러 내는 결정론적 검사입니다.
- 고유명사는 미리 등록할 수 있습니다. 회사명, 사람 이름, 제품명, 사내 용어를 워크스페이스 전체 목록이나 프로젝트별 목록으로 넣어 두면 그 표기를 우선 씁니다. 엑셀이나 CSV로 한꺼번에 넣는 것도 됩니다. 대체 오류가 도메인 용어에서 난다는 Microsoft 문서의 지적에 대한 가장 직접적인 대응입니다.
- 전사 모드에서는 문장 부호와 문단 나누기가 기본으로 복원됩니다. 자막 모드에는 적용되지 않습니다. 자막은 관례상 문장 부호를 넣지 않기 때문입니다.
지원 언어는 한국어를 포함해 95개 이상입니다. 회의 기록 관점에서 이걸 어떻게 쓰는지는 회의록 작성법에, 인터뷰나 연구 녹음 쪽은 녹취록 만드는 법에 정리해 두었습니다. 요약 단계에서 모델마다 결과가 어떻게 갈리는지는 회의 요약에 가장 좋은 LLM에서 따로 다뤘습니다.
화자 구분과 시간축 — 오류율이 건드리지 않는 두 가지
단어를 전부 맞혀도 결과물을 못 쓰게 만드는 요소가 둘 있습니다. 둘 다 WER 안에 들어 있지 않습니다.
화자 구분. 회의록에서 "누가 말했는가"는 "무슨 말이 나왔는가"만큼 중요합니다. 그런데 이건 모델의 실력만으로 결정되지 않습니다. Google Cloud의 한국어 문서는 화자 분할 기능을 "화자가 바뀌는 시점을 감지하고 오디오에서 감지된 개별 음성에 숫자로 라벨을 지정합니다"라고 설명하면서, "예상되는 화자 수에 따라 min_speaker_count 및 max_speaker_count 값을 설정해야 합니다"라고 못 박습니다(여러 화자의 오디오 스크립트 작성). 화자 수는 여러분이 넣는 입력값이라는 뜻입니다. 여기가 틀리면 단어를 다 맞혀도 발언 귀속이 어긋납니다. Subanana의 전사 모드에도 화자 수 설정이 있고, 직접 입력하거나 자동 감지에 맡길 수 있습니다. 참석 인원이 확실하다면 직접 넣는 쪽이 안정적입니다.
시간축. 텍스트가 좋다고 시간축이 좋은 건 아닙니다. 읽기용 녹취록이라면 자막 줄이 몇 초 밀려도 문제가 없지만, 영상에 얹는 자막이라면 그 밀림 하나로 결과물 전체를 못 씁니다. 앞서 본 대로 공개 순위표가 보고하는 값은 단어 오류율과 처리 속도입니다. 시간축이 영상에 맞는지는 거기 없습니다. 확인할 방법은 하나뿐입니다. 자막을 켜고 영상을 직접 재생해 보는 것.
이 두 가지가 순위표로는 절대 비교되지 않는 항목입니다. 그래서 실제 도구 선택은 순위표가 아니라 여러분의 파일 위에서 끝납니다.
정리된 결과물을 볼 때 확인할 여섯 가지
받아쓰기 결과를 받았을 때 무엇을 봐야 하는지, 순서대로 정리하면 이렇습니다. 위에서 아래로 갈수록 눈에 덜 띄고, 아래로 갈수록 나중에 사고가 납니다.
- 잘못 들은 단어가 고쳐졌는가. 가장 알아보기 쉬운 층입니다.
- 구어체가 읽을 수 있는 문어체로 정리됐는가. 말한 그대로가 필요한 문서가 아니라면, 정리되지 않은 구어체는 그 자체로 다시 손볼 일감입니다.
- 군더더기가 걷혔는가. "어", "그", 반복되는 시작 어구가 남아 있으면 읽는 속도가 눈에 띄게 떨어집니다.
- 사실이 그대로인가. 이름, 숫자, 고유명사. 이 항목이 이 목록에서 가장 중요하고, 가장 확인하기 귀찮습니다.
- 하지 않은 말이 덧붙지 않았는가. 화자가 말하지 않은 설명이 대괄호 주석으로 들어가 있지 않은지 봅니다.
- 끝까지 정리됐는가, 아니면 명백한 오류가 남았는가. 절반만 정리된 결과물은 손대지 않은 것보다 판단을 어렵게 만듭니다.
네 번째 항목이 이 글의 요지입니다. 나머지 다섯은 눈으로 훑으면 보이지만, 네 번째는 표적을 정하고 찾아야 보입니다.
그럼 직접 어떻게 확인하면 되나요
평가 프레임워크를 갖추지 않아도 벤치마크 함정은 피할 수 있습니다. 원칙은 단순합니다. 내 오디오로 시험하고, 나에게 중요한 것으로 판단하는 것.
- 깨끗한 샘플 말고, 가진 것 중 가장 조건이 나쁜 녹음을 쓰세요. 사투리가 섞이고, 말이 겹치고, 전문 용어가 나오고, 중간에 영어가 끼는 파일. 도구의 차이는 거기서 갈립니다. Microsoft의 문서도 정확도 테스트에 "30분~5시간의 대표 오디오"를 준비하라고 하고, "모델에 사용한 것과 다른 음향 데이터 세트를 선택하는 것이 중요합니다"라고 덧붙입니다. 만드는 쪽에서도 내 조건으로 재라고 말하고 있는 것입니다.
- 텍스트만 보지 말고 시간축을 확인하세요. 자막을 켜고 영상을 재생해 보면 됩니다. 밀린 자막은 텍스트 비교로는 안 보이고, 화면에서는 즉시 보입니다.
- 사실이 바뀐 곳을 표적으로 찾으세요. 이름, 숫자, 제품명, 브랜드만 따로 훑어보세요. 매끄럽게 읽히는데 숫자가 틀린 결과물이, 눈에 띄게 거친 결과물보다 나쁩니다.
- 원본 텍스트가 아니라 완성된 결과물로 판단하세요. 여러분이 실제로 쓰는 건 교정과 서식이 끝난 문서입니다. 그러니 그것을 평가하고, 거기까지 손이 얼마나 더 갔는지도 함께 세세요.
- 주기적으로 다시 시험하세요. 모델은 바뀝니다. 이번 분기에 여러분의 언어에 가장 좋았던 도구가 다음 분기에도 그렇다는 보장은 없습니다.
1번은 지금 바로 해 볼 수 있습니다. 무료 AI 온라인 필사 도구에 가장 까다로운 녹음을 넣고, 2번부터 4번까지를 직접 확인해 보세요. 무료 플랜에서는 파일마다 앞부분 15분까지 결과를 미리 볼 수 있습니다. 자막·녹취록 파일로 내보내는 것과 편집기에서 텍스트를 선택해 복사하는 것은 유료 플랜의 기능입니다. 품질을 눈으로 확인하는 데는 미리보기만으로 충분합니다. 네이버 클로바노트를 쓰다가 다른 선택지를 보고 있다면 클로바노트 대안 정리가 참고가 될 겁니다.
자주 묻는 질문
WER(단어 오류율)이 낮으면 실제로 더 정확한가요?
꼭 그렇지는 않습니다. WER은 삽입·삭제·대체 오류의 개수를 더해 전체 단어 수로 나눈 값이라, 세 종류를 같은 무게로 취급합니다. 조사 하나를 빠뜨린 것과 회사 이름을 다른 이름으로 바꾼 것이 같은 한 개로 계산된다는 뜻입니다. 문서로 쓸 수 있느냐를 결정하는 건 뒤쪽이므로, 숫자 하나만으로는 쓸 만한지 알 수 없습니다.
공개된 벤치마크 점수를 한국어 회의 녹음에 그대로 적용해도 되나요?
권하지 않습니다. 자주 인용되는 말뭉치들은 자기가 무엇인지 밝혀 두고 있습니다. LibriSpeech는 낭독된 영어 오디오북 약 1000시간이고, 다국어 벤치마크로 쓰이는 FLEURS는 기계 번역 벤치마크 문장을 읽어 만든 언어당 약 열두 시간짜리 데이터입니다. 마이크를 나눠 쓰는 회의실이나 말이 겹치는 인터뷰와는 조건이 다릅니다.
받아쓰기 품질을 직접 확인하려면 어떤 오디오로 테스트해야 하나요?
가지고 있는 것 중 가장 조건이 나쁜 실제 녹음이 좋습니다. Microsoft의 음성 서비스 문서는 정확도 테스트에 30분에서 5시간 분량의 대표 오디오를 준비하라고 안내하고, 학습에 쓴 것과 다른 음향 데이터 세트를 고르는 것이 중요하다고 덧붙입니다. 목적은 좋은 점수를 받는 것이 아니라, 평소 조건에서 무엇이 먼저 무너지는지 보는 것입니다.
화자 수는 미리 지정해야 하나요?
지정할 수 있으면 지정하는 편이 낫습니다. Google Cloud의 한국어 문서는 화자 분할이 화자가 바뀌는 지점을 감지해 숫자 라벨을 붙이는 기능이라고 설명하면서, 예상 화자 수에 맞춰 최소·최대 화자 수를 설정해야 한다고 안내합니다. Subanana의 전사 모드에도 화자 수 설정이 있고, 직접 입력하거나 자동 감지에 맡길 수 있습니다. 인원이 확실하다면 직접 넣는 쪽이 결과가 안정적입니다.
마무리
전사 도구를 비교할 때 봐야 할 것은 기능 개수도, 순위표 위치도 아닙니다. 그 점수가 어떤 오디오에서 나왔는지, 그리고 그 오디오가 여러분의 녹음과 얼마나 닮았는지입니다.
낭독된 오디오북에서 나온 숫자는 낭독된 오디오북에 대해 참입니다. 여러분의 회의실에 대해서는 아무것도 말해 주지 않습니다. 파일 하나만 직접 돌려 보면 그 사실은 십오 분 안에 확인됩니다.