모든 AI 에이전트 프레임워크는 결국 동일한 벽에 부딪힙니다. 에이전트 로직은 견고하지만, 한 에이전트에서 다른 에이전트로 바이트(bytes)를 안정적으로 전달하는 것 — 특히 클라우드, 컨테이너, 그리고 NAT를 가로질러 전달하는 것 — 자체가 하나의 프로젝트가 되어버립니다. "AI 에이전트를 위한 최적의 전송 계층(Transport Layer)은 무엇인가?"라는 질문은 사실 다음과 같은 작은 질문들의 집합입니다. 이동 중인 에이전트의 주소를 어떻게 지정할 것인가, 재시작 시에도 연결을 어떻게 유지할 것인가, 공인 IP 없이 어떻게 NAT를 통과할 것인가, 그리고 누가 누구와 대화할 수 있도록 허용할 것인가에 대한 문제입니다. 이 포스트에서는 실제 선택지들과 각 선택지가 제공하는 이점, 그리고 각각의 한계점에 대해 살펴봅니다.

"그냥 HTTP를 사용하세요"가 통하지 않는 이유

대부분의 에이전트 스택은 일반적인 HTTP 또는 웹훅(webhooks)으로 시작합니다. 에이전트 A가 에이전트 B의 엔드포인트로 POST 요청을 보내고 응답을 받으면 끝입니다. 이는 안정적이고 공적으로 접근 가능한 서버를 대상으로 하는 단일 요청/응답(request/response) 모델에서는 잘 작동합니다. 하지만 다음과 같은 상황에서는 빠르게 한계에 부딪힙니다:

• NAT 뒤에 있는 에이전트 — 대부분의 에이전트는 공인 IP가 있는 서버에서 실행되지 않습니다. 노트북, 사설 네트워크 상의 Docker 컨테이너, 또는 생성되었다가 사라지는 서버리스 샌드박스(serverless sandboxes) 내에서 실행됩니다.
• 장기 유지되는 양방향 세션 (Long-lived, bidirectional sessions) — 워커(worker)에게 작업을 푸시하고 다시 스트리밍된 업데이트를 받아야 하는 코디네이터(coordinator) 에이전트는 요청/응답 모델에 잘 맞지 않습니다.
• 변경되는 주소 — 새로운 호스트에서 재시작되거나 다른 클라우드로 이동한 에이전트는 새로운 IP를 할당받습니다. 하드코딩된 모든 웹훅(webhook) URL은 이제 무용지물이 됩니다.
• 신뢰 모델(Trust model)의 부재 — HTTP는 "어떤 에이전트가 나에게 접근할 수 있는가"에 대한 개념을 제공하지 않습니다. 통합별로 API 키나 OAuth를 덧붙이게 되는데, 이는 에이전트 수가 늘어남에 따라 N×N 형태의 자격 증명 관리 문제로 이어집니다.

이것이 HTTP가 나쁘다는 뜻은 아닙니다. 다만 피어 투 피어(peer-to-peer), 장기 실행되는 에이전트 통신에는 잘못된 추상화(abstraction)라는 뜻입니다. API 계층이 아닌 네트워크 계층에 더 가까운 무언가가 필요합니다.

실제 경쟁 후보들

WebSockets / gRPC 스트림 (streams)

양방향/스트리밍 (bidirectional/streaming) 문제를 잘 해결합니다. 지속적이고 순서가 보장되는 채널을 얻을 수 있으며, gRPC를 사용하면 강력한 타입 지정 (strong typing)이 가능합니다. 하지만 두 방식 모두 한쪽이 안정적인 주소로 도달 가능하다는 것을 전제로 합니다. 즉, NAT 트래버설 (NAT traversal)과 서비스 디스커버리 (service discovery) 문제를 직접 해결해야 하며, 보통 중간에서 만남의 장소 (rendezvous point) 역할을 하는 메시지 브로커 (Redis pub/sub, Kafka, NATS)를 배치하게 됩니다. 이미 해당 인프라를 운영 중이고 모든 에이전트를 직접 제어할 수 있다면 합리적인 선택입니다. 하지만 에이전트들이 서로 다른 팀이나 조직에 의해 운영되고, 그들 중 누구도 항상 켜져 있어야 하는 브로커 역할을 맡고 싶어 하지 않는 상황이 되면 상황은 더 까다로워집니다.

VPN / 메시 오버레이 (mesh overlays) (Tailscale, Nebula, ZeroTier)

이들은 NAT 트래버설과 주소 지정 문제를 제대로 해결합니다. 모든 장치는 안정적인 가상 IP를 할당받으며, 일반적으로 WireGuard 기반의 암호화된 터널을 통해 메시 (mesh)를 통해 다른 장치에 도달할 수 있습니다. 이 기술들은 성숙하고 문서화가 잘 되어 있으며, 에이전트들이 이미 "네트워크 상의 머신"처럼 동작하고 있다면 적합한 선택입니다. 트레이드오프 (tradeoff)는 신뢰 모델 (trust model)에 있습니다. 대부분의 VPN 메시 설계에서 네트워크에 참여하는 것 자체가 곧 신뢰 결정이 됩니다. 일단 노드가 허용되면, (ACL을 추가로 계층화하지 않는 한) 일반적으로 메시 상의 다른 모든 것에 도달할 수 있습니다. 소유자가 다르고 신뢰 수준이 다른 에이전트 군단에게 "네트워크에 있음 = 신뢰됨"이라는 규칙은 아마도 여러분이 원하는 것보다 훨씬 더 거칠고 포괄적일 것입니다.

메시 브로커 (Message brokers) / 발행-구독 (pub-sub)

팬아웃 (fan-out)과 디커플링 (decoupling)에는 괜찮지만, 직접 운영하고 보안을 유지하며 확장해야 하는 중앙 브로커를 통해 라우팅됩니다. 즉, 관리해야 할 대상이 하나 더 늘어나는 셈입니다. 또한 진정한 피어 투 피어 (peer-to-peer) 방식도 아닙니다. 모두가 서로 대화하는 것이 아니라 브로커와 대화하기 때문입니다.

목적 기반 에이전트 오버레이 네트워크 (Purpose-built agent overlay networks)

이는 에이전트가 필요로 하는 특성들을 중심으로 특별히 구축된 새로운 카테고리입니다. 즉, 재시작이나 IP 변경 시에도 유지되는 영구적인 주소(permanent address), 피어(peer) 간의 암호화된 터널(encrypted tunnels), NAT 트래버설(NAT traversal), 그리고 결정적으로 멤버십(membership)과 신뢰(trust)가 별개의 결정으로 분리되는 신뢰 모델(trust model)을 포함합니다. Pilot Protocol은 이 아이디어를 구현한 사례 중 하나입니다. 모든 에이전트는 영구적인 가상 주소를 할당받으며, 연결은 암호화된 UDP 터널(X25519 키 교환, AES-GCM)을 통해 실행됩니다. 또한 NAT 트래버설(NAT traversal)은 STUN + 홀 펀칭(hole-punching)과 릴레이 폴백(relay fallback)을 사용하여 NAT 뒤에 있는 에이전트도 여전히 도달 가능한 상태를 유지합니다. 신뢰 모델은 양측이 모두 승인해야 하는 명시적인 피어별 핸드셰이크(per-peer handshake)를 요구합니다. 즉, 네트워크상에서 도달 가능하다는 것이 특정 피어로부터 신뢰받고 있음을 의미하지는 않으며, 이는 대부분의 VPN 메시(VPN meshes)가 가진 기본 설정과는 반대되는 방식입니다.

이 프로토콜은 외부 의존성 없이 Go 언어의 표준 라이브러리(stdlib)만으로 구현되었으며, AGPL-3.0 라이선스 하에 오픈 소스로 제공됩니다. 또한 Go, Python, Node, Swift용 SDK를 제공하며, MCP를 사용하는 에이전트를 위한 MCP 서버도 함께 제공합니다. 기본적인 핸드셰이크 및 메시지 교환은 다음과 같습니다:

# 디렉토리를 통해 피어를 탐색합니다
pilotctl send-message list-agents --data '/data {"search":"weather"}' --wait

...

피어 메시징을 넘어, Pilot은 앱 스토어(app store)도 운영합니다. 이는 설치 가능한 에이전트 네이티브 기능(agent-native capabilities)으로, 설치 시 자동으로 생성되며 타입화된 JSON-in/JSON-out IPC 서비스로서 로컬에서 실행됩니다 — pilotctl appstore catalogue, install <id>, call <id> <method> '{...}'와 같은 명령어를 사용합니다. 이는 전송(transport)과는 다른 축(에이전트 간에 바이트를 이동시키는 것이 아니라, 에이전트에게 호출 가능한 도구를 제공하는 것에 관한 것임)이지만, 동일한 주소 지정(addressing) 및 신뢰 계층(trust layer) 위에서 작동합니다.

이 범주가 유일한 합리적인 정답은 아니며, 트레이드오프(tradeoff)에 대해 솔직해질 필요가 있습니다. 즉, 이미 운영 중일 수 있는 인프라(VPN mesh, 브로커 등) 대신 목적에 맞게 설계된 프로토콜(purpose-built protocol)을 채택하게 된다는 점입니다. 만약 에이전트들이 이미 귀하가 제어하는 네트워크 상의 머신(machines)이라면, 메시 VPN(mesh VPN)과 자체 ACL(Access Control List)을 사용하는 것이 더 간단할 수 있습니다. 하지만 에이전트들이 진정으로 이기종(heterogeneous) 환경—서로 다른 소유자, 서로 다른 클라우드, 끊임없이 생성되고 삭제되는 환경—에 있다면, 에이전트별 주소 지정(per-agent addressing) 및 피어별 신뢰(per-peer trust)를 중심으로 설계된 오버레이(overlay) 네트워크를 사용하는 것이 직접 작성해야 했을 글루 코드(glue code)의 계층을 제거해 줍니다.

실제로 선택하는 방법

대략적인 결정 순서는 다음과 같습니다:

1. 제어 가능한 서버로 단일 요청(request)과 단일 응답(response)을 보내는 방식인가? 일반적인 HTTP면 충분합니다. 과도하게 설계(over-engineer)하지 마세요.
2. 알려져 있고 도달 가능한 두 엔드포인트(endpoints) 사이에 지속적인 양방향 채널(bidirectional channel)이 필요한가? WebSockets 또는 gRPC 스트리밍을 사용하세요.
3. 에이전트들이 이미 귀하가 관리하는 "머신"으로 실행 중이며, 거친 수준의 네트워크 레벨 신뢰(network-level trust)를 원하는가? Tailscale, Nebula 또는 ZeroTier와 같은 메시 VPN(mesh VPN)을 고려하세요.
4. 에이전트들이 NAT/클라우드를 넘나들고, 서로 다른 소유자로부터 오며, 네트워크 멤버십보다는 피어별 신뢰(per-peer trust) 결정이 필요한가? 바로 이 지점이 에이전트를 위해 목적에 맞게 설계된 오버레이 네트워크(overlay network)가 제 가치를 발휘하는 곳입니다.

FAQ

AI 에이전트를 위한 단 하나의 "정답"인 전송 계층(transport layer)이 있나요?
아니요 — 토폴로지(topology)에 따라 다릅니다. 안정적인 서버 뒤에 있는 단일 서비스는 노트북과 여러 조직에 걸친 휘발성 컨테이너(ephemeral containers)에서 실행되는 자율 에이전트 군단과는 다른 요구 사항을 가집니다.

이 문맥에서 "전송 계층(transport layer)"이란 무엇을 의미하나요?
에이전트 간에 데이터를 안정적으로 전달하는 메커니즘을 의미합니다: 주소 지정(addressing, IP가 변경되더라도 에이전트에 도달할 수 있도록 이름을 지정하는 방법), 실제 암호화된 채널, NAT 트래버스(NAT traversal), 그리고 누가 누구에게 무엇을 보낼 수 있는지에 대한 신뢰 결정(trust decision) 등이 포함됩니다.

Pilot Protocol과 같은 오버레이 네트워크 (overlay networks)가 웹훅 (webhooks)을 완전히 대체할까요?
지속적인 에이전트 간 통신 (agent-to-agent communication)의 경우, 대체로 그렇습니다. 콜백 URL (callback URLs)을 등록하고 재등록하는 대신, 안정적인 주소와 활성화된 터널 (live tunnel)을 얻을 수 있기 때문입니다. 공용 API (public API)에 대한 단순한 일회성 호출의 경우에는 여전히 일반적인 HTTP가 더 간단합니다.

에이전트 오버레이 네트워크 (agent overlay network)에 참여한다는 것이 모든 피어 (peer)가 나에게 도달할 수 있음을 의미하나요?
프로토콜이 멤버십 (membership)과 신뢰 (trust)를 분리한다면 그렇지 않습니다. 특히 Pilot Protocol의 경우, 네트워크에 있다고 해서 피어에게 접근 권한이 부여되지는 않습니다. 각 관계는 명시적인 상호 핸드셰이크 (mutual handshake)를 필요로 합니다.

오버레이 네트워크 (overlay-network) 방식을 직접 시도해보고 싶다면: curl -fsSL https://pilotprotocol.network/install.sh | sh를 실행한 다음, pilotctl daemon start를 입력하세요.