받아쓰기가 그냥 사라져서는 안 됩니다
긴 생각을 받아썼는데 텍스트 입력이 실패해서 그냥 사라집니다. 받아쓰기 앱이 당신의 말을 잃는 이유, 그리고 Keebye가 남기는 로컬 텍스트 전용 기록.
정확히 내가 뜻한 그대로였던 90초 — 완성된 PR 설명, 고객에게 보내는 신중한 답장 — 그런데 텍스트가 들어가는 순간에 작은 무언가가 틀어집니다. 목표 창에 포커스가 없었습니다. 붙여넣기가 먹히지 않았습니다. 앱이 딸꾹질했습니다. 그리고 텍스트는 그냥 사라집니다. 어딘가에 저장된 게 아닙니다. 버퍼에 남아 있는 것도 아닙니다. 사라졌습니다. 텍스트를 넣는 일을 전사본의 유일한 사본으로 다루는 모든 받아쓰기 파이프라인은 이 실패 양상을 가집니다.
그 뒤에 오는 건 특정하고 과도한 종류의 분노이고, 저는 그게 정당하다고 봅니다. 잃어버린 초가 핵심이 아닙니다. 핵심은 당신이 일을 했다는 것입니다. 생각을 짜냈고, 잘 말했고, 기계도 제대로 전사까지 했는데, 도구가 전달 문제 하나로 결과를 파괴했다는 것입니다. 두 번째 테이크는 결코 첫 번째만큼 좋지 않습니다. 문단 하나를 기억에 의존해 다시 받아써 본 사람은 알죠. 재현되지 않습니다. 그것의 더 밋밋한 사촌이 나올 뿐입니다.
저도 Keebye가 있기 전에 다른 도구에서 이렇게 받아쓰기를 잃어 봤습니다. 이 앱이 둘러싸고 만들어진 작은 비상사태 중 하나입니다.
받아쓴 텍스트는 왜 그냥 사라지나?
이건 어느 벤더의 버그가 아닙니다. 분야 차원의 설계 결정이고, 이 분야가 왜 그렇게 했는지 이해할 값어치가 있습니다.
받아쓰기 앱은 편집기가 아니라 관입니다. 한쪽으로 발화가 들어가고 다른 쪽으로 텍스트가 나옵니다. 남의 창으로요. 터미널, Slack 입력창, Google 문서 같은 곳으로. 자기 문서가 없고, 바로 그 점이 이 도구들을 보이지 않고 빠르게 만듭니다. 하지만 그건 전사본이 흔히 정확히 한 순간만 존재한다는 뜻입니다. 텍스트가 들어가는 순간이죠. 그리고 그 순간은 파이프라인 전체에서 가장 취약한 단계입니다. 전달되는 그 밀리초에 어느 창이 포커스를 갖고 있는지에, 클립보드가 다른 앱과 경합하지 않는지에, 손쉬운 사용 권한의 기분이 어떤지에, 대상 앱이 합성 입력을 받아들이는지에 달려 있습니다. 그중 하나라도 실패하면 순수한 관에는 뒤에 아무것도 없습니다. 물은 바닥에 쏟아졌습니다.
도구들이 사본 남기기를 꺼려 온 원칙적인 이유도 있습니다. 당신이 받아쓴 모든 것의 기록은 민감합니다. 당신의 받아쓰기는 당신의 메시지이고, 프롬프트이고, 반쯤 만들어진 결정입니다. 그걸 저장하는 벤더는 — 특히 클라우드 근처 어딘가에 — 책임을 만들어 낸 것이고, 그 책임을 피하는 쉬운 길은 아무것도 남기지 않는 것입니다. 사용자는 그 조심스러움을 휘발성으로 물려받습니다. 벤더 입장에서 가장 안전한 받아쓰기는 존재한 적 없는 받아쓰기니까요.
논리는 이해합니다. 다만 저는 그게 엉뚱한 쪽을 위해 최적화한다고 봅니다. 로컬 기록을 남기는 쪽의 실패 양상은 당신 디스크 위의 파일 하나입니다. 아무것도 남기지 않는 쪽의 실패 양상은 창이 포커스를 잃었다는 이유로 증발하는 당신의 작업입니다.
Keebye는 무엇을, 어디에 남기나
그래서 Keebye는 기본으로 켜진 기록을 남기고, 그게 정확히 무슨 뜻인지 적겠습니다. 더도 덜도 아닙니다.
기록이 켜져 있으면 완료된 모든 받아쓰기가 당신 Mac의 로컬 SQLite 데이터베이스에 쓰입니다(배관이 궁금한 분들을 위해 말하자면 rusqlite, WAL 모드). 파일은 앱 지원 디렉터리 — com.keebye.app/keebye.db — 에 있고 기기를 떠나지 않습니다. 동기화도, 업로드도, 그것이 붙은 계정도 없습니다. 당신 디스크 위의, 당신 소유의 파일입니다.
복구는 실제로 텍스트를 잃는 두 가지 방식을 중심으로 설계됐습니다. 흔한 경우 — 방금 1초 전에 텍스트 입력이 실패한 경우 — 에는 가장 빠른 길이 있습니다. 트레이 메뉴에 Copy Last Dictation 항목이 있습니다. 클릭하면 가장 최근 받아쓰기가 클립보드에 올라옵니다. 원래 가야 했던 곳에 붙여넣고 넘어가세요. 더 드문 경우 — "화요일에 뭔가 받아썼는데 그게 다시 필요해" — 는 Dictation History… 를 거칩니다. 전체 목록이 있는 창이고, 검색이 되며, 항목별 삭제와 판을 통째로 비우고 싶을 때를 위한 전체 지우기가 있습니다.
보존 기간은 30일이고 자동으로 강제됩니다. 정리는 데이터베이스가 열릴 때 한 번, 그리고 텍스트가 들어갈 때마다 한 번 더 돌아가므로, 그 창은 "대략 30일, 우리가 시간 날 때"가 아니라 진짜 30일입니다. 그리고 예전의 휘발성 동작을 원한다면 — 그래야 할 사람들이 있고 곧 이야기하겠습니다 — 기록은 설정(history_enabled)이고, 끄면 아무것도 기록되지 않습니다.
텍스트만. 오디오는 절대로.
제가 가장 신경 쓰는 부분은 이 기록이 무엇이 _아닌지_입니다. 텍스트뿐입니다. Keebye의 기록 스키마에는 오디오 열이 없습니다. 기본값이 꺼짐인 오디오 보존 설정이 아니라, 열 자체가 없습니다. 녹음 자체는 결코 저장되지 않습니다. 이건 설계에 의한 구조입니다. "안드레이한테 마이그레이션이 일주일 밀린다고 답해"라는 전사본만 해도 충분히 민감한데, 그걸 말하는 당신 목소리에 타임스탬프까지 붙은 건 다른 차원의 산물이고, 저는 앱이 그걸 쌓아 둘 능력을 갖는 것을 원하지 않았습니다.
글자 수에 비해 중요한 뉘앙스가 하나 더 있습니다. 보안 필드 — 비밀번호 형식 입력란 — 에 받아쓰면 기록은 그것을 남기지 않습니다. 텍스트 흔적조차 잘못된 유일한 자리가, 저희가 흔적을 남기지 않는 유일한 자리입니다.
이건 앱의 나머지와 같은 태세입니다. 음성 인식은 온디바이스로 돌고, 그 이야기는 자기 언어로 받아쓰기의 맥락에서 썼습니다. 다만 기록은 그 태세가 시험받는 자리입니다. 기록은 Keebye가 당신의 말을 조금이라도 남기는 유일한 곳이니까요. 로컬, 텍스트 전용, 스스로 삭제. 그게 기본 켜짐을 얻어 낼 만한 모양이라고 느꼈습니다.
솔직한 한계
늘 그렇듯 솔직함의 절입니다.
다시 들을 수 없습니다. 텍스트 전용은 양날입니다. 전사가 틀렸다면 — 모델이 이름을 잘못 듣거나 숫자를 망가뜨렸다면 — 기록은 그 틀린 텍스트를 충실하게 보존하고, 논쟁을 끝내 줄 오디오는 설계상 사라졌습니다. 대부분의 복구 상황에서는 상관없습니다. 실패한 건 텍스트 입력이지 전사가 아니었으니까요. 하지만 받아쓰기 기록을 음성 메모 보관함으로 원했다면, 이건 일부러 그게 아닙니다.
30일은 30일입니다. 기록은 안전망이지 보관소가 아닙니다. 어떤 받아쓰기가 한 달 너머까지 중요하다면, 그것의 집은 앱의 데이터베이스가 아니라 당신이 받아쓴 그 문서입니다. 정리는 묻지 않습니다.
로컬 전용은 로컬 전용입니다. 당신의 기록은 기기를 따라다니지 않습니다. 데스크톱에서 한 받아쓰기는 노트북에서 되살릴 수 없습니다. 저는 이걸 프라이버시 기능으로 내놓고 있고 실제로 그렇습니다. 전송되는 게 없으니 동기화되는 것도 없죠. 하지만 이게 한계이기도 하다는 걸 아닌 척하지 않겠습니다. 둘 다입니다. 여기에 기대기 전에 당신에게는 어느 쪽인지 알아야 합니다.
그리고 경계에 놓인 경우. 당신의 위협 모델이 _흔적을 아예 남기지 말라_고 한다면 기록을 끄세요. 설정 하나이고, 앱은 그걸 완전히 존중합니다. 기본 켜짐은 지난 화요일의 문단을 되찾고 싶어 하는 대다수 사용자에게 맞는 선택입니다. 나머지에게 함정이 되어서는 안 되겠죠.
일에는 단일 실패 지점이 없어야 합니다
이 기능이 존재하는 더 깊은 이유는 이렇습니다. 저는 하루를 병렬 레인으로 굴립니다. 어떤 창에서는 에이전트가 만들고, 다른 창에서는 사람이 기다리고, 목소리가 그 전부를 먹이는 채널입니다. 그 워크플로가 Claude Code를 목소리로 조종하기의 전제 전체입니다. 이따금 자기 화물을 파괴하는 채널은 하루를 얹을 채널이 아닙니다. 개발자는 복구 경로를 기대합니다. 되돌리기, 로그, reflog, 휴지통. 그런데 많은 받아쓰기 흐름은 텍스트 입력이 실패했을 때 그에 해당하는 걸 하나도 내놓지 않습니다.
이 분야의 도구들을 저울질하는 중이라면, 저희 비교는 다른 도구가 빛나는 지점에 대해서도 솔직합니다. Keebye vs Superwhisper와 Keebye vs Wispr Flow. 그리고 사라지는 텍스트에는 형제 같은 불만이 있습니다. 마이크가 깨어나기 전에 받아쓰기의 첫 단어가 먹히는 것인데, 그 이야기는 받아쓰기 앱이 첫 단어를 먹는 이유에 썼습니다.
Keebye는 macOS용 얼리 액세스 중입니다. 아래에서 무료 체험을 시작해 문단 하나를 받아쓰고, 일부러 목표 창을 빗나가게 한 다음, Copy Last Dictation으로 텍스트를 되살려 보세요. 잘못된 포커스는 여전히 복구 한 단계를 치르게 하지만, 더 이상 그 생각까지 치르게 하지는 않습니다.
다음 긴 받아쓰기를 되살릴 수 있게 만드세요
무료 체험을 시작해, 긴 PR 설명을 목소리에 맡기기 전에 Copy Last Dictation을 시험해 보세요.
Start free trialEarly access: we'll email you the moment the macOS build is ready — your 14 days start when you first sign in from the app.
계속 읽기
받아쓰기 앱이 첫 단어를 먹는 이유
핫키를 누르고 말을 시작했는데 첫 단어가 잘려 나갑니다. 콜드 스타트 클리핑이 생기는 이유와, 따뜻한 마이크에 500 ms 프리롤을 더해 고치는 방법.
병렬 에이전트에 프롬프트 받아쓰기, 레인 하나씩
코딩 에이전트를 두세 개 동시에 돌리면 프롬프트 쓰는 일이 병목이 됩니다. 지금 보고 있는 레인을 떠나지 않고 병렬 레인에 먹이를 주는 음성 워크플로.
Claude Code를 목소리로 조종하기: 병렬 레인으로 만들기
AI 코딩 에이전트는 타이핑을 병목으로 만들었습니다. macOS에서 병렬 에이전트 레인을 가로질러 프롬프트와 리뷰와 방향 수정을 받아쓰는 실전 워크플로.