Android AI 에이전트 작업 대기열: 다중 대화, 세션 승인, 복구 설계

여러 에이전트 대화에 실제 작업 대기열이 필요한 이유

Android AI 에이전트 작업 대기열은 메시지를 순서대로 쌓아 두는 채팅 목록이 아닙니다. 우리가 FoneClaw를 만들며 가장 먼저 부딪힌 문제는 “대화는 여러 개 열 수 있는데, 휴대폰 작업은 같은 기기 위에서 실제 효과를 낸다”는 점이었습니다. 한 대화에서는 “회의 전 방해 금지 모드 켜줘”라고 요청하고, 다른 대화에서는 “방금 본 화면을 설명해 줘”라고 물을 수 있습니다. 두 요청이 같은 권한, 같은 화면, 같은 승인 버튼을 공유하면 사용자는 어떤 작업이 어디까지 진행됐는지 알기 어렵습니다.

폰 작업은 중간에 자주 멈춥니다. 권한이 빠져 있을 수 있고, 사용자의 승인이 필요할 수 있고, 앱 화면이 바뀌었을 수 있고, 네트워크나 기기 상태 때문에 기다려야 할 수 있습니다. 대화 UI만 여러 개 있다고 해서 이런 상태가 자동으로 분리되지는 않습니다. Android 에이전트 동시성에서 중요한 것은 많은 말풍선을 여는 능력이 아니라, 각 작업의 목표와 현재 상태와 다음 행동을 독립적으로 유지하는 능력입니다.

그래서 우리는 작업 대기열을 작업 생명주기 제어로 봅니다. 작업은 생성되고, 실행되고, 멈추고, 권한을 기다리고, 사용자의 승인을 받고, 다시 확인되고, 완료되거나 복구됩니다. 여러 단계 Android 자동화의 일반적인 구성법은 한 번의 음성 명령으로 Android 작업 자동화하기: FoneClaw 고급 가이드에서 더 깊게 다루고, 이 글에서는 여러 대화가 동시에 존재할 때 그 작업들이 어떻게 섞이지 않아야 하는지에 집중합니다.

실행, 대기, 승인, 권한, 중지, 완료 상태

작업 대기열이 유용해지려면 상태 이름이 사용자에게 의미가 있어야 합니다. “처리 중” 하나로 모든 것을 덮으면 사용자는 기다려야 하는지, 승인해야 하는지, 설정을 열어야 하는지, 작업을 다시 시작해야 하는지 알 수 없습니다. FoneClaw에서 우리는 Android 폰 작업을 볼 때 상태를 작게 나누는 편이 더 안전하다고 봅니다. 상태가 분명하면 대화가 바뀌어도 작업의 다음 행동이 흐려지지 않습니다.

대기는 완료도 실패도 승인도 아닙니다. 예를 들어 “회의 전에 DND 켜기” 작업이 권한을 기다리는 동안, 사용자는 다른 대화에서 화면 요약을 요청할 수 있습니다. 이때 첫 작업은 권한 필요 상태로 남아 있고, 두 번째 작업은 독립적으로 실행될 수 있어야 합니다. 대기 상태를 제대로 표현하면 사용자는 에이전트가 멈춘 이유를 이해하고, 다른 작업으로 넘어갔다가도 원래 작업으로 돌아올 수 있습니다.

상태 전이는 더 중요합니다. 승인 필요에서 완료로 바로 건너뛰려면 사용자가 승인해야 합니다. 권한 필요에서 실행 중으로 돌아가려면 권한 상태를 다시 확인해야 합니다. 중지됨에서 재개하려면 현재 화면과 원래 목표가 여전히 맞는지 확인해야 합니다. 이런 작은 전이가 모여 신뢰 가능한 Android 에이전트 작업 대기열을 만듭니다.

대화 정체성과 작업 격리

작업 격리는 여러 대화가 독립적으로 실행되는 데 필요한 기본 조건입니다. 대화 A에서 만든 메시지 초안, 대화 B에서 요청한 DND 변경, 대화 C에서 보고 있는 현재 화면이 같은 메모리처럼 섞이면 폰 에이전트는 빠르게 위험해집니다. 각 작업에는 어느 대화에서 시작됐는지, 사용자가 무엇을 요청했는지, 어떤 대상 앱이나 기능을 향하는지, 어떤 화면 맥락을 사용했는지, 어떤 도구가 제안됐는지, 어떤 승인이 남았는지가 붙어 있어야 합니다.

여기서 대화 정체성은 모델의 임시 문맥 창과 다릅니다. 모델은 긴 대화를 기억하는 것처럼 보일 수 있지만, Android 작업에는 더 단단한 식별자가 필요합니다. 사용자가 대화를 전환해도 작업 식별자는 유지되어야 하고, 승인 카드가 나타날 때는 어느 대화의 어떤 작업인지 보여 줘야 합니다. 대화가 닫히거나 최근 목록으로 이동해도 대기 중인 작업은 자신의 상태와 다음 행동을 잃지 않아야 합니다.

격리의 목적은 사용자를 귀찮게 하는 것이 아니라 작업의 출처를 분명하게 만드는 것입니다. 예를 들어 한 대화에서 “민수에게 늦는다고 보낼 초안”을 만들고, 다른 대화에서 “팀 채널에 회의 요약”을 만들었다면 두 초안의 대상과 문맥은 분리되어야 합니다. 사용자가 두 번째 대화에서 승인 버튼을 눌렀을 때 첫 번째 초안이 전송되는 구조는 작업 대기열 설계의 실패입니다.

더 깊은 신원, 권한, 감사 로그 설계를 보려면 AI 에이전트 신원과 권한: 도구별 승인 제어와 감사 로그 설계가 도움이 됩니다. 이 글에서는 제품 보안 전체보다 다중 대화 안에서 어떤 상태가 원래 세션에 붙어 있어야 하는지를 다룹니다. 작업 격리는 보안의 일부이고, Android 권한, 도구 정책, 승인 기록, 사용자 검토와 함께 작동할 때 힘을 얻습니다.

승인 UX를 복잡하게 만들지 않는 세션 기반 승인

세션 기반 승인은 승인 버튼을 더 많이 만드는 일이 아닙니다. 좋은 승인은 하나의 카드 안에서 “어느 대화의 어떤 작업인지, 무엇을 바꾸는지, 어느 대상에 적용되는지, 승인 후 어떤 결과가 생기는지”를 보여 줍니다. 사용자가 대화를 전환한 뒤에도 승인 카드는 원래 작업에 묶여 있어야 합니다. 대기하거나 거절한 승인이 다른 작업의 허가로 이동하는 흐름은 폰 작업에서 특히 위험합니다.

최소한의 승인 정보는 네 가지입니다. 첫째, 원래 대화 또는 작업 이름입니다. 둘째, 대상입니다. 연락처, 앱, 설정, 파일, 화면 흐름 같은 실제 효과의 위치입니다. 셋째, 제안된 행동입니다. 켜기, 보내기, 열기, 변경, 저장처럼 결과를 명확히 말해야 합니다. 넷째, 현재 상태입니다. 권한이 준비됐는지, 화면이 여전히 맞는지, 마지막 확인 뒤 시간이 얼마나 지났는지를 사용자가 이해할 수 있어야 합니다.

승인 UX 자체의 세밀한 설계는 AI 에이전트 승인 UX: 신뢰도, 작업 이유, 확인과 복구를 설계하는 법에서 더 깊게 다룹니다. 여기서의 핵심은 승인 정체성입니다. 폰 에이전트는 “사용자가 방금 눌렀다”는 사실만 보지 않고, 그 승인이 어느 작업에 속하는지 확인해야 합니다. 세션 기반 승인은 다중 대화 AI 에이전트가 같은 화면 위에서 여러 작업을 다룰 때 잘못된 실행을 줄이는 실질적인 장치입니다.

병렬 에이전트 팀과 휴대폰 작업 대기열의 차이

다중 대화 AI 에이전트라는 말은 종종 병렬 에이전트 팀과 섞입니다. MiniMax Agent Team 소개는 leader, worker, verifier 역할을 나누고, 장시간 작업에서 중간 상태를 보존하며, 일시 중지와 재개, 사람의 개입을 다루는 방향을 보여 줍니다. 이런 구조는 연구, 문서 작성, 코드 작업처럼 여러 하위 작업을 나눠 처리하는 데 적합합니다. 하지만 휴대폰 위의 실제 동작은 같은 방식으로 동시에 밀어붙이기 어렵습니다.

휴대폰은 단일 사용자의 개인 기기입니다. 화면은 하나이고, 전경 앱도 하나이며, 알림, 권한, 입력 포커스, Bluetooth, 위치, 계정 상태가 동시에 얽힙니다. 여러 연구 에이전트가 병렬로 조사하는 것은 가능해도, 한 Android 기기에서 두 작업이 동시에 같은 설정 화면을 바꾸거나 같은 메시지 앱에 다른 초안을 넣는 것은 사용자가 이해하기 어렵습니다. 그래서 Android 에이전트 동시성은 병렬 추론보다 순서 있는 실행, 대기, 승인, 중지, 복구에 더 가깝습니다.

OPPO는 Google Cloud와의 AIOS 방향 발표에서 Agent-to-Agent 상호운용, 기기와 클라우드 협업, 메모리와 개인정보 보호를 차세대 생태계 방향으로 설명했습니다. OPPO Mente Lab의 X-OmniClaw 저장소는 세션별 에이전트 루프, 격리된 런타임, 정밀한 중지 체인을 설계 신호로 보여 줍니다. 이런 흐름은 업계가 세션 분리와 중지를 런타임 문제로 보고 있음을 말해 줍니다.

Microsoft도 워크플로 중심 멀티 에이전트 아키텍처에서 오케스트레이션, 에이전트, 상태, 프로세스 제어를 분리해 설명합니다. FoneClaw에서 우리가 가져오는 교훈은 명확합니다. 지식 작업은 병렬로 나눌 수 있지만, 휴대폰 작업은 사용자가 볼 수 있는 순서와 상태로 정리되어야 합니다. 병렬 에이전트 팀은 산출물을 만들고, 폰 작업 대기열은 개인 기기에서 실제 효과가 나는 단계들을 사용자 통제 아래 진행합니다.

중지, 재개, 권한 복구, 오래된 상태 확인

작업 대기열의 품질은 일이 잘 풀릴 때보다 끊겼을 때 드러납니다. 사용자가 DND를 켜려 했는데 권한이 빠져 있고, 그 사이 다른 대화에서 화면 설명을 요청했다고 해 보겠습니다. 좋은 대기열은 첫 작업을 권한 필요 상태로 남겨 둡니다. 두 번째 대화는 별도 상태로 진행합니다. 사용자가 다시 첫 작업으로 돌아오면 원래 목표, 필요한 권한, 마지막으로 확인한 화면, 다음 행동을 보여 줍니다.

재개는 단순히 다시 실행하는 일이 아닙니다. Android에서는 시간이 지나면 화면이 바뀌고, 앱이 닫히고, 권한이 바뀌고, 네트워크가 끊기고, 사용자가 직접 일부 단계를 처리했을 수 있습니다. 그래서 재개 전에는 네 가지를 다시 확인해야 합니다. 원래 대상이 맞는지, 현재 화면이 예상과 맞는지, 필요한 권한이 있는지, 실행하려는 효과가 여전히 사용자의 의도와 맞는지입니다. 오래된 작업은 새 미리 보기나 짧은 확인 질문을 거쳐야 자연스럽습니다.

중지도 독립 상태로 다뤄야 합니다. 사용자가 중지하면 진행 중인 도구 호출과 남은 단계가 멈추고, 이미 발생한 효과와 아직 실행되지 않은 효과가 구분되어야 합니다. 모든 Android 행동을 되돌릴 수 있는 것은 아니므로, 복구는 “무조건 원복”이 아니라 “현재 상태를 확인하고 다음 안전한 선택지를 제시”하는 쪽에 가깝습니다. 권한 복구도 마찬가지입니다. 설정 화면으로 보내는 것만으로 끝나지 않고, 권한이 돌아온 뒤 원래 작업이 여전히 유효한지 확인해야 합니다.

FoneClaw에서 우리는 지원되는 Android 작업을 governed tools, 권한 흐름, 승인, 보이는 결과, 복구로 묶어 다룹니다. 공개 기능 범위는 FoneClaw 기능 페이지에서 확인할 수 있으며, 100+ built-in tools라는 안정적인 표현으로 기능 표면을 설명합니다. 대기열 설계의 목적은 많은 작업을 한꺼번에 밀어 넣는 것이 아니라, 멈춘 작업을 사용자가 이해할 수 있는 상태로 되돌리는 것입니다.

현재 FoneClaw가 다중 대화 작업을 이어 가는 방식

현재 공개된 FoneClaw는 recent-session management, strict cross-conversation task queue, independent running and waiting states, session-bound approvals, task isolation, permission recovery 기반을 이어받고, 이동 가능한 플로팅 어시스턴트, 의도적인 현재 화면 첨부, Home과 플로팅 어시스턴트 사이의 작업 연속성을 더했습니다. 사용자는 FoneClaw 다운로드 페이지에서 현재 앱을 받아 이 흐름을 직접 확인할 수 있습니다.

우리가 이 구조를 만든 이유는 실제 Android 사용 흐름이 한 화면에 머물지 않기 때문입니다. 사용자는 Home에서 “회의 전 준비”를 시작하고, 알림을 보고, 설정 화면으로 이동하고, 다른 앱 위에서 플로팅 어시스턴트를 다시 열 수 있습니다. 이때 원래 작업이 사라지거나 다른 대화와 섞이면 사용자는 에이전트가 무엇을 하려는지 잃어버립니다. FoneClaw의 작업 연속성은 Home과 플로팅 어시스턴트가 실행, 승인, 중지, 권한 복구를 같은 작업 상태로 이어 가도록 설계된 흐름입니다.

예를 들어 대화 A에서 “회의 모드 준비”를 시작하고 DND 권한이 필요해졌다고 해 보겠습니다. 작업은 권한 필요 상태로 대기합니다. 사용자는 대화 B로 이동해 “현재 화면을 설명해 줘”라고 요청할 수 있습니다. 대화 B의 현재 화면 첨부는 사용자가 의도적으로 붙인 맥락이고, 대화 A의 DND 권한 상태와 분리됩니다. 나중에 대화 A로 돌아오면 FoneClaw는 원래 목표와 권한 복구 경로를 다시 보여 줍니다.

이 구조는 병렬 멀티 에이전트 플랫폼을 표방하기 위한 것이 아니라, 개인 Android 기기에서 여러 대화의 작업 상태를 안전하게 운반하기 위한 것입니다. 설정된 모델은 추론과 계획을 맡고, FoneClaw는 지원되는 Android 실행, 세션 기반 승인, 작업 격리, 중지, 복구를 담당합니다. 우리가 만들고 있는 방향은 사용자가 여러 대화를 열어도 각 작업이 자신의 이름표와 다음 행동을 잃지 않는 폰 에이전트 런타임입니다.

Android 에이전트 작업 대기열 평가 체크리스트

Android 에이전트 작업 대기열을 평가할 때는 열린 채팅 수보다 작업 정체성과 다음 행동이 보이는지를 봐야 합니다. 가장 작은 테스트는 두 개의 낮은 위험 대화로 시작합니다. 대화 A에서 DND 상태 확인이나 볼륨 점검처럼 되돌리기 쉬운 작업을 요청합니다. 일부러 권한 필요 또는 승인 필요 상태에서 멈춥니다. 대화 B로 전환해 현재 화면 설명이나 앱 열기 같은 별도 요청을 실행합니다. 다시 대화 A로 돌아와 원래 작업이 그대로 남아 있는지 확인합니다.

• 정체성: 승인 카드가 원래 대화, 작업, 대상, 제안된 행동을 보여 주는가.
• 상태 명확성: 실행 중, 대기, 승인 필요, 권한 필요, 중지, 완료가 구분되는가.
• 격리: 대화 B의 화면 맥락이나 승인 결과가 대화 A 작업에 섞이지 않는가.
• 순서: Android에서 실제 효과가 나는 작업이 사용자가 이해할 수 있는 순서로 진행되는가.
• 복구: 권한 변경, 앱 전환, 중지 뒤에도 원래 목표와 현재 조건을 다시 확인하는가.

이 테스트를 통과한 뒤에야 메시지 전송, 파일 공유, 공개 게시처럼 외부 효과가 큰 작업으로 넓히는 편이 좋습니다. 휴대폰 에이전트의 품질은 많은 작업을 동시에 시작하는 능력보다, 여러 대화 속에서도 작업 상태와 승인 정체성을 끝까지 보존하는 능력에서 드러납니다. 더 넓은 감독 관점은 모바일 AI 에이전트 제어: 스마트폰이 작업 지휘실이 되는 순간에서 이어서 볼 수 있습니다.