How TCS built an agentic test orchestrator with Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

TCS는 Amazon Bedrock AgentCore 기반의 Agentic Test Orchestrator로 BFSI 고객의 프로젝트 맥락과 테넌트 격리를 유지하며 API·브라우저 UI 테스트를 자동화했고, 약 100개 시나리오 비교에서 엔지니어 투입 노력 88% 감소를 보고했다.

📌 핵심 요약

• TCS는 은행·금융서비스·보험(BFSI) 테스트에서 요구사항 해석, 시나리오 설계, 스크립트 유지보수, 실행 및 실패 분석의 반복 작업을 줄이고자 했다. 핵심 요구사항은 프로젝트별 맥락 반영, API·브라우저 UI 테스트 지원, 테넌트별 데이터·지식 저장소 격리, 요구사항부터 증빙·보고까지의 반복 가능한 처리였다.
• Amazon Bedrock의 모델 선택권과 AgentCore runtime의 수요 대응 확장 및 세션별 격리 microVM을 활용했다. Strands Agents SDK로 구축한 전문 에이전트가 생성·대화형 수정·요구사항 변환·점진적 확장·실행을 분담하고, 프로젝트 자료는 Amazon Bedrock Knowledge Bases에서 테넌트·프로젝트·세션 맥락으로 검색한다.
• 플랫폼은 공유 컴퓨팅과 테넌트별 데이터·신원·키 분리를 결합한 다중 테넌트 SaaS다. 각 테넌트에 Kubernetes namespace, Amazon Cognito 사용자 풀, AWS KMS 키, Amazon S3 버킷, Amazon DynamoDB 테이블 및 Amazon Bedrock Knowledge Bases를 제공한다.
• API 테스트는 Amazon ECS의 AWS Fargate로, Selenium UI 테스트는 Chrome과 가상 디스플레이를 실행하는 Amazon EC2 기반 ECS로 보낸다. LangGraph가 실행 순서와 제한된 재시도를 통제하며, 코드 오류만 수정 대상으로 삼고 연결·인증 같은 환경 오류는 코드 수정기에 전달하지 않는다.
• TCS는 BFSI 고객용으로 운영 중인 이 솔루션을 약 100개 테스트 시나리오의 기존 수작업 절차와 비교했다. 시나리오당 엔지니어 노력은 약 2시간에서 약 14분으로, 전체는 약 200시간에서 약 24시간으로 줄어 88% 감소를 보고했지만, 제공된 원문은 수치 출처 설명 도중 끊겨 추가 측정 조건을 확인할 수 없다.

🧩 주요 포인트

1. 프로젝트 맥락 검색과 전문 에이전트의 단계별 분업 → 단일 프롬프트의 통제 한계를 보완하고 연결된 요구사항 변경을 테스트에 반영하는 구조.
2. 공유 컴퓨팅·테넌트별 데이터 격리와 API·UI별 실행 환경 분리 → 다중 테넌트 운영과 서로 다른 테스트 인프라 요구를 함께 수용.
3. 고정된 실행 순서·제한된 코드 수정과 88% 노력 감소 보고 → 통제와 효율을 결합한 사례지만, 측정 조건이 불완전해 성과의 일반화에는 한계.

🧠 상세 정리

1. 반복 작업을 줄이기 위한 네 가지 요구사항

TCS가 대규모 테스트를 수행하는 BFSI 고객 환경에서는 애플리케이션 코드 작성보다 이후의 요구사항 해석, 시나리오 설계, 자동화 작성·유지보수, 실행 환경 준비, 실패 조사와 검토 증빙 취합이 릴리스의 제약으로 작용했다. 목표는 품질 엔지니어를 대체하는 것이 아니라 반복적인 변환·실행 작업을 줄여 위험 분석, 탐색적 테스트와 릴리스 판단에 더 많은 시간을 쓰도록 하는 것이었다. 이를 위해 프로젝트 고유 맥락에 근거한 테스트, API와 브라우저 UI 지원, 테넌트별 데이터·지식 저장소 격리, 요구사항 수집부터 증빙·보고까지 반복 가능한 경로라는 네 가지 조건을 설정했다. 기존 자동화는 실행 속도를 높였지만 시나리오와 스크립트 작성, 로케이터·의존성 유지보수, 실패 진단은 여전히 사람이 맡았고 연결된 사용자 스토리가 바뀌면 이전 스크립트가 낡아지는 문제가 남았다. TCS는 단일 생성형 AI 프롬프트만으로 다단계 엔지니어링 작업을 통제하기 어렵다고 보고, 전문 에이전트와 결정적 감독자, 실행 워크플로를 결합했다.

2. AgentCore 선택과 전체 처리 구조

TCS는 에이전트 인프라보다 테스트 로직에 개발 역량을 집중하기 위해 Amazon Bedrock AgentCore를 선택했으며, 그 근거로 모델 선택권, 수요에 따른 실행 확장, 세션별 격리를 제시했다. Amazon Bedrock에서는 시나리오 설계나 코드 생성 등 작업에 맞는 모델을 선택하고 새 모델을 도입할 수 있으며, AgentCore runtime은 여러 테넌트의 동시 세션을 지원하고 각 세션을 별도 microVM에서 실행한다. 플랫폼은 Amazon CloudFront 뒤의 Amazon EKS 웹 애플리케이션과 Amazon Cognito 로그인을 통해 요구사항을 받고, Strands Agents SDK로 만든 전문 에이전트를 AgentCore runtime에서 구동한다. 입력은 Jira 스토리, BRD, Swagger 명세, 업로드 문서, GitLab 소스 폴더와 캡처한 UI 흐름이며, 산출물은 테스트 시나리오, Gherkin 기능 파일, 실행 가능한 Java 또는 Python 테스트다. 생성된 테스트는 Amazon ECS에서 실행되고 결과와 산출물은 Amazon S3 및 Amazon DynamoDB에 저장되며, 로그는 Amazon CloudWatch에 수집되고 진행 상황과 보고서는 테넌트별 웹 애플리케이션에 표시된다.

3. 공유 제어 영역과 테넌트별 격리

플랫폼은 컴퓨팅 자원을 공유하면서 데이터와 신원은 테넌트별로 분리하는 구조를 채택해, 금융서비스 고객이 요구하는 데이터·키 경계를 확보한다. 공유 제어 영역에는 Amazon EKS 클러스터, 컨테이너 레지스트리, 관리 포털, 테넌트 등록부, 온보딩 자동화, Amazon CloudFront 배포와 AWS WAF 보호가 포함된다. 각 테넌트의 애플리케이션 영역에는 전용 Kubernetes namespace, Amazon Cognito 사용자 풀, AWS KMS 키, Amazon S3 버킷, Amazon DynamoDB 테이블과 Amazon Bedrock Knowledge Bases가 제공된다. 신규 테넌트 등록은 관리 API가 대기 상태의 테넌트 레코드를 기록하고 Amazon EventBridge로 이벤트를 발행한 뒤, AWS CodeBuild가 AWS CDK를 사용해 해당 인프라를 배포하는 이벤트 기반 방식으로 진행된다. 이 방식은 테넌트별 신원과 데이터 경계를 유지하면서도 인프라 프로비저닝을 반복 가능한 절차로 만든다.

4. 프로젝트 맥락에 근거한 테스트 생성

TCS는 일반적인 프롬프트가 아니라 각 프로젝트의 도메인과 요구사항을 반영하도록 맥락 검색을 플랫폼의 기본 기능으로 구성했다. 업로드한 요구사항과 생성 산출물은 Amazon S3에, 세션 메타데이터는 Amazon DynamoDB에 저장하며, 프로젝트 문서와 동기화한 소스 파일은 벡터 임베딩을 사용해 Amazon Bedrock Knowledge Bases에 색인한다. 에이전트에 자료를 전달하기 전에 테넌트·프로젝트·세션 맥락으로 검색을 필터링해 한 고객의 자료가 다른 고객의 테스트에 반영되지 않도록 한다. 지원하는 맥락에는 Jira 스토리와 연결된 스토리 체인, BRD, Swagger 정의, 참조 코드, 로케이터 문서, 설정 모듈, 테스트 데이터와 GitLab 소스 폴더가 포함된다. UI 자동화에서는 별도 캡처 서비스가 Puppeteer를 사용해 URL과 자연어 목표를 UI 흐름 문서 및 XPath 로케이터 문서로 변환하며, 이 자료도 테스트 생성에 필요한 프로젝트 맥락을 제공한다.

5. 전문 에이전트의 역할 분담

플랫폼은 규제 환경의 작업 흐름을 통제하기 위해 전체 작업을 하나의 대형 프롬프트에 맡기지 않고, AgentCore runtime의 컨테이너화된 서비스에서 실행되는 전문 에이전트로 나눈다. 생성 에이전트는 구조화된 시나리오를 만들고 이를 Gherkin으로 변환한 뒤 Java 또는 Python 자동화 코드를 생성·검증하며, 생성 런타임은 시나리오·Gherkin·코드 생성·검증 전용 도구로 요청을 전달한다. 채팅 에이전트는 요청을 정보 질의와 수정 요청으로 분류해 답변하거나 현재 산출물을 변경하고, 동적 작업 에이전트는 BRD 맥락을 검색해 요구사항과 인수 조건을 갖춘 사용자 스토리를 만든다. 점진적 생성 에이전트는 연결된 Jira 스토리 체인에 걸쳐 기존 시나리오·Gherkin·코드를 확장하므로 매번 처음부터 생성할 필요를 줄인다. 실행 에이전트는 산출물 조회, 실행 환경 선택, 테스트 실행, 실패 분류, 통제된 수정과 최종 결과 저장을 담당하며, 각 에이전트는 테스트 수명주기의 특정 단계를 맡는다.

6. API와 UI에 맞춘 실행 환경

TCS는 API 테스트와 브라우저 기반 UI 테스트의 인프라 요구가 다르다는 점을 반영해, 실행 에이전트가 생성된 코드에서 테스트 유형을 감지하고 적합한 환경으로 보내도록 했다. API 테스트는 AWS Fargate를 사용하는 Amazon ECS에서 실행하고, Selenium UI 테스트는 Amazon EC2 기반 Amazon ECS 클러스터에서 실행해 Chrome과 가상 디스플레이를 사용할 수 있게 한다. UI 실행에서는 FFmpeg로 가상 디스플레이를 캡처하고 HTTP Live Streaming(HLS) 스트림을 Amazon S3에 게시해 Amazon CloudFront로 전달할 수 있다. 테스트 로그는 Amazon CloudWatch로 보내고 생성된 Cucumber 보고서는 Amazon S3에 저장하며, 보고서에는 시간 제한이 있는 접근을 제공한다. 이 구조는 하나의 플랫폼에서 두 테스트 유형을 지원하면서 실행 환경, 실행 중 관찰 기능, 결과 보고를 각 작업의 특성에 맞게 연결한다.

7. 제한된 재시도와 코드 수정 절차

실행 에이전트는 자동 수정이 BFSI 파이프라인의 통제 범위 안에서 이루어지도록 조회·실행·수정·저장 단계를 LangGraph 워크플로로 정의한다. LangGraph의 명시적 상태 그래프는 단계 순서와 재시도 횟수의 경계를 정하고, AgentCore runtime은 이 워크플로를 수행하는 에이전트의 호스팅·확장·격리를 담당한다. 조회 노드는 테스트 프로젝트와 생성 자산을 가져와 파일을 정제하고 프레임워크를 감지하며, 실행 노드는 선택한 ECS 작업을 시작해 상태를 관찰하고 로그와 결과를 수집·분석한다. 실패가 코드 오류로 분류되고 재시도 정책이 허용할 때만 수정 에이전트에 제한된 오류 맥락을 전달하며, 안전 검사는 빈 파일, 예상하지 못한 새 파일과 과도한 파일 크기 변경을 거부한다. 연결이나 인증 실패 같은 환경 오류는 코드 수정기에 보내지 않고, 저장 노드는 최종 코드, 상태, 시도 횟수, 로그, 파싱한 결과와 보고서 위치를 보존한다.

8. 계층별 보안과 운영 관측

솔루션은 규제 대상인 BFSI 테넌트를 지원하기 위해 신원·네트워크·데이터·애플리케이션 계층에 걸쳐 보안 통제를 적용한다. 플랫폼 관리자와 각 테넌트는 별도의 Amazon Cognito 사용자 풀을 사용하며, 백엔드는 JSON Web Token(JWT) 검증과 역할 기반 권한 확인을 수행한다. 데이터 계층에서는 테넌트별 AWS KMS 키와 암호화된 Amazon S3 저장소를 사용하고 DynamoDB 접근 범위를 테넌트로 제한하며, Jira와 GitLab 자격 증명은 AWS Secrets Manager에 보관한다. Amazon EKS에서는 Kubernetes namespace, NetworkPolicy와 ResourceQuota로 테넌트를 분리하고 컨테이너를 비루트 사용자로 실행하며 Linux capabilities를 제거한다. 네트워크 경계에는 AWS WAF 관리형 규칙과 요청 속도 통제를 적용하고 Amazon CloudFront와 Application Load Balancer를 통해 HTTPS로 전달하며 제한적인 보안 헤더를 사용한다. 운영 관측에는 에이전트 활동을 기록하는 OpenTelemetry 추적과 Amazon CloudWatch 로그 및 Container Insights를 활용한다.

9. 운영 성과와 제공된 근거의 범위

TCS는 Agentic Test Orchestrator를 BFSI 고객을 위한 운영 환경에서 사용하고 있으며, 노력 절감 효과를 평가하기 위해 약 100개 테스트 시나리오로 구성된 대표 BFSI 작업을 기존 절차와 비교했다. 기존 수작업에서는 시나리오를 설계하고 스크립트를 작성해 실행하는 데 시나리오당 약 2시간의 엔지니어 노력이 들어 전체 약 200시간이 필요했다고 설명한다. 오케스트레이터를 사용한 경우 평균 노력은 시나리오당 약 14분, 같은 작업 전체는 약 24시간으로 줄었으며, 원문은 이 비교에서 88% 감소했다고 보고한다. 이 수치는 해당 작업에서 측정한 엔지니어 투입 노력의 변화로 제시되므로 전체 릴리스 소요 시간이나 모든 고객의 성과로 확대해 해석할 근거는 제공되지 않는다. 또한 제공된 원문은 수치의 출처를 설명하는 괄호 문장이 시작된 뒤 중간에 끊겨 있어, 추가 측정 조건과 단서까지 확인할 수 없다는 한계가 있다.

🧾 핵심 주장 / 시사점

• 자동화의 범위를 테스트 실행에서 요구사항 해석·시나리오·코드 생성·실패 처리로 넓힌 점이 핵심이다. 전문 에이전트와 프로젝트 맥락 검색은 기존 자동화가 남겨 둔 반복 작업을 줄이기 위한 연결 구조다.
• AgentCore runtime의 세션별 microVM 격리와 테넌트별 신원·데이터·키 분리는 서로 다른 수준의 경계를 담당한다. 이 사례의 격리 구조는 실행 세션뿐 아니라 검색 맥락과 저장 자원까지 포함한다.
• 자동 수정의 범위를 코드 오류로 제한하고 환경 오류를 제외한 설계는 실패 유형에 따라 처리 경로를 나눈다는 의미가 있다. 88% 노력 감소는 이 통제 구조를 포함한 특정 비교의 결과이며, 제공된 자료만으로 다른 작업의 효과까지 확정할 수는 없다.

✅ 액션 아이템

• 테스트 생성 적용 시 프로젝트별 맥락 반영과 테넌트별 데이터·신원·키 분리 조건 검토.
• API·브라우저 UI 테스트의 실행 환경 분리와 코드 오류에만 적용하는 제한된 재시도·수정 범위 확인.
• 88% 노력 감소의 적용 가능성 판단에 앞서 약 100개 테스트 시나리오 비교의 추가 측정 조건 확인.

❓ 열린 질문

• 테넌트·프로젝트·세션 맥락으로 검색한 자료가 테스트에 적절히 반영됐는지는 어떻게 검증하는가?
• 코드 오류와 연결·인증 같은 환경 오류는 어떤 기준으로 구분하며, 제한된 재시도의 허용 범위는 어떻게 정하는가?
• 약 100개 테스트 시나리오에서 보고한 88% 노력 감소의 추가 측정 조건은 무엇인가?