2026년 9월 15일 확인 · 오늘의 AI 생활실험실
회의 녹음을 글로 바꾸는 일에서 정말 아까운 시간은 변환 버튼을 누른 뒤가 아니라, 잘못 적힌 이름과 숫자를 다시 듣고 고치는 순간입니다. Microsoft가 9월 10일 발표한 Azure AI Speech LLM 2607은 이런 다국어 인식과 전문용어 처리를 개선한 업데이트입니다. 무엇이 달라졌는지, 공개 성능표를 어디까지 믿어도 되는지, 우리 녹음으로 어떻게 검증할지를 함께 살펴봅니다.
자료의 범위: 이 글은 공식 문서와 공개 리더보드를 확인한 분석입니다. Azure API로 직접 성능 시험을 수행하지 않았습니다. 아래 활용 사례는 적용 제안이며 비용 계산은 가정입니다. 이미지 3장은 모두 가상의 성인을 표현한 AI 생성 실사형 이미지로, 실제 직원이나 직접 테스트를 촬영한 사진이 아닙니다.
1. 2607 업데이트에서 달라진 핵심
Microsoft는 2605 대비 혼합 언어, 이름·도메인 용어, 문장부호·숫자 표기 개선과 최대 3배 빠른 지연 성능을 발표했습니다. 또한 전문용어를 일반 프롬프트에 섞는 대신 전용 phrase list 매개변수로 전달하는 사용법을 강조합니다. 서비스 쪽에 자동 배포되는 업데이트이며, 발표 본문은 Fast API 이용을 명시합니다. Microsoft 공식 발표
| 변화 | 업무에서 확인할 점 |
|---|---|
| 대화 중 언어 전환 인식 개선 | 한국어 문장 속 영문 제품명이 누락되는지 |
| 숫자·문장부호 처리 개선 | 금액·날짜·소수점·부정 표현이 보존되는지 |
| 전용 phrase list | 중요한 용어의 인식률과 잘못된 삽입을 함께 평가 |
| 2605 대비 최대 3배 속도 주장 | 동일 녹음의 전체 완료 시간을 별도 측정 |
2607은 업데이트 이름이지 API의 model에 임의로 넣을 값이 아닙니다. 기존 Speech 리소스와 선택한 전사 기능을 확인해야 합니다.
2. Fast 전사와 LLM Speech, 무엇을 선택할까
Fast transcription은 녹음 파일을 받아 결과를 동기식으로 돌려주는 전사 API입니다. 녹음을 빠르게 처리한다는 말과, 마이크 입력에 실시간 응답하는 스트리밍 서비스라는 말은 다릅니다. 회의가 끝난 뒤 회의록을 만드는 경우부터 적용하는 편이 평가 범위를 잡기 쉽습니다.
| 기능 | Fast 기본 | LLM Speech | MAI-Transcribe-2 |
|---|---|---|---|
| 음성 전사·화자 구분 | 지원 | 지원 | 지원 |
| 번역 | 미지원 | 지원 | 미지원 |
| 사용자 프롬프트 | 미지원 | 지원 | 미지원 |
| 스테레오 채널 처리 | 지원 | 지원 | 미지원 |
| phrase list·타임스탬프 | 지원 | 지원 | 지원 |
위 표는 공식 기능 비교이지 인식 정확도 순위가 아닙니다. 지원 표시는 모든 언어·설정 조합에서 같은 품질을 보장하지 않습니다. LLM Speech와 MAI-Transcribe-2도 서로 다른 경로이므로 모델별 옵션을 섞지 마세요. Fast transcription 기능·입력 안내
3. 실제 성능: 제공사 측정값부터 분리해서 보기
공식 발표의 숫자와 공개 평가 사이트의 숫자는 출처와 비교 기준이 다릅니다. 먼저 제공사 주장에 어떤 빈칸이 있는지 확인하면 과장된 기대를 줄일 수 있습니다.
| 제공사 발표 항목 | 확인된 내용 | 해석의 한계 |
|---|---|---|
| 속도, Microsoft 내부 평가 | 2605 대비 최대 3배 빠름 | 발표문에 절대 지연·p95·전체 표본 상세 없음 |
| 다국어·고유명사 품질 | 개선 방향을 설명 | 한국어 WER 개선율 수치는 제시하지 않음 |
| 전사 예시 비교 | 두 음성 입력의 결과 예시 | 두 사례로 모든 녹음의 품질을 일반화할 수 없음 |
출처는 위 Microsoft 발표이며 모두 제공사 측정값 또는 제공사 설명입니다. 최대치는 평균치가 아닙니다. 업로드 시간, 파일 길이, 동시 요청, 네트워크 조건까지 합친 업무 완료 시간이 같은 비율로 줄어든다고 계산해서는 안 됩니다. 실제 요금도 응답 대기 시간과 별개로 살펴봐야 합니다.
4. 외부 공개 평가: 영어 WER 4.53%의 의미
9월 15일 열어 본 Open ASR Leaderboard의 최신 표는 9월 11일 갱신 표시였습니다. 기본 영어 단문 평가에서 다음 값이 확인됐습니다. WER은 낮을수록 좋고, 아래 모델들은 속도 지표 RTFx가 NA로 표시되어 있어 속도 순위를 만들 수 없습니다.
| 리더보드 모델 표기 | 평균 WER | 기본 순위 |
|---|---|---|
| zoom/scribe_v2_pro | 4.38% | 1 |
| microsoft/azure-speech-07-2026 | 4.53% | 2 |
| modulate/multilingual | 4.56% | 3 |
| elevenlabs/scribe_v2 | 4.84% | 6 |
| microsoft/azure-speech-06-2026 | 4.91% | 8 |
Open ASR의 실제 표와 About 방법론을 직접 확인했습니다. 기본 10개 데이터셋 항목의 매크로 평균이며 AMI·GigaSpeech·LibriSpeech·비공개 대화 자료 등이 포함됩니다. 선택 항목을 바꾸면 평균과 순위도 바뀝니다. 6월 모델과 7월 모델의 차이는 0.38%포인트지만, 6월 표기를 공식 발표의 2605와 같은 것으로 단정하지 않았습니다.
이는 Microsoft 자체 홍보표와 구분되는 외부 공개 평가입니다. 다만 공동체가 기여하는 리더보드이지, 이 블로그가 독립 재실험한 결과는 아닙니다. 공개 코드와 제출 절차는 확인했지만 이 모델의 개별 실행 로그까지 감사하지 않았습니다. 비공개 세트는 운영진이 평가한다고 설명합니다. 평가 저장소와 재현 절차
가장 중요한 제한은 한국어 회의 점수가 아니라는 점입니다. 또 이 평가는 문장부호·대소문자 등을 정규화하므로 깔끔한 숫자 표기나 회의록 문체의 품질까지 같은 점수로 설명할 수 없습니다. 영어 평균이 좋아도 우리 회사 제품명과 겹쳐 말하는 음성은 따로 검사해야 합니다.
5. 한국어 지원과 이용 범위를 먼저 확인하기
LLM Speech의 공식 입력 언어 목록에는 Korean이 포함됩니다. Speech 언어 표에는 ko-KR이 있고, 지역 표의 Korea Central에는 Fast transcription 지원 표시가 있습니다. 하지만 언어 지원과 리소스 지역 지원, 특정 업데이트의 계정별 배포 여부는 다른 조건입니다. 이 글에서 사용자 Azure 계정의 실제 접근권한을 확인한 것은 아닙니다. 언어 표 · 지역 표
도입 전에는 새 Foundry 포털의 Speech to text에서 Fast transcription을 선택해 테스트 파일을 넣고 Transcript와 JSON을 함께 살펴보세요. 공식 Fast 입력 제한은 5시간 미만이면서 500MB 미만입니다. WAV·MP3 등 지원 형식도 확인해야 합니다. 경계값에 맞춰 대용량 파일을 한 번에 넣기보다 대표 구간으로 먼저 검증하는 방법을 권합니다.
한국어 단일 녹음은 예상 언어를 지정한 경우와 자동 감지를 비교하고, 한영 혼합 녹음은 실제 언어 전환을 담은 별도 세트로 검사하세요. 한국어 지원이라는 한 줄만 보고 사투리, 짧은 약어, 잡음 속 발화를 모두 같은 수준으로 처리한다고 기대하지 않는 것이 좋습니다.
6. 전문용어는 긴 프롬프트보다 관리 가능한 용어 목록으로
Phrase list는 모델을 다시 훈련하는 기능이 아니라, 인식 시 특정 단어를 더 중요하게 보도록 돕는 힌트입니다. 공식 문서는 Fast·실시간·LLM Speech 등의 사용을 안내하며, batch transcription에는 적용되지 않는다고 설명합니다. 힌트가 정답을 강제로 보장하는 것도 아닙니다. Phrase list 공식 가이드
처음부터 회사 용어집 전체를 넣기보다는 자주 틀리는 제품명·프로젝트명·약어 20개 정도로 작게 시작해 보세요. 이는 권장 실험 규모이지 API의 최대 허용 개수가 아닙니다. 어떤 음성에서 틀렸는지, 올바른 표기는 무엇인지, 추가 후 다른 단어가 오인식되는지까지 함께 기록해야 합니다.
예를 들어 가상의 프로젝트명 ‘해온랩’이 반복해서 일반 단어로 바뀐다면 용어 후보에 추가하고, 해당 이름이 전혀 없는 녹음에도 시험합니다. 정답 이름이 더 잘 나오는 것만 보고 성공으로 판단하면, 평범한 대화에 브랜드명을 잘못 끼워 넣는 부작용을 놓칠 수 있습니다. 용어 목록에도 버전과 변경 이유를 남기세요.
7. 개발자가 확인할 요청 구조
공식 LLM Speech 예시는 아래 전사 경로와 api-version=2025-10-15를 사용합니다. enhancedMode를 켜고 task를 transcribe로 지정하는 구조입니다. 여기에 phraseList 같은 설정을 조합할 수 있습니다. 다음은 공식 구조를 바탕으로 만든 설명용 예시이며, 실제 요청을 실행하거나 성공을 확인한 코드는 아닙니다. LLM Speech API 안내
POST /speechtotext/transcriptions:transcribe?api-version=2025-10-15
multipart/form-data:
audio: 사용 권한이 있는 녹음 파일
definition:
{
"enhancedMode": {"enabled": true, "task": "transcribe"},
"phraseList": {"phrases": ["해온랩", "가상프로젝트"]}
}인증은 공식 문서의 Microsoft Entra ID 방식 또는 리소스 키 구성을 따르고, 실제 키는 서버의 비밀 저장소에 둡니다. 블로그 예시·클라이언트 코드·공개 저장소에 넣으면 안 됩니다. 여기서 언어를 생략한 것은 다국어 기본 동작을 설명하기 위한 것이며, 모든 녹음에 생략이 최선이라는 뜻은 아닙니다.
응답 본문의 durationMilliseconds를 요청 지연으로 착각하지 마세요. 오디오 길이와 실제 호출에 걸린 시간은 별도로 기록해야 합니다. 오류가 나면 우선 리소스 주소·API 버전·파일 형식·선택 기능을 대조하고, 같은 파일을 무한 재전송하지 않도록 재시도 횟수와 예산 한도를 둡니다.
8. 가격: 시간당 표시와 초 단위 과금 구분
공식 가격 페이지는 Speech to Text를 초 단위로 과금한다고 설명하고, 현재 LLM Speech가 Fast Transcription과 같은 가격·SKU ID를 공유한다고 안내합니다. 확인한 공개 페이지에서는 금액이 $-로 표시되어 계정·지역별 확정 단가를 확보하지 못했습니다. 이를 무료라고 해석하거나 기억 속 단가로 채우지 않았습니다. Azure Speech 공식 가격
실제 선택한 지역과 계약의 시간당 단가를 C라고 놓으면, 30분 녹음 100개의 단순 전사량은 50시간이고 기본 산술 비용은 50×C입니다. C가 가정상 0.40달러라면 20달러, 1달러라면 50달러입니다. 두 숫자는 현재 Azure 요금이 아니라 예산 민감도를 보여 주는 가정입니다. 할인·부가 기능·저장·네트워크·세금·환율·재시도 비용은 제외했습니다.
비교할 때는 “한 번 호출에 얼마”보다 “검수 완료된 녹음 한 시간에 얼마”를 보세요. 전사 API 비용이 낮아도 이름과 숫자를 고치는 시간이 늘면 전체 비용은 높아질 수 있습니다. 반대로 몇 초 빠른 결과보다 사람의 재청취 시간을 줄이는 것이 더 중요할 때도 있습니다.
9. 회의록·인터뷰·자막에 적용하는 세 가지 흐름
회의록: 전사문에서 곧바로 최종 결정을 자동 확정하지 마세요. 먼저 발언과 시간 정보를 보존하고, 별도 요약 단계에서 결정·담당자·기한을 추출한 뒤 원문 위치로 돌아가 확인하는 흐름을 제안합니다. “아직 확정하지 않았다”라는 발언의 부정이 빠지면 문장이 매끄러워도 잘못된 회의록입니다.
인터뷰: 질문과 답변을 정리하되 실제로 하지 않은 말을 자연스럽게 보충하지 않게 합니다. 녹음 권한이 있는 파일만 쓰고, 사람 이름과 회사명은 필요한 범위의 용어 목록으로 관리하세요. 인용문을 외부에 내보내기 전에는 해당 음성을 재청취하고 편집한 문장과 원발화를 구분하는 절차가 필요합니다.
영상 자막: 전사 정확도 외에 화면에 머무는 시간, 한 줄 길이, 문장 분리, 전문용어 표기의 일관성을 따로 검사합니다. 단어 수준 시간 정보가 있어도 곧바로 보기 좋은 자막이 되는 것은 아닙니다. 조용한 설명 영상과 음악·배경 소음이 섞인 장면을 나누어 샘플을 구성하세요.
세 흐름 모두 원음 → 전사 → 편집·요약 → 검수로 역할을 나누고 원음 위치와 변경 이력을 남기는 것이 핵심입니다.
10. 우리 업무에서 재현하는 30개 녹음 평가
다음은 이 글의 제안이며 이미 수행한 실험이 아닙니다. 조용한 한국어, 한영 혼합, 잡음, 고유명사, 숫자, 겹쳐 말하기를 포함한 녹음 30개를 준비합니다. 각 조건은 같은 원음·지역·기능·동시성에서 3회씩 비교하세요. 먼저 5개로 요청 구성을 확인한 뒤 범위를 늘리면 시행착오를 줄일 수 있습니다.
| 평가 항목 | 기록 방법 | 주의점 |
|---|---|---|
| WER·CER | 사람이 확정한 정답과 단어·문자 오류 비교 | 띄어쓰기·숫자 정규화 규칙을 고정 |
| 이름·금액 정확성 | 핵심 항목 정답 수와 누락·삽입 수 | 전체 평균과 별도로 기록 |
| 완료 시간 | 업로드 시작부터 응답 수신까지 p50·p95 | 소표본 p95를 서비스 보장으로 해석하지 않음 |
| 성공률·재시도 | 전체 시도 중 사용 가능한 결과 비율 | 실패한 요청도 분모에 포함 |
| 업무 비용 | API·저장·재처리와 사람 검수 시간 | 가장 빠른 성공 사례만 선택하지 않음 |
WER은 치환·삽입·삭제를 정답 단어 수로 나눈 값이고, CER은 문자 단위로 계산합니다. 둘은 다른 지표이므로 한 표의 동일 열에 섞으면 안 됩니다. RTFx는 음성 길이를 처리 시간으로 나눈 속도 지표입니다. 한국어 평가에서는 띄어쓰기와 숫자 표기 정책을 먼저 고정하고 원문 정확성과 읽기 편의성을 나누어 채점하는 방법을 권합니다. WER·CER·RTFx 정의
용어 목록이 없는 설정 A와 짧은 목록을 넣은 설정 B부터 비교하면 변경의 효과를 해석하기 쉽습니다. 합격 기준은 “중요한 이름·금액을 사람이 확인하기 전 외부 전송 금지”처럼 실제 위험과 연결하세요. 모델 이름을 가리고 검수하면 새 버전에 대한 기대가 채점에 영향을 주는 것도 줄일 수 있습니다.
11. 자주 생기는 실패와 도입 체크리스트
화자 구분은 사람의 신원을 인증하는 기능이 아닙니다. speaker 번호가 나온다고 그 번호가 특정 직원이라는 뜻은 아니며, 언어 감지가 켜졌다고 화자 라벨도 자동으로 생기는 것이 아닙니다. Fast 요청에서는 diarization을 명시적으로 설정하고 응답의 speaker를 확인해야 합니다. 기능별 요청 속성이 다르므로 실시간 SDK 예시를 그대로 옮기지 마세요. 언어 감지·화자 구분 설정
대표적인 실패는 읽기 좋은 전사문을 사실상 정답으로 취급하는 것입니다. 숫자 한 자리, 부정어 하나, 발언자 한 명의 연결이 달라져도 중요한 의미가 바뀝니다. 낮은 평균 오류율만 보고 검수 단계를 없애기보다, 업무에서 치명적인 필드에 사람 확인을 집중하는 설계가 낫습니다.
- 녹음의 처리 권한과 외부 전송 가능 범위를 확인했는가?
- 선택 리소스·지역·API 버전·기능을 기록했는가?
- 한국어와 혼합 언어를 각각 평가했는가?
- 용어 힌트의 개선과 잘못된 삽입을 모두 확인했는가?
- 실패·재시도·검수 시간을 예산에 반영했는가?
- 원음 보관 기간·접근 권한·삭제 절차를 정했는가?
- 서비스 업데이트 후 같은 회귀 시험을 다시 돌릴 수 있는가?
12. 자주 묻는 질문과 결론
한국어에서도 무조건 3배 빨라지나요?
그렇게 확인되지 않았습니다. 공식 최대 속도 주장은 특정 제공사 평가이고, 공개 영어 리더보드의 Azure 속도 값도 NA입니다. 한국어 원음의 전체 완료 시간을 별도로 측정해야 합니다.
Phrase list를 쓰면 모델을 다시 학습하나요?
아닙니다. 요청 시 인식에 도움을 주는 힌트입니다. 자주 틀리는 용어부터 작은 목록으로 시작하고, 없는 단어가 잘못 추가되는지도 함께 확인하세요.
2607을 쓰려면 기존 앱을 전부 바꿔야 하나요?
Microsoft는 서비스 측 자동 배포를 안내합니다. 다만 LLM Speech·기본 전사·실시간 경로가 동일한 설정이라는 뜻은 아닙니다. 내 애플리케이션이 사용하는 API와 옵션을 확인하고 회귀 시험을 하세요.
회의 요약까지 한 번에 맡겨도 되나요?
전사 품질과 요약 품질은 별개의 문제입니다. 원음과 전사문의 연결을 유지한 뒤 별도 요약·검수 단계로 나누는 방법을 권합니다. 중요한 결정과 금액은 사람이 승인하도록 남겨 두세요.
이번 업데이트의 가치는 순위 한 줄보다 “내 녹음의 이름과 숫자를 덜 고쳐도 되는가”로 판단하는 편이 좋습니다. 공개 영어 점수는 유용한 출발점이고, 최종 선택은 같은 한국어 녹음에 대한 오류·시간·비용·검수 부담을 함께 기록한 뒤 내려야 합니다.
