AI 에이전트를 위한 NAT Traversal: 왜 멀티 에이전트 시스템은 서로를 찾지 못하는가

서로 다른 네트워크에 있는 두 AI 에이전트가 서로 통신하도록 시도해 보았다면, 아마 다음과 같은 벽에 부딪혔을 것입니다: 에이전트 A는 인터넷에 잘 접속할 수 있고, 에이전트 B도 마찬가지지만, 에이전트 A가 에이전트 B에게 직접 전화를 걸 수 없습니다. 에러 메시지도 없고, 타임아웃도 발생하지 않습니다. 연결 시도가 그저 조용히 사라져 버릴 뿐입니다.

이것은 당신의 코드에 있는 버그가 아닙니다. 이것은 NAT (Network Address Translation, 네트워크 주소 변환)가 설계된 대로 정확하게 작동하고 있는 것이며, 피어 투 피어 (Peer-to-Peer, P2P) AI 에이전트 네트워킹이 보기보다 어려운 가장 큰 이유입니다.

문제점: NAT는 발견되기를 원하는 에이전트를 위해 만들어지지 않았습니다

NAT (RFC 3022)가 존재하는 이유는 IPv4 주소가 고갈되었기 때문입니다. 모든 장치에 공인 IP (Public IP)를 할당하는 대신, 라우터가 여러 개의 사설 IP (Private IP)를 하나의 공유된 공인 IP로 매핑하며, 나가는 길에 패킷 헤더를 다시 작성합니다. 이 과정에서의 트레이드오프(Tradeoff)는 다음과 같습니다: 외부로 나가는 연결은 잘 작동하지만, 요청되지 않은 내부로 들어오는(unsolicited inbound) 연결은 차단됩니다. 왜냐하면 NAT에는 해당 트래픽을 어떤 내부 머신이 받아야 하는지 알려주는 매핑 정보가 없기 때문입니다.

서버로 외부 HTTP 요청을 보내는 노트북의 경우에는 문제가 되지 않습니다. 하지만 서로 피어(Peer)로서 동작하기를 원하는 두 AI 에이전트에게는 심각한 문제입니다. 네트워크 관점에서 보면, 각 에이전트는 의도치 않은 방화벽 역할을 하도록 설계된 장치 뒤에 앉아 있는 클라이언트일 뿐입니다.

Agent A --> NAT-1 --> NAT-2 --> Agent B
두 패킷 모두 차단됨: 어느 NAT도 상대방에 대한 매핑을 가지고 있지 않음.

"에이전트들이 서로 직접 연결할 수 있다"고 가정하는 대부분의 프레임워크 — HTTP 기반의 MCP 트랜스포트 (MCP transports), 단순한 A2A 구현, 일반적인 REST 콜백(callbacks) 등 — 는 여기서 조용히 실패합니다. 이러한 방식은 한 대의 머신이나 하나의 클라우드 VPC 내에서의 데모에서는 훌륭하게 작동하지만, 에이전트 중 하나가 가정용 라우터, Wi-Fi를 사용하는 노트북, 또는 NAT가 적용된 컨테이너 네트워크 뒤에 있는 순간 깨져버립니다. 실패 모드는 대개 조용합니다. 요청이 그냥 타임아웃(Timeout)될 뿐이며, 그 이유가 명확하지 않습니다.

모든 NAT가 동일한 것은 아닙니다

IETF의 고전적인 분류 체계 (RFC 3489)는 NAT 동작을 네 가지 유형으로 나눕니다. 어떤 통과(Traversal) 전략이 유효할지는 이 유형에 따라 크게 달라집니다:

NAT 유형	매핑 규칙 (Mapping rule)	응답 가능한 대상	통과 전략 (Traversal strategy)
Full Cone	모든 목적지에 대해 동일한 외부 포트 사용	모든 외부 호스트	직접 연결, STUN을 통해
...

Cone NAT(Full, Restricted, Port-restricted)는 더 우호적인 다수를 차지하며, 홀 펀칭 (Hole-punching)이 이들을 상대로 안정적으로 작동합니다. Symmetric NAT는 까다로운 사례입니다. 이는 통신하는 모든 목적지에 대해 서로 다른 외부 포트를 할당하기 때문에, STUN 서버가 관찰한 포트가 피어(Peer)가 실제로 보게 될 포트와 일치하지 않기 때문입니다. 포트 추측(Port-guessing)으로는 이를 안정적으로 해결할 수 없으며, 릴레이 (Relay)가 유일하게 보장된 대안입니다.

실제 통과가 일어나는 방식

1단계 — 자신의 공용 엔드포인트 (Public endpoint) 파악. 이것이 바로 STUN (RFC 5389)의 용도입니다. 잘 알려진 서버가 귀하의 패킷에서 관찰된 소스 IP:포트(source IP:port)를 다시 반사(Reflect)해 주며, 이를 통해 귀하가 트래픽을 보낼 때 외부 세계가 귀하를 어떻게 보는지 알 수 있습니다.

에이전트 (Agent) (192.168.1.50:4000) → NAT (203.0.113.10) → 비콘 (Beacon) (35.193.106.76:9001)
비콘 응답: "귀하의 엔드포인트는 203.0.113.10:54321입니다"

2단계 — 동시 펀칭 (Simultaneous punch) 조율. Cone NAT의 경우, 두 에이전트는 (거의) 동시에 서로의 발견된 엔드포인트로 UDP 패킷을 보냅니다. 각 아웃바운드(Outbound) 패킷은 해당 에이전트의 라우터에 NAT 매핑을 생성하며, 두 매핑이 어느 한 쪽의 NAT 세션 상태가 만료되기 전에 생성된다면, 이후 피어로부터 오는 패킷은 그대로 통과하게 됩니다.

에이전트 A (Agent A) -- 펀칭 요청 (punch request) --> 비콘 (Beacon)
비콘 (Beacon) -- 펀칭 명령 (punch command) --> 에이전트 B (Agent B)
비콘 (Beacon) -- 펀칭 명령 (punch command) --> 에이전트 A (Agent A)
...

여기서 까다로운 부분은 타이밍입니다. NAT 매핑 (NAT mappings)은 일반적으로 30~120초의 비활성 상태 후에 만료되며, 만약 펀칭 (punches)이 긴밀하게 조정되지 않으면 한쪽의 패킷이 다른 쪽의 NAT 매핑이 열리기 전에 도착하여 드롭 (dropped)될 수 있습니다. 견고한 구현체는 한 번의 시도 후에 포기하는 대신 자동으로 재시도합니다.

3단계 — 펀칭이 작동하지 않을 때 릴레이 (relay)로 전환. 대칭형 NAT (Symmetric NAT) 및 셀룰러와 일부 ISP 네트워크에서 흔히 볼 수 있는 대부분의 캐리어급 NAT (CGNAT) 설정의 경우, 신뢰할 수 있는 펀칭이 불가능합니다. 유일한 해결책은 양측 모두가 도달할 수 있고, 그들 사이의 트래픽을 전달하는 릴레이 서버 (relay server)를 사용하는 것입니다. 이는 직접 경로 (direct path)보다 느리지만, 직접 연결이 진정으로 불가능할 때 확실히 작동하는 옵션입니다.

에이전트 네트워크를 구축하는 사람들에게 이것이 갖는 의미

로컬 도구를 호출하는 단일 머신 에이전트를 구축하고 있다면, 이 중 어느 것도 중요하지 않습니다. MCP 및 유사한 도구 호출 (tool-calling) 프로토콜이 해당 범위를 잘 처리하기 때문입니다. 이것이 중요해지기 시작하는 시점은 _에이전트_가 _다른 에이전트_에게 도달하기를 원하는 순간부터입니다. 예를 들어, 노트북에서 실행되는 조정 레이어 (coordination layer)가 집에 있는 GPU 박스에서 실행되는 더 무거운 에이전트에게 접속해야 하거나, 모든 에이전트에 대해 공인 IP (public IPs)를 할당하고 방화벽 규칙 (firewall rules)을 일일이 열어주지 않고도 서로를 찾아야 하는 다양한 클라우드와 NAT에 흩어져 있는 에이전트 군단(fleet)의 경우입니다.

그것이 바로 Pilot Protocol이 목표로 하는 구체적인 격차입니다. 이 프로토콜은 각 에이전트에 영구적인 가상 주소를 부여하고, STUN 발견 (discovery), 홀 펀칭 (hole-punching), 그리고 릴레이 폴백 (relay fallback)을 자동으로 처리하여 에이전트가 IP 대신 이름으로 서로에게 접속할 수 있게 합니다. 사용자가 트래버설 (traversal) 코드를 작성할 필요는 없습니다. pilotctl daemon start 명령이 에이전트를 등록하고, NAT 유형을 발견하며, 데몬 (daemon)이 피어 (peer)별로 적절한 전략을 선택합니다. 이는 Tailscale, Nebula, ZeroTier와 같은 VPN 스타일의 오버레이 (overlays)와 함께 이 분야의 도구 중 하나입니다. 다만 이들은 내장된 신뢰 모델을 가진 개별 주소 지정 가능한 에이전트보다는 머신 (machines)을 위한 중복되는 문제들을 해결합니다.

어떤 스택을 사용하든, 도구와 상관없이 근본적인 교훈은 동일합니다. 만약 당신의 멀티 에이전트 시스템 (multi-agent system)이 에이전트들이 항상 서로에게 직접 연결할 수 있다고 가정한다면, 당신은 암묵적으로 NAT를 배제한 것입니다. 그리고 NAT는 당신의 가정이 무엇이었는지 상관하지 않습니다.

FAQ

왜 내 에이전트 간 연결은 localhost에서는 작동하지만 네트워크를 가로지르면 실패하나요?
localhost에는 경로상에 NAT가 없습니다. 실제 네트워크와 라우터가 개입되면, 매핑을 미리 설정하거나 홀을 열어두지 않는 한 요청되지 않은 인바운드 패킷 (unsolicited inbound packets)은 드롭(drop)됩니다.

그냥 공인 IP (public IP)를 사용해서 이 모든 과정을 건너뛸 수 없나요?
모든 에이전트가 공인 IP를 가지고 있다면 가능합니다. 대부분의 클라우드 VM은 이를 가지고 있으며, 트래버설 (traversal) 도구들은 일반적으로 고정된 공인 엔드포인트 (public endpoint)를 등록하여 STUN을 완전히 건너뛸 수 있게 해줍니다. 문제는 노트북, 홈 네트워크, 그리고 안정적인 공인 IP가 없는 대부분의 소비자용 또는 CGNAT 연결에서 발생합니다.

홀 펀칭 (hole-punching)이 모든 NAT 유형에서 작동하나요?
아니요. Full Cone, Restricted Cone, Port-Restricted Cone NAT에서는 안정적으로 작동합니다. 하지만 Symmetric NAT는 목적지마다 다른 외부 포트를 할당하며, 이는 홀 펀칭이 의존하는 조정 (coordination) 과정을 깨뜨립니다. 이 경우 릴레이 (relay)가 유일하게 신뢰할 수 있는 대안입니다.

이것이 AI 에이전트 특유의 문제인가요, 아니면 일반적인 P2P 네트워킹 문제인가요?
근본적인 NAT 메커니즘은 일반적입니다. 이는 수년 전 VoIP와 게임 분야에서 해결했던 것과 동일한 문제입니다. AI 에이전트에게 있어 새로운 점은 _지속 가능하고 발견 가능한 정체성 (persistent, discoverable identity)_이 필요하다는 것입니다. 재시작하거나, 클라우드를 이동하거나, IP가 변경되는 에이전트라도 여전히 안정적인 주소로 도달할 수 있어야 하며, 이는 일회성 호출 설정과는 약간 다른 요구사항입니다.