만약 여러분이 서비스 메시 (Service Mesh)를 위한 Consul과 Overlay Network 사이에서 고민 중이라면, 결정적인 요인은 기능 체크리스트나 벤치마크 표가 아닙니다. 그것은 바로 하나의 가설입니다. 바로 여러분의 워크로드 (Workload)가 안정적인 네트워크 위치를 가진 곳에 거주하는 장기 실행 서비스 (Long-lived services)라는 가설입니다. 이 가설이 성립할 때, Consul과 같은 서비스 메시 (Service Mesh)는 진정으로 좋은 해답이 됩니다. 하지만 이 가설이 성립하지 않을 때 — 예를 들어 특정 작업을 위해 생성되었다가 새로운 IP로 재시작되고, 홈 라우터 뒤에 위치하는 자율 에이전트 (Autonomous agents)와 같은 경우 — Overlay Network 모델이 유일하게 적합한 모델처럼 보이기 시작합니다.

서비스 메시를 위한 Consul vs Overlay Network: 두 가지 서로 다른 문제

이것을 두 제품 간의 정면 대결로 취급하고 싶은 유혹이 들 수 있습니다. 하지만 그렇지 않습니다. 이들은 동일한 문제의 서로 다른 계층 (Layer)을 해결하며, 두 계층 모두 중요합니다.

Consul은 컨트롤 플레인 (Control plane)입니다. Consul은 서비스 디스커버리 (Service discovery, DNS 및 HTTP API), 상태 확인 (Health checking), KV 스토어 (KV store), 그리고 Consul Connect를 통한 서비스 메시 (Service mesh) 기능을 제공합니다. 여기에는 서비스 간 mTLS (mutual TLS), 서비스 인텐션 (Service intentions)을 통한 권한 부여, 그리고 암호화된 트래픽을 처리하는 사이드카 프록시 (Sidecar proxies, 일반적으로 Envoy)가 포함됩니다. Consul은 메시 인프라 자체(서버, 에이전트, 프록시)에 접근이 가능하고 안정적인 데이터 센터 (Datacenter) 또는 VPC 내부에서 실행되도록 구축되었습니다. 만약 하나의 클라우드에서 Nomad 또는 Kubernetes를 실행하고 있다면, Consul은 "어떤 서비스가 존재하는가, 어떤 서비스가 건강한 상태인가, 그리고 어떻게 안전하게 통신하는가?"라는 질문에 답할 수 있는 성숙하고 잘 지원되는 방법입니다.

Overlay Network는 도달 가능성 계층 (Reachability layer)입니다. 이는 하단에 어떤 물리적 네트워크가 있든 상관없이 모든 노드 (Node)에 가상 주소를 부여합니다. WireGuard 스타일의 터널, UDP 캡슐화 (Encapsulation), NAT 트래버설 (NAT traversal) 등이 이에 해당합니다. Tailscale, Nebula, Netbird, ZeroTier가 보통 언급되는 이름들입니다. Overlay는 인텐션 (Intentions)이나 요청 라우팅 (Request routing)과 같은 L7 메시 (L7 mesh) 기능을 제공하지 않습니다. 대신 분산 환경에서 더 기본적이고 더 가치 있는 것을 제공합니다. 바로 _어떤 노드든, 어디서나, 안정적인 주소를 통해 다른 어떤 노드와도 통신할 수 있다_는 점입니다.

따라서 진짜 질문은 "어느 것이 더 나은가"가 아닙니다. "당신에게 실제로 결여된 레이어(layer)는 무엇인가?"입니다. 만약 당신의 서비스들이 이미 서로에게 도달할 수 있다면, 당신에게 필요한 것은 컨트롤 플레인 (control plane)입니다. 만약 서로 도달할 수 없다면, 컨트롤 플레인은 모래 위에 세워진 것과 다름없습니다.

서비스 메시 모델이 가정하는 것

Consul을 포함한 서비스 메시 (service mesh) 모델은 당신의 환경에 대해 다음과 같은 네 가지 사항을 조용히 가정합니다:

1. 장기 실행 서비스 (Long-lived services). 서비스는 몇 달 동안 실행되는 프로세스입니다. 한 번 등록되면 수년간 발견되며, 그 정체성 (identity)은 인스턴스 (instance)가 아닌 역할 (role)에 결합됩니다.
2. 도달 가능한 레지스트리 (A reachable registry). 서비스 디스커버리 (service discovery)가 작동하는 이유는 에이전트 (agent)가 자신이 등록한 서버에 항상 도달할 수 있기 때문입니다. 컨트롤 플레인은 그것이 실행되는 네트워크만큼 신뢰할 수 있습니다.
3. 안정적인 네트워크 위치 (Stable network locations). 디스커버리 엔트리 (discovery entries)와 헬스 체크 (health checks)는 유효하게 유지되는 IP를 가정합니다. 노드 (node)가 이동하면, 무언가가 이를 감지하고 다시 등록해야 합니다.
4. 메시를 운영하는 주체 (Someone operates the mesh). 프록시 (proxy)가 배포되고, 인증서 (certificate)가 교체되며, 인텐션 (intention)이 작성되고, 서버가 업그레이드됩니다. 인간 또는 플랫폼 팀이 이 과정에 참여합니다.

데이터 센터 내부나 단일 클라우드 VPC 내에서는 이 모든 가정이 유효합니다. 이것이 바로 그곳에서 서비스 메시가 적합한 형태이며, 생태계의 많은 부분이 서비스 메시를 기반으로 구축된 이유입니다.

에이전트가 이러한 가정을 깨뜨리는 지점

AI 에이전트 (AI agents)는 이 네 가지 모두를 위반하며, 이는 특별한 방식이 아니라 에이전트 인프라를 서비스 인프라와 다르게 느껴지게 만드는 평범한 방식들로 발생합니다:

• 에이전트는 일시적입니다 (Agents are ephemeral). 에이전트는 태스크별로 생성되고, 생겼다 사라지는 컨테이너 내에서 실행되며, 작업 사이에는 휴면 상태에 들어갔다가 작업이 완료되면 해제됩니다. 수명이 짧은 프로세스를 레지스트리 (Registry)에 등록하는 것은 보상 없이 장부 정리만 하는 격입니다.
• 에이전트는 이동합니다. 코딩 에이전트는 노트북에서 실행되고, 연구 에이전트는 클라우드 VM에서 실행되며, 모니터링 에이전트는 코로케이션 (Colo)의 엣지 박스에서 실행됩니다. 동일한 논리적 에이전트가 IP와 네트워크를 끊임없이 변경합니다.
• 에이전트는 NAT 뒤에 존재합니다. 홈 라우터, 캐리어급 NAT (Carrier-grade NAT), 기업 방화벽 등이 이에 해당합니다. 에이전트에 도달할 수 있는 인바운드 포트가 없으며, 이를 열어줄 관리자도 없습니다.
• 운영자가 없습니다. 자율 에이전트는 티켓을 발행하고 사람이 사이드카 (Sidecar) 배포를 승인할 때까지 기다릴 수 없습니다. 인프라에 무엇이 필요하든 에이전트가 스스로 수행해야 하며, 그렇지 않으면 실행되지 않습니다.

이러한 상황에서 메시 (Mesh) 모델은 단순히 어색해지는 수준을 넘어, 그 핵심 가설이 뒤집힙니다. 레지스트리는 인력을 배치할 수 없는 단일 장애점 (Single point of failure)이 됩니다. 고정 IP는 신화가 됩니다. 사이드카는 그것이 감싸야 할 프로세스에 도달할 수 없기 때문에 설치할 수 없는 무언가가 됩니다.

오버레이 네트워크 (Overlay Network)가 더 적합한 경우

오버레이 네트워크는 에이전트가 필요로 하는 방식 그대로 모델을 뒤집습니다:

• 주소가 인스턴스보다 오래 지속됩니다. 각 노드는 재시작, IP 변경, 클라우드 간 이동 시에도 유지되는 영구적인 가상 주소를 소유합니다. 도달 가능성 (Reachability)은 배포 시마다 발생하는 문제가 아니라 네트워크의 속성이 됩니다.
• NAT 트래버설 (NAT traversal)이 내장되어 있습니다. STUN, 홀 펀칭 (Hole punching), 릴레이 폴백 (Relay fallback)을 통해 서로 다른 NAT 뒤에 있는 두 노드가 여전히 직접적인 암호화 터널을 구축할 수 있습니다. 인바운드 포트, 고정 IP, 방화벽 변경이 필요 없습니다.
• 신뢰는 네트워크 단위가 아닌 피어 (Peer) 단위입니다. VPN은 "접속됨 = 신뢰함"이라고 말합니다. 핸드셰이크 (Handshake) 기반의 신뢰를 사용하는 오버레이는 "멤버십과 신뢰는 별개"라고 말하며, 사용자가 각 피어를 명시적으로 승인합니다. 자율 에이전트에게 이는 단순히 접속할 수 있는 네트워크와 신뢰할 수 있는 네트워크 사이의 차이입니다.

그 마지막 지점은 들리는 것보다 훨씬 더 중요합니다. 서비스 메시 (Service Mesh)에서 신뢰는 제어 평면 (Control Plane)으로부터 옵니다. 즉, 인증 기관 (CA)이 인증서를 발급하고 프록시 (Proxy)가 이를 강제합니다. 반면 에이전트 네트워크 (Agent Network)에는 제어 평면이 없는 경우가 많습니다. 따라서 신뢰는 에이전트들 사이의 쌍방향적이고 명시적인 결정이어야 합니다.

에이전트 사례, 구체적으로

만약 당신의 "서비스"가 실제로 에이전트라면, 오버레이 (Overlay) 모델이 문제에 직접적으로 대응됩니다. 그 형태의 한 예로, 이 분야에는 Pilot Protocol이라는 오픈 소스 프로젝트가 있습니다. 이는 AI 에이전트를 위해 특별히 구축된 오버레이 네트워크입니다. 모든 에이전트는 영구적인 가상 주소, 암호화된 UDP 터널 (X25519 키 교환 및 AES-GCM 사용), 릴레이 폴백 (Relay Fallback)을 포함한 NAT 트래버설 (NAT Traversal), 그리고 발견을 위한 랑데부 레지스트리 (Rendezvous Registry)를 할당받습니다. 신뢰는 각 피어 (Peer) 간의 명시적인 핸드셰이크 (Handshake)를 통해 이루어지며, 사이드카 (Sidecar) 대신 한 번의 명령으로 로컬에 설치할 수 있는 에이전트 네이티브 도구 앱 스토어가 존재합니다. 이 프로젝트는 Go 언어로 작성되었으며, 외부 의존성이 없고, AGPL-3.0 라이선스를 따르며, 네트워크상에 243k명 이상의 에이전트와 사용자가 있습니다. 시작하는 흐름은 다음과 같습니다:

curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl handshake <peer-node> "collaborating on the migration"
pilotctl send-message <peer-node> --data 'status?'

이것이 전체 루프입니다: 설치, 핸드셰이크, 메시지 전송. 레지스트리 등록도, 사이드카도, 포트 포워딩 (Port Forwarding)도, 운영할 제어 평면도 필요 없습니다. 에이전트 자체가 주소 지정과 신뢰를 직접 수행합니다. Pilot Protocol의 문서에서 이 모델에 대해 더 자세히 설명하고 있습니다.

한 단락으로 요약하는 결정

워크로드가 안정적인 위치를 가진 장기 실행 서비스(long-lived services)이고 플랫폼을 운영하는 팀이 있다면 Consul을 유지하세요. 그것이 바로 메시(mesh) 모델의 용도이며, 매우 잘 수행합니다. 반면, 워크로드가 에이전트(agents) 형태, 즉 일시적(ephemeral)이고, 이동성이 있으며, NAT 뒤에 있고, 운영자가 개입하지 않는 구조라면 오버레이 네트워크(overlay network)를 선택하세요. 만약 두 번째 부류에 속한다면, 그 구조에 메시 모델을 억지로 끼워 맞추려 하지 마세요. 메시 모델이 기반하고 있는 가정 자체가 귀하의 워크로드가 위반하고 있는 바로 그 가정이기 때문입니다. 대신 주소 지정 계층(addressing layer)부터 시작하세요. 그리고 모든 노드가 현재 실행 중인 위치에 의존하지 않는 주소로 도달 가능한 네트워크 위에 에이전트 간 계층(agent-to-agent layer)이 놓이도록 하세요.

참조: Pilot Protocol — curl -fsSL https://pilotprotocol.network/install.sh | sh · docs at pilotprotocol.network/docs · source at github.com/pilot-protocol