AI 에이전트, 휴대폰과 서버에서 무엇이 달라질까
작성 Clifford · 제품 리서치
Memex 팀이 작성했습니다. 플랫폼 공식 자료와 Memex 소스를 2026년 10월 17일에 확인했습니다. 아키텍처를 다루는 글이며 배터리, 속도, 백그라운드 실행의 신뢰성을 비교 측정한 결과가 아닙니다. 제안하는 혼합 설계는 Memex에서 출시한 기능이 아닙니다.
산책을 마치고 음성 메모를 남깁니다. “봄에 교토에 가도 좋겠네. 하지만 또 일정이 꽉 찬 여행은 싫어.” 지금은 이 생각을 남기고, 예전 메모와 연결할 수 있으면 충분합니다. 날짜와 여행 방안을 에이전트에게 조사해 달라고 할 때는 몇 달 뒤일 수도 있습니다. 기록은 작업이 생기기 전부터 쓸모가 있습니다.
두 대화는 같은 채팅창에서 이루어질 수 있습니다. 하나는 지금 살아가는 순간 곁에 있고, 다른 하나는 휴대폰을 내려놓은 뒤에도 이어져야 할 수 있습니다. 에이전트의 실행 위치는 그동안 할 수 있는 일과, 작업이 멈췄을 때 앱이 알려 줘야 할 내용을 바꿉니다.
세 가지 위치는 별개의 결정이다
에이전트의 제어 프로그램은 입력을 읽고, 모델에 묻고, 도구를 호출한 뒤 결과를 저장합니다. 이 프로그램은 휴대폰 앱에서 실행하면서 모델 추론은 API 제공업체에 요청할 수 있습니다. 기록 저장소의 위치는 또 다른 문제입니다. 일기가 휴대폰에 있다는 사실만으로 추론 위치를 알 수는 없습니다. 도구 동작의 실행 경계도 따로 있습니다. 휴대폰의 제어 프로그램은 로컬 파일을 수정하거나 원격 캘린더 API를 호출할 수 있습니다.
“로컬 모델”도 어느 기기에서 로컬인지 밝혀야 합니다. 노트북의 Ollama 서버가 선택한 모델을 실제로 로컬에서 실행한다면 추론은 노트북에서 이루어집니다. 휴대폰이 그 엔드포인트에 연결한다는 사실만으로 휴대폰 내부 추론이나 클라우드 전달의 부재를 입증할 수는 없습니다. 아래 비교는 제어 프로그램과 도구의 실행 위치에 관한 것입니다. 저장, 제어, 추론의 세 계층이 함께 옮겨 간다고 가정하지 않습니다.
| 설계 결정 | 휴대폰의 제어 프로그램 | 서버의 제어 프로그램 |
|---|---|---|
| 에이전트 반복문 | 앱 실행 환경 안에서 동작합니다. | 원격 워커나 서비스에서 동작합니다. |
| 기록 | 앱의 로컬 기록을 사용할 수 있습니다. | 관련 기록의 허가된 접근이나 전달받은 사본이 필요합니다. |
| 모델 추론 | 기기 내 모델 또는 원격 엔드포인트를 사용합니다. | 호스트의 모델 또는 별도 엔드포인트를 사용합니다. |
| 휴대폰 앱을 닫은 뒤 | OS 실행 시간과 복구 장치에 달려 있습니다. | 호스트와 작업 시스템이 가동 중이면 독립적으로 이어 갈 수 있습니다. |
| 도구와 권한 | 앱 권한과 운영체제의 제약을 받습니다. | 호스트 도구, 인증 정보와 명시적인 기기 연결의 제약을 받습니다. |
백그라운드 실행에는 플랫폼의 조건이 있다
iOS 앱은 임의의 반복문을 상시 서비스로 만들 수 없습니다. 시스템이 백그라운드 실행 시간을 관리합니다. iOS와 iPadOS 26의 BGContinuedProcessingTask는 사용자가 명시적으로 시작한 작업을 진행 표시, 취소, 만료 처리와 함께 이어 가는 수단입니다. 앱을 떠난 뒤 마칠 수 있는 작업은 늘어나지만, 무인 작업을 아무 때나 시작할 권한을 주지는 않습니다.
Android는 일반 비동기 작업, 지속성 작업, 포그라운드 서비스를 구분합니다. WorkManager는 지속성 작업을 위한 것이며, 포그라운드 서비스에는 사용자에게 보이는 방식과 시작 조건에 제약이 있습니다. 일부 서비스 유형에는 시스템 및 타깃 버전에 따라 시간 제한도 적용됩니다. 함수를 async로 만드는 것만으로 이런 실행 권한을 얻을 수는 없습니다.
서버에서는 제어 프로그램이 휴대폰 앱의 생명주기에서 독립할 수 있습니다. 그래도 실행 중인 호스트, 스케줄러나 큐, 유효한 인증 정보, 장애 처리와 모니터링이 필요합니다. 관리형 클라우드 서비스와 집에서 계속 켜 두는 컴퓨터 모두 이 역할을 맡을 수 있지만, 운영 책임은 다릅니다.
Apple: 백그라운드 실행과 계속 처리 · Android: 백그라운드 작업 · Android: 서비스 시간 제한
작업 저장과 동작 재개는 다르다
도구가 캘린더 일정을 만들었다고 가정해 보겠습니다. 생성은 성공했지만 에이전트가 성공을 기록하기 전에 응답이 사라졌습니다. 다시 시도하면 같은 일정이 하나 더 생길 수 있습니다. 제어 프로그램을 서버로 옮겨도 이 불확실성은 남습니다.
안정적인 복구에는 지속성 있는 작업 상태와, 그 상태 밖에서 실제로 일어나는 동작에 대한 대응이 모두 필요합니다. API가 지원한다면 같은 동작 식별자로 재시도임을 알릴 수 있습니다. 그렇지 않다면 실제로 무엇이 일어났는지 확인하고 다음 동작을 결정해야 할 수 있습니다. AWS의 멱등 API 설명은 호출자가 제공하는 요청 식별자가 왜 중요한지 보여 줍니다.
큐가 미완료 작업을 기억하더라도 처리 함수는 처음부터 다시 실행될 수 있습니다. 각각의 모델 호출이나 도구 단계부터 재개하려면 추가 상태와 도구별 보장이 필요합니다. “중단 후 복구된다”가 어느새 “모든 동작이 정확히 한 번만 실행된다”는 뜻이 되어서는 안 됩니다.
차이는 화면에서도 드러난다
짧은 회고라면 휴대폰의 제어 프로그램이 선택한 로컬 기록을 읽고, 생각이 생생할 때 후속 질문을 할 수 있습니다. 다른 모든 앱을 자동으로 들여다볼 수 있는 것은 아닙니다. 접근은 권한과 사용 가능한 인터페이스에 제한됩니다. 최신 메모가 동기화되지 않았다면 서버 에이전트가 같은 맥락을 받기 위한 명확한 경로가 필요합니다. 서버에 브라우저와 명령줄 도구를 갖추어도 그것만으로 휴대폰에만 있는 정보에 접근할 권한이 생기지는 않습니다.
나중에 여행 방안을 조사할 때 원격 실행은 “끝날 때쯤 돌아오기”를 지원할 수 있습니다. 결과는 휴대폰의 재접속을 기다릴 수 있습니다. 그래도 앱은 조사 중, 연결 대기, 일시 정지, 실패, 사용자 답변 대기 같은 의미 있는 상태를 보여 줘야 합니다. 실행은 멈췄는데 계속 돌아가는 로딩 표시는 작업에 관한 가장 중요한 사실을 숨깁니다.
로컬에서 제어한다고 답변이 더 빠른 것은 아닙니다. 두 설계가 같은 원격 모델을 호출하면 추론과 통신이 대기 시간의 대부분일 수 있습니다. 기기 내 추론은 계산을 휴대폰으로 옮기는 대신 그 기기의 메모리, 에너지와 발열 제약을 받습니다. 오프라인 기록 저장과 원격 모델이 필요한 흐름까지 오프라인에서 마치는 것도 서로 다른 기능입니다.
개인정보 보호와 비용은 작업 경로를 따라간다
휴대폰에서 관련 문단 몇 개를 선택하면 기록 전체를 실행 서버에 먼저 복제하지 않아도 될 수 있습니다. 그래도 선택한 문장은 모델 요청에 담겨 기기 밖으로 나갈 수 있습니다. 서버도 권한 범위와 보관 기간을 제한할 수 있습니다. 어느 쪽이든 기록, 프롬프트, 도구 출력, 로그와 백업의 이동 경로를 살펴봐야 합니다. 반복문이 도는 기기만으로 판단할 수는 없습니다.
모델 선택도 별개의 결정입니다. 엔드포인트 선택은 처리 경계를 선택하는 것이지, 모든 제공업체가 비공개 처리나 오프라인 동작을 보장한다는 뜻은 아닙니다. 워커를 호스팅하면 컴퓨팅과 유지보수 비용이 추가될 수 있습니다. 휴대폰 실행은 기기 자원을 쓰며 API 요금도 발생할 수 있습니다. 작업과 측정이 정해지지 않았다면 언제나 더 저렴하거나 효율적인 쪽을 고를 수 없습니다.
Memex 소스에서 확인할 수 있는 범위
이번에 확인한 리비전의 Memex에는 작업 상태, 실행 소유권, 오래된 실행 상태 복구와 설정 가능한 재시도를 갖춘 영속 로컬 작업 큐가 있습니다. 백그라운드 조정 프로그램은 작업 활동과 앱 생명주기를 연결합니다. Android에는 WorkManager로 큐를 처리하는 경로가 있고, iOS 브리지에는 처리 작업과 진행 및 만료 처리를 갖춘 iOS 26 계속 처리 경로가 있습니다.
백그라운드 워커는 일시 정지 상태를 기록하고 다음 시도를 마련할 수도 있습니다. 이는 중단을 관리하는 장치입니다. 무중단 실행, 모든 내부 단계에서의 정확한 재개, 외부 동작의 중복 완전 방지를 입증하지는 않습니다. 소스 검토는 설치된 기기에서의 시험이 아니며, 특정 출시 빌드의 지원 여부는 따로 확인해야 합니다.
오픈 소스이므로 이런 경계를 살펴보고 수정할 여지가 있습니다. Memex의 출발점은 개인 기록과 그 가까이서 동작하는 설정 가능한 워크플로입니다. 가끔 생기는 개인적인 일을 전부 상시 실행 서버 작업으로 만들 필요는 없습니다.
Memex 작업 큐와 복구 · Android 큐 스케줄링 · iOS 백그라운드 브리지 · 백그라운드 워커와 일시 정지
미래의 혼합 설계: 작업을 넘기고 이력을 남긴다
앞으로는 원본 기록을 휴대폰에 두고 범위가 정해진 조사를 다른 호스트에 넘기는 설계를 생각할 수 있습니다. 여행 요청이라면 선택한 날짜, 예산과 관련 취향을 보냅니다. 서버는 모든 일기를 영구히 보유하는 대신 출처가 있는 후보 목록을 반환합니다.
인계에는 작업 식별자, 입력 스냅샷, 허용 도구, 지출 한도와 다음 단계를 책임질 주체가 필요합니다. 조사 중에 “조용한 여행”을 “친구들과 가는 여행”으로 바꾸면 어떻게 될까요? 돌아온 목록은 이전 선호를 사용했다고 밝히고 수정 여부를 물어야 합니다. 새 계획을 조용히 덮어써서는 안 됩니다.
취소할 때도 추가 조사를 멈추는 것과 이미 실행한 동작을 되돌리는 것을 구분해야 합니다. 초안은 검토할 수 있지만, 실제 예약에는 별도의 승인 경계와 중복 요청을 식별할 방법이 필요합니다. 이는 설계 제안이며 Memex에서 출시한 휴대폰·서버 작업 위임 기능이 아닙니다. 기기 내 모델이 좋아져도 OS 생명주기 규칙은 사라지지 않고, 서버 연산량이 늘어도 빠진 개인 맥락이 저절로 채워지지는 않습니다.
먼저 무엇을 남기고 싶은지 생각한다
긴 작업이 뒤따르지 않아도 음성 메모는 저장할 가치가 있어야 합니다. 일상의 많은 순간에 유용한 것은 기록, 짧은 대화, 나중에 다시 볼 수 있는 내용입니다. 이 경로를 휴대폰 가까이에 두는 것은 자료가 들어오는 방식에도 맞습니다.
산책 몇 달 뒤 여행 조사의 출발점은 이미 그곳에 있습니다. 당시 무엇을 원했는지 자신의 말로, 날짜와 이후 수정 내용까지 남아 있습니다. 더 오래 실행되는 워커가 가끔 필요한 조사를 맡을 수 있습니다. 매일의 기록이 그 작업의 근거가 됩니다.