Building intent-driven UI testing with Amazon Nova Act

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Epsilon은 기존 Playwright 회귀 테스트를 유지하면서 Amazon Nova Act와 Amazon Bedrock AgentCore Browser Tool을 결합해 여러 제품팀이 공동 플랫폼에서 사용하는 의도 기반 UI 테스트 서비스를 구축했다.

📌 핵심 요약

• Publicis Groupe 소속 Epsilon의 50명 규모 Agentic Platform 팀은 제품팀별 브라우저 인프라·의존성·인증 통합의 중복 부담을 줄이기 위해 기존 Playwright 회귀 테스트 위에 자연어 기반 UI 테스트를 추가했다.
• Amazon Nova Act는 자연어 테스트 단계를 실행하며, Amazon Bedrock AgentCore Browser Tool은 격리된 임시 브라우저 세션, 실시간 보기, Amazon S3 세션 기록, AWS CloudTrail 감사를 제공한다. AWS IAM 인증과 계정 간 AssumeRole은 기존 보안 모델 및 테넌트 격리에 활용된다.
• 플랫폼 API로 target_url과 자연어 단계를 등록하면 백그라운드 실행기가 CDP WebSocket을 통해 테스트를 수행하고, 단계별 스크린샷·성공 여부·전체 통과율 등을 저장한다. 제품팀은 ui-test-agent의 기록·실행 스킬을 기존 플랫폼 인터페이스로 이용한다.
• 에이전트 생성 예시는 로그인, 입력, 조건부 안내 건너뛰기, 스크롤, 저장 결과 확인을 포함한다. 전용 실행 서비스는 nova-act 3.x와 브라우저 클라이언트 의존성을 분리하며, 성공한 실행 궤적의 재생은 반복 실행의 지연과 비용을 줄이는 방법으로 제시된다.
• 원문은 의도 중심 단계 작성, 런타임 분리, 다중 테넌트 설계, 관리형 관측 기능 활용, 뷰포트 동작 고려를 권고한다. 도입부는 18단계 워크플로와 측정 결과를 예고하지만 제공된 예시 표는 8단계이며, 결과 부분이 잘려 구체적인 성과 수치는 확인할 수 없다.

🧩 주요 포인트

1. Playwright의 결정적 회귀 검증에 자연어 테스트를 추가 → 기존 테스트 자산을 유지하면서 UI 구조 변화에 대한 대응력과 비개발자의 검토 가능성을 보완한다.
2. 관리형 브라우저와 AWS IAM·AssumeRole을 공통 플랫폼에 결합 → 제품팀의 중복 운영 부담을 줄이고 계정별 격리와 감사 가능성을 확보한다.
3. 전용 런타임과 실행 궤적 재생으로 운영 안정성·반복 실행 효율을 추구 → 다만 제공된 원문만으로 실제 비용·지연 개선 폭이나 전체 테스트 성과를 정량 평가하기는 어렵다.

🧠 상세 정리

1. 공통 에이전트 플랫폼에서 출발한 UI 테스트

Publicis Groupe 소속의 데이터·기술·마케팅 서비스 기업 Epsilon은 수억 개의 소비자 프로필과 수천 개 브랜드 관계를 다루며, 빠르게 바뀌는 애플리케이션에 맞춰 UI 테스트를 확장할 필요가 있었다. 내부의 50명 규모 Agentic Platform 팀은 다른 제품팀이 AI 에이전트를 안전하게 구축·배포·통제·운영하도록 공통 인프라를 제공한다. 이 플랫폼에는 스킬 기반 에이전트 빌더, 연합형 신원 관리와 실행 전 권한 확인, Model Context Protocol(MCP) 통합, 계정 간 프로비저닝이 포함된다. 제품팀이 AI 도구를 도입할 때 신원·보안·브라우저 인프라·모델 통합을 각각 다시 해결하지 않도록 하는 것이 공통 플랫폼의 역할이다. Epsilon은 UI 테스트도 이러한 관리형 기능의 하나로 제공하기 위해 Amazon Nova Act와 Amazon Bedrock AgentCore Browser를 결합했다.

2. Playwright를 유지하면서 테스트 범위 보완

Epsilon의 기존 UI 테스트가 제대로 작동하지 않았던 것은 아니며, 웹 애플리케이션의 기능을 검증하던 Playwright 기반 회귀 테스트는 현재도 핵심 기반으로 유지된다. 다만 스크립트형 테스트는 선택자와 페이지 구조에 밀접하게 연결되어 있어, 실제 기능이 정상이어도 외형적인 UI 변경으로 실패할 수 있다는 한계가 있었다. 여러 제품팀이 각자의 애플리케이션에 충분한 테스트 범위를 확보하려면 브라우저 인프라 구축, 의존성 관리, 신원 시스템 통합을 팀마다 반복해야 한다는 부담도 있었다. 플랫폼팀은 새로 참여한 팀이 별도의 맞춤형 CLI를 운영하는 방식보다 기존 에이전트 모델에 맞는 관리형 기능을 원했다. 따라서 목표는 Playwright를 대체하는 것이 아니라 그 위에 의도 기반 테스트를 추가하고, 다른 에이전트 기능과 같은 API로 소비하는 다중 테넌트 서비스로 제공하는 것이었다.

3. 자연어 실행과 관리형 브라우저의 선택 근거

Epsilon은 선택자 기반 테스트를 보완할 자연어 테스트 작성 기능과 다중 테넌트 플랫폼에 맞는 관리형 브라우저 인프라를 핵심 요구사항으로 평가했다. Nova Act는 보상 잔액이 보이는지 확인하라는 식의 평문 영어 지시를 실행하며, 원문은 이런 단계가 외형적인 UI 변화에 더 잘 견디고 비개발자도 읽기 쉽다고 설명한다. Amazon Bedrock AgentCore Browser Tool은 격리된 임시 브라우저 세션을 제공하므로 브라우저 바이너리나 디스플레이 서버를 직접 관리할 필요를 줄인다. 실시간 관찰과 사람의 제어 인계는 CAPTCHA나 다중 요소 인증에 활용할 수 있고, Amazon S3 세션 기록과 AWS CloudTrail 감사도 제공된다. Nova Act의 표준 AWS 자격 증명 체인과 태스크 역할 기반 인증은 별도 API 키 배포 없이 기존 보안 모델에 맞으며, AWS STS AssumeRole을 이용하면 각 팀의 AWS 계정에서 범위가 제한된 역할로 테스트를 실행할 수 있다.

4. 워크플로 등록부터 결과 저장까지의 실행 구조

사용자는 플랫폼 API에 target_url과 자연어 단계 목록을 전달해 워크플로를 만들고, 플랫폼은 생성 시 AWS에 Nova Act 워크플로 정의를 등록한다. 실행 시에는 Python 비동기 작업 처리 프레임워크인 Celery 기반 백그라운드 실행기가 브라우저 세션을 열고, Chromium을 제어하는 표준 인터페이스인 CDP WebSocket을 통해 Nova Act로 각 단계를 수행한다. 실행 중에는 조건부 동작도 처리하며 단계별 스크린샷과 성공·실패를 기록하고, 전체 통과율과 결과 JSON, Amazon S3의 스크린샷, 세션 ID를 저장한 뒤 완료 훅으로 플랫폼에 결과를 반영한다. 아키텍처 설명에서 사용자 요청은 Agent Cloud Frontend와 인증·권한 검사를 수행하는 API Gateway를 거쳐 Django REST API 및 워크플로 관리·실행 조정·스위트 조정 계층으로 흐른다. 테스트 작업은 Amazon SQS에 대기한 뒤 Amazon ECS의 Runner Service가 처리하며, 결과·스크린샷·실행 궤적·HTML 보고서는 Amazon S3에 저장된다.

5. 제품팀의 이용 방식과 핵심 통합 코드

UI 테스트 기능은 표준 에이전트인 ui-test-agent로 노출되며, 시나리오를 대화형으로 탐색하고 자연어 단계를 기록하는 ui-test-recorder와 기록된 단계를 실행해 구조화된 결과를 반환하는 ui-test-executor라는 두 스킬을 갖는다. 새 제품팀이 참여하면 플랫폼팀은 계정 간 IAM 역할을 프로비저닝하고 대상 애플리케이션 URL을 등록한 뒤 기존 플랫폼 API를 통한 에이전트 접근 권한을 부여한다. 이후 제품팀은 다른 플랫폼 기능에 쓰던 인터페이스로 워크플로 생성, 실행 요청, 결과 조회를 수행한다. 핵심 통합 코드는 boto3 세션과 browser_session으로 관리형 브라우저를 열고, generate_ws_headers로 얻은 WebSocket 주소와 헤더를 NovaAct의 CDP 연결 설정에 전달하는 구조다. 시작 URL과 AWS 세션을 지정한 다음 nova_act.act에 자연어 지시를 넘기며, Epsilon은 이 기본 패턴을 다중 테넌트 실행 조정, 결과 수집, 관측 계층으로 감싼다.

6. 에이전트 생성 예시가 보여주는 조건부 처리

제시된 에이전트 생성 예시는 사용자 이름과 비밀번호 입력으로 로그인한 뒤 Create Agent로 이동해 Design a new specification 카드를 선택하는 흐름으로 시작한다. 온보딩 안내 상자가 나타나면 Skip Tour를 선택하고 올바른 페이지인지 확인한 다음, 에이전트 이름과 설명을 입력한다. 이어 Goal Statement 필드가 보일 때까지 스크롤해 내용을 입력하고, 스킬 검색창이 보이지 않으면 다시 스크롤한 뒤 스킬을 검색해 추가한다. 마지막에는 Save를 선택하고 성공 안내를 확인한 후 목록으로 돌아가 새 에이전트가 나타나는지 검증한다. 원문은 안내 상자가 있을 때 처리하거나 대상이 보일 때까지 스크롤하는 동작에 전통적 프레임워크에서는 명시적 분기가 필요하지만 Nova Act에서는 자연어로 표현할 수 있다고 설명한다. 다만 도입부에서 예고한 것은 18단계 워크플로이고 제공된 표는 8단계이므로, 이 자료만으로 나머지 단계나 전체 구성의 관계를 확인할 수는 없다.

7. 런타임 분리와 다중 테넌트 운영 원칙

Epsilon은 Workflow와 IAM 인증을 지원하는 nova-act 3.x 및 Amazon Bedrock AgentCore Browser Tool 클라이언트를 FastAPI 사이드카 형태의 전용 실행 서비스에 고정한다. 이는 주요 백엔드의 Strands 에이전트 스택과 의존성이 충돌하지 않도록 분리하는 조치이며, 실행 서비스가 비활성화되면 워커가 프로세스 내부 실행으로 전환해 배포 중의 복원력을 제공한다. 팀은 Nova Act의 서명 엔드포인트가 브라우저 세션의 리전과 관계없이 us-east-1을 대상으로 한다는 점도 경험했으며, 별도 서비스와 독립적인 의존성 잠금 파일로 디버깅하기 어려운 충돌을 예방할 것을 권고한다. 테스트 단계는 CSS 선택자 조작보다 확인하려는 의도를 표현하도록 작성해 UI 재설계에 대한 내성과 제품 관리자·QA 담당자의 검토 가능성을 높이는 방향을 제안한다. 다중 테넌트 환경은 처음부터 범위가 제한된 IAM 정책과 계정 간 AssumeRole을 사용해 각 테넌트의 역할과 계정에서 실행하도록 설계하며, 이를 통해 격리·감사 가능성·장애 범위 제한을 확보한다.

8. 실행 궤적 재사용과 관측 기능, 성과 확인의 한계

반복 실행의 비용을 줄이기 위해 Epsilon은 draft 상태에서 실행 궤적 재시도를 사용하고, 성공한 궤적을 저장해 active 상태에서 재생한다. 원문은 이 방식이 회귀 테스트처럼 반복되는 실행에서 중복된 대규모 언어 모델의 판단 과정을 생략해 지연과 비용을 줄인다고 설명하지만, 제공된 범위에는 감소 폭을 나타내는 수치가 없다. 관측에는 Amazon Bedrock AgentCore Browser Tool의 실시간 보기, 세션 기록, AWS CloudTrail 통합을 활용해 자체 관측 기능의 유지보수 부담을 줄이고 규정 준수 담당자에게 익숙한 감사 수단을 제공한다. 또한 브라우저의 기본 뷰포트 동작을 고려해 Goal Statement 입력란이 보일 때까지 스크롤하라는 식으로 단계를 작성하고, 페이지 아래쪽 콘텐츠도 처리되는지 확인할 것을 권고한다. 원문은 마지막에 Results and impact 항목으로 넘어가지만 여러 팀에서 운영된다는 취지의 첫 문장 도중에 잘려 있다. 따라서 앞서 설명한 구현과 운영 권고는 정리할 수 있으나, 실제 적용 범위나 측정된 전체 성과를 구체적으로 확정할 근거는 부족하다.

🧾 핵심 주장 / 시사점

• 이 사례의 확장 방식은 개별 테스트의 자연어 전환에 그치지 않고, UI 테스트를 기존 에이전트 플랫폼의 공통 서비스로 제공하는 데 있다.
• 자연어 단계는 UI 변경에 대한 대응력과 비개발자의 검토 가능성을 함께 높이는 수단으로 제시되며, Playwright가 담당하는 결정적 회귀 검증과 병행된다.
• 실행 궤적 재생과 관리형 인프라는 효율 개선의 구체적인 방법이지만, 제공된 결과 부분이 불완전하므로 개선 효과의 크기는 판단할 수 없다.

✅ 액션 아이템

• 기존 Playwright 회귀 테스트를 유지하면서 자연어 기반 UI 테스트로 보완할 범위를 검토.
• Amazon Bedrock AgentCore Browser Tool과 AWS IAM·AssumeRole을 활용한 공통 플랫폼 적용 및 계정별 격리 방식 검토.
• 전용 실행 서비스와 실행 궤적 재생의 적용 가능성을 검토하고, 구체적인 성과 수치 부재를 고려해 비용·지연 개선 판단을 유보.

❓ 열린 질문

• Playwright와 자연어 기반 UI 테스트는 어떤 기준으로 검증 범위를 나누는가?
• 성공한 실행 궤적의 재생은 반복 실행의 비용과 지연을 실제로 얼마나 줄였는가?
• 도입부의 18단계 워크플로와 제공된 8단계 예시는 어떤 관계인가?