누군가 에이전트에게 실제 iPhone을 주었던 27 추천수를 받은 r/openclaw 스레드를 발견했고, 그 후로 계속 생각이 납니다

며칠 전 저는 이 r/openclaw 게시물을 발견했습니다: “I gave my agent my actual iphone..”

이 게시물은 27개의 추천수(upvotes)와 16개의 댓글이 달려 있었습니다.

그 낮은 수치야말로 제가 클릭한 정확한 이유였습니다.

가장 흥미로운 에이전트(agent) 아이디어들은 보통 출시 영상으로 다듬어지기 전에 나타납니다. 한 빌더(builder)가 약간은 기괴한(cursed) 무언가를 시도하면, 다른 몇몇 빌더들이 댓글로 몰려들고, 갑자기 이 카테고리가 어디로 향하고 있는지 보이기 시작합니다.

이 스레드(thread)가 바로 그런 느낌이었습니다.

게시자는 시뮬레이터(simulator)를 사용하지 않았다고 말했습니다. 전화기인 척하는 브라우저(browser)가 아닙니다. 실제 iPhone입니다. 그들은 에이전트가 그것에 "완전히" 접근할 수 있다고 말했으며, 나중에 그것이 "꽤나 편법적인(hacky)" "Appium 유형의 레이어(layer)"라고 설명했습니다.

그 한 가지 세부 사항이 헤드라인보다 더 중요합니다.

왜냐하면 만약 당신이 에이전트를 구축하고 있다면, 다음 격전지는 아마 단순히 브라우저 자동화(browser automation)만이 아닐 것이기 때문입니다. 그것은 지속적인 모바일 정체성(persistent mobile identity)입니다. 즉, 실제 전화번호, 실제 앱 세션(app session), 그리고 며칠 동안 상태(state)를 유지하는 실제 로그인된 기기입니다.

그리고 그런 방식으로 생각하기 시작하면, 이것은 더 이상 눈속임(gimmick)처럼 들리지 않습니다.

흥미로운 부분: 이것은 마법이 아니라 표준 모바일 자동화입니다

게시자가 "Appium 유형의 레이어"라고 말했을 때, 모든 것이 더 믿을만해졌습니다.

만약 당신이 이전에 모바일 자동화(mobile automation)를 해본 적이 있다면, 이것은 명백한 원시 요소(primitive)입니다.

capabilities = {
  "platformName": "iOS",
  "appium:automationName": "XCUITest",
...

이것은 어떤 신비로운 AI 네이티브 스택(AI-native stack)이 아닙니다. 그저 모바일 자동화에 그 위에 에이전트 루프(agent loop)를 얹은 것뿐입니다.

그것이 바로 이것이 취약한(fragile) 이유이기도 합니다.

만약 당신의 에이전트가 실제 iPhone UI를 구동하고 있다면, 당신은 항상 다음 단계의 문제에 직면해 있습니다:

Face ID 프롬프트
권한 모달(permissions modal)
이상한 애니메이션 상태(animation state)
오래된 화면 읽기(stale screen read)
잘못된 요소에 찍히는 탭(tap)

그러니 네, 이것은 편법적(hacky)입니다.

하지만 브라우저 에이전트들도 편법적이었습니다. 초기 RPA도 편법적이었습니다. Selenium도 편법적이었습니다. "편법적(Hacky)"이라는 것은 종종 도구(tooling)가 더 좋아지면 사람들이 반드시 원하게 될 무언가의 첫 번째 버전일 뿐입니다.

에이전트용 iPhone을 실제로 어디에 사용할 수 있을까요?

이 지점에서 해당 스레드는 제목보다 더 영리해졌습니다.

게시자는 다음과 같은 것들을 테스트하고 있다고 말했습니다:

승인을 거친 iMessage 초안 작성
iOS Shortcuts (단축어) 실행
API가 없는 앱 사용
모바일 앱 QA/테스트

그것은 탄탄한 목록입니다.

"폰 위의 AI"가 새롭기 때문이 아닙니다. 그런 프레임워크는 너무 피상적입니다.

진정한 유스케이스(use case)는 에이전트에게 지속 가능한 모바일 정체성(mobile identity)을 부여하는 것입니다.

그것은 다음을 의미합니다:

실제 전화번호
실제 iMessage 계정
지속적인 앱 세션 (persistent app sessions)
로그인이 유지되는 기기
며칠에 걸친 작업 간의 연속성

이것이 중요한 이유는 많은 지저분한 자동화 작업들이 여전히 모바일 전용 앱 내부에 존재하기 때문입니다.

모든 것에 API가 있는 것은 아닙니다.

그리고 API가 존재하더라도, 종종 인간이 앱에서 수행하는 정확한 워크플로우(workflow)를 노출하지 않습니다.

최선의 아키텍처는 순수 UI 자동화가 아닌 계층화된 구조입니다

만약 당신이 이것을 구축하고 있다면, 올바른 방향은 "모든 것에 대해 전체 UI를 자동화하는 것"이 아닙니다.

그것은 계층화된 스택(layered stack)입니다:

앱에 API가 있다면 API를 사용하십시오.
사용 가능하다면 iOS Shortcuts (단축어) 또는 App Intents를 사용하십시오.
필요한 경우에만 UI 자동화로 후퇴(fall back)하십시오.

이것이 실용적인 버전입니다.

여기서 Shortcuts (단축어)는 깔끔한 통합(integration)과 지저분한 UI 제어 사이의 가교 역할을 할 수 있기 때문에 특히 흥미롭습니다.

만약 앱이 Shortcut (단축어) 액션을 노출한다면, 에이전트가 그것을 호출하게 하십시오.

만약 그렇지 않다면, 에이전트가 화면을 구동하게 하십시오.

이러한 하이브리드 모델은 모든 작업이 완전한 시각적 제어를 받을 가치가 있는 것처럼 가장하는 것보다 훨씬 더 낫습니다.

회의론자의 관점은 옳지만, 불완전합니다

명백한 반론은 이것입니다: 적절한 통합(integration)을 구축할 수 있는데 왜 굳이 폰 UI를 자동화하나요?

타당한 지적입니다.

만약 앱에 이미 안정적인 API가 있다면, API를 사용하십시오.

만약 Shortcut (단축어) 액션을 노출한다면, 그것을 사용하십시오.

단 한 번의 HTTP 요청으로 끝날 수 있는 일을 하기 위해 iPhone UI 전체를 구동하는 것은 더 느리고, 더 취약하며, 다소 황당한 일입니다.

하지만 그 스레드의 신봉자들 또한 더 중요한 무언가에 대해 옳습니다:

모바일 전용 인터페이스 뒤에는 여전히 놀라울 정도로 많은 실제 업무가 숨겨져 있습니다.

여기에는 다음이 포함됩니다:

iMessage 워크플로우 (workflows)
공개 API가 없는 소비자용 앱 (consumer apps)
현장 운영 앱 (field operations apps)
스케줄링 앱 (scheduling apps)
로컬 비즈니스 도구 (local business tools)
로그인 세션 자체가 가치 있는 자산인 앱

이것이 바로 OpenClaw 사용자들이 이에 공감한 이유입니다.

에이전트 (agents)를 구축하는 사람들은 단순히 Slack에서 질문에 답하는 봇만을 원하는 것이 아닙니다. 그들은 실제로 작동하는 시스템을 원합니다.

그리고 작동한다는 것은 투박한 인터페이스 (ugly surfaces)를 다루는 것을 의미합니다.

브라우저 (Browsers)가 하나의 투박한 인터페이스입니다.

실제 iPhone은 또 다른 인터페이스입니다.

휴대폰에서는 비용 문제가 더 악화됩니다

스레드의 작은 댓글 하나가 머릿속을 떠나지 않았습니다. 게시자는 "flash 3.5"를 사용하고 있으며 그것으로 충분히 잘 작동한다고 말했습니다.

그것이 핵심입니다.

그들은 이미 제어 계층 (control layer)을 모델 계층 (model layer)으로부터 분리하고 있습니다.

그것이 바로 여러분이 원하는 바입니다.

왜냐하면 일단 에이전트가 휴대폰을 제어하기 시작하면, 비용이 빠르게 급증할 수 있기 때문입니다.

단 한 번의 재시도 (retry)만으로도 다음 과정이 발생할 수 있습니다:

또 다른 스크린샷 캡처
또 다른 비전 패스 (vision pass) 실행
다음 행동 계획
행동 제안
승인 대기
로딩 스피너 (load spinner)나 모달 (modal) 이후 재시도

장시간 지속되는 세션에서 이를 반복하면 토큰당 과금 (per-token billing) 방식은 끔찍하게 느껴지기 시작합니다.

이것이 바로 많은 에이전트 데모들이 실제 운영 환경 (production)에서 조용히 무너지는 지점입니다. 작업 자체는 비용이 많이 들지 않습니다. 작업 주변에서 반복되는 사고 과정 (thinking)이 비용을 발생시킵니다.

토큰당 비용을 지불하고 있다면, 모든 루프 (loop)가 고통이 됩니다.

만약 n8n, Make, Zapier, OpenClaw 또는 커스텀 워크플로우 (custom workflows)에서 에이전트를 실행하고 있다면, 상황은 더욱 악화됩니다. 에이전트가 단 한 번의 깔끔한 요청만 수행하는 경우는 드물기 때문입니다. 에이전트는 재시도, 확인, 도구 호출 (tool calls), 그리고 승인 단계들을 거치며 계속 움직입니다.

이것이 바로 모델 라우팅 (model routing)이 중요한 이유입니다.

일상적인 인지 (perception)와 계획 (planning)에는 더 저렴한 모델을 사용하십시오.

작업이 모호하거나, 이해관계가 높거나, 승인이 필요한 경우에만 더 강력한 모델로 격상(escalate)시키십시오.

그리고 워크로드 (workload)가 지속적이라면, 사용량 기반의 토큰 과금보다는 정액제 컴퓨팅 (flat-rate compute) 방식이 훨씬 더 매력적일 것입니다.

그것이 바로 제가 Standard Compute와 같은 제품들이 여기서 유의미하다고 생각하는 실질적인 이유입니다. 만약 여러분이 장시간 실행되는 에이전트, 특히 모바일 UI 상태를 루프(loop)하며 탐색하는 에이전트를 구축하고 있다면, 에이전트가 로딩 스피너(loading spinner)를 바라볼 때마다 토큰 지출을 지켜보는 것보다 예측 가능한 월간 가격으로 무제한 컴퓨팅 (unlimited compute)을 제공하는 것이 훨씬 더 합리적인 선택일 것입니다.

폰 에이전트를 위한 실질적인 라우팅 패턴

제가 사용한다면 다음과 같은 분할 방식을 사용할 것입니다:

작업 유형	모델 전략
기본적인 화면 이해	저렴하고 빠른 모델
...

의사 코드 (Pseudo-code) 버전:

type Action = "tap" | "scroll" | "type" | "send" | "book" | "buy";

function pickModel(task: {
...

요점은 간단합니다. 모든 탭 (tap) 동작에 프리미엄 모델 비용을 지불하지 마십시오.

만약 제가 이것을 만든다면, 가드레일 (guardrails)부터 시작할 것입니다

무서운 점은 에이전트가 버튼을 누를 수 있느냐 없느냐가 아닙니다.

무서운 점은 실제 iPhone이 실제 행동을 수행할 수 있다는 것입니다.

브라우저 에이전트가 잘못된 양식을 제출하는 것은 짜증스러운 일입니다.

하지만 iPhone 에이전트가 잘못된 iMessage를 보내거나, 잘못된 예약을 확정하거나, 잘못된 결제 흐름을 건드리는 것은 차원이 다른 실수입니다.

따라서 여러분이 이 분야에 진지하게 임하고 있다면, 최소 기능 가드레일 (minimum viable guardrails)은 다음과 같은 모습이어야 한다고 생각합니다:

전송/예약/구매 (send/book/buy) 동작 전 승인 단계
전체 스크린샷 및 작업 로그
지속적인 세션 ID (persistent session IDs)
재현 가능한 작업 추적 (replayable task traces)
앱 및 연락처에 대한 명시적인 허용 목록 (allowlists)
신뢰도가 떨어질 경우 인간에게 인계 (human handoff) 하는 폴백 (fallback) 메커니즘

예를 들면 다음과 같습니다:

const session = await phones.createSession({
  device: "iphone",
  region: "us",
...

이것이 이 아이디어의 성숙한 버전입니다.

"내 봇이 이제 내 폰을 가지고 있다"가 아니라,

"에이전트가 감사 가능성 (auditability)을 갖춘 통제된 모바일 세션 내에서 작동할 수 있다"에 가깝습니다.

직접 구축할 것인가, 디바이스 클라우드 (device cloud)를 사용할 것인가, 아니면 에이전트 네이티브 레이어 (agent-native layer)를 사용할 것인가?

이 시장은 현재 세 가지 경로로 나뉘고 있습니다.

옵션	실제로 얻게 되는 것
실제 iPhone에서 DIY Appium 사용	최대의 유연성, 최대의 운영상 고통
...

이것들은 서로 같은 것이 아닙니다.

BrowserStack은 주요 업무가 앱 테스트인 경우에 훌륭합니다.

Browseblue 스타일의 시스템은 에이전트에게 지속 가능한 모바일 정체성 (mobile identity)을 부여하는 것이 업무라면 더 흥미롭습니다.

완전한 제어가 필요하고 그 혼란을 감수할 의향이 있다면 DIY 방식도 여전히 유효합니다.

실험을 원한다면, 처음에는 지루하게 유지하세요

만약 제가 다음 주에 이것을 프로토타이핑한다면, 자율적인 문자 메시지 전송이나 위험도가 높은 흐름 (flows)으로 시작하지 않을 것입니다.

저는 여기서부터 시작하겠습니다:

1. 하나의 좁은 워크플로우 (workflow)를 선택하세요

좋은 예시:

앱을 열고 상태 화면 읽기
iMessage 초안을 작성하되 전송은 하지 않기
단축어 (Shortcut)를 실행하고 결과 확인하기
QA 흐름을 탐색하고 스크린샷 캡처하기

2. 초기에 승인 (approvals) 단계를 추가하세요

안전 장치를 나중에 덧붙이려고 기다리지 마세요.

첫날부터 "전송", "예약", "구매"를 승인 게이트 (approval-gated)로 만드세요.

3. 오케스트레이션 (orchestration)과 추론 (inference)을 분리하세요

에이전트 루프 (agent loop)는 모델 호출을 전체 아키텍처가 아닌 하나의 구성 요소로 취급해야 합니다.

4. 모든 것을 로그로 남기세요

최소한 다음과 같이:

session_id=iphone-123
timestamp=2026-05-27T10:15:00Z
action=tap
...

5. 비용 프로필을 즉시 확인하세요

이 부분은 사람들이 예상하는 것보다 더 중요합니다.

워크플로우가 많이 반복된다면, 토큰 기반 과금 방식은 "딱 한 번만 더 재시도"하는 것이 얼마나 비싸지는지를 정확히 보여줄 것입니다.

이것이 헤비한 자동화를 실행하는 팀들이 종종 종량제 지출 대신 고정된 월간 청구 방식을 원하는 이유입니다.

해당 스레드에서 얻은 저의 실제 결론

저는 헤드라인의 핵심 아이디어가 "이제 에이전트가 휴대폰을 사용할 수 있다"라고 생각하지 않습니다.

그것은 너무 당연합니다.

진정한 아이디어는 에이전트가 인간이 실제로 일하는 장소에서 지속적인 정체성 (persistent identities)을 필요로 하기 시작했다는 점입니다.

단순히 API 키뿐만이 아닙니다.

단순히 브라우저 세션뿐만이 아닙니다.

실제 전화번호. 실제 앱 로그인. 실제 저장된 상태. 실제 승인 이력. 며칠에 걸친 실제 연속성.

그것이 바로 이 스레드를 흥미롭게 만드는 지점입니다.

스택은 임시방편적(hacky)입니다. UI 자동화(UI automation)가 취약하다는 회의론자들의 말은 맞습니다. 네이티브 통합(Native integrations)이 가능하다면 그것이 더 깔끔합니다.

모두 사실입니다.

하지만 저는 이것이 여전히 무언가 실질적인 것을 가리키고 있다고 생각합니다.

다음 세대의 유용한 에이전트(agents)는 단순히 Slack이나 Discord에서 답변만 하지 않을 것입니다.

그들은 다음과 같은 일을 수행할 것입니다:

iPhone 전용 앱을 실행하고
세션(session)을 유지하며
iMessage 초안을 작성하고
승인을 기다린 뒤
올바른 번호로 메시지를 전송하고
다음 날에도 여전히 로그인된 상태로 돌아오는 것

엉망인가요? 전적으로 그렇습니다.

하지만 모든 중요한 인터페이스 계층(interface layer)도 그것이 일상이 되기 전에는 그러했습니다.

그리고 만약 미래가 제가 생각하는 방식대로 나타난다면, 승자는 단순히 더 나은 에이전트 루프(agent loops)를 가진 곳이 아닐 것입니다.

그들은 더 나은 비용 제어(cost control) 능력도 갖추게 될 것입니다.

왜냐하면 일단 에이전트가 채팅(chat)에서 운영(operation) 단계로, 특히 모바일 환경으로 넘어가게 되면, 예측 가능한 컴퓨팅(predictable compute)은 단순히 있으면 좋은 기능(nice-to-have)이 아니라 아키텍처(architecture)의 일부가 되기 때문입니다.