Implementing synthetic monitoring using Amazon Nova Act

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Nova Act와 Amazon Bedrock AgentCore를 활용해 UI 변경에 대응하는 합성 모니터링을 구축하고, 핵심 고객 여정의 검증·예약 실행·실패 알림을 관리형 서비스로 운영하는 방법을 설명한다.

📌 핵심 요약

• 합성 모니터링은 로그인·구매·양식 제출 같은 고객 여정을 주기적으로 실행해 인프라 지표나 API 검사만으로 드러나지 않는 UI 장애를 발견한다. Selenium과 Playwright의 명시적 DOM 선택자는 UI 변경에 취약해 지속적인 유지보수가 필요하다.
• Amazon Nova Act는 DOM 선택자 대신 UI 스크린샷을 처리하는 멀티모달 LLM과 자연어 동작을 사용한다. 초기 기업 고객 사례에서 브라우저 워크플로 정확도가 90%를 넘었지만, 개별 사이트 검증과 적응 실패에 대비한 재시도 설계가 필요하다.
• Amazon Bedrock AgentCore Runtime과 AgentCore Browser tool이 에이전트 실행 및 격리된 브라우저 환경을 제공한다. Amazon EventBridge Scheduler는 중요도에 따라 5분부터 1시간 간격으로 InvokeAgentRuntime을 직접 호출하고, 고객 여정 실패는 Amazon SNS로 알린다.
• 에이전트는 act()로 UI를 조작하고 불리언 스키마를 사용하는 act_get()으로 결과를 검증한다. 테스트에서 일반적인 6단계 여정은 2~4분이 걸렸으며, Nova Act CLI 또는 이를 감싼 deploy.py로 배포할 수 있다. AWS CDK 경로는 예약 실행·알림과 함께 실패한 호출용 SQS 데드레터 큐 및 인프라 장애용 Amazon CloudWatch 경보를 구성한다.
• 알림 피로를 줄이려면 3~5개 핵심 워크플로와 의미 있는 결과 검증부터 시작한다. 샘플은 단계별 단일 시도로 Browser 세션 비용을 줄이지만 오탐 가능성이 있고, 단계별 재시도는 세션 시간을 늘린다. 모니터링 시스템 자체의 실행 빈도·시간도 관찰해야 하며, 제공된 원문의 비용 설명은 다섯 구성 요소를 예고한 뒤 중간에 끊긴다.

🧩 주요 포인트

1. 선택자 의존에서 화면 기반 추론으로 전환 → UI 변경에 따른 유지보수 부담을 줄일 수 있지만, 90%를 넘는 초기 정확도가 개별 사이트의 성공을 보장하지는 않는다.
2. 예약 호출과 고객 여정 검증의 실패 경로 분리 → Amazon CloudWatch 경보는 인프라 장애를, 에이전트의 Amazon SNS 알림은 기능적 실패를 드러내므로 두 경로를 구분해 운영해야 한다.
3. ~5개 핵심 워크플로·결과 중심 검증·단계별 재시도 조정 → 탐지 범위, 오탐 가능성, Browser 세션 비용과 실행 시간 사이의 균형이 운영 품질을 좌우한다.

🧠 상세 정리

1. 고객 여정을 직접 검증하는 합성 모니터링

합성 모니터링은 자동화된 트랜잭션으로 실제 사용자 여정을 재현하고, 로그인·구매·양식 제출 같은 중요한 흐름을 일정에 따라 반복 검증하는 방식이다. 고객이 문제를 겪은 뒤 대응하는 대신 성능 저하나 UI 상호작용의 고장을 더 빨리 발견하는 데 목적이 있다. 전자상거래에서는 상품 검색, 가격과 재고 표시, 장바구니 조작, 결제 확인이 정상적으로 완료되는지를 검사해 고객 접점의 문제를 사전에 찾는다. 금융 서비스의 계정 접근과 거래, 여행·숙박의 예약, SaaS의 가입과 구독 업그레이드, 의료기관의 진료 예약 포털에도 같은 접근을 적용할 수 있다. 글은 Amazon Nova Act와 Amazon Bedrock AgentCore를 결합한 에이전트 기반 구조 및 구현 패턴을 소개하고, 전체 구현을 담은 샘플 저장소가 제공된다고 설명한다.

2. 기존 선택자 기반 자동화의 한계와 Nova Act의 접근

지표·로그·트레이스·API 검사로 인프라 상태를 관찰하더라도, 프런트엔드 배포로 결제 버튼이 고장 나거나 외부 로그인 화면이 바뀌는 고객 여정 수준의 장애는 즉시 드러나지 않을 수 있다. Selenium과 Playwright의 명시적 DOM 로케이터와 선택자는 작은 UI 변경에도 깨질 수 있어 선택자 수정, 실행 타이밍 불안정 처리, 스크립트 갱신에 지속적인 노력이 든다. 원문은 워크플로당 10줄 이상의 명시적 선택자가 필요한 기존 예시와 결제 버튼 클릭·결제 양식 작성·주문 확인을 자연어 3줄로 표현한 Nova Act 예시를 대비한다. Amazon Nova Act는 UI 스크린샷을 처리하는 멀티모달 LLM으로 화면을 추론하므로 대부분의 경우 스타일 변경에 대응하며, 초기 기업 고객 사례에서 브라우저 워크플로 정확도가 90%를 넘었다고 제시한다. 다만 자체 사이트에서 검증하고 적응 실패를 위한 재시도를 설계해야 하며, 기존 기업용 모니터링 플랫폼이 브라우저 검사를 고가의 추가 기능으로 판매하는 점도 감시 범위와 예산 사이의 제약으로 지적한다.

3. 관리형 서비스의 역할과 예약 실행 흐름

Amazon Nova Act는 자연어 동작과 오케스트레이션 로직으로 UI 워크플로를 정의하고 실행하며, Amazon Bedrock AgentCore Runtime은 세션 격리와 안정적인 호출 엔드포인트를 갖춘 서버리스 실행 환경을 제공한다. AgentCore Browser tool은 실행마다 안전하고 격리된 원격 브라우저 환경을 제공해 팀이 브라우저 팜을 직접 운영하는 부담을 줄인다. Amazon EventBridge Scheduler는 여정의 중요도에 따라 5분부터 1시간 간격으로 실행을 예약하고, 범용 대상 기능을 통해 InvokeAgentRuntime을 직접 호출한다. 런타임 안의 에이전트는 AgentCore Browser 세션에서 Nova Act로 UI를 조작하며, 어느 단계에서든 여정이 실패하면 Amazon SNS로 알림을 발행한다. 실패 알림은 이메일, 채팅 연동, 사고 대응 도구 등 구독된 엔드포인트로 즉시 전달되며, 이 구조는 에이전트 실행과 브라우저 인프라를 관리형 서비스로 구성한다.

4. 구현 준비와 결과 중심의 여정 정의

구현에는 Amazon Nova Act, Amazon Bedrock AgentCore의 Runtime과 Browser tool, Amazon ECR, IAM, Amazon EventBridge Scheduler, Amazon SNS에 접근할 수 있는 AWS 계정이 필요하다. 개발 환경에는 Python 3.11 이상, Docker, 자격 증명이 설정된 AWS CLI v2가 필요하며, 운영용 CDK 경로에는 Node.js 18 이상과 AWS CDK도 요구된다. 독립 실행형 deploy.py도 제공되며, deploy.py 또는 CDK로 SNS 이메일 구독을 생성하려면 이메일 주소가 있어야 한다. 여정 정의는 가장 중요한 고객 흐름에서 시작하고, 전자상거래의 예로 홈페이지 로드, 상품 검색, 상세 페이지 이동, 장바구니 추가 검증, 결제 준비 상태를 포함한다. 단순히 동작을 끝냈는지만 보지 않고 검색 결과가 올바르게 나타나는지, 장바구니에 상품이 있는지, 오류 배너가 없는지 명시적으로 확인해야 하며, 원문은 이런 결과 검증이 불완전한 검사와 지나치게 느슨한 검증 조건에서 발생하는 오탐·미탐을 줄인다고 설명한다.

5. 에이전트의 동작·검증·실패 보고

에이전트는 자연어 동작을 논리적인 여정 단계로 묶고 주요 지점에 검증 조건을 배치하며, act()로 UI를 조작하고 불리언 스키마를 사용하는 act_get()으로 결과를 확인한다. 여정이 실패하면 여정 유형, 대상 URL, 소요 시간, 완료된 단계와 실패한 단계를 알림에 담고, 상세 예외 정보는 런타임 로그에 남긴다. 코드는 Nova Act SDK를 직접 사용하며, AgentCore Runtime에 배포하면 실행 환경이 Browser tool을 통해 브라우저 세션의 수명주기를 관리한다. 테스트에서는 일반적인 6단계 여정이 페이지 로딩 시간에 따라 2~4분에 완료됐으므로, 이 시간은 모든 사이트에 적용되는 고정 성능으로 제시된 것은 아니다. 샘플 저장소에는 오류 처리와 단계별 단일 시도 실행을 포함한 전체 에이전트 정의가 있으며, 현재 메서드 시그니처와 SDK 버전은 Nova Act User Guide를 참조하도록 안내한다.

6. Nova Act CLI와 CDK를 통한 배포

예약 실행을 연결하기 전에 Nova Act CLI의 act workflow create, deploy, show 명령으로 에이전트 코드를 패키징하고 컨테이너 이미지를 Amazon ECR에 올린 뒤 AgentCore Runtime을 프로비저닝한다. 배포 후 엔드포인트 ARN은 일정하게 유지되고 업데이트는 새 런타임 버전을 생성하므로, Scheduler의 대상을 매번 바꿀 필요가 없으며 act workflow show로 대상에 사용할 ARN을 확인한다. 샘플의 deploy.py는 Docker와 AWS 자격 증명 같은 사전 조건을 검사하고 CLI 명령 실행, SNS 알림 주제 생성, EventBridge 예약 연결을 묶어 python deploy.py 한 번으로 전체 배포를 수행한다. 별도의 agentcore CLI도 있지만 이 샘플은 Nova Act의 act workflow 명령을 표준으로 사용하며, 반복 가능한 운영 배포를 위한 CDK 스택은 deploy.py의 독립적인 대안으로 제공된다. CDK 스택은 최소 권한 IAM을 적용한 예약 실행, SNS 주제, Scheduler의 InvokeAgentRuntime 호출 실패를 수집하는 SQS 데드레터 큐를 구성하고, 큐의 적재량과 예정된 실행 누락을 감시하는 두 Amazon CloudWatch 경보도 생성한다. 실행 누락 경보는 AWS/Scheduler InvocationAttemptCount 지표에서 데이터 누락을 위반 상태로 처리하며, HTTP 수준에서는 응답하지만 고객 여정이 기능적으로 실패하는 경우는 이 경보가 아니라 에이전트의 SNS 알림으로 드러난다.

7. 알림 피로와 재시도 비용의 균형

원문은 모든 페이지를 빠짐없이 감시하기보다 로그인·결제·계정 접근 같은 3~5개 핵심 워크플로에서 시작하고, 실제 실패 양상과 사업 영향을 근거로 범위를 넓히라고 권고한다. 지나친 감시는 알림 소음을 늘려 실제 장애에 둔감해지게 하므로, 매출이나 고객 신뢰에 직접 영향을 주는 여정에 집중해야 한다는 취지다. 검증 역시 페이지의 모든 DOM 요소를 확인하기보다 검색 결과의 표시와 장바구니 내용 같은 의미 있는 결과를 확인해야 하며, 지나치게 세밀한 조건은 탐지 개선 없이 오탐만 늘릴 수 있다. 샘플 에이전트는 Browser 세션 비용을 줄이기 위해 단계마다 한 번만 실행하지만, 원문이 약 90%로 설명하는 Nova Act의 자연어 적응 성공률 때문에 실제로 존재하는 UI 요소를 찾지 못해 잘못된 알림을 낼 수 있다. 더 낮은 오탐률이 필요한 팀은 실패한 단계를 한 번 다시 실행한 뒤 실패를 선언하는 단계별 재시도를 추가할 수 있지만, 그만큼 세션 시간이 길어지는 비용을 고려해야 한다.

8. 모니터링 시스템 자체의 관찰과 비용 설명의 한계

배포 이후의 운영 과제로 원문은 모니터링 시스템 자체의 관찰과 비용 관리를 제시하며, AgentCore Runtime이 Amazon CloudWatch에 발행하는 에이전트 호출 지표로 실행 빈도와 소요 시간을 추적할 수 있다고 설명한다. 에이전트는 성공할 때 SNS 알림을 발행하지 않고 종료하며 고객 여정 실패를 SNS로 알리므로, 성공 알림이 없다는 동작과 실제 예약 실행 여부를 함께 이해해야 한다. 원문은 실패한 에이전트 호출을 감지하기 위해 SNS 주제에 데드레터 큐를 구성하라고도 안내하고, 앞선 CDK 설명에서는 Scheduler 호출 실패를 수집하는 SQS 데드레터 큐와 인프라 경보의 역할을 별도로 설명한다. 비용 절은 비용이 다섯 구성 요소에서 발생한다고 시작하지만, 제공된 본문에서 완전히 확인되는 항목은 AgentCore Runtime 호출, Browser tool 세션, Nova Act 추론뿐이다. 이후 문장이 Amazon이라는 단어에서 끊기므로 나머지 비용 항목이나 단가·총비용은 확인할 수 없으며, 제공된 자료만으로 비용 구성을 완성할 수는 없다.

🧾 핵심 주장 / 시사점

• 화면 기반 추론은 선택자 유지보수를 줄이는 수단이지만, 자체 사이트 검증과 결과 단언, 적절한 재시도가 함께 있어야 실제 고객 여정의 정상 여부를 신뢰성 있게 판단할 수 있다.
• 예약 실행과 에이전트 호출이 정상이어도 고객 여정은 실패할 수 있으므로, 모니터링 인프라의 상태와 서비스 기능의 상태를 서로 다른 신호로 관찰하는 설계가 중요하다.
• 감시 범위와 검증 조건을 무조건 늘리기보다 사업상 중요한 여정에 집중하고 재시도 수준을 조정하는 접근이 알림의 유용성과 실행 비용을 함께 관리하는 핵심이다.

✅ 액션 아이템

• 로그인·구매 등 3~5개 핵심 워크플로를 선정하고 act_get()을 활용한 결과 중심 검증을 적용.
• Amazon Nova Act의 개별 사이트 성공률과 오탐 가능성을 검증하고, Browser 세션 비용과 실행 시간을 고려해 단계별 재시도 여부를 결정.
• Amazon CloudWatch 경보와 Amazon SNS 알림을 구분해 인프라 장애 및 고객 여정의 기능적 실패 탐지를 확인.

❓ 열린 질문

• 3~5개 핵심 워크플로 중 우선 감시할 고객 여정은 무엇이며, 각 여정에 5분부터 1시간 사이의 어떤 실행 간격이 적절한가?
• Amazon Nova Act를 개별 사이트에 적용했을 때 성공률과 오탐 가능성은 어느 수준이며, 단계별 재시도로 늘어나는 Browser 세션 비용과 실행 시간을 수용할 수 있는가?
• Amazon CloudWatch 경보와 Amazon SNS 알림이 각각 인프라 장애와 고객 여정의 기능적 실패를 제대로 탐지하는지 어떻게 확인할 것인가?