ReAct 루프의 과제 (East-West 트래픽)

ReAct 루프는 본질적으로 AI 에이전트가 지속적으로 "생각"하고(reasoning) "행동"함으로써(acting) 복잡한 문제를 분해하는 과정입니다. 에이전트는 LLM에 질의하고, 출력을 파싱하며, 내부 도구 또는 API(RAG 데이터베이스, 계산기, 외부 서비스)를 호출하고, 결과를 평가한 뒤 다시 루프로 돌아갑니다.
이 과정은 East-West API 트래픽의 엄청난 폭발을 야기합니다.
이 트래픽은 다음과 같은 특징을 가집니다:
매우 빈번한 통신 (Highly Chatty): 사용자 프롬프트당 수백 개의 마이크로 트랜잭션이 발생합니다.
자율성 (Autonomous): 에이전트가 어떤 내부 API를 호출할지 즉석에서 결정하므로, 트래픽 패턴을 예측하기 매우 어렵습니다.
지연 시간에 민감 (Latency Sensitive): 네트워크 오버헤드의 매 밀리초가 AI의 속도에 대한 사용자의 체감 성능을 저하시킵니다.

무거운 서비스 메시(Service Mesh)와 mTLS가 부족한 이유

플랫폼 엔지니어들이 East-West 트래픽을 목격하면, 보통 Istio와 같은 무거운 서비스 메시(Service Mesh)와 상호 TLS (mTLS)를 해결책으로 제시하곤 합니다. 하지만 Agentic AI의 맥락에서 이는 심각한 마찰을 초래합니다:

• mTLS 오버헤드: 전통적인 mTLS는 공개 키 기반 구조 (PKI) 및 인증서 로테이션(certificate rotation)에 의존합니다. 동적으로 확장되는 AI 마이크로서비스 전반에서 이러한 인증서를 관리하는 것은 막대한 DevOps 오버헤드를 발생시킵니다.

• 계층적 사각지대 (The Layered Blindspot): mTLS는 Layer 4(전송 계층)에서 작동합니다. 이는 머신 A가 머신 B와 통신하고 있음을 보장하지만, 그들이 무엇을 말하고 있는지는 알지 못합니다.

• 지연 시간 세금 (The Latency Tax): 전통적인 암호화 검증의 핸드셰이크(handshake) 오버헤드는 빠르게 실행되는 ReAct 루프에 치명적입니다.

비유: AI ReAct 루프를 뛰어난 분석가 그룹 사이의 빠른 브레인스토밍 세션이라고 생각해 보십시오. 전통적인 mTLS를 사용하는 것은 그들이 다음 문장을 말하기 전에 반드시 멈춰서 운전면허증을 꺼내 보여주고 공증인이 문서에 도장을 찍게 만드는 것과 같습니다. 보안 메커니즘이 시스템의 속도를 파괴하는 것입니다.

취약점과 "과도한 에이전시(Excessive Agency)"의 위험성

취약점을 보여주는 사례가 있느냐고요? 물론입니다. LLM을 위한 OWASP Top 10은 특히 **과도한 에이전시 (Excessive Agency)**와 **안전하지 않은 출력 처리 (Insecure Output Handling)**를 강조합니다.

만약 공격자가 외부로 노출된 AI 인터페이스에 프롬프트 인젝션 (Prompt Injection) 공격을 성공적으로 수행한다면, 해당 에이전트는 악의적인 내부자로 변모합니다. 만약 내부 API가 네트워크 경계나 정적 API 토큰으로만 보호되고 있다면, 탈취된 에이전트는 측면 이동 (Lateral Movement)을 수행하거나, 민감한 RAG 데이터를 액세스하거나, 내부 도구를 통해 파괴적인 동작을 실행할 수 있습니다. 전통적인 Layer 3-5 방어 체계는 트래픽이 "신뢰할 수 있는" AI 에이전트 포드 (Pod)에서 발생한다면 그것이 정당한 것이라고 가정합니다. 이러한 방어 체계는 하이재킹된 추론 루프 (Reasoning Loop)에 대해 완전히 눈이 멀어 있습니다.

Layer 7 접근 방식

이것이 바로 우리가 Hopr.co에서 **Korvette-S 워크로드 보안 프록시 (Workload Security Proxy, WoSP)**를 구축한 정확한 이유입니다. 정적 인증서와 무거운 네트워크 계층 메시 (Mesh)에 의존하는 대신, 우리는 자동화된 이동 표적 방어 (Automated Moving Target Defense, AMTD)를 사용합니다.

동료들에게 설명할 때 저는 다음과 같이 구분하여 설명합니다:

• 트랜잭션 수준의 제로 트러스트 (Zero Trust at the Transaction Level): 우리는 **MAID™ (Machine Alias IDentity)**를 사용하여 워크로드에 암호화되고 순환되는 신원을 제공합니다. 우리는 단순히 IP나 정적 인증서를 신뢰하지 않고, 각 트랜잭션에 대해 신원을 검증합니다.

• 측면 이동 (Lateral Movement) 차단: SEE™ (Synchronous Ephemeral Encryption) 프로토콜을 사용하여, 우리의 사이드카 (Sidecar)는 상호 인증을 설정하고 즉각적으로 키를 교체합니다. 만약 AI 에이전트가 변절하더라도, 가로챈 자격 증명이나 정적 API 키를 재사용하여 다운스트림 서비스(Downstream Services)를 악용할 수 없습니다.

• 애플리케이션에 투명함 (Invisible to the Application): 우리는 WebAssembly (Wasm) 필터를 갖춘 Envoy 사이드카 아키텍처를 사용하여 이를 배포합니다. 예를 들어, 우리의 Lane7 블루프린트는 기반 애플리케이션 코드의 어떠한 변경도 요구하지 않고 Envoy 설정에 xtra-wasm-filter를 직접 주입하는 방법을 보여줍니다.

• 눈에 띄게 숨겨진 코드 (Codes Hidden In Plain Sight, CHIPS™): 우리는 Layer 7 또는 Layer 4의 페이로드 (Payload)에 이동 표적 방어를 직접 내장합니다.

Lane7 Agentic AI Blueprint를 살펴보면, 이는 애플리케이션 계층의 프로토콜 복잡성을 기반의 제로 트러스트 (Zero Trust) 보안 모델로부터 분리하는 데 있어 마스터클래스급 설계를 보여줍니다. 다음은 이 6-포드 (6-pod) 아키텍처가 어떻게 작동하며, 어떻게 원활한 프로토콜 혼합을 수행하는지에 대한 상세 분석입니다:

6-포드 파이프라인 아키텍처 (The 6-Pod Pipeline Architecture)

이 블루프린트는 전형적인 스캐터-게더 (scatter-gather, fan-out/fan-in) ReAct 파이프라인을 제시하지만, 모든 내부 홉 (hop)에 걸쳐 Hopr의 자동 이동 표적 방어 (Automated Moving Target Defense, AMTD)를 적용하여 보안을 강화했습니다. 메시지 흐름은 각 단계를 통해 깔끔하게 이동합니다:

• 진입/라우팅 단계 (The Entry/Routing Phase): 트래픽이 경계 진입점인 ai-gateway에 도달하면, 페이로드 (payload)를 검증한 후 ai-orchestrator로 전달합니다. 오케스트레이터는 MCP 스타일의 작업 디스패처 (task dispatcher) 역할을 수행하며, 두 개의 병렬 처리 브랜치로 작업을 브로드캐스트 (broadcast) 합니다.

• 추론/액션 단계 (The Inference/Action Phase): 페이로드는 llm-gateway (LLM 추론 SDK 호출을 처리)와 tool-executor (웹 검색 또는 DB 조회와 같은 에이전틱 도구 (agentic tools)를 디스패치)에 의해 동시에 처리됩니다.

• 집계/출구 단계 (The Aggregation/Exit Phase): nlp-processor는 팬인 (fan-in) 애그리게이터 (aggregator) 역할을 하며, LLM 브랜치와 도구 브랜치가 모두 완료될 때까지 기다린 후 결과를 병합합니다. 마지막으로, 통합된 페이로드를 경계 출구 역할을 하는 ai-results-sink로 전송합니다.

이기종 프로토콜 설계 (The Heterogeneous Protocol Design)

네트워킹 관점에서 이 블루프린트가 탁월한 이유는 현대적인 AI 워크로드의 현실, 즉 모든 것이 상태가 없는 (stateless) HTTP일 필요는 없다는 점을 처리하는 방식에 있습니다. 이 아키텍처는 포드 경계 전반에 걸쳐 의도적으로 **이기종 프로토콜 (heterogeneous protocols)**을 사용합니다.

AI 파이프라인 구간의 특정 요구 사항에 따라 프로토콜을 다음과 같이 분리합니다:

• 경계 및 상태 라우팅을 위한 HTTP (HTTP for Boundaries and State Routing): 표준 HTTP는 ai-gateway, ai-orchestrator, nlp-processor, 그리고 ai-results-sink에 사용됩니다. 이는 경계 진입(boundary entry), 팬아웃 디스패치(fan-out dispatch), 팬인 집계(fan-in aggregation), 그리고 경계 탈출(boundary exit)과 같이 표준 요청/응답 프레이밍(request/response framing)이 최적인 구간에서 매우 합리적인 선택입니다.

• 스트리밍 추론 구간을 위한 WebSocket (WebSocket for Streaming Inference Legs): 설계도(blueprint)는 llm-gateway와 tool-executor를 위해 지속적인 WebSocket 세션으로 전환합니다. 프로덕션 환경에서 LLM 추론과 에이전트 도구 호출(agentic tool-calls)은 실시간 스트리밍 응답을 필요로 하므로, 지속적인 WebSocket 연결이 이 작업에 적합한 도구가 됩니다.

어떻게 매끄럽게 혼합되는가 (Envoy/Wasm의 마법)

YAML
schema_version: "2.0"
network:
...

보통 서비스 메쉬(service mesh) 내부에서 HTTP와 WebSocket을 혼합하려면 복잡하고 취약한 L7 라우팅 규칙이 필요합니다. Lane7 설계도는 보안 수준을 Layer 4로 낮춤으로써 이를 매끄럽게 처리합니다.

내부적으로 다음과 같은 일이 일어납니다:

• 순수 L4 터널링 (Pure L4 Tunneling): Envoy 설정에서 Hopr의 xtra4.wasm 필터가 envoy.tcp_proxy 바로 앞에 위치합니다. 이는 순수한 Layer 4 지속 TCP 터널을 형성합니다.

• 프로토콜 투명성 (Protocol Transparency): 보안(CHIPS™ 페이로드 임베딩, SEE™ 암호화, MAID™ 로테이션)이 TCP 바이트 스트림(byte stream) 수준에서 이루어지기 때문에, 프로토콜 프레이밍(protocol framing)은 완전히 투명합니다. HTTP 프레이밍, WebSocket 프레임, 그리고 gRPC HTTP/2 프레임 모두 보안 계층을 동일하게 통과합니다.

• 스마트 이그레스 설정 (Smart Egress Configuration): 송신 포드(sending pod)의 이그레스(egress) Envoy 리스너는 수신 포드(receiving pod)가 기대하는 인그레스(ingress) 프로토콜이 무엇이든 그에 맞춰 통신하도록 자동으로 구성됩니다.

DevOps 엔지니어로서 우리는 스트리밍 LLM 추론 (streaming LLM inference)을 경직된 HTTP 요청/응답 사이클 (request/response cycle)을 통해 강제로 처리하려고 할 때, 엄청난 지연 시간 (latency)과 타임아웃 (timeout) 문제가 발생한다는 것을 알고 있습니다. 300초의 유휴 타임아웃 (idle timeout)을 가진 L4 TCP 프록시 (proxy)를 활용함으로써, 이 아키텍처는 WoSP 터널을 활성 상태로 유지하고, 애플리케이션 코드가 가장 적합한 프로토콜을 사용하여 localhost와 네이티브하게 통신할 수 있게 하며, 클러스터 전체를 기본적으로 보안 상태로 유지합니다.

이제 AI 인프라에서 가장 중요한 문제인 네트워크 가로채기를 통한 프롬프트 인젝션 (Prompt Injection)에 대해 이야기해 보겠습니다.

업계의 대부분은 프롬프트 인젝션을 사용자가 채팅 UI에 악의적인 프롬프트를 입력하는 것과 같은 외부의, 정문(front-door) 문제로 이야기합니다. 하지만 플랫폼 엔지니어 (Platform Engineers)로서 우리는 침해 (breach)가 발생했다는 가정하에 운영해야 합니다. 만약 공격자가 클러스터 내의 낮은 등급의 서비스를 장악한다면, 그들은 동서향 트래픽 (East-West traffic)을 스니핑 (sniffing)하여 측면 이동 (move laterally)을 시도할 것입니다. 정적 API 토큰 (static API tokens)이나 장기 유지되는 mTLS 인증서로 보호되는 전통적인 서비스 메시 (service mesh) 환경에서는, 공격자가 유효한 자격 증명을 단순히 가로채서 재전송(replay)하고, 내부의 llm-gateway나 tool-executor에 악의적인 프롬프트를 직접 주입할 수 있습니다. 갑자기 공격자가 내부 에이전트 (agents)에 대한 자율적인 제어권을 갖게 되는 것입니다. Lane7 Agentic AI 아키텍처가 이러한 킬 체인 (kill chain)을 어떻게 완전히 끊어내는지 설명하겠습니다.

AMTD를 통한 네트워크 수준의 프롬프트 인젝션 방어
6-포드 블루프린트 (6-pod blueprint)는 Hopr의 자동 이동 표적 방어 (Automated Moving Target Defense, AMTD)를 사용하여 모든 포드 간 통신을 보호합니다. 정적 ID (static identities)에 의존하는 대신, AMTD 엔진은 암호화된 ID (cryptographic identities)를 매우 빈번하게(설정 가능) 교체합니다.
이것이 공격자의 기회 창 (window of opportunity)에 어떤 영향을 미치는지 생각해 보십시오:

• 가로채기 (The Interception): 공격자가 ai-orchestrator와 llm-gateway 사이의 가공되지 않은 TCP 스트림 (raw TCP stream)을 스니핑(sniff)하는 데 성공합니다.

• 추출 (The Extraction): 공격자가 세션 식별자 (session identity) 또는 자격 증명 (credential)을 추출합니다.

• 피벗 (The Pivot): 공격자가 악의적인 프롬프트 인젝션 (Prompt Injection) 페이로드를 제작하고 탈취한 자격 증명을 재전송 (replay)하려고 시도합니다.

• 차단 (The Block): 암호화된 식별자 (cryptographic identities)가 매우 빈번하게 교체되기 때문에, 가로챈 자격 증명은 거의 즉시 완전히 쓸모없게 됩니다. Hopr WoSP는 위조된 요청을 즉시 드롭 (drop)합니다.

L7 계층 (Layer 7)에서 공격 표면 (attack surface)을 지속적으로 변화시킴으로써, 우리는 공격자가 탈취한 자격 증명을 무기화하는 데 필요한 시간을 박탈합니다.

블루프린트 (Blueprints)의 진정한 목표: 속도와 단순성

Cloud Native AMTD 보안 모델이 믿을 수 없을 정도로 강력하긴 하지만, 동료 DevOps 엔지니어로서 솔직히 말씀드리자면, 우리가 Lane7 블루프린트를 구축하는 주된 이유는 단지 보안 때문만은 아닙니다. 그것은 바로 **개발 속도 (developer velocity)와 운영의 단순성 (operational simplicity)**에 관한 것입니다.

제로 트러스트 (Zero Trust) 애플리케이션 네트워크를 처음부터 구축하는 것은 보통 막대한 관리 비용 (administrative tax)을 요구합니다. 인증 기관 (Certificate Authority, CA)을 구축해야 하고, 복잡한 공개 키 기반 구조 (Public Key Infrastructure, PKI)를 관리해야 하며, Istio 가상 서비스 (virtual services) 및 사이드카 주입 (sidecar injections)을 위해 수천 줄의 취약한 YAML 코드를 작성해야 합니다.

Lane7 블루프린트는 이러한 오버헤드 (overhead)를 완전히 제거합니다. 이것이 여러분의 CI/CD 파이프라인에 중요한 이유는 다음과 같습니다:

• PKI 오버헤드 없음 (No PKI Overhead): 이 블루프린트는 어떠한 종류의 인증서, CA(인증 기관), 또는 PKI (공개키 기반 구조)도 필요하지 않은 제로 트러스트 (Zero Trust) 파이프라인을 구현합니다.

• 애플리케이션 코드의 깔끔함 유지 (Application Code Stays Clean): 개발자는 localhost와 네이티브하게 통신하도록 코드를 작성합니다. WoSP 사이드카 (sidecar)가 모든 보안 전송 및 크로스 클러스터 라우팅 (cross-cluster routing)을 투명하게 처리하므로, 제로 트러스트를 달성하기 위해 애플리케이션 코드를 변경할 필요가 없습니다.

• 즉시 배포 (Instant Deployment): 이 블루프린트는 사전 검증된 "강철 프레임 (steel frame)"을 제공합니다. 여러분은 단순히 app.py 스텁 (stub)에 커스텀 LLM 로직을 주입하고, 이미지를 빌드한 뒤, 단일 bash deploy.sh 스크립트를 실행하여 전체 6-포드 (6-pod) 아키텍처를 구동하기만 하면 됩니다.

시작하기 위한 단계는 다음과 같습니다.

1. 선택 및 다운로드: 저희 Blueprint Catalog에서 Lane7 블루프린트를 무료로 선택하여 다운로드하세요.
   몇 분 안에 블루프린트 .zip 번들과 30일 무료 체험 라이선스를 받게 됩니다.

2. 번들 압축 해제: 압축을 풀고 README를 따르세요.
   라이선스와 자격 증명 (credentials)은 각 포드의 02-secrets.yaml에 포함되어 있습니다.
   Kubernetes 매니페스트 (manifests)는 사전 구성되어 있어 추가 설정이 필요하지 않습니다.

3. 클러스터 생성: 로컬 Kubernetes 환경에서 클러스터를 생성하거나(또는 기존 클러스터 사용) 하세요.

4. Docker 이미지 생성: 각 포드의 각 app.py에 대한 Docker 이미지를 생성하고 (블루프린트에 Dockerfile 포함됨), 해당 이미지를 클러스터에 삽입하세요.

5. 배포: 단일 명령 deploy.sh로 앱 네트워크를 배포하세요.
   README에 따라 포드 배포를 모니터링하세요.

6. 애플리케이션 커스텀: 각 포드의 애플리케이션을 커스텀하세요. 여러분의 비즈니스 로직을 쉽게 추가할 수 있도록 설계되었습니다. 섹션 1만 편집하면 됩니다.

평균적인 DevOps 엔지니어라면 약 15분 만에 배포를 완료할 수 있습니다.

왜 Lane 7인가

우리는 플랫폼 엔지니어링 (Platform Engineering) 팀이 빠른 배포와 보안 유지 사이에서 하나를 선택해야만 하는 상황을 방지하기 위해 이러한 블루프린트 (blueprints)를 설계했습니다. 또한, AMTD를 배포 가능한 템플릿 (template)에 내장함으로써, 복잡한 멀티 에이전트 (multi-agent) AI 네트워크의 출시를 가속화하는 동시에, 측면 이동 (lateral movement) 및 네트워크 수준의 프롬프트 인젝션 (prompt injection)으로부터 해당 네트워크를 면역화할 수 있습니다.