상태 비저장 MCP와 상태 유지 Agent 워크플로: Android 폰 에이전트 작업 상태 설계

MCP 2026-07-28에서 바뀐 것

MCP 2026-07-28을 폰 에이전트 관점에서 읽으면 답은 분명합니다. 프로토콜 전송은 더 상태 비저장에 가까워졌고, 애플리케이션은 여전히 상태를 가져야 합니다. MCP 2026-07-28 공식 릴리스 안내는 stateless protocol core, self-describing requests, MRTR, header routing, cacheable lists, authorization hardening, extensions framework, Tasks extension을 포함한 변화를 정리합니다. 이 변화는 서버 배포와 라우팅을 단순하게 만들지만, Android 폰 작업의 승인과 복구까지 프로토콜이 대신 맡는 구조는 아닙니다.

SEP-2575 상태 비저장 MCP 제안은 mandatory initialization handshake를 제거하고, session-negotiated assumption 대신 per-request metadata를 쓰는 방향을 설명합니다. 핵심은 요청이 자신이 필요한 능력과 맥락을 더 명확히 들고 다니는 것입니다. 서버 인스턴스가 바뀌어도 요청을 처리할 수 있게 만들면 round-robin, serverless, 재시작, 배포가 쉬워집니다.

FoneClaw를 만들며 우리가 배운 점은 이 변화가 폰 에이전트에 특히 중요하다는 것입니다. 휴대폰 작업은 대화 한 줄로 끝나지 않습니다. 수신자 확인, 방해금지 권한, 현재 앱 상태, 듀얼 SIM 선택, 승인 기록, 실패 후 복구가 모두 상태입니다. MCP 전송 계층이 가벼워질수록 phone-agent host는 어떤 상태를 자신이 소유하는지 더 분명히 해야 합니다. 도구와 리소스 발견의 신뢰 문제는 Agentic Resource Discovery란? ai-catalog.json과 폰 에이전트 신뢰 경계에서 더 깊게 볼 수 있습니다.

상태 비저장 MCP 요청 생명주기

상태 비저장 MCP의 기본 흐름은 요청 단위로 읽으면 쉽습니다. 클라이언트는 매 요청마다 자신의 프로토콜 버전, 필요한 capability, 인증 맥락, 요청 대상, 필요한 state reference를 함께 보냅니다. 서버는 이전 handshake에서 암묵적으로 저장해 둔 세션을 기대하기보다, 들어온 요청이 가진 정보와 명시적인 handle을 보고 응답합니다. 이 방식에서는 호환되는 어떤 서버 인스턴스도 self-contained request를 처리할 수 있습니다.

discovery도 명확해집니다. 도구 목록이나 리소스 목록은 cacheable list로 다룰 수 있고, header routing은 요청을 올바른 서버 또는 기능 집합으로 보내는 데 도움을 줍니다. 대규모 배포에서는 같은 도구를 여러 인스턴스가 제공하고, 요청이 매번 다른 인스턴스로 갈 수 있습니다. 이때 필요한 것은 “서버 메모리에 있을 것”이라는 기대가 아니라, 명시적인 handle, 요청 metadata, 외부 상태 저장소, idempotency key, correlation id입니다.

SEP-2567 explicit state handles 제안은 implicit protocol session state를 server-minted state handle로 대체하는 방식을 설명합니다. handle은 나중 호출에 이어 전달될 수 있습니다. 하지만 handle은 애플리케이션 전체 상태의 이름표일 뿐입니다. 폰 에이전트에서는 그 handle이 어느 사용자 요청, 어느 Android 기기 상태, 어떤 승인, 어떤 결과 기록과 연결되는지 host가 관리해야 합니다. 이 구분이 없으면 stateless MCP 서버는 확장되더라도 phone-task reliability는 약해집니다.

폰 에이전트가 소유해야 하는 여섯 가지 상태

상태 비저장 MCP와 상태 유지 Agent 워크플로를 함께 쓰려면 상태를 한곳에 뭉뚱그리지 말아야 합니다. FoneClaw에서 Android 작업을 설계할 때 우리는 상태를 최소 여섯 장부로 나눠 봅니다. 어떤 장부는 짧게 남고, 어떤 장부는 감사와 복구를 위해 더 오래 남습니다. 중요한 것은 MCP 서버가 모든 상태를 소유하는 구조보다, phone-agent host가 사용자와 기기 맥락에 가까운 상태를 책임 있게 들고 있는 구조입니다.

승인과 인증은 서로 다른 상태입니다. 인증은 “이 사용자가 이 connector에 접근할 수 있는가”를 다루고, 승인은 “이 순간 이 메시지를 이 사람에게 보내도 되는가”를 다룹니다. Android 기기 상태도 저장값만 믿기보다 실행 직전에 다시 읽어야 합니다. 앱 화면은 바뀌고, 권한은 꺼지고, 네트워크는 끊길 수 있습니다. 신원, 권한, 감사 설계를 더 깊게 다루려면 AI 에이전트 신원과 권한: 도구별 승인 제어와 감사 로그 설계가 이어지는 기준을 제공합니다.

MCP Tasks, MRTR, elicitation과 승인

MCP 2026-07-28의 extensions framework 안에서 Tasks는 장기 작업을 다루기 위한 공식 확장으로 등장합니다. Tasks는 시간이 걸리는 작업에 handle을 부여하고, 클라이언트가 나중에 진행 상태나 결과를 확인하는 패턴에 맞습니다. MRTR과 elicitation은 모델, 도구, 사용자 입력이 오가는 상호작용을 더 구조적으로 만들 수 있습니다. 예를 들어 도구가 “수신자가 두 명입니다. 어느 쪽입니까?” 같은 추가 입력을 요구할 수 있습니다.

폰 에이전트에서는 이 구조가 매우 유용합니다. 길 안내 준비, 파일 변환, 회의 녹음 처리, 메시지 초안 검토처럼 한 요청이 오래 걸리거나 사용자의 추가 선택을 기다릴 수 있습니다. 하지만 task handle은 사용자 승인과 같은 의미가 아닙니다. handle은 작업을 다시 찾는 식별자이고, 승인은 특정 순간의 대상과 결과에 대한 사용자 선택입니다. SMS 전송, 전화 걸기, 설정 변경 같은 행동에서는 별도의 승인 기록이 필요합니다.

취소와 만료도 상태 설계의 일부입니다. 사용자가 작업을 멈추면 Tasks handle은 취소 상태를 가져야 하고, 승인 대기 시간이 지나면 새 기기 상태를 읽고 다시 확인해야 합니다. hidden transport session을 되살리는 방식보다, 명시적인 작업 handle과 승인 기록, 만료 정책을 host가 관리하는 편이 폰 에이전트에 맞습니다. 공식 변화의 큰 틀은 MCP 2026-07-28 릴리스 안내에서 확인할 수 있습니다.

상태 비저장 MCP 위의 상태 유지 Android 작업

실제 예로 “민수에게 10분 늦는다고 문자 보내기 전에 보여줘”라는 Android 작업을 보겠습니다. 사용자의 의도는 FoneClaw host 안에서 작업 상태로 생성됩니다. host는 수신자 후보, 메시지 본문, 기본 SMS 앱, 현재 화면, 필요한 권한을 확인합니다. 외부 connector나 도구 호출이 MCP를 쓴다고 가정하면, 요청은 per-request metadata, task id, idempotency key, 필요한 state handle을 포함해야 합니다. 같은 요청이 다른 서버 인스턴스로 가도 무엇을 해야 하는지 알 수 있어야 합니다.

다음은 승인입니다. 사용자는 수신자와 본문을 보고 “보내기”를 선택합니다. 이 승인 기록은 task handle과 별도로 남아야 합니다. 승인에는 대상, 본문, 시간, 사용자, 기기 상태, 만료 조건이 포함됩니다. 그 뒤 Android 실행 계층은 기본 메시지 앱, 수신자, 완성된 본문, 하나의 안정적인 보내기 컨트롤을 다시 확인합니다. 기기 상태는 실행 직전 재확인해야 합니다. 화면이 바뀌었거나 듀얼 SIM 선택이 뜨면 작업은 사용자가 이어갈 수 있는 상태로 전환됩니다.

실행 후에는 검증이 필요합니다. 전송이 완료됐는지, 초안으로 남았는지, 권한이 부족했는지, 화면 컨트롤이 모호했는지 결과를 기록합니다. 재시도가 필요한 경우 idempotency key가 중요합니다. 같은 메시지를 두 번 보내는 것은 복구가 아니라 중복 외부 효과입니다. 그래서 실패 유형을 나눠야 합니다. 네트워크 일시 오류, 권한 부족, 사용자 취소, 화면 변화, 외부 앱 오류는 서로 다른 복구 경로를 가져야 합니다.

현재 공개된 FoneClaw는 플로팅 어시스턴트, 같은 휴대폰 안 작업 연속성, 권한 복구, 빠른 작업을 제공합니다. 현재 화면 기반 작업 흐름은 Android 플로팅 AI 어시스턴트 현재 화면: 묻고 확인하고 실행하는 방법에서 이어서 볼 수 있습니다. 전화 작업처럼 MCP 도구와 Android native action 선택이 갈리는 사례는 AI 에이전트 전화 걸기: MCP 전화 도구와 Android 다이얼러 방식 비교가 더 구체적으로 다룹니다.

MCP 서버를 확장하면서 폰 작업 신뢰성 지키기

상태 비저장 MCP 서버는 운영 관점에서 장점이 큽니다. 서버를 재시작하기 쉽고, 여러 인스턴스에 요청을 나눌 수 있으며, serverless 배포와도 잘 맞습니다. MCP Go SDK v1.7.0 릴리스는 2026-07-28 프로토콜 생명주기에 맞춘 per-request metadata와 server discovery, legacy protocol version 호환 경로를 구현 예시로 보여 줍니다. SDK마다 세부 적용은 다를 수 있지만, 방향은 분명합니다. 서버는 가벼워지고 요청은 명확해집니다.

폰 작업 신뢰성은 그 위의 host 설계가 지킵니다. 재시도할 수 있는 읽기 작업과 재시도하면 위험한 외부 효과를 구분해야 합니다. 상태 확인, 도구 목록 조회, 초안 생성은 비교적 안전하게 재시도할 수 있습니다. SMS 전송, 전화 걸기, 설정 변경, 파일 삭제처럼 결과가 남는 작업은 idempotency key, 승인 기록, 실행 전 device state recheck, 실행 후 verification이 필요합니다. retry policy는 “실패했으니 다시”가 아니라 실패 유형과 외부 효과를 보고 정해야 합니다.

correlation과 audit도 필수입니다. 한 요청이 어떤 사용자 의도에서 시작됐고, 어떤 MCP 요청으로 나갔으며, 어떤 Android 상태에서 실행됐고, 어떤 결과로 끝났는지 이어져야 합니다. 회의 녹음에서 action item을 만들고 폰 작업으로 넘기는 흐름은 AI 녹음기 MCP: 회의 메모를 확인 가능한 휴대폰 작업으로 바꾸는 법에서 더 잘 보입니다. stateless MCP 서버는 scale을 담당하고, stateful AI agent host는 작업 신뢰성을 담당합니다.

보안 경계와 마이그레이션 체크리스트

보안에서 가장 중요한 구분은 인증, 권한, 승인, 작업 handle입니다. 인증은 누가 접속했는지 확인합니다. 권한은 어떤 리소스나 도구를 쓸 수 있는지 정합니다. 승인은 특정 작업 순간의 사용자 선택입니다. task handle은 장기 작업을 다시 찾는 식별자입니다. 이 네 가지를 섞으면 폰 에이전트가 위험해집니다. MCP 2026-07-28의 authorization hardening은 connector 보안을 강화하는 방향이고, Android phone task에는 host-side 승인과 감사가 함께 필요합니다.

마이그레이션은 단계적으로 진행해야 합니다. 기존 client와 server가 모두 새 생명주기를 한 번에 쓰는 환경만 있는 것은 아닙니다. SDK는 legacy protocol version 호환 경로를 제공할 수 있고, 배포 환경은 version negotiation, capability discovery, explicit state handle 지원 여부를 확인해야 합니다. 우리는 FoneClaw 관점에서 미래 connector를 설계할 때 현재 제품의 phone-host state ownership 원칙을 기준으로 봅니다. 현재 FoneClaw는 MCP 2026-07-28 지원 발표가 아니라, host가 작업 상태와 권한 복구를 유지해야 하는 제품 사례입니다.

• 프로토콜 확인: client와 server가 2026-07-28 생명주기, metadata, discovery, extension을 어떻게 지원하는지 확인합니다.
• 상태 분리: 대화, 작업, 기기, 승인, 인증, 감사 상태의 소유 위치를 문서화합니다.
• handle 설계: explicit state handle과 task handle을 승인 토큰이나 인증 토큰과 구분합니다.
• idempotency 적용: 외부 효과가 있는 Android 행동에는 idempotency key와 결과 검증을 둡니다.
• 복구 경로: 권한 부족, 화면 변화, 사용자 취소, 네트워크 오류를 서로 다른 상태로 기록합니다.
• 감사 연결: 사용자 의도부터 MCP 요청, Android 실행, 결과까지 trace를 이어 둡니다.

FoneClaw가 계속 만드는 방향은 명확합니다. 외부 connector가 stateless하게 확장되더라도, 사용자의 Android 작업은 phone-host 안에서 상태 있게 관리되어야 합니다. 승인과 권한과 복구가 보이는 흐름으로 이어질 때, 상태 비저장 MCP와 상태 유지 Agent 워크플로는 서로 충돌하지 않고 함께 강해집니다.