Amazon Nova Act, 사용자 의도를 중심으로 synthetic monitoring을 재구성하다

Amazon은 Amazon Nova Act를 활용한 synthetic monitoring 구현을 위한 6단계 참조 구현을 공개했다. 이 방식은 고정된 UI selector 대신 자연어 기반 browser action을 사용한다. 9월 28일 공개된 이 구현은 Nova Act, Amazon Bedrock AgentCore, EventBridge Scheduler, CloudWatch, SNS를 결합한다. 핵심 주장은 일반적인 인터페이스 변경으로 기존 스크립트가 중단되더라도 agent가 중요한 고객 여정을 계속 점검할 수 있다는 것이다.

이 약속은 synthetic monitoring을 둘러싼 논의를 바꾼다. 이제 질문은 스크립트화된 browser가 버튼을 클릭할 수 있는지에만 국한되지 않는다. AI agent가 의도한 버튼을 인식하고, 여정을 완료하며, 결과를 검증하고, 애플리케이션 장애와 자체 불확실성을 구분할 수 있는지가 관건이다.

Selenium과 Playwright는 결정론적 제어 기능을 갖춘 성숙한 automation framework로 남아 있다. AWS가 소프트웨어 테스트 전반에서 이러한 도구를 대체하는 것은 아니다. 대신 locator 유지보수 감소가 모든 상호작용을 제어하는 것만큼 중요한 반복적인 production 점검을 위한 다른 운영 모델을 제안하고 있다.

AWS, Browser Agent를 예약형 Monitor로 전환하다

이번 공개는 browser 추론, 격리 실행, scheduling, alerting을 하나의 관리형 monitoring 경로로 묶는다.

Synthetic monitoring은 실제 고객이 문제를 신고하기 전에 애플리케이션을 대상으로 자동화된 transaction을 실행한다. Monitor는 로그인하고, 항목을 검색하고, 상품 페이지를 열고, 장바구니에 추가한 뒤 checkout이 계속 가능한지 확인할 수 있다.

Infrastructure metric만으로는 이 전체 여정이 작동하는지 항상 파악할 수 없다. Backend가 정상 status code를 반환하더라도 비활성화된 버튼, 손상된 overlay, 지연된 third-party widget 또는 frontend regression이 고객을 막을 수 있다.

새로운 monitoring architecture는 EventBridge Scheduler를 사용해 AgentCore Runtime에서 호스팅되는 Nova Act workflow를 호출한다. 이어 Nova Act가 AgentCore Browser session을 조작하고, 여정이 실패하면 SNS가 alert를 배포한다.

AWS는 여정의 중요도에 따라 5분 간격부터 1시간 간격까지의 schedule을 제안한다. 샘플은 6단계 ecommerce flow에 초점을 맞추며, 페이지 로딩 동작에 따라 실행 시간이 2~4분이라고 보고한다.

이번 공개가 중요한 이유는 browser action 자체를 넘어서는 범위를 다루기 때문이다. 샘플에는 agent code, deployment automation, infrastructure-as-code 옵션, alert routing, dead-letter 처리, 실행 누락 alarm이 포함된다.

AWS는 두 가지 deployment 경로를 제공한다. Python deployment script는 prerequisite check를 수행하고 SNS topic을 생성하며 workflow를 배포하고 schedule을 연결한다. 별도의 AWS Cloud Development Kit stack은 반복 가능한 infrastructure provisioning을 처리한다.

CDK 경로는 실패한 scheduler invocation을 위한 Amazon SQS dead-letter queue를 추가한다. 또한 dead-letter-queue depth와 누락된 scheduled run에 대한 CloudWatch alarm도 생성한다.

이 구분은 중요하다. Monitor는 scheduler가 agent에 도달하지 못해 실패할 수도 있고, agent가 애플리케이션에 도달한 뒤 손상된 여정을 발견해 실패할 수도 있다. Infrastructure alarm은 첫 번째 범주를, agent의 SNS message는 두 번째 범주를 다룬다.

따라서 sample implementation은 monitoring을 각각 관찰 가능한 구성 요소의 연쇄로 취급한다. 이는 browser intelligence를 전체 해결책으로 제시하는 것보다 더 설득력 있다.

이 연쇄는 새로운 dependency도 만든다. 이제 유효한 결과는 EventBridge, AgentCore Runtime, AgentCore Browser, Nova Act inference, 대상 애플리케이션, alert route에 따라 달라진다. 팀은 최종 status만 신뢰할 것이 아니라 monitor 자체를 관찰해야 한다.

사용자 여정 실패가 Selector 유지보수를 압박하다

AWS는 production browser 점검이 모든 인터페이스 세부 사항을 미리 인코딩해야 한다는 가정에 도전하고 있다.

기존 browser automation은 role, label, test ID, CSS selector 또는 XPath expression 같은 contract를 통해 element를 식별한다. 이 접근 방식은 정밀성을 제공하지만, 지속성은 선택한 contract에 달려 있다.

Selenium은 페이지의 구조화된 browser 표현인 Document Object Model, 즉 DOM에서 element를 찾는 여러 방식을 제공한다. Selenium의 locator guidance는 가능할 때 안정적인 ID를, 그렇지 않을 때는 간결한 CSS selector를 권장한다.

Playwright는 automatic waiting, retry, 사용자 대면 속성에 기반한 locator로 이 모델을 개선한다. 공식 locator documentation은 긴 CSS 또는 XPath chain보다 role, text, label, 명시적인 test ID를 권장한다.

이러한 기능은 비교를 “AI는 작동하고 스크립트는 실패한다”보다 더 미묘하게 만든다. 잘 설계된 Playwright test는 rerendering과 여러 timing 변경을 견딜 수 있다. 안정적인 accessibility role 또는 test ID 역시 시각적 redesign 이후에도 유지될 수 있다.

팀이 완전히 통제하지 못하는 페이지를 monitoring할 때 유지보수 부담은 더 뚜렷해진다. Third-party identity provider, payment interface, consent dialog, embedded booking service, 자주 테스트되는 production variant는 안정적인 contract를 제공하지 않을 수 있다.

내부에서 통제하는 페이지도 churn을 만들 수 있다. Label 변경, checkout component 이동, 또는 experiment가 다른 layout을 제공한 뒤 test가 실패할 수 있다. 그러면 엔지니어는 제품이 실패한 것인지, monitor가 오래된 것인지를 판단해야 한다.

Amazon Nova Act는 시각적 접근 방식을 취한다. Multimodal model로 screenshot을 처리하고 “Click the checkout button” 같은 자연어 instruction에 따라 동작한다. 이 instruction은 CSS class나 element ID가 아니라 의도를 설명한다.

이 추상화가 selector 기반 monitoring에 가해지는 핵심 압력이다. Product team은 사용자에게 보이는 작업을 반드시 바꾸지 않고도 styling이나 내부 markup을 변경할 수 있다. Nova Act가 여전히 작업을 인식한다면 monitor는 selector update 없이 계속 동작할 수 있다.

AWS는 초기 enterprise use case에서 browser-workflow 정확도가 90%를 넘었다고 말한다. 이 수치는 AWS가 제시한 것이며, 모든 site, journey 또는 interface condition에서의 정확도를 입증하지는 않는다.

그럼에도 이 수치는 의도된 trade-off를 보여준다. Agent는 긴밀히 결합된 selector가 만드는 결정론적 유지보수를 줄이기 위해 일부 확률적 동작을 받아들인다.

압박은 반복 monitor가 많고 인터페이스 release가 잦은 팀에 가장 크게 작용한다. 개별 selector repair는 작을 수 있다. 하지만 수많은 journey, device, variant, region 전반에서는 이러한 repair가 지속적인 운영 workload가 된다.

이 변화는 ownership에도 영향을 준다. 기존 점검에서는 test engineer가 애플리케이션 구조를 이해해야 하는 경우가 많다. 의도 기반 action은 operator가 비즈니스 여정을 더 직접적으로 설명하게 해 주지만, engineer는 여전히 assertion, permission, retry, observability를 설계해야 한다.

AWS는 포괄적인 coverage를 시도하기보다 3~5개의 핵심 workflow부터 시작할 것을 권장한다. Login, checkout, account access, booking, subscription 변경은 영향이 낮은 navigation path보다 더 적합한 후보이다.

이 조언은 제안을 현실에 맞게 유지한다. Agent 기반 monitoring은 손상된 여정이 의미 있는 비즈니스 결과를 초래하고, 많은 취약한 점검을 유지하는 데 측정 가능한 비용이 드는 경우 가장 가치가 크다.

Amazon Nova Act를 활용한 Synthetic Monitoring 구현이 Control Layer를 바꾸다

핵심 메커니즘은 자연어 prompting만이 아니라 agentic interaction과 명시적 outcome validation의 분리에 있다.

샘플은 browser action을 journey step으로 묶는다. Nova Act의 act() method는 자연어로 설명된 action을 수행한다. act_get() method는 workflow가 Boolean schema에 대해 평가할 수 있는 structured information을 반환한다.

이 분리는 페이지에서 클릭을 진행하는 것만으로는 성공을 증명할 수 없기 때문에 중요하다. Monitor는 고객이 중요하게 여길 결과를 확인해야 한다.

Retail journey에서 완료는 표시되는 search result, 장바구니에 담긴 올바른 item, 이용 가능한 checkout path를 요구할 수 있다. 단순한 page transition은 빈 result set, error banner 또는 잘못된 cart state를 숨길 수 있다.

따라서 AWS는 의미 있는 checkpoint에서 assertion을 수행할 것을 권장한다. 이 설계는 모든 시각적 element를 점검하지 않고 비즈니스 outcome을 검증한다. 이 균형은 cosmetic change가 alert를 발생시키는 반면 기능 장애는 보이지 않는 상황의 가능성을 낮춘다.

Step이 실패하면 샘플은 journey type, target URL, total duration, 완료된 step, 실패한 step을 publish할 수 있다. 상세 exception은 runtime log에 남아 operator가 실행을 조사할 수 있다.

AgentCore Runtime은 관리형 execution layer를 제공한다. Workflow는 안정적인 runtime endpoint를 수신하므로 EventBridge Scheduler가 이를 직접 호출할 수 있다. Update된 deployment는 scheduler target을 변경하지 않고 새 runtime version을 생성할 수 있다.

Nova Act command-line interface는 local workflow code를 package화하고, container image를 Amazon Elastic Container Registry에 push하며, runtime을 provision한다. Nova Act interfaces에는 Python SDK, IDE extension, browser playground, execution trace용 AWS console도 포함된다.

AgentCore Browser는 팀이 browser farm을 유지할 필요 없이 격리된 remote browser를 제공한다. 각 scheduled run은 cookie, cache, local storage, intermediate state를 위한 별도의 environment를 받는다.

AWS는 synthetic monitoring에 ephemeral session을 권장한다. Ephemeral session은 깨끗한 상태에서 시작해 실행 후 사라지므로, 이전의 성공적인 login 또는 cached page가 새로운 failure를 가리는 일을 방지한다.

AgentCore Runtime은 CPU, memory, filesystem resource를 격리하는 경량 virtual machine인 전용 microVM을 사용한다. session architecture에 따르면 session이 끝날 때 microVM은 종료되고 memory는 정리된다.

격리는 security와 test validity를 모두 개선한다. 한 monitor가 다른 monitor의 authentication state, shopping cart, experiment assignment 또는 browser storage를 상속해서는 안 된다.

이 architecture는 internal application도 지원한다. AgentCore Browser는 기본적으로 public network access를 사용하지만, VPC configuration은 private environment의 egress를 제한할 수 있다. IAM policy는 workflow가 사용할 수 있는 browser, runtime, notification resource를 결정한다.

Authenticated journey에는 추가적인 규율이 필요하다. Credential은 prompt, source file 또는 deployment artifact에 포함된 environment value가 아니라 AWS Secrets Manager에서 가져와야 한다. Access는 monitor에 필요한 특정 account 및 transaction scope로 제한되어야 한다.

Amazon Nova Act를 활용한 synthetic monitoring 구현에도 여전히 orchestration code가 필요하다. Agent는 어떤 journey가 중요한지, 얼마나 자주 실행할지, 어떤 outcome이 성공을 증명하는지, 또는 불확실한 결과가 언제 operator에게 page를 보내야 하는지를 결정하지 않는다.

이처럼 사람이 설계한 control layer가 browser automation을 monitoring으로 전환한다. Nova Act는 step 실행 방식을 바꾸지만, reliability는 여전히 주변 system에 달려 있다.

진짜 경쟁은 Intent와 Determinism 사이에 있다

Nova Act는 페이지 구조와의 결합을 줄이지만, 예측 가능한 locator failure를 확률적 해석으로 대체하기도 한다.

셀렉터 기반 검사는 대체로 원인을 확인할 수 있는 방식으로 실패한다. 요소가 일치하지 않았거나, 실행 가능한 상태가 되지 않았거나, 제한 시간 내에 예상 상태에 도달하지 못한 경우다. 엔지니어는 DOM을 살펴보고 계약을 업데이트할 수 있다.

에이전트 기반 검사는 애플리케이션이 망가졌기 때문일 수도, 모델이 인터페이스를 잘못 해석했기 때문일 수도, 지시가 모호했기 때문일 수도 있다. 외부에서는 이 경우들이 비슷하게 보일 수 있다.

이것이 AWS 제안의 핵심 긴장 관계다. 의도 기반 자동화는 취약한 셀렉터를 망가뜨리는 일상적인 인터페이스 변경에도 살아남을 수 있다. 반면 페이지가 안정적인 계약을 제공할 때는 결정론적 자동화가 여전히 이해하고 추론하기 쉽다.

가장 강력한 구현은 이 접근법들을 상호 배타적으로 다루지 않을 것이다. 팀은 하위 수준 API 검사, 컴포넌트 테스트, 결정론적 브라우저 스위트를 유지하면서 선택한 프로덕션 여정에 에이전트 주도 모니터를 추가할 수 있다.

각 계층은 서로 다른 질문에 답한다. API 검사는 서비스가 올바르게 응답하는지 판단한다. 결정론적 엔드투엔드 테스트는 정의된 애플리케이션 계약을 검증한다. 에이전트 주도 모니터는 브라우저가 여전히 사용자에게 보이는 목표를 완료할 수 있는지 묻는다.

차이는 리디자인 과정에서 분명해진다. 접근성 의미 체계가 안정적으로 유지된다면 역할 기반 Playwright 로케이터는 계속 작동할 수 있다. CSS 체인은 즉시 실패할 수 있다. Nova Act는 시각적으로 성공할 수도 있고, 여러 요소가 비슷해 보여 잘못된 컨트롤을 선택할 수도 있다.

이러한 변동성 때문에 여정 문구는 테스트 설계의 일부가 된다. “결제를 완료하라”는 “화면에 보이는 결제 컨트롤을 선택하고, 검토 페이지가 표시되는지 확인하며, 주문은 제출하지 말라”보다 더 많은 재량을 남긴다.

지시는 특히 파괴적인 거래와 관련한 경계를 명시해야 한다. 프로덕션 모니터가 실제 결제를 실수로 제출하거나, 메시지를 보내거나, 고객 데이터를 수정하거나, 재고 압박을 만들어서는 안 된다.

결과 검증에도 같은 수준의 주의가 필요하다. 장바구니 아이콘만 확인하는 모니터는 잘못된 상품이 추가된 경우에도 성공을 보고할 수 있다. 모든 라벨과 레이아웃 세부 사항을 검증하는 모니터는 본래 줄이려 했던 유지보수 부담을 다시 만들어 낸다.

팀에는 불확실성에 대한 정책도 필요하다. 모델의 단일 실패가 반복되는 고객 대면 장애와 자동으로 같은 심각도를 가져서는 안 된다. 반대로 지나친 재시도는 실제 사용자가 여전히 겪는 간헐적 결함을 숨길 수 있다.

AWS 샘플은 단계당 한 번의 시도를 선택한다. 이는 브라우저 실행 시간과 추론 사용량을 제한하지만, AWS는 Nova Act가 존재하는 요소를 찾지 못할 때 오탐 경보가 발생할 수 있음을 인정한다.

단계 수준의 재시도는 이러한 경보를 줄일 수 있다. 하지만 세션이 길어지고 새로운 해석상의 질문도 생긴다. 두 번째 시도에서 성공한 것은 애플리케이션이 정상이라는 뜻일까, 아니면 경험이 저하됐다는 뜻일까?

답은 여정에 따라 달라진다. 위험이 낮은 검색 검사에서 한 번 재시도하는 것은 수용할 수 있다. 인증 또는 결제 과정에서 반복적인 지연은 그 자체로 조사가 필요할 수 있다.

에이전트 주도 모니터링은 테스트 검토 방식도 바꾼다. 엔지니어는 프롬프트, 검증 스키마, 스크린샷, 트레이스, 재시도 동작, 모델 결과를 검토해야 한다. DOM 셀렉터는 더 이상 유일한 실행 가능한 명세가 아니다.

이것이 유지보수를 없애는 것은 아니다. 유지보수의 초점이 의도 정의, 평가 규칙, 접근 제어, 실패 분류로 이동한다. 이 변화는 여전히 가치 있을 수 있지만, 팀은 이를 가정하지 말고 측정해야 한다.

따라서 Selenium과 Playwright에 가해지는 압박은 제한적이고 구체적이다. Nova Act는 프로덕션 여정 모니터링의 유일한 메커니즘으로서 이들의 사용 방식에 도전한다. 그러나 정밀하고 반복 가능한 엔지니어링 테스트에서 이들이 맡는 역할을 대체하지는 않는다.

90퍼센트 에이전트는 아직 신뢰할 수 있는 페이저가 아니다

가장 큰 미해결 과제는 실제 장애를 가리지 않으면서 오탐 경보를 낮게 유지할 수 있는지다.

AWS가 보고한 90퍼센트 이상의 정확도는 고무적이지만, 개별 모니터의 서비스 수준 목표는 아니다. 다양한 워크플로 전반의 정확도는 특정 사이트, 릴리스 패턴, 인증 흐름, 지리적 리전에서의 성능을 보여주지 않는다.

남은 오류율은 모니터링 빈도를 고려하면 중요하다. 5분마다 실행되는 검사는 30일인 한 달에 약 8,640회 실행된다. 에이전트에서 비롯된 작은 실패율조차 이 규모에서는 주의를 분산시키는 경보를 만들 수 있다.

AWS 샘플은 6단계 여정마다 약 24회의 작업 및 검증 호출을 추정한다. 5분 주기에서는 월 약 207,360회의 Nova Act 작업에 이른다.

이 수치는 모든 배포에 대한 예측이 아니다. 팀이 적용 범위를 확대하기 전에 단계별 신뢰성, 세션 지속 시간, 경보 품질을 평가해야 하는 이유를 보여준다.

합리적인 도입은 섀도 모드에서 시작된다. 운영자는 에이전트가 온콜 팀을 호출하지 않은 채 실행되도록 하고, 그 결과를 결정론적 검사, 애플리케이션 텔레메트리, 수동 재현 결과와 비교할 수 있다.

팀은 실패 원인별로 라벨을 붙여야 한다. 유용한 범주에는 확인된 애플리케이션 결함, 예상된 애플리케이션 변경, 에이전트 해석 오류, 인증 문제, 인프라 호출 실패, 결론을 내릴 수 없는 결과가 포함된다.

이 분류는 지시와 재시도를 조정하는 데 필요한 근거를 만든다. 또한 에이전트가 유지보수를 줄이는지, 아니면 단지 다른 검토 대기열을 만드는지를 드러낸다.

모니터 자체에 대한 모니터링도 필수다. CloudWatch 호출 메트릭은 에이전트가 의도한 빈도로 실행되는지와 각 실행에 걸리는 시간을 보여줄 수 있다. SQS 데드레터 큐는 런타임에 도달하지 못한 스케줄러 전달을 드러낸다.

이 신호들은 여정 경보를 대체하지 않는다. 런타임은 결제가 망가졌음을 발견한 뒤에도 정상적으로 반환될 수 있다. 반대로 스케줄러, 런타임, 브라우저 또는 알림 경로가 실패하는 동안 애플리케이션은 정상 상태를 유지할 수 있다.

보안은 또 다른 압박 지점을 만든다. 브라우저 에이전트는 신뢰할 수 없는 텍스트를 포함할 수 있는 페이지 콘텐츠를 본다. 팀은 허용 도메인, 부여된 권한, 사용 가능한 도구, 허용된 거래를 제한해야 한다.

자격 증명도 최소 권한을 가져야 한다. 합성 계정은 실제 고객이나 직원의 접근 권한을 상속해서는 안 된다. 해당 데이터는 식별 가능하고 삭제 가능해야 하며, 적절한 경우 비즈니스 보고에서 제외돼야 한다.

지역별 모니터링은 신중한 해석이 필요하다. AWS 리전 전반에 워크플로를 배포하면 지역별 접근성 또는 지연 시간 문제를 드러낼 수 있지만, 클라우드 브라우저는 모든 가정용 네트워크, 기기 또는 고객 환경을 재현하지는 못한다.

CAPTCHA, 봇 탐지, 동의 시스템, 사기 방지 제어도 합성 브라우저를 실제 사용자와 다르게 처리할 수 있다. 성공적인 에이전트 세션이 모든 고객에게 같은 경로가 제공된다는 보장은 아니다.

모델 자체도 시간이 지나며 바뀔 수 있다. 팀에는 애플리케이션 변경과 에이전트 동작 변경을 구분할 수 있도록 회귀 여정과 버전 기록이 필요하다.

AWS는 실행, 세션, 액션, 단계를 포함한 실행 트레이스를 Nova Act 콘솔을 통해 제공한다. 이 기록은 실패 조사에 도움이 될 수 있지만, 조직은 스크린샷이나 민감한 페이지 데이터를 포함하는 아티팩트를 얼마나 오래 보관할지 결정해야 한다.

올바른 기준은 완벽한 정확도가 아니다. 기존 모니터도 불안정한 실패를 낸다. 핵심 질문은 새로운 시스템이 대응 인력을 압도하지 않으면서 탐지를 개선하고 유지보수를 줄이는가이다.

독립적인 프로덕션 데이터가 उपलब्ध해지기 전까지 AWS의 정확도 주장은 출발 가설로 남아야 한다. 각 팀은 자체 여정과 실패 허용 수준을 기준으로 이 주장을 검증해야 한다.

세 가지 신호가 에이전트 모니터링의 지속 가능성을 보여줄 것이다

다음 단계는 경보 정밀도, 워크플로 내구성, 반복 가능한 프로덕션 도입의 증거로 평가해야 한다.

첫 번째 신호는 확인된 애플리케이션 장애와 에이전트에서 비롯된 경보의 비율이다. 팀은 재현 가능한 결함에 해당하는 페이징 수와 해석 오류, 타이밍 또는 모호한 지시에서 비롯되는 수를 추적해야 한다.

제한적인 재시도와 프롬프트 조정 후 이 비율이 개선된다면 Amazon Nova Act를 활용한 합성 모니터링 구현의 근거는 더 강해진다. 운영자가 일상적으로 경보를 무시한다면, 시스템은 AWS가 피하고자 하는 경보 피로 문제를 재현하게 될 것이다.

두 번째 신호는 실제 인터페이스 변경을 견뎌내는 능력이다. 설득력 있는 평가는 의도적으로 취약한 XPath 스크립트가 아니라 잘 구축된 Playwright 검사와 Nova Act를 비교해야 한다.

팀은 어떤 모니터가 라벨 변경, 레이아웃 조정, 컴포넌트 재렌더링, 실험을 견뎌내는지 기록해야 한다. 또한 결정론적 역할 또는 테스트 ID 로케이터는 계속 작동하는데 에이전트가 혼란을 겪는 사례도 기록해야 한다.

이 비교는 시각적 추론이 지속적인 가치를 더하는 지점을 보여줄 것이다. 또한 계약이 안정적이고 작업에 정밀한 제어가 요구되므로 결정론적으로 유지해야 하는 여정도 식별할 것이다.

세 번째 신호는 레퍼런스 아키텍처를 넘어서는 폭넓은 증거다. 사례 연구는 모니터 규모, 실행 빈도, 오탐률, 평균 탐지 시간, 유지보수 시간, 실패 범주를 보고해야 한다.

현재 구현과 성능 주장은 AWS에서 나왔기 때문에 독립적인 결과가 중요하다. 이 접근법이 커머스, 금융, 여행, 의료, 소프트웨어 서비스 전반에 일반화되는지는 프로덕션 경험이 결정할 것이다.

조직은 최종 판결을 기다릴 필요가 없다. 높은 가치를 지니면서 되돌릴 수 있는 여정 하나를 선택해 기존 모니터와 함께 에이전트를 실행할 수 있다. 로그인 준비 상태, 제품 검색, 결제 가능 여부는 범위가 제한된 시험을 제공할 수 있다.

이 시험에는 명시적인 성공 기준이 포함돼야 한다. 확인된 결함 탐지, 오탐 경보, 유지보수 노력, 세션 지속 시간, 각 실패를 설명하는 데 필요한 시간을 측정하라.

비교하는 동안 기존 텔레메트리를 유지하라. 애플리케이션 로그, API 검사, 트레이스, 프런트엔드 오류 보고, 결정론적 테스트는 에이전트의 결론을 평가하는 데 필요한 근거를 제공한다.

Amazon Nova Act를 활용한 합성 모니터링 구현은 보편적인 대체재가 아니라 추가적인 관측 가능성 계층으로서 가장 설득력이 있다. 그 가치는 페이지 구조가 모니터링 코드가 따라가야 할 속도보다 더 빠르게 바뀌는 환경에서 사용자 의도를 검증하는 데 있다.

실무적인 질문은 간단하다. 장애 발생 시 비용이 충분히 크고, 스크립트 검사의 부담을 만들 만큼 자주 변경되며, 에이전트가 지속적으로 실행해도 충분히 안전한 고객 여정은 무엇인가? 거기서 시작해 모든 경보를 측정하고, 모델이 어디까지 맡아야 할지는 프로덕션 증거가 결정하게 하라.