에이전트가 루프를 돌며 도구를 호출하고, 결과를 확인하고, 다시 호출할 때 — 외부 HTTP 엔드포인트로의 모든 왕복(round-trip)은 지연 시간(latency), 인증 설정, 에러 처리, 그리고 네트워크 불확실성을 추가합니다. 루프 내에서 이를 열 번 반복하면 비용은 복리로 증가합니다. 긴밀한 루프를 실행해야 하는 에이전트에게는 도구 자체의 아키텍처가 그 뒤에 있는 모델만큼이나 중요합니다.

여기서 로컬 우선 (local-first) AI 에이전트 도구가 등장합니다. 이는 에이전트 자신의 머신에서 로컬 프로세스로 실행되며, HTTP 대신 IPC(Inter-Process Communication)를 통해 통신하고, 무거운 작업은 다른 곳에서 수행하는 도구입니다. 이는 기존의 REST 도구 패턴과는 다른 형태이며, 에이전트 루프의 판도를 바꿉니다.

REST의 저항 (The REST drag)

오늘날 전형적인 에이전트 설정에서의 도구 호출은 다음과 같이 작동합니다:

1. 에이전트가 데이터가 필요하다고 결정 → JSON 페이로드(payload)를 구성함
2. 이를 HTTP를 통해 원격 엔드포인트로 전송함
3. 원격 서버가 인증, 처리, 응답함
4. 에이전트가 응답을 파싱하고 필요한 내용을 추출함
5. 루프를 계속하며 — 이 과정을 다시 반복함

각 단계는 실패 모드(failure modes)를 유발합니다: DNS resolution, TLS handshake, connection pooling, rate limiting, 토큰 만료, 네트워크 분할(network partitions). 이 중 어느 것도 에이전트의 문제는 아닙니다. 이는 에이전트가 매 호출마다 견뎌야 하는 인프라 오버헤드(infrastructure overhead)입니다.

1020회 반복되는 루프에서 이러한 오버헤드는 배가 됩니다. 200ms의 REST 호출은 에이전트가 모델에 닿기도 전에 누적 지연 시간이 24초가 됩니다. 그리고 이것은 재시도(retries), 타임아웃(timeouts), 429(Too Many Requests) 에러가 없는 '해피 패스(happy path)'일 때의 이야기입니다.

로컬 우선 AI 에이전트 도구: 얇은 어댑터 형태 (the thin-adapter shape)

대안적인 패턴이 등장하고 있습니다: 에이전트 머신에 가벼운 어댑터(adapter) 프로세스를 로컬에서 실행하고, 무거운 백엔드 로직은 다른 곳에 두는 것입니다. 로컬 어댑터는 JSON 입력을 받아 JSON 출력을 내보냅니다. 호출마다 HTTP 스택, DNS, TLS가 필요하지 않습니다. 그저 로컬 소켓(socket)이나 파이프(pipe)만 있으면 됩니다.

agent → [JSON] → local adapter → [작업 수행, 필요 시 원격 호출] → [JSON] → agent

에이전트가 메시지를 보내면, 어댑터(adapter)가 이를 동기적(또는 콜백을 통한 비동기적)으로 처리하며, 결과는 동일한 형식으로 도착합니다. 부트스트랩(bootstrap)해야 할 HTTP 스택도 없고, 예열(warm)해야 할 커넥션 풀(connection pool)도 없습니다. 원격 백엔드(remote backend)가 존재하더라도 어댑터 뒤로 추상화되어 있으며, 에이전트는 이를 직접 다루지 않습니다.

이는 Pilot Protocol 앱 스토어가 작동하는 방식과 대략적으로 유사합니다. 설치된 각 앱은 데몬(daemon) 위에서 감독되는 로컬 프로세스(local process)로 실행되며, JSON-in/JSON-out 인터페이스로 타입(type)이 지정됩니다. 에이전트는 <app>.<method> '{...}'를 호출할 뿐이며, curl, fetch, 또는 URL 생성 과정이 필요 없습니다. 앱은 내부적으로 원격 백엔드와 통신할 수 있지만, 에이전트는 호출 자체를 위해 네트워크 스택(network stack)을 건드리지 않습니다.

루프 내에서 로컬 우선 (Local-First) AI 에이전트 도구가 중요한 이유

에이전트가 반복(iterate)할 때 그 차이는 복리로 커집니다. 구조화된 데이터를 가져와서 변환한 뒤 다시 루프로 전달하는 도구를 가정해 봅시다.

REST 방식 — 매 반복마다: 연결, TLS, 인증 헤더(auth header), 전송, 대기, 파싱(parse), 오류 확인 과정을 거칩니다. 도구 자체는 상태가 없으며(stateless), 에이전트의 관점에서는 매 호출이 차가운 상태(cold)에서 시작됩니다.

로컬 어댑터 (Local-adapter) 방식 — 어댑터 프로세스가 호출 사이에도 계속 살아 있습니다. 인증(Auth)은 시작 시 한 번만 협상됩니다. 백엔드로의 연결은 어댑터 내부에서 풀링(pooled)됩니다. 에이전트는 JSON 한 줄을 보내고 다시 한 줄을 받습니다. 루프는 전송(transport)이 아닌 추론(reasoning)에 시간을 할애합니다.

에이전트가 작업당 5~15회 도구를 호출하는 워크플로(검색, 쿼리, 검색(retrieve), 분석, 작성 등)의 경우, 이러한 절감 효과는 미미한 수준이 아니라, 반응성이 좋은 툴체인(toolchain)과 느릿하게 느껴지는 툴체인을 가르는 결정적인 차이가 됩니다.

지연 시간(Latency)을 넘어: 서명(Signatures)과 권한(Permissions)

운영 환경(production)에서 중요한 또 다른 장점이 있습니다. 로컬 어댑터는 API 키 수준이 아닌 프로세스 수준에서 권한(permissions)을 강제할 수 있다는 점입니다.

모든 도구가 REST 호출일 때, 에이전트는 일반적으로 해당 엔드포인트(endpoint)가 제공하는 모든 것에 접근할 수 있는 베어러 토큰(bearer token)을 보유하게 됩니다. 이 토큰이 유출되면 전체 공격 표면(surface)이 노출됩니다.

도구가 로컬 프로세스 (local process)로 실행될 때, 권한은 설치 시점에 범위가 지정(scoped)됩니다. 어댑터 (adapter)는 에이전트가 명시적으로 수락한 메서드만을 공개합니다. 에이전트는 백엔드 자격 증명 (backend credentials)을 절대 보유하지 않으며, 어댑터가 이를 보유합니다. 에이전트가 해킹되더라도 권한을 부여받지 않은 도구는 호출할 수 없습니다.

Pilot의 앱 스토어는 권한 부여 범위 (grant-scoped permissions)를 통해 이를 구현합니다. 각 매니페스트 (manifest)는 SHA256 해시와 Ed25519 서명을 고정하며, 매 실행 (spawn) 시마다 재검증됩니다. 에이전트는 설치 시점에 권한 세트를 수락하며, 그 세트가 에이전트가 가질 수 있는 전부입니다. 즉, 주변 권한 (ambient authority)은 존재하지 않습니다.

포기해야 하는 것

로컬 우선 (Local-first) 도구 어댑터가 공짜는 아닙니다. 에이전트의 머신에 데몬 (daemon) 또는 감독 프로세스 (supervisor process)가 필요하며, 이는 관리해야 할 상태 (state)이자 모니터링해야 할 대상입니다. 또한 에이전트를 특정 런타임 환경 (runtime environment)에 종속시킵니다. 반면 REST 도구는 어디에서나 호출될 수 있습니다.

하지만 에이전트가 이미 통제된 환경 (컨테이너, VM, 노트북 등)에서 실행되고 있다면, 루프 내에서 반복적으로 호출하는 도구의 경우 로컬 어댑터가 엄격하게 더 낫습니다.

실질적인 시사점

현재 에이전트 루프 (agent loops)를 구축하고 있는데 도구 호출이 무겁게 느껴진다면, 전송 계층 (transport layer)을 살펴보십시오. 에이전트가 수행하는 각각의 HTTP 왕복 (round-trip)은 추론 (reasoning)에 쓸 수 있는 시간입니다. 데몬에서 JSON 입력과 JSON 출력을 처리하는 가벼운 로컬 어댑터는 가장 중요한 지점인 루프 내부의 마찰을 제거합니다.

Pilot Protocol의 app-store apps (런타임 보안을 위한 AEGIS, 근거 기반 검색을 위한 cosift, 페이지 추출을 위한 plainweb)와 같은 도구들은 정확히 이러한 형태를 제공합니다. 도구를 발견하고, 설치하고, 로컬 IPC 서비스로 호출하십시오. 이 패턴은 오버레이 네트워크 (overlay network) 없이도 채택할 수 있을 만큼 범용적입니다. 가벼운 어댑터를 실행하고, 무거운 백엔드는 다른 곳에 두며, 에이전트가 가장 잘하는 일에 집중하게 만드십시오.

에이전트 루프는 소프트웨어의 새로운 핫 패스 (hot path)입니다. 도구가 병목 현상 (bottleneck)이 되지 않도록 하십시오.