가장 짧은 답은 이렇습니다. 오프라인 받아쓰기가 대개 더 빠르게 느껴지는 이유는 “말을 멈췄다”에서 “텍스트가 나타났다”까지 거치는 단계가 적기 때문입니다. 클라우드 받아쓰기가 더 알맞은 선택일 수도 있지만, 로컬 워크플로에는 없는 네트워크와 업로드 비용을 치릅니다.
TL;DR
- 온디바이스 받아쓰기는 업로드와 원격 처리 경로를 루프에서 없애 줍니다.
- 공유 기록, 서버 측 자동화, 적극적인 다시 쓰기 워크플로가 필요하다면 클라우드 도구도 훌륭할 수 있습니다.
- Apple의 현재 Mac 안내는 받아쓰기 동작이 설정에 따라 다르다는 점을 분명히 밝힙니다. 일반 텍스트 받아쓰기가 온디바이스로 처리되는지 Siri 서버로 전송되는지는 키보드 설정에서 확인할 수 있습니다.
- 음성 제어도 한 번 다운로드한 뒤에는 오프라인으로 사용할 수 있습니다.
- 매일 Mac에서 받아쓰기를 쓴다면 진짜 질문은 정확도만이 아닙니다. 워크플로 지연, 즉 발화할 때마다 하루 종일 기다리는 시간입니다.
- 정확도는 모델 크기만큼이나 입력을 다듬는 방식과 말하는 습관에 좌우됩니다.
정말 중요한 지연 문제
하루에 이백 번 호출하는 도구에서는 모델 품질과 기능 목록이 잘못된 기준입니다. 도구가 어떻게 느껴질지를 예측하는 질문은 더 좁습니다.
말을 멈춘 뒤에 몇 단계가 일어나는가?
지연은 어디서 오는가
이 섹션은 측정이 아니라 메커니즘을 설명합니다. 단계에 이름을 붙이는 것이 목적이므로, 마케팅 페이지의 어떤 숫자를 믿을지가 아니라 내 컴퓨터에서 무엇을 측정해야 하는지 알 수 있습니다.
온디바이스 워크플로의 경로는 보통 다음과 같습니다.
- 오디오를 로컬에서 캡처하고,
- 청크를 로컬에서 처리하거나 스트리밍하고,
- 끝나지 않은 꼬리 부분을 마무리하고,
- 텍스트를 삽입합니다.
클라우드 받아쓰기는 여기에 네트워크 경로가 더해집니다.
- 오디오를 로컬에서 캡처하고,
- 연결을 엽니다(DNS 확인, TLS 핸드셰이크, 때로는 인증),
- 오디오를 업로드하고,
- 원격 추론을 기다리고,
- 결과를 다운로드하고,
- 때로는 텍스트를 또 다른 다시 쓰기나 서식 계층에 통과시킵니다.
두 번째 목록에는 서로 다르게 동작하는 두 가지 특성이 있으니 이해해 둘 만합니다.
연결 설정은 요청마다 대략 고정된 비용입니다. DNS, TLS, 인증에 드는 비용은 두 단어를 받아썼든 두 분을 받아썼든 거의 같습니다. 이 비용은 긴 녹음에서는 분산되지만 5초짜리 메모에서는 전혀 분산되지 않습니다. 그러니 평소 발화가 짧을수록 대기 시간 중 음성 인식과 상관없는 몫이 커집니다. 지속 연결과 스트리밍 프로토콜이 이를 줄여 주기 때문에, “클라우드 대 로컬”이라는 꼬리표보다 구현 세부 사항이 더 중요합니다.
전송 시간은 오디오 길이에 비례합니다. 인식 품질은 일반적으로 압축이 적거나 없는 오디오에 유리하므로, 긴 세션의 페이로드는 작지 않습니다. 안정적인 연결에서는 눈에 띄지 않습니다. 호텔이나 카페 Wi-Fi에서는 바로 이것이 달라지는 변수입니다.
로컬이라고 해서 마법처럼 즉시 끝나는 것은 아닙니다. 말을 멈춘 뒤에도 처리는 일어납니다. 하지만 업로드하고 돌려받는 루프 전체와, 내가 통제할 수 없는 네트워크에 좌우되는 지연 부분이 사라집니다.
발화 길이와 네트워크 조건을 바꿔 볼 수 있는 인터랙티브 데모에서 이 모양을 직접 확인할 수 있습니다: /blog/latency-demo.
윈도잉: 긴 세션도 느려지지 않아도 되는 이유
단순한 로컬 구현은 말이 끝나기를 기다린 다음 녹음 전체를 전사합니다. 이것은 업로드와 같은 확장성 문제를 안고 있습니다. 30분 분량의 오디오는 30분 분량의 오디오이기 때문입니다.
스트리밍 구현은 말하는 동안 제한된 배치 단위로 디코딩해서 이를 피합니다. 말을 멈추면 마지막 미완성 배치만 마무리하면 됩니다.
Voice Type은 이런 방식으로 동작하며, 배치 목표는 29초이고 범위는 15에서 29로 제한됩니다. 배치는 고정 길이 윈도가 아닙니다. 배치기는 발화 구간을 통째로 모으고 경계에서 구간을 반으로 자르지 않으므로, 목표를 넘어가게 될 구절은 대신 다음 배치에서 시작됩니다. 실질적인 결과는 말을 멈춘 뒤의 대기 시간이 세션 길이가 아니라 배치 목표로 제한된다는 것입니다. 2분짜리 받아쓰기와 30분짜리 받아쓰기는 끝날 때 남은 작업량이 같습니다.
이것은 벤치마크가 아니라 아키텍처의 특성입니다. 마지막 처리에 실제로 걸리는 시간은 Mac에 따라 다르며, 직접 측정해 보시기를 권합니다.
클라우드 받아쓰기: 움직이는 부분은 많지만 알맞은 선택일 때도 있습니다
제품이 가치 있는 일을 하고 있다면 클라우드 경로의 추가 단계 하나하나가 그만한 값어치를 할 수 있습니다.
- 팀 기록,
- 계정 단위 동기화,
- 서버 측 프롬프트 또는 템플릿 파이프라인,
- 더 큰 규모의 회의 또는 파일 처리,
- 거친 음성 입력을 개선하는 후처리.
“클라우드는 나쁘다”는 이야기가 아닙니다. 클라우드에는 병목이 될 수 있는 요소가 더 많다는 이야기입니다.
Apple은 어디에 있는가
Apple 자체의 스택이 이제 이 논의의 한가운데에 있습니다.
현재 지원 페이지는 두 가지를 분명히 합니다.
- 일반 텍스트 받아쓰기는 설정에 따라 온디바이스로 처리되거나 Siri 서버로 전송될 수 있습니다.
- 음성 제어는 한 번 다운로드해야 하며, 그 후에는 인터넷 없이 사용할 수 있습니다.
그러니 “Mac 받아쓰기”는 하나의 고정된 아키텍처가 아닙니다. 다음에 따라 달라집니다.
- 하드웨어,
- 언어와 지역,
- 사용하는 기능,
- 받아쓰기를 쓰는지 음성 제어를 쓰는지.
일반적인 비교 글이 빨리 낡는 이유 중 하나입니다. “Mac 받아쓰기”를 마치 하나의 정적인 제품인 것처럼 이야기하기 때문입니다.
매일 쓰는 사용자가 차이를 더 크게 느끼는 이유
일주일에 한 단락만 받아쓴다면 로컬과 클라우드의 차이는 별로 중요하지 않을 수 있습니다.
하루에 수십 번, 수백 번 받아쓴다면 작은 지연이 쌓입니다.
- 연결을 기다리고,
- 업로드가 끝나기를 기다리고,
- 응답을 기다리고,
- 텍스트를 “다듬는” 두 번째 처리를 기다립니다.
온디바이스 워크플로가 힘을 얻는 지점이 여기입니다. 절대적인 지연이 늘 극적인 것은 아닙니다. 비용을 키우는 것은 반복입니다. 최상의 경우보다 일관성이 더 중요합니다. 나쁜 Wi-Fi에서도 예측 가능한 워크플로가, 좋은 Wi-Fi에서는 더 빠르지만 나쁜 Wi-Fi에서는 쓸 수 없는 워크플로보다 낫습니다.
정확도는 모델만의 문제가 아닙니다
모델 크기는 모든 제품 페이지가 맨 앞에 내세우는 숫자이지만, 여러 입력 중 하나일 뿐입니다. 실제 사용에서 정확도는 다음에 좌우됩니다.
- 마이크 품질,
- 방 안의 소음,
- 에코,
- 입력 게인,
- 음성 분할,
- 어휘 불일치,
- 그리고 워크플로가 집중을 깨지 않고 계속 이어 가게 해 주는지 여부.
그래서 “가장 큰 모델을 씁니다”라는 주장만으로는 앱이 Slack, Gmail, Linear에서 실제로 어떻게 느껴질지 알 수 없습니다.
인식 전에 입력 다듬기
음성 모델은 특정한 특성을 가진 오디오로 학습됩니다. 입력이 그 분포에 가까울수록 모델이 추측할 일이 줄어듭니다. 세 가지 조정이 대부분의 일을 합니다.
- 음량을 정규화해 일정한 목표에 맞춥니다. 몸을 앞으로 기울여 말하든 뒤로 기대어 말하든 단어가 비슷한 수준으로 들어옵니다.
- 저주파 럼블을 필터링합니다. 가벼운 하이패스를 사용합니다. 책상 두드리는 소리, 에어컨, 건물 소음에는 음성이 아닌 에너지가 실려 있습니다.
- 노이즈를 인식하는 음성 활동 감지(VAD)를 사용해, 무음과 배경음이 단어인 것처럼 인식기에 전달되지 않게 합니다.
Voice Type은 인식 전에 이 세 가지를 모두 적용합니다. 실시간 받아쓰기의 출시 기본값은 음량 목표 마이너스 16 LUFS와 50 Hz 하이패스이며, 둘 다 앱의 오디오 설정에서 확인하고 조정할 수 있습니다. 출력을 땜질하는 것보다 신호를 개선하는 것이 더 정직하다는 생각에서 나온 설계입니다. 프롬프트에 크게 의존하는 “수정”은 실제로 말한 내용에서 벗어나면서도 전사 결과를 자신 있어 보이게 만들 수 있습니다.
개별 구성 요소에 대한 관련 글: 음성 활동 감지, 16 kHz로 리샘플링.
이 순서로 진행되는 두 단계. 음량 목표는 하나의 숫자가 아니라 오디오가 어떤 경로를 거쳤는지에 따라 달라집니다. 출처: WhisperState+FileTranscription.swift, WhisperState.swift.
문장 부호와 문장 나누기
문장 부호는 잘못되었을 때만 눈에 띕니다. 빠진 마침표. 두 번 들어간 공백. 문장을 갈라놓는 고유명사.
대부분은 분할 문제로 귀결되며, 그래서 입력을 다듬는 방식과 말하는 습관이 직접 영향을 줍니다. 음량이 크게 흔들리면 문장 경계로 읽힐 수 있습니다. 방 안의 소음은 모델이 문장을 확정할 때 쓰는 쉼을 흐리게 만듭니다.
어떤 마이크에서든 도움이 되는 습관:
- 마침표 자리에서 조금 더 길게 쉬세요. 반 박자면 깔끔한 경계 신호를 주기에 충분합니다.
- 정확해야 할 때는 목록의 문장 부호를 소리 내어 말하세요. 촘촘한 목록이나 코드라면 “comma”라고 소리 내어 말하면 추측할 여지가 없어집니다.
- 음량을 일정하게 유지하세요. 크게 말하기보다 마이크에 더 가까이 다가가 말하세요. 깨끗한 신호가 센 신호보다 낫습니다.
- 사용자 지정 단어를 추가하세요. 일반 사전에 없는 제품명과 전문 용어는 등록하면 기준점이 되어, 긴 메모에서 수정이 줄어듭니다.
- 도구가 노이즈 억제를 제공한다면 약하게 유지하세요. 공격적인 게이팅은 자음을 잘라 내고, 잘린 자음은 노이즈보다 더 큰 대가를 치르게 합니다.
어떤 받아쓰기 설정이든 내 컴퓨터에서 시험해 보는 간단한 방법이 있습니다. “period”라는 말을 하지 않고 빈 문서에 이 문장을 읽어 보세요.
Aeloria and Kyran left Eldmere at dawn. They crossed the Kintara ridge before the fog rolled in. Skystack Nova ships next week.
지어낸 고유명사와 평범한 문장 구조가 섞여 있어, 모르는 어휘와 문장 나누기를 한 번에 확인할 수 있습니다. 보통 거리에서 한 번, 마이크를 더 가까이 두고 한 번 실행한 다음 비교해 보세요.
프라이버시는 기능이 아니라 구조적인 차이입니다
온디바이스 받아쓰기에서는 오디오가 기기를 떠나지 않으므로, 읽어야 할 보관 정책도 녹음을 맡길 업체도 없습니다. 클라우드 받아쓰기에서는 설계상 오디오가 기기를 떠나며, 프라이버시 문제는 특정 업체의 처리 방식에 대한 문제가 됩니다.
Voice Type은 받아쓰기를 로컬에서 처리합니다. 선택 사항인 LLM 다시 쓰기는 예외이며, 직접 켜야 하는 옵트인 기능입니다. 텍스트는 우리 서버를 거치지 않고 Mac에서 사용자가 키를 제공한 제공업체로 곧바로 전송됩니다. 자세한 내용은 신뢰 센터와 개인정보 처리방침에서 확인하세요.
Voice Type의 역할
Voice Type은 반복 사용 사례를 중심으로 만들어졌습니다. 단축키를 누른 채 말하고, 놓으면 텍스트가 로컬에서 돌아옵니다. 위에서 설명한 롤링 윈도 동작도 포함됩니다.
다음에 집중하는 도구와는 하는 일이 다릅니다.
- 파일 전사,
- 회의 녹음,
- 클라우드 다시 쓰기,
- 또는 공유되는 서버 측 기록.
구호가 아니라 카테고리를 비교하고 싶다면 이 페이지들이 더 유용합니다.
그래도 클라우드가 더 나은 경우
다음이 필요하다면 클라우드가 여전히 더 알맞습니다.
- 팀 전체가 공유하는 전사본,
- 서버 측 저장과 검색,
- 긴 받아쓰기 초안에 대한 자동 후처리,
- 프라이버시보다 중앙 집중에 의존하는 워크플로,
- 로컬 연산 대신 관리형 인프라.
정직한 결론은 “로컬이 클라우드를 이긴다”가 아닙니다. 이렇습니다.
병목이 상호작용 속도라면 로컬이 이깁니다. 병목이 협업, 서버 측 처리, 중앙 집중형 워크플로라면 클라우드가 이깁니다.
어느 쪽을 선택해야 할까요?
이 기준을 사용하세요.
| 가장 중요하게 생각하는 것은… | 더 알맞은 선택 | | --- | --- | | Mac 앱에 빠르게 반복해서 받아쓰기 | 온디바이스 | | 로컬 프라이버시 모델 | 온디바이스 | | 공유 기록과 서버 측 자동화 | 클라우드 | | 파일 업로드와 전사본 관리 | 클라우드 또는 파일 전사 도구 | | 접근성 방식의 음성 제어 | Apple 음성 제어 |
실천할 다음 단계
아직 결정하지 못했다면 이렇게 해 보세요.
- 며칠 동안 실제 마이크와 실제 앱에서 Apple 받아쓰기를 사용해 보세요.
- 긴 녹음만이 아니라 짧은 발화 뒤의 지연에도 주목하세요.
- 불안정한 네트워크에서 같은 테스트를 반복하세요. 두 아키텍처가 갈리는 곳이 거기입니다.
- 기본 제공 도구로 충분하다면 계속 쓰세요.
- 글쓰기보다 워크플로를 자꾸 생각하게 된다면 전용 로컬 앱을 써 보세요.
로컬 Mac 방식을 알고 싶다면 여기서 시작하세요.
출처
- Apple Support: Dictate messages and documents on Mac
- Apple Support: If Dictation on Mac doesn’t work as expected
- Apple Support: Get started with Voice Control on Mac
- OpenAI research: Whisper overview
- Paper: Robust Speech Recognition via Large-Scale Weak Supervision