어제까지만 해도 당신의 에이전트(agent)에 접속할 수 있었습니다. 하지만 어젯밤 DHCP 임대 기간이 만료되었거나, 컨테이너(container)가 재스케줄링되었거나, 클라우드(cloud)가 공인 IP를 조용히 재할당하면서, 이제 에이전트를 가리키던 모든 하드코딩된 엔드포인트(endpoint), 모든 웹훅(webhook) URL, 모든 설정(config)은 더 이상 존재하지 않는 머신을 가리키고 있습니다. 이것은 제가 에이전트 플릿(agent fleets)이 통신 불능 상태가 되는 것을 목격한 가장 흔한 방식이며, 결코 에이전트의 잘못이 아닙니다. 그것은 주소 지정 모델(addressing model)의 문제입니다.

해결책은 IP를 추적하는 더 나은 방법을 찾는 것이 아닙니다. IP를 에이전트의 정체성(identity)으로 취급하는 것을 중단하는 것입니다. 에이전트의 IP가 변경되어도 연결 상태를 유지하기 위해 실제로 충족되어야 하는 조건은 다음과 같습니다.

에이전트의 주소가 IP가 되어서는 안 되는 이유

IP 주소는 머신이 네트워크의 _어디(where)_에 연결되어 있는지를 설명합니다. 그 머신이 _무엇(what)_인지에 대해서는 아무것도 말해주지 않습니다. 이 구분이 중요한 이유는 현대의 배포 모델(deployment model)에 관한 모든 것이 "어디"를 불안정하게 만들기 위해 존재하기 때문입니다.

• 노트북은 절전 모드로 들어갑니다. 새로운 네트워크에서 깨어날 때, DHCP는 새로운 주소를 할당합니다.
• 컨테이너는 재스케줄링됩니다. 새로운 포드(pod)는 새로운 네트워크 네임스페이스(network namespace)이며, 종종 새로운 IP를 가집니다.
• 클라우드는 재할당합니다. 스팟 인스턴스(Spot instances)는 소멸하고, 탄력적 IP(elastic IPs)는 분리되며, 리전(regions)이 이동합니다.
• CGNAT 및 통신사 네트워크는 당신이 보는 주소가 다른 누구도 도달할 수 없는 주소임을 의미합니다.

만약 에이전트의 주소가 곧 IP라면, IP가 변경될 때마다 에이전트는 연결할 수 없게 됩니다. 즉, 결국에는 항상 연결이 끊기게 됩니다. 주소와 IP는 서로 다른 두 가지여야 합니다.

에이전트의 IP가 변경되어도 연결 상태를 유지하는 방법

IP 변동(IP churn) 속에서도 에이전트가 연결 상태를 유지하려면 네 가지 속성이 충족되어야 합니다. 저는 해결책을 검토할 때 첫 번째 속성뿐만 아니라 네 가지 모두를 기준으로 확인하는 것이 유용하다는 것을 발견했습니다:

1. 정체성(Identity)이 위치(Location)와 분리되어야 합니다. 다른 에이전트들이 당신을 찾기 위해 사용하는 주소는 당신의 IP가 변경될 때 바뀌어서는 안 됩니다. 그것은 라우터에 의해 할당된 숫자가 아니라, 이름(Name)이나 ID여야 합니다.
2. 매핑(Mapping)이 스스로 업데이트되어야 합니다. IP가 변경될 때, 에이전트는 자신의 새로운 위치를 어떤 레지스트리(Registry)나 네임서버(Nameserver)에 자동으로 알릴 수 있어야 합니다. 만약 사람이 직접 설정(Config)이나 DNS 레코드를 수정해야 한다면, 그 사람이 깨어날 때까지 에이전트는 다운된 상태가 됩니다.
3. 도달 가능성(Reachability)이 공인 IP(Public IP)에 의존하지 않아야 합니다. NAT(Network Address Translation) 뒤편—홈 네트워크, 사무실 방화벽, 클라우드 이그레스(Cloud egress)—에는 인바운드 경로가 전혀 존재하지 않습니다. 홀 펀칭(Hole-punching)과 릴레이 폴백(Relay fallback)은 에이전트가 태어난 데이터센터뿐만 아니라 어디에서든 주소에 도달할 수 있게 만드는 핵심 요소입니다.
4. 전송 계층(Transport)이 주소 변동(Address churn) 속에서도 생존해야 합니다. TCP는 연결 도중 엔드포인트 IP가 변경되는 순간 종료됩니다. 소켓(Socket)이 사라지기 때문입니다. 사용자 공간(Userspace)에서 신뢰성(Reliability)을 구현한 UDP 기반 전송 계층은 주소 변경 시에도 세션을 유지합니다. 왜냐하면 "연결"이 IP에 고정된 커널 소켓의 속성이 아니라, 오버레이(Overlay)의 속성이기 때문입니다.

대부분의 "도달 가능하게 유지하라"는 조언은 속성 1에서 멈춥니다. 그렇게 하면 네트워크가 실제로 변경될 때까지만 작동하는 시스템을 만들게 됩니다.

옵션들에 대한 솔직한 비교

에이전트에게 IP보다 오래 지속되는 주소를 부여하는 솔직한 방법에는 세 가지가 있습니다. 이들은 서로 대체 가능한 것이 아니라, 서로 다른 문제를 겨냥하고 있습니다.

다이내믹 DNS (Dynamic DNS). IP가 변경될 때 DNS 레코드를 업데이트하는 클라이언트를 실행하는 방식입니다. 간단하며, 공인 IP와 안정적인 호스트네임(Hostname)을 가진 서버에는 실제로 효과가 있습니다. 하지만 속성 3과 4를 충족하지 못합니다. NAT 뒤에서는 레코드가 가리킬 대상이 없으며, DNS는 매핑의 캐시(Cache)이기 때문에 TTL(Time To Live), 리졸버 캐시(Resolver caches), 전파 지연(Propagation delays)으로 인해 피어(Peer)들이 변경 후에도 오랫동안 이전 주소를 계속 해석할 수 있습니다. DDNS는 블로그에는 괜찮습니다. 하지만 "지금 당장" 도달 가능해야 하는 에이전트에게는 취약합니다.

Overlay VPNs (Tailscale, ZeroTier). 이들은 신원(identity)을 적절히 처리하며 NAT 트래버설 (NAT traversal) 성능이 진정으로 뛰어납니다. 즉, 머신이 네트워크 변경 시에도 이름을 유지하며, 이는 동일한 문제에 대한 실질적인 해결책이 됩니다. 이들은 머신 및 인간의 VPN 사용을 목표로 합니다. 테일넷 (tailnet)에 참여하면 주소를 할당받고, 그 주소로 연결하면 됩니다. 본연의 기능을 매우 잘 수행합니다.

Pilot Protocol과 같은 에이전트 네이티브 오버레이 (Agent-native overlays). 도달 가능성을 유지해야 하는 대상이 노트북이 아닌 _에이전트 (agent)_인 경우, 제가 추천할 방식은 바로 이것입니다. Pilot Protocol은 모든 에이전트에게 재시작, IP 변경, 클라우드 간 이동 시에도 유지되는 영구적인 가상 주소를 부여합니다. 데몬 (daemon)은 에이전트의 현재 위치를 레지스트리 (registry)에 계속 알려주므로, 피어 (peer)들은 동일한 주소를 현재 위치로 해석(resolve)할 수 있습니다. 전송 방식은 사용자 공간 신뢰성 (userspace reliability)을 갖춘 암호화된 UDP 터널 (X25519 키 교환 및 AES-GCM)을 사용하며, NAT 트래버설 (NAT traversal)은 STUN 및 홀 펀칭 (hole-punching)과 릴레이 폴백 (relay fallback)을 지원하므로, 홈 라우터 뒤에 있는 에이전트도 클라우드 VPC 내에 있는 에이전트만큼이나 쉽게 도달할 수 있습니다. 이는 오픈 소스 (Go, 표준 라이브러리만 사용)이며, 현재 네트워크에는 243k명 이상의 에이전트와 사용자가 있습니다.

솔직한 비교를 하자면: 공인 IP 서버를 위한 호스트 이름이 단순히 필요한 경우라면 DDNS가 적합합니다. Overlay VPNs는 인간과 머신의 VPN 접속에 적합합니다. Pilot은 사용자가 DNS를 건드리거나 포트를 열지 않고도, 다른 에이전트들이 어떤 네트워크에서든 당신의 에이전트를 찾아 도달해야 하는 상황을 위해 구축되었습니다.

실제 사용 모습

구체적으로 "주소가 IP보다 오래 지속된다"는 것은, 이전에 직접 관리해야 했던 부분들이 더 이상 당신의 문제가 되지 않음을 의미합니다:

curl -fsSL https://pilotprotocol.network/install.sh | sh

데몬이 한 번 등록하면 에이전트는 주소를 할당받습니다. 네트워크가 변경되어도 — 노트북이 깨어나거나, 컨테이너가 재스케줄링되거나, 클라우드가 재할당되더라도 — 데몬은 랑데부 레지스트리 (rendezvous registry)에 새로운 위치를 다시 알립니다. 그 외의 다른 것은 변하지 않습니다:

pilotctl set-hostname order-processor        # 한 번만 실행
# ...며칠 후, 다른 네트워크, 다른 IP에서...
pilotctl send-message order-processor --data 'status?'

두 번째 명령은 어디서든 작동합니다. 왜냐하면 order-processor는 IP가 아니었기 때문입니다. 업데이트할 DNS 레코드도, 구매해야 할 고정 IP (Static IP)도, 재설정해야 할 포트 포워딩 (Port Forwarding)도 없습니다. 이 주소는 에이전트가 현재 위치한 곳 어디로든 네트워크가 해석(Resolve)하는 이름입니다. 이것이 설계의 핵심입니다.

핵심 요약 (The Takeaway)

에이전트의 IP가 변경될 때도 연결 상태를 유지하려면 다음과 같이 설계해야 합니다: 정체성 (Identity)을 위치 (Location)로부터 분리하고, 사람이 개입하는 대신 네트워크가 스스로 재공지 (Re-announce)하게 하며, 공인 IP (Public IP) 없이도 도달 가능성 (Reachability)이 작동하도록 만들고, 단일 주소에 고정되지 않는 전송 방식 (Transport)을 선택해야 합니다. 어떤 "연결 유지" 솔루션이든 이 네 가지 속성을 기준으로 검토해 보십시오. 그러면 문제가 발생한 후가 아니라, 발생하기 전에 실패 모드 (Failure modes)를 명확히 파악할 수 있습니다.

다른 에이전트가 찾아낼 수 있는 에이전트를 구축하고 있다면, Pilot Protocol이 에이전트 주소 지정(Addressing)을 처리하는 방법에 관한 문서를 통해 레지스트리 (Registry), 주소 모델 (Address model), 그리고 NAT 트래버설 (NAT traversal)에 대해 더 자세히 알아볼 수 있습니다. 위의 설치 명령어를 사용하면 약 1분 만에 노드를 구축할 수 있으며, 이때 할당받은 주소는 다음 IP 변경 후에도 그대로 유지될 것입니다.