페이로드 내 정책: AI 에이전트 아키텍처 준비

AI 에이전트는 애플리케이션이 인프라와 상호 작용하는 방식을 바꾸고 있습니다. 기존 시스템과 달리 에이전트는 각 요청에 무엇을 해야 하는지, 어떻게 복구할지, 성공의 기준은 무엇인지에 관한 자체 목표와 컨텍스트, 의사 결정 로직을 담습니다. 이러한 변화는 트래픽 관리에 대한 오랜 전제를 무너뜨리고 엔터프라이즈 인프라를 재고하도록 요구합니다. 요청별 자율성이 보편화된 환경에서는 정적 라우팅, 공유 리소스, 중앙 집중식 정책만으로는 더 이상 충분하지 않습니다.

에이전트 아키텍처에서는 인프라가 사후 대응식 실행에서 벗어나 내재된 의도를 실시간으로 해석하는 방향으로 발전해야 합니다. 이러한 변화를 인식하는 기업은 기존 투자를 폐기하는 대신 이를 조정하여 미래에 대비할 수 있습니다.

소개

AI 에이전트는 단순한 지능형 애플리케이션이 아닙니다. 이는 애플리케이션이 작동하고, 의사결정을 내리고, 적응하는 방식의 구조적 변화를 의미합니다. 기존 시스템과 달리 에이전트는 트래픽 정책에 단순히 대응하는 데 그치지 않고 자체 정책을 적용합니다. 에이전트가 보내는 각 요청에는 데이터뿐만 아니라 무엇이 일어나야 하는지, 대체 동작은 어떻게 이루어져야 하는지, 성공의 기준은 무엇인지에 관한 내재된 로직도 포함됩니다.

이러한 변화로 의사 결정의 주체가 정적인 제어 플레인에서 런타임 자체로 이동합니다. 그 결과 오랫동안 유지되어 온 제어 플레인과 데이터 플레인의 경계가 허물어지고, 로드 밸런서, 게이트웨이, 프록시와 같은 트래픽 인프라는 사전 구성된 경로를 수동적으로 실행하는 대신 요청별 정책을 해석해야 합니다.

이 백서에서는 상태 확인과 폴백 로직부터 관측 가능성 및 보안 정책 적용에 이르기까지, 에이전트 아키텍처가 트래픽 엔지니어링의 핵심 전제를 어떻게 무너뜨리는지 살펴봅니다. 또한 요청별 의도가 중요해진 환경에서 정적 풀이나 평균 기반 상태 지표와 같은 기존 방식이 더 이상 충분하지 않은 이유를 설명합니다. 아울러 레이어 7 인프라가 진화하지 않으면 안정적이지만 전략적으로는 존재감이 없는 범용 배관으로 전락할 수 있다고 주장합니다. 이에 대응하려면 조직은 트래픽 스택을 재고해 런타임에 프로그래밍할 수 있고, 컨텍스트를 인식하며, Model Context Protocol(MCP)과 같은 에이전트 네이티브 프로토콜에 부합하도록 만들어야 합니다. 여기에는 폴백 로직 재설계, 시맨틱 관측 가능성 도입, 에이전트가 생성한 정책의 적용 지원이 포함됩니다. 실시간 데이터 레이블링과 같은 새로운 도구는 이러한 전환을 뒷받침하는 데 핵심적인 역할을 합니다.

요컨대, 트래픽 관리의 미래는 단순히 패킷을 전달하는 데 그치지 않고 목적을 실행하는 데 있습니다.

에이전트 아키텍처: 주요 특징

에이전트 아키텍처는 에이전트라고 불리는 자율적인 생성형 AI 기반 구성 요소가 목표 지향적 작업을 수행하고, 실시간으로 의사 결정을 내리며, 실행 방식을 즉석에서 조정하는 데 필요한 컨텍스트를 유지하는 새로운 운영 모델을 제시합니다. 이러한 에이전트는 오늘날의 서비스 체이닝과 매우 유사하게 작동하지만, 사전 구성된 워크플로에 의존하지 않습니다. 대신 목표, 환경 상태 및 관찰된 결과를 바탕으로 런타임에 적절한 실행 흐름을 결정합니다.

이러한 변화는 사전에 정의된 워크플로를 중앙에서 오케스트레이션하는 기존 시스템에서 벗어나, 실시간으로 실행 경로를 구성할 수 있는 분산형 동적 시스템으로 전환하는 것을 의미합니다. 정적인 마이크로서비스 체인의 예측 가능성은 실시간 데이터와 의도를 기반으로 유연하고 민첩하게 대응하는 의사 결정으로 대체됩니다.

에이전트 기반 시스템은 다음과 같은 특징으로 정의됩니다:

• 목표 중심 실행: 에이전트는 정적인 워크플로가 아니라 프롬프트나 임무에 따라 행동합니다. 목표 달성 여부에 따라 API를 선택하고, 매개변수를 수정하며, 경로를 변경합니다. 예: ‘고객 불만 해결’을 처리하는 에이전트는 이전 결과에 따라 결제, 계정 및 메시징 API를 각기 다르게 호출할 수 있습니다.
• 이식 가능한 컨텍스트: 에이전트는 자체 메모리, 상태, 정책을 유지합니다. 모델 컨텍스트 프로토콜(MCP) 또는 구조화된 메타데이터를 통해 이 컨텍스트를 각 요청에 포함합니다.
• 런타임 적응: 에이전트는 인프라가 결정할 때까지 기다리는 대신, 재시도, 경로 재지정, 에스컬레이션 또는 실행 경로 조정 등을 실시간으로 수행하며 즉각 대응합니다.
• 내재된 관찰 가능성: 모든 작업에는 자체 설명이 포함됩니다. 에이전트는 특정 경로를 선택한 이유, 평가한 항목, 목표 달성 여부를 보고할 수 있습니다. 이는 단순한 로그와 메트릭이 아니라 행동으로서의 관찰 가능성입니다.

이러한 요소들이 함께 작용하면서 애플리케이션 환경은 예측 가능한 형태에서 적응하며 진화하는 형태로 전환됩니다.

기존 트래픽 관리에 미치는 영향

현재의 트래픽 관리 시스템은 명확한 경계를 기반으로 구축되어 있습니다:

• The 제어 플레인은 유효한 엔드포인트, 우선할 경로, 적용할 정책 등 의도한 바를 정의합니다.
• The 데이터 플레인은 결정을 실행합니다. 즉, 요청을 라우팅하고 보안을 적용하며 부하를 분산합니다.

이 모델은 수십 년 동안, 특히 서비스 지향 아키텍처와 마이크로서비스 환경에서 효과적으로 작동해 왔습니다. 이 모델은 트래픽 흐름을 사전에 모델링할 수 있고 워크로드가 예측 가능한 패턴을 따른다고 가정합니다.

예시:

• 로드 밸런서는 /api/login 요청을 한 풀로, /api/images 요청을 다른 풀로 라우팅합니다.
• 상태 확인을 통해 노드를 사용 가능 또는 중단 상태로 표시합니다.
• 정적 임계값에 따라 장애 조치 조건이 결정됩니다.

이러한 시스템은 다음에 의존합니다:

• 정책 및 구성을 정적 리소스에 긴밀하게 결합(예: 특정 풀 및 멤버)
• 정적 구성 요소(예: 풀 및 멤버)
• 결정론적 라우팅(경로, 헤더 또는 프로토콜 기반)
• 중앙 집중식 오케스트레이션을 통한 서비스 검색, 상태 확인 및 장애 조치 로직

하지만 에이전트 기반 시스템은 이러한 가정을 무너뜨리는 유동성, 자율성, 자기 주도적 논리를 도입합니다.

에이전트 아키텍처에서는 제어 플레인과 데이터 플레인 간의 전통적인 경계가 허물어지기 시작합니다. 에이전트는 단순히 요청을 실행하는 데 그치지 않고, 요청의 정의, 대체 경로를 사용해야 하는 조건, 성공을 측정하는 방법, 나아가 선호 경로까지 결정하는 로직을 내장합니다. 이는 전통적으로 제어 플레인에서 다루던 사안이지만, 에이전트는 이러한 로직을 요청 자체와 함께 데이터 플레인을 통과하는 헤더, 토큰 또는 메타데이터에 인코딩합니다.

이러한 융합은 데이터 플레인이 더 이상 중앙에서 내린 결정을 수동적으로 실행하는 역할에 머물 수 없음을 의미합니다. 이제 데이터 플레인은 정책을 실시간으로 능동적으로 해석해야 합니다. 요청은 더 이상 단순한 패킷이 아니라 정책을 담은 산출물입니다. 따라서 로드 밸런서, 게이트웨이, 라우팅 계층은 사후 대응형 구성 요소에서 에이전트가 전달하는 의도를 실시간으로 해석하는 구성 요소로 진화해야 합니다.

이러한 변화는 제어 플레인이 정적이고 중앙 집중적이라는 핵심 아키텍처 가정을 무너뜨립니다. 대신 의사 결정 로직은 분산되고 이식 가능하며 개인화된 형태로 각 요청과 함께 전달되어 런타임에 실행됩니다. 이는 단순히 배포 방식의 변화가 아니라, 의사 결정이 이루어지는 위치와 방식의 변화입니다.

이는 Kubernetes가 네트워킹, 스토리지, 심지어 L4 트래픽 라우팅까지 기반 인프라를 추상화하고, 이 모든 것을 선언적 제어 인터페이스 뒤의 "배관"으로 만들면서 시작한 작업을 사실상 완성합니다. Kubernetes는 이러한 계층을 없애지는 않았지만 부차적인 위치로 격하시켰습니다. 그 결과 이 계층들은 보이지 않게 자동화되어 새로운 의도 기반 시스템에 종속되었습니다.

에이전트 아키텍처도 같은 역할을 하지만, 인프라뿐만 아니라 전체 스택을 대상으로 합니다.

트래픽 관리에 대한 중대한 장애

이러한 중단 상황을 실제 사례를 통해 구체적으로 살펴보기 위해 로컬 애플리케이션 전송 시나리오를 생각해 보겠습니다:

예: 한 지역 전자상거래 사이트에서는 ADC를 사용하여 내부 API 트래픽을 관리합니다. 주문 처리 속도를 최적화하는 임무를 맡은 AI 에이전트는 특정 API 엔드포인트(예: /api/inventory/check)에서 요청 복잡성 증가와 백엔드 데이터베이스 경합으로 인해 성능이 저하되고 있음을 파악합니다. "가장 빠른 응답"을 비롯한 기존 로드 밸런싱 알고리즘은 특정 풀 멤버의 모든 응답을 일반화한 평균으로 성능을 계산할 뿐, 작업별 또는 호출별로 계산하지 않기 때문에 이러한 성능 저하의 미묘한 차이를 포착하지 못합니다.

SLA를 충족하기 위해 에이전트는 이러한 재고 확인 요청을 트랜잭션 쿼리에 최적화된 대체 노드 그룹으로 재라우팅합니다. 이를 위해 각 요청에 다음과 같은 컨텍스트 헤더를 태그합니다. X-Task-Profile: inventory-sensitive. 로드 밸런서가 올바르게 구성되어 있다면 이를 해석해 트래픽을 적절히 전달할 수 있습니다. 그러나 이러한 노드는 /api/inventory와 연결된 정적 풀에 미리 할당되어 있지 않으므로, 트래픽 스티어링 서비스는 에이전트가 전달한 지시를 준수하고 정적 구성에 의존하지 않으면서 라우팅을 동적으로 결정할 수 있어야 합니다.

이 시나리오는 풀과 같은 정적 구조의 한계를 보여 주며, 컨텍스트를 인식하고 동적으로 프로그래밍할 수 있는 트래픽 처리의 필요성을 강조합니다.

에이전트 기반 시스템은 트래픽 엔지니어링의 몇 가지 기본 전제를 무너뜨립니다:

제어/데이터 플레인의 융합: 과거에는 정적 규칙에 따라 라우팅이 결정되었지만, 이제는 요청 자체가 라우팅을 결정합니다. 이로 인해 기존의 적용 로직이 무력화됩니다.

의도 기반 라우팅: 에이전트는 단순히 엔드포인트가 아니라 목표에 따라 트래픽을 라우팅합니다. /api/process와 같은 단일 엔드포인트가 에이전트의 지시에 따라 수백 가지의 서로 다른 작업 흐름을 처리할 수도 있습니다.

정적 풀의 시대는 끝납니다: 기존 풀은 역할이 고정되어 있다고 가정합니다. 하지만 에이전트는 어떤 순간에는 GPU 액세스가 필요하고 다음 순간에는 CPU 최적화가 필요할 수 있어, 고정된 풀 구성원 자격으로는 유연하게 대응하기 어렵습니다.

대체 경로와 장애 조치가 전략적으로 바뀝니다: 과거의 장애 조치는 “다음 서버를 시도한다”는 의미였습니다. 이제 에이전트는 실시간 성능과 과거 결과를 평가하고, 어떻게 진행할지 전략적으로 결정합니다.

트래픽 패턴은 반복되는 것이 아니라 새롭게 나타납니다: 에이전트는 필요에 따라 워크플로를 생성합니다. 모든 경로를 미리 정의할 수는 없으며, 필요에 따라 형성됩니다.

이러한 변화로 인해 로드 밸런서, 게이트웨이, 옵저버빌리티 스택은 유동적인 실시간 트래픽 로직에 민첩하게 대응해야 합니다.

상태 및 성능 지표 재고

상태 및 성능 지표는 언제나 트래픽 관리의 기반이었습니다. 부하 분산 여부를 결정하려면 서버를 사용할 수 있는지, 응답 속도가 얼마나 빠른지, 부하가 얼마나 많이 걸려 있는지를 파악해야 합니다. 하지만 에이전트 기반 시스템에서 상태는 단순히 정상과 비정상으로 나뉘지 않으며, 성능도 광범위한 범주를 기준으로 평균을 낼 수 없습니다. 지표에는 단순히 대상이 가동 중인지 여부가 아니라, 대상이 특정 작업에 적합한지 여부가 반영되어야 합니다.

중요한 이유: 상태 지표는 트래픽 라우팅, 장애 조치 결정, 성능 최적화에 직접적인 영향을 미칩니다. 에이전트 네이티브 환경에서는 요청마다 의도가 다르며, 서로 다른 경로나 응답 보장이 필요할 수 있습니다. 기존 방식으로는 다음과 같은 이유로 이러한 요구를 충족할 수 없습니다:

• 이들은 피상적인 집계 지표에 의존하며(예: 평균 응답 시간), 이로 인해 작업별 편차가 드러나지 않습니다.
• 이들은 서버 관점에서만 상태를 평가하며, 에이전트 수준의 성공 여부나 만족도는 파악하지 못합니다.
• 이들은 트래픽의 동질성을 전제로 하지만, 런타임 의사 결정에 따라 요청이 달라지는 경우에는 이러한 전제가 성립하지 않습니다.

예: API 서버 풀의 모든 서버가 상태 확인상 "정상"일 수 있지만, 그중 하나는 X-Task-Profile: inventory-sensitive 쿼리에 대해 지속적으로 100ms 이내에 응답하지 못할 수 있습니다. 이 지연 시간 프로필을 기대하는 에이전트는 인프라가 정상으로 판단하더라도 이를 장애로 인식합니다.

필요한 사항:

• 의도와 관찰된 결과를 반영하는 요청별 실시간 텔레메트리.
• 노드가 다른 작업에서는 정상 상태이더라도 일부 작업에서는 성능이 저하되었음을 인식하는 작업별 상태 점수 평가.
• 에이전트가 보고한 성공 또는 실패를 라우팅 및 우선순위 지정 로직에 반영하는 피드백 루프.

데이터 라벨링 도구는 전송 중인 트래픽에 라벨을 지정하고 성능 및 맥락과의 부합 여부를 포착함으로써 여기서 핵심적인 역할을 할 수 있습니다. 이를 통해 시스템은 단순히 무슨 일이 일어났는지뿐만 아니라, 그 일이 이를 시작한 주체의 목표를 달성했는지까지 판단할 수 있습니다.

에이전트 아키텍처의 폴백, 서킷 브레이커 및 재시도 기능

기존 인프라에서는 재시도, 백업 노드로의 리디렉션, 서킷 브레이커 작동과 같은 폴백 동작이 인프라 계층에서 구현됩니다. 로드 밸런서, 프록시, 게이트웨이는 사전 정의된 임계값(예: 시간 초과, 오류 비율)을 사용하여 대상에 대한 트래픽 라우팅을 중단하고 대체 대상으로 전환할 시점을 결정합니다.

에이전트 아키텍처는 이러한 논리를 뒤집습니다.

에이전트는 자체적인 대체 전략을 갖추고 있습니다. 요청 자체에 재시도 정책, 에스컬레이션 로직, 목표 중심의 우선순위를 포함합니다. 이로 인해 복잡성이 증가하고 인프라 수준의 장애 조치 메커니즘과 충돌할 가능성이 생깁니다.

중요한 이유:

• 인프라는 장애를 복구 가능한 것으로 판단하는 반면, 에이전트는 이를 허용할 수 없는 것으로 판단할 수 있습니다(또는 그 반대일 수도 있습니다).
• 에이전트와 인프라가 동시에 대체 동작을 시도하여 불필요한 재시도, 지연 시간 증가 또는 트래픽 루프가 발생할 수 있습니다.
• 평균적인 트래픽을 기준으로 설계된 서킷 브레이커는 에이전트가 여전히 최적이라고 판단하는 서비스에 대한 접근을 차단할 수 있습니다.

주요 위험:

• 이중 폴백: 에이전트와 인프라가 모두 재시도하여 불필요한 부하가 발생합니다.
• 경쟁 상태: 시스템이 몇 밀리초 내에 문제를 해결할 수 있었음에도 에이전트가 더 비싸거나 보안성이 낮은 옵션으로 전환합니다.
• 결정론적 장애 조치의 무력화: 정적 정책으로는 에이전트의 미묘한 판단 차이를 수용할 수 없습니다.
• 손상: 에이전트 메타데이터의 형식이 잘못되었거나, 누락되었거나, 읽을 수 없습니다.

적응 지침:

• 인프라는 에이전트가 지정한 대체 처리 우선순위를 인식할 수 있도록 발전해야 합니다(예: X-Fallback-Order, X-Timeout-Preference 사용).
• 서킷 브레이커는 전역 임계값 대신 작업별 또는 에이전트별 로직을 지원할 수 있도록 의도를 인식하게 만들어야 합니다.
• 에이전트가 선호하는 전략을 제안하고 게이트웨이가 시스템 상태, 부하 및 정책을 바탕으로 조정하는 협상 인식형 장애 조치 로직의 도입을 고려하세요.
• 트래픽 시스템은 에이전트 메타데이터가 없거나 불완전하거나 스키마 검증에 실패하는 경우에도 기본 실행 로직을 지원하여 서비스가 원활하게 축소 운영되도록 해야 합니다.
• 인프라는 시스템 성능 저하 시 루프를 유발하거나 트래픽을 증폭시킬 수 있는 재귀적 위임 또는 에이전트 간 상충하는 재시도를 감지하고 방지해야 합니다.

예시: 실시간 사기 탐지를 수행하는 에이전트가 50ms 이내의 응답을 요청합니다. 이 에이전트의 대체 로직은 느린 전체 쿼리보다 캐시된 부분 결과를 우선합니다. 이를 인지하지 못한 인프라는 여전히 전체 서비스 백엔드로 요청을 라우팅하여 사용자가 체감하는 지연을 초래할 수 있습니다. 보다 협력적인 모델이라면 에이전트의 대체 처리 우선순위를 존중하여 더 빠른 성능 저하 응답을 제공할 것입니다.

의사 결정이 스택의 상위 계층으로 이동함에 따라 대체 전략도 그에 맞춰 상위 계층으로 이동해야 합니다. 서킷 브레이커와 재시도 로직은 정적이거나 불투명한 상태로 남아 있어서는 안 되며, 시스템 전반의 안전성과 공정성을 유지하면서 에이전트가 명시한 선호도에 맞게 조정되어야 합니다.

고가용성과 장애 조치는 여전히 중요합니다

에이전트 아키텍처가 의사 결정과 조정을 요청 계층으로 옮기더라도, 핵심 시스템의 안정성을 보장하는 책임은 여전히 기반 인프라에 있습니다. 따라서 인프라 계층의 고가용성(HA) 및 장애 조치 메커니즘은 여전히 필수적입니다. 실제로 시스템이 더욱 동적이고 자율적으로 작동할수록 이러한 메커니즘의 중요성은 더욱 커집니다.

에이전트는 목표와 컨텍스트에 따라 트래픽을 전달할 수 있지만, 문제가 발생했을 때도 서비스의 접근성과 복원력을 유지하려면 여전히 네트워크에 의존해야 합니다. 로드 밸런서는 에이전트의 대체 전략과 관계없이 접근할 수 없는 노드, 장애가 발생한 서비스 또는 성능이 저하된 환경을 감지하고 실시간으로 트래픽 경로를 변경해야 합니다.

변하지 않는 핵심 역할:

• 풀 멤버 및 백엔드 서비스 상태 모니터링
• 네트워크 파티션 또는 라우팅 장애 감지
• 활성 상태, 가용성 또는 시스템 수준의 성능 저하에 따라 트래픽 리디렉션
• 필요한 경우 상태 저장 서비스 또는 세션의 고가용성(HA) 유지

에이전트가 “다음에 무엇을 해야 하는지”를 결정하는 로직을 포함할 수는 있지만, “노드가 다운되었을 때 얼마나 신속하게 복구할지”는 여전히 로드 밸런서가 담당합니다.

적응형 에이전트 인식 라우팅 로직을 도입하더라도 운영 안정성이 저해되어서는 안 됩니다. 계측 체계가 잘 갖춰진 인프라는 다음을 유지해야 합니다:

• 노드를 사용할 수 없게 될 경우 즉각적인 장애 조치 및 트래픽 재분산
• 업스트림 장애로부터 에이전트와 서비스를 보호하는 복원력 높은 고가용성(HA) 토폴로지
• 에이전트의 폴백 로직과 충돌하지 않고 이를 보완하는 신속한 자동 복구

요컨대, 에이전트 중심 아키텍처는 장애 조치의 필요성을 없애는 것이 아니라 오히려 그 중요성을 더욱 높입니다. 이제 인프라는 더 빠르게, 상황을 더욱 세밀하게 파악하여 대응하는 동시에 자율적 동작을 가로막는 병목 지점이 되지 않아야 합니다.

엔터프라이즈 트래픽 관리에 미치는 영향

에이전트 기반 아키텍처로의 전환은 로드 밸런서와 게이트웨이 같은 트래픽 시스템의 작동 방식에 근본적인 변화를 가져옵니다. 기존 트래픽 시스템은 사전 구성된 정책(대개 요청 외부에 존재)을 기반으로 의사 결정을 내렸지만, 에이전트 기반 시스템은 해당 정책을 요청 자체에 포함합니다. 이것이 바로 모델 컨텍스트 프로토콜(MCP)이 지원하는 핵심 기능인 요청별 내장 정책 실행의 기반입니다.

이 모델을 "페이로드 내 정책"이라고 부르겠습니다. 중앙 집중식 시스템이 모든 예외 상황을 분석하도록 하는 대신, 에이전트가 관련 정책 결정 사항(예: 대체 전략, 노드 선호도, 오류 허용 범위 또는 개인정보 보호 요구 사항)을 각 요청에 인코딩합니다. 그러면 인프라는 이러한 정책 지침을 읽고 해석하여 실시간으로 실행해야 합니다.

이 새로운 실행 모델은 트래픽 관리 구성 요소의 역할을 다음과 같이 변화시킵니다:

• 결정자에서 실행자로: 인프라는 더 이상 트래픽의 이동 경로를 결정하지 않고, 에이전트가 전달한 결정을 실행합니다.예: X-Route-Preference: gpu-optimized를 읽은 로드 밸런서는 해당 노드가 원래 풀에 포함되어 있지 않았더라도 그에 따라 트래픽을 전달해야 합니다.
• 런타임에 프로그래밍 가능: iRules와 정책은 X-Intent, X-Context, 또는 X-Goal과 같은 헤더를 평가해야 합니다. 이를 통해 로직이 사전 구성된 경로에서 동적인 인라인 해석 방식으로 전환됩니다.
• 컨텍스트 인식 라우팅: ADC 및 유사 서비스는 호스트나 경로뿐만 아니라 ID, 의도, 컨텍스트를 기반으로 라우팅해야 합니다.
• 의미론적 관측 가능성: 로그에는 무슨 일이 발생했는지뿐만 아니라 그 이유도 표시되어야 합니다. “에이전트가 지연 시간 임계값 초과로 인해 경로를 변경함”이 단순히 “풀 B로 라우팅됨”이라고 표시하는 것보다 더 유용합니다.

데이터 라벨링 기술과 유사한 도구는 실시간 요청의 맥락에 태그를 지정하고 분류함으로써 이러한 전환을 지원하고, 시맨틱 라우팅과 관측 가능성을 실질적으로 구현할 수 있게 합니다.

에이전트 아키텍처를 위한 엔터프라이즈 인프라 준비

AI 에이전트는 독립적으로 작동하지 않습니다. 레거시 시스템과 상호 운용되고, 기존 API를 활용하며, 엔터프라이즈 데이터베이스의 비즈니스 로직을 조작하고, 모놀리식 백엔드와 마이크로서비스에 호스팅된 함수를 호출하게 됩니다. 기업 입장에서는 처음부터 새로 시작할 수 없으며, 기존 환경을 발전시켜야 한다는 의미입니다.

현실: 에이전트는 모든 것과 소통하게 될 것입니다

엔터프라이즈 기술 스택은 다음 요소가 혼합되어 있습니다:

• 재무 업무에 여전히 사용되는 수십 년 된 SOAP API
• 웹 애플리케이션을 지원하는 RESTful 서비스
• 비동기식 재고 시스템을 위한 메시지 큐
• 클라우드 네이티브 마이크로서비스
• 속도 제한과 복잡한 인증이 적용된 SaaS API
• LLM 및 미세 조정된 에이전트

에이전트는 이 모든 영역을 아우르며 작동하는 법을 배워야 합니다. 또한 인프라는 상황 인식형 정책을 적용해 이러한 상호작용을 실시간으로 조율할 수 있어야 합니다.

엔터프라이즈 팀이 준비해야 할 사항

1. 내부 시스템을 의도 중심의 인터페이스를 통해 노출

에이전트가 원하는 것은 5개의 엔드포인트가 아니라 하나의 목표입니다. 에이전트가 단일 시맨틱 진입점을 통해 사용할 수 있도록 추상화 계층이나 API 조합을 통해 비즈니스 기능(예: ‘주문 상태 조회’)을 제공하세요.

준비 단계: API 게이트웨이 또는 서비스 메시를 사용하여 작업 중심의 엔드포인트를 명확한 입출력 계약으로 통합하세요.

2. 단순한 메트릭이 아닌 컨텍스트를 위한 계측

기존 로깅은 메서드, 경로, 응답 시간에 중점을 둡니다. 하지만 에이전트가 중요하게 여기는 것은 다음과 같습니다:

• 작업이 무엇이었는지
• 어떤 대체 방법을 시도했는지
• 목표 달성 여부

준비 단계: 트래픽에 다음과 같은 레이블을 지정하는 시맨틱 관측성 도구를 도입하세요: X-Intent, X-Task-Type, X-Agent-Outcome.

3. 내장된 정책의 런타임 평가 지원

에이전트는 요청에 대체 지침, 타임아웃 설정, 보안 요구사항을 포함합니다. 기존 인프라는 이 데이터를 폐기합니다.

준비 단계: 에이전트 메타데이터(예: X-Route-Preference, X-Fallback-Order, X-Data-Class)를 파싱하고 이에 따라 동작하도록 트래픽 정책을 확장합니다. iRules 또는 이와 유사한 런타임 스크립팅부터 시작하세요.

4. 액세스 제어 및 거버넌스 재정비

에이전트는 자율적으로 작동합니다. 다음 사항을 파악해야 합니다:

• 어떤 에이전트가 누구를 대신해 행동하는지
• 어떤 도구에 액세스할 수 있는지
• 접근이 허용된 데이터 범위

준비 단계: IP 허용 목록이나 정적 RBAC에만 의존하지 말고, ID 기반 액세스 제어와 속성 기반 정책 제어(ABAC)를 통합하세요.

5. 폴백 및 재시도 로직 분리

인프라와 에이전트가 서로 앞다투어 복구를 시도해서는 안 됩니다. 한쪽은 런타임 목표를 처리하고, 다른 쪽은 시스템 차원의 안전장치를 적용하도록 하세요.

준비 단계: 에이전트의 대체 처리 범위(에이전트가 제어하는 영역)와 인프라 장애 조치(직접 관리하는 영역)를 명확히 구분하세요. 조정 규칙과 재정의 조건을 정의하세요.

결론

AI가 개별 모델에서 자율 에이전트로 발전함에 따라 기업은 전략적 전환점에 직면하고 있습니다. 이러한 에이전트는 완전히 새로운 환경에서 작동하는 것이 아니라 기존 애플리케이션과 통합되고, 레거시 API를 호출하며, 핵심 비즈니스 시스템 전반의 의사결정을 주도하게 될 것입니다. 따라서 기업은 새로운 도구를 도입하는 데 그치지 않고, 아키텍처가 의도와 실행, 거버넌스를 처리하는 방식을 재고함으로써 지금부터 이를 지원할 준비를 해야 합니다.

지금은 기존 시스템을 전면 교체할 때가 아닙니다. 전통적인 시스템과 새롭게 등장하는 에이전트의 동작이 명확한 의도와 정밀성을 바탕으로 상호 운용되어야 하는 융합의 시점입니다.

에이전트 아키텍처의 시대가 다가오고 있습니다. 지금부터 대비하는 기업은 단순히 뒤처지지 않는 데 그치지 않고 시장을 선도하게 될 것입니다.

로리 맥비티

2025년 7월 1일 게시