How Rescale built an AI triage agent with Strands Agents and AI-DLC

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Rescale은 AWS의 AI-DLC와 Strands SDK로 야간 테스트 실패를 분류하는 AI 에이전트를 5일 만에 스테이징에 구축하고 수주 내 프로덕션에 배포했으며, 운영 중 사람의 분류와의 일치율은 44%에서 68%로 높아지고 테스트 실패 분석으로 배포가 막히는 시간은 20% 감소했다.

📌 핵심 요약

• Rescale에서는 수백 개의 엔드투엔드 테스트가 주간 프로덕션 배포를 통제하며, 실패 원인 분류와 담당 팀 배정, 여러 로그·모니터링 시스템 및 저장소의 근거 수집에 엔지니어의 반복 작업과 여러 팀의 조율이 필요했다.
• AWS 아키텍트와 Rescale 엔지니어는 5일간의 대면 AI-DLC 워크숍에서 요구사항, 설계, 구현, 평가를 함께 진행했다. AI가 계획과 코드를 생성하고 사람이 범위와 설계를 결정했으며, 자동 PR 생성은 후속 단계로 미뤘다.
• Strands SDK로 구현한 에이전트는 Amazon EKS의 기존 Argo Workflows 파이프라인에서 실행된다. Amazon Bedrock의 Claude Opus 4.8, 과거 실패 패턴 지식 기반, MCP를 통한 Amazon CloudWatch 로그 조회를 활용해 실패를 네 가지 원인으로 분류하고 엔지니어 검토용 수정 권고를 수초 내 생성한다.
• 에이전트는 4일 차에 전체 파이프라인이 스테이징에서 실행됐고, 5일 차에는 PyTest 기반 평가와 초기 분류 일치율 기준선이 마련됐다. 프로덕션 운영 중 사람의 분류와의 일치율은 44%에서 68%로 상승했으며, 골든 데이터셋과 프롬프트를 반복 개선하고 있다.
• Rescale은 프로덕션 도입 이후 테스트 실패 분석으로 배포가 막히는 시간이 20% 감소했다고 보고했다. AI-DLC를 신규 엔지니어링 시뮬레이션 제품의 개발 생명주기에 통합하고 있으며, HPC 시뮬레이션 애플리케이션 카탈로그 관리와 컨테이너 취약점 추적에도 적용하고 내부 Center of Excellence 설립을 검토하고 있다.

🧩 주요 포인트

1. 엔드투엔드 테스트가 주간 배포의 관문이므로, 초기 분류 자동화는 온콜 반복 업무뿐 아니라 변경 사항의 프로덕션 도달 시간을 줄이는 데 연결된다.
2. AI-DLC는 공동 요구사항 구체화와 사람의 설계 승인을 통해 구현 방향을 정렬하고, 기존 Amazon EKS와 Amazon CloudWatch를 활용하는 설계 전환으로 운영 대상과 의존성을 줄였다.
3. 사람과의 분류 일치율 68%와 엔지니어 검토 절차는 현재 성과와 남은 개선 여지를 함께 보여주며, Rescale은 이 경험을 바탕으로 AI-DLC 적용을 다른 엔지니어링 업무로 넓히고 있다.

🧠 상세 정리

1. 반복되는 테스트 분류가 배포 병목으로 이어진 배경

Rescale은 항공우주, 자동차, 에너지, 생명과학, 반도체, 제조 분야의 연구개발·엔지니어링 팀에 지능형 HPC, 모델링·시뮬레이션, 에이전트 기반 디지털 엔지니어링과 AI 물리 기능을 제공하는 플랫폼이다. 플랫폼이 성장하면서 분산 서비스와 수십 개 저장소에 걸친 야간 엔드투엔드 테스트 실패를 분류하는 운영 부담도 커졌다. 엔지니어는 테스트 보고서에서 출발해 로그, 과거 패턴, 소스 코드를 확인하고 원인과 담당 팀을 추정한 뒤, 실제 디버깅에 필요한 근거를 여러 시스템에서 모아야 했다. 수백 개 테스트의 통과가 주간 프로덕션 배포 조건이었으므로, 해결되지 않은 실패는 여러 팀의 수시간 조율과 배포 지연으로 이어질 수 있었다. 팀은 자동 분류와 라우팅을 수행할 에이전트라는 해결 방향을 이미 알고 있었고, 이를 운영 가능한 시스템으로 구현하면서 다른 활용 사례에도 확장할 구조적인 개발 방식을 필요로 했다.

2. AI가 실행하고 사람이 결정하는 AI-DLC

Rescale이 다루려던 문제는 범위가 명확하고 일정이 촉박했지만, 프로덕션에서의 작동을 좌우할 아키텍처 결정을 생략할 수는 없었다. 이에 선택한 AI-DLC는 AI가 작업 계획과 코드, 아키텍처를 제안하되 불명확한 부분은 질문하고, 사람이 각 단계의 결과를 검증하며 방향을 결정하는 오픈소스 AI 중심 개발 방법론이다. 또 비동기 인계 대신 요구사항을 함께 구체화하는 Mob Elaboration과 AI가 구현을 맡는 동안 팀이 함께 구축하는 Mob Construction을 활용한다. Rescale은 코드 작성 자체보다 AI가 팀의 의도를 제대로 이해하도록 만드는 것이 어려운 부분이라고 보았으며, 공동 세션에서 질문에 답하고 다음 단계로 넘어가기 전에 계획을 승인했다. 이러한 방식은 계획·설계부터 테스트·검토·운영까지 AI를 활용하면서도 범위 정의, 결과 검증, 프로덕션 변경 승인과 최종 책임은 엔지니어에게 두는 기존 방향과 맞아떨어졌다.

3. 기존 CI/CD 안에서 작동하는 분류 에이전트

에이전트는 Amazon EKS에서 운영되는 기존 Argo Workflows CI/CD 파이프라인의 한 단계로 실행되며, 수백 개 테스트로 구성된 야간 Playwright 실행에서 실패가 발생하면 전용 포드가 시작된다. Amazon Bedrock의 Claude Opus 4.8을 호출해 각 실패를 인프라 문제, 코드 버그, 불안정한 테스트, 환경 문제 중 하나로 분류한다. 이 과정에서 지식 기반의 과거 실패 패턴을 가져와 맥락을 보완하고, MCP를 통해 Amazon CloudWatch의 포드 로그를 조회해 분류를 뒷받침하는 실행 시점의 근거를 수집한다. 결과에는 구체적인 파일 참조, 함수명, 권장 수정 사항을 담은 구조화된 보고서가 포함되며, 조치를 취하기 전에 엔지니어가 검토한다. Strands SDK로 구현한 에이전트는 여러 실패의 동시 분석과 JSON·HTML 출력을 지원하고, 전체 흐름을 수초 안에 처리해 팀의 기존 보고 파이프라인에 결과를 전달한다.

4. 1~2일 차: 질문으로 범위와 작업 단위를 확정

워크숍은 AWS 아키텍트가 구축을 안내하고 Rescale 엔지니어가 직접 구현에 참여하는 5일간의 대면 공동 작업으로 진행됐다. 첫 1~2일의 착수 단계에서는 구현 전에 비전 문서와 기술 환경 문서로 의도와 조건을 정리했으며, 출발점은 실패를 분류하고 수정 방안을 권고하는 AI 기반 테스트 분류라는 한 문장이었다. 팀은 공동 세션에서 AI가 생성한 20개 이상의 확인 질문에 답하면서 1단계의 범위와 2단계로 미룰 항목을 명시한 요구사항 문서를 만들었다. 다섯 개 사용자 스토리는 과거 실패 패턴 지식 기반, 핵심 분류·수정 권고 에이전트, 트리거·인프라·배포를 담당하는 Argo Workflow 통합, 정확도 측정과 회귀 검증을 위한 평가 체계라는 네 작업 단위로 통합됐다. 단계별 경계와 우선순위는 사람이 결정했고, 자동 풀 리퀘스트 생성 같은 기능은 후속 단계로 남겨 초기 구축 범위를 제한했다.

5. 2~4일 차: 두 차례 설계 전환과 전체 흐름 구현

구축 단계에서 팀은 인터페이스 계약과 데이터 스키마를 정의하고 기능·비기능 설계 질문을 검토한 뒤 아키텍처를 승인했다. 첫 번째 전환은 에이전트 실행 환경을 당초 계획한 Amazon Bedrock AgentCore에서 기존 Argo Workflows가 운영되는 Amazon EKS로 옮긴 것으로, 새로운 런타임 운영을 추가하지 않고 Argo에서 직접 실행할 수 있게 했다. 두 번째 전환은 MCP로 조회하던 외부 로깅 서비스 대신 Amazon CloudWatch를 사용한 것으로, MCP 패턴을 유지하면서 뒤쪽의 로그 출처를 바꿔 의존 관계를 단순화했다. 두 변경 모두 팀이 검증한 뒤 진행했으며, AI-DLC의 공유 요구사항·설계 문서를 직접 갱신해 맥락을 유지했다. Strands SDK로 만든 에이전트를 컨테이너화해 Amazon EKS에 배치한 결과, 4일 차에는 Argo 트리거부터 포드 실행, MCP 로그 조회, 지식 기반 검색, 구조화된 분류 결과 출력까지 전체 파이프라인이 스테이징에서 작동했다.

6. 5일 차: 평가 기준선과 복잡도에 따른 검토 깊이

마지막 운영 단계에서는 실제 호출 모드와 스텁 모드를 지원하는 PyTest 기반 평가 프레임워크를 구축하고, 이후 개선을 측정할 초기 분류 일치율 기준선을 마련했다. Rescale의 CTO와 엔지니어링 부사장 대상 실시간 시연에서는 인프라 실패와 실제 코드 버그를 올바르게 분류하고 파일 수준의 구체적인 수정 권고를 제시했다. 작업별 검토 깊이는 달랐는데, 지식 기반은 최소한의 설계 후 Terraform으로 수시간 내 배포한 반면 핵심 분류 에이전트에는 아키텍처 검토, 인터페이스 계약, 12개 설계 질문과 반복적인 코드 검토를 적용했다. Argo 통합은 인프라 계약과 IAM에 집중했고, 평가 체계는 설계를 가볍게 가져가되 구현에 많은 비중을 뒀으며, 글은 이를 AI-DLC가 복잡도에 맞춰 엄밀성을 조정한 사례로 설명한다. 5일 차 종료 시점에는 실제 테스트 실패를 처리하는 에이전트가 스테이징에서 가동됐고, 측정된 기준선과 프로덕션 전환 경로가 확보됐다.

7. 프로덕션 성과와 사람 검토의 지속

에이전트는 문제 정의에서 5일 만에 스테이징 배포에 도달한 뒤 수주 내 프로덕션에 투입됐으며, 야간 엔드투엔드 테스트 실패의 수동 1차 분류를 자동화했다. 각 실패에 대해 원시 로그만 전달하는 대신 실행 가능한 다음 조치를 담은 구조화된 수정 권고 보고서를 제공하지만, 자동 분류 결과를 검증하는 역할은 엔지니어가 계속 맡는다. 사람의 분류와 에이전트 분류의 일치율은 초기 배포 시점의 44%에서 글 작성 시점의 68%로 상승했으며, 팀은 골든 데이터셋과 프롬프트 엔지니어링을 반복 개선하고 있다. Rescale이 측정한 테스트 실패 분석으로 프로덕션 배포가 막히는 시간은 도입 이후 20% 감소했고, 이 테스트가 주간 배포의 관문이므로 변경 사항이 프로덕션에 도달하는 속도에 직접 영향을 줬다. 온콜 중 반복 분류에 쓰는 시간도 줄었다고 설명하지만, 해당 시간의 감소율이나 일치율 평가에 사용한 표본 규모는 제시하지 않는다.

8. 하나의 에이전트에서 조직의 개발 방식으로 확장

Rescale은 이번 워크숍의 더 큰 효과를 에이전트 하나의 배포뿐 아니라 AI를 활용하는 엔지니어링 접근법의 변화로 설명한다. 참여 엔지니어들은 배운 방식을 이미 다른 업무에 적용하고 있으며, 한 엔지니어는 에이전트 구축을 넘어 AI가 기여할 수 있는 복잡한 개발 작업에서도 앞으로 자신의 업무 흐름에 포함하겠다고 밝혔다. 조직 차원에서는 우수 사례를 정리하고 다른 팀의 독립적인 도입을 돕는 소규모 내부 AI-DLC Center of Excellence를 검토하고 있으나, 설립이 완료됐다고 하지는 않는다. 신규 엔지니어링 시뮬레이션 제품의 표준 개발 생명주기에는 AI-DLC를 통합하면서 시뮬레이션 전문성, 제품 요구사항, 플랫폼 설계, 검증과 운영을 하나의 구조적인 설계 과정으로 연결하고 있다. 핵심 질문을 조기에 해결하고 검토된 결정을 실행 가능한 명세로 남겨 코딩 에이전트에 명확한 수용 기준을 제공하는 접근이며, HPC 시뮬레이션 애플리케이션 카탈로그 관리와 컨테이너 취약점 추적에도 이미 활용하고 있다.

🧾 핵심 주장 / 시사점

• 개선 효과는 실패 분류 자체의 속도뿐 아니라 배포 관문에서의 대기 시간 감소로 나타났다. 반복 운영 업무를 자동화할 때 실제 개발 흐름의 병목과 연결된 효과를 볼 수 있는 사례다.
• Amazon EKS와 Amazon CloudWatch로의 설계 전환은 기존 운영 환경을 활용하는 선택의 의미를 보여준다. 팀은 새로운 런타임과 로그 조회 의존성을 줄이면서 에이전트의 핵심 분석 흐름을 유지했다.
• 분류 일치율 상승과 사람 검토의 병행은 이 사례가 지속적인 평가·개선을 전제로 운영됨을 보여준다. 조직 확장 역시 AI의 구현 능력과 엔지니어의 범위·설계·검증 책임을 함께 유지하는 방향이다.

✅ 액션 아이템

• 골든 데이터셋과 프롬프트의 반복 개선에 따른 사람과의 분류 일치율 68%의 후속 변화 추적.
• 주간 프로덕션 배포에서 테스트 실패 분석으로 배포가 막히는 시간의 20% 감소 효과 지속 확인.
• HPC 시뮬레이션 애플리케이션 카탈로그 관리와 컨테이너 취약점 추적의 AI-DLC 적용 경험을 바탕으로 내부 Center of Excellence 설립 검토.

❓ 열린 질문

• 사람과의 분류 일치율이 44%에서 68%로 상승한 뒤에도 남아 있는 불일치는 네 가지 실패 원인 중 어디에 집중되는가?
• 테스트 실패 분석으로 배포가 막히는 시간의 20% 감소는 주간 프로덕션 배포에서 지속적으로 유지되는가?
• Rescale이 검토 중인 내부 Center of Excellence는 다른 엔지니어링 업무의 AI-DLC 도입을 어떻게 지원할 것인가?