Mac 상황 인식 음성 입력: 앱이 입력 위치를 아는 방법

Mail에서 답장을 반쯤 쓰던 중이라고 해 봅시다. ⌥Space를 누른 채로 열 초쯤 말하고 손을 뗍니다. 다듬어진 문장은 별도의 편집기도 아니고, 옮겨 담기를 기다리는 클립보드도 아닌, 메일 본문란에 바로 들어갑니다.

텍스트가 어디로 갈지 말한 적이 없는데도 그렇습니다.

대부분의 음성 도구는 목적지를 거꾸로 다룹니다. 말하기 전에 선택지를 건넵니다. 원문 모드, 문장부호 모드, 프롬프트 모드, 채팅 스타일, 메일 스타일 같은 것입니다. 사용자가 목적지를 선언하면 도구는 그 선언을 믿습니다. TalkTalkType에는 그런 선택지가 없습니다. 목적지를 직접 읽습니다. 사용자가 있던 앱과 커서 아래의 특정 입력란을 보고, 둘을 고정된 대응표로 분류한 뒤, 사용자가 직접 시작하는 음성 다듬기 단계에서 결과를 맞춥니다.

이 글은 그 읽기가 어떻게 작동하고, 무엇을 바꾸며, 어디에서 멈추는지를 다룹니다.

목적지는 키를 누르는 순간 포착됩니다

녹음은 키를 누르는 순간 시작됩니다. 그 순간 Mac 앱은 포커스된 앱을 전달 대상으로 포착합니다. 프로세스 ID, 번들 식별자, 앱의 지역화 이름입니다. 결과가 준비되면 그 앱으로 텍스트를 되돌려 보냅니다.

전달 경로는 두 가지입니다. Paste 모드에서는 macOS 접근성 API로, 사용자가 있던 입력란에 텍스트를 삽입합니다. 이때 먼저 클립보드를 저장했다가 삽입 후 복원합니다. Copy 모드에서는 결과가 클립보드에서 수동 붙여넣기를 기다립니다. 어느 쪽이든 목적지는 키를 누를 때 쓰던 앱이며, 한마디도 하기 전에 확정됩니다.

키를 누르는 순간 포착한다는 점이 전체를 자동으로 느끼게 만드는 핵심입니다. 텍스트가 준비될 때까지 기다렸다면, 사용자가 이미 창을 바꾼 뒤라 결과가 엉뚱한 곳에 떨어질 수 있습니다. 대신 시작한 입력란에서 그대로 끝납니다. 이 전달의 기계적 구조와 그 뒤에 있는 macOS 권한은 Mac의 모든 앱에서 쓰는 음성 입력에서 자세히 다룹니다.

분류는 추측이 아니라 대응표입니다

대상 앱이 알려지면, 분류기는 지금 입력하는 곳이 어떤 표면인지 결정합니다. 이때 언어 모델에게 묻지 않습니다.

첫 단계는 번들 식별자를 고정된 접두사 대응표로 앱 군에 할당합니다. Terminal, iTerm2, Warp, WezTerm, kitty는 터미널로 해석됩니다. VS Code, Xcode, JetBrains IDE, Sublime Text, Zed는 코드 편집기로 해석됩니다. Mail과 Outlook은 메일, Slack, Discord, LINE, Telegram은 채팅, TextEdit, Notes, Pages, Word, Obsidian은 문서, Safari, Chrome, Firefox, Arc는 브라우저로 해석됩니다.

두 번째 단계는 입력란의 접근성 role과 subrole로 표면을 다듬습니다. 검색란(AXSearchField)은 검색 쿼리가 됩니다. Mail에서는 텍스트 영역이 메일 본문이 되고, 텍스트 필드가 제목이 됩니다. 채팅 앱에서는 텍스트 영역이나 텍스트 필드가 채팅 메시지가 됩니다. 문서 앱에서는 텍스트 영역이 문서, 텍스트 필드가 짧은 입력란이 됩니다. 코드 편집기에서는 텍스트 영역이 코드 편집기 표면이 됩니다.

여기에는 추론이 없고, 대응표와 role 검사 몇 개만 있습니다. 그 대가로 모든 분류에는 감사 가능한 이유 문자열이 붙습니다. Mail 본문은 app_family:email role:AXTextArea subrole:-로 분류됩니다. 앱이 왜 그 결론에 도달했는지 그대로 읽을 수 있습니다. 결론이 모델의 확신이 아니라, 눈에 보이는 두 사실에서 도출되기 때문입니다.

대응표가 빗나가면, 안전한 쪽으로 빗나갑니다. 번들 식별자가 알려지지 않은 앱은 이유 unknown_app와 함께 unknown으로 분류됩니다. 알려진 앱이라도 알려지지 않은 role의 입력란은 마찬가지로 unknown이며, 이유는 unknown_role입니다. unknown이란 아무것도 특별히 하지 않는다는 뜻입니다. 이것이 안전한 기본값입니다. 입력란이 무엇인지 판별할 수 없을 때, TalkTalkType은 잘못 추측하지 않고 단어를 있는 그대로 다룹니다.

표면마다 무엇이 달라지는가

표면 분류는 다듬기 단계가 무엇에 맞춰도 되는지를 결정합니다. 대응은 다음과 같습니다.

두 줄에는 보충 설명이 필요합니다. 브라우저 줄이 항상 unknown인 것은 의도적입니다. 웹 페이지는 어떤 입력란이든 자유롭게 그릴 수 있습니다. 네이티브 Mail이나 Slack 입력란을 읽을 수 있게 해 주는 구조적 신호는 브라우저 탭 안에서는 성립하지 않습니다. 그래서 TalkTalkType은 웹 입력란을 분류하는 척하지 않고, 그대로 둡니다.

코드 편집기와 터미널 줄에는 기술 토큰에 대한 구체적인 보장이 있습니다. 이 표면에서는 말한 파일 이름, 경로, 슬래시 명령이 일반 텍스트로 보존됩니다. 그것이 존재한다거나, 해석된다거나, 실행된다는 취급을 일절 받지 않습니다. 터미널에 명령을 음성 입력해도 얻는 것은 문자열 그대로이며, 그 이상은 아닙니다.

맞춤은 다시 쓰기가 아니라 다듬기 단계입니다

여기는 가장 과장하기 쉬운 부분이라, 경계가 중요합니다.

정리된 결과는 먼저 메뉴 막대 HUD에 초안으로 도착합니다. 이 첫 붙여넣기는 충실한 Clean 출력입니다. Clean은 말한 모든 단어를, 말한 순서대로, 의도한 어감과 간결함 그대로 유지합니다. 모호하지 않은 망설임 추임새만 제거하고, 한 줄로 묶으며, 바꿔 쓰거나, 보충하거나, 다듬지 않습니다. Raw 모드는 정리를 통째로 생략합니다. 처음 보이는 것은 사용자가 말한 그대로입니다.

상황을 읽는 맞춤은 그 뒤 Voice Patch 흐름에서 일어납니다. 초안에서, 텍스트를 삽입하기 전에 음성으로 다듬기를 지시할 수 있습니다. 아니면 그대로 확정하거나, 복사하거나, 버릴 수도 있습니다. 표면에 맞추라고 요청하면, 모델 지시는 문자 그대로 "주어진 결정론적인 데스크톱 앱과 입력란 분류에만 맞춰라"입니다. 같은 흐름이 의미와 보호된 사실을 모두 보존하고, 필요한 최소한의 편집만 하며, 화면에 대해 받은 모든 것을 지시가 아니라 데이터로 취급합니다.

즉 Mail을 보자마자 첫 붙여넣기를 몰래 "메일체"로 고쳐 쓰지 않습니다. 충실한 초안을 보여 주고, 이미 감지한 표면에 근거해, 사용자가 음성으로 요청한 맞춤이 이루어집니다.

이 설계가 답하는 질문은, 왜 다른 도구들은 여전히 선택지를 건네는가입니다. TalkTalkType에는 설정 어디에도 출력 모드 선택이 없습니다. 스위치는 Clean 온과 오프 하나뿐입니다. 충실하고 가벼운 정리, 아니면 아무것도 하지 않는 것 둘 중 하나입니다. 목적지에 맞는 정리는 모두 입력란 읽기에서 옵니다. 사용자가 관리하는 모드에서 오지 않습니다. 강점으로 봐 주었으면 하는 부분이 바로 그곳입니다. 말하기 전에 설정할 것이 하나 줄고, 잘못 설정할 것은 없어진다는 점입니다.

컨텍스트는 동의 경계를 넘거나, 아예 나가지 않습니다

입력란을 읽으면 당연한 질문이 생깁니다. 화면의 나머지 정보는 어떻게 되는가 하는 것입니다.

앱이 조립할 수 있는 컨텍스트 스냅샷에는 앱 식별 정보, 창 제목, 입력란 구조(role, subrole, 여러 줄인지, 보안 비밀번호 입력란인지), 캐럿 바로 앞뒤의 텍스트, 현재 선택 영역, 활성 창의 선택적 스크린샷, 포착 시각, 권한 상태가 포함됩니다. 다루는 범위가 넓으므로, 경계는 클라이언트의 선의가 아니라 서버에서 강제됩니다.

가장 중요한 것은 두 가지입니다. 첫째, 입력란의 레이블과 자리 표시자는 AI 제공자로 전혀 전송되지 않습니다. 이 문자열은 다른 앱이 공급하는 임의의 텍스트이고, 분류에는 구조적 속성만으로 충분하므로, 서버는 레이블이나 자리 표시자를 포함한 요청을 그 자리에서 거부합니다. 둘째, 각 컨텍스트 채널(텍스트 컨텍스트, 스크린샷, 환경설정 기억)은 서버가 소유한 기능 플래그 뒤에 있습니다. 셋 모두 프로덕션에서 기본적으로 켜져 있고, 배포별로 재정의할 수 있습니다. 어떤 채널이 요청에 대해 활성화되어 있지 않으면, 서버는 컨텍스트를 조용히 제거하는 대신 거부합니다. 거부된 요청은 클라이언트에게 동의 상태가 오래되었다고 알려 줍니다. 조용히 제거하면 그것은 숨겨집니다.

Mac, 서비스, 제공자가 각각 무엇을 보유하는지를 다루는 전체 데이터 원장은 Mac의 개인정보 보호 음성 입력에 있습니다.

환경설정은 이 Mac에서만, 앱별로 배웁니다

컨텍스트의 마지막 조각은 환경설정 기억이며, 이것은 Mac 안에 머뭅니다.

환경설정은 ~/Library/Application Support/TalkTalkType/PreferenceMemory/preferences.sqlite의 로컬 SQLite 데이터베이스에 저장됩니다. 클라우드 동기화는 없습니다. 저장하는 키는 의도적으로 좁습니다. 응답 어조(간결, 중립, 격식, 친근), Oxford comma 사용 여부, 0에서 2까지의 상세 수준, 선호 용어 목록입니다. 각 환경설정은 모든 앱에 적용되거나 번들 식별자로 지정한 한 앱에 적용되며, 한 앱 설정이 전체 설정보다 우선합니다.

여기에 있는 것은 명시적으로 승인되고 활성화되기 전까지 일절 사용되지 않습니다. 다듬기 요청에는 추상화된 값만 실립니다. 원본 음성, 초안 텍스트, 거부된 후보는 이 저장소에 기록되지 않습니다. 한 앱에서 반복해서 수정하면 앱이 환경설정을 제안할 수 있습니다. 다만 제안은 사용자가 승인하기 전까지 아무것도 하지 않습니다.

부족한 곳

정직한 한계는 설계의 일부이며, 각주가 아닙니다.

브라우저는 unknown으로 분류되므로, 웹 양식에 대한 표면 맞춤은 없습니다. 웹 입력란의 구조를 신뢰하지 않기 때문입니다. 맞춤은 음성 다듬기 흐름 안에서 적용되며, 첫 붙여넣기의 묵묵한 다시 쓰기로는 적용되지 않습니다. 첫 붙여넣기는 설계상 충실하게 남습니다. 맞춤이 사용자의 단어를 바꿔 써서 없애지도 않습니다. 의미와 보호된 사실은 보존되고, 편집은 지시를 만족시키는 최소한으로 제한됩니다.

플랫폼은 Mac 전용이며 macOS 26(Tahoe) 이상이 필요합니다. 전사는 클라우드에서 실행되므로, 처리 중 음성은 Mac 밖으로 나갑니다. 서비스는 음성도 전사 텍스트도 기본적으로 저장하지 않습니다. 인식 언어는 일본어와 영어입니다. "복사", "Safari 열기" 같은 음성 명령은 같은 생각의 또 다른 표현으로, 텍스트로 입력되는 대신 포착된 앱에 대한 Mac 동작으로 실행됩니다.

자신의 업무에 맞춰 판단하기

이 설계의 주장은, 목적지가 앱이 읽을 수 있는 사실이지 사용자가 계속 관리해야 할 설정이 아니라는 것입니다. 모드 선택은 그 일을 사용자에게 외주 줍니다. 그리고 선택기란, 사용자가 바꾸는 것을 잊는 순간 도구가 깨도 되는 약속입니다. 번들 식별자와 입력란 role에 대한 대응표는 더 밋밋하고 더 정직합니다. 적은 수의 앱을 정확히 알고, 모를 때는 모른다고 말합니다.

TalkTalkType은 사용량을 단어가 아니라, 주당 음성 입력 건수와 주당 음성 시간 풀로 셉니다. 2026년 7월 30일 기준으로, 플랜은 Free가 0달러(주 30건, 15분), Plus가 1달러(주 80건, 30분), Pro가 7달러(주 500건, 250분, 1회 2분), Max가 18달러(주 1,200건, 600분)입니다. 현재 수치와 플랜 제공 상황은 요금 페이지에 있습니다.

TalkTalkType을 다운로드해서 실제로 쓰는 입력란에서 감지를 시험해 볼 수 있습니다. Mail에서, 터미널에서, 웹 양식에서 각각 단축키를 누르고, 결과가 어디에 떨어지며 무엇을 건드리지 않는지 지켜보십시오. 앱은 이미 어디에서 입력하고 있는지 알고 있습니다. 흥미로운 부분은, 그것을 모를 때 얼마나 솔직하게 그렇게 말하는가입니다.