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

AI 에이전트는 단순한 지능형 애플리케이션 그 이상입니다. 애플리케이션의 작동 방식, 의사결정, 적응 구조에 근본적인 변화를 가져옵니다. 기존 시스템과 달리 에이전트는 트래픽 정책에 수동적으로 반응하지 않고 자신만의 정책을 만들어 실행합니다. 에이전트가 전송하는 각 요청은 데이터뿐 아니라 어떤 행동을 할지, 실패 시 대처 방법, 성공 기준 같은 내장 로직도 함께 담고 있습니다.

우리는 의사 결정을 정적인 제어 평면에서 런타임 환경으로 직접 옮깁니다. 이로 인해 제어 평면과 데이터 평면의 오랜 분리가 사라지고, 로드 밸런서, 게이트웨이, 프록시 같은 트래픽 인프라가 미리 설정된 경로를 수동으로 실행하는 것이 아니라, 요청마다 정책을 해석하는 역할을 하게 됩니다.

이 논문은 에이전트 아키텍처가 트래픽 엔지니어링의 핵심 가정을 어떻게 무너뜨리는지, 건강 상태 검사와 폴백 로직부터 관찰 가능성과 보안 적용에 이르기까지 다룹니다. 전통적인 정적 풀과 평균 기반 건강 지표가 요청 단위의 의도가 중시되는 환경에서는 더 이상 충분하지 않은 이유를 명확히 설명합니다. 레이어 7 인프라는 반드시 진화해야 하며, 그렇지 않으면 신뢰할 수는 있지만 전략적으로 보이지 않는 일반적인 인프라에 머무를 위험이 있습니다. 이에 대응하려면 조직이 트래픽 스택을 재설계해야 합니다. 런타임에 프로그래밍 가능하고, 상황을 인지하며, Model Context Protocol(MCP) 같은 에이전트 네이티브 프로토콜과도 완벽히 연동되도록 해야 합니다. 여기에는 폴백 로직 개선, 의미 기반 관찰 가능성 수용, 그리고 에이전트가 주도하는 정책 강화를 지원하는 작업이 포함됩니다. 실시간 데이터 라벨링 같은 신기술이 이 전환 과정에 핵심적인 역할을 합니다.

요컨대, 트래픽 관리의 미래는 단순히 패킷을 전달하는 것을 넘어, 명확한 목적을 실현하는 데 있습니다.

에이전트 구조는 자율적이고 생성형 AI를 활용하는 구성 요소인 에이전트를 도입하여 목표 지향 작업을 수행하고 실시간으로 의사결정을 하며, 상황에 맞게 실행 과정을 즉시 조정할 수 있도록 필요한 맥락을 제공합니다. 이 에이전트는 오늘날 서비스 체이닝처럼 작동하지만, 사전에 구성된 워크플로에 의존하지 않습니다. 대신, 목표와 환경 상태, 관찰된 결과를 바탕으로 실행 흐름을 실시간으로 결정합니다.

이 변화는 미리 정해진 워크플로 기반의 전통적인 중앙 집중식 시스템에서 벗어나, 실행 경로를 실시간으로 생성하는 분산적이고 역동적인 시스템으로 전환하는 것을 의미합니다. 정적인 마이크로서비스 체인의 예측 가능성을 실시간 데이터와 의도에 기반한 유연하고 즉각적인 의사결정으로 바꿉니다.

에이전트 기반 시스템의 주요 특징은 다음과 같습니다:

• 목표 기반 실행: 에이전트는 고정된 워크플로 대신 프롬프트나 임무에 따라 행동합니다. 목표 달성 여부를 판단해 API를 선택하고, 매개변수를 조정하며, 경로를 바꿉니다.

  예제: 고객 불만 해결을 담당하는 상담원은 이전 결과에 따라 청구, 계정, 메시징 API를 각각 다르게 호출합니다.

• 이식 가능한 컨텍스트: 에이전트가 자체 메모리, 상태, 정책을 내장합니다. 모델 컨텍스트 프로토콜(MCP)이나 구조화된 메타데이터를 통해 요청마다 해당 컨텍스트를 담아 전달합니다.
• 런타임 적응: 우리는 인프라의 결정을 기다리지 않고 에이전트가 즉시 재시도, 경로 변경, 에스컬레이션 또는 실행 경로 조정을 하도록 합니다.
• 내장된 관찰 기능: 모든 행동이 자체적으로 설명됩니다. 에이전트는 경로 선택 이유, 평가 내용, 목표 달성 여부를 보고합니다. 이는 단순한 로그와 지표뿐 아니라 행위로 표현되는 관찰성입니다.

이 요소들이 함께 애플리케이션 환경을 예측 가능함에서 적응하고 진화하는 방향으로 바꿉니다.

현재 트래픽 관리 시스템은 명확한 경계 위주로 설계되어 있습니다:

• 제어 평면은 의도를 규정합니다: 어떤 엔드포인트가 유효한지, 어떤 경로를 더 선호할지, 어떤 정책을 적용할지 당신이 결정합니다.
• 데이터 플레인이 결정을 실행합니다: 요청을 라우팅하고, 보안을 적용하며, 부하를 분산시킵니다.

이 모델은 특히 서비스 지향 아키텍처와 마이크로서비스 환경에서 수십 년간 효과적으로 작동해 왔습니다. 트래픽 흐름을 사전에 예측하고 워크로드가 일정한 패턴을 따른다는 전제하에 설계되었습니다.

Examples:

• 로드 밸런서는 /api/login 요청을 한 풀로, /api/images 요청을 다른 풀로 분배합니다.
• 상태 확인을 통해 노드가 사용 가능한지 아니면 중단되었는지 표시합니다.
• 정적 임계값이 장애 조치 조건을 설정합니다.

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

• 특정 풀과 멤버 같은 정적 리소스에 정책과 구성을 밀접하게 결합합니다
• 풀과 멤버 같은 정적 구조
• 경로, 헤더, 프로토콜에 기반한 결정적 라우팅
• 서비스 검색, 상태 점검, 폴백 로직을 위한 중앙 집중식 관리

하지만 에이전트 기반 시스템은 유동성, 자율성, 그리고 스스로 판단하는 논리를 적용해 기존 가정을 무너뜨립니다.

에이전트 아키텍처에서는 제어 플레인과 데이터 플레인의 구분이 점점 허물어집니다. 에이전트는 단순히 요청을 실행하는 것에 그치지 않고, 요청의 내용, 폴백을 유발할 조건, 성공 기준, 선호 경로까지 정의하는 로직을 내장합니다. 전통적으로 제어 플레인의 역할이던 이런 기능을 에이전트가 헤더, 토큰, 또는 메타데이터에 인코딩해 요청과 함께 데이터 플레인을 통해 전달합니다.

이 융합은 데이터 플레인이 중앙 집중식 결정을 수동적으로 실행하는 역할에서 벗어나야 함을 의미합니다. 데이터 플레인이 정책을 즉시 능동적으로 해석해야 합니다. 요청은 단순한 패킷이 아니라 정책 관련 산물입니다. 따라서 로드 밸런서, 게이트웨이, 라우팅 계층은 반응하는 부품에서 에이전트가 담은 의도를 실시간으로 해석하는 역할로 변모합니다.

이 변화는 제어 평면이 고정되고 중앙에 집중되어 있다는 기본 아키텍처 가정을 흔듭니다. 대신 의사 결정 로직은 분산되고 휴대 가능하며 개인화되어, 각 요청과 함께 흐르면서 실행 시점에 처리됩니다. 이건 단순한 배포의 변화가 아니라, 결정이 이뤄지는 장소와 방식 자체가 바뀐 것입니다.

쿠버네티스가 네트워크, 스토리지, L4 트래픽 라우팅 같은 인프라를 추상화하며 시작한 일을 이제 완성했습니다. 모든 것을 선언형 제어 면 뒤에서 “배관”처럼 다루도록 만든 것입니다. 우리는 그 계층을 없애지 않고 역할을 낮췄습니다. 그 계층은 이제 보이지 않고 자동화되며, 새로운 의도 중심 시스템에 종속됩니다.

에이전트 아키텍처는 인프라뿐만 아니라 전체 스택에도 동일한 기능을 제공합니다.

이러한 혼란을 현실적인 사례로 이해하려면 로컬 애플리케이션 전달 상황을 살펴보세요.

예시: 지역 전자상거래 사이트는 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 토폴로지
• 에이전트 폴백 로직과 충돌하지 않고 보완하는 빠르고 자동화된 복구를 제공합니다

요컨대, 에이전트 중심 아키텍처가 장애 조치 필요성을 없애는 것이 아니라, 오히려 그 중요성을 높입니다. 인프라는 이제 더 빠르게, 더 풍부한 문맥을 인지하며, 자율적 작동에 걸림돌이 되지 않도록 반응해야 합니다.

에이전트 기반 아키텍처로 전환하면 로드 밸런서나 게이트웨이 같은 트래픽 시스템의 작동 방식을 근본적으로 바꿔야 합니다. 기존 트래픽 시스템이 요청 외부에 있는 사전 설정된 정책에 따라 결정을 내렸다면, 에이전트 중심 시스템은 정책을 요청 자체에 직접 적용합니다. 이것이 바로 모델 컨텍스트 프로토콜(MCP)이 제공하는 핵심으로, 요청별로 임베디드된 정책을 실행할 수 있게 합니다.

우리는 이 모델을 "페이로드 내 정책"이라고 부르겠습니다. 중앙 집중식 시스템이 모든 예외 상황을 분석하는 대신, 에이전트가 각 요청에 관련 정책 결정(폴백 전략, 노드 선호, 오류 허용 한도, 개인정보 보호 요구사항 등)을 직접 담아냅니다. 그다음 인프라는 실시간으로 이 정책 지침을 읽고 해석하며 신속히 실행합니다.

새 실행 모델을 통해 트래픽 관리 구성 요소의 역할을 근본적으로 바꿉니다:

• 결정하는 사람에서 실행하는 사람으로: 인프라는 더 이상 트래픽 경로를 정하지 않고, 에이전트의 결정을 실행합니다.

  예시: 로드 밸런서가 X-Route-Preference: gpu-optimized를 읽으면, 해당 노드가 원래 풀에 없더라도 트래픽을 그에 맞게 전달해야 합니다.

• 런타임에 프로그래밍 가능: iRules와 정책은 X-Intent, X-Context, X-Goal 같은 헤더를 평가해야 합니다. 이로써 논리를 미리 설정된 경로가 아닌 동적으로 즉석에서 해석할 수 있습니다.
• 컨텍스트 인식 라우팅: ADC와 유사한 서비스는 호스트나 경로가 아닌 ID, 의도, 상황에 맞춰 라우팅을 수행해야 합니다.
• 의미 기반 관찰 가능성: 로그에는 무슨 일이 일어났는지뿐만 아니라 그 이유도 명확히 나타나야 합니다: “대기 시간 한계 초과로 에이전트가 경로를 변경했습니다”가 단순히 “풀 B로 라우팅됨”보다 훨씬 유용합니다.

데이터 레이블링 기술과 유사 도구가 실시간 요청 컨텍스트에 태그를 붙이고 분류하여 의미 기반 라우팅과 관측을 가능하게 하며 변화에 효과적으로 대응할 수 있도록 도와줍니다.

AI 에이전트는 독립적으로 작동하지 않습니다. 기존 시스템과 연동하고, 전통적인 API를 활용하며, 엔터프라이즈 데이터베이스 내 비즈니스 로직을 다루고, 모놀리식 백엔드와 마이크로서비스 양쪽에 있는 함수를 호출할 수 있습니다. 기업 입장에서는 새로 시작할 수 없으며 반드시 진화해야 합니다.

엔터프라이즈 스택은 다음 요소들이 결합된 형태입니다:

• 금융 분야에서 여전히 사용되는 수십 년 된 SOAP API
• 웹 애플리케이션 뒤에 숨은 RESTful 서비스
• 비동기 재고 시스템용 메시지 큐
• 클라우드에 최적화된 마이크로서비스
• 속도 제한과 복잡한 인증을 갖춘 SaaS API
• 대형 언어 모델과 맞춤형 에이전트

에이전트는 모든 영역에서 효과적으로 작동하는 법을 배워야 합니다. 인프라는 상황에 맞는 정책을 실시간으로 적용해 상호작용을 원활하게 중재할 수 있어야 합니다.

에이전트는 다섯 개 엔드포인트가 아니라 하나의 목표를 원합니다. 단일 의미적 진입점을 통해 에이전트가 사용할 수 있도록 추상화 계층이나 API 구성을 통해 비즈니스 기능(예: "주문 상태 조회")을 제공합니다.

준비 단계: API 게이트웨이나 서비스 메시를 활용해 작업별 엔드포인트를 명확한 입출력 계약으로 통합하세요.

기존 로깅은 메서드, 경로, 응답 시간에 집중합니다. 하지만 에이전트는 다음을 중시합니다:

• 수행한 작업 내용
• 어떤 대체 방안을 시도했습니까
• 목표를 달성했는지 여부

준비 단계: X-Intent, X-Task-Type, X-Agent-Outcome 같은 레이블로 트래픽을 태그하는 의미 기반 관찰 도구를 도입하세요.

에이전트는 요청에 폴백 지침, 타임아웃 설정, 보안 요구 사항을 포함합니다. 기존 인프라는 이 정보를 무시합니다.

준비 단계: 트래픽 정책을 확장해 에이전트 메타데이터(예: X-Route-Preference, X-Fallback-Order, X-Data-Class)를 분석하고 대응하십시오. iRules나 유사한 런타임 스크립트로 시작하세요.

에이전트는 스스로 작동합니다. 다음 내용을 꼭 확인하세요:

• 어떤 대리인이 누구를 대신해 행동하나요
• 어떤 도구에 접근할 수 있나요
• 어떤 데이터 범위에 접근할 수 있습니까

준비 단계: IP 허용 목록이나 정적 RBAC에 그치지 말고 ID 기반 접근과 속성 기반 정책 제어(ABAC)를 통합하세요.

인프라와 에이전트가 복구를 두고 경쟁하지 않게 하세요. 하나는 런타임 목표를 달성하고, 다른 하나는 시스템 안전장치를 실행하도록 맡기십시오.

준비 단계: 에이전트 폴백 범위(에이전트가 통제하는 부분)와 인프라 페일오버(고객이 관리하는 부분)를 명확히 구분하세요. 협상 규칙과 오버라이드 조건을 정의하세요.