FROM THE WORKSHOP / 작업일지
2026.09.22 작업일지 v1.0.0
느려진 윈도 받아쓰기를 고치고, 맥에서는 음성 인식을 준비하는 시간을 줄였다.
기록 범위는 9월 21일 21시부터 9월 22일 21시까지다. 9월 26일에 완료 근거를 다시 대조해, 작업 제목만 나열하던 본문을 고쳤다.
짧게 말했는데 결과를 오래 기다리는 문제를 추적했다. 윈도에서는 실행 파일에 포함된 음성 인식 엔진의 구성이 원인이었다.
1. 짧은 음성도 오래 걸리던 이유
입타 윈도판에서 몇 초짜리 말을 처리하는 데 지나치게 오래 걸리는 문제가 있었다. 조사 결과, 새 설치 파일에 포함된 음성 인식 엔진이 컴퓨터의 가속 기능을 활용하지 못하는 구성이 먼저 선택되고 있었다. 같은 음성이라도 포장된 실행 환경에 따라 처리 시간이 달라질 수 있는 문제였다.
이 부분을 수정한 0.1.23을 설치하고 공개했다. 마지막에는 사용자가 보내 준 화면에서 입타의 결과가 텔레그램의 실제 입력칸에 들어간 것을 확인했다. 문장 다듬기를 기다리는 시간도 사용자가 수용한 범위로 종결했다. 단순히 검사 프로그램이 성공한 것과 실제 입력 성공을 구분해 확인한 셈이다.
2. 맥에서는 준비를 반복하지 않도록 했다
맥에서는 음성 인식 엔진을 미리 준비하고 다시 쓰는 방법을 실험했다. 동일한 합성 음성으로 비교한 검사에서는 짧은 문장의 처리 중앙값이 약 0.42초에서 0.25초로 줄었다. 실제 텍스트 편집기의 입력칸에 결과가 정확히 들어가는지도 확인했다.
이 수치는 합성 음성으로 수행한 정해진 비교의 결과다. 사용자가 말하기 시작해서 문장 다듬기까지 끝나는 전체 시간이 모두 그만큼 줄었다는 뜻은 아니다. 어떤 구간을 측정했는지 구분해서 남겼다.
3. 한줄일기는 같은 이름의 다른 앱부터 구분했다
한줄일기 (App Store)의 토스 안에서 실행되는 버전도 확인했다. 공유받은 화면이 같은 이름의 다른 앱을 가리키고 있어, 처음에는 아이콘 문제처럼 보였다. 실제 대상 앱의 공유 링크를 다시 대조한 뒤 사용자의 공개 실행과 하트 아이콘 표시를 확인했다.
새 실행 환경으로 옮긴 코드와 공개된 앱은 확인했지만, 옛 환경의 실제 기록이 모두 보존되는지까지 확인한 것으로 쓰지는 않았다. 그 항목은 기존 합의에 따라 이번 출시 조건에서 제외돼 있었다.
4. 확인한 범위를 넘어 말하지 않기
이날의 중심은 새로운 기능의 수보다 사용 흐름이 이어지는지였다. 윈도에서는 말한 결과가 입력칸에 들어가는 것을 확인했고, 맥에서는 준비 시간을 줄이는 실험을 진행했다. 두 결과는 환경도 검증 범위도 다르므로 하나의 속도 개선 수치로 합치지 않았다.
배운 것 — 느린 이유를 찾으려면 사용한 엔진과 실제 설치 파일을 함께 봐야 한다.
— 강대종 / @ssamssae