Accelerating software delivery with agentic QA automation using Amazon Nova Act – Part 3

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Nova Act 기반 QA Studio는 애플리케이션별 테스트 소유권과 건강도 지표, 팀·역할 기반 접근 제어를 결합해 여러 팀으로 확장되는 QA 자동화의 가시성과 관리 체계를 제공한다.

📌 핵심 요약

• QA Studio는 자연어 테스트 작성과 AI 시각 탐색 실행을 소개한 Part 1, 테스트 스위트와 CI/CD용 CLI를 추가한 Part 2에 이어, Part 3에서 애플리케이션과 팀 기반 사용자 관리를 도입한다. 개별 테스트와 테스트 스위트는 애플리케이션에 속하고 그 소유권을 상속한다.
• QA Studio는 실행 결과를 애플리케이션·환경별 Amazon CloudWatch 사용자 지정 지표로 기록한다. 통과율·실행 횟수·실패 건수와 함께 통과율에서 불안정한 테스트에 대한 감점을 반영한 0~100 건강도 점수를 제공한다.
• 추세 분석은 시간 단위의 7일 보기와 일 단위의 30일 보기를 지원하며 환경별 필터링이 가능하다. 최근 7일간 통과와 실패가 바뀐 빈도로 불안정한 테스트를 정렬하고, 최근 실패에서 Amazon Nova Act 실행 경로 로그와 세션 녹화로 연결한다.
• 각 애플리케이션은 정확히 한 팀이 소유하며 Admin·Team Lead·Editor·Executor·Viewer의 5개 역할은 하위 역할의 권한을 포함한다. Admin은 스튜디오 전체 역할이고, 팀 간 공유는 view·execute·full 수준을 지원하되 실제 권한은 사용자 역할과 공유 수준 중 더 제한적인 쪽을 따른다.
• 접근 제어는 Amazon Cognito 그룹, AWS Lambda 권한 부여자, Amazon DynamoDB의 소유권·공유 정보와 API의 역할·리소스 검사로 구현한다. QA Studio 참조 솔루션은 AWS CDK로 자체 AWS 계정에 배포하며 테스트 데이터·결과·지표는 해당 계정 안에 유지되고, 팀과 역할 및 애플리케이션을 설정한 뒤 테스트를 실행하면 지표가 쌓인다.

🧩 주요 포인트

1. 애플리케이션 단위 소유권과 테스트의 권한 상속 → 테스트가 여러 제품과 팀으로 늘어나도 관리 범위와 책임 주체를 연결하고 개별 테스트마다 권한을 설정하는 부담을 줄인다.
2. 통과율·불안정성·환경별 추세와 실행 증거의 결합 → 단일 빌드의 성공 여부를 넘어 테스트의 안정성과 애플리케이션 개발 과정의 건강도를 살피고 실패 원인을 추적할 수 있다.
3. 팀별 소유권, 누적 역할, 공유 권한 상한과 API의 이중 검사 → 다른 팀에 필요한 접근을 제공하면서도 사용자 역할과 애플리케이션 소유·공유 관계가 허용하는 범위로 작업을 제한한다.

🧠 상세 정리

1. QA 자동화 확장의 병목과 애플리케이션 도입

조직에서 QA 자동화가 확산되면 여러 제품과 팀의 테스트 수백 개가 뒤섞이면서, 테스트 작성보다 정리와 접근 통제가 더 큰 과제가 된다. 특정 애플리케이션의 테스트 커버리지가 현재 건강한지, 문제가 생겼을 때 누가 책임지는지도 쉽게 파악하기 어려워진다. Amazon Nova Act 기반 참조 솔루션인 QA Studio는 Part 1의 자연어 테스트 작성과 AI 시각 탐색 실행, Part 2의 테스트 스위트 및 CI/CD용 CLI에 이어 이러한 조직 차원의 문제를 다룬다. 새로 도입한 애플리케이션은 웹사이트·웹 앱·서비스 프런트엔드 같은 테스트 대상을 나타내며, 개별 테스트인 유스 케이스와 테스트 스위트를 담고 소유권을 부여한다. 생성할 때 이름과 기본 URL을 입력하고 개발·스테이징·운영 등의 환경을 선택적으로 지정하며, 애플리케이션 화면에서 테스트를 만들거나 기존 테스트를 추가하고 스위트로 묶을 수 있다.

2. 통과율과 불안정성을 함께 반영하는 건강도

QA Studio는 개별 실행의 성공 여부를 확인하는 데서 나아가, 시간에 따라 누적되는 결과로 애플리케이션 개발 과정의 건강도를 살피도록 한다. 이를 위해 모든 실행 결과를 애플리케이션과 환경 차원으로 구분한 Amazon CloudWatch 사용자 지정 지표로 기록하고, 애플리케이션 페이지에서 건강도 정보로 보여준다. 화면 상단에는 선택한 기간의 통과율, 전체 실행 횟수, 현재 실패 건수가 표시되어 당장의 상태를 확인할 수 있다. 별도로 제공하는 0~100 건강도 점수는 통과율을 출발점으로 삼고, 통과와 실패를 오가는 불안정한 테스트에 대한 감점을 적용한다. 따라서 통과율이 높더라도 결과가 일관되지 않은 테스트가 있으면 완벽한 상태로 보이지 않으며, 여러 애플리케이션을 살피는 팀은 각 실행 결과를 일일이 열지 않고도 안정적인 대상과 주의가 필요한 대상을 구별할 수 있다.

3. 기간별 추세와 실패 증거를 연결하는 분석

지표 탭은 현재 상태를 보여주는 요약에서 더 나아가 실행 횟수, 성공과 실패, 평균 실행 시간의 변화를 분석한다. 팀은 시간 단위로 표시되는 7일 구간이나 일 단위로 표시되는 30일 구간을 선택하고, 환경 차원을 이용해 특정 환경만 필터링할 수 있다. 이를 통해 같은 테스트 집합이 스테이징과 운영 환경에서 어떻게 다르게 동작하는지 비교할 수 있다. 불안정한 테스트 보기는 최근 7일 동안 통과와 실패가 바뀐 빈도로 유스 케이스를 정렬해, 테스트 스위트에 대한 신뢰를 떨어뜨리는 간헐적 실패를 드러낸다. 최근 실패 보기는 최신 실패 실행을 나열하고 각 항목을 Part 1에서 설명한 Amazon Nova Act 실행 경로 로그와 세션 녹화에 연결하므로, 실패한 테스트에서 에이전트가 실제로 본 화면과 진행 과정으로 한 번의 클릭으로 이동할 수 있다.

4. 팀 소유권과 다섯 역할의 권한 상속

QA Studio에서 각 애플리케이션은 정확히 한 팀에 속하며, 해당 팀 구성원은 그 애플리케이션을 다루고 다른 팀은 별도 공유가 없으면 볼 수 없다. 권한은 Admin, Team Lead, Editor, Executor, Viewer의 다섯 역할로 나뉘며, 상위 역할은 하위 역할이 가진 권한을 모두 포함한다. Admin은 팀별로 부여하는 역할이 아니라 모든 팀·애플리케이션·사용자에 접근하고 팀 생성과 애플리케이션 할당을 수행하는 스튜디오 전체 역할이다. Team Lead는 자기 팀 구성원을 관리하고 팀의 애플리케이션을 생성하며, Editor는 그 안의 유스 케이스와 테스트 스위트를 생성·편집한다. Executor는 테스트를 수정하지 않고 실행하며 Viewer는 애플리케이션과 결과를 읽기만 할 수 있고, 개별 테스트의 접근 권한은 소속 애플리케이션을 따라가므로 수천 개의 테스트마다 별도 권한을 관리할 필요가 줄어든다.

5. 관리자와 팀 리드에게 제공되는 관리 범위

관리자는 Users 페이지에서 모든 계정의 팀과 역할을 한곳에서 확인하고, 팀과 역할로 필터링해 어느 팀에 Team Lead가 있으며 누가 스튜디오 전체 관리자 권한을 갖는지 파악한다. 원문의 참조 배포 예시는 두 팀에 걸친 사용자 네 명으로 구성되며, 역할은 Team Lead 두 명, Viewer 한 명, 스튜디오 전체 관리자 한 명이다. Teams 페이지는 같은 구성원 정보를 팀별로 집계해 구성원 수와 애플리케이션 수를 나란히 보여주고, 전체 Applications 목록은 기본 URL·소유 팀·유스 케이스 수·마지막 실행 상태를 제공한다. 반면 팀 리드의 My Team 화면은 Members, Applications, Use Cases, Shared Access의 네 탭으로 자기 팀의 관리 범위를 제시한다. Members에서는 구성원 추가와 역할의 인라인 변경이 가능하고, Applications에서는 팀 소유 애플리케이션의 테스트 수와 마지막 실행 시간을 확인하며, 예시의 AWS Team 리드는 Team Lead 한 명과 Viewer 한 명으로 이루어진 두 구성원을 관리한다.

6. 팀 간 공유와 실제 권한을 제한하는 상한 규칙

팀 간 협업에서는 플랫폼 팀이 애플리케이션을 소유하면서 기능 팀에는 테스트 실행만 허용하는 식의 접근이 필요할 수 있다. QA Studio는 이를 위해 소유 팀이 다른 팀에 view, execute, full 중 하나의 수준으로 애플리케이션 접근을 공유하도록 지원한다. 공유 애플리케이션에서 사용자의 실제 권한은 자신의 역할과 공유받은 수준 중 더 제한적인 쪽으로 결정되므로, Viewer는 full 공유를 받아도 읽기 전용으로 남는다. 반대 방향의 제한도 적용되어, 원문에서 AWS Team이 AMZN Team에 view 접근을 부여한 애플리케이션은 AMZN Team의 Editor에게도 읽기 전용으로 보인다. 팀 리드는 Shared Access 탭에서 다른 팀에 부여한 접근 수준을 확인하고 공유를 추가·철회·변경할 수 있으며, 이 규칙은 협업을 위해 접근을 넓혀도 수신자의 역할이나 소유 팀이 정한 공유 범위를 넘어서는 권한이 생기지 않게 한다.

7. 서버리스 기반의 권한 검사와 지표 처리

QA Studio는 앞선 글에서 소개한 서버리스 기반 위에 팀 접근 제어와 지표 처리를 추가한다. 각 팀은 역할별 Amazon Cognito 그룹 집합에 대응하며, AWS Lambda 권한 부여자는 요청마다 호출자의 그룹을 API 범위와 팀 컨텍스트로 해석한다. 팀·구성원 관계·애플리케이션 소유권·팀 간 공유 정보는 기존 Amazon DynamoDB 단일 테이블 설계에 저장한다. AWS Lambda와 Amazon API Gateway로 구성된 백엔드는 역할이 허용하는 범위를 검사하고, 호출자의 팀이 애플리케이션을 소유하거나 공유받았는지를 리소스 수준에서 다시 확인한다. 모든 실행은 QAStudio/Executions 네임스페이스에 애플리케이션·환경별 CloudWatch 사용자 지정 지표를 내보내고, 지표 API는 이를 읽어 건강도와 추세 차트를 구성한다. 접근 권한이 Cognito 그룹에서 도출되므로 Part 2의 OAuth 클라이언트 자격 증명 흐름도 같은 모델을 따르며, CI 파이프라인은 필요한 범위만 가진 머신 ID로 인증한다.

8. 자체 계정 배포와 조직 단위 운영으로의 확장

애플리케이션, 지표, 팀 기반 접근 제어는 사용자의 AWS 계정에 배포하는 QA Studio 참조 솔루션에 포함되며, 배포에는 AWS Cloud Development Kit인 AWS CDK를 사용한다. 모든 테스트 데이터와 실행 결과, 지표는 해당 계정 경계 안에 유지되고, 구체적인 배포 및 설정 방법은 QA Studio GitHub 저장소와 문서에서 안내한다. 배포 후 관리자는 팀을 만들고 구성원과 역할을 지정한 다음 애플리케이션을 팀에 할당하며, 각 팀이 테스트를 실행하기 시작하면 건강도 지표가 채워진다. 원문은 자연어 테스트 작성, 테스트 스위트와 CI/CD 통합, 애플리케이션별 건강도 및 팀 권한 관리가 결합되어 여러 팀으로 QA 자동화를 확장하면서도 가시성과 통제를 유지하도록 돕는다고 설명한다. 직접 사용해 보는 흐름으로는 참조 솔루션 배포 후 첫 팀과 애플리케이션을 만들고 유스 케이스 몇 개를 실행해 지표가 형성되는 모습을 확인하는 방법을 제시하며, 실행 에이전트의 추가 정보는 Amazon Nova Act 제품 페이지로 연결한다.

🧾 핵심 주장 / 시사점

• 애플리케이션은 테스트를 묶는 단위이면서 소유권·권한·건강도 지표가 만나는 기준점이므로, 조직 규모가 커질 때 테스트 상태와 책임 주체를 함께 파악하는 데 의미가 있다.
• 통과율에서 불안정성에 대한 감점을 적용하고 기간별 추세를 함께 제공하는 방식은, 성공한 실행이 많다는 사실과 테스트 결과를 신뢰할 수 있다는 판단을 구분하도록 돕는다.
• 팀 간 공유 수준과 사용자 역할 중 더 제한적인 권한을 적용하는 구조는 협업을 위한 접근 확대와 기존 역할 제한을 동시에 유지하며, 백엔드의 역할·리소스 검사가 이를 뒷받침한다.

✅ 액션 아이템

• AWS CDK로 QA Studio를 자체 AWS 계정에 배포하고 팀·역할·애플리케이션을 설정한 뒤 테스트를 실행해 지표 생성 확인.
• 통과율과 0~100 건강도 점수, 7일·30일 추세를 함께 검토하고 불안정한 테스트와 최근 실패의 Amazon Nova Act 실행 증거 확인.
• 애플리케이션별 소유 팀과 view·execute·full 공유 수준을 정하고 사용자 역할과 공유 수준 중 더 제한적인 권한이 적용되는지 확인.

❓ 열린 질문

• QA Studio의 0~100 건강도 점수에서 불안정한 테스트에 대한 감점은 어떤 기준으로 산정되는가?
• 7일·30일 추세와 환경별 지표를 함께 볼 때 어떤 애플리케이션과 불안정한 테스트에 우선적으로 대응해야 하는가?
• 팀 간 협업에 필요한 접근을 제공하려면 애플리케이션 소유권과 view·execute·full 공유 수준을 어떻게 정해야 하는가?