WhatsApp 음성 명령: Gemini, Siri, Voice Access, FoneClaw 경로 정리

휴대폰과 작업별 WhatsApp 음성 경로

WhatsApp 음성 명령은 한 가지 방식으로 통일되지 않는다. Android에서 Gemini가 requirements를 만족하면 WhatsApp connected app 경로로 연락처에게 메시지를 보내거나 WhatsApp call을 시작할 수 있다. iPhone에서는 Siri가 WhatsApp의 앱 지원 intent와 현재 iOS, 연락처, 언어 설정을 통해 메시지나 통화 요청을 처리할 수 있다. Android Voice Access는 WhatsApp API가 아니라 보이는 화면의 label, number, grid, gesture, dictation을 음성으로 조작하는 접근성 경로다. FoneClaw는 현재 native WhatsApp send 또는 call tool을 주장하지 않고, WhatsApp 주변의 Android 작업 준비와 보이는 확인 흐름을 돕는다.

먼저 작업을 고르자. “음성으로 WhatsApp 메시지 보내기”라면 Android에서는 Gemini connected app 또는 Voice Access 화면 조작을 확인하고, iPhone에서는 Siri WhatsApp 명령을 확인한다. “Siri WhatsApp 연락처 통화”라면 앱 이름과 연락처를 명확히 말하고 실제 iPhone에서 후보와 확인 화면을 본다. “WhatsApp 메시지를 읽거나 답장”하려면 Gemini의 WhatsApp connected app이 직접 WhatsApp history를 읽는 경로가 아니라는 점을 먼저 알아야 한다. 알림 읽기와 답장은 Utilities 경로와 알림 권한의 문제다.

핵심은 native connected-app execution과 visible UI navigation을 섞지 않는 것이다. 같은 “보내줘”라도 Gemini, Siri, Voice Access, FoneClaw가 맡는 층이 다르다.

Android에서 Gemini로 WhatsApp 메시지와 통화하기

Google Gemini Apps Help의 WhatsApp calls and messages 안내는 Gemini mobile on Android가 requirements를 만족할 때 WhatsApp을 통해 연락처에게 call 또는 message를 할 수 있음을 설명한다. 이 경로는 Gemini web, Gemini in Google Messages, Live chats의 일반 대화 기능까지 넓혀 해석하면 안 된다. Android mobile에서 Gemini connected app이 WhatsApp과 연결되어 있고, 연락처와 앱 설정이 맞을 때 쓰는 경로다.

명령은 짧고 명확해야 한다. “Gemini, WhatsApp에서 민지에게 10분 늦는다고 메시지 보내줘”처럼 app name, recipient, content를 한 문장에 넣는다. 통화는 “WhatsApp으로 현우에게 전화 걸어줘”처럼 일반 phone call과 WhatsApp call을 구분해 말한다. Gemini가 같은 연락처와 마지막으로 사용한 communication app을 참고할 수 있으므로, WhatsApp을 원한다면 명령에 WhatsApp을 직접 넣는 편이 좋다.

제한도 뚜렷하다. Gemini의 WhatsApp connected app은 WhatsApp history를 직접 읽거나 요약하는 경로가 아니다. WhatsApp으로 image, audio, video 같은 media를 보내는 route로도 읽으면 안 된다. notification을 읽거나 reply하는 작업은 WhatsApp connected app 자체가 아니라 Gemini Utilities와 Android notification permission 흐름에서 다뤄진다. 그래서 “Gemini가 WhatsApp 메시지를 보낼 수 있나요?”에는 “Android mobile에서 requirements와 connected app 조건이 맞으면 text message와 call route가 있다”고 답하고, “Gemini가 WhatsApp 대화를 읽어 요약하나요?”에는 “그 connected app route는 직접 history read나 summarize가 아니다”라고 구분해야 한다.

Gemini 음성 설정, Utilities, Android action 범위를 넓게 정리하고 싶다면 Gemini 안드로이드 음성 제어: 설정부터 FoneClaw 실행과 복구까지를 함께 보면 좋다. WhatsApp만 볼 때도 이 구분이 실수 방지에 중요하다. app connection, contact, language, permission, confirmation이 맞아야 실제 결과가 안정적이다.

iPhone에서 Siri와 WhatsApp 사용하기

iPhone에서 “Siri로 WhatsApp 연락처에 전화할 수 있나요?”라는 질문의 답은 app-supported route와 현재 기기 상태를 함께 확인해야 한다. Apple은 messaging app과 VoIP app이 Siri와 통합할 수 있는 intent framework를 제공한다. Apple Developer의 SiriKit Messaging 문서는 participating messaging app이 message composition과 sending intent를 지원할 수 있음을 보여준다. Apple Developer의 messaging app interaction 문서는 app-specific interaction, contact resolution, execution result 같은 흐름을 설명한다.

다만 framework가 있다는 사실만으로 모든 iPhone, 모든 언어, 모든 WhatsApp build에서 같은 command가 동작한다고 말할 수는 없다. 실제 확인은 기기에서 해야 한다. WhatsApp이 설치되어 있는지, Siri 설정에서 WhatsApp 사용이 허용되어 있는지, 연락처 접근이 가능한지, 연락처 이름이 Siri가 해석하기 쉬운지 확인한다. 같은 이름의 연락처가 여러 명이면 Siri가 후보를 묻거나 다른 route를 선택할 수 있다.

명령은 “Siri, WhatsApp으로 지민에게 지금 출발한다고 보내줘”, “Siri, WhatsApp으로 민수에게 전화해줘”처럼 구성한다. 앱 이름을 빼면 일반 Messages나 phone route로 흐를 수 있다. 연락처 이름이 영어, 한국어, 별명으로 섞여 있으면 표시 이름을 정리하거나 성까지 포함해 말하는 편이 좋다. 그리고 전송이나 통화 전 화면에 표시되는 상대와 내용은 반드시 확인한다. 앞으로의 Siri AI 기능 소식과 현재 WhatsApp command route를 섞지 말고, 지금 설치된 앱과 OS에서 되는지 보는 것이 가장 정확하다.

Android Voice Access로 WhatsApp 화면 조작하기

Android WhatsApp 음성 제어에서 Voice Access는 connected app API가 아니라 visible UI navigation이다. Google Android Accessibility Help의 Voice Access commands 안내는 app opening, labels, numbers, grids, gestures, dictation, editing, calls를 음성으로 조작하는 방법을 설명한다. WhatsApp에서도 이 원리는 같다. 앱을 열고, 보이는 chat을 선택하고, text field에 받아쓰기하고, Send button을 확인하는 방식이다.

예를 들어 “Open WhatsApp”, “Tap Search”, “Type 민지”, “Tap 2”, “Type 지금 출발했어”, “Tap Send”처럼 화면에 보이는 요소를 단계별로 조작할 수 있다. 화면 label이 잘 잡히지 않으면 number overlay나 grid를 사용한다. 긴 메시지는 한 번에 받아쓰기보다 짧게 나눠 말하고, 보내기 전에 text field에 들어간 문장을 확인한다. Voice Access는 화면을 실제로 조작하기 때문에 UI가 바뀌면 명령도 달라질 수 있다.

읽기와 답장도 같은 원리다. Voice Access가 WhatsApp history를 의미적으로 읽고 요약하는 native WhatsApp integration은 아니다. 화면에 보이는 채팅을 열고, 필요한 위치로 스크롤하고, 보이는 내용을 사용자가 확인하며, 답장 field에 dictation하는 방식이다. 언어 command coverage도 다를 수 있으므로 한국어 명령만으로 모든 UI 조작이 같게 작동한다고 보면 안 된다.

Voice Access를 실제로 설정하고 명령 체계를 익히는 과정은 이 글의 범위를 넘는다. 접근성 음성 조작을 자세히 준비하려면 안드로이드 음성 제어 설정 가이드: 손이 바쁠 때 안전하게 쓰는 실전 기준을 참고하면 된다. WhatsApp에서는 마지막 Send verification이 특히 중요하다. connected app route보다 UI navigation은 더 유연하지만, 그만큼 화면 확인이 필수다.

수신자, 내용, 권한, 전송 확인하기

WhatsApp 음성 명령에서 privacy와 confirmation은 추상적인 주의 문구가 아니라 실제 작업 순서다. 첫째, recipient를 확인한다. 연락처 이름이 비슷하거나 단체방과 개인 chat이 섞이면 잘못된 상대에게 갈 수 있다. 둘째, content를 확인한다. 음성 인식은 숫자, 시간, 주소, 외래어, 이름에서 실수할 수 있다. 셋째, route를 확인한다. WhatsApp message인지, system SMS인지, 일반 phone call인지, WhatsApp call인지 구분해야 한다.

권한도 분리해서 봐야 한다. Contacts permission은 연락처 해석에 필요하고, notification access나 notification permission은 읽기와 reply route에 영향을 줄 수 있다. WhatsApp request를 수행하는 데 필요한 정보는 WhatsApp에도 전달될 수 있다. 모든 voice processing이 local이라고 가정하거나, 모든 route가 항상 보내기 전에 묻는다고 기대하면 안 된다. 기기와 앱 설정에 따라 확인 방식이 다르다.

잠금 화면과 주변 사람도 현실적인 변수다. 음성으로 메시지를 말하면 근처 사람이 내용을 들을 수 있고, lock screen에서 허용되는 동작은 기기 정책에 따라 다르다. 민감한 내용이라면 먼저 앱을 열고 수신자를 확인한 뒤 짧게 dictation하는 편이 낫다. SMS와 RCS의 핸즈프리 전송 확인 흐름을 따로 비교하고 싶다면 안드로이드 핸즈프리 문자 가이드: Galaxy 음성 입력부터 FoneClaw SMS 검토·전송까지에서 WhatsApp이 아닌 system messaging route를 이어서 볼 수 있다.

FoneClaw가 돕는 인접 Android 단계

FoneClaw에서 우리는 WhatsApp을 native tool처럼 말하지 않는다. 현재 FoneClaw에는 WhatsApp-specific send 또는 call tool이 있다는 주장을 하지 않는다. System SMS tools도 WhatsApp message가 아니다. 이 경계를 분명히 해야 사용자가 어떤 route를 선택할지 정확히 판단할 수 있다. 대신 FoneClaw는 WhatsApp 주변의 Android 준비 작업을 governed phone-agent 흐름으로 돕는다.

예를 들어 사용자가 “WhatsApp으로 보낼 답장 문장을 정리하고 앱을 열어줘”라고 말하면, FoneClaw는 의도를 이해하고 답장 draft를 준비하고 WhatsApp app launch 같은 일반 Android 단계를 도울 수 있다. 사용자가 현재 WhatsApp 화면을 직접 첨부하면, FoneClaw는 user-triggered current-screen context를 작업 판단에 활용할 수 있다. 이 맥락은 사용자가 선택해서 제공하는 것이며, background WhatsApp history access를 뜻하지 않는다.

보이는 UI 단계도 지원 범위 안에서 다룬다. FoneClaw는 visible screen context, app launch, task state, approval, stopping, permission recovery를 통해 사용자가 다음 행동을 확인할 수 있게 만든다. 다만 generic UI interaction은 native integration만큼 안정적이라고 말할 수 없다. WhatsApp UI가 바뀌거나, chat 대상이 애매하거나, Send button이 보이지 않으면 FoneClaw는 무리하게 결과를 보장하지 않고 확인이나 recovery 흐름으로 돌린다.

우리가 제품에서 지키는 원칙은 간단하다. AI가 문장을 준비할 수 있어도, 상대방에게 실제 메시지가 가거나 call이 시작되는 순간에는 사용자가 볼 수 있어야 한다. FoneClaw는 adjacent Android steps를 더 적은 조작으로 준비하고, 가능한 곳에서 확인 가능한 결과를 만들고, 막히는 곳에서는 다음 선택을 보여준다. 전화 실행 route 자체를 더 깊게 이해하려면 AI 에이전트 전화 걸기: MCP 전화 도구와 Android 다이얼러 방식 비교에서 app-specific call과 system dialer의 차이를 볼 수 있다.

그래서 “FoneClaw가 WhatsApp을 제어할 수 있나요?”라는 질문에는 정확히 답해야 한다. FoneClaw는 native WhatsApp integration이나 WhatsApp history access를 주장하지 않는다. FoneClaw는 지원되는 Android 준비 단계, 사용자가 제공한 화면 맥락, draft 작성, app launch, 보이는 확인과 recovery를 통해 WhatsApp 작업 주변을 돕는 adjacent route를 제공한다.

WhatsApp 음성 명령 실패 점검

WhatsApp 음성 명령이 실패하면 먼저 route 이름부터 확인한다. Android Gemini connected app인지, Siri app intent인지, Voice Access visible navigation인지, FoneClaw adjacent preparation인지에 따라 고칠 지점이 다르다. Gemini에서 WhatsApp으로 보내고 싶다면 명령에 WhatsApp을 직접 넣는다. Gemini가 연락처의 마지막 communication app을 참고할 수 있으므로 “민지에게 보내줘”보다 “WhatsApp에서 민지에게 보내줘”가 안전하다.

다음은 app connection과 contact다. Gemini에서는 connected app 설정과 WhatsApp 설치 상태를 확인한다. iPhone에서는 Siri가 WhatsApp을 사용할 수 있는지, WhatsApp이 contacts에 접근할 수 있는지 본다. Voice Access에서는 WhatsApp 화면이 실제로 열려 있고, label이나 number가 보이는지 확인한다. 연락처 이름이 겹치면 성, 별명, 회사명까지 포함해 말한다.

권한과 언어도 점검한다. Microphone, Contacts, Notifications는 서로 다른 permission path다. Notification read와 reply는 connected app이 아니라 Utilities 또는 system notification route와 관련될 수 있다. 한국어로 말하면서 연락처가 영어 별칭으로 저장되어 있으면 인식이 흔들릴 수 있다. 긴 명령이 실패하면 app 열기, chat 찾기, message dictation, send confirmation으로 나눠서 진행한다.

• route 지정: Gemini, Siri, Voice Access, FoneClaw 중 어떤 경로인지 먼저 정한다.
• 앱 이름 포함: 일반 SMS나 phone route로 가지 않도록 WhatsApp을 명령에 넣는다.
• 연락처 정리: 같은 이름, 별명, 다국어 표시 이름을 확인한다.
• 권한 분리: Contacts, Notifications, Microphone, app connection을 따로 본다.
• 결과 확인: 수신자, 내용, call screen, Send 상태를 화면에서 확인한다.

재설치는 마지막에 가까운 선택이다. 대부분의 문제는 route 지정, connected app, contacts, permission, language, visible UI state에서 먼저 드러난다. WhatsApp 음성 명령은 빠르게 시작하되, 실제 결과는 사용자가 확인하는 방식이 가장 안정적이다.