방화벽 뒤에 있는 AI 에이전트를 프로덕션 환경에 배포하기 (포트를 열지 않고)

에이전트가 구축되었습니다. 테스트도 통과했습니다. 로컬(Locally)에서는 모든 것이 잘 작동합니다. 그다음에는 아무도 데모에서 보여주지 않는 부분이 등장합니다. 바로 방화벽 뒤에 있는 AI 에이전트를 프로덕션(production) 환경에 배포해야 하며, 외부의 무언가가 에이전트에 도달할 수 있어야 한다는 점입니다. 예를 들어 고객 이벤트 발생 시 실행되는 SaaS 웹훅(webhook), 스케줄러(scheduler), 또는 다른 클라우드에 있는 또 다른 에이전트 등이 이에 해당합니다.

에이전트는 준비되었습니다. 하지만 네트워크는 준비되지 않았습니다. 평소에 사용하는 모든 인바운드(inbound) 경로가 차단되어 있으며, 포트(port)를 열 수도 없는 상황입니다.

이 글은 정확히 그러한 상황을 위한 배포 가이드입니다. 프레임워크 조사나 메시 토폴로지(mesh topology)에 관한 에세이가 아닙니다. 네트워크를 노출하지 않고 외부에서 로컬 에이전트에 접근할 수 있도록 만드는 구체적인 문제에 관한 것입니다.

방화벽 뒤에 있는 AI 에이전트를 프로덕션 환경에 배포하기: 진짜 문제

에이전트 특유의 용어들을 걷어내고 보면 문제는 평범합니다. 요청을 받아야 하는 프로세스가 있지만, 인바운드 연결을 허용하지 않는 네트워크에 위치해 있다는 것입니다.

웹 서비스라면 공인 IP(public IP)와 로드 밸런서(load balancer)로 이 문제를 해결하겠지만, 에이전트는 두 가지 측면에서 이를 더 어렵게 만듭니다.

• 데이터가 있는 곳에 배포되는 경우가 많습니다 — 온프레미스(on-prem), 엄격한 이그레스 전용(egress-only) 규칙이 적용된 VPC, 또는 네트워크 사이를 이동하는 노트북 등입니다. 웹훅(webhook)을 지정할 수 있는 고정된 공인 IP가 없습니다.
• 장시간 실행되며 상태를 유지(stateful)합니다. 개발자의 세션과 함께 종료되는 터널(tunnel)은 프로덕션용이 아닙니다. 뒤에 있는 머신이 작동하지 않을 때도 주소는 안정적이어야 합니다.

따라서 요구 사항은 다음과 같습니다: 안정적인 주소 지정, 인바운드 포트 없음, 그리고 재시작, IP 변경, 클라우드 이동 시에도 생존할 수 있는 무언가가 필요합니다.

일반적인 해결책이 맞지 않는 이유

표준 도구 상자(standard toolbox)에 대해 공정하게 말하자면, 각 옵션은 특정 맥락에서는 적절합니다.

포트 포워딩 (Port forwarding). 고전적인 방식입니다. 라우터나 보안 그룹 (security group)에서 포트를 열고 이를 에이전트에 매핑합니다. 에이전트가 호스트를 이동하거나, 사무실 IP가 변경되거나, 보안 검토에서 해당 규칙을 검토하기 전까지만 유효합니다. 또한, 에이전트의 엔드포인트 (endpoint)를 인터넷에 직접 노출하는 것은 실제 공격 표면 (attack surface)이 됩니다. 에이전트는 행동하는 프로세스이며, 행동하는 표면은 프롬프트 인젝션 (prompt-injection) 연구자들이 파고드는 지점입니다.

고정 IP를 사용하는 리버스 프록시 (A reverse proxy with a static IP). 인프라를 직접 제어할 수 있다면 견고하고, 지루하며, 올바른 방법입니다. 공인 주소, TLS 종료 (TLS termination), 그리고 에이전트로 돌아가는 보안 채널을 갖춘 장비가 필요합니다. 이것은 진정한 배포 (deployment)입니다. 만약 고객의 네트워크에 에이전트 하나를 전달하는 상황이라면, 프록시까지 함께 전달하고 싶지는 않을 것입니다.

ngrok 스타일의 터널 (ngrok-style tunnels). 데모나 스테이징 (staging) 환경에는 탁월합니다. 터널 엔드포인트는 제3자이며, 주소는 변경될 수 있는 세션에 종속되어 있습니다. 수년간 안정적이어야 하는 웹훅 (webhook) 대상에게는 취약한 기반이 될 수 있지만, "작동함을 증명하는" 단계에서는 진정으로 유용한 방식입니다.

VPN. 네트워크를 연결하여 도달 가능성 (reachability) 문제를 해결하지만, 신뢰 (trust) 또한 함께 연결해 버립니다. VPN에서는 노드가 네트워크에 있으면 신뢰할 수 있는 것으로 간주됩니다. 에이전트 간 트래픽 (agent-to-agent traffic)의 경우, 종종 그 반대인 도달 가능성 및 독립적으로 결정되는 피어별 명시적 신뢰 (explicit per-peer trust)를 원하게 됩니다. (이는 오버레이 네트워크 (overlay networks)가 해결하기 위해 구축된 고전적인 "연결됨 ≠ 신뢰함"의 구분입니다.)

이 방법들이 틀린 것은 아닙니다. 단지 "알 수 없는 방화벽 뒤에 있는 하나의 에이전트를 외부에서 도달 가능하게 만든다"는 목적과는 다른 배포 형태에 맞춰져 있을 뿐입니다.

아웃바운드 전용 옵션: 오버레이 네트워크 (An Overlay Network)

진지하게 고려해 볼 만한 네 번째 형태가 있습니다. 바로 에이전트를 오버레이 네트워크의 노드로 실행하는 것입니다. 여기에서의 연결성은 아웃바운드 전용 (outbound-only) 터널을 통해 구축됩니다.

핵심 아이디어는 다음과 같습니다: 에이전트의 데몬(daemon)이 랑데부 레지스트리(rendezvous registry)로 한 번 접속하여 암호화된 UDP 터널을 구축하고, 재시작, IP 변경, 클라우드 간 이동 시에도 유지되는 **영구 가상 주소 (permanent virtual address)**를 할당받는 것입니다. 일단 이 주소를 확보하면, 다른 에이전트와 해당 에이전트에 접속해야 하는 서비스들이 직접 메시지를 보낼 수 있으며, 사용자 측에서 인바운드 포트를 열 필요가 없습니다. NAT 트래버설 (NAT traversal; STUN + hole-punching, 릴레이 폴백 포함)이 "우리 둘 다 NAT 뒤에 있는" 경우를 처리합니다.

이것이 바로 Pilot Protocol이 구현하고 있는 방식입니다. 이는 AI 에이전트를 위한 오픈 소스 오버레이 네트워크 (overlay network)로, Go 언어로 작성되었으며 외부 의존성이 없고 AGPL-3.0 라이선스를 따릅니다. 모든 에이전트는 안정적인 주소를 부여받으며, 통신은 종단간 암호화 (end-to-end encryption; X25519 키 교환, AES-GCM)됩니다.

프로덕션 배포에서 중요한 부분은 신뢰 모델 (trust model)입니다. 두 에이전트가 통신하기 전에 명시적인 핸드셰이크 (handshake) — 즉, 상호 승인 과정을 거칩니다. 도달 가능성 (reachability)과 신뢰 (trust)는 분리되어 있습니다. 메시지에 따라 동작하는 에이전트에게는 특정 피어(peer)로부터 신뢰받지 않더라도 네트워크에 의해 _도달 가능_할 수 있다는 점이 훨씬 더 나은 기본 설정입니다.

실제 배포 모습

방화벽 뒤에 있는 깨끗한 상태의 머신에서 시작하는 전체 흐름은 다음과 같습니다:

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

데몬이 시작되고 노드를 등록합니다:

pilotctl daemon start

이것이 "포트를 여는" 단계입니다. 다만 실제로 열리는 포트는 없습니다. 데몬이 아웃바운드로 접속할 뿐, 인바운드는 아무것도 열리지 않습니다. 에이전트는 가상 주소를 할당받으며, 이제 이름으로 도달 가능한 상태가 됩니다.

다른 에이전트(또는 사용자가 제어하는 서비스)는 다른 피어에 접속하는 것과 동일한 방식으로 해당 에이전트에 접속합니다:

pilotctl send-message <agent-address> --data 'task: summarize the new support tickets'

신뢰는 피어별로 명시적으로 이루어집니다:

pilotctl handshake <agent-address> "production webhook consumer"

컨슈머(consumer) 측에서 승인하면 메시지가 흐르기 시작합니다. 에이전트의 머신이 재시작되거나, 다른 클라우드로 이동하거나, 새로운 IP를 할당받더라도 주소는 동일하게 유지됩니다. 피어(peer)들은 에이전트가 물리적으로 어디에 위치하는지 신경 쓰지 않습니다.

Webhooks, 다른 에이전트, 그리고 App Store

특히 "SaaS 웹훅(webhook)이 내 에이전트에 도달해야 하는" 경우, 다음 두 가지 문서 페이지가 중요합니다:

• Webhooks — 데몬(daemon)은 데몬 이벤트에 대한 실시간 HTTP 알림을 수신할 수 있으며, 이를 통해 에이전트는 폴링 (polling) 없이도 반응형 상태를 유지할 수 있습니다.
• Gateway — IP 트래픽을 오버레이 (overlay) 네트워크로 연결해 주는 선택적인 별도 바이너리(binary)로, 이를 통해 일반적인 TCP 도구(curl, 브라우저 등 무엇이든)가 오버레이 피어에 도달할 수 있습니다. 에이전트를 호출하는 대상이 그 자체로 에이전트가 아닐 때 유용합니다.

또한 에이전트는 이제 디렉토리(directory)가 있는 네트워크의 노드(node)이므로, 단순히 수신만 하는 것이 아니라 발견 (discover)도 할 수 있습니다. 에이전트를 도달 가능하게 만드는 것과 동일한 배포 방식을 통해, 서비스 에이전트를 찾고 앱 스토어에서 기능 앱을 설치할 수도 있습니다 (pilotctl appstore catalogue, pilotctl appstore install <id>, pilotctl appstore call <id> <method> '{}'). 한 번의 설치로 에이전트는 네트워크의 툴링 (tooling)에 접근할 수 있으며, 별도로 프로비저닝 (provisioning)할 API 키도 필요하지 않습니다.

체크리스트

현재 방화벽 뒤에 에이전트를 배포하고 있다면, 다음 사항을 검토하십시오:

1. 인바운드 포트 없음. 아웃바운드 전용 연결을 선호하십시오. 누군가 방화벽 규칙을 요청한다면 그 이유를 물으십시오.
2. 안정적인 주소. 머신이 이동하더라도 웹훅 대상이 변경되어서는 안 됩니다. 영구적인 가상 주소는 계속 바뀌는 터널 URL보다 낫습니다.
3. 도달 가능성과 분리된 신뢰. 네트워크에 있다는 것이 곧 신뢰를 의미해서는 안 됩니다. 에이전트의 동작을 트리거할 수 있는 모든 것에 대해 피어별로 명시적인 승인이 필요합니다.
4. 기본적인 암호화. 에이전트 트래픽은 다른 프로덕션 트래픽과 마찬가지로 보호할 가치가 있습니다.
5. 도달 가능성은 엔드포인트가 아니라 기능입니다. 에이전트가 도달 가능해지면 피어를 발견하고, 서비스 에이전트에 쿼리(query)를 보내고, 앱을 설치할 수 있습니다. 즉, 배포 자체가 그 가치를 스스로 증명합니다.

에이전트가 가장 어려운 부분이었습니다. 마지막 단계인 — 에이전트가 도달 가능하게 만드는 것 — 은 그럴 필요가 없습니다.

본격적으로 도입하기 전에 작동 원리를 확인하고 싶다면, Pilot Protocol 문서를 통해 주소 지정 (addressing), 전송 (transport), 그리고 신뢰 모델 (trust model)을 귀하의 배포 제약 조건과 비교하여 평가할 수 있을 만큼 충분히 자세하게 살펴볼 수 있습니다. 만약 읽는 과정을 건너뛰고 직접 실행되는 것을 보고 싶다면:

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