개발자를 위한 받아쓰기가 영어 전용이어서는 안 되는 이유

대부분의 개발자 도구에는 게으른 전제가 하나 박혀 있습니다. 코드가 영어 키워드로 쓰이니 개발자도 영어로 일할 것이라는 전제입니다. 부쿠레슈티, 상파울루, 바르샤바, 키이우에서 팀으로 일해 본 사람이라면 그게 얼마나 틀린 말인지 압니다.

맞습니다, 함수 이름은 getUserSession이고 커밋 메시지도 아마 영어일 겁니다. 하지만 코드 주변의 모든 것을 보세요. 버그가 보고된 Slack 스레드, 지연을 설명하는 고객 대상 메시지, 마이그레이션 계획을 적은 내부 문서, 외교적 표현이 필요한 코드 리뷰 코멘트, 스탠드업 노트. 이중언어 팀에서는 그 층 전체가 팀의 언어로 일어날 수 있습니다.

그동안 받아쓰기 도구들은 대체로 비영어 발화를 나중에 생각할 것으로 다뤄 왔습니다. 설정 메뉴 어딘가에서 기술적으로 지원되지만, 그걸 위해 설계된 적은 드물고, 앞세워진 적은 거의 없습니다. 받아쓰기가 데모가 아니라 빌더를 위한 진짜 입력 채널이 되려면, 당신이 실제로 생각하는 언어에서 동작해야 합니다.

이중언어의 하루가 평범한 하루입니다

그 결의 촉감은 이렇습니다. 모국어로 생각하고, 영어로 코딩하고, 하루 종일 그 사이를 오갑니다. 루마니아 개발자가 retryWithBackoff를 쓰고, 그다음 Slack으로 옮겨 가 애초에 재시도 로직에 왜 백오프가 필요했는지를 루마니아어로 설명합니다. 독일 엔지니어는 영어 문법으로 된 PR을 리뷰하고 독일어 산문으로 주석을 답니다.

타이핑은 이 이중언어성을 잘 감당합니다. 키보드는 당신이 어떤 언어를 치든 신경 쓰지 않으니까요. 그런데 음성을 더하는 순간, 도구가 갑자기 신경을 쓰기 시작합니다. 받아쓰기가 영어에서만 잘 돌아간다면 코드에 붙은 영어 조각은 받아쓸 수 있어도, 다른 언어로 쓰는 메시지와 문서와 설명은 받아쓸 수 없습니다.

Claude Code를 목소리로 조종하기에서 다룬 병렬 에이전트 워크플로에서는 이 문제가 더 날카로워집니다. 목소리가 여러 레인의 제어 채널이라면 — 한 창에서는 에이전트에게 프롬프트를 주고, 다른 창에서는 동료에게 답하고 — 영어 밖에서 흔들리는 받아쓰기 도구는 정확히 당신 레인의 절반을 망가뜨립니다. 에이전트 프롬프트는 되는데, 팀원에게 보내는 답장은 안 됩니다.

Keebye는 실제로 무엇을 하나

언어 지원에 관한 주장은 받아쓰기 마케팅이 흐릿해지는 지점이니, Keebye가 오늘 구현하고 있는 것을 정확히 적겠습니다. 더도 덜도 아닙니다.

기본 엔진은 영어에 맞춰져 있습니다. 이걸 묻어 두지 않겠습니다. 기본 제공 모델은 빠르고 정확한 영어 받아쓰기에 최적화되어 있습니다. 가장 작은 좋은 기본값이고, 많은 사용자에게는 그 이상이 필요 없기 때문입니다.

다국어 엔진은 일급 옵션이고, 로컬에서 돕니다. 설정에서 Canary 엔진으로 바꾸면 25개 언어의 온디바이스 음성 인식을 쓸 수 있습니다. 불가리아어, 크로아티아어, 체코어, 덴마크어, 네덜란드어, 영어, 에스토니아어, 핀란드어, 프랑스어, 독일어, 그리스어, 헝가리어, 이탈리아어, 라트비아어, 리투아니아어, 몰타어, 폴란드어, 포르투갈어, 루마니아어, 러시아어, 슬로바키아어, 슬로베니아어, 스페인어, 스웨덴어, 우크라이나어. 그리고 당신이 일하는 언어를 고정할 언어 선택기가 함께 있습니다. Keebye의 다른 모든 것처럼 이것도 당신의 Mac에서 돕니다. 자기 언어로 팀에게 말하는 오디오는 기기를 떠나지 않고, 모델을 한 번 내려받고 나면 오프라인에서도 계속 동작합니다.

Apple의 네이티브 엔진도 있습니다. macOS에 이미 들어 있는 음성 인식을 쓰고 싶다면 — 시스템 언어에서 동작합니다 — Keebye는 모델 다운로드 없이 그것을 대신 쓸 수 있습니다.

당신의 전문 용어도 따라옵니다. 커스텀 사전은 엔진과 무관하게 적용되고, 이건 다국어 작업에서 덜이 아니라 더 중요합니다. 모든 팀은 제품 이름과 영어 차용어, 그리고 그것을 감싸는 현지 문법으로 자기만의 크레올을 만들어 내니까요.

그리고 솔직한 경계 하나. 25개 언어는 25개 언어이지 "모든 언어"가 아닙니다. 당신의 언어가 그 목록에 없다면 Keebye의 다국어 엔진은 오늘 당신을 감당하지 못하고, 저희는 그걸 마케팅용 숫자로 올려 잡기보다 그대로 말하는 쪽을 택합니다. (언어를 고정하는 법, 트레이 빠른 전환, 자동 감지가 틀렸을 때 무슨 일이 벌어지는지 같은 일상적인 작동은 받아쓰기 언어를 고정하세요에 있습니다.)

왜 이게 드물고, 왜 그게 기회인가

로컬 우선 다국어 받아쓰기는 정말로 흔하지 않습니다. 클라우드 받아쓰기 제품들은 대체로 가장 넓은 언어 목록을 가지고 있습니다. 큰 서버 모델로 오디오를 보내는 게 언어를 늘리는 쉬운 방법이니까요. 하지만 그건 당신의 발화를 남의 인프라로 흘려보낸다는 뜻이고, 어떤 팀에게는 바로 그 점이 받아들일 수 없는 것입니다. 그 맞바꿈은 Keebye vs Wispr Flow에서 솔직하게 정리했습니다. 반대로 로컬 우선 도구들은 역사적으로 영어를 앞세우고 다른 언어는 체크박스로 다뤄 왔습니다. (같은 질문을 두고 저울질하는 Superwhisper 사용자라면 저희 비교를 읽어 보세요.)

그 결과 진짜 빈틈이 생깁니다. 폴란드어로 받아쓰면서 동시에 오디오를 자기 기기에 두고 싶은 개발자가 설 자리가 별로 없습니다.

이건 개인적인 문제이기도 합니다. Keebye의 창업자 이야기 — 두 아이, 세 스타트업, 하나의 목소리 — 는 마침 국제 스타트업들과 일하는 루마니아어 사용자 빌더의 이야기입니다. 이 글이 묘사하는 바로 그 이중언어 분리를 매일 살아 낸 이야기죠. 다국어 엔진은 시장을 보고 더한 기능이 아닙니다. 창업자가 점심때까지 필요했던 기능입니다.

이게 향하는 곳

저희의 베팅은 단순합니다. 빌더를 위한 음성 입력은 키보드와 같은 기준으로 평가받을 겁니다. 당신의 언어에서 되거나, 고장 났거나 둘 중 하나입니다. "영어 플러스 별표 하나"는 진짜 팀과 부딪히면 살아남지 못합니다.

그 25개 언어 중 하나로 일한다면 아래에서 무료 체험을 시작하세요. 엔진을 Canary로 바꾸고, 언어를 고정하고, 다음 Slack 답장을 실제로 말하는 방식대로 받아쓰세요. 그다음 무엇이 깨졌는지 어떤 언어로든 편한 쪽으로 알려 주세요.