음성 입력 아키텍처: Loqua의 3-모델 음성 입력 스택

저는 Shuran이에요. 음성 입력을 매일 쓰는 알고리즘 연구자들로 구성된 작은 팀을 이끌고 있어요. Loqua를 만든 이유는, 우리가 평가한 받아쓰기 도구들 — 대부분 잘 만들어졌고, 대부분 진짜 유용한 도구들 — 이 코드, 다국어 혼용, 앱 인식 포매팅을 시켜보면 모두 같은 천장에 부딪혔기 때문이에요. 그 천장은 구조적인 거지 튜닝 문제가 아니에요. 구조를 바꿔야 한다고 결정한 뒤 우리가 도달한 아키텍처가 이거예요.

이건 논문이 아니에요. 블로그 수준의 산책이에요 — 각 레이어 뒤의 직관, 나온 숫자들, 그리고 우리가 이 스택을 실제로 어디에 쓰는지. 더 깊은 학술 컨텍스트를 원한다면 끝의 "더 읽을거리" 섹션에 우리가 참고한 논문들을 적어뒀어요.

Wrap-Whisper의 함정

OpenAI의 Whisper는 영어 음성 인식의 가능성을 바꿔놨어요. 놀라운 모델이에요. Whisper 논문은 약한 지도 학습 오디오 훈련을 스케일링하면, 도메인별 파인튜닝 없이도 다양한 억양, 조건, 99개 언어에 걸쳐 견고한 범용 ASR이 나온다는 걸 보여줬어요. 이 분야의 구조적인 승리죠.

하지만 Whisper는 ASR 모델이지 받아쓰기 제품이 아니에요. "음성을 정확히 받아쓰는 것"과 "편집 없이 이메일에 붙여 넣을 수 있는 텍스트를 만드는 것" 사이의 간극은 커요. Whisper의 출력을 포매팅 레이어에 통과시키는 wrap-Whisper 접근은 그 간극의 일부를 메워줘요. 하지만 우리가 신경 쓴 세 곳에서 실패해요.

• 기술 어휘. Whisper는 "react query"를 듣고 "react query"를 줘요. 코드베이스에서 그게 @tanstack/react-query이고, 패키지 임포트가 원하던 거라는 걸 몰라요. 기술 어휘 NER은 음소를 듣는 모델이 아니라 주변 컨텍스트를 보는 모델이 필요해요.
• 앱 인식 포매팅. Whisper는 받아쓰기를 해요. Slack에 있는지 파이썬 파일에 있는지는 몰라요. 위에 포매터를 붙이려면 휴리스틱(부서지기 쉬움)이나 발화마다 무거운 LLM 호출(느리고 클라우드 의존적)이 필요해요.
• 빠듯한 레이턴시 예산 안의 스트리밍. Whisper는 배치 받아쓰기에 탁월해요. 스트리밍, 저지연, 온디바이스 Whisper는 타협(더 작은 모델, 낮은 정확도)이나, 모델 구조와 싸우는 공격적인 엔지니어링이 필요해요.

연구 프로토타입으로 wrap-Whisper 경로를 시도해봤어요. 아이디어를 검증하기엔 충분히 좋았어요. 매일 쓰는 도구로 쓰기엔 충분하지 않았어요.

3-모델 직관: 다른 종류의 음성 인식 스택

직관은 이거예요 — 음성 입력은 세 가지 일이고, 같은 모델은 셋 다 못 해요. 세 가지 일:

1. 단어를 듣기. 어쿠스틱-투-토큰. ASR이 잘하는 일이에요.
2. 의도 이해. 군말, 잘못된 시작, 문장 중간 교정을 정리. 기술 엔터티 인식. 사용자가 실제로 무엇을 입력하려 했는지 결정.
3. 올바른 자리에 두기. 출력을 목적지 앱에 맞게 포매팅. 같은 의도가 VS Code에서는 코드로, Slack에서는 Slack 메시지로, Cursor에서는 구조화된 프롬프트로 나오게 만들기.

세 가지를 다 하려는 단일 엔드투엔드 모델에는 어려운 구조적 문제가 있어요. "음소 받아쓰기"의 손실 표면과 "Slack용 포매팅"의 손실 표면이 다른 방향을 가리키죠. 공동 학습은 둘 다 타협해요. 우리 자신의 어블레이션으로 이걸 확인할 수 있어요 — 레이어 2와 3을 멀티태스크 데이터로 학습되는 하나의 트랜스포머로 합쳐봤는데 양쪽 정확도가 모두 떨어졌어요.

셋으로 분할하면 각 모델이 한 가지 일을 잘 할 수 있어요. 비용은 레이어 간 핸드오프의 적은 레이턴시인데, 이건 모든 걸 단일 파이프라인으로 뉴럴 엔진 위에서 돌려서 회수해요. 그게 Loqua 음성 입력 아키텍처의 핵심이에요 — 거대한 모놀리식 받아쓰기 엔진이 아니라, 각 레이어가 문제의 한 부분에 맞춰 학습된 작은 받아쓰기 모델 스택이에요.

레이어 1: 음성 인식

음성 입력 → 토큰 시퀀스. 이건 Whisper를 직접 감싼 것이 아니라 과제 특화 음성 인식기예요. 아키텍처 선택은 타협할 수 없는 세 가지 제약에 의해 결정됐어요.

• 스트리밍 우선. 화자가 발화를 끝내기 전에 출력이 시작돼요. 그래서 기본값으로 전체 오디오 시퀀스에 대한 비인과적(non-causal) 어텐션은 배제돼요 — 우리는 스트리밍 친화적인 변형을 써요.
• 온디바이스 뉴럴 엔진 호환성. 모델 크기와 연산자 선택은 뉴럴 엔진을 통한 Apple의 Core ML 위에서 효율적으로 실행되는 것에 의해 제한돼요. 이건 실제 제약이에요 — 논문에서는 괜찮아 보이는 연산자가 뉴럴 엔진 경로에서 떨어져 나와 CPU 바운드가 될 수 있어요.
• 저음량 견고성. 학습 데이터에 의도적으로 속삭임 정도의 입력(카페에서 조용히, 늦은 밤에 받아쓰는 사람들)을 포함시켜요. 대부분의 범용 ASR 학습 데이터는 일반 음량이고, 속삭임 음량은 명시적인 커버리지가 필요해요.

이 레이어의 출력은 타이밍과 신뢰도 점수를 가진 토큰 시퀀스예요. 최종 텍스트가 아니라, 다음 레이어가 정리할 원시 인식 결과예요.

레이어 2: 언어 인텔리전스

토큰 시퀀스 → 정리되고 의도가 해결된 텍스트. 사용자가 체감하는 품질의 대부분이 여기 살기 때문에, 가장 큰 연구 투자를 하는 곳이에요.

이 레이어의 일: 음성 모델이 들은 것을 받아서 사용자가 의미한 것을 만드는 것. 세 가지가 병렬로 일어나요.

• 군말과 잘못된 시작 제거. "음, 그래서, 기본적으로, 우리는 — 아 잠깐, 다시 시작할게 — 우리는 이걸 캐싱해야 해"가 "우리는 이걸 캐싱해야 해"가 돼요. 문장 중간 교정은 존중되고, 헛기침은 사라져요.
• 기술 어휘에 대한 NER. 흔한 라이브러리, 프레임워크, 모델 패밀리, 파일 확장자, 터미널 명령, 관용적인 API 표면의 이름을 학습해요. JavaScript 파일 컨텍스트일 때 "React query"가 @tanstack/react-query가 돼요. 내부 목표는 큐레이션된 도메인 내 기술 어휘에서 90% 후반대 인식이라, 흔한 용어마다 개인 사전을 강요받지 않고도 식별자가 제대로 나와요.
• 구조 형성. 출력이 문장인지, 글머리 리스트인지, 마크다운 표인지, 코드 주석인지는 다음 레이어(멀티모달 컨텍스트)가 목적지에 대해 말하는 것에 따라 여기서 결정돼요.

이 레이어는 파라미터 수로는 스택에서 가장 작은 모델이지만, 사용자 경험 임팩트는 가장 커요. 나머지 둘을 합친 것보다 더 많은 팀 시간을 여기에 썼어요.

레이어 3: 멀티모달 컨텍스트

앱 상태 + 화면 + 커서 → 포맷 디렉티브. 이게 옴니모달 레이어예요 — 그리고 이게 우리가 이걸 그냥 "받아쓰기 앱"이라 부르지 않는 이유예요. Loqua의 일은 받아쓰는 게 아니에요. 당신이 의미한 것을, 당신이 의미한 곳에 적는 거예요.

컨텍스트 레이어는 macOS Accessibility를 통해 활성 앱을, (있다면) 선택된 텍스트를, 보이는 인접 텍스트를, 목적지의 구조적 단서(Gmail 작성 vs Slack 스레드 vs VS Code 파이썬 파일 vs Cursor 채팅 패널)를 읽어요. 그리고 언어 레이어가 최종 텍스트를 만드는 데 쓰는 포맷 디렉티브를 출력해요.

더 깊은 직관 — 왜 옴니모달 아키텍처가 음성 입력을 단순히 강화하는 게 아니라 바꾸는지 — 은 별도의 글이에요. 그 흐름을 따라가고 싶다면 음성과 비전의 만남: 옴니모달 모델이 어떻게 컨텍스트 인식 받아쓰기를 가능하게 하는가을 보세요.

우리가 추적하는 숫자들

이건 내부 벤치마크 및 도그푸딩 숫자이지 외부 벤치마크 스위트가 아니에요. 테스트 세트는 우리 자체 기술 어휘, 코드 스위칭 예시, 억양 있는 영어 샘플, 시끄러운 일상 환경을 포함해요. 다음 콘텐츠 단계는 공개 방법론 페이지가 되어야 해요. 그래야 이 숫자들을 손짓 없이 인용할 수 있어요.

우리는 무엇에 쓰는가

이 스택에 대해 가장 중요한 말은, 우리가 그걸 쓰기 때문에 만들었다는 거예요. 팀원 모두가 매일 받아써요 — 커밋, PR, 사내 Slack, 더 긴 기술 글, 그리고 (제 경우엔) 이런 블로그 글의 산문 대부분. 아키텍처를 형성한 결정들은 제품 사양에서가 아니라 실제 사용에서 나왔어요.

일상 사용에서 아키텍처-vs-기능 구분이 드러나는 세 곳:

• 코드 받아쓰기. NER 품질이 코드를 위한 실현 가능한 인터페이스로서의 음성과 장난감으로서의 음성을 가르는 차이예요. 이게 무엇을 가능하게 하는지는 코드 받아쓰기 가이드를 보세요.
• 다국어 코드 스위칭. 사내 Slack의 절반은 중국어와 영어가 섞여 있어요. 언어 레이어는 코드 스위칭된 데이터로 학습돼요(우회가 아니라) — 문장 중간 전환이 모드 토글 없이 동작해요.
• 앱 인식 포매팅. 같은 음성 구절이 VS Code에서는 코드 주석이 되고 GitHub에서는 구조화된 PR 설명이 되는 것 — 그게 음성 입력과 쓸 만한 제품 사이의 차이예요.

우리는 작은 팀이에요. 이 이야기의 솔직한 버전은 — Whisper를 감싼 제품과 3-모델 연구 스택을 동시에 유지할 리소스가 없다는 거예요. 우리 자신을 위한 품질이 필요했기 때문에 구조적인 경로에 베팅했고, 폭이 넓지만 품질이 없는 것보다는 좁지만 품질이 있는 걸 출시하는 쪽을 선택했어요.

2026년에 각 레이어를 어떻게 다시 만들었는가

레이어 1 — 음성 인식. 인식기는 스트리밍, 저음량 발화, 기술 어휘 주변으로 조여졌어요. 더 깊은 산책은 옴니모달 음성 스택의 내부에 있고, 포스트 트레이닝 디테일은 음성 스택의 RL에 있어요.

레이어 2 — 언어 인텔리전스. 언어 레이어는 이제 정리, 엔터티 보존, 앱 인식 구조를 별도의 후처리기가 아니라 하나의 받아쓰기 모델 스택으로 다뤄요. 그곳이 강화 학습이 가장 많이 도움이 되는 곳이에요. 사용자가 가장 적게 편집하는 출력을 고르는 거죠.

레이어 3 — 멀티모달 컨텍스트. 컨텍스트 레이어는 로컬 화면 증거를 중심으로 재구성됐어요. 활성 앱, 선택된 텍스트, 보이는 식별자, 커서 주변. 아키텍처는 보이는 것을 보는 리스너 만들기를 참고하세요.

다음 프런티어는 비단어(non-word) 오디오예요. AED와 오디오 캡셔닝을 옵션이자 로컬 우선 컨텍스트로 활용하는 것. 그 프로토타입 단계 작업은 의미를 가진 소리에서 다뤄요.

더 읽을거리

이 블로그 수준 설명보다 더 깊이 들어가고 싶다면:

• Whisper 논문 (Radford et al., 2022) — 레이어 1에서 참고한 약한 지도 오디오 학습 패러다임.
• Apple Core ML 문서 — 뉴럴 엔진 배포가 실제로 어떤 모습인지.
• 레이어 3 추론에 대해서는 동반 노트인 voice meets vision: omni-modal 받아쓰기를 참고하세요.
• 무엇이 회선을 건너고 무엇이 건너지 않는지는 하이브리드 아키텍처를 통한 프라이버시 바이 디자인을 보세요.

아키텍처에 대해 질문이 있거나 이 레이어 중 어느 것이든 더 깊이 파고들고 싶다면 우리에게 연락하세요. 우리는 작은 팀이고 모든 이메일을 읽어요.