20개 테스트 동시 실행하는 QA Studio의 테스트 스위트

배포 버튼을 누르고 나면 테스트 스크립트가 끝날 때까지 화면만 바라보며 시간을 버리는 일이 잦다. 수십 개의 테스트 케이스를 하나씩 순차적으로 실행하는 기존 방식은 전체 회귀 테스트 시간을 늘려 개발 속도를 늦추는 주범이다. Amazon Nova Act 기반의 QA Studio는 이러한 병목을 해결하기 위해 테스트 스위트를 통한 병렬 실행 구조를 제공한다.

QA Studio에서 테스트 스위트는 개별 유즈케이스를 하나의 그룹으로 묶은 컬렉션을 의미한다. 각 유즈케이스는 Amazon ECS on AWS Fargate 환경에서 독립적인 워커 태스크로 실행된다. 서버리스 컨테이너 환경을 활용해 각 테스트가 완전히 격리된 상태로 구동되는 방식이다. 이 구조 덕분에 최대 20개의 테스트 케이스를 동시에 실행할 수 있다. 개별 테스트가 서로 자원을 공유하지 않고 독립적으로 돌아가므로 전체 테스트 소요 시간을 단축하고 실행 효율을 높인다.

테스트 스위트는 목적에 따라 기능 영역, 릴리스 단계, 테스트 성격으로 분류해 관리한다. 배포 때마다 핵심 경로만 빠르게 확인하는 스모크 테스트, 애플리케이션 전체를 훑는 회귀 테스트, 기능 간 상호작용을 검증하는 통합 테스트로 나누어 구성하는 식이다. 웹 인터페이스에서 이름과 설명을 입력하고 기존 유즈케이스를 추가하면 스위트가 생성된다. 각 유즈케이스가 가진 시작 URL, 변수, 비밀번호, 헤더 설정은 스위트 내에서도 독립적으로 유지되어 실행 시 그대로 적용된다.

스위트를 실행하면 QA Studio는 각 유즈케이스에 대한 개별 실행 기록을 생성하고 이를 워커 큐로 전달한다. 사용자는 스위트 실행 페이지에서 성공, 실패, 진행 중인 테스트의 개수를 한눈에 확인하는 통합 뷰를 통해 전체 현황을 파악한다. 특정 테스트가 실패했다면 해당 결과로 들어가 AI 에이전트가 움직인 궤적 로그, 단계별 스크린샷, 전체 세션 녹화본을 검토해 실패 지점을 찾아낸다. 각 스위트는 실행 이력을 누적하여 관리하므로 특정 기능의 회귀 안정성이 시간이 지남에 따라 어떻게 변화하는지 시계열적으로 추적할 수 있다.

QA Studio의 스위트 구조를 활용하면 복잡한 유즈케이스 묶음을 단 한 번의 실행으로 처리하며 인프라 확장성을 통해 대기 시간을 줄일 수 있다. 이는 배포 후 검증 시간을 단축해 릴리스 주기를 앞당기는 실무적인 QA 워크플로의 기반이 된다.

파이프라인 통합을 위한 qa-studio CLI 구현 방식

배포 버튼을 누른 뒤 팀원들이 하나둘씩 모여 화면을 보며 수동으로 기능을 점검하는 시간 낭비를 제거하기 위해 QA Studio는 CI/CD 러너에서 직접 실행할 수 있는 `qa-studio CLI`를 제공한다. 이 도구는 웹 앱과 동일한 API 백엔드를 공유하여 설정의 일관성을 유지한다. 웹 환경에서는 작업을 Fargate 워커로 분산해 처리하지만, CLI는 명령어를 입력한 CI/CD 러너 머신 내부에서 Amazon Nova Act를 직접 구동해 테스트를 수행한다. 실행 결과는 다시 QA Studio 서버로 전송되어 수동 실행 결과와 자동화 결과를 하나의 이력으로 통합 관리한다.

실무자가 이 환경을 구축하려면 먼저 공식 저장소에서 소스를 가져와 러너 실행에 필요한 라이브러리와 의존성을 포함해 패키지를 설치해야 한다.

pip install .[runner]

여기서 `[runner]` 옵션은 CLI가 실제 브라우저를 제어하고 AI 모델과 통신하는 실행 환경을 갖추게 한다. 자동화 파이프라인은 비대화형 환경이므로 OAuth 2.0 클라이언트 자격 증명 방식을 통해 인증을 처리한다. 이를 위해 웹 인터페이스에서 OAuth 클라이언트를 생성하고, API 접근에 필요한 세부 권한인 스코프를 지정해야 한다. 필수 스코프는 `api/suite.read`, `api/suite.write`, `api/executions.read`, `api/executions.write`, `api/usecases.read`, `api/usecases.execute` 총 6가지다. 설정된 자격 증명을 파이프라인 환경 변수로 등록하면 CLI가 내부적으로 액세스 토큰을 요청하고 캐싱하며, 만료 시 자동으로 갱신해 연속 실행을 보장한다.

인증 설정이 완료되면 단 한 줄의 명령어로 미리 정의된 테스트 스위트 전체를 즉시 실행할 수 있다.

qa-studio run --suite <suite_id>

전체 소스 코드와 상세 설정 방법은 GitHub 저장소에서 확인할 수 있다. CLI는 테스트를 수행하는 동안 각 단계의 상태를 실시간으로 API에 업데이트하며, 완료 후에는 궤적 로그와 세션 녹화본 같은 아티팩트를 자동으로 업로드한다. 개발자는 테스트 시나리오를 수정하지 않고 CLI 명령어만으로 배포 승인 여부를 결정하는 자동화 게이트를 구축할 수 있다.

CLI를 통해 파이프라인에 통합한 후에는, 각 환경(개발, 스테이징, 운영)에 맞는 설정을 효율적으로 관리하는 것이 다음 과제다.

환경별 설정 변경과 보안을 위한 오버라이드 메커니즘

개발 서버에서 성공한 테스트를 스테이징 서버에서 다시 돌리려면 보통 설정 파일의 URL을 일일이 수정해야 한다. QA Studio CLI는 `--base-url` 플래그를 통해 저장된 테스트 정의를 수정하지 않고 실행 시점에 도메인만 즉시 교체한다.

qa-studio run --suite <suite_id> --base-url https://staging.example.com

이 플래그는 시작 URL의 도메인 부분만 바꾸고 뒤에 붙는 세부 경로와 쿼리 파라미터는 그대로 보존한다. 덕분에 하나의 테스트 시나리오를 개발, 스테이징, 운영 환경에 그대로 적용하며 환경 전환에 드는 수동 작업을 없앴다.

사용자 계정이나 테스트용 ID처럼 환경마다 값이 달라지는 항목은 `{{VariableName}}` 형태의 템플릿 변수로 정의한다. 실행 단계에서 `--var` 플래그를 사용하면 런타임에 해당 변수 식별자가 실제 값으로 대체되어 동작한다.

qa-studio run --suite <suite_id> --var username=test_user

테스트 정의를 하나로 유지하면서 실행 시점의 파라미터만 바꾸는 방식으로 관리 효율을 높였다.

비밀번호나 API 키 같은 민감 정보는 AWS Secrets Manager에 암호화하여 저장하고 관리한다. 테스트 단계에서는 실제 값 대신 비밀값의 이름만 참조하며 실제 값은 실행 시점에만 메모리에서 호출해 사용한다. 특히 이 값들은 실행 로그나 이력 기록에 기록되지 않도록 설계되어 CI/CD 파이프라인 설정 파일에 비밀번호를 직접 적지 않고도 안전하게 테스트를 수행할 수 있다.

파이프라인의 중단 여부를 결정하는 종료 코드는 0(성공), 1(테스트 실패), 2(인프라 문제)의 세 가지 상태로 구분한다. 이를 통해 인프라 장애인지 실제 기능 버그인지를 구분해 파이프라인 대응 전략을 다르게 가져갈 수 있다. 테스트 실패 시에는 담당 개발자에게 즉시 알림을 보내고 인프라 문제일 때는 자동으로 재시도 로직을 실행하는 식의 워크플로 구축이 가능하다.

GitHub Actions부터 Jenkins까지, 실제 CI/CD 적용 사례

QA Studio CLI는 결과 리포트 형식을 두 가지로 제공한다. 프로그램이 읽기 좋은 `--format json`과 사람이 로그에서 바로 확인하기 좋은 `--format human` 중 선택할 수 있다. 개발자는 파이프라인의 자동화 단계에서는 JSON을 사용해 후속 작업을 트리거하고, 에러 로그를 직접 훑어볼 때는 human 형식을 선택해 확인 시간을 줄인다.

GitHub Actions에서는 `if: always()` 조건을 설정하여 테스트 성공 여부와 상관없이 녹화본과 로그를 자동으로 업로드하는 구조를 갖춘다. 테스트가 깨진 순간의 화면과 로그가 즉시 아티팩트로 저장되므로, 실패 시점의 화면을 즉시 확인해 재현 시간을 줄일 수 있다.

보안 설정은 파이프라인 구축의 핵심이다. GitLab CI에서는 `OAUTH_CLIENT_ID` 같은 민감한 변수를 protected 및 masked 설정으로 보호해 로그에 노출되지 않게 관리한다. Jenkins는 `withCredentials` 블록을 통해 비밀값을 주입하여 콘솔 출력에 자격 증명이 남지 않도록 제어한다.

CLI로 실행한 테스트의 결과는 웹 인터페이스와 통합된다. CLI가 테스트를 트리거하면 궤적 로그, 스크린샷, 세션 녹화본이 실시간으로 웹 UI에 업로드된다. 파이프라인 로그에서는 단순한 성공과 실패 여부만 확인하고, 상세한 실패 원인은 QA Studio 웹 인터페이스에서 시각적으로 분석하는 분리 전략을 취한다.

한국 AI 실무자가 바라본 에이전트 QA의 도입 기준

Selenium이나 Playwright 같은 전통적인 자동화 도구는 HTML 요소의 ID나 XPath가 조금만 바뀌어도 테스트가 즉시 실패한다. Amazon Nova Act 기반의 QA Studio는 코드를 짜는 대신 자연어로 유즈케이스를 정의한다. 실무자가 "장바구니에 상품을 담고 결제 페이지로 이동한다"라고 적으면 AI 에이전트가 화면을 직접 보고 조작한다. 스크립트 작성 대신 시나리오 설계에 시간을 더 쓴다.

UI 변경이 잦은 현대적인 웹 서비스에서 에이전트 QA는 AI의 시각적 탐색 능력에 의존하므로 UI의 미세한 변화에 유연하게 대응한다. 화면 구성이 바뀌더라도 AI가 '결제 버튼'이라는 목적지를 스스로 찾아내어 클릭하기 때문에, 단순 반복적인 코드 수정 작업이 사라진다.

이 방식은 테스트 케이스가 수백 개 이상으로 방대하고, 마이크로서비스 아키텍처(MSA)를 채택해 환경별 배포가 빈번한 조직에 가장 적합하다. 특히 여러 서비스가 얽혀 있어 영향도 파악이 어렵고 개발, 스테이징, 운영 환경을 빠르게 오가며 검증해야 하는 상황에서 효율이 극대화된다. 복잡한 배포 파이프라인을 가진 조직일수록 도입 실익이 크다.

QA 엔지니어의 핵심 역량은 이제 비즈니스 로직 검증으로 이동한다. 기술적인 구현 디테일이나 라이브러리 버전 관리에 쏟던 에너지를 도메인 지식을 바탕으로 한 엣지 케이스 설계에 투입할 수 있다. 결과적으로 QA 조직은 비즈니스 로직 검증과 엣지 케이스 설계 중심으로 업무가 바뀐다.

배포 때마다 느린 테스트 스크립트를 기다리며 낭비하던 시간은 이제 선택의 영역이다. Amazon Nova Act 기반의 QA Studio는 ECS on AWS Fargate를 통해 최대 20개의 테스트 케이스를 병렬로 실행하고, OAuth 2.0 기반 CLI로 CI/CD 파이프라인에 즉시 통합된다.

결국 실무의 핵심은 테스트 정의를 수정하지 않고 CLI 플래그만으로 개발, 스테이징, 운영 환경에 즉시 대응하는 체계를 만드는 것이다. CLI 플래그 설정을 통해 환경별 대응 워크플로를 구축하고 배포 대기 시간을 제거하는 것이 QA 자동화의 실질적인 완성이다.