AWS Agent Monitoring, 품질과 인프라 장애를 분리하다
AWS가 일반적인 인프라 대시보드로는 놓치기 쉬운 장애에 대응하기 위해, 4개 에이전트로 구성된 항공 예약 시스템용 이중 계층 에이전트 모니터링 패턴을 소개했다.
이 접근 방식은 Amazon Bedrock AgentCore Evaluations와 AWS DevOps Agent를 결합한다. 한 계층은 에이전트의 행동과 출력 품질을 평가하고, 다른 계층은 해당 행동을 뒷받침하는 클라우드 리소스를 조사한다.
이 분리는 중요하다. AI 에이전트는 온라인 상태를 유지하면서도 관련 없는 답변을 제공하거나, 잘못된 도구를 선택하거나, 여러 단계로 이루어진 작업을 잘못 처리할 수 있기 때문이다. 반대로, 에이전트 워크플로 자체는 건전하더라도 다운스트림 서비스, 권한 또는 네트워크 경로의 장애로 실패할 수 있다.
AWS는 사실상 익숙한 운영 모델에 문제를 제기하고 있다. 애플리케이션 팀은 일반적으로 지연 시간, 오류, 로그, 리소스 상태를 프로덕션 신뢰성의 핵심 신호로 간주한다. 에이전트 시스템에도 이러한 신호는 필요하지만, 시스템이 올바른 결정을 내렸는지를 보여주는 근거 역시 필요하다.
AWS monitoring pattern은 이 구분을 운영 워크플로로 전환한다. 지속적 평가는 품질이 낮은 세션을 식별하고, 자율 조사 기능은 의심되는 인프라 원인을 추적한다.
그 결과는 모든 것을 아는 단일 모니터가 아니다. 품질 판단과 인프라 진단 사이의 책임 분담이다. 이 분담이 핵심 약속인 동시에 기업이 면밀히 검증해야 할 부분이기도 하다.
AWS Agent Monitoring, 이제 행동과 인프라를 모두 포괄
핵심 변화는 AWS agent monitoring이 응답 품질과 서비스 상태를 별도의 프로덕션 신호로 취급한다는 점이다.
이 사례는 4개 에이전트로 구성된 항공 예약 애플리케이션을 사용한다. 감독 에이전트가 항공편, 사용자, 예약 작업을 담당하는 전문 에이전트들을 조율한다.
이 구조는 새롭게 등장하는 많은 엔터프라이즈 시스템과 닮아 있다. 고객 요청은 하나의 인터페이스로 들어오지만, 시스템이 답변을 반환하기 전에는 여러 에이전트와 서비스가 관여할 수 있다.
항공편 에이전트는 이용 가능한 노선을 조회할 수 있다. 사용자 에이전트는 여행자 정보에 접근할 수 있다. 감독 에이전트가 다음 행동을 선택한 뒤에는 예약 에이전트가 예약을 완료할 수 있다.
이 아키텍처는 전문성을 높이지만 장애 표면도 확장한다. 부정확한 결과는 추론, 라우팅, 컨텍스트, 도구 선택, 권한, 데이터 접근 또는 사용 불가능한 서비스에서 시작될 수 있다.
기존 모니터링은 요청 완료 여부, 소요 시간, 오류를 반환한 구성 요소를 알려줄 수 있다. 이러한 측정값은 여전히 필요하지만, 완료된 작업이 유용했는지는 답하지 못한다.
AgentCore Evaluations는 이 행동상 공백을 다룬다. 평가는 시스템 가용성만 판단하는 대신, 정의된 기준을 사용해 에이전트 상호작용, 트레이스 또는 세션을 점수화한다.
AWS는 온라인 평가를 워크플로의 지속적인 부분으로 제시한다. 팀은 프로덕션 상호작용에 평가기를 적용하고 실제 세션 전반의 점수 분포를 살펴볼 수 있다.
온디맨드 평가는 더 좁은 경로를 제공한다. 점수, 불만 또는 인시던트가 조사를 필요로 할 때 운영자는 세션이나 트레이스를 선택해 자세히 분석할 수 있다.
이 구분은 팀에 두 가지 유용한 관점을 제공한다. 집계 점수는 악화되는 패턴을 드러낼 수 있고, 세션 수준 검토는 하나의 부정적 결과로 이어진 경로를 재구성하는 데 도움을 준다.
이 사례의 대시보드는 단순한 통과 또는 실패 지표가 아니라 품질 요약과 분포를 보여준다. 에이전트 품질은 종종 점진적으로 저하되기 때문에 이는 중요하다.
모델 업데이트는 애플리케이션 오류를 일으키지 않으면서도 지시 준수 성능을 낮출 수 있다. 수정된 프롬프트는 평균 응답을 개선하는 한편, 중요한 특정 작업의 신뢰성을 떨어뜨릴 수도 있다.
따라서 행동 계층은 인프라 모니터링만으로는 생성할 수 없는 신호를 만든다. 애플리케이션이 의도된 목적을 달성했는지를 묻는다.
AWS DevOps Agent는 경계의 다른 쪽에서 작동한다. 지원 AWS 환경의 장애를 조사하기 위해 운영 데이터와 리소스 관계를 분석한다.
이 사례는 이 조사를 애플리케이션 및 인프라 텔레메트리를 수집하는 Amazon CloudWatch에 연결한다. DevOps agent는 해당 신호를 사용해 토폴로지를 구성하고 의심되는 장애 경로를 추적할 수 있다.
이 워크플로는 모니터링을 하나의 순서로 재구성한다. 먼저 의미 있는 품질 문제를 감지한다. 다음으로 인프라가 기여했는지 판단한다. 그런 뒤 사람이 검토할 수 있도록 근거와 제안된 해결 조치를 제시한다.
이 조합이 기존 관측 가능성 관행을 없애는 것은 아니다. 그 위에 행동 평가를 추가하고, 그 전반에 걸쳐 조사 에이전트를 더한다.
플랫폼 팀에 이는 프로덕션의 최소 기준을 바꾼다. 서비스 대시보드가 녹색이라고 해서 에이전트가 실제 업무를 완료했다는 뜻은 더 이상 아니다.
4개 에이전트는 하나의 대시보드가 보여주는 것보다 더 많은 장애 경로를 만든다
멀티 에이전트 예약 워크플로는 하나의 사용자 요청을 가장 취약한 결정 하나가 최종 결과를 좌우할 수 있는 연쇄 과정으로 바꾼다.
항공사 사례는 운영상 문제를 구체적으로 보여준다. 감독 에이전트가 요청을 받고 3개의 전문 에이전트에 작업을 라우팅한다.
이러한 계층 구조는 각 에이전트의 책임을 제한할 수 있다. 그러나 최종 응답이 여러 추론 및 서비스 경계를 넘는 성공적인 조율에 의존하게 된다는 의미이기도 하다.
여행자가 예약 변경을 요청한다고 가정해 보자. 감독 에이전트는 요청을 인식하고, 관련 컨텍스트를 유지하며, 올바른 전문 에이전트를 선택하고, 적절한 지침을 전달해야 한다.
전문 에이전트는 이어 유효한 매개변수로 적절한 도구를 호출해야 한다. 결과를 정확히 해석하고 감독 에이전트가 계속 진행할 수 있도록 충분한 정보를 반환해야 한다.
기술적으로 성공한 호출도 고객에게는 좋지 않은 결과를 낳을 수 있다. 시스템이 항공편을 조회했지만 대화 초반에 제공된 날짜 제약을 무시할 수 있다.
또는 올바른 예약 서비스에 잘못된 승객 식별자를 전달할 수 있다. 기저 작업을 완료하지 않은 채 그럴듯한 확인 메시지를 생성할 수도 있다.
이러한 결과가 반드시 높은 CPU 사용량이나 명백한 서버 오류를 유발하는 것은 아니다. 일부는 정상 상태 코드와 허용 가능한 지연 시간을 반환할 수도 있다.
그래서 에이전트 평가에는 상호작용 중 수행된 단계를 기록하는 트레이스가 필요하다. 트레이스는 최종 답변을 라우팅 선택, 모델 호출, 도구 활동 및 지원 서비스와 연결할 수 있다.
OpenTelemetry는 표준화된 텔레메트리를 통해 모델 및 에이전트 활동을 기술하기 위한 generative AI conventions를 개발하고 있다. 이 노력은 일반적인 애플리케이션 필드만으로는 에이전트 워크플로에 충분하지 않은 이유를 보여준다.
항공사 설계는 두 번째 문제도 드러낸다. 사용자 관점에서는 낮은 품질과 인프라 장애가 유사한 증상을 만들 수 있다.
예약 도구는 서비스가 사용 불가능해 타임아웃될 수 있다. 반대로 에이전트가 요청을 오해해 그 도구를 아예 호출하지 않을 수도 있다.
사용자는 예약이 실패했다는 사실만 본다. 운영 팀은 해결책을 선택하기 전에 어떤 유형의 장애가 발생했는지 판단해야 한다.
이 판단은 여러 팀에 동시에 부담을 준다. AI 엔지니어는 프롬프트, 평가 기준, 에이전트 오케스트레이션을 담당한다. 플랫폼 엔지니어는 런타임, 권한, 텔레메트리, 종속 서비스를 담당한다.
애플리케이션 소유자는 여전히 고객 결과를 책임진다. 보안 팀은 한 에이전트가 다른 리소스에 접근할 수 있게 하는 ID와 정책을 통제할 수 있다.
기존 경보는 장애가 어디서 시작됐는지 확정하지 못한 채 이 모든 팀을 동일한 인시던트 채널로 불러들일 수 있다. 이는 수동 로그 검색과 상충하는 가설을 부추긴다.
AWS의 이중 계층 설계는 더 나은 출발점을 제공하려 한다. 낮은 품질 점수는 살펴볼 만한 행동을 식별하고, 인프라 조사는 한 가지 원인 범주를 검증한다.
이 접근 방식은 팀이 평가 결과와 운영 트레이스 간 관계를 보존할 때 가장 가치가 크다. 그 연결이 없다면 서로 단절된 두 개의 경보 스트림만 받게 된다.
트레이스 연속성은 비동기식 또는 분산형 워크플로에서 특히 중요하다. 원래의 사용자 요청은 작업이 완료되기 전 여러 프로세스를 거칠 수 있다.
모든 핸드오프에는 안정적인 식별자와 유용한 속성이 필요하다. 그렇지 않으면 조사자는 낮은 점수의 세션을 이를 뒷받침한 정확한 인프라 이벤트와 신뢰성 있게 연결할 수 없다.
바로 이 지점에서 아키텍처는 단순한 제품 시연을 넘어선다. 이는 프로덕션 에이전트를 위한 책임 계약을 정의한다.
평가 계층은 시스템이 수용 가능한 방식으로 행동했는지 말해 준다. 관측 가능성 계층은 무슨 일이 일어났는지 보여준다. 조사 계층은 인프라가 왜 그렇게 작동했는지를 제안한다.
증거가 충분한지는 여전히 사람이 결정해야 한다. 해결책이 프롬프트, 평가기, 서비스, 정책 또는 데이터 파이프라인 중 어디에 속하는지도 사람이 판단한다.
실제 메커니즘은 두 조사 간의 핸드오프다
AWS의 설계는 품질 점수가 조사자에게 검토할 구체적인 세션, 트레이스 및 시간대를 전달할 때만 작동한다.
AgentCore Evaluations는 단순한 상태 점검이 아니다. 에이전트 상호작용에 평가기, 즉 점수 규칙 또는 모델 기반 심사자를 적용한다.
평가기에는 정의된 대상이 필요하다. 구현에 따라 그 대상에는 작업 완료, 관련성, 정확성, 유용성 또는 기타 비즈니스별 기준이 포함될 수 있다.
지속적 평가는 프로덕션 트래픽 전반의 패턴을 드러낼 수 있다. 팀은 프롬프트 수정, 모델 전환, 도구 업데이트 또는 배포 후 점수가 변했는지 확인할 수 있다.
온라인 경로는 감지에 유용하다. 표본으로 추출한 프로덕션 상호작용을 운영자가 시간에 따라 추세를 파악할 수 있는 품질 신호로 전환한다.
온디맨드 경로는 진단을 지원한다. 운영자는 비정상적인 결과를 발견한 후 선택한 트레이스나 세션을 평가할 수 있다.
AWS의 사례는 낮은 점수 세션을 대상으로 한 AI 지원 패턴 분석도 보여준다. 근거에 대한 가능한 대응으로 프롬프트 개선 권장 사항을 제시한다.
그 권장 사항은 여전히 가설이다. 제안된 프롬프트는 불명확한 지침을 해결할 수 있지만, 손상된 권한이나 사용할 수 없는 종속성은 복구할 수 없다.
따라서 다음 핸드오프가 중요하다. 근거가 운영상 장애를 가리키면 AWS DevOps Agent가 관련 클라우드 환경을 조사한다.
그 역할은 하나의 로그 행을 요약하는 것보다 넓다. 시연된 인터페이스는 토폴로지 그래프를 구축하고, CloudWatch 데이터를 검토하며, 장애와 연관된 경로를 추적한다.
현대의 에이전트 애플리케이션은 하나의 고립된 프로세스로 실행되는 경우가 드물기 때문에 토폴로지가 중요하다. 이들은 런타임, API, ID 제어, 데이터 저장소, 네트워크 경로에 의존한다.
이후 DevOps agent는 식별된 근본 원인과 추적된 장애 경로를 제시한다. 검토를 위한 예방 또는 해결 단계도 제공한다.
이 순서는 숙련된 인시던트 대응자의 워크플로를 닮아 있다. 영향을 받은 경로를 파악하고, 상관관계가 있는 신호를 수집하며, 가능한 원인을 검증하고, 대응 방안을 권고한다.
자동화는 이 조사의 속도와 범위를 바꾼다. 소스 텔레메트리를 바탕으로 결론을 검증해야 하는 필요성까지 바꾸지는 않는다.
이중 계층 메커니즘은 첫 번째 시스템이 두 번째 시스템의 탐색 영역을 좁힐 때 가장 강력하다. 트레이스 컨텍스트 없는 낮은 점수는 인프라 에이전트에 지나치게 큰 모호성을 남긴다.
그 반대도 마찬가지다. 품질 신호가 없는 리소스 이상은 사용자에게 의미 있는 영향을 주지 않을 수 있다.
이로써 실용적인 모니터링 파이프라인이 만들어진다.
모든 에이전트 및 도구 인계 과정에 추적 가능한 식별자를 부여한다.
명시적인 품질 기준에 따라 프로덕션 상호작용을 평가한다.
낮은 점수, 점수 변화 또는 반복되는 실패 패턴을 감지한다.
영향을 받은 세션과 해당 에이전트의 처리 경로를 점검한다.
의심되는 인프라 원인을 자율 조사를 위해 에스컬레이션한다.
프로덕션 동작을 변경하기 전에 증거를 검토한다.
조치 후 평가를 다시 실행해 결과를 측정한다.
마지막 단계는 수명주기를 완결한다. 팀이 목표로 한 동작이 개선됐고 다른 작업에 피해를 주지 않았음을 입증하기 전까지 수정은 완료된 것이 아니다.
이 원칙은 인프라 변경만큼 프롬프트 변경에도 적용된다. 수정된 감독자 지침은 취소 요청의 라우팅을 개선할 수 있지만 신규 예약의 라우팅은 약화시킬 수 있다.
따라서 평가 세트에는 대표적인 작업과 중요한 엣지 케이스가 포함되어야 한다. 프로덕션 샘플링은 예상치 못한 동작을 드러낼 수 있고, 통제된 회귀 테스트 스위트는 이미 알려진 요구사항을 보호한다.
Amazon의 광범위한 AgentCore documentation은 에이전트를 배포하고 운영하기 위한 서비스 모음을 설명한다. 평가는 이 더 큰 운영 환경 안에 속한다.
이 아키텍처는 텔레메트리 기반으로서 CloudWatch에도 의존한다. AWS의 observability guidance는 애플리케이션과 리소스를 파악하는 데 사용되는 메트릭, 로그, 알람 및 트레이스를 다룬다.
이러한 기반은 제품 분리를 설명한다. AgentCore는 에이전트 시스템의 동작에 초점을 맞추는 반면, DevOps 조사는 그 동작을 실행하는 환경에 집중한다.
이 구분은 유용하지만 통합 의무를 만든다. 팀은 두 계층 전반에서 일관된 트레이스 컨텍스트, 접근 제어, 보존 정책 및 에스컬레이션 규칙을 마련해야 한다.
이러한 통제가 없다면 자율 분석은 감사하기 어려운 그럴듯한 설명을 만들어낼 수 있다. 모든 결론이 관찰 가능한 증거로 되돌아갈 때 이 메커니즘은 성공한다.
평가 점수는 자체적인 사각지대를 만들 수 있다
가장 큰 불확실성은 AWS가 점수를 계산할 수 있는지 여부가 아니라, 그 점수가 기업이 실제로 중시하는 결과를 나타내는지 여부다.
평가 메트릭은 압축된 판단이다. 복잡한 상호작용을 팀이 모니터링할 수 있는 레이블, 범주 또는 숫자로 바꾼다.
이러한 압축은 운영 관리를 가능하게 한다. 동시에 성공의 의미에 대한 이견을 가릴 수도 있다.
예약 지원 도우미는 운임 규정을 위반하면서도 높은 관련성 점수를 받을 수 있다. 도움이 되는 것처럼 들리지만 승객이 선택한 좌석을 유지하지 못할 수도 있다.
일반적인 평가기는 중요한 경고를 누락한 간결한 답변에 보상을 줄 수 있다. 또 다른 평가기는 기대하는 표현이 지나치게 좁다는 이유로 올바른 응답에 불이익을 줄 수 있다.
모델 기반 심사기는 추가적인 불확실성을 초래한다. 평가는 심사 모델, 지침, 컨텍스트 및 루브릭을 정의하는 데 쓰인 예시에 따라 달라질 수 있다.
따라서 팀은 사람이 검토한 사례를 기준으로 평가기를 검증해야 한다. 불일치를 측정하고, 오탐을 점검하며, 영향이 큰 작업의 미탐을 추적해야 한다.
임계값에도 맥락이 필요하다. 평균 점수의 작은 하락은 실제 회귀, 새로운 트래픽 구성 또는 정상적인 심사 변동을 반영할 수 있다.
집계 수치는 특정 집단에 집중된 피해를 감출 수 있다. 항공사 지원 도우미가 전체적으로는 잘 작동하지만 국제선 변경이나 복잡한 가족 여행 일정에서는 불균형적으로 실패할 수 있다.
샘플링은 또 다른 사각지대를 만든다. 지속적 평가는 운영상 유용하지만, 팀이 모든 평가기로 모든 상호작용에 점수를 매기지는 않을 수 있다.
선택한 표본은 가치가 높고 위험하며 드문 워크플로를 포괄해야 한다. 그렇지 않으면 대시보드는 가장 자주 관찰하는 일반적인 요청에 유리하게 작동한다.
AWS 사례는 이 조합이 모든 실패 유형을 포착한다는 독립적 증거가 아니라 하나의 아키텍처를 보여준다. 조직은 여전히 자체 사고 사례를 통해 이를 검증해야 한다.
인프라 조사에도 유사한 한계가 있다. 로그와 리소스 관계 간 상관관계는 설득력 있는 실패 경로를 식별할 수 있지만, 유일한 가능한 원인을 확립하지는 못한다.
불완전한 텔레메트리는 분석을 왜곡할 수 있다. 누락된 스팬, 일관되지 않은 타임스탬프 또는 없는 애플리케이션 속성은 잘못된 구성요소가 원인처럼 보이게 할 수 있다.
접근 설계 역시 가시성에 영향을 준다. 조사 에이전트에는 관련 리소스를 점검할 충분한 권한이 필요하지만, 무제한 접근은 불필요한 보안 위험을 초래한다.
기업은 읽기 접근 권한을 좁게 부여하고 에이전트의 쿼리를 기록해야 한다. 자동화된 조치는 조사보다 더 강력한 안전장치를 갖춰야 한다.
NIST의 AI risk profile은 생성형 AI 시스템을 위한 측정, 모니터링, 문서화 및 인간 감독을 강조한다. AI가 다른 AI 시스템을 평가하거나 조사할 때도 이러한 관행은 여전히 중요하다.
가장 방어 가능한 배포 방식은 진단과 실행을 분리한다. 시스템이 증거를 수집하고 조치를 권고하게 하되, 중요한 프로덕션 변경에는 승인을 요구해야 한다.
그 경계는 가능한 영향을 반영해야 한다. 상태를 보존하지 않는 개발 서비스를 재시작하는 일은 ID 정책을 변경하거나 예약 워크플로를 수정하는 일과 다르다.
팀은 트레이스 안의 민감한 데이터도 관리해야 한다. 에이전트 세션에는 고객 세부 정보, 예약 정보, 도구 인수 또는 모델 출력이 포함될 수 있다.
평가 및 관측성 파이프라인은 불필요한 콘텐츠를 최소화해야 한다. 보존, 암호화, 접근 및 마스킹 정책은 모니터링 데이터 자체에도 적용되어야 한다.
공급업체 집중은 전략적 트레이드오프를 제시한다. 제시된 패턴은 런타임, 평가, 텔레메트리 및 인프라 조사를 아우르는 AWS 서비스를 사용한다.
이러한 통합은 이미 AWS를 중심으로 운영되는 워크로드의 운영 마찰을 줄일 수 있다. 반면 멀티클라우드 조사와 마이그레이션을 더 복잡하게 만들 수도 있다.
오픈 텔레메트리 형식은 일부 결합도를 줄일 수 있다. 표준화된 트레이스 식별자와 의미론적 필드는 기존 관측성 시스템으로 증거를 내보내기 쉽게 한다.
그러나 표준 이벤트 스키마가 평가의 의미까지 표준화하는 것은 아니다. 팀은 여전히 애플리케이션, 사용자 및 위험을 기준으로 품질을 정의해야 한다.
따라서 결정적인 질문은 조직에 평가 대시보드가 있는지가 아니다. 엔지니어가 각 점수가 무엇을 측정하며 언제 실패하는지 설명할 수 있는지가 핵심이다.
신뢰할 수 있는 프로그램은 버전 관리된 평가기를 유지하고, 이를 인간의 판단과 벤치마킹하며, 애플리케이션 변경 후 검토할 것이다.
또한 주요 사고를 감사할 수 있을 만큼 원시 증거를 충분히 오래 보존할 것이다. 점수는 주의를 유도해야지, 근본적인 상호작용 기록을 대체해서는 안 된다.
AWS DevOps Agent는 기존 관측성 워크플로에 압력을 가한다
경쟁 압력은 특정 모니터링 공급업체 하나보다 AI 품질과 인프라 운영을 분리해 온 관행에 더 크게 가해진다.
많은 조직은 이미 애플리케이션 성능 모니터링, 중앙 집중식 로깅, 분산 추적 및 사고 관리 플랫폼을 사용한다. 이러한 시스템은 여전히 프로덕션 운영의 중심에 있다.
AWS의 접근 방식이 이를 구식으로 만드는 것은 아니다. 기존 신호에 에이전트별 품질 계층과 더 자율적인 조사 인터페이스가 필요하다고 주장한다.
클라우드 제공업체는 이 주장을 펼치기에 유리한 위치에 있다. 플랫폼 내 서비스 관계, 네이티브 텔레메트리, ID 컨텍스트 및 배포 메타데이터에 접근할 수 있기 때문이다.
독립 관측성 공급업체는 다른 강점을 지닌다. 여러 클라우드, 서비스, 모델 및 애플리케이션 프레임워크 전반에 걸쳐 하나의 운영 관점을 제공하는 경우가 많다.
따라서 전략적 경쟁은 통합된 클라우드 컨텍스트와 이식 가능한 운영 컨텍스트 사이에서 벌어진다. AWS의 패턴은 자체 서비스 전반의 긴밀한 통합을 선호한다.
크로스 플랫폼 스택은 에이전트가 여러 모델 제공업체를 사용하거나 다양한 환경에서 실행될 때 일관된 조사를 지원한다. 어느 경로도 애플리케이션별 평가의 필요성을 없애지는 않는다.
에이전트 개발 플랫폼도 행동 계층을 두고 경쟁한다. 일부는 에이전트 워크플로를 중심으로 트레이싱, 데이터세트, 프롬프트 실험, 평가기 및 회귀 테스트를 제공한다.
AWS는 이러한 관심사를 관리형 런타임 및 운영 서비스에 직접 연결할 수 있다. 가치는 팀이 모든 경계를 가로질러 하나의 트레이스를 얼마나 매끄럽게 따라갈 수 있는지에 달려 있다.
이러한 연속성은 이중 계층 개념이 일상적인 워크플로가 될지, 또 하나의 대시보드 묶음이 될지를 결정할 것이다. 운영자는 사고 대응 중 컨텍스트 전환을 늘리는 도구를 꺼린다.
DevOps 에이전트는 사고 대응에 대한 기대도 바꾼다. 토폴로지를 자율적으로 구축하고 원인을 제안하는 시스템은 초기 조사를 단축할 수 있다.
하지만 팀이 제대로 보정되지 않은 평가에서 조사를 시작하면 알림량도 늘릴 수 있다. 낮은 품질의 탐지는 낮은 품질의 사고를 두 번째 계층으로 흘려보낸다.
이는 평가기 거버넌스를 운영 거버넌스의 일부로 만든다. AI 팀은 알림을 받는 엔지니어와 분리되어 점수를 조정할 수 없다.
공유 런북은 점수가 티켓을 생성하는 시점, 조사를 시작하는 시점, 그리고 단지 추세를 갱신하는 시점을 정의해야 한다.
또한 품질 사고와 인프라 사고를 구분해야 한다. 품질 회귀에는 프롬프트 롤백, 모델 롤백, 도구 수정 또는 데이터 정정이 필요할 수 있다.
인프라 사고에는 용량, 구성, 권한, 네트워킹 또는 서비스 조치가 필요할 수 있다. 일부 사고는 두 범주에 걸칠 것이다.
유용한 분류 체계는 모든 낮은 점수가 클라우드 장애가 되는 것을 막는다. 동시에 모든 타임아웃이 인프라 잡음으로 치부되는 것도 막는다.
4개 에이전트로 구성된 항공사 사례는 이러한 모호성을 드러내기 때문에 가치가 있다. 모든 서비스가 정상인데도 감독자가 잘못된 라우팅 결정을 내릴 수 있다.
전문 에이전트는 올바른 결정을 내렸지만 의존성이 비정상이라 실패할 수 있다. 두 결과는 고객에게 동일하게 보일 수 있다.
AWS의 기여는 이러한 가능성을 분리하는 명시적 메커니즘이다. 시장 압력은 이 운영상 주장으로부터 따른다.
관측성 제공업체는 플랫폼이 토큰 사용량과 모델 지연 시간만 표시하는 것이 아니라 에이전트 행동을 어떻게 평가하는지 보여줘야 한다.
에이전트 플랫폼은 트레이스가 인프라 증거와 어떻게 연결되는지 보여줘야 한다. 도구 호출에서 끝나는 추론 트레이스로는 도구 내부에서 무슨 일이 일어났는지 설명할 수 없다.
기업 구매자는 전체 체인에 걸친 범위를 평가해야 한다. 어느 계층이 실패를 감지하는지, 어느 계층이 이를 조사하는지, 어느 팀이 조치를 담당하는지 알아야 한다.
또한 내보낸 텔레메트리가 원래 플랫폼 밖에서도 충분한 의미를 유지하는지 물어봐야 한다. 이식성은 감사, 사고 검토 및 미래 아키텍처 선택에 영향을 준다.
지식 집약적인 엔지니어링 팀의 경우, 이전 사고, 결정 및 런북을 검색 가능한 형태로 기록해 두는 것은 실시간 텔레메트리를 보완할 수 있다. technical knowledge base는 모니터링 도구가 좀처럼 포착하지 못하는 인간적 맥락을 보존하는 데 도움이 된다.
이러한 맥락은 트레이스를 대체하지 않는다. 왜 임계값이 존재하는지, 어떤 해결책이 과거에 실패했는지, 누가 중요한 운영 변경을 승인했는지를 설명한다.
승리하는 워크플로는 기계 증거와 조직의 기억을 연결할 것이다. 어느 한 계층만으로는 충분하지 않다.
두 계층 모델의 성과를 보여줄 세 가지 신호
다음 검증 과제는 AWS 고객이 이 시연을 측정 가능하고 감사 가능한 프로덕션 개선으로 전환할 수 있는지 여부다.
첫 번째 신호는 애플리케이션 변경 전반에서 평가의 안정성이 유지되는지다. 팀은 프롬프트, 모델, 도구, 트래픽 패턴이 바뀐 뒤에도 AgentCore 점수가 계속 의미 있는지 살펴봐야 한다.
안정적이라는 것은 고정돼 있다는 뜻이 아니다. 설명되지 않는 평가기 드리프트가 아니라, 점수 변화가 사람이 검토한 개선 또는 성능 저하와 부합한다는 의미다.
반복 가능한 보정의 증거는 AWS의 주장을 더 강화할 것이다. 명확한 검증 없이 임계값이 자주 변경된다면 행동 계층에 대한 신뢰는 약화될 것이다.
두 번째 신호는 좋지 않은 결과에서 인프라 문제 발견까지 이어지는 추적의 연속성이다. 예약 사례는 감독자, 전문 에이전트, 도구, AWS 리소스 전반에 걸쳐 유용한 컨텍스트를 전달하는 데 달려 있다.
고객은 낮은 점수를 받은 단일 세션에서 시작해 구체적이고 증거로 뒷받침되는 원인으로 끝나는 조사를 찾아봐야 한다. 그 과정은 사람이 운영자로서 재현할 수 있어야 한다.
일관된 추적 연결은 이중 계층 모델을 뒷받침할 것이다. 누락된 스팬과 약한 상관관계는 팀이 새 인터페이스 뒤에서 동일한 수동 검색을 계속 수행하게 만들 것이다.
세 번째 신호는 개선 권고가 수용되는 비율이다. AWS DevOps Agent는 근본 원인에 대한 설명과 예방 단계를 제시할 수 있지만, 그 권고가 올바른지는 운영자가 판단해야 한다.
팀은 엔지니어가 제안된 조치를 얼마나 자주 수용, 수정 또는 거부하는지 추적해야 한다. 또한 수용된 변경 사항이 새로운 품질 문제를 만들지 않으면서 재발을 방지하는지도 측정해야 한다.
높은 수용률만으로는 충분하지 않다. 더 나은 지표는 정확도, 절약된 시간, 재발 여부, 변경 후 평가 결과를 함께 고려한다.
이러한 신호는 홍보용 시연이 아니라 운영 검토에 나타나야 한다. 프로덕션 환경의 증거는 자율 조사가 사고 지속 시간을 줄이는지, 아니면 첫 번째 가설만 더 빠르게 제시하는지를 보여줄 것이다.
이 패턴을 도입하는 조직은 범위가 제한된 워크플로부터 시작해야 한다. 예약 조회는 되돌릴 수 없는 예약 확정이나 결제 조치보다 위험이 적다.
조직은 소수의 비즈니스 결과를 정의하고, 사람이 검토하는 평가 사례를 만들며, 모든 인계 과정을 계측할 수 있다. 이후 낮은 점수를 읽기 전용 인프라 조사와 연결할 수 있다.
이 단계적 접근 방식은 더 넓은 권한을 부여하기 전에 증거를 만들어낸다. 또한 영향이 제한된 상태에서 누락된 텔레메트리와 약한 평가 기준을 드러낸다.
팀은 각 평가기와 고객 결과 간의 관계를 문서화해야 한다. 관련성 점수가 거래 정확성을 대신해서는 안 된다.
또한 프롬프트, 평가기, 모델, 도구, 런북을 함께 버전 관리해야 한다. 그렇지 않으면 사고 검토 과정에서 당시 어떤 운영 가정이 적용됐는지 재구성할 수 없다.
AWS 에이전트 모니터링은 점점 더 뚜렷해지는 문제에 유용한 해답을 제시한다. 에이전트는 가용하고 빠르지만 틀릴 수 있으며, 동일한 증상 아래 인프라는 정상일 수도 고장 났을 수도 있다.
AgentCore Evaluations와 AWS DevOps Agent는 이 문제를 행동 측정과 운영 조사로 나눈다. 각 계층이 서로 다른 질문을 다루기 때문에 이 설계는 신뢰할 만하다.
성공 여부는 두 계층 사이의 인계에 달려 있다. 낮은 점수가 올바른 추적, 올바른 인프라 증거, 그리고 검증된 개선으로 이어질 수 있는가?
이것이 기업 팀이 다음으로 검증해야 할 질문이다. 중요한 워크플로 하나로 시작해 성공의 의미를 정의하고, 두 계층이 현재의 사고 대응 프로세스보다 더 명확한 의사결정을 제공하는지 확인해야 한다.
