AI 에이전트가 재시작될 때마다 주소를 잃어버립니다. 다른 클라우드에서 실행하면 — 주소가 달라집니다. NAT 뒤로 옮기거나, 재스케줄링되는 Kubernetes pod에 배치하면 — 매번 주소가 달라집니다. 이것은 사소한 불편함이 아니라, 다른 에이전트와 통신해야 하는 모든 에이전트에게 구조적인 문제입니다.

DNS는 보통 웹 서비스(web services)의 이 문제를 해결합니다. 하지만 에이전트는 웹 서비스가 아닙니다. 에이전트는 피어(peer)입니다. 에이전트는 대화를 시작하고 수락하며, 오프라인 상태에서 메시지를 보내고 나중에 이를 검색하며, 자신이 알고 있는 모든 대상에게 다시 등록하지 않고도 환경 사이를 이동합니다. 컨테이너 IP나 특정 호스트에 연결된 DNS 이름은 이를 제공하지 못합니다.

에이전트 주소가 견뎌내야 하는 세 가지 요소

재시작 (Restarts). 에이전트가 다운되었다가 다시 올라올 때, 에이전트에 도달하는 방법을 알고 있던 모든 것이 여전히 작동해야 합니다. 컨테이너 IP를 사용하면 이를 잃게 됩니다. Docker는 IP를 고정하지 않는 한 재시작할 때마다 컨테이너에 새로운 IP를 부여합니다 (고정하더라도 서브넷이 변경될 수 있습니다). DNS 레코드는 결국 업데이트되지만 — TTL(Time To Live)이 60초 미만이고 장비에 동적 DNS(dynamic DNS) 에이전트가 있는 경우에만 — A 레코드가 전파될 때쯤이면, 재연결을 시도했던 모든 피어는 타임아웃(timeout)을 겪게 됩니다.

IP 변경 (IP changes). 에이전트는 단일 IP 주소에 묶여 있어서는 안 됩니다. 개발자들은 노트북에서 에이전트를 구축하고, 스테이징 VM(staging VMs)에서 테스트하며, 프로덕션 클러스터(production clusters)에 배포합니다 — 세 개의 서로 다른 네트워크, 세 개의 서로 다른 IP입니다. 모든 환경 변화는 모든 피어에게 새로운 주소를 다시 알려줘야 함을 의미하며, 이는 중앙 레지스트리(central registry)에 보고하거나 수동으로 재설정해야 함을 의미합니다. 수십 개의 에이전트가 있을 때 이 중 어느 것도 확장성(scale)을 갖지 못합니다.

클라우드 간 이동. 이것은 인프라 엔지니어들을 밤잠 설치게 만드는 문제입니다. AWS에서 시작하여 GCP 또는 Hetzner로 이동하는 에이전트는 자신의 정체성(identity)을 함께 가져가야 합니다. some-agent.mycompany.com과 같은 DNS 이름은 새로운 클라우드 제공업체의 서브넷(subnet)이 DNS 팀의 마지막 업데이트와 일치하지 않을 때 작동을 멈춥니다. 그리고 중복성(redundancy)을 위해 여러 클라우드에 걸쳐 에이전트를 실행하는 경우, 에이전트당 하나의 정적 IP(static IP)를 할당하는 것은 비용이 많이 들고 취약합니다.

DNS는 웹 앱에는 작동하지만, 에이전트에는 작동하지 않습니다

DNS는 가장 명백한 첫 번째 답변입니다. 모든 웹 서비스가 주소 지정(addressing) 문제를 해결하는 방식이기 때문입니다. 서비스가 호스트 이름(hostname)을 할당받고, 클라이언트가 이를 조회하면 끝납니다. 하지만 DNS는 주소 지정 대상이 계속 가동 상태를 유지하며 연결을 수락하는 서버라고 가정합니다.

에이전트는 다릅니다:

• NAT(노트북, 홈 서버, 기업용 VPN 등) 뒤에 있을 수 있습니다 — 레코드에 넣을 수 있는 공개적으로 도달 가능한 주소가 없기 때문에 DNS는 도움이 되지 않습니다.
• 일시적(ephemeral)일 수 있습니다 — 단일 작업을 위해 생성되었다가 작업이 완료되면 파괴되는 에이전트들입니다.
• 에이전트가 메시지를 보낼 당시 오프라인 상태였더라도, 메시지가 나중에 도착할 수 있도록 전송해야 합니다.
• DNS를 중개자로 통하는 것이 아니라, 피어(peers)와 직접 신뢰 관계를 구축해야 합니다.

DNS는 서버가 안정적인 IP를 가진 데이터 센터에 위치하는 세상을 위해 설계되었습니다. 에이전트는 노트북, 엣지 디바이스(edge devices), 컨테이너, 서버리스 런타임(serverless runtimes)에서 실행되며, 이 중 어느 것도 해당 모델에 부합하지 않습니다.

컨테이너 진영이 잘못 알고 있는 것

"Service와 ClusterIP가 있는 Pod에 넣으세요"라는 말은 에이전트가 클러스터 외부의 에이전트와 통신해야 할 때까지는 해결책처럼 들립니다. 하지만 그 단계에 이르면 NAT 트래버설(NAT traversal), 클러스터 간 DNS 해상(DNS resolution), mTLS 인증서 관리 문제를 해결해야 합니다 — 즉, 의도치 않게 풀 메시 네트워킹(full mesh networking) 계층을 직접 재구현하게 되는 셈입니다.

저는 팀들이 서비스 디스커버리 (service discovery)를 위해 Consul이나 etcd를 사용하고, mTLS를 위해 Linkerd를, 외부 접속을 위해 nginx 인그레스 컨트롤러 (ingress controllers)를, 그리고 상태 공유를 위한 커스텀 킵얼라이브 (keepalive) 시스템을 구축하는 정교한 설정을 구축하는 것을 보았습니다. 이는 단일 주소 계층 (addressing layer)이 처리해야 할 일을 네 개의 별도 도구가 수행하고 있는 것입니다. 그리고 에이전트가 클러스터 간에 이동할 때 여전히 문제가 발생합니다.

영구적인 주소의 실제 모습

에이전트를 위한 영구적인 주소는 세 가지 속성을 가집니다:

1. 변하지 않습니다. 주소는 재시작, IP 변경, 클라우드 마이그레이션 (cloud migrations) 후에도 유지됩니다. 이는 에이전트가 특정 순간에 어디에서 실행 중인지와 관계없이, 다른 에이전트들이 해당 에이전트에 도달하기 위해 사용하는 안정적인 핸들 (handle)입니다.

2. 어디에서나 도달 가능합니다. NAT 뒤에 있든, 클라우드 VM에 있든, 기차 안의 노트북에서 실행 중이든 — 다른 에이전트들이 여전히 메시지를 전달할 수 있습니다. 네트워크 트래버설 (network traversal)은 에이전트가 아닌 주소 계층이 처리합니다.

3. 정체성 (identity)을 담고 있습니다. 주소는 단순한 위치 지정자 (locator)가 아닙니다 — 이는 에이전트의 암호화 키 (cryptographic key)와 결합되어 있습니다. 신뢰는 별도의 인증 기관 (certificate authority)을 통해 덧붙여지는 것이 아니라, 주소 자체에 내장됩니다.

이것이 가상 주소 (virtual address)의 형태입니다. 에이전트는 한 번 등록하여 안정적인 식별자 (identifier)를 얻고, 어떤 네트워크를 통해서도 이동할 수 있으며 — 전송 계층 (transport layer)이 이를 따라갑니다. 다른 에이전트들은 그것이 현재 어디에 있는지 알 필요가 없습니다. 그저 주소로 보내기만 하면 네트워크가 전달 경로를 찾아냅니다.

이것이 오늘날 중요한 이유

단일 에이전트 프로젝트는 이 벽에 부딪히지 않습니다. 에이전트 하나를 실행하고 API와 통신하면, 아무도 그 주소에 신경 쓰지 않습니다. 하지만 서로 통신해야 하는 두 개의 에이전트가 생기거나 — 혹은 한 에이전트가 다른 에이전트에게 작업을 넘겨줘야 하는 순간 — 그들에게 도달할 수 있는 안정적인 방법이 필요합니다.

그 지점에서 멀티 에이전트 시스템 (multi-agent systems)이 정체됩니다. 저는 네트워킹 계층이 제대로 고려되지 않아, 설계가 잘 된 에이전트 아키텍처가 무너지는 것을 보았습니다. 팀들은 결국 웹훅 (webhook) 엔드포인트를 덧붙이거나, 새로운 메시지를 위해 데이터베이스를 폴링 (polling)하거나, 모든 것을 병목 현상이자 단일 장애점 (single point of failure)이 되는 중앙 릴레이 (central relay)를 통해 라우팅하게 됩니다.

각 에이전트를 위한 영구적인 주소(permanent address)가 있다면 이 문제는 해결됩니다. 에이전트들은 단 한 번 서로를 발견하고, 주소를 교환하며, 직접 통신합니다. 폴링(polling), 중앙 릴레이(central relay), DNS TTL 레이스 컨디션(race conditions)이 필요 없습니다.

실질적인 테스트

다음에 멀티 에이전트 시스템(multi-agent system)을 설계할 때, 한 가지 질문을 던져보세요. 만약 에이전트가 다른 IP를 가진 다른 머신에서 재시작된다면, 그 에이전트의 모든 피어(peers)들이 여전히 그에게 도달하는 방법을 알고 있습니까?

만약 그 답변에 "설정 파일(config file)을 업데이트한다"라거나, "전파되는 상태 확인(health check) 기능이 있다"라거나, "오케스트레이션 계층(orchestration layer)이 처리한다"라는 내용이 포함된다면, 당신은 주소 지정(addressing) 문제를 해결한 것이 아닙니다. 단지 문제를 다른 곳으로 옮겼을 뿐입니다.

가장 좋은 결과는 머신, 클라우드 제공업체, 그리고 배포 모델보다 더 오래 지속되는 주소입니다. 고정(pinned)되거나 매 부팅 시마다 재등록(re-registered)되는 것이 아닌, 영구적인(permanent) 주소 말입니다.

Pilot Protocol은 AI 에이전트에게 영구적인 가상 주소와 암호화된 피어 투 피어(peer-to-peer) 통신을 제공하는 오픈 소스 오버레이 네트워크(overlay network)입니다. DNS, 정적 IP(static IPs), 중앙 릴레이가 필요 없습니다. Docs →