AI 에이전트 기능 라우팅: AutoAttach, Suggest, Fallback 실전 가이드

Android 요청을 기능 후보로 바꾸기

AI 에이전트 기능 라우팅은 사용자의 말을 곧바로 실행하는 과정이 아니다. 예를 들어 사용자가 “이 화면의 배송 정보를 메모하고 내일 확인 알림을 만들어줘”라고 말하면, 에이전트는 먼저 현재 화면 읽기, 메모 작성, 알림 생성, 일정 확인, 앱 열기 같은 기능 후보를 만든다. 그다음 화면 맥락, 사용자의 의도, 기기 권한, 지원되는 Android 도구, 활성화된 Skill이나 Plugin 상태를 보고 후보 순위를 정한다.

모든 도구와 확장 기능을 매 요청마다 한꺼번에 모델 문맥에 넣을 수는 없다. 너무 많은 기능 설명을 넣으면 비용과 지연 시간이 늘고, 모델이 엉뚱한 도구를 고를 가능성도 커진다. 그래서 상황별 기능 매칭은 “가능한 모든 기능”을 나열하는 일이 아니라, 지금 요청에 필요한 후보를 좁히고 실행 가능성을 평가하는 일이다.

여기서 중요한 경계가 있다. 의미가 맞는 기능을 찾았다고 해서 그 기능을 실행할 권한이 생기지는 않는다. “알림”이라는 단어가 들어갔다면 알림 관련 후보를 올릴 수 있지만, 실제 알림을 만들려면 지원 도구, 권한, 사용자 확인, 결과 검증이 필요하다. 일반적인 도구, Plugin, Skill, Workflow의 계층 정의가 필요하다면 FoneClaw 도구·플러그인·스킬·워크플로 차이: Android 폰 에이전트 확장 계층 가이드에서 전체 구조를 먼저 볼 수 있다. 이 글은 그 계층을 다시 정의하기보다, 하나의 요청이 어떤 경로로 기능 후보를 통과하는지에 집중한다.

AutoAttach, Suggest, Fallback 선택 기준

FoneClaw에서 기능 라우팅을 설계할 때 우리가 특히 분리해서 보는 경로가 AutoAttach, Suggest, Fallback이다. 세 가지는 모두 라우팅에 속하지만 역할이 다르다. AutoAttach는 확신이 높은 맥락이나 기능 정보를 요청에 붙여 모델이 더 정확히 판단하게 돕는 경로다. Suggest는 실행이나 활성화가 필요할 수 있는 선택지를 사용자에게 보이게 제안하는 경로다. Fallback은 지원 기능이 없거나, 확신이 낮거나, 권한과 상태가 맞지 않을 때 안전한 다음 단계로 이어 가는 경로다.

AutoAttach는 실행이 아니다. 현재 화면 요약에 필요한 화면 정보, 선택한 파일의 메타데이터, 이미 활성화된 로컬 Skill의 설명처럼 사용자가 요청한 작업과 강하게 맞는 정보를 붙일 수 있다. 하지만 AutoAttach가 도구를 누르거나 Plugin을 설치하거나 외부 결과를 만드는 것은 아니다. 자동으로 붙이는 것은 맥락과 후보 정보이지, 민감한 행동이 아니다.

Suggest는 사용자가 선택할 수 있어야 하는 순간에 쓰인다. 예를 들어 요청에 맞는 Plugin 후보가 있지만 아직 활성화되지 않았거나, 여러 Skill이 비슷한 작업을 다룰 수 있거나, 같은 이름의 앱이 두 개 있을 때는 Suggest가 맞다. 사용자는 어떤 기능을 쓸지, 설치나 활성화를 진행할지, 기존 내장 도구로 계속할지 볼 수 있어야 한다.

Fallback은 실패를 감추는 장치가 아니다. 기능이 없거나, 의존성이 빠졌거나, 권한이 거부되었거나, 후보가 애매할 때 작업을 안전하게 멈추고 다음 선택을 제공하는 경로다. 예를 들어 “이 영상을 다운로드해줘”라는 요청에서 적절한 신뢰 경로가 없으면 무작정 웹에서 APK를 찾지 않는다. 대신 현재 지원되는 범위, 필요한 Plugin 제안, 사용자가 확인해야 할 경계를 보여준다.

발견부터 실행까지 상태를 분리하기

기능 라우팅에서 가장 자주 생기는 오류는 발견, 첨부, 설치, 활성화, 승인, 실행을 한 덩어리로 보는 것이다. 좋은 라우터는 이 상태들을 분리한다. 발견은 후보를 찾는 일이다. 첨부는 현재 요청에 필요한 맥락이나 기능 설명을 붙이는 일이다. 설치는 아직 없는 확장 기능을 기기에 가져오는 일이다. 활성화는 설치된 기능을 사용할 수 있는 상태로 전환하는 일이다. 승인은 특정 작업을 실행해도 되는지 사용자가 확인하는 일이다. 실행은 실제 Android 동작이고, 결과 확인은 그 동작이 끝났는지 검증하는 일이다.

Agent Plugins 같은 흐름은 Skill과 MCP 서버를 하나의 패키지로 묶는 방향을 보여준다. Google Developers의 Agent Plugins 설명도 패키징 메타데이터와 공유 형식을 다룬다. 하지만 패키징은 신뢰, 활성화, 실행 승인과 다르다. 어떤 Plugin이 발견되었다고 해서 설치된 것도 아니고, 설치되었다고 해서 모든 요청에서 실행 승인된 것도 아니다.

GitHub의 agent finder 같은 흐름도 같은 교훈을 준다. GitHub Changelog의 agent finder 안내는 요청에 맞는 리소스를 찾고 순위를 매기는 방식을 보여주지만, 발견이 조용한 설치를 뜻하지는 않는다. FoneClaw에서도 이 원칙을 지킨다. 후보 탐색은 후보 탐색이고, 실행은 실행이다.

상태를 분리하면 사용자가 무엇을 맡겼는지 알 수 있다. “배송 정보를 메모하고 알림을 만들어줘”라는 요청에서 화면 맥락은 AutoAttach될 수 있다. 메모 기능은 이미 지원되는 내장 도구 후보로 올라올 수 있다. 알림 생성에 필요한 권한이 없다면 복구 안내가 필요하다. 저장 전 문구와 알림 시간은 승인 단계에서 확인된다. 이렇게 나눠야 기능 라우팅이 신뢰할 수 있는 Android 실행으로 이어진다.

매니페스트, 의존성, 맥락, 신뢰도 활용하기

상황별 기능 매칭은 단어 유사도만으로 결정하면 약하다. 라우터는 기능 매니페스트, 의존성, 현재 맥락 메타데이터, 권한 상태, 사용자 선택 이력, 신뢰도 점수를 함께 봐야 한다. 매니페스트는 기능의 이름, 입력 형식, 출력, 위험도, 필요한 권한, 지원 범위를 알려준다. 의존성은 그 기능이 실행되기 전에 필요한 앱, Plugin, 계정, 네트워크, 시스템 권한을 보여준다.

의존성이 해결되지 않은 기능은 바로 실행 후보가 아니라 준비 후보가 된다. 예를 들어 어떤 Skill이 특정 Plugin 도구를 필요로 한다면 Plugin이 설치되고 검토되고 활성화되어야 한다. 기능 설명이 그럴듯해도 의존성이 빠져 있으면 Suggest나 Fallback으로 가야 한다. 또한 기능 집합을 갱신할 때는 부분적으로 활성화된 상태를 남기면 위험하다. FoneClaw는 기능 스냅샷을 안정적으로 다루는 방향으로 설계해, 갱신 실패가 곧 깨진 후보 목록으로 이어지지 않게 한다.

맥락 메타데이터도 중요하다. 현재 화면이 쇼핑 앱인지, 메신저인지, 캘린더인지에 따라 같은 “저장해줘”라는 요청의 의미가 달라진다. 화면에 배송 번호가 있으면 메모와 알림 후보가 올라갈 수 있고, 대화방이 열려 있으면 메시지 초안 후보가 올라갈 수 있다. 하지만 맥락이 보인다고 해서 바로 전송하거나 저장하는 것은 아니다.

신뢰도는 숫자 하나로 끝나지 않는다. 높은 신뢰도는 AutoAttach를 허용할 수 있지만, 외부 결과가 생기는 실행은 별도 승인으로 넘어간다. 낮은 신뢰도는 사용자의 선택을 요구하거나 Fallback으로 이어진다. 매니페스트와 권한 위험을 더 깊게 보고 싶다면 AI 에이전트 스킬 보안: 검사 통과보다 실행 중 권한 확인이 중요한 이유에서 실행 중 권한 확인의 중요성을 이어서 볼 수 있다.

기능이 없거나 애매할 때 복구하기

좋은 Android 에이전트 도구 라우팅은 실패를 조용히 반복하지 않는다. 기능이 없으면 없다고 말하고, 대안을 제시한다. 후보가 오래되었으면 기능 목록을 다시 확인하거나 마지막으로 검증된 상태로 돌아간다. 권한이 거부되었으면 권한 복구 경로를 보여준다. 대상이 애매하면 사용자가 고를 수 있게 한다. 실패 원인이 다르면 복구도 달라야 한다.

기능 없음은 가장 단순한 경우다. 예를 들어 요청에 맞는 내장 도구가 없고 활성화된 Skill도 없다면, 라우터는 무리하게 비슷한 기능을 실행하지 않는다. 사용 가능한 작업으로 바꾸거나, 필요한 확장 기능을 제안하거나, 사용자가 직접 처리해야 하는 지점을 알려준다. 이때 Suggest는 유용하지만, 제안이 곧 설치나 실행은 아니다.

오래된 의존성은 더 미묘하다. Plugin은 설치되어 있지만 기능 매니페스트가 바뀌었거나, 필요한 권한이 사라졌거나, 네트워크 상태 때문에 확인이 불완전할 수 있다. 이런 상태에서는 이전 결과를 맹신하지 않고 검증된 스냅샷을 기준으로 판단해야 한다. 거부된 권한은 모델 재시도로 해결되지 않는다. Android 설정이나 앱 권한 화면을 통해 사용자가 결정해야 한다.

대상이 애매한 경우도 많다. 연락처에 같은 이름이 두 명 있거나, “이 앱”이 현재 화면 앱인지 최근 사용 앱인지 불명확하거나, “내일”이 사용자의 시간대와 맞는지 확인이 필요할 수 있다. 이때 라우터는 실행을 늦추더라도 질문해야 한다. 승인과 복구의 화면 설계가 궁금하다면 AI 에이전트 승인 UX: 신뢰도, 작업 이유, 확인과 복구를 설계하는 법에서 신뢰도와 확인 문구를 더 구체적으로 볼 수 있다.

FoneClaw의 안전한 기능 라우팅

FoneClaw에서 우리는 기능 라우팅을 Android 폰 에이전트의 실행 전 단계로 다룬다. 사용자의 요청과 현재 맥락을 보고 후보를 만들고, 100+ built-in tools, Skill, Workflow, reviewed Plugin 경로 중 현재 작업에 맞는 후보를 좁힌다. 이 과정은 사용자를 대신해 무언가를 몰래 실행하는 흐름이 아니다. 후보를 찾고, 필요한 맥락을 붙이고, 제안을 보여주고, 지원되지 않는 경로에서는 Fallback을 제공하는 흐름이다.

AutoAttach는 사용자가 요청한 작업을 더 정확히 이해하기 위한 맥락 연결에 쓰인다. 예를 들어 플로팅 어시스턴트에서 현재 화면을 사용자가 첨부한 경우, 화면의 텍스트와 앱 맥락은 배송 메모나 일정 후보를 고르는 데 도움을 준다. 하지만 이 단계는 실행이 아니다. 저장, 전송, 삭제, 설정 변경 같은 결과가 남는 행동은 별도의 승인과 도구 계약을 거친다.

Suggest는 사용자가 선택해야 할 후보를 보여주는 데 쓰인다. 요청에 맞는 Skill을 배울 수 있거나, Plugin 활성화가 도움이 될 수 있거나, 여러 내장 도구가 비슷하게 보일 때 FoneClaw는 보이는 선택지를 제공한다. Skill learning은 preview와 confirmation을 거쳐 비활성 초안으로 저장될 수 있다. Plugin activation은 검토 가능한 상태를 거쳐야 한다. 제안은 편의 기능이지만, 조용한 설치나 자동 실행은 아니다.

Fallback은 제품의 약속을 지키는 장치다. 지원되지 않는 앱 제어, 빠진 권한, 불명확한 대상, 실패한 실행이 있을 때 FoneClaw는 다음에 할 수 있는 일을 보여준다. 예를 들어 “배송 번호를 저장하고 내일 확인”이라는 요청에서 화면을 읽을 수 없으면 화면 첨부를 요청할 수 있고, 알림 권한이 없으면 권한 복구를 안내할 수 있으며, 알림 대신 메모만 저장하는 대안을 제시할 수 있다.

우리는 이 구조를 통해 모델의 계획과 Android 실행을 분리한다. 모델은 후보를 해석하고 순서를 제안한다. FoneClaw는 지원되는 기능, 활성화 상태, 권한, 승인, 결과 확인을 관리한다. 더 넓은 리소스 발견과 신뢰 경계는 Agentic Resource Discovery란? ai-catalog.json과 폰 에이전트 신뢰 경계에서 별도로 다루고, 이 페이지에서는 요청 하나가 실제 기능 라우팅을 통과하는 방식을 중심으로 본다.

기능 라우터 설계와 테스트 체크리스트

기능 라우터는 정확도만으로 평가하면 부족하다. 맞는 후보를 고르는 능력만큼 잘못된 후보를 붙이지 않는 능력, 후보가 없을 때 멈추는 능력, 권한과 활성화 상태를 구분하는 능력이 중요하다. 테스트는 성공 사례와 실패 사례를 함께 넣어야 한다. “현재 화면을 메모해줘”처럼 명확한 요청, “그거 저장해줘”처럼 애매한 요청, 지원 기능이 없는 요청, 권한이 거부된 요청을 모두 봐야 한다.

• 후보 품질: 요청과 맥락에 맞는 기능 후보가 상위에 오는지 확인한다.
• 오탐 방지: 비슷하지만 위험한 기능을 AutoAttach하지 않는지 본다.
• no-match 처리: 맞는 기능이 없을 때 억지 실행 대신 Fallback을 제공하는지 확인한다.
• 의존성 상태: 필요한 앱, Plugin, 권한, 계정 상태를 실행 전에 구분하는지 본다.
• 활성화 경계: 발견과 설치, 설치와 활성화, 활성화와 실행 승인을 분리하는지 확인한다.
• 승인 경계: 전송, 삭제, 공유, 설정 변경 앞에서 사용자 확인이 보이는지 본다.
• 복구 증거: 실패 후 이유와 다음 선택지가 남는지 확인한다.

AI 에이전트 기능 라우팅의 목표는 더 많은 기능을 무조건 자동으로 붙이는 것이 아니다. 목표는 사용자의 요청에 필요한 기능을 정확히 좁히고, 확신이 높은 맥락은 조심스럽게 붙이고, 선택이 필요한 후보는 보이게 제안하고, 실행 전 승인과 실패 후 복구를 분명하게 유지하는 것이다. FoneClaw는 이 기준을 Android 사용자가 실제 작업에서 느낄 수 있는 방향으로 계속 다듬고 있다.