모든 엔지니어링 팀이 이러한 의식적인 절차를 알고 있으며, Rescale도 예외는 아니었습니다. 야간 테스트 스위트가 실패하면, 당직 엔지니어가 로그를 확인하고 근본 원인을 분류한 뒤 적절한 팀에 전달하고, 다음 날 아침에 또 같은 과정을 반복하게 됩니다. 규모가 커져 분산된 서비스와 수십 개의 저장소에 걸쳐 이러한 의식은 당직 로테이션 속에 숨어 있는 풀타임 직업이 되어 버립니다.
Rescale 는 AI 시대를 위해 구축된 디지털 엔지니어링 플랫폼입니다. 항공우주, 자동차, 에너지, 생명과학, 반도체, 제조 분야의 R&D 및 엔지니어링 팀이 Rescale 플랫폼을 사용하여 혁신을 가속화하며, 지능형 HPC, 고급 모델링 및 시뮬레이션, 에이전틱 디지털 엔지니어링, AI 물리를 단일 플랫폼에서 함께 제공합니다.
코딩을 넘어, Rescale은 엔지니어가 결과에 대해 책임을 지는 전제 아래 계획과 설계부터 구현, 테스트, 리뷰, 운영에 이르는 엔지니어링 전 주기에 걸쳐 AI를 활용합니다. AI가 제안하고 실행할 수는 있지만, 범위를 정의하고 작업을 검증하며 프로덕션 변경을 승인하는 것은 사람입니다. 그结果 엔지니어는 아키텍처, 제품 판단, 그리고 복잡한 분산 시스템을 운영하는 데 필요한 맥락에 집중할 수 있습니다.
이 글에서는 Rescale이 어떻게 다음을 사용했는지 보여드립니다: AI 기반 개발 수명 주기(AI-DLC) AWS에서 프레임워크를 활용하여 지능형 트리아지 에이전트를 구축했습니다. 이들은 문제 정의부터 스테이징 배포까지 5일, 프로덕션까지는 몇 주 만에 도달했습니다. 이 게시물에서는 Rescale이 자사의 엔지니어링 조직 전반으로 AI-DLC를 확장하는 방법도 다룹니다.
The challenge
Rescale의 플랫폼이 성장함에 따라 이를 운영·유지하는 부담도 커졌습니다. 엔지니어들은 반복적이지만 중요한 작업, 즉 자동화된 엔드투엔드(end-to-end) 테스트 실패를 분류하는 데 상당한 시간을 소모하고 있었습니다. 테스트 스위트에서 수백 개의 테스트 케이스가 실행되며, 실패가 발생하면 모든 알림, 버그 리포트, 에스컬레이션을 분류하고 우선순위를 정해 적절한 팀에 전달해야 했습니다. 전달 후에는 디버깅을 시작하기 전에도 여러 로깅 및 모니터링 시스템과 여러 소스 저장소에서 증거를 수집해야 했습니다. 엔드투엔드 테스트를 통과해야 서비스를 프로덕션에 배포할 수 있었기 때문에, 이러한 시스템 장애의 디버깅은 새로운 변경 사항을 프로덕션에 반영하는 중요 경로(critical path)에 있었습니다.
수동 워크플로에서는 엔지니어들이 테스트 보고서에서 로그, 과거 패턴, 소스 코드로 이동하며 장애를 분류하고 담당 팀일 가능성이 높은 팀을 파악했습니다. 이러한 통합 테스트가 주간 프로덕션 릴리스의 게이트 역할을 하기 때문에, 해결되지 않은 장애가 발생하면 배포가 진행되기 전까지 여러 팀이 수 시간 동안 조율 작업에 묶일 수 있었습니다.
팀은 해결책이 어떤 모습이어야 하는지 명확하게 알고 있었습니다. 바로 이슈를 자동으로 분류하고 라우팅할 수 있는 지능형 에이전트였습니다. 그들이 찾고 있던 것은 그러한 이해를 바탕으로 프로덕션 환경에서 작동하는 시스템으로 나아갈 수 있는 구조화된 방법, 그리고 이후 다른 사용 사례에도 이 접근 방식을 확장할 수 있을 만큼 충분한 구조였습니다.
Rescale가 AI-DLC를 선택한 이유
Rescale의 트리아지 에이전트는 촉박한 일정 안에서 범위가 명확히 정의된 과제였습니다. 팀은 그 속도에 맞춰 진행하면서도 시스템이 프로덕션 환경에서 제대로 작동할지를 결정짓는 아키텍처 결정을 건너뛰지 않는 개발 방식이 필요했습니다.
The AI 기반 개발 수명 주기(AI-DLC) 소프트웨어 개발을 위한 오픈 소스, AI 중심 방법론으로, 두 가지 아이디어를 중심으로 만들어졌습니다:
- AI가 실행하고 인간이 결정합니다: AI가 작업 계획을 세우고, 코드를 작성하고, 아키텍처를 제안하지만, 추측하는 대신 의사결정 지점을 제시하고 명확히 할 질문을 묻습니다. 인간은 각 단계에서 검증하고 방향을 이끕니다.
- 팀 세션이 비동기 인계를 대체합니다: 한 사람이 혼자 개발하고 나중에 리뷰를 요청하는 대신, AI-DLC는 집중적인 그룹 세션을 사용합니다. 즉, 요구 사항을 함께 정의하는 Mob Elaboration과 AI가 구현을 처리하는 동안 함께 빌드하는 Mob Construction입니다. 의사 결정은 실시간으로 이루어집니다.
AI-DLC가 적합했던 이유는 어려운 부분이 코드를 작성하는 것이 아니었기 때문입니다. 진짜 어려운 점은 AI가 팀이 무엇을 만들고자 하는지 이해하도록 만드는 것이었습니다. 모브 세션(mob session)에서 Rescale 엔지니어들은 AI의 질문에 함께 답하고 AI가 다음 단계로 넘어가기 전에 각 계획을 승인했기 때문에 어떤 것도 가정에 맡겨지지 않았습니다.
솔루션 개요
Rescale의 트리아지(triage) 에이전트는 매일 밤 실행되는 엔드투엔드 테스트 실패의 분류 및 라우팅을 자동화합니다. 이 에이전트는 Amazon Elastic Kubernetes Service(Amazon EKS)에서 Rescale의 기존 Argo Workflows 지속적 통합 및 지속적 전달(CI/CD) 파이프라인 내의 한 단계로 실행됩니다. 수백 개의 테스트 케이스로 구성된 매일 밤의 Playwright 스위트에서 실패가 발생하면 파이프라인이 트리아지 에이전트 파드를 트리거합니다.
에이전트는 다음 단계를 수행합니다:
- Amazon Bedrock에서 Claude Opus 4.8을 호출하여 각 실패를 근본 원인 범주, 즉 인프라 문제, 코드 버그, 불안정한 테스트(flaky test), 또는 환경 문제로 분류합니다.
- 지식 베이스에서 관련성 있는 과거 장애 패턴을 검색하여 추가 맥락을 제공합니다.
- 분류를 뒷받침하는 런타임 증거를 위해 Model Context Protocol(MCP)을 통해 파드 로그를 조회합니다.
- 엔지니어가 조치를 취하기 전에 검토할 수 있도록 구체적인 파일 참조, 함수 이름 및 권장 수정 사항이 포함된 구조화된 Remediation 보고서를 생성합니다.
에이전트는 이 워크플로를 몇 초 만에 완료하고 팀의 기존 보고 파이프라인에 직접 결과를 출력합니다. 다음 다이어그램은 이러한 구성 요소들이 어떻게 결합되는지 보여줍니다:
Figure 1: Rescale의 AI 트리아지(triage) 에이전트 아키텍처. Amazon EKS에서 실행되며, 분류에는 Amazon Bedrock을, 과거 장애 패턴용 지식 베이스를 사용하고, Amazon CloudWatch 통합을 통한 MCP 기반 로그 검색을 수행합니다
AI-DLC 워크숍 경험
이 프로젝트는 5일간의 대면 워크숍 형식으로 진행되었습니다. AWS 아키텍트가 빌드를 안내하는 동안 Rescale 엔지니어들이 직접 키보드를 잡고 실시간으로 함께 개발했습니다.
인셉션(Inception) 단계(1–2일차): 비전에서 검증된 요구사항까지
팀은 요구사항 범위를 정하는 것으로 시작했으며, 작업을 시작하기 전에 비전 문서와 기술 환경 문서에 의도를 담아 기반을 마련했습니다. 그 의도는 “실패를 분류하고 수정 방안을 추천하는 AI 기반 테스트 트리아지를 원한다”는 단 한 문장으로 시작되었습니다. 팀은 모브(mob) 형식으로 협업하며 AI가 생성한 20개 이상의 명확화 질문에 답했습니다. 그 결과 Phase 1 경계가 명확히 정의되고 Phase 2 항목은 보류된, 범위가 지정된 요구사항 문서가 만들어졌습니다. 5개의 사용자 스토리가 4개의 작업 단위로 통합되었습니다:
- 과거 장애 패턴을 위한 지식 베이스.
- 핵심 분류 및 수정 엔진으로서의 AI 트리아지 에이전트.
- 트리거, 인프라 및 배포를 위한 Argo Workflow 통합.
- 정확도 측정 및 회귀 게이팅을 위한 Evaluation Harness.
중요한 경계는 인간의 결정에 의해 정해졌습니다: Phase 1과 Phase 2의 구분, 우선순위 순서, 그리고 자동화된 풀 리퀘스트(PR) 생성과 같은 보류된 기능들이 그것입니다.
컨스트럭션(Construction) 단계(2–4일차): 아키텍처에서 실행되는 코드까지
팀은 인터페이스 계약과 데이터 스키마를 정의하고, 기능적·비기능적 설계 질문들을 완료하며 아키텍처를 승인했습니다. 빌드 과정에서 두 번의 아키텍처 전환이 있었고, 팀은 방향을 바꾸기 전에 각각을 검증했습니다.
먼저, 팀은 에이전트를 Amazon Bedrock AgentCore에서 호스팅할 계획이었으나, Rescale이 이미 Argo Workflows CI/CD 파이프라인을 운영 중인 Amazon EKS로 옮겼습니다. 에이전트를 기존 클러스터에 두면 새로운 런타임을 운영할 필요가 없고 Argo에서 직접 트리거하는 경로가 확보되었습니다. 다음으로, 초기 빌드에서 에이전트는 MCP를 통해 서드파티 로깅 서비스에서 로그 증거를 가져왔습니다. 팀은 로그 검색을 Amazon CloudWatch로 옮겨 의존성 체계를 단순화했습니다. MCP 패턴은 그대로 유지되었고, 그 뒤에 있는 소스만 바뀌었습니다. AI-DLC는 요구사항과 설계 결정을 공유 문서에 보관하기 때문에, 팀은 해당 문서들을 그 자리에서 업데이트하면서 맥락을 잃지 않고 계속 개발할 수 있었습니다.
에이전트는 Strands SDK를 사용하여 구축되었으며, JSON 및 HTML의 구조화된 출력으로 동시 장애 분석을 지원하고 Amazon EKS에서 컨테이너화되었습니다.
4일차까지 전체 파이프라인이 스테이징에서 실행 중이었습니다: Argo 워크플로우 트리거, 트리아지 에이전트 pod, MCP 로그 쿼리, 지식 베이스 검색, 그리고 구조화된 트리아지 출력.
오퍼레이션(Operations) 단계(5일차): 평가 및 인계
팀은 라이브 및 스텁(stubbed) 테스트 모드를 갖춘 PyTest 기반 평가 프레임워크를 구축하여, 에이전트를 측정하고 개선하기 위한 초기 분류 일치도 기준선을 확립했습니다. 에이전트는 Rescale의 CTO와 엔지니어링 부사장에게 라이브로 시연되었으며, 인프라 장애와 실제 코드 버그를 모두 정확히 분류하고 파일 수준의 구체적인 수정 권장사항을 제시했습니다.
AI-DLC가 복잡성에 맞춰 엄격함을 조정한 방식
모든 작업 단위가 동일하게 다뤄지는 것은 아닙니다. 지식 베이스는 최소한의 설계만 필요했고 몇 시간 만에 Terraform으로 배포되었습니다. 트리아지 에이전트는 전체 엄격함을 적용받았습니다: 아키텍처 검토, 인터페이스 계약, 12개의 설계 질문, 그리고 반복적인 코드 리뷰. Argo 통합은 인프라 계약과 IAM에 집중했습니다. Evaluation Harness는 가벼운 설계에 무거운 구현을 사용했습니다. AI-DLC는 복잡성에 맞춰 깊이를 자동으로 조정했습니다.
5일차가 끝날 무렵, 에이전트는 스테이징에서 라이브 상태로 실제 테스트 실패를 처리하고 있었으며, 측정된 정확도 기준선과 명확한 프로덕션 경로를 갖추고 있었습니다.
프로덕션 성과
트리아지 에이전트는 워크숍 이후 프로덕션에서运行 중입니다. 에이전트는 매일 밤의 엔드투엔드 테스트 실패를 자동으로 분류하여, 수동 1차 트리아지를 엔지니어가 검증하는 자동화된 1차 패스로 대체했습니다. 각 실패에 대해 에이전트는 원시 로그 대신 실행 가능한 다음 단계가 포함된 구조화된 수정 보고서를 생성합니다. 인간 트리아지와의 에이전트 분류 일치도는 초기 배포 시 44%에서 현재 68%로 상승했습니다. 팀이 골든 데이터셋과 프롬프트 엔지니어링을 반복 개선함에 따라 계속 향상되고 있습니다.
트리아지 에이전트가 프로덕션에 들어간 이후, 팀은 테스트 실패 분석으로 인해 프로덕션 배포가 막히는 시간이 20% 감소했다는 것을 측정했습니다. 이러한 테스트가 Rescale의 주간 프로덕션 릴리스의 게이트 역할을 하기 때문에, 그 감소는 변경 사항이 프로덕션에 도달하는 속도에 직접적으로 반영됩니다. 엔지니어들은 또한 반복적인 분류 업무에 온콜 근무를 소비하는 시간도 줄었습니다.
워크숍 이후의 삶: 하나의 에이전트에서 AI 우선 실천으로
워크숍은 하나의 프로덕션 에이전트를 만들어냈지만, 더 큰 효과는 Rescale이 엔지니어링 업무에 접근하는 방식에 미쳤습니다. 트리아지 에이전트는 AI 시대를 위한 디지털 엔지니어링 역량을 제공하려는 Rescale의 더 넓은 노력의 일부입니다. 내부적으로 Rescale은 AI로부터 실현된 이러한 이점을 자체 엔지니어링 조직 전반에 적용하고 있습니다. AI-DLC는 Rescale의 엔지니어들에게 그 방향을 실천에 옮길 수 있는 구조화되고 반복 가능한 방법을 제공했습니다.
조직 전반에 AI-DLC 확산
Rescale은 모범 사례를 정립하고 다른 팀들이 이 방법론을 독립적으로 채택하도록 돕는 소규모 그룹인 내부 AI-DLC Center of Excellence, 모범 사례를 체계화하고 다른 팀들이 이 방법론을 독립적으로 채택하도록 돕는 소규모 그룹입니다.
참여한 엔지니어들은 이미 배운 것을 적용하고 있습니다. 한 엔지니어는 이 프로세스가 “앞으로 내 워크플로우의 일부가 될 것”이라고 언급했는데, 에이전트 구축뿐만 아니라 AI가 기여할 수 있는 모든 복잡한 개발 업무에 적용될 것이라고 했습니다.
더 넓은 AI 네이티브 개발
Rescale는 이제 AI-DLC를 신규 엔지니어링 시뮬레이션 제품을 위한 표준 소프트웨어 개발 수명 주기에 통합하고 있습니다. 이 프레임워크는 시뮬레이션 도메인 전문 지식, 제품 요구 사항, 플랫폼 아키텍처, 검증 및 운영을 하나의 구조화된 설계 프로세스로 통합합니다. 팀은 핵심 질문을 조기에 해결하고, 검토된 결정을 실행 가능한 사양으로 문서화하며, 코딩 에이전트에게 명확한 수용 기준과 함께 집중된 작업을 부여합니다. 이를 통해 엔지니어가 제품의 정확성에 대한 책임을 유지하는 동시에 제품 개념부터 검증된 구현까지의 경로가 단축됩니다.
동일한 접근 방식은 이미 제품 지원 플랫폼 작업 및 에이전트 시스템에 사용되고 있습니다:
- HPC 시뮬레이션 애플리케이션 카탈로그 관리.
- 정부 규정 준수 요구 사항을 위한 컨테이너 취약점 추적 및 해결.
- 워크플로 기반 클라우드 코딩 에이전트.
결론
트리아지 에이전트의 경우, AI-DLC의 가장 유용한 결과물은 코드 자체가 아니었습니다. 그것은 초기 아이디어에서 검토된 시스템 설계에 이르는 구조화된 경로, 즉 명확화 질문, 범위가 지정된 요구 사항, 평가 기준이었습니다.
그 사양은 코딩 에이전트에게 더 좁고 더 잘 정의된 문제를 제공했습니다. 에이전트에게 구현하면서 아키텍처를 추론하도록 요청하는 대신, 팀은 사람들이 이미 검토한 결정에 따라 집중된 구축 작업에 에이전트를 활용할 수 있었습니다. 그 결과 통합하고 개선하기 더 쉬운, 더 집중되고 검토 가능한 산출물이 나왔습니다. Rescale에게 이것이 반복 가능한 패턴입니다. AI-DLC를 사용하여 설계 대화를 구조화하고, 그 결정을 사양으로 전환한 다음, 코딩 에이전트를 사용하여 구현을 가속화하는 것입니다.
주요 요점
- 실제 문제로 시작하십시오. Rescale의 트리아지 에이전트는 엔지니어링 과제를 해결했기 때문에 성공했습니다. 솔루션이 아니라 문제가 주도했습니다.
- 인간의 감독은 속도를 늦추는 것이 아니라 가속합니다. 시스템을 개선한 모든 아키텍처 전환은 AI 제안에 대한 인간의 검증에서 비롯되었습니다. AI가 생성하고 인간이 검증하는 모브(mob) 형식은 혼자 작업하는 것보다 빠릅니다.
- AWS 스택은 에이전트에 필요한 각 계층을 제공했습니다. Amazon Bedrock은 Rescale이 이미 사용 중이던 환경에서 분류를 위한 파운데이션 모델 액세스를 제공했으므로, 팀은 추가적인 모델 인프라 오버헤드 없이 트리아지 워크플로를 구축할 수 있었습니다. Strands SDK는 에이전트 프레임워크를 제공했고, Amazon EKS는 Rescale의 기존 파이프라인 내에서 컨테이너화된 에이전트를 호스팅했습니다.
AI-DLC 시작하기
- 방법론 이해하기: 다음을 읽어보십시오: AI-DLC 소개 블로그 및 적응형 워크플로 심층 분석.
- 서비스 탐색하기: Amazon Bedrock에 대해 자세히 알아보기.
- 지금 사용해 보기: 오픈 소스 AI-DLC 워크플로 규칙을 다음에서 복제하십시오: github.com/awslabs/aidlc-workflows.
- 실제 사례 보기: 다음을 통해 살펴보십시오: Amazon Q Developer를 활용한 실전 AI-DLC 구축.
- 연결하기: AWS 어카운트 팀에 문의하여 AI-DLC가 귀사의 특정 엔지니어링 워크플로에 맞게 조정될 수 있는 방법을 논의하십시오.