안전한 크로스 디바이스 AI 에이전트 핸드오프: 작업 상태와 승인 설계

원격 지휘, 작업 이전, 알림 재개와 한 기기 연속성 구분

안전한 크로스 디바이스 AI 에이전트 핸드오프를 설계하려면 먼저 무엇이 다른 기기로 넘어가는지 구분해야 합니다. 대화 내용이 휴대폰에 표시되는 것만으로 작업이 이전된 것은 아닙니다. 실제 실행 환경이 그대로인 채 다른 화면에서 진행 상황을 보고 지시하는 원격 지휘가 있고, 실행에 필요한 입력과 권한을 새 기기로 넘기는 작업 이전이 있습니다. 알림을 눌러 원래 작업 화면으로 돌아오는 방식과 한 기기 안에서 표시 위치만 바뀌는 연속성도 별도 유형입니다.

예를 들어 PC에서 코드 검사를 실행한 뒤 휴대폰으로 진행 상황을 보고 추가 질문에 답한다면 작업은 PC 환경에 남아 있습니다. 휴대폰은 원격 지휘 화면입니다. 반대로 PC에서 준비한 파일과 작업 상태를 휴대폰으로 복사해 Android 앱에서 처리를 계속한다면 실제 실행 환경이 달라지는 작업 이전입니다. 후자의 경우에는 휴대폰 권한과 앱 상태를 새로 확인해야 하며 PC에서 받은 허용이 자동으로 적용돼서는 안 됩니다.

같은 Android 휴대폰에서 Home 화면과 플로팅 도우미 사이를 오가는 경우에는 기기 간 이동이 일어나지 않습니다. 작업의 실행 주체와 권한을 가진 기기는 그대로이고 사용자가 상태를 보는 위치만 바뀝니다. 이 구분을 명확히 하면 제품이 보여 줘야 할 정보도 달라집니다. 원격 지휘 화면에는 원본 실행 환경을 표시하고, 작업 이전 화면에는 새 실행 환경과 재승인 항목을 보여 주며, 한 기기 연속성에서는 동일한 작업 상태가 끊기지 않았음을 확인시켜야 합니다.

안전한 이어받기에 필요한 최소 작업 상태

기기 사이에서 작업을 안전하게 이어 가려면 채팅 기록보다 구조화된 작업 상태가 필요합니다. 최소한 사용자와 에이전트 신원, 원래 요청의 목적, 사용한 입력, 현재 단계, 지금까지 만든 산출물, 실제 실행 환경, 마지막 갱신 시점을 전달해야 합니다. 이 정보가 없으면 새 화면은 에이전트가 무엇을 하려 했는지 추측하게 되고, 오래된 자료나 이미 완료된 단계를 다시 실행할 수 있습니다.

PC에서 “테스트 실패 원인을 찾아 수정안을 준비하되 파일은 바꾸지 마”라고 시작한 작업을 생각해 보겠습니다. 휴대폰 화면에는 원래 목적과 수정 금지 조건, 검사한 저장소와 기준 브랜치, 현재 테스트 단계, 발견한 오류, 실제 실행 중인 PC 세션과 마지막 갱신 시각이 보여야 합니다. 대화의 마지막 문장만 전달되면 휴대폰에서 “수정해 줘”라는 후속 지시가 초안 작성인지 파일 변경인지 판단하기 어렵습니다.

입력 자료에는 단순 이름보다 버전 식별 정보가 필요합니다. 같은 파일이 PC와 휴대폰에서 서로 다르게 수정됐거나 앱 화면이 바뀌었다면 기존 계획은 유효하지 않을 수 있습니다. 새 화면은 최신 입력을 다시 가져오거나 충돌을 표시해야 합니다. 개인 일정, 연락처, 최근 대화처럼 사용자 맥락이 작업 결과를 바꾸는 방식은 개인 컨텍스트 AI 에이전트: 휴대폰 작업을 이해하는 맥락의 기준에서 더 자세히 살펴볼 수 있습니다.

도구나 외부 자원을 다른 환경에서 다시 찾는 작업이라면 신뢰할 수 있는 기능 설명과 제공 주체도 상태에 포함돼야 합니다. 이름이 같은 도구를 새 기기에서 임의로 선택하면 권한과 결과 형식이 달라질 수 있습니다. 에이전트가 사용할 자원을 검증하는 기준은 Agentic Resource Discovery란? ai-catalog.json과 폰 에이전트 신뢰 경계에서 이어서 확인할 수 있습니다.

승인을 작업, 행동과 실행 기기에 묶는 방법

승인은 대화 전체에 부여하는 포괄적인 허용이 아니라 특정 작업의 특정 행동에 대한 결정이어야 합니다. 누가 요청했고, 어떤 입력을 사용하며, 어느 환경에서 어떤 명령이나 휴대폰 동작을 수행하는지 함께 묶어야 합니다. PC에서 파일 읽기를 허용한 기록이 휴대폰의 메시지 전송 권한이 될 수 없고, 초안 생성을 승인한 사실이 실제 전송 동의로 바뀌어서도 안 됩니다.

원격 지휘에서는 승인 화면과 실행 장소가 다를 수 있습니다. 휴대폰에서 승인 버튼을 눌러도 실제 명령은 PC의 실행 중인 세션에서 수행될 수 있습니다. 따라서 승인 화면에는 원본 환경, 작업 이름, 실행할 행동, 대상 파일이나 서비스, 예상 영향이 표시돼야 합니다. 사용자가 “허용”을 누른 뒤 어느 기기에서 무엇이 바뀌는지 알 수 없다면 원격 제어의 편리함이 작업 혼동으로 이어집니다.

작업 이전은 권한을 더 엄격하게 다시 평가해야 합니다. 실행 장소가 PC에서 휴대폰으로 바뀌면 Android 앱 권한, 로그인 계정, 파일 접근 범위와 기기 잠금 상태가 달라집니다. 원본 환경에서 허용된 행동이라도 새 기기에서 실행할 권한이 없거나 대상이 달라졌다면 다시 확인해야 합니다. 승인 후 입력 파일, 명령, 수신자 또는 실행 환경이 바뀌면 기존 승인은 만료시키고 변경된 내용을 새로 보여 주는 편이 안전합니다.

확인 화면은 “계속할까요?”처럼 추상적인 문구보다 행동을 직접 설명해야 합니다. “회사 노트북의 세션에서 테스트 명령 실행”, “Android 휴대폰의 업무용 계정으로 일정 변경”, “원격 저장소에 수정 내용 게시”처럼 실행 주체와 결과를 함께 표시합니다. 신뢰도와 작업 이유, 승인 전후의 복구 방식을 설계하는 기준은 AI 에이전트 승인 UX: 신뢰도, 작업 이유, 확인과 복구를 설계하는 법에서 구체적으로 확인할 수 있습니다.

승인 기록에는 결정한 사용자, 표시된 작업 내용, 결정 시점과 실제 실행 결과가 연결돼야 합니다. 승인이 있었지만 작업이 시작되지 않았거나 다른 입력으로 실행됐다면 성공 기록으로 남겨서는 안 됩니다. 거절된 행동은 진행되지 않았음을 보여 주고, 수정 후 다시 제안된 작업에는 새 승인 상태를 부여해야 합니다. 이 연결이 명확해야 다른 기기에서 재접속한 사용자도 무엇을 허용했고 무엇이 아직 대기 중인지 이해할 수 있습니다.

절전, 연결 끊김과 만료에서 복구하기

기기 간 작업은 정상적인 연결보다 끊어진 뒤의 행동에서 신뢰성이 드러납니다. 원본 PC가 절전 상태에 들어가거나 네트워크가 끊기면 원격 화면은 작업을 완료된 것으로 표시해서는 안 됩니다. “연결 끊김”, “원본 환경 응답 대기”, “실행 결과 확인 필요”처럼 확인 가능한 상태를 보여 줘야 합니다. 마지막으로 받은 출력과 마지막 갱신 시각을 함께 표시하면 사용자는 화면이 최신인지 판단할 수 있습니다.

연결이 끊긴 순간 명령이 이미 전달됐는지 불분명할 수도 있습니다. 이때 같은 행동을 즉시 반복하면 파일 변경, 메시지 전송, 배포 같은 작업이 중복될 수 있습니다. 재연결 후에는 원본 환경에서 실제 결과를 조회하고, 미완료가 확인된 단계만 다시 실행해야 합니다. 각 행동에 중복 실행을 판별할 식별값과 결과 기록을 두면 “버튼을 눌렀지만 응답을 못 받은 상태”를 안전하게 처리하기 쉬워집니다.

앱 상태 변화도 연결 장애만큼 중요합니다. 휴대폰에서 승인 화면을 열어 둔 사이 PC의 파일이 바뀌거나 다른 사용자가 작업을 완료했다면 기존 미리 보기는 오래된 상태입니다. 실행 전에 입력 버전과 현재 단계를 다시 비교하고, 차이가 있으면 승인 요청을 갱신해야 합니다. 원본 앱이 종료됐거나 로그인 세션이 만료됐다면 새 인증 뒤 작업 범위가 그대로인지 확인합니다.

기기 연결용 토큰은 짧은 유효 기간과 명확한 폐기 경로를 가져야 합니다. 만료된 토큰으로 재접속을 시도하면 작업 내용을 계속 보여 주기보다 사용자를 다시 인증하고 해당 세션에 접근할 권한을 확인합니다. 사용자가 기기를 분실하거나 원격 제어를 끝냈다면 연결을 해제하고 남은 토큰과 대기 입력을 폐기할 수 있어야 합니다. 연결 종료와 작업 기록 삭제는 서로 다른 선택으로 제공하는 편이 좋습니다.

복구 화면에는 마지막 성공 단계, 확인되지 않은 행동, 새로 필요한 입력과 다음 선택을 표시해야 합니다. 사용자는 작업을 재개하거나 중지하고, 원본 환경에서 직접 확인하거나, 새 작업으로 다시 시작할 수 있습니다. 여러 작업을 휴대폰에서 지휘하고 상태를 비교하는 경험은 모바일 AI 에이전트 제어: 스마트폰이 작업 지휘실이 되는 순간에서 더 깊게 살펴볼 수 있습니다.

GitHub Copilot CLI 원격 제어 사례

GitHub Copilot CLI 원격 제어는 작업 이전과 원격 지휘를 구분하기 좋은 현재 사례입니다. 사용자는 터미널에서 실행 중인 Copilot CLI 세션을 GitHub Mobile, github.com, VS Code 또는 JetBrains 화면에서 확인하고 지시할 수 있습니다. 실제 CLI 세션은 처음 시작된 환경에서 계속 실행됩니다. 휴대폰이나 웹 화면은 진행 상황을 받아 보고 추가 입력과 결정을 전달하는 지휘 창 역할을 합니다.

GitHub Copilot CLI 원격 제어 정식 제공 안내에 따르면 원격 화면에서는 출력 내용을 실시간으로 보고, 진행 방향을 조정하고, 다음 입력을 대기열에 추가할 수 있습니다. 에이전트가 질문하면 답할 수 있고 권한 요청을 허용하거나 거절하며 세션을 중지할 수도 있습니다. 이 구조에서 휴대폰은 CLI 명령을 로컬로 실행하는 기기가 아니라 원본 세션과 상호작용하는 화면입니다.

구체적인 상황을 보면 차이가 더 분명합니다. 개발자가 회사 노트북에서 Copilot CLI에 테스트 실행과 오류 분석을 맡긴 뒤 이동한다고 가정해 보겠습니다. 휴대폰에서는 테스트 진행과 질문을 확인하고 “해당 파일은 수정하지 말고 원인만 정리해 줘”라는 입력을 대기열에 추가할 수 있습니다. 명령 실행과 저장소 접근은 노트북 환경에 남아 있으므로 해당 환경의 파일, 권한과 도구 상태가 계속 기준이 됩니다.

GitHub의 Copilot CLI 원격 제어 문서는 연결과 지휘 범위를 이해하는 기준을 제공합니다. 사용자는 원격 화면에서 진행을 보더라도 원본 세션이 실행 중인지, 어느 저장소와 환경을 사용 중인지 확인해야 합니다. 휴대폰에서 승인한 명령이 원본 환경에 어떤 변화를 만드는지도 승인 전에 읽을 수 있어야 합니다.

2026년 7월에는 GitHub Mobile의 Copilot CLI 실시간 알림 안내가 발표됐습니다. iOS와 Android에서 원격 CLI 세션의 중요한 상태 변화를 알림으로 받고 해당 세션으로 돌아갈 수 있습니다. 이는 알림 재개와 원격 지휘를 연결하는 방식입니다. 이 사례가 보여 주는 핵심은 실행 환경을 몰래 옮기는 것이 아니라, 실행 장소를 유지하면서 다른 화면에 최신 상태와 통제 수단을 제공하는 것입니다.

현재 FoneClaw의 한 휴대폰 연속성

현재 FoneClaw는 한 Android 휴대폰 안에서 Home과 이동 가능한 플로팅 도우미 사이의 작업 연속성을 강화했습니다. 사용자는 다른 앱을 보고 있는 동안 간결한 패널을 열어 현재 작업 상태를 확인하고, Home으로 돌아간 뒤에도 같은 실행 흐름을 이어갈 수 있습니다. 실제 작업과 Android 권한은 같은 휴대폰에 남으며 표시 위치만 바뀝니다.

예를 들어 사용자가 예약 앱을 보다가 플로팅 도우미를 열고 “이 화면에서 날짜와 장소를 확인해 일정 후보를 만들어 줘”라고 요청할 수 있습니다. 현재 제공되는 한 번 누르기 화면 첨부는 현재 앱 화면을 작업 입력으로 추가하며 FoneClaw의 플로팅 요소는 첨부 이미지에서 제외합니다. 모델은 실제 앱 화면을 기준으로 내용을 이해하고, FoneClaw의 관리되는 Android 도구가 지원되는 후속 작업을 수행합니다.

작업 도중 일정 저장 승인이 필요하면 플로팅 패널에서 대상 캘린더, 날짜, 시간과 예상 결과를 확인할 수 있습니다. 사용자가 Home으로 이동해도 같은 작업의 승인 상태와 실행 위치가 유지됩니다. 작업을 중지하거나 필요한 권한을 설정한 뒤 원래 흐름으로 돌아오는 과정도 Home과 플로팅 도우미 사이에서 이어집니다. 이는 다른 기기로 권한이나 작업 상태를 복제하는 방식이 아니라 한 휴대폰에서 표시 위치가 바뀌어도 맥락을 잃지 않는 경험입니다.

현재 제공되는 독립적인 작업 상태와 대화별 승인은 이 연속성의 기반입니다. 여러 대화가 있을 때 각 작업은 실행 중인지 대기 중인지 별도로 표시되고, 한 대화의 승인은 다른 작업에 섞이지 않습니다. 작업 맥락도 분리되므로 화면 위치를 바꾼 뒤 돌아왔을 때 올바른 대상과 승인 요청을 다시 확인할 수 있습니다.

FoneClaw에서 우리는 설정된 모델의 판단과 Android 도구의 실제 행동을 구분합니다. 모델은 사용자의 의도와 화면 입력을 이해하고 필요한 단계를 계획합니다. 관리되는 도구는 지원되는 휴대폰 작업을 수행하며 권한, 승인, 중지와 결과 확인을 같은 기기 안에서 연결합니다. 현재 FoneClaw의 연속성은 이 작업 상태를 플로팅 도우미와 Home에서 더 쉽게 확인하고 통제하도록 만든 변화입니다.

시작부터 기록 삭제까지 검증하는 점검표

크로스 디바이스 AI 에이전트 핸드오프는 설명만 읽기보다 영향이 낮은 작업으로 직접 시험해야 합니다. 테스트용 폴더에서 파일 목록을 확인하고 요약을 만드는 작업처럼 외부 전송이나 배포가 없는 시나리오가 적합합니다. 원본 환경에서 시작한 뒤 다른 화면으로 이동해 지시를 추가하고, 읽기 권한 요청을 처리하고, 중지와 재연결을 시험하면 작업 상태와 복구 방식을 순서대로 확인할 수 있습니다.

1. 시작: 원본 기기에서 테스트 작업을 만들고 사용자, 에이전트, 입력 폴더, 기대 결과와 금지된 행동이 기록되는지 확인합니다.
2. 원격 지휘: 휴대폰이나 웹에서 같은 작업을 열어 원본 실행 환경, 현재 단계, 마지막 갱신 시각과 진행 출력을 볼 수 있는지 확인합니다.
3. 추가 입력: “파일을 수정하지 말고 오류가 있는 이름만 정리해 줘”라는 조건을 보내고 입력이 대기열에 들어갔는지, 원본 환경이 이를 받았는지 살펴봅니다.
4. 승인: 에이전트가 파일 읽기나 명령 실행을 요청할 때 작업, 행동, 대상, 실행 환경이 표시되는지 확인하고 한 번은 허용하고 한 번은 거절해 봅니다.
5. 중지: 원격 화면에서 세션을 중지한 뒤 원본 환경에서도 실행이 멈췄는지, 이미 완료된 결과와 미실행 단계가 구분되는지 확인합니다.
6. 재연결: 네트워크를 끊었다가 다시 연결하고 마지막 성공 단계, 확인되지 않은 행동과 갱신된 입력을 보여 주는지 살펴봅니다.
7. 기록: 어떤 기기에서 시작했고 누가 무엇을 승인했으며 실제로 어떤 결과가 생성됐는지 작업 기록에서 확인합니다.
8. 삭제: 원격 연결을 해제하고 토큰, 대기 입력, 작업 기록과 산출물을 각각 선택해 삭제할 수 있는지 확인합니다.

작업 이전 기능을 시험한다면 별도의 검사가 필요합니다. 새 기기가 원래 입력을 정확히 받았는지, 실행 환경이 실제로 바뀌었다고 표시되는지, 새 기기의 권한을 다시 확인하는지 살펴보세요. 원본과 새 환경이 동시에 같은 단계를 실행하지 않도록 소유권 전환 시점도 기록돼야 합니다. 이전 직전에 입력이 바뀌었다면 새 환경은 오래된 상태로 진행하지 않고 갱신이나 사용자 선택을 요구해야 합니다.

현재 FoneClaw는 한 휴대폰 안의 연속성을 별도로 시험할 수 있습니다. 민감하지 않은 앱 화면을 첨부해 요약을 요청하고, 플로팅 도우미에서 Home으로 이동한 뒤 다시 작업을 여세요. 실행 중·대기 중 상태, 승인, 중지, 권한 복구가 같은 대화에 유지되는지 확인합니다. 화면 첨부에 FoneClaw 플로팅 요소가 빠지고 실제 앱 내용만 전달되는지도 검토할 수 있습니다.

마지막 판단 기준은 단순합니다. 사용자는 지금 어느 환경에서 작업이 실행되는지, 어떤 입력과 권한을 사용하는지, 무엇이 승인 대기 중인지, 연결이 끊겼을 때 실제 결과가 있었는지를 알아야 합니다. 이러한 정보가 시작부터 삭제까지 이어질 때 크로스 디바이스 연속성은 편리한 원격 화면을 넘어 검증 가능한 작업 통제 방식이 됩니다.