받아쓰기 앱이 첫 단어를 먹는 이유

핫키를 누릅니다. 말을 시작합니다. 전사본이 두 번째 단어에서, 때로는 세 번째 단어에서 시작하는 걸 지켜봅니다. "재시도 로직을 리팩터링해"가 "로직을 리팩터링해"로 나옵니다. "안 되면 롤백해"는 "되면 롤백해"로 나오는데, 이건 당신을 대신해 타이핑되기에 정말로 위험한 문장입니다. 이 실패는 운영체제 내장 도구부터 전용 받아쓰기 도구까지, 콜드 스타트로 시작하는 마이크 파이프라인 전반에서 쉽게 재현됩니다.

사람들은 이걸 저마다 다르게 말합니다. "앞이 잘려요", "말하기 전에 한 박자 쉬어야 해요", "첫 단어가 늘 없어요". 하지만 하나의 현상이고, 한 번 당하고 나면 누구나 같은 우회 요령을 익힙니다. 키를 누르고, 한 박자 기다리고, 그다음 말하기. 그러니까 이제 당신은 도구의 부족함을 메우려고 하루에 수십 번 작은 미신 같은 의식을 치르고 있는 셈이고, 당신이 도구를 길들인 게 아니라 도구가 당신을 길들인 것입니다.

저도 다른 도구에서 그 의식을 몇 달 치렀습니다. Keebye를 만들면서 그걸 없애는 게 목록의 첫 항목 중 하나였습니다. 해법에 대부분의 앱이 하지 않을 불편한 맞바꿈이 필요하다는 게 드러났기 때문입니다. 그래서 그 맞바꿈도 해법만큼 분명하게 이야기하고 싶습니다.

첫 단어는 왜 잘리나?

이건 어느 벤더의 허술함이 아니라 분야 차원의 문제이고, 물리는 단순합니다. 마이크는 즉각적이지 않습니다.

받아쓰기 앱이 순진한 방식으로 녹음을 시작할 때 — 핫키를 누르고 그다음 마이크를 열 때 — 당신 발화의 첫 샘플이 잡히기 전에 긴 사슬이 돌아야 합니다. OS 오디오 세션이 초기화돼야 합니다. 입력 장치가 깨어나야 하는데, 어떤 하드웨어에서는 말 그대로 예열 시간이 걸립니다. 스트림 형식이 협상되고, 버퍼가 할당되고, 처음 도착하는 버퍼들은 대개 버려지는 쓰레기입니다. 기기와 장치에 따라 그 사슬은 "한 박자"에서 몇 초 사이 어딘가가 걸립니다.

그동안 당신은 — 이미 생각을 완성한 사람은 — 손가락이 키에 닿는 순간에 말을 시작합니다. 사실 대개는 그 순간보다 머리카락 한 올 _먼저_입니다. 누르려는 의도와 말하려는 의도는 뇌에서 함께 출발하고, 발화의 시작은 앱의 준비를 예사로 앞지릅니다. 스트림이 살아나기 전에 말한 모든 것은 앱 입장에서는 존재한 적이 없습니다. 모델은 애초에 잡히지 않은 오디오를 전사할 수 없습니다. 그래서 "로직을 리팩터링해"가 됩니다.

앱은 왜 마이크를 준비 상태로 두지 않고 요청이 올 때 여는 걸까요? 대개는 시민 의식 때문입니다. 마이크를 열어 두면 전력을 조금 쓰고, 훨씬 더 중요하게는 OS의 마이크 표시등이 켜집니다. 사용자는 그걸 "이 앱이 나를 듣고 있다"로 읽는 게 당연하죠. 요청이 올 때만 마이크를 열면 표시등은 정직해지고 앱은 예의 발라 보입니다. 그 대가가 녹음 시작 지점의 콜드 스타트 위험입니다.

해법: 키를 누를 때 이미 듣고 있는 마이크

Keebye는 이걸 양쪽 끝에서 공격하고, 두 메커니즘은 문제의 서로 다른 절반을 풀기 때문에 나눠서 볼 값어치가 있습니다.

따뜻한 마이크. 한 세션의 첫 녹음 이후, Keebye는 오디오 입력 스트림을 열어 둡니다. 그러면 세션 초기화, 장치 깨우기, 스트림 협상 같은 콜드 스타트 사슬이 그 스트림이 건강한 동안 이후의 받아쓰기 전에 이미 끝나 있다는 뜻입니다. 당신의 손가락이 움직이기 전에 스트림은 살아 있습니다.

프리롤. 따뜻한 스트림은 앱의 늦음을 고치지만 당신의 늦음은 고치지 못합니다. 기억하세요, 당신의 발화 시작은 키 누름을 앞지를 수 있습니다. 그래서 Keebye는 가장 최근 오디오를 500밀리초짜리 롤링 버퍼로 유지합니다(16 kHz에서 8,000 샘플, 링 버퍼로). 핫키를 누르면 그 직전 0.5초가 발화의 앞머리로 흘러 들어갑니다. 그 버퍼 안에서 시작된 오디오는 키 누름 전에 버려지는 대신 전사기에 넘어갑니다.

합친 결과는 이렇습니다. 반복 받아쓰기에서는 따뜻한 스트림과 500 ms 프리롤이 발화가 키 누름 직전이나 그와 동시에 시작하는 흔한 경우를 감당합니다. 그 경계 안에서는 의식 같은 멈춤이 필요 없어집니다. 녹음 시작보다 0.5초 넘게 앞서 말한 단어는 되살릴 수 없고, 세션의 첫 받아쓰기는 여전히 평범한 스트림 시작 지연을 치릅니다.

맞바꿈, 그대로 말하자면

여기가 제가 묻어 두기를 거부하는 부분입니다. 이 설계의 정직한 대가이니까요. 오디오 스트림이 받아쓰기 사이에도 열려 있기 때문에, 받아쓰지 않는 동안에도 macOS는 마이크를 사용 중으로 표시합니다. 주황색 점이 켜져 있습니다. Control Center(제어 센터)를 보면 Keebye가 마이크를 쓰는 앱으로, 당신이 아무것도 안 하고 있는 바로 그 순간에 올라와 있습니다.

그 시간 동안 실제로 일어나는 일은 이렇습니다. 오디오는 500 ms 링 버퍼로 흘러 들어가 계속 버려집니다. 아무것도 전사되지 않습니다. 아무것도 저장되지 않습니다. 당신이 키를 누르기 전까지 버퍼를 떠나는 건 없고, 0.5초보다 오래된 것은 링에 덮여 영영 사라집니다. 하지만 표시등이 거짓말한다고 주장하지는 않겠습니다. 사실이 아니니까요. 스트림은 열려 있고, "언제든 들을 수 있는 상태"는 이 아키텍처에 대한 공정한 묘사입니다. 당신이 요청하기 전까지 의미 있는 뜻에서 듣는 건 아무것도 없더라도 말이죠.

저는 이 맞바꿈을 눈 뜨고 의도적으로 골랐고, 이유는 이렇습니다. 요청이 올 때 마이크를 여는 방식은 매번 콜드 스타트 위험을 들여옵니다. 잘린 단어, 틀린 문장, 길들여진 멈춤. 따뜻한 스트림 설계의 대가는 주황색 점에 대한 당신의 불편함으로 떨어지고, 그 뒤에는 따져 볼 수 있는 아키텍처가 있습니다. 텍스트 전용 로컬 기록(받아쓰기가 그냥 사라져서는 안 됩니다에 썼습니다), 온디바이스 전사, 저장되지 않는 오디오, 0.5초짜리 링 메모리. 저는 그 점을 감수하겠습니다. 당신이 감수하지 않겠다면 — 그것도 정당한 입장이고, 정말로 다른 도구가 당신에게 맞는 선택일 수 있습니다. 저희 Keebye vs Superwhisper와 Keebye vs Wispr Flow 페이지는 바로 그 판단을 돕기 위해 쓰였습니다.

놀라는 사람이 없도록, 경계 두 개

세션의 맨 첫 받아쓰기는 여전히 평범한 스트림 시작 지연을 겪습니다. 마이크가 따뜻한 건 이미 녹음이 한 번 있었기 때문입니다. 첫 번째는 여전히 설정 비용을 치릅니다. 이후의 받아쓰기는 스트림이 열려 있는 동안 이득을 봅니다.

프리롤은 500밀리초이고, 500밀리초는 한 박자이지 한 문장이 아닙니다. 버퍼는 자연스러운 경우, 즉 키 누름보다 살짝 먼저 시작된 단어를 감당합니다. 문장을 다 말하고 그제야 키를 눌러야겠다고 떠올렸다면 앞의 단어들은 설계상 사라집니다. 링은 언제나 0.5초만 담고, 그건 정확히 앱이 놀고 있는 동안 의미 있는 오디오를 쥐고 있지 않게 하려는 것입니다. 프리롤이 더 길면 당신의 무심한 시작을 더 많이 잡겠지만, 주변 오디오도 더 많이 메모리에 담아 둘 것입니다. 0.5초가 제가 그은 선입니다.

왜 0.5초가 들리는 것보다 중요한가

잘린 첫 단어는 작은 버그처럼 보입니다. Keebye가 만들어진 그 병렬 레인 워크플로에서는 — 여러 AI 에이전트와 여러 사람 대화를 동시에 모는 제어 채널로서의 목소리, 두 아이, 세 스타트업, 하나의 목소리가 묘사한 그 하루에서는 — 받아쓰기가 하루에 수십 번, 몰아서, 맥락 전환 도중에 일어납니다. 의식 같은 멈춤을 요구하는 도구는 그 모든 묶음에 세금을 매기고, 더 나쁘게는 이따금 당신의 의미를 뒤집어서 보내 버립니다. "되면 롤백해"는 딱 한 번 웃겼습니다.

이 분야의 신뢰성은 하나의 큰 기능이 아닙니다. 더 작은 안전장치들의 축적입니다. 첫머리 오디오를 위한 프리롤, 전사본 뒤의 기록, 그리고 되살릴 수 있는 텍스트 입력 경로. 이 글은 그중 첫 번째에 관한 것이고, 기록에 관한 글이 두 번째를 다룹니다.

Keebye는 macOS용 얼리 액세스 중입니다. 아래에서 무료 체험을 시작해, 반복 받아쓰기로 "안 되면 롤백해"라고 말하고, 첫 단어가 살아남는지 확인해 보세요. 시험은 그게 전부입니다.