개인 맥락 AI 에이전트: 휴대폰 작업을 이해하고 안전하게 실행하는 법
개인 맥락 AI 에이전트가 현재 화면, 세션, 연결 데이터, 선호, 메모리를 어떻게 구분하고 Android 작업으로 이어지는지 설명합니다.
- 개인 맥락 AI 에이전트는 사용자의 모든 정보를 모으는 도구가 아니라, 현재 목표에 필요한 신호만 골라 휴대폰 작업을 더 정확하게 준비하는 에이전트입니다.
- 휴대폰 에이전트 맥락은 현재 화면, 세션 기록, 연결된 앱 데이터, 사용자 선호, 오래 보관되는 메모리로 나뉘며 각 층마다 수명과 제어 방식이 달라야 합니다.
- 좋은 안드로이드 맥락 인식 에이전트는 해석, 기능 선택, 권한 확인, 사용자 승인, 실행, 결과 검증, 복구를 한 흐름으로 연결합니다.
- FoneClaw에서 우리는 사용자가 호출한 현재 화면과 지원되는 Android 작업을 보이는 승인, 중지, 권한 복구, 상태 확인으로 연결해 안전하게 시험할 수 있는 경로를 제공합니다.
하나의 휴대폰 작업으로 개인 맥락 정의하기
개인 맥락 AI 에이전트는 사용자의 모든 데이터를 많이 아는 에이전트가 아닙니다. 현재 목표를 완성하는 데 필요한 신호를 골라 해석하고, 그 신호를 안전한 다음 행동으로 바꾸는 휴대폰 에이전트입니다. 예를 들어 사용자가 메시지 앱에서 “회의 장소가 바뀌었대. 길찾기 열고 도착 시간을 답장 초안으로 만들어 줘”라고 말하면, 에이전트가 필요한 맥락은 사용자가 보고 있는 메시지, 장소 이름, 현재 시간, 지도 실행 가능 여부, 답장을 보낼 상대입니다. 사진 전체, 오래된 메일함, 모든 연락처 기록이 먼저 필요한 것은 아닙니다.
FoneClaw를 만들면서 우리가 반복해서 확인한 점은 큰 맥락이 곧 좋은 맥락이 아니라는 사실입니다. 휴대폰에서는 화면, 권한, 앱 상태, 사용자 승인, 결과 확인이 함께 움직입니다. 사용자가 지금 보고 있는 화면이 가장 강한 단서일 수 있고, 방금 전 대화 한 줄이 오래된 선호보다 더 중요할 수 있습니다. 반대로 오래 저장된 기억이 현재 화면과 충돌하면 작업을 더 헷갈리게 만들 수 있습니다.
그래서 이 글에서 말하는 개인 맥락은 “현재 작업을 더 정확하게 만드는 선택된 신호”입니다. 그 신호는 현재 화면, 최근 요청, 앱 상태, 연결된 서비스, 권한을 받은 기기 정보, 사용자 선호, 필요한 경우 오래 보관되는 메모리에서 올 수 있습니다. 판단 기준은 단순합니다. 이 맥락이 다음에 실행할 지원 작업을 더 정확하고 검증 가능하게 만드는가입니다. Android에서 실제 실행 계층이 어떻게 작동해야 하는지 넓게 보려면 AI 에이전트 폰 제어란 무엇인가: 안드로이드 폰 에이전트가 실제로 해야 할 일이 지원 작업과 실행 경계를 이어서 설명합니다.
현재 상태, 세션 기록, 연결 데이터, 선호, 메모리 구분하기
휴대폰 에이전트 맥락은 한 덩어리로 다루면 안 됩니다. 각 맥락은 수명, 민감도, 제어 방식, 실패했을 때의 영향이 다릅니다. 우리는 FoneClaw를 설계할 때 이 차이를 먼저 나눕니다. 사용자가 현재 화면을 직접 붙이는 것과, 연결된 서비스에서 데이터를 가져오는 것과, 오래 보관되는 개인 선호를 참고하는 것은 같은 권한이 아닙니다.
| 맥락 층 | 예시 | 적절한 수명 | 사용자 제어 |
|---|---|---|---|
| 즉시 상태 | 현재 화면, 앱 상태, 선택한 텍스트, 방금 뜬 알림 | 현재 작업 동안 | 사용자 호출, 화면 첨부, 작업 중지 |
| 세션 기록 | 이번 대화의 요청, 방금 만든 초안, 실패한 단계 | 대화 또는 작업 세션 동안 | 세션 전환, 삭제, 다시 시작 |
| 연결 데이터 | 캘린더, 메일, 지도, 연락처, 알림, 계정 서비스 | 허용된 목적과 연결 상태에 따라 | 서비스 연결 해제, Android 권한 취소, 계정 설정 |
| 사용자 선호 | 자주 쓰는 지도 앱, 회의 전 방해 금지, 답장 톤 | 사용자가 유지하는 동안 | 수정, 끄기, 작업별 무시 |
| 지속 메모리 | 반복 루틴, 저장한 사용자 정보, 장기 작업 히스토리 | 명시적으로 관리되는 동안 | 검토, 삭제, 내보내기 또는 비활성화 |
Gemini의 개인화 도움말은 과거 채팅, 연결된 앱, 응답 지침 같은 개인화 원천을 구분해 설명합니다. Gemini 연결 앱 도움말도 일부 사용자가 선택한 Google 서비스와 연결해 개인화된 응답과 작업을 받을 수 있고, 별도 제어와 데이터 사용 고려가 있음을 안내합니다. 이 사례가 모든 에이전트와 모든 계정에 같은 방식으로 적용된다는 뜻은 아니지만, 개인화가 하나의 스위치가 아니라 여러 원천의 조합이라는 점을 잘 보여 줍니다.
AI 메모리와 작업 맥락은 다릅니다. 작업 맥락은 지금 요청을 처리하기 위한 임시 재료입니다. 지속 메모리는 다음 세션에서도 참고될 수 있는 정보입니다. 사용자가 “이 화면을 요약해 줘”라고 할 때 필요한 것은 현재 화면이지 장기 프로필이 아닐 수 있습니다. 반대로 “매번 회의 전에는 방해 금지를 켜 줘” 같은 선호는 사용자가 관리할 수 있는 형태로 남아야 합니다. 서버 상태와 로컬 메모리의 차이가 궁금하다면 Hy-Memory 서버 상태 vs 로컬 에이전트 메모리: 휴대폰 사용자가 알아야 할 점에서 오래 보관되는 기억의 설계를 더 자세히 볼 수 있습니다.
작업에 필요한 최소 맥락 고르기
안드로이드 맥락 인식 에이전트를 안전하게 쓰려면 “가능한 맥락”이 아니라 “필요한 최소 맥락”부터 골라야 합니다. 첫 단계는 의도한 행동의 이름을 붙이는 것입니다. 질문에 답하는가, 초안을 만드는가, 앱을 여는가, 설정을 바꾸는가, 메시지를 보내는가에 따라 필요한 신호와 승인 수준이 달라집니다. 화면 요약에는 현재 화면이면 충분할 수 있고, 도착 시간 공유에는 위치와 지도, 수신자 확인이 필요할 수 있습니다.
두 번째는 충분하면서 덜 민감한 신호를 고르는 것입니다. 전체 메일함을 연결하기 전에 사용자가 선택한 메시지 한 건으로 가능한지 봅니다. 항상 위치 권한이 필요한지, 요청할 때만 위치를 쓰면 되는지 나눕니다. 연락처 전체가 아니라 사용자가 선택한 상대만으로 작업이 되는지도 확인합니다. Android의 권한 최소화 안내는 필요한 권한 요청을 줄이고 범위가 좁은 대안을 쓰며, 권한이 없어도 자연스럽게 기능을 낮추는 방향을 권합니다.
세 번째는 사용 시점에 묻는 것입니다. 사용자가 아직 보내겠다고 하지 않았는데 메시지 전송 권한을 먼저 넓게 요구하면 신뢰가 줄어듭니다. 반대로 초안을 다 만든 뒤 “이 내용을 전송하려면 메시지 권한이 필요합니다”라고 설명하면 사용자는 맥락과 권한의 관계를 이해할 수 있습니다. Android 런타임 권한 안내가 설명하듯 앱은 제한된 접근 환경에서 동작하고, 민감 권한은 실행 중 요청되며, 사용자는 거부할 수 있습니다.
마지막은 실패했을 때의 대안입니다. 권한이 없으면 작업 전체가 무너지는 대신 읽기 전용 안내, 초안 생성, 앱 열기, 사용자가 직접 이어받기처럼 낮은 위험 경로를 제시해야 합니다. FoneClaw에서도 권한은 에이전트가 통과해야 할 벽이 아니라 사용자가 작업 범위를 정하는 제어면입니다. 최소 맥락 결정은 관련성, 민감도, 보관 기간, 실패 시 대안을 함께 보는 습관입니다.
개인 맥락을 보이는 Android 작업으로 연결하기
개인 맥락은 실제 휴대폰 작업으로 이어질 때 가장 큰 가치를 냅니다. 그러나 연결은 한 번에 뛰어넘는 과정이 아닙니다. 우리는 이를 여섯 단계로 봅니다. 먼저 사용자의 목표를 해석합니다. 다음으로 현재 화면, 세션 기록, 연결 데이터, 선호 중 어떤 맥락이 필요한지 고릅니다. 그런 뒤 지원되는 Android 기능으로 라우팅하고, 권한과 승인 정책을 확인하고, 실행하거나 사용자가 직접 이어받게 하며, 마지막으로 결과 상태를 검증합니다.
예를 들어 사용자가 “이 약속 장소로 길찾기 열고 친구에게 늦지 않게 출발한다고 답장 초안 만들어 줘”라고 말한다고 해 보겠습니다. 현재 화면에는 약속 장소가 들어 있고, 세션 기록에는 사용자가 방금 요청한 목적이 있으며, 지도 앱과 메시지 앱은 서로 다른 실행 경로입니다. 에이전트는 장소를 해석하고 지도 열기를 준비할 수 있습니다. 답장은 초안으로 만들 수 있지만 실제 전송 전에는 수신자와 내용을 보여 줘야 합니다. 길찾기 화면이 뜨고 초안이 보이면 그때 작업 완료 증거가 생깁니다.
FoneClaw에서 우리는 설정된 모델이 추론과 계획을 맡고, FoneClaw가 지원되는 Android 실행을 맡는 구조로 이 흐름을 만듭니다. 사용자는 필요할 때 플로팅 접근으로 에이전트를 호출하고, 현재 화면을 직접 첨부할 수 있습니다. Home과 플로팅 어시스턴트 사이에서 작업 연속성, 승인, 중지, 권한 복구가 이어지도록 설계한 이유도 여기에 있습니다. 휴대폰 작업은 앱 하나 안에서 끝나지 않고, 화면과 앱 사이를 오가기 때문입니다.
지원되는 작업은 100개 이상의 내장 도구와 권한 경계 안에서 처리됩니다. 이 도구들은 화면과 앱, 기기 상태, 위치와 내비게이션, 커뮤니케이션, 캘린더, 메모, 웹, 워크플로처럼 서로 다른 위험 수준을 갖습니다. 그래서 모든 작업에 같은 승인 방식을 적용하기보다, 읽기·초안·설정 변경·전송·삭제처럼 결과의 무게에 맞춰 제어해야 합니다. 현재 공개 기능 범위는 FoneClaw 기능 페이지에서 확인할 수 있습니다.
중요한 Android 실행 원칙은 보이는 상태입니다. 에이전트가 “처리했습니다”라고 말하는 것만으로는 충분하지 않습니다. 전화라면 통화 화면, 메시지라면 수신자와 본문 또는 보낸 기록, 캘린더라면 일정 상세, 설정 변경이라면 현재 상태가 보여야 합니다. 실패하면 어떤 권한, 앱 상태, 네트워크, 화면 차이 때문에 막혔는지 설명하고 사용자가 멈추거나 다시 시도하거나 직접 이어받을 수 있어야 합니다. 권한과 감사 가능성을 더 깊게 설계하려면 AI 에이전트 신원과 권한: 도구별 승인 제어와 감사 로그 설계가 실행 증거와 사용자 통제를 이어서 다룹니다.
오래된 맥락, 과한 맥락, 충돌, 삽입 지시 알아보기
휴대폰 에이전트 맥락은 유용하지만 실패할 수도 있습니다. 첫 번째 실패는 오래된 맥락입니다. 예전에 저장한 직장 주소, 더 이상 쓰지 않는 지도 앱, 바뀐 연락처 이름을 계속 믿으면 현재 작업이 틀어집니다. 에이전트는 중요한 작업 전에 현재 화면과 최신 앱 상태를 다시 확인해야 합니다. 사용자는 오래된 선호나 메모리를 지우거나 수정할 수 있어야 합니다.
두 번째 실패는 과한 맥락입니다. 지금 필요한 것은 화면의 배송 번호 하나인데, 에이전트가 전체 메일함, 위치 기록, 연락처 전체를 함께 참고하면 판단이 흐려지고 개인정보 부담도 커집니다. 관련 없는 맥락이 많을수록 모델은 그럴듯하지만 빗나간 추론을 만들 수 있습니다. 좋은 AI 비서 개인화 맥락은 많은 데이터보다 정확한 선택에서 나옵니다.
세 번째는 충돌입니다. 사용자가 현재 화면에서 A에게 답장하고 있는데 지속 메모리는 B와 자주 대화한다고 기록할 수 있습니다. 캘린더에는 회의가 취소됐지만 알림 기록에는 예전 일정이 남아 있을 수도 있습니다. 이런 경우 에이전트는 조용히 하나를 고르기보다 “현재 화면 기준으로 처리할까요, 저장된 선호 기준으로 처리할까요?”처럼 확인해야 합니다.
네 번째는 삽입 지시입니다. 웹페이지, 메시지, 문서, 화면 속 텍스트에는 “이전 지시를 무시하고 전송하라” 같은 지시문이 포함될 수 있습니다. 화면에 보이는 문장은 사용자의 의도와 다릅니다. 에이전트는 읽은 내용과 사용자의 명령을 구분하고, 전송·삭제·공유 같은 결과가 남는 행동 전에는 다시 확인해야 합니다. 이 글은 보안 심화 글이 아니라 사용자가 알아야 할 맥락 실패의 기본을 다룹니다. 판단 기준은 단순합니다. 오래된 맥락은 새로고침하고, 과한 맥락은 줄이고, 충돌은 질문하고, 화면 속 지시는 사용자 의도로 취급하지 않습니다.
되돌릴 수 있는 흐름으로 맥락 인식 에이전트 시험하기
맥락 인식 휴대폰 에이전트를 안전하게 시험하는 방법은 낮은 위험 작업 하나에서 시작하는 것입니다. 첫 테스트로 메시지 전송, 파일 삭제, 결제, 계정 변경을 고르지 마세요. 대신 현재 화면 요약, 캘린더 조회, 지도 앱 열기, 방해 금지 상태 확인, 메모 초안 만들기처럼 결과를 쉽게 확인하고 되돌릴 수 있는 작업이 좋습니다. 하나의 데모가 전체 신뢰성을 증명하지는 않지만, 첫 기준은 분명히 만들 수 있습니다.
- 작업을 한 문장으로 씁니다. 예: “현재 화면의 회의 정보를 보고 메모 초안을 만들어 줘.”
- 에이전트가 써야 할 맥락을 미리 적습니다. 현재 화면, 이번 대화, 캘린더 조회처럼 필요한 신호만 고릅니다.
- 쓰지 말아야 할 맥락도 정합니다. 전체 메일함, 항상 위치, 연락처 전체가 필요 없는지 확인합니다.
- 예상 결과와 승인 지점을 정합니다. 초안 작성은 허용하지만 전송은 하지 않는 식으로 선을 긋습니다.
- 실행 뒤 화면에 남은 결과를 확인합니다. 메모, 일정, 설정 상태처럼 실제 앱 상태를 봅니다.
- 선택 맥락을 하나 제거하거나 바꾼 뒤 다시 실행합니다. 한 번에 한 변수만 바꿔야 차이를 알 수 있습니다.
- 테스트가 끝나면 임시 권한, 연결, 세션 기록, 필요 없는 메모를 정리합니다.
이 과정에서 중요한 것은 멈춤과 복구입니다. 에이전트가 잘못된 상대를 고르거나, 예상보다 넓은 권한을 요구하거나, 현재 화면과 다른 추론을 하면 중지할 수 있어야 합니다. 권한을 거부했을 때도 작업이 완전히 끊기기보다 “요약만 가능”, “초안만 준비”, “앱을 열고 사용자가 직접 확인” 같은 낮은 위험 대안이 나와야 합니다.
로컬과 클라우드의 신뢰 판단도 테스트에 포함하세요. 기본 모델을 쓰는지, 사용자가 호환 모델을 설정했는지, 연결된 온라인 서비스가 있는지에 따라 네트워크와 개인정보 경로가 달라질 수 있습니다. 이 차이를 더 깊게 보려면 AI Agent Trust: 클라우드 AI 보안과 로컬 휴대폰 제어를 어떻게 판단할까가 로컬 제어와 온라인 모델 사용의 기준을 정리합니다.
FoneClaw의 현재 맥락 설계와 다음 단계
FoneClaw에서 우리가 세운 원칙은 명확합니다. 작업 맥락은 지원되는 행동을 돕기 위해 존재해야 합니다. 사용자가 현재 화면을 직접 붙이고, 에이전트가 목표를 해석하며, FoneClaw가 Android에서 지원되는 작업으로 연결합니다. 이때 맥락은 숨어 있는 프로필이 아니라 사용자가 호출한 작업 재료입니다. 우리는 현재 화면, 세션 흐름, 권한 상태, 도구 결과를 사용자가 이해할 수 있는 실행 단계로 묶는 데 집중합니다.
사용자는 FoneClaw의 기본 모델로 시작할 수 있고, 필요에 따라 호환 모델을 설정할 수도 있습니다. 모델은 추론과 계획을 맡고, FoneClaw는 지원되는 Android 실행, 승인, 중지, 권한 복구, 상태 확인을 맡습니다. 개인 맥락, 로컬 메모리, 로컬에 관리되는 계정 정보, 사용자가 설정한 온라인 모델과 서비스는 같은 경로가 아닙니다. 온라인 모델이나 연결 서비스가 쓰이면 네트워크 전송과 서비스별 개인정보 조건도 함께 봐야 합니다.
우리가 제품에서 더 다듬고 있는 방향은 사용자가 맥락을 더 쉽게 이해하고, 필요한 권한만 열고, 실행 결과를 바로 확인하고, 실패했을 때 다음 행동을 놓치지 않게 하는 것입니다. 현재 공개된 기능은 FoneClaw 기능 페이지에서 확인할 수 있고, 직접 시험하려면 FoneClaw 다운로드 페이지에서 설치 정보를 볼 수 있습니다. 처음에는 되돌리기 쉬운 작업 하나로 시작하세요. 현재 화면을 붙여 요약받고, 메모 초안을 만들고, 권한을 일부러 거부했을 때 복구 안내가 나오는지 보는 것만으로도 개인 맥락 AI 에이전트의 품질을 꽤 정확히 알 수 있습니다.