채용 공고, 도구의 README, 혹은 여러분이 지켜보는 동안 에이전트가 양식을 작성하는 데모 등에서 "파일럿 에이전트 (pilot agent)"라는 용어를 계속 접하게 될 것입니다. 이 용어는 중요해 보이면서도 동시에 막연하게 당연하게 들리기도 합니다. 이것이 새로운 종류의 에이전트일까요, 마케팅적인 재브랜딩일까요, 아니면 이미 이름을 붙이지 않았을 뿐 여러분이 이미 구축하고 있는 무언가일까요?

대부분은 마지막 경우에 해당합니다. 파일럿 에이전트 (pilot agent)란 파일럿이 항공기를 조종하는 방식처럼, 브라우저, 데스크톱, API 인터페이스, 혹은 전체 워크플로우 (workflow)와 같은 다른 무언가를 조종하는 것이 임무인 AI 에이전트 (AI agent)를 말합니다. 제어 장치에 손을 얹고 목적지에 도달할 것으로 기대되는 상태 말이죠. 이 용어가 유행하는 이유는 실제 에이전트 시스템에서 계속해서 나타나는 분업 구조를 명명하고 있으며, 그 분업이 구체적인 엔지니어링 결과(engineering consequences)를 초래하기 때문입니다.

파일럿 에이전트 (Pilot Agent)란 무엇인가?

파일럿 에이전트 (pilot agent)는 사용자를 대신하여 다른 시스템을 작동시키는 에이전트입니다. 일반적인 에이전트가 자신의 런타임 (runtime) 내부에서 질문에 답하거나 코드를 작성하는 것과 달리, 파일럿 에이전트는 외부의 무언가 속으로 직접 들어가 인간 운영자처럼 작동합니다. 즉, 현재 상태를 확인하고, 다음에 할 일을 결정하며, 시스템 자체의 인터페이스를 통해 동작을 수행한 다음, 그 결과를 확인합니다.

실제로는 세 가지 유형이 주를 이룹니다:

• 브라우저 파일럿 에이전트 (Browser pilot agents). 이들은 실제 브라우저를 조종합니다. API가 없는 작업들, 즉 예약, 조사, 양식 작성, 자신의 세션 스크래핑 (scraping) 등을 수행하기 위해 클릭, 타이핑, 탐색, DOM 읽기 등을 수행합니다.
• 컴퓨터 사용 에이전트 (Computer-use agents). 이들은 운영체제 (OS) 전체를 조종합니다. 보통 VM(가상 머신)이나 샌드박스 (sandbox) 내부에서 사람이 해당 기기에서 할 수 있는 모든 일을 위해 스크린샷, 마우스, 키보드를 사용합니다.
• 워크플로우 파일럿 에이전트 (Workflow pilot agents). 이들은 화면을 전혀 건드리지 않습니다. 이들은 API 호출, 데이터 이동, 다음 단계 결정 등 도구와 서비스의 체인을 조종하며, 파이프라인 (pipeline)이 완료되었는지에 따라 평가받습니다.

공통점은 다음과 같습니다: 에이전트가 자신이 소유하지 않은 무언가의 "운전석"에 앉아 있다는 것입니다. 이것이 정의의 전부입니다.

파일럿 (Pilot) vs 코파일럿 (Copilot): 누가 운전하고 있는가?

유용한 대조군은 코파일럿 (Copilot)입니다. 코파일럿은 루프 안에 머무르는 (stays in the loop) 인간을 보조합니다. 즉, 코파일럿은 제안하고, 완성하고, 초안을 작성하며, 최종적인 실행 버튼은 인간이 누릅니다. 반면 파일럿 에이전트 (Pilot Agent)는 제한된 자율성 (bounded autonomy)을 가진 채 운전대를 넘겨받습니다. 당신이 목표, 예산, 그리고 가드레일 (guardrails)을 설정해주면, 에이전트는 작업이 완료되거나 다시 돌아와 질문해야 할 때까지 스스로 작동합니다.

이러한 차이는 명칭보다 더 중요합니다. 에이전트를 코파일럿에서 파일럿으로 격상시킬 때, 당신은 그 주변에 구축해야 하는 것들을 바꾸게 됩니다:

• 이제 **권한 범위 지정 (permission scoping)**이 필요합니다. 에이전트가 스스로 행동하므로, 에이전트가 접할 수 있는 모든 기능은 주변 권한 (ambient access)이 아닌 명시적인 허가가 필요합니다.
• **검증 (verification)**이 필요합니다. 파일럿 에이전트는 자신의 행동이 성공했는지 판단할 수 있어야 합니다. 그렇지 않으면 똑같은 벽을 향해 영원히 달려갈 것입니다.
• **도달 범위 (reach)**가 필요합니다. 그리고 이것은 대부분의 사람들이 가장 마지막에 깨닫게 되는 부분입니다.

파일럿 에이전트의 구조 (The Anatomy of a Pilot Agent)

무엇을 조종하든, 루프는 대략 다음과 같이 동일합니다:

1. 인지 (Perceive) — 현재 상태(DOM, 스크린샷, API 응답, 파일 트리)를 읽습니다.
2. 계획 (Plan) — 목표를 향한 다음 행동을 선택합니다.
3. 실행 (Act) — 시스템 인터페이스(클릭, 키 입력, HTTP 호출, CLI)를 통해 실행합니다.
4. 검증 (Verify) — 행동이 제대로 수행되었는지 확인합니다. 그렇지 않다면 복구하고 재시도합니다.

엔지니어링의 무게 중심은 1단계와 4단계에 있습니다. 인지는 반드시 '그라운딩 (grounded)' 되어야 합니다. 즉, 에이전트는 오래된 스냅샷이 아니라 구조화된 현재 상태를 필요로 합니다. 검증에는 저렴한 피드백이 필요합니다. 존재하는 셀렉터 (selector), 상태 코드 (status code), 혹은 차이점 (diff) 같은 것들 말입니다. 그 외의 모든 것은 배관 작업 (plumbing)에 불과합니다.

모든 파일럿 에이전트가 결국 필요하게 되는 또 다른 요소는 **런타임에 설치할 수 있는 툴체인 (toolchain)**입니다. 인간이 설정을 수정하지 않고서는 검색 기능을 추가할 수 없는 브라우저 파일럿은 자율적인 것이 아니라, 그저 원격 제어되는 커서 (remote-controlled cursor)일 뿐입니다.

파일럿 에이전트가 실패하는 지점: 도달 범위 문제 (The Reach Problem)

모든 심각한 배포에서 나타나는 실패 모드가 있습니다. 바로 파일럿 에이전트가 한 기기에서 브라우저를 구동하고, 그 파일럿 에이전트가 위임하는 워커(worker) — 모델 서버, 데이터 파이프라인, 두 번째 에이전트 등 — 가 NAT 뒤, 기업 방화벽 뒤, 또는 무언가가 재시작될 때마다 IP 주소를 재할당하는 클라우드에 있는 경우입니다.

웹훅(Webhooks)은 유지되지 않습니다 (수신자가 도달 가능해야 합니다). 공개 URL은 만료됩니다 (IP가 변경됩니다). VPN은 과도하게 신뢰합니다 (그 안에 있는 모든 것이 모든 것을 볼 수 있습니다). 그리고 이 모든 것은 자율적인 시스템에 붙인 인간의 인프라 답변입니다.

이 지점에서 '파일럿'이라는 은유는 귀엽다는 것에서 벗어나 문자 그대로가 됩니다. 비행기는 전방 주소(forwarding address)가 만료되는 타워를 부르지 않습니다. 항공기는 어디에 있든 작동하는 호출 부호(call sign)를 가지고 있으며, 관제탑은 그 이름을 통해 그것을 찾습니다. 에이전트 역시 동일한 속성 — 재시작, IP 변경, 클라우드 이동에도 살아남는 안정적인 식별자와 도달 가능성 — 을 필요로 합니다. 그래야 파일럿 에이전트가 기기 간에 위임할 수 있기 때문입니다.

파일럿 에이전트에게 네트워크가 필요한 경우

바로 이 점을 위해 구축된 네트워크 계층이 등장합니다. Pilot Protocol은 AI 에이전트에게 영구적인 가상 주소, 암호화 터널(X25519 키 교환, AES-GCM), 그리고 STUN 기반의 홀 펀칭과 릴레이 폴백을 통한 NAT 트래버설을 제공하는 오픈 소스 오버레이 네트워크입니다. 따라서 어떤 NAT 뒤에 있는 에이전트라도 이름으로 도달할 수 있습니다. 신뢰는 피어(peer)별이며 명시적입니다: 에이전트는

curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl handshake worker-node-42 "pilot agent requesting trusted peer"
pilotctl send-message worker-node-42 --data '/data {"job":"summarize"}'

포트 포워딩(port forwarding), 고정 IP(static IP), 웹훅 수신기(webhook receiver)가 필요 없습니다. 파일럿 에이전트(pilot agent)는 자신의 호출 부호(call sign)를 유지하며, 피어(peer)는 그 아래에서 계속해서 변화하는 머신들을 유지하지만 아무도 이를 알아차리지 못합니다.

파일럿 에이전트는 스스로 도구를 설치합니다

자율성의 두 번째 절반은 툴체인(toolchain)이며, 바로 이 지점에서 파일럿 에이전트(pilot-agent) 패턴이 흥미로워집니다. 오버레이 네트워크(overlay network)가 에이전트에게 '도달 범위(reach)'를 제공한다면, **앱 스토어(app store)**는 에이전트에게 '역량(capabilities)'을 제공합니다. 이는 에이전트 자체의 데몬(daemon)에서 로컬로 실행되는 설치 가능한 앱들로, 입력된 IPC 서비스(JSON in, JSON out)로서 설치 시 자동으로 생성됩니다. 루프는 '탐색(discover) → 설치(install) → 호출(call)' 순으로 진행됩니다:

pilotctl appstore catalogue
pilotctl appstore install io.pilot.cosift
pilotctl appstore call io.pilot.cosift cosift.help '{}'

자율적인 파일럿에게 이를 안전하게 만드는 속성들은 다음과 같습니다: 앱은 서명 검증(signature-verified)을 거칩니다(매니페스트(manifest)가 sha256과 ed25519 서명을 고정하며, 매 실행 시마다 재확인됨), 권한은 부여 범위(grant-scoped)로 제한되며 설치 시점에 수락됩니다(주변 권한(ambient authority) 없음), 그리고 모든 앱은 런타임 .help 컨벤션을 노출하므로 에이전트는 사람이 문서를 읽지 않고도 자신이 무엇을 할 수 있는지 스스로 찾아낼 수 있습니다. 근거 있는 웹 검색(grounded web search), 코드를 테스트할 샌드박스(sandbox), 또는 에이전트 간 결제를 보낼 방법이 필요한 브라우저 파일럿(browser pilot)은 단 한 번의 명령으로 이를 설치할 수 있습니다. REST 배관 작업(REST plumbing)이나 브라우저 탭도 필요 없습니다.

이것이 바로 파일럿 에이전트가 원하는 루프입니다: 피어(peer)에 대한 안정적인 도달 범위, 그리고 스스로 가져올 수 있는 역량의 카탈로그(catalog)를 갖는 것입니다.

파일럿 에이전트란 진정으로 무엇인가?

질문에 직접적으로 답해 보겠습니다. 파일럿 에이전트(pilot agent)는 외부 시스템에 대해 제한된 자율성(bounded autonomy)을 가진 AI 에이전트입니다. 즉, 명시적인 권한(explicit permissions)과 자신의 작업 내용을 확인할 수 있는 방법을 갖춘 상태에서, 목표를 향해 인지(perceive)하고, 계획(plan)하며, 행동(act)하고, 검증(verify)합니다. 파일럿 에이전트가 유용한 범주인 이유는 여러분이 구축하는 대상 자체를 변화시키기 때문입니다. 즉, 범위가 지정된 권한 부여(scoped grants), 근거 있는 인지(grounded perception), 검증 피드백(verification feedback), 런타임 설치 가능한 도구(runtime-installable tools), 그리고 — 모두가 뒤늦게 깨닫게 되는 부분인 — 에이전트가 도달 가능한 상태를 유지하고 기기 간에 작업을 위임(delegate)할 수 있게 하는 네트워크를 의미합니다.

이미 파일럿 에이전트를 구축하고 있다면, 체크리스트는 간단합니다. 에이전트에 안정적인 주소(stable address)를 부여하고, 스스로 도구를 설치할 수 있게 하며, 접근할 수 있는 범위를 제한(scope)하십시오. 기반 인프라(plumbing)는 이미 존재하며, 명칭(naming)이 뒤늦게 따라왔을 뿐입니다.